Business white paper

Seven steps to
software security
Business white paper | Seven steps to software security

After a decade of news detailing countless successful

cyber‑attacks, it’s hard to imagine a corporation not
understanding they need a software security solution. Unlike
implementing software quality assurance, the processes that
go into making applications more secure are still relatively
immature. As well, ownership for the security of software in
an organization is not always consistent or clear. This paper
Table of contents provides seven practical steps organizations can begin today
2 What you will learn to secure their applications and prevent the damages
2 Delivering more secure code: The seven steps cyber‑attacks can bring.
3 Step 1: Quick evaluation and plan
4 Step 2: Specify the risk and threats to the
software What you will learn
4 Step 3: Review the code
5 Step 4: Test and verify • Seven practical steps to begin an application security program
5 Step 5: Build a security gate • Methods of measuring application security program success
6 Step 6: Measure • Ways to implement a secure development life cycle
7 Step 7: Educate • Application security best practices and methodologies for success
8 Conclusions
8 About HP Fortify Delivering more secure code: The seven steps
8 About HP Enterprise Security
Understanding technical security risk begins with knowing how and where vulnerabilities occur
within an organization. Vulnerabilities can impact every level of enterprise infrastructure from
hardware to network to software (both old and new). These vulnerabilities are the gateway that
malicious actors use to circumvent security protections and steal or alter data, deny access, and
compromise critical business processes. Increasingly, the entry points for attackers are Web
applications. Long-standing vulnerabilities like cross-site scripting are still not being corrected
in development or deployment. Almost half of the Web applications tested during 2012 were
From 2000–2012, four of the top six susceptible to cross-site scripting, a threat that’s been around almost as long as the Web
vulnerabilities submitted to the Open itself.1 Simply put, application developers are not taking care of their data in how it’s stored,
Source Vulnerability Database (OSVDB) were gathered, or retrieved.
exploitable via the Web.2
How then to begin to address these problems? According to the National Institute of Standards
and Technology (NIST), after an application is released into production, it costs 30X more to fix
than during design.3 So, it makes sense to try to resolve these problems during development
where it makes the most economic impact. Organizations that have been successful in facing
these challenges have found some things work better than others. The key to getting started
is to select a few practical activities that can begin to instill security processes that produce
more secure applications. These activities can be as simple as a single “security gate” that
applications must pass through before release or a series of small tasks at each step in the
software development life cycle (SDLC) to build security into the application. However, even this
simple approach is easier said than done. The inertia against change can be so great that it is
easy to become paralyzed—which usually results in security not being addressed sufficiently
at any step from development to deployment. As a way to help, this document proposes seven
practical steps that development groups can take to deliver more secure software—with the
emphasis on “practical.”

1, 2
HP 2012 Cyber Security Risk Report, March 2013
3
“ The Economic Impacts of Inadequate
Infrastructure for Software Testing,” National
Institute of Standards & Technology

2
Business white paper | Seven steps to software security

Step 1: Quick evaluation and plan

The first step is to evaluate the current state of software security inside your organization and
create a plan for what additional steps need to be taken to address security. Think of this as
triage. This evaluation and plan need not be a comprehensive, multi-month effort. The best way
to start is by simply creating lists of activities currently undertaken to address security issues
and the actions that need to be added. For example, the table in figure 1 documents a project’s
overall software security preparedness, providing a scale to measure against. A plan—no
matter how brief or short-term—is critical for getting buy-in within the organizations.
Realistically, your first plan might need to be a “proof-of- concept” that allows you to build a
more thorough and aggressive plan after positive results have been obtained. It sounds simple
(and it is for a reason), but it’s amazing how many companies skip this essential step.

Figure 1. Evaluation

Internal security experts exist and have been identified 1 2 3 4 5

Threat analysis completed for every project 1 2 3 4 5

Education programs for security occur regularly 1 2 3 4 5

Specific tools and resources have been acquired and allocated 1 2 3 4 5

Post-deployment security is fully integrated with overall process 1 2 3 4 5

Vulnerability response maximizes benefits and prevents repeats 1 2 3 4 5

Regardless of your approach, the plan should address three elements: (1) the software security
infrastructure that surrounds each software development project; (2) specific security activities
each project team chooses to undertake; and (3) how you will manage vulnerabilities that are
found. The table in figure 2 provides example elements of a plan.

Figure 2. Elements of a plan

Assigned security Who: Assign individuals How issues will be

expert of team lead to tasks and roles tracked and reported

Automated tools that What: List steps and Team processes to

support steps success criteria for each triage, prioritize, and
take action on reported
security defects
Process checklists When: Include steps
and requirements and activities in project
timeline

3
Business white paper | Seven steps to software security

Step 2: Specify the risk and threats to the software

Security is in essence the art of risk mitigation. Software applications that store customers’
private information need to be better protected than an internal application for scheduling
conference rooms. So, similar to how you would list your group’s capabilities to build more
secure software, you should determine the risk associated with a piece of software and the
threats to its safety. Risk analysis is a field unto itself and can be found in commercial solutions
such as Microsoft ® STRIDE and standards-based approaches such as NIST ASSET. Although
varied in their implementation, approaches like these typically have many detailed steps and
involve a significant investment of time. A simpler technique than a full-blown risk analysis is
a threat analysis, which considers the threats posed to an application. Threat analysis helps
you avoid security mistakes in your design and focuses code reviews and security testing on
the most vulnerable components of the application. For that reason, you should consider this
step as one of the most important you can undertake. A simple threat analysis can be divided
into two phases. Phase one identifies the assets an application must protect and evaluates
which assets are most important. This task can be tricky as some assets are more apparent
than others and the nature of assets varies from application to application. Examples of assets
include records of private information, such as credit card numbers, employee or customer
records, or financial figures. Other examples include resources that an organization provides to
others, such as e-commerce solutions, corporate websites, and email support for customers.
Still others are intangible resources, such as your company’s reputation. For example, how
would a security breach affect the credibility of the company?

Phase two of threat analysis consists of understanding the application itself and the dangers
it faces from attackers. Organizations should develop a high-level model of the application’s
components and dataflow paths. The application’s attack surface should be mapped, identifying 
interfaces that accept input from users or interact with other systems. Teams should note any
points on the attack surface that allow an exploit to compromise the integrity, availability,
or confidentiality of an asset. Non-critical applications stored on the same server as critical
applications must also be considered, as breaches of the former can also impact the latter.
Finally, rank the threats based on importance of the asset affected and the likelihood of exploit.
This threat analysis exercise, while simpler than a full blown risk analysis, still may require a
high level of expertise about the application and how attackers work. However, it does not need
to be precise, and the return can be substantial in that it focuses efforts on the most important
areas without a lot of waste. Of course, not even the most thorough threat analysis can prevent
the introduction of security vulnerabilities during development, which leads us to step 3.

Step 3: Review the code

There is a simple fact in the software world—the code that gets deployed is the true
instantiation of any application. Consequently, organizations should review code throughout the
implementation and testing stages for security vulnerabilities that may be introduced during
development. In most every case, these reviews uncover numerous security vulnerabilities
that would otherwise be deployed. And, coupled with threat analysis, an organization can use
the review as a verification that the software does not leave open vulnerabilities to the threats
they most care about. Many groups today rely upon manual code reviews to perform this step.
Manual audits, however, require rich security expertise and tremendous investments in time.
Fortunately, there are consistent and well researched patterns of how developers introduce
security vulnerabilities into applications, providing a basis for accurate, automated security
analysis tools. The best source code analysis tools can evaluate multiple tiers and track the flow
of data within an application. They can work on bodies of code that range from small to large,
and effectively present and manage their own results so human auditors can quickly identify
and prioritize potential security flaws.

4
Business white paper | Seven steps to software security

Security source code analysis embedded in developer environments, such as Microsoft Visual
DevStudio and Eclipse, can also serve as basic and ongoing educational tools for developers.
These tools provide feedback at the point the error is introduced, allowing for a less costly fix
and a more concrete learning experience. Below is a list of key capabilities required for effective
automated security source code tools:

• Comprehensive identification of numerous vulnerability types

• Ability to perform varied analysis, such as global data flow, control flow, and configuration file
analysis, to reduce false positives
• Ability to analyze across application tier boundaries in order to find vulnerabilities that manual
reviews would never discover
• Multiple filtering, querying, and sorting options on analysis results
• Support for all languages used by your development teams
• Extensible to enforce your particular secure coding policies
• Support for analysis at the developer desktop via integrated development environment (IDE)
plug-ins

Step 4: Test and verify

Testing is a complementary technique to code reviews, a final exam for the secure software
development life cycle, and something that can also be aided by automation. The warning here
is that traditional functional testing is not effective at finding security vulnerabilities. Software
quality tests are traditionally focused on verifying a set of features as defined by some
reasonably well-specified requirements or expected user actions. Security testing requires a
different mindset and approach—for it is the absence of security that testers must find.

A common approach is to conduct application penetration testing. The purpose of the

penetration test is to simulate attacks against the software to discover anomalous behavior.
As with code reviews, these tests can be performed manually or with an automated tool.
Similar to source code analysis, human penetration testing is capable of uncovering complex
problems that cannot be found any other way. However, they require skills, expertise, and time
unavailable in most organizations. Automated tools can provide a knowledge base of known
attacks and rapidly fire those attacks at an application, but they often miss the subtle flaws or
input fields human hackers exploit. In addition, penetration testing coverage—the amount of
a running application actually exercised in a penetration test—is often very small with respect
to an application’s true attack surface. One solution is to use results from source code analysis
to feed into the penetration test so that (1) the testing takes into account all input sources
and ignores areas where vulnerabilities do not exist and (2) the remediation task is greatly
enhanced. There are also products that correlate the results of both code reviews and dynamic
automated analysis, which combines the strength of both approaches.

There is no easy answer to testing for security. The most practical approach, however, is
not to rely upon testing to find the vulnerabilities. Testing should primarily verify that the
vulnerabilities found in code review have been eliminated.

Step 5: Build a security gate

The most fundamental and arguably the best way to get the process started and achieve
tangible results is to construct a security “gate.” If an organization can only implement one
step, this is the one. Many organizations begin by requiring a single gate as the software leaves
testing and before it is released to operations or production.

This “final check” gate has the advantage that it is simple to understand and raises the visibility
of security issues before release. A downside is that a milestone so late in the development
cycle does not provide adequate time to adjust for security defects found in the code.

5
Business white paper | Seven steps to software security

Obviously, a key question is what criteria will be used to judge whether the software is fit to
pass through the security gate. A practical criterion would be an audit of the code. A code review
gate—whether it is required during active development, testing, or as a last check before
releasing the software to production—typically discovers significant numbers of security
vulnerabilities. As well, dynamically scanning the application in its running state, as an attacker
would, can also be an effective security gate. The important thing is to test the application for
security before it is deployed.

As the organization’s secure development processes mature, the criteria can expand to require
specific steps completed in detail and discovered issues remedied; that is, threat analysis was
performed, code reviews were conducted and issues uncovered were mitigated, security testing
was done, no other serious vulnerabilities were found, and minor vulnerabilities were corrected.
This more stringent gate may also contain a specialized security audit via independent security
experts before declaring the application “production ready.”

Step 6: Measure
Organizations should measure the success of their security activities so that the process can
be improved to meet changing requirements. Software security is still an emerging field—as
are the metrics that judge the effectiveness of activities within that field. However, there are
many activities that can and should be measured to provide insight into the state of software
security for an organization or project. Organizations can measure adherence to the security
process as it was designed, or measure the success of the security process as it is implemented.
For example, Microsoft measures the effectiveness of their SDLC by counting the number of
security bulletins within the first twelve months following a release (see figure 3). While the
Microsoft metric is a trailing metric, measures taken during development can provide sufficient
time to allow remediation of vulnerabilities before deployment. These metrics include tracking
measures such as vulnerabilities found per category, by severity, and over time. For example,
one project may introduce buffer overflow or SQL injection errors more frequently than another,
signaling a candidate for additional education. Audit coverage and history, vulnerability aging,
and even composite risk measures are possible. The key is to begin collecting data early on to
create a baseline during development.

Figure 3. Vulnerability severities for project Pluto

Critical High Medium Low

Critical = 3
Low = 3
3 3

Medium = 1 1

9
High = 9

6
Business white paper | Seven steps to software security

Figure 4. Vulnerability trends per project

Pluto Orion

100

75

Vulnerabilities

25

0
Dec 27 Dec 30 Jan 02 Jan 05 Jan 08

Step 7: Educate
After deciding what security measures will be implemented, the most crucial issue is to
educate the key stakeholders so they can effectively implement the security activities. Even
with training, developers are not likely to become security experts because they have other
pressing responsibilities and because of the complexity of becoming a security expert in
general. Typically, some group or selected individuals must be assigned to the role of security
“leads.” They may be individuals who already have an interest in security, individuals who are
specifically trained in security, or individuals explicitly hired to fill that role. These experts will
be responsible for implementing the security plan from beginning to end and are critical to its
success. The presence of security experts, however, does not relieve others of the responsibility
for security. Security must be the responsibility of every member of the organization, even
when starting small. Without full participation, no security plan is likely to succeed.

However, because individuals cannot be responsible for what they don’t understand, education
is key. To understand security requires knowing a lot of specific details. Developers must
understand how hackers think, what makes functions vulnerable, and how many bits a session
ID should be for a site that receives seven million hits a day, and on and on.

Organizations cannot make every member of each architecture, development, quality assurance,
and operations team a security expert, so how can security be improved? The security plan for
responding to vulnerabilities suggests developing internal best practices. These are excellent
security training resources for new and existing engineers. What better source of critical mistakes
to avoid than those that have already been made? Leveraging internally developed best practices
as educational tools provides targeted security knowledge with proven relevancy.

Consider sending key individuals in the development life cycle to training sessions or bringing a
security expert in-house to provide onsite training. Money and time invested in training are well
spent, especially within the context of the previous six steps. Ultimately, the solution is to make
security a mindset that pervades the development group. Everyone should be thinking about
what could go wrong each time they design a feature, produce a build, or write a line of code.
Each should ask, “how could an attacker take advantage of what I am doing?” If, at every step,
everyone is thinking about what could go wrong, security will improve.

7
Business white paper | Seven steps to software security

Conclusions
Software security is a serious problem. To mitigate the risks, software development
organizations must start thinking about security as a part of every step in the total software
development life cycle. Development teams can utilize a practical, seven-step plan to deliver
more secure software:
1. Evaluate the current state of software security and create a plan for dealing with it
throughout the development life cycle.
2. Specify the risks and threats to the software so they can be eliminated before they
are introduced.
3. Build a gate to prevent applications with vulnerabilities from going into production.
4. Review the code for security vulnerabilities introduced during development.
5. Test the application for vulnerabilities in addition to functional testing.
6. Measure the success of the security plan so that the process can be continually improved.
7. Educate stakeholders about security so they can implement the security plan.

Any development organization can implement this security plan and begin to receive a return on
their efforts within a minimal period of time. The key is to start now.

Visit HP Fortify at hp.com/go/fortify

About HP Fortify
HP Fortify is the market leading solution for automating and managing a comprehensive
software security program. With the most advanced technologies available on premise and
on demand, HP Fortify empowers organizations to find, fix, and fortify all their software
applications—from legacy systems to today’s mobile applications.

Visit HP Enterprise Security at hp.com/go/SIRM About HP Enterprise Security

HP is a leading provider of security and compliance solutions for modern enterprises that
want to mitigate risk in their hybrid environments and defend against advanced threats.
Based on market leading products from ArcSight, Fortify, and TippingPoint, the HP Security
Intelligence and Risk Management (SIRM) platform uniquely delivers the advanced correlation,
application protection, and network defense technology to protect today’s applications and
IT infrastructures from sophisticated cyber threats.

Learn more at
hp.com/go/fortify

Sign up for updates

hp.com/go/getupdated Rate this document

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only
warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein
should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
Microsoft is a U.S. registered trademark of Microsoft Corporation.
4AA4-6504ENW, September 2013, Rev. 1