Enterprise Security Architecture Whitepaper

Enterprise Security Architecture

Managing Security across the Lifecycle

John Pavone, Director of Acceleration Services

Aspect Security, Inc. (www.aspectsecurity.com)
Email: john.pavone@aspectsecurity.com
9175 Guilford Road, Suite 300
Columbia MD, 21046
Phone: (direct) 610-574-0736 (office) 301-604-4882

Whitepaper: Application Architecture as a Catalyst to Securing Applications

October, 2007

Introduction

The IT industry is doing a good job in “patching” the security holes in our networks and host operating
systems. According to a recent Gartner study only 25% of the attacks seen today are aimed at the network
and host layers – that’s the good news – the bad news is that our business application is the attacker’s new
target of choice.
Are we as good at “securing” our applications?
Recently, the SANS Institute has made web application security the number one threat in their Top Twenty
Security Attack Targets (2006 Annual Update). The analyst community agrees, noting over 75% of
applications are vulnerable and 70% of attacks are now focused on these custom applications. Custom
applications and services are the hackers’ favorite target. The technology is evolving and connecting so
quickly that it has been very difficult for the security community to keep up. The attackers know this and
they’re taking full advantage.
Application security is challenging, and there are many tempting approaches out there. We’re here to tell
you that if you want to get value out of your application security efforts, put a plan in place that will drive
deep visibility into application security. Then you can manage with metrics.
In our experience, organizations that establish an application security team are the most likely to succeed.
The team should be responsible for both facilitating visibility and leading efforts to improve security.
Typically, those teams do training, verification, process, tools, architecture, etc…
Application Architecture Catalyst
Integrating application security with your application architecture functions provides reuse and a cost
effective approach to securing applications. The application security function should work closely with the
application architecture team to improve application security. Compare this with a reactive approach that
deals with application security late in the lifecycle. This “penetrate-and-patch” approach is significantly
more expensive and will never address the root causes that lead to applications security problems. Instead
of treating the symptoms, work with application architecture to eliminate application security issues before
they are a problem. Application architecture can be a catalyst to securing your portfolio of applications,
providing many of the fundamental people, process and technology capabilities required in improving your
application’s security posture.
 Enterprise Security Architecture Whitepaper

1 Applications are Vulnerable

Many organizations rely on the underlying infrastructure to protect their applications. These lead to what we
like to call the top 5 myths of application security. If these sound familiar in your organization, it’s time to
get serious about application security.

1. Perimeter security works ‐‐ my application is secure because it’s inside the firewall. 
2. Security is an infrastructure problem. 
3. Product “X” handles AAA (Authentication, Access Control, Accountability) for my application. 
4. Developers don’t need to understand security. 
5. Scanners achieve pretty good coverage. 

Attackers can by-pass your infrastructure security by simply following the security rules of the
infrastructure. This may sound somewhat recursive or self-defeating, but if attackers follow the simple rules
of a web application’s primary protocol, HTTP, many infrastructures would accept these requests and pass
them along to the application. This places your application in the direct line of fire of an attacker. Is your
application vulnerable to these attacks? How about the OWASP Top Ten?

The OWASP Top Ten

The OWASP Top Ten provides a powerful awareness document for web application security representing a
broad consensus about what the most critical web application security flaws are. Adopting the OWASP Top
Ten is perhaps the most effective first step towards changing the software development culture within your
organization into one that produces secure code. The statistics on the OWASP Top Ten are ridiculous --
90% of applications have XSS (cross-site scripting). We find serious issues in every application we analyze
(and that’s a lot). The following is the 2007 edition of the OWASP Top Ten:

A1 - Cross Site Scripting
(XSS)
A2 - Injection Flaws
A3 - Malicious File
Execution
A4 - Insecure Direct Object
Reference
A5 - Cross Site Request
Forgery (CSRF)
A6 - Information Leakage
and Improper Error
Handling
A7 - Broken Authentication
and Session Management
A8 - Insecure Cryptographic Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers
Storage use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
A9 - Insecure
Communications
A10 - Failure to Restrict
URL Access
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser
without first validating or encoding that content. XSS allows attackers to execute script in the victim's
browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when
user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data
tricks the interpreter into executing unintended commands or changing data.
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data,
resulting in devastating attacks, such as total server compromise. Malicious file execution attacks
affect PHP, XML and any framework which accepts filenames or files from users.
A direct object reference occurs when a developer exposes a reference to an internal implementation
object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can
manipulate those references to access other objects without authorization.
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a
vulnerable web application, which then forces the victim's browser to perform a hostile action to the
benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
Applications can unintentionally leak information about their configuration, internal workings, or violate
privacy through a variety of application problems. Attackers use this weakness to steal sensitive data,
or conduct more serious attacks.
Account credentials and session tokens are often not properly protected. Attackers compromise
passwords, keys, or authentication tokens to assume other users' identities.
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive
communications.
Frequently, an application only protects sensitive functionality by preventing the display of links or
URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized
operations by accessing those URLs directly.
 Enterprise Security Architecture Whitepaper

2 Application Security Challenges

Securing applications becomes a daunting task for most organizations. The sheer number of applications,
lines of code and architecture variations combined with the specialized skills and knowledge required to
security assess these applications leave information security and IT management at a loss. The challenges
of application security include knowledge / understanding / skill-set, technical complexity, and scaling.

Knowledge / Understanding / Skill-Set

Many IT professionals are not trained in application security so defining what needs to be fixed / changed in
the way we develop applications fall on deaf ears. Training requires careful planning to make sure the right
message and direction is being delivered. In our experience hands on training specific to the developer’s
programming platform is most effective.

Technical Complexity
Determining or assessing whether an application is vulnerable to attack is complex and requires specialized
skills. Developers do not think like attackers, so augmenting their skill-set to do this type of analysis is
difficult with only a few being able to make the transition. This causes the basic economic problem of supply
& demand – low supply of security analysts with high demand.

Scaling
So, an organization needs to train the masses, hire specialists, and get their arms around the applications in
their portfolio, all within budgetary constraints. Typically, a mid-large size organization has hundreds of
applications, millions of lines of code and varying technologies and architectures. How do you get assurance
that the applications are secure while keeping costs in check?

3 Approaches to Application Security

In our experience we’ve seen many approaches organizations take in achieving security in their applications.

The “Silver Bullet”

The first approach many organizations take to securing their applications is to find a product that will
automate the assessment of the applications already in production as well as facilitate the developer in
building secure applications -- the “silver bullet.” This seems like a viable solution and many are seduced by
its appeal to quickly provide coverage at a low cost. The reality is automated tools do provide a valuable
component to the application security plan but they do not offer the assurance coverage required and end
up costing more on intangibles like tool training, managing false positives, and overall buy-in from the
development community. Automated tools are not the “silver bullet” for application security, but can
compliment an overall security plan.

“Penetrate and Patch”

Organizations that are introduced to application security through actual production incidents quickly go on a
reaction based plan and remediate their issues with a “SWAT” team approach. They bring together their
best IT technicians paired with outside security consultants and fix their most critical applications in
production. This usually carries a high cost but remediates quickly. This approach does remediate
production vulnerabilities, today, but without proper analysis and planning may not remediate root causes –
“Treating the Symptom.” Providing enterprise based security controls and augmenting development
processes to define and design with security in mind establishes a repeatable and consistent approach to
application security. The “SWAT” team approach may fix vulnerabilities today, but they typically reappear
over time.
 Enterprise Security Architecture Whitepaper

“One at a Time - Ad-Hoc”

A small penetration test team is formed, tools are purchased and they’re ready to assess applications.
Communication is sent out to the development community and if the application teams think about it or the
business forces them to, the penetration test team will assess their application. This is what we refer to as
the “Ad-Hoc” approach. It does provide for a repeatable and consistent security assessment process, but
there’s no priority or plan of execution in order to know whether your critical applications are secure and
dollars are being spent wisely. Securing one application at a time does not work without an overall priority
and execution plan.

Need an Application Security Plan

All the approaches above offer application security capability, but in order to improve an organization’s
application security posture, a security plan across people, process and technology is needed. This usually
begins with establishing a dedicated application security function (team) to address and formulate a plan.
The plan must establish a line of site from policy to implementation, cover the entire application portfolio,
manage improvement through metrics, and most importantly, invest in people, process, and technology.

4 Application Security Team

Many organizations, particularly in the financial industry have established teams that focus on various
aspects of application security. This trend started about 2002 and has continued to grow slowly for the past
five years. At this point, a majority of financial institutions have a specialized application security team of
some sort. There are many types of these teams, ranging from small 1-2 person teams to larger groups
with a core team and an extended team of field architects.
The Application Security Team role is to improve the security of the organization’s entire software
application inventory by discovering and managing application security risks. The team also encourages
security improvements to the people, process, and technology involved in acquiring, building, and
maintaining applications.

People and Teams

The Application Security Team provides a critical single point of focus for an organization’s application
security efforts. A key foundational element is for the team to establish a security awareness and training
program for developers, managers, and architects. The team will also provide subject matter experts (SME)
support to development projects. Finally, the Application Security Team will be responsible for keeping
management apprised of the state of application security across the organization.

• Provide Application Security Awareness and Training Program 
• Provide Application Security SMEs and Support Services 
• Report on Application Security to Senior Management 
• Manage Application Security 

Process
The Application Security Team also plays a critical role in defining and implementing process improvements
designed to more reliably create secure software. The team will establish a set of application security
policies and standards, and then perform various reviews throughout the lifecycle to ensure they are being
followed.

• Integrate Security Activities into the Application Development Process 
• Provide Application Security Assurance (Verification) Reviews 
• Steward Application Security Policy and Standards Framework 
• Measure and Improve Process Effectiveness 
 Enterprise Security Architecture Whitepaper

Tools and Technology

The Application Security Team is in the best position to establish an application security portfolio that
indicates exactly which applications are the most critical. The team should also work to standardize
enterprise security controls and APIs, to maximize reuse and assurance. The team should also identify the
supporting tools, such as vulnerability and code scanners, and play a major role in determining how they are
to be used.

• Manage Application Portfolio 
• Establish Application Security Knowledge Portal 
• Establish Enterprise Controls and APIs 
• Institutionalize Standard Application Security Tools 

5 Synergies with Application Architecture

So where does application architecture come into play? There are many synergies between application
security and architecture functions. Application architectures need to understand the business plan,
inventory applications, and establish a consistent and repeatable approach in the design and implementation
of applications. The process they follow can be leveraged by application security to provide a quality based,
consistent and cost effective approach in fulfilling the application security plan.

Leverage people
Application security can virtually scale their staff by leveraging application architects as security analysts.
They offer the closest skill-set and usually look at problems from a macro-design viewpoint. The architects
are also in the development community and have established working relationships, providing the much
needed buy-in from developers.

Utilize existing processes

Application architects are already integrated within the application development process conducting design /
architecture reviews and planning activities. Augmenting their reviews to provide security relevant
assessment provides early assessment activity and broad coverage.

Design with Security in Mind

Understanding an application’s technical and business profile determines the level of inherent risk. Much of
this information has already been collected by application architects and could be leveraged to prioritize the
level of security assurance required across the portfolio. Application architectures can be reviewed with
security in mind establishing and enforcing secure design patterns, standards and implementations.
 Enterprise Security
S Architecture White
epaper

6 Con
ntinuous Im
mproveme
ent Proce
ess

An applica
ation security plan should im
mprove the se
ecurity posture
e of an organization by insttituting a
continuous improvemen nt process. The
T following diagram
d depic ontinuous improvement plan:
cts a 4 step co

1. Define
e what’s Imp
portant to Prrotect
You have to establish some priorities s, and that me
eans understa anding what’s important to protect. You’’re
trying to achieve
a a “line
e of sight” from
m your enterpprise level sec
curity concerns s all the way through
t the la
ayers
to the impplementation details.
d That’s the only wayy to know tha at you’ve effecctively addressed all the risks.
Application
n architecturee artifacts can be leveragedd to define crittical assets & functions
f oss the portfolio of
acro
application
ns.
 Enterprise Security
S Architecture White
epaper

2. Establlish Security
y Controls
Applicationn security use
es a number ofo different conntrols. Many are
a technical, but don’t forgget about the
people and process con ntrols. Applica
ation architectture can directly address th
he technical co
ontrols by
integratingg them into architecture deesigns. Appliccation architec
cture teams an nd process im
mprovement
capabilitie
es can also be leveraged by y application se
ecurity.

3. Verify Security an
nd Diagnose Risks
Thinking like an attackeer is a difficultt skill-set to ac
cquire. Definiing security analysis processses including
threat mo odeling, vulnerrability assesssment and risk k analysis into
o the developmment lifecycle will help esta
ablish
a consisteent and repeattable security function. Utilizing applicattion architects s as security subject matterr
experts ca an provide suppport services s to the application teams in n performing these tasks. Architects can n
facilitate code
c reviews, security testin ng and archite ecture/design reviews. Hav ving the architects involvedd in
these key security activvities will prov
vide insight on n the applicatio
on’s risk postu
ure leading to
o securer
implementations. Auto omated tools provide
p a valu
uable capability in data colle
ection and cov
verage.
 Enterprise Security Architecture Whitepaper

4. Analyze Metrics and Improve the Organization

Metrics should be collected every step of the way. Metrics can measure the effectiveness of the application
security plan from which management can make key decision on direction and budget. Metrics should
address people, process and technology improvements including application coverage, risk management,
and training.

7 A Catalyst for Application Security

An organization’s application architecture function can provide critical benefits to the application security
plan. Leveraging the existing people, process and technology activities provided by many application
architecture functions gives the application security team a jumpstart. Benefits include cost effectiveness,
higher quality, scaling and flexibility in staffing, and an overall better security process.

About the Author:

John Pavone has been an IT professional for over 20 years. In the last 12 years, John has concentrated
solely on Information and IT Infrastructure Security. John works for Aspect Security, a leader in the
application security consulting space, as a practice lead specializing in the enablement of application security
within organizations. John held various security related management positions, including the chief security
architect for a large financial services firm. In this role, John established an enterprise–wide IT security
program utilizing a quantitative risk assessment and mitigation approach with a direct line of sight to the
organization’s corporate dashboard. Other major accomplishments include the development and
mainstreaming of an IT risk management process, the creation of an application vulnerability testing lab,
and the security design and implementation of an enterprise single sign-on and authorization system.