Welcome to the SDL Blog!

Greetings and welcome to the Microsoft Security Development Lifecycle Blog!

We on the Security Engineering team at Microsoft have been getting a lot of friendly pokes from customers, partners, colleagues, and competitors, asking us to say more about the Microsoft Security Development Lifecycle (SDL) in an open forum. While Michael Howard, Steve Lipner, and others have written and spoken about SDL in numerous publications and venues, we understand the desire to “take a peek under the hood,” so to speak. Thus, the “SDL Blog” was born – with apologies for the decidedly unimaginative nom-de-blog. What we’d like to do in this space is provide information about SDL and commentary on security and privacy processes as close to “real time” as possible.  We hope to accomplish a number of things by blogging on the SDL:

-          Inform: We want to provide factual information about the SDL – this includes explorations of both the “good” and the “bad.” To that end, we will try to avoid posting on the same types of subjects that Michael, Adam and MSRC talk about in their blogs – however you can expect there to be some degree of crossover from time to time.

-          Inspire debate:  Amongst ourselves and with you, dear reader. There are a number of issues around security, privacy, and various processes in which reasonable people will differ. That’s cool. Platform fan-boys/otaku need not post. We’ll keep it respectful if you will…

-          Respond to the “security punditocracy:” It has been interesting for some of us to watch those at various points on the punditocracy food chain, commenting not only on what the Microsoft SDL “is,” but also commenting on its effectiveness. While some of the feedback is valid, these commentaries are usually followed by the obligatory pitch for one’s own proprietary process. For those of you old enough to remember – “…it’s a floor topping AND a dessert wax!” springs to mind (apologies to SNL for the deliberate misquote).

We seek to shine the light of day onto these commentaries and let reasonable people decide for themselves! To be clear, this is not a slagfest – we will amplify points about security and privacy processes made by others that are spot on; conversely, we will seek to debunk some popular misconceptions about Microsoft’s security efforts.

It’s important to note that some of us will likely post more frequently than others – security and privacy issues at Microsoft (and in the ecosystem) will wax and wane – we will comment accordingly. Rest assured, we will not sacrifice quality for frequency as it relates to posting info about the SDL.

Enough about why we’re here. Now would be a good time to introduce the contributors to this literary tour de force

Eric Bidstrup is a Group Program Manager responsible for managing SDL policy at Microsoft. He has worked at Microsoft for more than 17 years as an engineer and in program management.  He’s worked on a variety of products and technologies from the old Microsoft character mode applications (MS Word 4.0 anyone?) and Windows 3.0/3.1/95; he led the creation of Microsoft’s online “casual” games site MSN Gaming Zone , and worked in Microsoft Research on speech recognition and synthesis technologies. Eric also contributed to the development of MSN-TV2 , and has been working in security over the last few years.

Michael Howard is a Senior Security Program Manager in the Security Engineering group at Microsoft. He is an architect of the SDL and co-author of numerous security books including Writing Secure Code for Windows Vista, The Security Development Lifecycle, 19 Deadly Sins of Software Development and the award-winning Writing Secure Code.

Tina R. Knutson is a Senior Privacy Program Manager in Microsoft’s Corporate Privacy Group. Her main focus is developing rules, processes, and compliance tools for building privacy into products and services. She is a co-author of the company’s Privacy Guidelines for Developing Software Products and Services (2006), and a Certified International Privacy Professional (CIPP).

David Ladd has worked at Microsoft for 17 years in a variety of technical and management roles. He currently serves as a Senior Security Program Manager on the Security Engineering Strategy Team. Prior to this, David served as Group Program Manager in the MSR External Research Programs group, where he focused on the expansion of security research and education. David is the co-founder of the Trustworthy Computing Academic Advisory Board, a group created to expand the interactions among Microsoft and the academic security and privacy research communities. He serves on a number of external advisory boards and committees, is an associate editor of IEEE Security and Privacy magazine, and is a member of ACM, IEEE, and USENIX.  As Michael Howard and James Whittaker delight in pointing out, Dave is the author of no books.

 

Steve Lipner is Senior Director of Security Engineering Strategy in Trustworthy Computing at Microsoft. He is responsible for the definition and updating of the Security Development Lifecycle. Steve is also responsible for Microsoft’s policies and strategies for the security evaluation of its products, and for the development of other programs to provide improved product security to Microsoft customers. Steve has over 30 years’ experience as a researcher, development manager, and general manager in IT security. He is named as co-inventor on 11 patents in computer and network security. Steve is a co-author with Michael Howard of The Security Development Lifecycle.

Rob Roberts is a Program Manager in Microsoft’s Corporate Privacy Group. Rob’s roles include architect for privacy testing and tools, as well as privacy consultant to several Microsoft product groups. He is a co-author of Microsoft’s whitepaper on Privacy Guidelines for Developing Software Products and Services (2006).

Adam Shostack is a Program Manager in Microsoft’s Security Engineering group. Before working on the Security Development Lifecycle at Microsoft, Adam was involved in four startups on vulnerability scanning, privacy, patch management, and program analysis. He helped found the CVE, International Financial Cryptography association, the Privacy Enhancing Technologies workshop, and the Emergent Chaos blog.

James A. Whittaker who is now a Security Architect at Microsoft, spent his career in software testing and security. While a professor at Florida Tech, he created the largest academic software testing research center and made testing a degree track for undergraduates. Before he left Florida Tech, his research group had grown to over 60 faculty and students and had won over $12 million in research awards and contracts. He has several security-related patents for defense against viruses and worms, and is the creator of the highly acclaimed runtime fault injection tool Holodeck. Dr. Whittaker received his Ph.D. degree in computer science from the University of Tennessee in 1992 and is the author of How to Break Software, How to Break Software Security (with Hugh Thompson), How to Break Web Software (with Mike Andrews), and over 50 peer-reviewed papers on software development and computer security.

Dave Ladd

Sr. Security Program Manager

 

About the Author
Dave Ladd

Principal Security Group Program Manager

Join the conversation

3 comments
  1. NatureBuff

    I like what I see so far.

  2. vc-programmer

    hi,

    i had a couple of questions on STRIDE modelling, not sure if this is the right place to ask.

    1> STRIDE is defined as "a method of classifying the effect of a threat being realized".

    (a) since its the >>effects<< of a threat being realized, what are threats then?

    (b) effects of a threat being realized is >>risk<<.

    2> Since STRIDE is listed as a method for threat modelling, where are threats coming into the picture, if at all?

    could you share whats your understanding about STRIDE…

    thanks

  3. Anonymous

    I love factual stuff. Will love what you are about to share :)

Comments are closed.