255
Chapter 9
Applying the SDL
Framework to the
Real World
By Brook Schoenfi eld
In this chapter, we would like to introduce you to Brook Schoenfield. He is
a true thought leader and a well-respected software and enterprise security
architect. Because of Brook’s extensive experience as a software security archi-
tect, we have asked him to write this chapter. We believe this topic to be the
most difficult and critical part of the SDL and requires a seasoned software
security architect’s point of view to lend credibility to the solutions proposed.
Brook has been a co-worker and great friend of ours for several years and has
experienced the same challenges that we have in building, mentoring, manag-
ing, and providing technical leadership to both large and small software and
enterprise security programs. The following chapter is the result of many years
of experience by Brook of what works, what doesn’t work, and most impor-
tant, what should work to secure software during development. The model
presented in this chapter is also the result of many months of brain storm-
ing between James and Brook. As part of our introduction to Brook, we are
including an overview of his background below.
256 Core Software Security
Brook S. E. Schoenfield is McAfee’s Principal Architect, Product
Security. He provides technical leadership for all aspects of
product security across McAfee’s broad product portfolio.
Previously, he was Autodesk Inc.’s Enterprise Security Architect,
leading technical IT security strategy. As Cisco Systems’ Senior
Security Architect, he was the technical lead for SaaS product
security for the enterprise. Mr. Schoenfield has been a speaker at
conferences including RSA, Software Professionals, SANS What
Works Summits, and many others, presenting in his areas of
expertise: SaaS security, software security, information security
risk, Web security, service-oriented architectures, and identity
management. He has been published by SANS Institute, Cisco,
and IEEE.
9.0 Introduc tion
Software security depends on a series of properly executed tasks. There is
no “silver bullet” task whose execution will deliver “good enough” software
security. Security must be designed in from very early in the development
lifecycle. And each activity for finding defects is complementary to the
others. Leave out one of the activities and the others compensate only so
much for what’s been missed. The differences between software projects
dictates which tasks will deliver the most security return for investment;
some activities will be irrelevant for some systems. While the application
of some SDL security tasks depends on each project’s particular attri-
butes, there are other SDL tasks that lie at the heart of secure develop-
ment. These tasks are core to developing software that can be relied on
and that is also self-protective. This set of core activities applies to every
software project that must maintain a security posture, whatever that pos-
ture may be. These tasks are applied to every project.
Regardless of the development methodology employed, there will be
high-level system architecture tasks, software architecture considerations,
and software design issues. These constitute those tasks that must be done
before much production code has been written (though one may choose
to skip some of these when experimenting). After there is code to test,
there is the test plan to execute, which must include the functional tests
as well as testing from the attacker’s point of view. In between these pro-
cess markers, i.e., design time and testing, code will be written. Code
Applying the SDL Framework to the Real World 257
production is the heart of software development. In some methodologies,
there may be some design work that occurs just before writing, or even as
code is developed. Whatever the approach, there are table-stake tasks that
lie at the very heart of secure development: correctness for security, peer
review, and static analysis (if available).
None of these tasks, by itself, constitutes a silver bullet activity that
will deliver secure software. Each task complements the others. Creating a
secure and securable architecture, with flows that can be understood and
with controllable trust boundaries, enables the software’s features to be
written into an environment that supports security. A thoughtful security
architecture should require those features that will foster secure deploy-
ment and usage. Once the architecture supports the required security fea-
tures, these can be designed from the start rather than attempting to bolt
security on after the fact.
Since secure coding is still very much an art, with local language and
runtime variations adding to complexity, a strong, real-world SDL oper-
ates by “trust but verify.” Trust your developers to write secure code. But
check that code with multiple, independent, and complementary assur-
ance methods: peer review, static analysis, functional testing, and dynamic
analysis of the input paths.
In short, prepare for security, think about how to implement required
features, build these, then test the code to make sure that the security fea-
tures work as intended and that no vulnerabilities have been introduced
while coding.
We believe that, ultimately, software security is a problem that peo-
ple must solve; technology is merely an extension of the human mind.
Relationships, as we will see, are the key to a successful SDL. Obviously,
humans design, write, and test code. Humans must do each of these
things with security in mind in order for the finished product to have all
the attributes that comprise “secure software.” Since execution of each of
the SDL tasks requires intelligent, highly skilled, creative people, it is the
people who execute the SDL who are the most important ingredient. As
we explore each portion of the secure development lifecycle, we will take
note of the approaches that strengthen relationships and provide people
with motivation to produce secure software.
Figure 9.1 illustrates the flow of activities through the SDL:
Architect => Design => Code => Test
258 Core Software Security
Ultimately, the SDL flow in Figure 9.1 reduces to a simple SDL para-
digm: Architecture feeds design, which is then built, i.e., “coded.” The
coded design must be put through a series of validations, “test.” This
chapter details exactly which activities fit into each of the high-level
buckets illustrated by Figure 9.1, and how those activities are used within
either Waterfall or Agile development. As we examine the SDL from the
implementation view, we will ask key questions to determine precisely
which activities must be engaged to what type of software project. In
order to apply the secure development lifecycle activities appropriately,
it’s important to understand that not every activity is required for every
project. Applying every security task to every project, from entirely new
concepts (“greenfield”) and/or complete redesign to a minimal set of user
interface changes is wasteful and expensive. Requiring that every project
go through Web vulnerability scanning, even those that have no Web
server, is just plain silly. Not only will effort be expended with little secu-
rity reward, but development teams are likely to resist the SDL as mean-
ingless “administrivia,” ergo, work with no benefit, empty bureaucracy.
In the past, choosing the appropriate set of tasks out of the complete
SDL menu has been performed by skilled security professionals, often the
security architects or security engineers. As the security architect came to
Figure 9.1 The real-world software development lifecycle.
Applying the SDL Framework to the Real World 259
understand the system, she or he was able to prescribe the correct activi-
ties to deliver secure software. Knowing that there is a Web server that
will be deployed only within a segregated network and that will be used
only by a few trusted administrative staff, the architect might choose to
forego a detailed Web vulnerability scan in favor of network and applica-
tion access restrictions. The required security posture defense in depth
can be achieved through applying multiple controls, each complementing
the other. Like a painter with a palette of technical controls, the architect
builds the security posture out of his or her palette.
Some organizations don’t have much flexibility in the security controls
that can be deployed: They can only deploy a few; a complete “palette”
of solutions isn’t possible. Or the organization may not have the project
analysis skills that are required to appropriately assign SDL tasks to pro-
jects. Or there may be too few analysts to scale to a large or diverse soft-
ware development portfolio. In these and similar situations, one tendency
has been to employ a “one size fits all” approach. This approach applies
every SDL task to every project, regardless of project size, the amount of
intended software change, or change of the included components. In our
experience, this approach is fraught with pitfalls: resistance, misapplica-
tion, missed schedules, or teams simply ignoring security tasks altogether.
Integrating security into software projects is not a “one size fits all” pro-
blem. Not only will there be wasted, even useless effort, but the engineers
tasked with carrying out the tasks will lose faith in the SDL. This can
lead to apathy, even gaming the system to get around what appears to
developers to be a valueless bureaucracy.
Instead, we propose a straightforward approach that builds on years of
successful security analysis of hundreds of software projects at many diverse
organizations. This extensive experience has been distilled into a set of
key questions and the task flows that follow from the answers. Successful
application of the SDL activities can be accomplished by asking these few
important questions either at project initiation, or before each high-level
phase of development. Each defining question must be answered before
the SDL phase in which its associated tasks are to be completed.
This is not to suggest that executing these tasks is trivial. As has been
pointed out by Microsoft threat modelers, threat modeling can be per-
formed by anyone with an inquisitive mind. Still, in current practice, it
usually takes an experienced architect who understands the project’s archi-
tecture, the intended deployment model, the development languages, and
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.