Secure software development often goes unassured, if only because
companies don't know how to go about it. Ed Adams, CEO of Security
Innovation, shows that it can be handled in five steps that can be
performed as tasks by a development team.
A
sound, secure software development life cycle has five key steps:
prioritizing applications, constructing guidelines, defining standards,
training a team, and identifying tools and metrics. However, it all
starts with risk prioritization-an often forgotten, but most critical
step.
Most organizations have a formal risk management process in place.
Many have already ranked their applications based on answers to
questions such as: "How critical is the application?", "Does the
application touch certain sensitive data?" and "Is there a Web-facing
component?"
However, organizations tend to struggle with the ability to quantify
the
security risk of these applications, as well as the documents'
adherence to certain regulatory compliance initiatives for their
software development processes. The objective of a secure SDLC
(Software Development Lifecycle) program is to map risk management
practices to the various phases of a software development life cycle.
This yields three substantial benefits:
First, it ensures that you are covered for your compliance
requirements with respect to application development. Second, it
provides a mechanism for measuring application security within the same
risk management framework you're already using. And third, it allows
you to create more secure applications, which will reduce the risk
exposure of your business and minimize the "VaR" (Value at Risk) that
is managed by your applications.
Step 1: Prioritize Applications
Starting with a pilot application provides a baseline from which to
grow. Many organizations will change the risk ranking of an application
after it has gone through a security assessment. There are two reasons
why this is done: either because they have become aware of
vulnerabilities in an application or, just as often, they remain aware
of vulnerabilities that are already protected against (via a
compensating control that had already been put in place).
Conducting an analysis of existing software development processes
allows you to construct a gap analysis, as well as identify specific
activities in the SDLC that need to be improved with respect to
security. It also helps determine if the application development team,
whether they are in-house or outsourced, understand the requirements
and policies to which they are being asked to adhere.
The second component of this stage is to measure the security
quality of a pilot application via a code review and/or penetration
testing, which provides a baseline from which to measure improvement.
Step 2: Construct Guidelines
The next step is to construct high-level security guidance for team
members. This is driven by the gap analysis performed in Step 1 and is
mapped to your specific security policies. Many organizations already
have these high-level guidelines in place, as they may have been
adapted from an industry "standard" such as
ISO 17799 or OWASP. The challenge with adapted standards is that they provide no context for
your organization, and are either very vague (
ISO) or limited (OWASP).
The best approach is to adopt and roll out security guidelines that
are specific to your organization and software development process. You
need to include "gates" so it is clear when (and why) a project is
allowed to be passed on to the next team member and phase of the SDLC.
It is irrelevant whether your applications are built internally or
outsourced. Once you have guidelines defined for each team member and
role (such as architect or developer), you can "outsource" the
development phase quite easily. It doesn't matter if the development
team exists physically or logistically, as long as they are held to the
defined security and design requirements.
Step 3: Define Corporate Standards
The next step is to detail those guidelines and tie them into your
information security policies, data classification standards and any
regulatory initiatives to which you must comply (such as PCI,
Sarbanes-Oxley Act or Health Insurance Portability and Accountability
Act). The purpose of this step is to create corporate standards for
secure application development. Many requirements, such as PCI, require
that you adopt and document "industry best practices for secure
application development." That is precisely what this step is intended
to achieve.
As with all good security standards and policies, you need to create
easily understandable and implementable procedures for those policies.
This includes policy "translation"-the ability to bridge the gap
between business risk policies and how they are interpreted and
implemented by the software development team or teams.
Step 4: Train Your Teams
Once you have built your policies, constructed your corporate secure
coding standards and provided procedures for implementation, you need
to give your people the training they need to implement correctly.
Training should not be limited to technical training for your
development team. Managers, business analysts and internal auditors or
security assessors also need to be trained. A good curriculum will
include 100-level "awareness" training, as well as 200- and 300-level
courses for roles such as manager, business analyst, architect or
developer.
Step 5: Identify Tools and Metrics
The identification of appropriate tools your team will use should go
hand-in-hand with the training. It is important that you select the
right tools for defining, developing and testing your applications. It
is also crucial that you choose tools for security guidance and
integration into your existing workflows and risk management
procedures.
No program can be successful without the ability to measure its
progress. Therefore, the definition of metrics is critical. Context is
extremely important. You need to select metrics that are meaningful to
you and your organization. A common metric is "Security Requirements
Coverage"-how many of your active projects are meeting 75 percent or
more of the defined security requirements. However, there are many
other metrics suitable for your organization's objectives. Be sure to
spend some time determining what they should be.
Ed Adams,
CEO of Security Innovation, is a
seasoned software executive with successful business experience in
various-sized organizations that serve the IT security and quality
assurance industries. He leverages his technical and business skills,
as well as his pervasive industry experience, to direct world-renowned
application security experts and to deliver world-class professional
services to many of the most recognizable companies in the world (such
as Microsoft,
IBM, Visa,
ING, Symantec,
SAP and Hewlett-Packard).
Prior to Security Innovation, Mr. Adams held senior management
positions at Ipswitch; VeriTest, a division of Lionbridge Technologies;
Rational Software (now
IBM), Logistic Solutions; MathSoft; Foster-Miller; and two
U.S. Army Research Labs. He earned his MBA degree with honors from
Boston
College, and has B.A. degrees in Mechanical Engineering and English Literature from the
University of
Massachusetts. Ed Adams can be reached at eadams@securityinnovation.com.
Email
Print
