October 2008

SDL SERIES, ARTICLE #1

SDL Series - Article #1: Investigating the Security Development Lifecycle at Microsoft
In 2006, Michael Howard and Steve Lipner published The Security Development Lifecycle, opening the door to Microsoft's internal methodology for producing more secure software. In this column series, we will walk through the phases of the Microsoft Security Development Lifecycle (SDL) and examine how the SDL is currently put into practice on a daily basis in the development of Microsoft's products. The goal of our effort, through interviews and research, will be to further pull back the covers on Microsoft's practices for creating software upon which millions of users (and billions of dollars) depend.

Content
Security Features vs. Security Products The SDL, In a Nutshell Proven Effective Methodology Our Methodology About the Authors

Other Papers in the Series

Article #2: Security Education at Microsoft Article #3: The Microsoft Security Org Chart Article #4: Threat Modeling at Microsoft Article #5: Microsoft Security Toolbox Article #6: Microsofts Security Response Article #7: Evolution of the Microsoft SDL Article #8: Microsoft SDL Investigation: The Wrap Up

Security Features vs. Security Products

To lay the groundwork for our investigation, it's important to get a few definitions out of the way. When people speak of security, they may talk of features such as Kerberos authentication, or BitLocker hard drive encryption. To be clear, these are valuable security features, but they are not the focus of our investigation. Instead, we are focusing on the secure nature of the product itself. As an analogy, imagine a server which requires your computer to prove its identity by sending a verifiable certificate. The server has implemented an authentication security feature; however, if the server software contains a bug, the security feature may be circumvented. Our focus is on the unintended vulnerabilities which negate or diminish the effectiveness of a product's security features. We're interested in how Microsoft works to ensure that its products contain as few security bugs and security design flaws as possible.

2
The SDL, in a Nutshell
While any security expert is quick to point out that no process is perfect and no product is free of vulnerabilities, the SDL is designed to obtain two specific goals. First, the SDL should reduce the number of security vulnerabilities in a product. Second, and very importantly, the SDL should reduce the severity of vulnerabilities which remain. If you've heard Microsoft people speak about the security of their products, they use terms like "attack surface area", "secure by default", and "defense in depth." As part of our investigation, we'll dig into the terminology, showing what it means, and where it fits under the umbrella of the SDL.

Proven Effective Methodology

In "The Security Development Lifecycle," Howard and Lipner made a series of bold statements. On the first page of the introduction, the authors state, "We can categorically state that the SDL does lead to more secure software." They go on to claim that, at the time of writing, Microsoft customers "have benefited from a vulnerability reduction of more than 50% because of the SDL." Finally, the authors throw down the gauntlet and say, "If you are not implementing a process similar to the SDL, the processes you have now do not create more secure products." Do methodologies matter? In our investigation for the How Software Is Built blog, we have delved into the development methodology differences between primarily closed source companies like Microsoft, and numerous open-source projects, like Linux distributions. We can state without reservation that projects which form the core of Linux distros do not use a process similar to the SDL, and differences in development methodologies is something well examine as we perform our investigation.

We can categorically state that the SDL does lead to more secure software Howard and Lipner in their book The Security Development Lifecycle

Our Methodology
In doing this investigation, we will use the book, The Security Development Lifecycle, as our guide, and focus in on the following aspects: Education and Awareness Security Team Organization Threat Modeling Automated Tools Security Response The Evolution of the SDL These chapters align with a typical software development lifecycle, as shown in Figure 1, and our investigation will walk through this lifecycle from start to finish:

Figure 1: SDL Techniques as part of the Software Development Lifecycle

For each topic, we plan to interview people on the Microsoft product teams, and find out, in their own words, how the phases of the SDL come alive on a daily basis. Our efforts will depend on the access that Microsoft provides, and the frankness of the conversations that people are willing to have. And our expectation is to provide an in-depth look at how the world's largest software vendor delivers on its promise of providing more secure products and services.

About the Authors

Scott Swigart and Sean Campbell originally began their careers as Developers, DBAs and technical trainers. In 2000, they teamed up and grew a technical consultancy business, which they sold in 2006. Scott and Sean went on to found Cascade Insights, a boutique firm focused on providing technical analysis and strategic insight on emerging and converging technologies, across both closed and open source environments. You can learn more about Scott and Sean at www.cascadeinsights.com as well as at the www.howsoftwareisbuilt.com blog.