SDL and Incident Response ◾ 199
Security Development Lifecycle Drivers and Benefi ts
Secure software is a major tactical component of a good security strategy. e application layer
is where the majority of attacks are taking place and the majority of damage is being done. We
must have a strategy for curbing this activity or bear the liabilities failure imposes upon us. e
business world has experienced more than enough damage from security failures and now fi nds
itself struggling to keep the compliance requirements that grew out of those failures from put-
ting them out of business. Compliance is probably the biggest driver for application security from
two perspectives: fi rst, having the ability to prove compliance and second, stemming the tide of
increased regulatory oversight. e more we fail, the more the powers that be will try to force us
to do better. SDL standards are built around industry best practices as well as legal and regulatory
requirements. Applications built with SDL are designed to be compliant from the start. Avoiding
compliance liabilities is only one of the economic advantages, however.
Applications built with SDL not only have fewer security fl aws, but they are better quality
products in general because the mandatory reviews and testing requirements of SDL also catch
other fl aws. Better quality and fewer security fl aws means less
downtime, fewer incidents, and lower costs. It also allows security
personnel to focus on planning and supporting business initiatives.
e standards that SDL introduces to support the security man-
agement process further reduce costs by eliminating complexities,
duplication of eff ort, and manual processes. Commonality is an
important aspect of incident response because it promotes the effi -
cient fl ow of information from security controls to responders,
making it possible for them to quickly repel malicious activity. Quick response has its economic
advantages; the faster the response, the less the damage; the less the damage, the less recovery time
and resources required. Consider this fact: An automated attack can compromise something on
the order of 20 systems every minute, and the proliferation rate increases with every infected sys-
tem. Waiting to respond is not an option.
Secure applications and well-designed security controls are business enablers. Poor applica-
tion security practices are quite the opposite. A company Bill worked with had a homegrown help
Gartner estimates that if 50 percent of
software vulnerabilities were removed
prior to production…enterprise con-
fi guration management and incident
response costs would be reduced by
75 percent each.
The Gartner Group
Objectives
requirements
scope release
strategy
acceptance
criteria
Functional
specifications
Envision Plan and design Build Stabilize Deploy Support Retire
Design
specifications
Test and verify functionality
Build out of
solution design
Resolve solution
discrepancies
Acceptance
signoff
pilot
deployment
production
deployment
Operate and
support
Migrate and/or
shutdown
service
Secure delivery lifecycle tasks and processes
Services delivery lifecycle tasks and processes
Pen
testing
Arch
and attack
surface review
Secure design and development training
Security
resource
assigned at
kickoff
Security
design
review
Implement and
verify security
according to
guides and best
practices
Create
security
operations
guidance
Security
tools
Security
team
final security
review
(FSR)
Monitor
security
operations and
compliance
Secure
disposition of
data
reat
modeling
Figure 11.4 Secure delivery lifecycle processes and tasks.
TAF-K11348-10-0301-C011.indd 199TAF-K11348-10-0301-C011.indd 199 8/18/10 3:11:02 PM8/18/10 3:11:02 PM
200 ◾ Security Strategy: From Requirements to Reality
desk application it used extensively to service internal users, external partners, contractors, and
vendors. One partner was heavily integrated with the company and wanted to be able to enter ser-
vice tickets directly into the system. It was a perfectly reasonable request from a customer services
standpoint: eir users would only need to call a single help desk, and the service ticket would be
routed to the appropriate responder. Unfortunately, the service desk applications had such a poor
security design that accommodating the request required major software reengineering. Foolishly,
the company decided to “patch” a few functions so that the software could be accessed remotely.
e results were disastrous; partner queries to the system often returned records from other cus-
tomers, resulting in a stream of security incident investigations that unnecessarily wasted valuable
security resources. A clear application security strategy and sound development tactics anticipate
the future and build applications equipped to handle new uses and security requirements. Secure
applications are an asset to the business, whereas insecure apps are a liability.
Transparency is another strong driver. Organizations want secure applications, but they expect
the security features to be transparent. In addition to timely responses to malicious activity, SDL
objectives must include timely performance (usability). Some of the major complaints against the
Vista operating system were related to usability. Vista had great security controls but slow perfor-
mance and unfriendly (intrusive) processes. Microsoft lost sight of this customer expectation, and
they paid for it with one of their lowest ever adoption rates.
Compliance remains the primary driver for security controls in general. Application security
is one tactic that has signifi cant promise for improving organizational compliance eff orts. e
improvements SDL brings to application security and quality in general greatly reduce main-
tenance and support cost, as well as potential loss liabilities. e improvements SDL standards
drive into common supporting processes improve not only incident response capabilities but also
operations, support, and customer service in general. e improvements it can bring to incident
response are a win–win for organizations that leverage this tactic. In the next section we will look
at some of the barriers to adoption.
SIDEBAR: THE SECURITY DEVELOPMENT LIFECYCLE SUCCESS STORY
Microsoft began applying the SDL process to all major products in 2004, and the results have been very impressive.
No one at Microsoft is willing to claim SDL is the security “silver bullet,” but the Return on Investment (ROI) has been
huge. The simplest measure of success is product vulnerabilities. There was a 45% decline in reported vulnerabili-
ties in Vista over Windows XP for the same reporting period (the fi rst year after the release of the product); Internet
Explorer 7 had a 65% decline; and SQL Server 2005 had a 90% decline. These products also had the lowest vulner-
ability counts of all competing products in the marketplace. SDL obviously works and works well.
Microsoft takes a lot of criticism for some of the things it does, but SDL is one for which they deserve a lot of
praise. Not only did they develop a great process for improving software security, but they gave it away to the indus-
try for free so that everyone else could do the same.
Security Development Lifecycle Challenges
Although the benefi ts of SDL are undeniable, there are some chal-
lenges, one of which is the rate of change in the IT world; new
requirements are constantly surfacing from legal and regulatory
changes, and new storage, processing, and connectivity technology
are completely changing the face of IT infrastructure. Cloistered
in-house enclaves have morphed into interconnected online and
outsourced services, manned data centers have become power
and pipe hubs for plugging in computer and storage containers
Why try to [hack] Vista when you have
[easier, non-Microsoft targets like]
Acrobat Reader installed, some antivirus
software with shoddy fi le parsing, and
the latest iTunes?
Halvar Flake
Security Researcher,
BlueHat Conference Speech
TAF-K11348-10-0301-C011.indd 200TAF-K11348-10-0301-C011.indd 200 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
SDL and Incident Response ◾ 201
(modules), and locally loaded client applications are quickly becoming browser-based Web apps.
Suddenly the skimpy pieces of information dropped in the audit trail are insuffi cient to meet evi-
dentiary requirements, and the disparate sources and formats of audit trails are hampering com-
pliance eff orts. Gone are the perimeter, network, and host security defenses applications relied on
to reduce security threats; now the user comes directly to the application. Gone are the physical
barriers that kept data isolated and safe; now thousands of users share the same processor and
storage facilities in the cloud infrastructure. All of these factors impact SDL, which for most
organizations (if they are using it at all) is a fairly new practice. Adapting SDL to these diff erent
environments is a stretch, to say the least. SDL was designed for large packaged products. It isn’t
well suited to Web applications that are constantly being updated and changed. Logging and
audit standards haven’t caught up with statutory and regulatory reporting requirements, and
application intrusion detection is practically nonexistent. Not only is it a problem with lagging
or missing standards, but it is also a problem with coverage. e process for packed application
development begins with product envisioning and ends with product release. In the online world,
product release is when the real work begins. Once the service goes online, it is a continual process
of fi xes, updates, and enhancements; you don’t get to walk away and start on the next version.
is is a major shift in the development paradigm, a shift many developers are not fi nding easy
to make.
Getting application developers to change their mind-set and incorporate mandatory function-
ality (performance, management, security, etc.) into their design and coding practices is not easily
accomplished. Microsoft’s trustworthy computing initiative kicked off in 2000 with a security
stand-down that many both inside and outside the company considered a joke and a complete
waste of time. It took years of training, reinforcement, process refi nements, and tooling to fi nally
get everyone on board, and 10 years after the fact, Microsoft is still struggling to make SDL
work well in its services business. SDL was designed to be used in the development of large pack-
aged software products with long development time frames. Many environments have very short
development and testing time frames where existing SDL processes do not work well. To address
that issue internally Microsoft developed a version of SDL for agile development methodologies.
After refi ning it for a while in-house, Microsoft made it available to the public in the fall of 2009.
Change takes time: Change impacts development schedules, and it takes time for people and
organizations to assimilate the new elements that change brings. Unfortunately, time is not always
a luxury organizations have.
SIDEBAR: STRANGER IN A FOREIGN LAND
I (Bill) used to do security code reviews and, believe me, developers do not like to be told their babies are ugly.
People tend to think development is a technical skill. To some extent it is, but mostly it is an art. As a reviewer,
I was constantly amazed at the creative ways that developers came up with to solve very complex problems. You
can teach an artist technique, but when you start telling her you want structure and order to what she is doing, you
are going to get resistance. Anyone who thinks Bill Gates stood up one day and said, “Okay from now on we’re
doing to develop trustworthy code,” and everyone said, “Yeah and amen,” you are kidding yourself. It takes time to
become skillful and productive at something, whether it is painting or programming; the more skillful you become,
the less interested you are in change, unless there is a compelling reason. Technology drives change, but unlike
painting, technology consumes the old when it produces the new. There have been thousands of improvements to
paint, but I can still buy a canvas; technology consumes the canvas and forces you to use a graphics pad. You can
spend 10 years learning how to be profi cient in a computer programming language, only to fi nd that it’s no longer
available and no longer supported. Consider this: In my 25 plus years working with computers, I have developed
reasonable profi ciency in eight different programming languages, four of which are obsolete. I still have code in my
development library that I couldn’t compile and run on any current technology if my life depended on it. The point
I’m making is that technology introduces more than enough change into the environment for developers to deal with.
For example, multiple 64-bit processors are now the standard for PCs; learning to leverage the capabilities of this
TAF-K11348-10-0301-C011.indd 201TAF-K11348-10-0301-C011.indd 201 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
202 ◾ Security Strategy: From Requirements to Reality
type of CPU architecture takes new skills that single-processor 32-bit programmers have to acquire. Adding more
stuff (that also changes constantly) such as mandatory performance, reliability, management, and security functions
only makes their jobs more diffi cult.
Have you ever tried to learn a foreign language? Imagine what it was like for the Visual Basic and Java developers
at Dell Computers when the company decided to standardize on C# and dotNet for all future development. Gone
are all the tools, shortcuts, code samples, and everything else they had that helped make them great developers.
Suddenly, 300 profi cient productive developers are relegated to newbie status while they try to assimilate and use
a whole new language, new techniques, new libraries, and so on. Time to forget what made you a great developer;
you are now a stranger in a foreign land—welcome.
Assimilation is not just a question of training and practice; it is also a matter of tooling. If you
want specifi c functionality within an application, there needs to be a library of methods to imple-
ment that functionality. Sometimes an existing library can be modifi ed to suit the need; other
times, a new library needs to be created. Developers are not going to build this functionality into
everything they create; they want to use a tool with this functionality. e lack of tools becomes
a challenge to adoption.
Cost can be another challenge. Microsoft experienced about a 15% impact to their develop-
ment process when they implemented SDL, 15% in cost and 15% in time. Depending on the
size of your project, that can be a pretty substantial hit. According to “Microsoft SDL: Return
on Investment” (Microsoft Corp., iSEC Partners, Inc., September 15, 2009), the approximate
start-up and run costs for the fi rst year of SDL would be $350,000 for a small development team
(50 people). For small and medium-size companies, that’s a pretty challenging number, and for
larger organizations looking to cut expenses, it could be a hard sell as well.
Cost and competency can also be major factors for incident response. Creating an eff ective
response capability that extends to the application and data management levels is going to require
some major retooling. Small and medium companies may not have the in-house expertise to do
this and hiring an external resource may be cost prohibitive. Even larger organizations may bristle
at the costs, despite the potentially good ROI.
e major barriers to SDL adoption are the start-up costs and the ability to assimilate new
processes and requirements into existing development eff orts. e lack of tooling can be another
challenge. Making the process work requires good tooling, and making the new functionality
work requires the software tools (libraries) implementing those functions. e impact and exper-
tise required to make SDL work may not make it a good fi t for every organization. Implementing
good tactical security practices at the application development and response level can be a chal-
lenge, especially for small and medium-size companies, but the return of investment makes it
worth the eff ort in the long run.
SDL Success Factors and Lessons Learned
Security Development Lifecycle has been a hot topic in the industry for a number of years. It has
its critics, but for the most part it has been praised for its eff ectiveness and positive impact on the
industry. e organizations that have been successful with the implementation of SDL have a
number of success factors in common. e fi rst factor, not surprisingly, is the need for executive
sponsorship. Security Development Lifecycle will not be successful if it is not mandatory, and
development teams are not required to attend mandatory training. e only way this is going
to happen is to have an executive leadership directive. Development standards are the second
factor; there must be a well-defi ned set of development standards and metrics for all phases of
the development process. e development of standards should be a cooperative eff ort between
development leads and security, and standards should be based on industry best practices and
TAF-K11348-10-0301-C011.indd 202TAF-K11348-10-0301-C011.indd 202 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
SDL and Incident Response ◾ 203
the legal and regulatory requirements applicable to the organization. Program continuity was
another major success factor; assigning the same security resource (“buddy”) to work with the
development team throughout the development process improves communications and produces
better results.
e most consistent lesson learned was the need to get “everyone’s head in the game.”
Mandatory training isn’t going to do the job; you are changing a culture and that takes con-
sistent reinforcement. Weyerhaeuser tied security incidents to people’s bonuses—how’s that
for incentive! Making the process cyclic is another important lesson: Learn from your failures
and mistakes. e fi nal lesson is never compromise good security practices, be security by
default, always fail to the most secure condition, enforce least privilege, and practice defense
in depth.
Michael Howard’s blog also contains this advice:
Model your threats before you start coding. ◾
Keep on top of the security news. ◾
Use DCOM/RPC security. ◾
Make your samples secure too. ◾
We have undertaken a rigorous “engineering excellence” initiative so that our engi-
neers understand and use best practices in software design, development, testing and
release. We’re doing this because software vulnerabilities are not just a Microsoft issue;
they’re an industry-wide issue.
Michael Howard
Application Control Objectives
e control objectives at the application layer are observation based. ere is a need to improve
the ability of applications to recognize malicious activity and to take action to capture activity
information, notify operations, and/or take mitigation actions. Let’s begin with the observation/
recognition attribute.
Observation/Recognition
ere is a general security principle that states: e closer a control is to the target of the attack,
the more eff ective it is at preventing, detecting, and/or responding to that attack. If you think
of this principle in terms of layered security, perimeter controls (e.g., fi rewalls) would be the
least eff ective, network-based control a little more eff ective, host based more eff ective, applica-
tion based even better, and data controls the best. Unfortunately, controls in the last two layers
are oriented mostly toward protection, not detection. In terms of eff ectiveness, this is actually a
backward approach. What is more eff ective at keeping someone from breaking through a door,
a good quality door or an armed guard? e guard is more eff ective because he or she can detect
the attack and move to prevent it before the door can be damaged. e current SDL approach
is to build a really high-quality door and let people beat on it until someone fi nds a way to bash
it open! Don’t take this in the wrong way: We are not saying we shouldn’t build quality doors,
just that our primary focus should be on detecting malicious behavior because it is the more
eff ective control.
TAF-K11348-10-0301-C011.indd 203TAF-K11348-10-0301-C011.indd 203 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.