Index:
1) Editor's Notes by Jaime Marcial
2) Announcements
3) Designing a solid foundation for our service interfaces by Jaime Marcial.
4) Application Layer Security: Myth or Reality? By Jason C. Hayek, Principal
Triad Information Security Services, LLC
5) Illinois Institute of Technology offers new short course on SOA
6) About Modularis
1. Editor's Notes - by Jaime Marcial
In this issue, we will analyze the foundation of a Service Interface and how we
can deliver all the quality characteristics expected from a mission-critical
enterprise system.
In addition, Jason C. Hayek from Triad Information Security Services, LLC gives
us some good pointers on how to think about and write secure code. He highlights
the most common mistakes that we developers overlook.
I found his article very helpful, when not only designing or implementing a
Service-Oriented Architecture, but also in my everyday software development.
I hope you find it as useful and informational as I did.
2. Announcements
* Modularis Accelerator 6 gets rave review in the October Issue of .NET
Developer's Journal
Doug Holland of the .NET Developer's Journal puts Modularis Accelerator 6
through its paces. Read the full review at the following URL:
http://www.accelerating.net/reviews/DNDJ_ProdReview.pdf
* Modularis employees donate their time and software to help i.c.stars deliver
the latest technology training to inner city young adults in Chicago. Read the
full announcment at the following URL:
http://www.icstars.org/pr/040817.htm
3. Designing a solid foundation for our service interfaces - by Jaime Marcial
Last month, we went through the exercise of defining the service interface for
the Order Management service. This month, I want to concentrate on the
infrastructure patterns that are necessary to provide a stateless and secure
persistence mechanism.
In order to provide all the quality characteristics of a critical enterprise
system, we need to think about a well-architected application architecture to
support our service interfaces. Designing a flexible logical architecture will
allow us to distribute the workloads in certain areas of our system as the
demand or load grows. This is not a new concept--layered applications have
existed for over 20+ years.
Let us think about scalability for a second. Assume that we implemented the
order management service as a monolithic class, which we expose using IIS and
web services.
Also, assume that the bulk of processing power is not in handling each web
service request, but rather in processing the request (database operations
included). We have a farm of n web service servers to handle a large number of
users. All machines are identical, and we have reached the limit of the
simultaneous requests that those servers can handle. The solution? Add another
server.
A deeper analysis of the problem shows that the bulk of the CPU cycles are
required to process authorization, data validation and business rule execution.
If we design our solution with scalability in mind, instead of adding another
server to the web service farm, we could reconfigure our physical architecture
to have the minimum number of servers handling the web service requests and
optimize the remaining servers to run the business and security code.
This may or may not be the proper solution to your situation, but it enables you
to individually load balance your web/web services interface, application and
data layers, letting you get the most from your hardware.
On the other hand, we improve maintainability by organizing the code into
well-encapsulated, clearly-defined layers. In addition, by establishing
patterns, the learning curve for a developer unfamiliar with your application
decreases dramatically.
I can go on and on about the benefits of layered infrastructure architecture, so
instead let us look at an actual design.
We can start with the following well-known stateless n-tier design:
User Interface/Service Agents/Service Consumers <-> Service Interface <->
Business Layer <-> Data Layer
In this design, lightweight classes or data objects that describe the business
entities and the relationships between them are used to transport the data
values between layers. Each layer then performs certain operations on the data
that are in-line with that layer's specific responsibilities.
For example, the User Interface Layer encapsulates the code used to render a web
page or a windows form. This layer also contains code to transform the raw data
obtained from a Service Interface into something meaningful to the application
user.
A Service Interface encapsulates the code that orchestrates the flow of business
processes. The business layer encapsulates the atomic data validation and
business policies applied to a specific entity or set of entities. The data tier
encapsulates the code that is necessary to communicate with the persistent data
store, isolating the application from having to know the mechanics of dealing
with a file system, relational database server, etc.
While this architecture is a step in the right direction, other supporting
services are required for truly enterprise-caliber applications. For example,
the User/Service interface requires access to an authentication mechanism, the
business layer requires access to an authorization service, and the data layer
may require another level of abstraction to support data source portability.
In conclusion, you can design a Service-Oriented Architecture and still end up
with monolithic implementations for each service. You should continue to spend
time carefully designing your service interfaces, but do not overlook the
architecture of the infrastructure that supports your SIs. A solid foundation
for your services will guarantee that your applications exhibit the
characteristics of sound software architecture (functionality, reliability,
usability, maintainability, scalability, flexibility, portability, availability,
and agility).
Next month, we will analyze the different infrastructure services that
complement our infrastructure architecture.
About the author
Jaime Marcial, a Senior Software Architect at Modularis, Inc., has a background
in software architecture, software development methodology, data modeling,
application development, and a host of other technologies. He serves as an
architect, trainer and consultant at Modularis. He co-authored the Modularis
Enterprise Application Development Methodology, and is one of the lead designers
and developers of the Modularis Accelerator tools. Jaime can be reached at
marcialj@modularis.com.
4. Application Layer Security: Myth or Reality?
by Jason C. Hayek, Principal, Triad Information Security Services, LLC
Myths
A common belief in the development community is "security by obscurity."
Programmers will ask themselves, "Why would someone want to exploit my
application?" Or, even if someone wanted to exploit my application, we have
network security in place and we're leveraging Secure Socket Layer (SSL)
communications. Besides, application security reviews are just too time
consuming and expensive. All of the above are common myths about application
security.
Secure applications are a bit of an oxymoron, right? There is no such thing as
a totally secure application, and anyone that tells you otherwise has likely
fallen for one of the oldest myths in the book. What history has taught us is
that where there is a will to compromise an application, there is a way. Even
though no application will ever be 100% secure, the practice of writing secure
code still requires much consideration, as many applications are reaching out to
all critical areas in an organization, including those that maintain proprietary
and confidential data.
I would suggest that it is not that difficult or expensive to develop secure
applications, and if organizations change their mindsets about application
security, the cost/benefit equation will seem much more reasonable.
Changing One's Mindset
The biggest challenge in learning how to write secure application is changing
how you think about developing software. There are six overall considerations
to keep in mind when developing secure code.
1. Technology alone (firewalls, encryption, etc.) does not solve application
security issues. It is imperative to remember that most security breaches come
from inside the firewall.
2. Routine testing only discovers very common vulnerabilities. Successful
hackers think outside the proverbial box. Rather than only testing what users
are supposed to do with the application, developers should consider assessing
all the things that an inquisitive user can do with the software.
3. The most secure code is developed by the slightly paranoid. Developers
have to test their assumptions and not just assume they are valid. Keep in mind
that although applications are often developed in a "vacuum," unique security
risks present themselves when released in different production environments.
4. Determine the application specific security requirements. Before you can
determine how to write a secure application, both the business owners and
developers need to determine exactly what the security requirements are. Due to
tight schedules and market pressures, and in order to release applications to
production as quickly as possible, development team managers often do not plan
enough time for security during coding and testing
5. Consider your defense in depth strategy. One of the best ways to address
application security is to adopt a defense in depth strategy. For example, if
someone does achieve unauthorized access, are there processes in place to
protect the data from easily leaving the organization?
6. Don't downplay security training and awareness. Although training and
awareness should be considered part of a defense in depth strategy, it's
criticality to developing secure code cannot be emphasized enough. In order to
sustain a secure coding process, the entire development team needs to embrace
application security training and awareness.
The Biggest Risks Associated with Application Security
The business risks associated with ineffective application security are
tremendous. Most of the time, the cost of repairing the damage from an
application breach will outweigh the cost of securing it. Although it can be
challenging to calculate actual damages from an incident, some of the most
damaging components of an incident often include both tangible and intangible
repercussions such as permanent loss of data, loss of revenue, fraud, loss of
productivity, damage to credibility/reputation, and legal liability.
Applying Fundamental Security Principles
Applying fundamental security principles throughout all phases of development,
especially the planning and early stages, are some of the most frequently
overlooked principals of writing secure code. If developers apply the following
information security triad, they will be well on their way to building
fundamentally secure applications:
* Confidentiality - ensuring that information is accessible only to those
authorized to have access;
* Integrity - safeguarding the accuracy and completeness of information and
processing methods; and,
* Availability - ensuring that authorized users have access to information
and associated assets when required.
Avoiding the Application Security Top 5 Most Wanted List
Almost everyone that has developed applications has likely heard of the most
prevalent security related programming issues. But time and time again, these
"Top 5 Most Wanted" issues cause severe headaches for many application
development teams and exponential problems their organizations. As such, the
Top 5 mandate a dishonorable mention!
1. Buffer Overruns / Heap Overflows - Can allow the attacker to gain root /
administrator access when extra bytes of data are dumped into stack memory /
memory addresses and malicious code is executed.
2. Format String Vulnerabilities - Can allow an arbitrary value to be written
into the memory of the running program. For example, at a basic level, when a
*printf() function is called and the user can input format strings ( %s %p %x),
the *printf() function will utilize the user supplied arguments, and they may
have malicious intent.
3. Denial of Service (DOS) - DOS attacks can also occur at the application
level versus the network level. Simply attempting to login enough times (e.g.,
flooding) can lock out the particular user ID.
4. Cross-Site Scripting (XSS) Vulnerabilities - Can occur when an attacker
uses a web application to send arbitrary code/scripts to an often unsuspecting
and often trusting end user.
5. Web Application Input Validation Problems - Can occur when a Web
application accepts input from a client browser and then passes that input to a
database or CGI processor without ensuring the data is valid. The most well
know version of this vulnerability is SQL injection.
Defense In Depth
Although defense in depth may sound cliche by now, strong application security
practices consider all levels of security, not just the application layer. The
process side of an application security defense in depth strategy will include,
at a minimum, documentation of secure programming practices, coding standards,
compliance validation, and training and awareness. An organization will be
unsuccessful at executing a defense in depth strategy if application security is
an afterthought of writing the code. By leveraging secure coding practices and
identifying common vulnerabilities during the early stages of application
development, organizations will be adding layers of defenses against potential
threats.
Conclusions / Closing Statements
It doesn't have to be difficult or expensive to develop secure applications. If
organizations change their mindsets about application security, the cost/benefit
equation will seem much more reasonable. Simple modifications and additions to
the development team's thought process will go a long way toward writing secure
code. By leveraging fundamental security principles (such as the information
security triad) and being cognizant of prevalent programming issues,
particularly at the planning and early development stages, organizations can
cost effectively manage their application security risks.
About The Author
Jason Hayek is the President and Co-Founder of Triad Information Security
Services, LLC based out of Chicago, Illinois. Triad's sole focus is information
security consulting. Triad offers a wide range of service offerings including:
security strategic planning, security assessments, application security reviews,
regulatory compliance, and technology integration. One of Triad's specialties
is advising organizations of all sizes on how to effectively align information
security and business operations. Triad reduces risks associated with malicious
activity and human error by appropriately aligning People, Process, and
Technology.
You can contact Jason Hayek at:
jhayek@TRIADINFOSEC.com
(office) 847-670-6744
5. Illinois Institute of Technology offers new short course on SOA
IIT has just announced a new 2-day course centering around SOA and .NET:
SC 414 - Accelerating the Software Development Lifecycle
In this course, the latest tools, techniques, and methodologies to accelerate
the software development lifecycle will be discussed. The best practices for the
architecture, design, and implementation of mission-critical software on the
Microsoft .NET platform will also be covered in some detail.
This course will explore Service-Oriented Architecture (SOA) and its impact on
software quality, efficiency, performance, and flexibility. A practical approach
to implementing SOA rapidly and safely will be demonstrated via a hands-on lab.
Prerequisites: Participants should have a basic understanding of object-oriented
design and computer programming. Experience with Microsoft .NET is recommended,
but not required.
Who should attend: This course is valuable for anyone interested in learning
about the latest advances in software architecture, tools, and techniques that
accelerate the software development lifecycle and drive down the risk, time, and
cost of software development.
Expected outcomes: Participants will learn Service-Oriented Architecture (SOA),
Model-Driven development, and will be able to start designing and rapidly
building SOA-enabled .NET software applications.
Date: Nov 9 - 10, 2004
Cost: $695
CEU: 1.4
Course #: SC 414
Location: IIT Rice Campus - Wheaton
Course Outline:
Day 1: Interactive Discussion
* Introduction to the Accelerated Software Development Lifecycle
* Introduction to Service-Oriented Architecture (SOA)
* Impact of SOA on the Software Development Lifecycle
* Impact of SOA on software quality, performance, and flexibility
* Introduction to Model-Driven Development
* Lessons from Manufacturing: Tools and Techniques to automate software
construction
* Accelerated Lifecycle Case Study Review
Day 2: Hands-On Workshop
* Designing, Building, Testing, and Deploying an SOA-Enabled .NET application
Registration:
Online - Visit http://www.cpd.iit.edu/shortcourse/register, complete the online
form and submit.
Call Janet Reif at 630.682.6035 or E-mail reif@iit.edu
6. About Modularis
Founded in 1999 and headquartered in Chicago, Illinois, Modularis, Inc. is doing
for software, what automation and robotics has done for manufacturing. Modularis
leveraged its expertise in Service-Oriented Architecture (SOA) and automation to
build Modularis Accelerator 6, an Architected-RAD environment without equal on
the Microsoft .NET platform.
Accelerator enables Modularis customers to build scalable, available, and
maintainable .NET applications at a fraction of the risk, time, and cost
typically associated with custom software development. For more information
about Modularis Accelerator, call Gery Knapp at (312) 648-1740 x208, or visit us
on the web at www.accelerating.net.
|
