Mapping Application Security To

Business Value:
Considerations And Recommendations For IT
And Business Decision Makers

Because applications
are a reflection of the
business, we believe
application security plays
a major role in creating
and retaining business
value system.

6450 Via Real, Suite3

Carpinteria, CA 93013

WHITE PAPER
800-721-9177
805-684-6858
 TABLE OF CONTENTS
1 Summary

2 The Role of Applications within the Information

Security System

3 Secure Software Development

4 Integrating the Application within the Information

Security System

5 Creating Business Value

6 Business Impact

Page 1 | www.redspin.com 2009 | White Paper

 Summary
This white paper outlines considerations
and recommendations for reducing
business risk by ensuring that your web
applications are secure.
Our goal is to present information
that will be helpful not only to IT and
information security professionals
but business unit general managers
as well. We will examine the
process of managing applications
throughout their lifecycle.
In an earlier white paper we introduced
We consider a simple top-down system for making the
association between security initiatives
application security and business metrics for the purpose
of better managing the information
from the standpoint security system. In this white paper we
will examine the relationship between
of supporting an investments in application security and
the metrics that drive business growth.
effective compute We will also explore the various
alternatives to approaching application
and communications security as well as the pros and cons
associated with each.
infrastructure... In a recent Harvard Business Review
article titled “The Big Shift” (HBR; July-
August 2009; John Seely-Brown, Lang
Davidson) the authors presented the
idea that in times of economic crisis
such as those we face now, traditional
metrics for managing business may be
insufficient to point the way forward.
The HBR article presents a framework for
understanding business transformation
in terms of three factors: foundations for
major change (such as compute power
and Internet usage), flows of resources
(such as information and knowledge)
Page 2 | www.redspin.com
and the impact of the combination of
the previous two factors on companies
and the economy. As is often the case
in business, this framework is measured
as an index (the shift index) comprised
of three components: foundation, flow
and impact. The foundation index is
strongly influenced by computing and
communications (Internet) infrastructure.
The flow index is influenced by
information sharing and Internet activity.
The impact index is influenced by
brand loyalty and competitive intensity.
The article concludes by challenging
executives on how can they best create
and capture value by managing these
factors.
Throughout this paper we will examine
what can be done with respect to
application security in terms of enabling
business by actively managing these
factors. Because applications are a
reflection of the business, we believe
application security plays a major role
in creating and retaining business value.
We frame the discussion of this role as
part of the overall security system whose
efficacy can be evaluated in terms
suggested by Seely-Brown and Davidson.
We consider application security
from the standpoint of supporting an
effective compute and communications
infrastructure (positively impacting the
foundation index). We examine the role
of applications in supporting the flow of
information and knowledge resources in
a secure fashion (positively impacting the
flow index). Lastly, we explore methods
to securely deploy applications and
business process to protect corporate
brands and promote competitive
advantage (positively affecting the
impact index).
2009 | White Paper
 The Role Of Applications Within The Information
Security System
For an application security system to support the business we must treat it like a system. It
must have structure and be measurable. We suggest a different approach that starts with
a top down perspective. We also believe that a system must be rich with the necessary
information but simple enough to support business decision making.

Our application security system uses the terms presented in the HBR article. Ultimately
we have three elements to manage with three associated indices to track. The system is
illustrated in table 1.

Foundation Flow Impact

Key Elements Storage, Compute, Data, Information, Business

Applications, Knowledge, People Processes,
Communications Business Value
Infrastructure

Key Metric Availability Confidentiality Integrity

Table 1. High level elements and metrics associated with the Information Security System

Note that aspects of application security make contributions in all three categories.
Next, we must think about the elements that connect the application security system
with the business. As with any other major subsystem of the overall information
security system, application security is a factor to consider in each major area of
the systems. An application security system must be driven by policy, integrated
with the overall strategy and tightly coupled with the controls that carry out holistic
protection objectives. An ideal description of the customer security system is shown in
the following diagram:

The Role Of
Applications Within
The Information
Security System

Figure 1. The Information Security System

Page 3 | www.redspin.com 2009 | White Paper

 Now, let’s examine where various aspects of the application security program fit in. Table
2 illustrates some key application security areas and their relation to our foundation,
flow, impact model of the information security system.

Foundation Flow Impact

Key Elements Storage, Compute, Data, Information, Business

Applications, Knowledge, People Processes,
Communications Business value
Infrastructure

Key Metric Availability Confidentiality Integrity

Application Developer Training Data Classification System Integration

Areas

Architecture Information Privilege Change Management

Threat Modeling Identity and Access Regulatory

Management Compliance

Privacy Audit Process Risk Assessment

Code Review Security Enforcement Incident Response

Mechanisms

Security Checklists Encryption and Key Production Testing

Management

Source Code Pre-Production Risk Management

Analysis Testing

For an information security system to be running optimally managers must make decisions
about each of these application security areas and put in place processes to carry out
their decisions. If managers ignore their responsibility or take shortcuts on process, ad-
hoc decisions will fill the void. These decisions often have disastrous results.

Let’s discuss a few of the application security areas in each category to explore the
relationship to the overall information security system and business value contribution
through the foundation, flow and impact framework.

Page 4 | www.redspin.com 2009 | White Paper

 Foundation – Secure Software Development
Developer Training
As web applications have become
more fundamental to the business,
security training which may often have
started through ad-hoc processes must
become formalized and widespread.
Developers cannot be held accountable
for security issues if they have not been
adequately trained. We recommend
general purpose security training for all
team members including QA staff. We
would also recommend specific training
targeted by development role.
Architecture
Just as the functional architecture
specifies the relationship between the
major subsystems that make up the
application, the same must be true of the
core security services that govern security
of the application. Often the team can
draw upon general application security
policies and specify how these general
policies manifest themselves in the
specific application environment. For
example, the general policy may make
statements regarding input validation, but
the architecture must refine these specific
to the business requirements and security
context associated with the application.
Threat Modeling
In order to have an understanding of
the risks associated with an application;
Often the team can developers must understand the threats
that are present. A common practice
draw upon general is to develop a threat model that
characterizes the threats and risks to
application security the application. Microsoft has invested
significant resources in formalizing
policies and specify this process. They recommend a step
by step process of identifying security
how these general objectives; reviewing the application
in terms of components, data flows
policies manifest and trust boundaries; decomposing
the application in terms of components
themselves in the to identify areas where security needs
to be evaluated; creating a structured
specific application list of threats; and enumerating likely
vulnerabilities associated with the
class of application in development.
environment. To assist in this effort of threat and risk
modeling Microsoft advocates a threat
classification scheme known as STRIDE.
Page 5 | www.redspin.com
This scheme aims to characterize the
threats with respect to the exploit that
may be employed. This clever acronym
stands for:
S poofing Identity
Tampering With Data
R epudiation
I nformation Disclosure
D enial Of Service
E levation Of Privilege
These areas provide a helpful
mechanism for enumerating threats to
the application.
Risk Assessment
As with any endeavor related to security,
we recommend a risk based approach
where development effort to secure the
application is guided by the risks to
business. Closely associated with this
process is a scoring scheme to help
evaluate risk to the application. Another
acronym applies to this problem as well:
DREAD.
DREAD attempts to quantify, compare and
prioritize the amount of risk presented by
a given threat. It stands for
D amage Potential
R eproducibility
E xploitability
A ffected Users
D iscoverability
Typically each of these areas is assessed
on a scale of 1 to 10 with 10 referring
to the most severe risk. As always risk
needs to be evaluated in terms of both
probability and impact.
2009 | White Paper
 Code Review
We recommend that an application in development pass a thorough code review. By
no means, do we expect each developer to walk through their sections line by line. In
contrast, this is an exercise that ensures that common assumptions are agreed upon,
and no major misunderstandings are present. A reasonable sample outline is suggested
as follows:

• Monitoring of security metrics is supported.

• Secure operational environment is specified.
• Attack surface and threat environment is understood.
• Misuse cases have been identified.
• Global security policy (for the project scope) is in place.
• Resource and trust boundaries have been identified.
• User roles and resource capabilities are understood.
• Security relevant requirements have been documented.
In practice the agenda and topics covered will undoubtedly be lengthier, but this serves
to give you a flavor of the process.

Security Checklists
These simple checklists are often useful for developers to keep security principles in
mind. Listed below is a subset of an actual checklist. These lists should also adapt
themselves to the business goals, threat environment and usage scenarios associated
with the application.

Procedure Category Goal

Denial Custom Application Does application continue to

of Service Vulnerability function normally when given abnormally
large input values, query strings, or
cookie strings?

Cross Site Custom Application Does the application allow scripts to be

Scripting Vulnerability reflected within the HTML content stream
and execute when viewed in a browser?
Does the application allow users to store
persistently harmful scripts?

SQL Injection Custom Application Does the application allow a user to

Vulnerability elicit database errors or run arbitrary
database commands by sending
unexpected input sequences?

OS-level Custom Application Does the application allow a user to

Command Vulnerability execute system commands by submitting
Injection specially crafted values in form fields
and/or query strings?

Authorization Authentication Does the application successfully restrict

Mechanisms access to all pages, scripts and objects for
which authentication is required? Is it
possible to access restricted resources via
forceful browsing?

Authorized Authentication Does the application properly enforce

Pages/Functions Mechanisms security controls to registered or
authenticated users? Does the application
allow a user to manipulate query strings
and obtain access to restricted URLs?

Authentication SSL Security Does the application allow user

Endpoint passwords to be submitted over
Request Should non-SSL connections?
Page 6 | www.redspin.com be HTTPS 2009 | White Paper
 Security Checklist (Cont.)

Procedure Category Goal

Authentication SSL Security Does the application allow user

Endpoint passwords to be submitted over
Request Should non-SSL connections?
be HTTPS

Credential SSL Security Once an SSL session is established, are

Transport Over there any cases when a user browses
an Encrypted to an HTTP resource?
Channel

Session Token Session Security Does the application utilize session IDs
Security that are sufficiently long and random?

Session Session Security Does the re-use of Session IDs allow

Hijacking one user to obtain access to another
user’s session?

HTTP Methods Infrastructure What HTTP methods does the web server
Testing support? Does the web server support
HTTP methods such as PUT or DELETE?

Source code analysis Web Server Infrastructure Are there configuration dependent
Configuration Testing vulnerabilities on the server? Depending
tools can provide Common Paths upon the web server type, what are the
most common configuration errors and

a useful point are they present?

of automation Directory
Browsing
Infrastructure
Testing
Can any directories be browsed?

in identifying User Error Environment Does the application reveal sensitive

Messages Security information in its error messages related to

potential risks and the presence or absence of user accounts?

vulnerabilities.
Source Code Analysis
Source code analysis tools can provide
a useful point of automation in identifying
potential risks and vulnerabilities. This
process may easily be integrated within
the build cycle. However, when it comes
to analysis those performing the analysis
must be equipped with the system
requirements and security specifications;
the threat profile for the system and any
additional supporting documentation.
The team is then equipped to examine
the tool output and determine whether
risks are relevant or not. The threat profile
may also help rule out potential risks and
vulnerabilities. Nevertheless, the findings
in scope must be addressed.

Page 7 | www.redspin.com 2009 | White Paper

 Flow – Integrating The Application Within The
Information Security System
Data Classification
Although this is a system wide information
security initiative application developers
and owners should create an inventory of
data expected to be used and generated
by the application. This exercise typically
classifies data as High Business Impact
(HBI), Medium Business Impact (MBI)
or Low Business Impact (LBI) depending
on the business requirements and the
confidentiality, integrity and availability
implications. Corporate security policy
should help in this regard.
Information Privilege
Again corporate security policy can
act as a reference point in making
decisions regarding information
privilege. Ultimately the decisions in
this area will reside in the application
security specification. It is useful though
to consider the total scope of information
sources and the associated privilege
levels. Internal policy requirements as
well as regulatory requirements will aid
in shaping these decisions.
Identity and Access
Management
When making identity and access
management decisions it is important
to have a clear understanding of the
type of customers the application will be
addressing. Clearly, different solutions
will present themselves for a consumer
facing banking application than for an
internal travel and expense system. It
The goal should be a is best to make this decision early and
then iterate and refine implementation
systematic reduction strategies as you refine the threat and
risk models as well as the application
in the number of specification.
Privacy
vulnerabilities over Privacy is another area that should be
dictated by corporate security policy and
time even as new reinforced by the application. There may
be circumstances where the application
functionality is is intended to be used internationally
and corporate policy has not yet caught
added. up with privacy laws in those countries.
In this case the application team must
do their own research and fold back the
results into corporate policy.
Page 8 | www.redspin.com
Security Enforcement
Mechanisms
Keep in mind that the application resides
within the infrastructure and you should
take full advantage of the enforcement
mechanisms that exist. The same is true of
monitoring mechanisms. The application
team does have to exert effort to ensure
that they understand how enforcement
works and what they expect to achieve
(whitelisting, blacklisting, etc.).
Encryption and Key
Management
Encryption can play a key role in reducing
the attack surface for critical data. Here,
you can use the output of the data
classification exercise to decide what
to encrypt. Key management is also an
important factor in the overall process. A
critical attribute to seek out are solutions
where you don’t have to change your
database table sizes to accommodate
encryption. In other words, the encrypted
data is the same size and data type as
the clear text data.
Preproduction Testing
Whether performed by QA or operations
pre-production testing is usually performed
using black box tools and should be done
in an environment that is nearly (if not)
identical to the production environment.
This activity should be performed as part
of the daily build cycle. The goal should
be a systematic reduction in the number
of vulnerabilities over time even as new
functionality is added.
2009 | White Paper
 Impact – Creating Business Value
System Integration
Very few applications in modern environments exist as standalone entities. At the very
least they employ directory services or back-up services. In most circumstances the
application is providing or receiving data from other applications, sometimes directly
or quite commonly through an enterprise message bus. It is imperative that the test
environment reflects these conditions and that no vulnerabilities are introduced through
this additional connectivity.

Change Management
Change management controls when fixes to the application may be introduced.
Processes should be stipulated by policy. An important practice is to document well the
circumstances surrounding the need for the change. Often, a new set of vulnerabilities
will have been found, but it is equally important to note if there has been a change in
threat model or with the supporting infrastructure.

Regulatory Compliance
We advocate creating policy such that internal compliance encompasses regulatory
requirements. In any circumstance testing procedures need to ensure compliance with
the applicable regulations. This is often a good opportunity to perform a web application
assessment from a trusted third party in that compliance is generally a cut and dried
area, but the assessment may also surface other important areas of consideration.

Audit Process
One aspect of the secure application development process should consider making
the audit process easy and predictable. Strong documentation, predictable logging,
and demonstration of adherence to policy all contribute towards a successful audit
experience. Most importantly anticipating and preparing for an audit makes this task
just another predictable item on the schedule rather than a fear inducing experience that
can disrupt performance to schedule.

Incident Response
What happens if there is a data breach? We recommend that you prepare in advance
for the actions that will be taken. Further, responding to an incident will extend beyond
just the core applications team. Be clear on the roles and responsibilities of security,
operations and your own applications group.

Production Testing
To assess applications running in production a different strategy must be employed. One
potential approach is to do application penetration testing with a suite of attacks that are
known to be non-invasive and likely will not take down the application. A better option,
if the application is deployed in a virtualized environment, is to take a “snapshot” of
the application to be tested. This image is then moved to a staging environment where
it can be tested thoroughly. When vulnerabilities are identified the application must be
fixed, tested and then released back to production under change control.

Risk Management
Another important practice is to actively manage risk associated with the application. We
have found that this can be done most effectively by developing a model that accounts
for the likelihood and probability of loss related events. For example, quantitatively
modeling the risk of financial loss due to data breach, fines associated with non-
compliance or business loss due to application downtime can be helpful in terms of
allocating resources for prevention. But it is also useful in terms of helping management
understand why so much effort is being expended around application security. Once
again, this is an ongoing process that must stay current with emerging threats whether
internal, external or from partner organizations.

Page 9 | www.redspin.com 2009 | White Paper

 Business Impact
The most important result of following this process is an application that is up and
running and fulfilling its mission whether that is to make employees more productive or
to generate revenue through online transactions.

The extended team, including operations, security and business unit management should
have a high degree of confidence in the following areas:

• The corporate brand is protected

• Risk has been minimized
• The service will be available (or at least not down because of security issues)
• Employees will be productive
• Regulatory fines will be avoided
• Reputational damage will be avoided

About Redspin www.redspin.com

Redspin delivers the highest quality information security assessments through technical
expertise, business acumen and objectivity. Redspin customers include leading companies
in areas such as health care, financial services and hotels, casinos and resorts as well
as retailers and technology providers. Some of the largest communications providers
and commercial banks rely upon Redspin to provide an effective technical solution
tailored to their business context, allowing them to reduce risk, maintain compliance and
increase the value of their business unit and IT portfolios. Penetration Testing

Page 10 | www.redspin.com 2009 | White Paper