In the last few years, as you all know security has been absolutely top of mind and a key priority for us at Microsoft.  You have heard us talk about Trustworthy Computing Initiative.  You have heard us talk about how we have fundamentally changed our software development lifecycle to keep security a key element of our day to day development activity.  That means if you are a program manager at Microsoft writing specifications for a product, you are also going to do a threat model at the same time as the functionality or component is being designed.  If you are a developer, you have access to a variety of rich static code analysis tools that you can run on your code and find/fix common security issues even before you check in your code.  If you are a tester, you have access to test automation tools and techniques that help you test for security vulnerability issues, penetration testing and the like.   

 

With Visual Studio 2005, we have made security as one of the top priorities for the product development organization.  Later this fall, the entire Whidbey team will be engrossed in a series of security related reviews we call the ‘security push’.  The key to remember is that teams won’t be thinking about security for the first time during the security push.  They think about it every day.  The security push is a focused effort to make sure that we have absolutely done all the right things in the product from a security point of view.

 

Like most teams at Microsoft, our process will build on the ‘Security Development Lifecycle’ or SDL. The SDL consists of six phases – Requirements, Design, Implementation, Verification, Release and Response. In the first phase, the team creates a plan and assigns resources. In the next phase, company-wide and divisional guidelines are applied, the design architecture is reviewed and the ship criteria are decided. The key here is to build a threat model. During the implementation phase, all testing is conducted based on these threat models. Tools and documentation related to security are prepared for release to customers. This phase is followed by the ‘security push’ during which the team conducts a series of intensive reviews, attack testing, reviews against new threats, a review of the threat models and a review of the ship criteria. The stage is finally set for the FSR – the Final Security Review. The team archives the compliance information, conducts penetration testing and once again reviews all threat models. Final sign-off is conducted by the Secure Windows Initiative Team or SWI team, which is part of our Security Business Unit and a company-wide team charged with education, best practices and overall improvement in the security design of Microsoft’s products.

 

Next week, I’ll post a list of resources that can help you make your code more secure.

 

Here’s a timeline representation of the SDL:

In the coming months, we will be publishing more information on SDL so that you all can understand more about how we do things internally as well as be able to use it as appropriate in your software development activities.

 

Namaste!