Hello all – Dave here…

I am currently at RSA and decided to take a few moments to blog about some updates to the Security Development Lifecycle.  Admittedly, I have been “radio silent” on the blog for awhile – for those that know me, that’s usually a warning signal that I am cooking something up…

Anyway, back when we first started this blog we promised that you would see more about the particulars of the SDL – and I think we have done a reasonably good job.  Michael Howard has written some pretty interesting pieces on a wide variety of subjects; bug post-mortems, philosophical notes and the like.  Adam Shostack did a fabulous job on the threat modeling series; Eric Bidstrup took a deeper look at the perceived vs. real benefits of the Common Criteria and I have penned a moderately well received screed or two from time to time.

However, one of the common requests (complaints?) that I have heard is that we have been short on the real “guts” of the SDL – that is to say, a point by point examination of how to apply the SDL. I would argue that Michael and Steve’s book on the SDL is a good primer on how to get started.  I think Jeremy Dallman added more momentum with his “Crawling toward SDL” post, giving some practical advice on how to approach the issue of secure software development from scratch.

Despite these efforts I have heard that people still want more detail – some folks are curious about how an organization the size of Microsoft programmatically drives culture change; others are looking for guidance that can be repurposed for their own organizations and finally, some folks are convinced that we are deliberately holding back some security “secret sauce” for some reason.  Go figure.

With that, let me cut to the chase.  Today, we have made the Microsoft Security Development Lifecycle, version 3.2 available for your perusal on MSDN.  This has been in the works for quite awhile and has involved a ton of folks in SEC and TWC putting in a lot of hours and resources into getting this published (props to Ziv Fass and Jed Pickel!).

As you can probably guess, this is not an exact duplication of the SDL for a number of reasons – but it’s pretty darn close. Given that caveat, allow me to illustrate a few points about this guidance...

• First, we have gone through and removed Microsoft specific jargon, references to internal resources on our intranet, and things that would likely make zero sense to an audience outside of Microsoft (the scrub work was one of the primary inhibitors to publishing previous versions of the guidance).
• Second, this is a generalized representation of how the SDL is applied at Microsoft for the development of rich client and server applications – while many of the principles apply to the creation of web applications, I would caution you to view this in the correct context.  While Bryan Sullivan has written about web development in the past we’ll have more on SDL and web application development in the future.
• Third, for all intents and purposes the SDL is considered the “minimum bar” for security and privacy at Microsoft for those products with meaningful security risk; there are a number of teams that choose to invest more time and resources as necessary to meet product team goals that may exceed the SDL.  We salute that behavior.  : )

Finally, in reference to the third point above, I am compelled to say the following. (LEGAL DISCLAIMER ALERT – those with weak constitutions should avert their eyes):

The following documentation on the Microsoft Security Development Lifecycle, version 3.2 is for illustrative purposes only. This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented herein. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, OR STATEMENTS ABOUT APPLICABILITY OR FITNESS OF PURPOSE FOR ANY ORGANIZATION ABOUT THE INFORMATION IN THIS DOCUMENT.

For the morbidly curious: Yes, I wrote that; yes, it passes legal muster; no, I am not a lawyer, nor do I play one on TV.  : )

So there you have it – Microsoft SDL 3.2.

There are a few sharp eyed souls that read the blog and will wonder about our publishing schedule for updates – it’s no secret that we examine the SDL every six months and either add new requirements to meet emerging threats or deprecate old guidance.  It has been described by some as analogous to “changing tires on a moving vehicle.”  Let me say now that we will NOT be publishing new SDL guidance on a six month schedule for the foreseeable future – we’ll settle on a reasonable publication frequency and hopefully accelerate over time.

I welcome your thoughts and comments...