What Executives Need to

Know About Web Application

Development Security

Secure SDLC enhances

the traditional Software
Development Life Cycle
to incorporate security as
a base requirement.

6450 Via Real, Suite3

Carpinteria, CA 93013

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

2 The Business Impact of Security

3 How the Current Development Process Creates Risk for

the Business

4 An Executive View of the Software Development Life Cycle

5 Secure SDLC – The Secure Software Development Life Cycle

6 Business Impact of Addressing Security Early

7 Four Steps to Immediately Improve the Security of

Your Applications

8 Conclusion

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

 Executive Summary
It is common knowledge that security is not one task at a given point in time but
an ongoing process, yet currently, the most common approach to securing a web
application involves doing a single security test, usually a Web Application Security
Assessment, when a development project is completed. While this is still a requirement
for secure software development, this paper discusses why security needs to be
incorporated earlier and throughout the Software Development Life Cycle (SDLC). We
also describe an improved model for developing more secure web applications – the
secure SDLC – and provide steps that you can take to immediately improve the security
of your existing web applications and development process. This applies to both new
application development and also existing applications that have been released to
production.

The Business Impact of Security

The days of “oops, we got hacked,”
The days of “oops, being an acceptable management
response after an intrusion are long
we got hacked,” gone. Customers, regulators, and the
news-reading public expect security
being an acceptable to be the default operating condition.
Security breaches have tremendous
management financial, brand and regulatory impact
and the “oops” response is no longer
response after a reasonable means of protecting a
CISO’s career. Security is expected.
an intrusion are
But security is hard. Even the most basic
long gone. web application can be quite complex,
so it is no surprise that making them
secure is no easy task. It is also not
surprising that creating a web application
that comes off the production line as
secure must have been developed with
security in mind since inception. After
all, you can’t expect a web application
coded with lackluster standards and
coding flaws to be secure upon release.
Secure applications do not just happen
randomly; they are part of a deliberate
commitment to a robust development
process with high security standards.
Secure application development requires
a long-term commitment to a structured
development process that embraces
security in all phases of development
from initial requirements development
by the marketing department to ongoing
operations and maintenance after
deployment.
The impact of a security breach continues
to rise in terms of hard costs, litigation
and lost brand value. The Heartland
Payment Systems, TJX/TJ Stores and
CardSystems, Inc. incidents are
examples of how high these costs can
be: hundreds of millions of dollars and
dozens of lawsuits for Heartland and TJX
respectively, while CardSystems is just a
shell of its old self as it lost essentially all
of its customers after its breach. As the
business impact of a breach increases,
executives are finding that maximizing
shareholder value means minimizing
security risk. This is a significant step
which takes a management commitment
to make security a requirement for all
web applications. A goal of this paper is
to help executives — those in leadership
roles, LoB GMs, CISOs and CIOs —
better understand the secure SDLC
so that secure development becomes
ingrained in the business culture.

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

 How the Current Development Process
Creates Risk for the Business
Here is a typical scenario in a web
development project: development is
complete and the application is ready
to be deployed or has already been
deployed (sometimes for years in the
case of legacy applications) and then
the project team decides to require a
security test before the application goes
into production to verify that it is secure.
Often, the decision is made based on
fear due to a recent security breach
reported in the news or by a competitor
or as a last minute requirement stipulated
by a big client. In these cases the
cost of a Web Application Security
Assessment has not been factored into
the development budget, which is one
indication that security was a last minute
task add-on rather than a core front-end
requirement. Furthermore, because not
only was security testing not budgeted,
it was not scheduled, introducing delays
into the release schedule.
This is not all bad of course, if security
was not considered early on in the
development process then doing a
Web Application Security Assessment,
if done properly and thoroughly, may
be the single biggest thing to minimize
the risk of a major security breach.
However, it is not without impact to the
organization. There are two significant
impacts that go beyond budget and
project management schedules that are
indicative of considering security late in
the development cycle.
1. Surprise
The first is surprise. Development teams
are often surprised with the extent of
the security issues identified as part of
a Web Application Security Assessment.
Because fixing security issues and
managing delays often involve other
groups, the surprise is felt throughout
the organization. The system architect
needs to evaluate the security flaws,
then the developers need to code up the
fix. Whether the development team is
outsourced or works in-house, they have
often moved on to other projects by the
Page 3 | www.redspin.com
time the bugs are uncovered. Because
business unit leaders and the marketing
department had no idea that security
specifically needed to be called out
as a requirement, they are surprised by
any additional cost and schedule delays
caused by these security fixes. Security
related schedule delays can be difficult
to explain to customers as well.
2. Risk
The second big impact is risk. Software
systems, even simple ones, can be quite
complex. While a Web Application
Security Assessment does a pretty good
job at assessing risk, it is not 100%
effective. There are potential flaws
in a web application that may not be
uncovered by an assessment. Some of
these flaws may be uncovered much
later as new testing methodologies
are developed — perhaps by testers,
or maybe by hackers. Furthermore,
no software can be perfect, therefore,
one aspect of secure application
design is to build in layers of security,
so if one aspect of the security model
fails, the impact would be minimized.
This type of security design minimizes
risk and reflects an understanding of
the complexity of software and the
ever-changing landscape of risk. It is
really unreasonable to expect that a
development process that is not built
around security, would result in a secure
application.
Many managers are responsible for
legacy web applications that were
inherited or acquired. In these cases a
Web Application Security Assessment
might be a requirement to quickly identify
security risk. In these situations, surprise is
a given, but with new development there
is no need to be surprised by security at
the end of the development life cycle.
In the following sections we’ll discuss
a new model for web development
that incorporates security up front and
minimizes both the surprise factor and the
risk with a predictable and repeatable
process to develop robust software that
adheres to security best practices.
2009 | White Paper
 An Executive View of the Software
Development Life Cycle
Secure SDLC enhances the traditional
software development life cycle
to incorporate security as a base
requirement. Security affects nearly all
parts of a software system, from the
operating systems and programming
languages used, to the data it transmits
and stores, to the customers/users and
their capabilities. So as you might expect,
incorporating security as a requirement
impacts all phases of development.
Before we discuss a secure SDLC, let’s
review the traditional SDLC.
Many models have been developed
to characterize and guide the software
development process and many
companies have modified these or
adopted their own to suit their specific
needs. While each company’s SDLC
may vary, they generally include the
following four phases. Our discussion of
secure SDLC will use this terminology.
Requirements
This is where the software is
conceptualized and specific features are
defined by a product team to address
a specific business need or customer
demand.
Design
In the design phase detailed specifications
for the software are developed along
with an overall application architecture.
Page 4 | www.redspin.com
Development
During this phase software developers
are focused on writing code to build the
application itself. This phase typically
begins with a heavy programming
emphasis, with an increased amount of
time spent on quality assurance testing
as the phase progresses.
Deployment
The final phase is ongoing. It begins with
a final test, including security testing,
and is then released. Once live, the web
application must be maintained along
with the network and server environment
in which it is hosted. Bugs are fixed,
features are added and the software is
generally maintained.
The many models of SDLC reflect the
evolution of thought on the subject (new
models are developed all the time) and
there is a need for organizations to
leverage a model that works for them.
For example, the model used by a
dedicated software company working on
a big project, might not be appropriate
for a small team project. Whatever
the model and naming conventions,
the basic progression of development
is pretty consistent. In the next section,
we’ll see how security is incorporated
into these phases.
2009 | White Paper
 Secure SDLC – The Secure Software
Development Life Cycle
Figure 1 incorporates initiatives associated with a secure SDLC into the four phases of a
traditional SDLC - requirements, design, development and deployment. These additions
are shown below each phase. While there are a variety of ways to integrate a secure
development process into an organization, and the differing structures, goals and
processes of each organization dictate a flexible approach, Figure 1 represents some
of the most basic elements that are likely part of most secure SDLCs.

To better understand the secure SDLC, we’ll provide a quick description of each of the
above tasks.

FOR ALL PHASES OF DEVELOPMENT

The fundamental requirement for any secure SDLC is education and management
commitment as these apply to all phases of the model.

Education
Security education applies to all development project stakeholders. For example, product
marketing needs to learn about the importance of security and the nature of security risk.
This will facilitate defining security requirements in the early phases of development
and also helps them understand the need to incorporate security testing into the project
timeline. Developers, for example, need technical education and training on secure
coding, while the Quality Assurance (QA) team needs to learn how to apply security
testing techniques. Then, farther down the line, the operational IT team would need to
be educated about securing the network and operating system environment.

Management Commitment
Security starts at the top. If executive management is not committed to cultivating a
culture of secure application development, then it is hard to imagine that the additional
investment of a secure SDLC would be considered a priority throughout the organization.
Integrating security into a development project moves the time allocation and some budget
items for security tasks earlier in the process. While this approach is widely accepted
as significantly reducing the security risk of a data breach that could impact business

Secure Software
Development Life
Cycle

Figure 1. Secure SDLC

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

 profitability and brand, it’s tempting to ignore security until later in the process as this
might speed up development and cut out some short term costs. Accepting incremental
development cost and time increases for the sake of long term risk management is a
strategic management decision.

REQUIREMENTS PHASE

Communication
Communication in the context of secure SDLC means ensuring that all development
project stakeholders are aware that security is strategic to the business. It is the statement
that adherence to fundamental security best practices, organizational security policies
and application level security requirements is central to the development effort. Early
articulation of the importance of these security principles is a starting point for ensuring
that the project does not lose sight of security.

Web Application Security Policy

A web application security policy serves as the documented version of the previous
communication step. It defines some of the high-level best practices, organization
security policies that specifically address web applications and security requirements
that are applicable to the entire portfolio of web applications in a given business. It is
a policy that ensures that multiple projects within a company are applying the secure
SDLC consistently. This codifies the secure SDLC and may include some of the basic
building blocks shown in Figure 1 as standards for development.

Use and Mis-Use Cases

Use case modeling in development is a way to characterize how users interact with a
system to use specific functionality of the software. Use cases provide a practical way
to describe common scenarios for how users will use certain functional requirements of
a system. Mis-use cases are similar except that they model how an attacker may use
the system in a way that is not intended by its designers to compromise the system.
Understanding mis-use cases helps determine the kinds of controls needed in the
application.

Security Requirements
In a pre-security oriented development process, the requirements phase captures the
features that need to be included in the application. This is an opportunity to define
what functionality the application will include. In secure SDLC, the requirements phase
is expanded to include any specific security considerations that need to be factored into
the development. This is the opportunity to specify any compliance- or data security-
driven security requirements, as well as any industry-specific best practices that are
relevant to web applications in general, or specific to an industry.

DESIGN PHASE

Secure Architecture
In secure SDLC, secure architecture refers to the design considerations that, when
incorporated as a fundamental building block of a system, minimize the inherent security
risk of an application. These include defense-in-depth, in which there are layers of
security controls implemented such that if one fails there is another layer as a backup.
Other examples are: least-privilege – users are only enabled with the minimum level of
functionality needed for their use; secure by default – the default settings of the system
are secure; minimize attack surface area – expose the minimum number of critical
functions that might be vulnerable to attack; fail secure – if the application should fail, it
does so in a way that does not expose the application to compromise; avoid security-
by-obscurity – there is nothing wrong with minimizing the public knowledge of your
systems, but this is not an appropriate security measure.

Design Review/Assessment
These refer to a similar process, where design review is completed internally and design
assessment is completed by an objective third-party. In either case the goal is the same,

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

 to have an objective review of the architecture, to ensure if the web application design
is consistent with the project security requirements and best-practice security architecture
principles.

Ship Criteria
Defining specific criteria that must be met before a project is deployed ensures that the
basic security objectives will not be forgotten as the web application project schedule
nears the end. For example, an application may only be allowed to be released if it is free
from vulnerabilities identified during the final Web Application Security Assessment.

Attack Surface Analysis

The surface area of a web application refers to the number of features and the extent
to which users can access them. More functional access by more users is more surface
area. More surface area represents more risk. One goal of application design should
be to minimize the attack surface area. Measuring the attack surface area can provide
an effective metric of risk and be used as a baseline as the system is developed to verify
that the attack surface area has not grown. Significant growth in attack surface area
may reflect coding errors or feature creep that significantly increases overall risk.

Threat Modeling
Threat modeling refers to a methodology used to identify risk in an application.
Understanding risk, including the vectors of attack, the probability of attack and the
potential impact is a cornerstone of secure application development. The ability to
prioritize risk enables the developers to focus their efforts on controls that matter most.
Microsoft has developed two methodologies to implement threat modeling. The first is
STRIDE which is a method for characterizing known threats. This acronym stands for:

S poofing Identity
Tampering With Data
R epudiation
I nformation Disclosure
D enial Of Service
E levation Of Privilege

Microsoft has developed a second methodology known by the acronym DREAD which
is used to create a risk rating that can be used to prioritize risk:

D amage Potential
R eproducibility
E xploitability
A ffected Users
D iscoverability

There are other frameworks for threat modeling; further review of these should provide
some guidelines on implementing this process for your next application.

DEVELOPMENT PHASE

Coding and Testing Standards

In secure SDLC traditional coding and testing standards are expanded to include security
considerations. Secure coding standards across an enterprise minimize the risk that a
developer will introduce a security vulnerability into the system – that may or may not be

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

 identified in the later Web Application Security Assessment phase of the project. Secure
testing standards ensure that the QA team incorporates mis-use cases and other specific
security scenarios into testing.

Static Analysis
Static analysis refers to automated code analysis tools that detect security vulnerabilities.
This is essentially a source code review that is automated and can be provided to
developers so they can periodically scan their code as they are developing features and
helps provide near real-time feedback on coding errors.

Source Code Review

A third-party review, either by a peer within the organization or another company, helps
ensure that coding standards are met and that their code does not include security
vulnerabilities. When source code review is included as a milestone in the development
plan, it reinforces to the team that secure coding practices are important and valued
highly throughout the business unit.

Unit Penetration Testing

This is a build level Web Application Security Assessment. In web development, the
application is typically incorporated into a web server or web application framework
such that at various phases in development the source code can be built so a running
application (with limited features) can be tested. Unit penetration testing focuses on
specific features or parts of the code base to capture potential security vulnerabilities
while the application is still in development. The idea is to provide feedback to the
developers while they are still in development and testing mode, rather than waiting until
later when they may have moved onto other projects.

DEPLOYMENT PHASE

Environment Hardening
This task includes all the steps needed to create a secure environment in which an
application is hosted. For example, robust source code does not reduce the overall
security risk much if one of the servers that it runs on is configured with a default password
that can be guessed by an attacker. Components of environmental hardening include
securing any servers that host the application and databases used in the production
environment, building a secure network environment surrounding the system and ensuring
that all the necessary physical controls are in place.

Application Penetration Testing

This involves conducting a Web Application Security Assessment against the final
application before it goes into production. This is the one step that is often included
even in non-secure-SDLC development shops. When implementing this phase in the
context of a secure development process the number of vulnerabilities identified is
reduced significantly (i.e. you find fewer surprises). In secure SDLC, this phase serves
more as a final security review milestone rather than a test that will likely have to be
completed multiple times to validate the remediation of a significant number of security
vulnerabilities.

Application Vulnerability Plan and Vendor Vulnerability Plan

A vulnerability plan refers to the documented process incorporated into secure SDLC
to address the inevitable scenario that a vulnerability will be identified in the system.
The plan should answer these types of questions: who will monitor the vulnerability
databases for new vulnerabilities? Who should they notify? How soon should the issue
be addressed? The application vulnerability plan refers to vulnerabilities identified
specifically with the custom code developed for a custom application, while the vendor
vulnerability plan addresses vulnerabilities found within the vendor applications, such as
the application server framework or the server operating systems.

Incident Response Plan

While it is commonly accepted that a secure development process improves the security
of applications and minimizes the overall risk of a security incident, it is also widely
agreed upon that web applications will never be completely free of risk. Having an

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

 incident response plan in place before any incident occurs will allow the stakeholders
to consider an action plan without the pressure and time constraints typical of incident
crisis management.

Security Requirements
This refers to the same requirements discussed in the first phase of development. During
this phase there must be an ongoing process to capture new security requirements as
they emerge. Whether customer driven or due to new regulation, these new requirements
must be communicated to the necessary stakeholders within a project.

Business Impact of Addressing Security Early

Figure 2 characterizes how development
cost and risk are impacted by moving
security earlier vs. later in the development
process.
Addressing Security Early
Security integrated early yields a more
robust application that is generally
considered to minimize risk. Also note
that, while there is a cost associated
with these security tasks, these can be
planned into the process and budgeted
for – they are integrated and expected.
Addressing Security Late
Because security flaws coded into
an application early in the process,
generally result in a less secure
application, it is pretty intuitive that
delaying security considerations until
late in the process constitutes higher risk.
What is less evident, is that this also
results in unanticipated costs. At best,
these costs are due to additional coding
and QA cycles that result from having the
Web Application Security Assessment
produce findings that must be fixed
before release. At worst, the extremely
high cost of a security breach.

Business Impact
of Addressing
Security Early

Figure 2.

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

 Secure SDLC Self Assessment -
“How secure is my current
development process?”
One question many of our clients have is
- How secure is our current development
process? One service Redspin provides
is a secure SDLC Process Assessment in
which we review the current development
process and provide a gap analysis and
recommendations to get our clients on
track toward a more secure process.
While this provides rapid and thorough
guidance along with a set of priorities so
organizations can focus on the tasks that
would provide the best return on effort,
there are a number of resources from
Microsoft and OWASP that can help
anyone do a self assessment of their own
development environment.
The table below provides some
questions that will help you determine
the maturity level of integrating security
into your development process. These
questions will help IT decision makers
determine components of the application
development process that must be
bolstered.

Secure SDLC Self Assessment Questions

Has security specifically been communicated by management as an important
consideration in development?
Do you categorize your applications based on risk?
Are compliance requirements defined and stated as a requirement during early
phases of a project?
Do you have documented coding standards?
Is code reviewed to ensure consistency with coding standards?
Does the QA team specifically test for security vulnerabilities during testing?
Are likely security threats to an application discussed and documented?
Are mis-use cases discussed and documented?
Is there awareness among team members from marketing, development and operations
about security principles?
Are projects required to perform a Web Application Security Assessment before release?
Are Web Application Security Assessments performed during early testing of a project?
Is there a documented web server hardening process used before servers are deployed?
Is there a consistent patch management process in place for the web hosting environment?
Are web hosting environments required to be subject to a network penetration test before an
application goes into production?
Is a structured change control and source control process used to manage code and updates?

Table 1.

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

 Four Steps to Immediately Improve the
Security of Your Applications
Of course many organizations either don’t have an existing secure SDLC or they have
a portfolio of legacy applications inherited from other business units or acquisitions,
or they pre-date secure SDLC. In any event, these applications can be migrated to a
secure SDLC. However, because those applications may embody significant risk to
the business in that at any time they could be compromised, a focused approach to
minimizing risk is essential. The following five steps should be considered immediately
for legacy applications.

1. Education, Communication & Management Commitment

Management commitment is more than a step of course; it’s a culture; it’s a commitment
to understanding the modern threat landscape such that security is prioritized. With
management commitment comes education; most security best practices, including the
steps involved in secure SDLC are fairly intuitive once the nature of security risk is
understood. It’s a bit of a what came first the chicken or the egg question when it
comes to management commitment and education as each one tends to follow the
other, however, both of these are critical components to build into an organization.
With these two components in place communication throughout an organization is a
natural progression – if management states that it understands and respects the need for
security, it can become a priority. And with communication comes the need for further
education specific to the parties involved – for example, where product managers may
need high-level security training, developers may need specific secure coding classes.

2. Web Application Security Assessment

This assessment is a specific task in secure SDLC. It involves an objective third-party
penetration test of the application to identify security vulnerabilities. While doing this
step when no other secure SDLC components are in place may yield a significant
number of findings that need to be addressed, the process often uncovers show-stopping
critical vulnerabilities that need to be addressed immediately. If nothing else has been
done to address security, this is something that should be considered.

3. Web Application Risk Assessment

Doing a risk assessment of your web application involves a scaled back version of
a number of steps of the secure SDLC as a single combined deliverable. The goal
of the risk assessment is to quickly gauge the nature and severity of the security risk
of an application. Out of this process yields the obvious next steps that should be
addressed to secure the application. Because each application is different, the security
considerations for each application vary significantly. For example, a publicly-facing
application which stores millions of healthcare records would have different security
requirements than an intranet used for team training. A web application risk assessment
involves threat modeling, attack surface analysis, application complexity quantification,
security architecture review and environment analysis. The goal is to quickly identify risk
and can typically be completed in one to five days.

4. Web Application Portfolio Analysis

A web application portfolio analysis is a cross-enterprise risk assessment. The goal is to
quickly identify web applications that are at-risk of a high impact security incident such
that they can be prioritized for additional security review. This is a great first step for
those organizations with a variety of legacy web applications.

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

 Conclusion
While no application can be completely secure, the consensus among the security
and development community is that those applications developed with a process that
integrates security early on and throughout the development process significantly reduces
security risk (while limiting surprises). Armed with an understanding of the secure SDLC
and its basic components IT decision makers should be able to communicate both the
need for security and the benefits of secure SDLC.

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 healthcare, 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 12 | www.redspin.com 2009 | White Paper