Early Days of the SDL, Part One

Hi everyone, Michael here. Even though 2001 and 2002 are a distant memory for many people, those years are still fresh in my mind; not because of CodeRed or Nimda, even though I had worked in the IIS team , but because of the important security work we started within the company.


Early in 2001 David LeBlanc and I lamented the deluge of email we constantly received asking pretty basic security questions; so rather than whine and complain we thought we would write a little book that covered some of the basics so we could focus on the ‘hard problems.’ That book was “Writing Secure Code” (aka WSC) named after Steve Maguire’s excellent “Writing Solid Code.” I think it’s fair to say WSC was the secret weapon that helped scale our early security work because we simply gave every engineer at Microsoft a copy and told them to read it!


Fast forward to October 2001. The .NET team found a small number of security bugs in the runtime and framework, and that made the .NET team nervous. So they bravely decided to have a “Security Stand-down,” which, in short, means stop all work, get more security training and find and fix security bugs. There was no time limit to the work. That’s why I said it was ‘brave’ because the work was done when incoming bugs flat-lined. I, and many others across the company were actively involved in the .NET security work, and while the work was beneficial, and frankly adrenalin-inducing (seriously, it was!), we knew such efforts were not sustainable. Eventually, we came to understand that we had to change our development process.


At the end of the November 2001, a small cadre of senior Windows folks, Steve Lipner included, met with the Microsoft senior leadership team, Bill Gates among them, to discuss security. At the end of the meeting, Bill said he wanted to learn more about security bugs in detail, so a four-hour follow-up meeting was scheduled for December for me to discuss security vulnerabilities in depth with Bill. At the end of the chat, I gave Bill a copy of Writing Secure Code.


While all this was going on, Craig Mundie and Bill had been working on an initiative to focus the company on security, privacy and reliability; that became known as Trustworthy Computing, and the memo of Jan 15, 2002 quickly followed, rallying the company. It also gave our group sufficient clout to do what needed to be done to add more security rigor to our development processes.


At first the process improvements were haphazard; we introduced a very rudimentary version of threat modeling in 2002, started using static analysis tools and teaching developers to review code for security bugs. And most major products at Microsoft underwent “Security Pushes” following the .NET Security Stand-down model. Over time we fine-tuned the best practices into what we have today at Microsoft: The Security Development Lifecycle.


When we started our little group to focus on “security as in threats, not security as in features” we had no name until Dave Thompson, then VP responsible for security (as in features) in Windows named us the Secure Windows Initiative, a name that has stuck until this year. Many of the original folks are still around; we’re still as active and energetic as we were in 2001 and 2002, just a little grayer and substantially wiser! Our small team, which is now an order of magnitude larger, changed the face of Microsoft security by changing the end-to-end development process, which believe me, is no easy task at a company the size of Microsoft.


My hat is off to everyone who worked on “Security as in threats” back then, especially those who understood how that is different from “Security as in features.”

About the Author
Michael Howard

Principal Security Program Manager

Michael Howard is a principal security program manager on the Trustworthy Computing (TwC) Security team at Microsoft, where he is responsible for managing secure design, programming, and testing techniques across the company. Michael is an architect of the Security Development Read more »