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 Brooks 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 architects 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 projects 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 attackers point of view. In between these pro-
cess markers, i.e., design time and testing, code will be written. Code

Get Core Software Security now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.