Microsoft's Security Development Lifecycle

In the past decade it has been easy to slag Microsoft for their stance on security. It has appeared that the drive for profits have always trumped the safety and security of the code. When Microsoft decided to STOP development and retrain the ENTIRE development group about secure programming, many in the industry brushed it off as a PR stunt. But as I pointed out early last year, if we look at what Microsoft has been doing as of late, we can see that they have made significant changes to build a foundation for a more secure computing experience:

1. They have created better error-reporting software. They have found that the top 20% of their errors make up 80% of the problems. Knowing this and capitalizing allows Microsoft to significantly prioritize and reduce bugs that matter the most.
2. They have created better developer tools to help write more secure software, with release of tools like prefix, prefast, AppVerifier and FxCop. Their only problem right now with this is that they AREN’T letting developers know about them!
3. They halted product development for a period of time and retrained their developers to code more securely
4. They audited as much product source code as humanly possible and now have a dedicated lead security person for each component of the Windows source code to watch over code quality as it relates to security. Previously they had a clean up crew come in after the fact and try to sanitize the master sources.
5. Microsoft has begun to provide more secure defaults when shipping new product. As a clear example we have seen the launch of Windows Server 2003 with a lessened attack surface than previous versions of their server product.
6. Microsoft now provides better tools such as the Microsoft Baseline Security Analyzer to analyze and audit patch management as it relates to security bugs in a proactive manner.
7. After major security incidents (like MSBlaster and MyDoom) Microsoft has released tools to help respond and fix possible vulnerable and compromised machines. Although these are not timely enough (IMHO), it’s still good to see.
8. Microsoft has provided a more definitive patch management cycle to address “patch hell” until their newer products get released that have a significantly lessened attack surface, and have better code quality.
9. Microsoft provides better integrated firewalling with their Internet Connection Firewall (ICF), released with the latest service pack for XP. Ok this item isn’t about secure coding... but more about "secure by default" mentality.
10. Microsoft is being more open about the entire security process. And not just for PR purposes. More articles, documentation and transparent communication are now available through MSDN, Microsoft employee blogs, and Microsoft’s Security webcasts.

The last bullet is what I want to talk about today. Michael Howard reports that you can now read about the security-related process improvements they have put in place at Microsoft. They have been working on defining this for about two years now, and as of today now have made this document public.

It is an excellent document providing real insight on what is going on with Microsoft's own security development lifecycle. Well worth the investment in time to read and learn from. (Anyone who is arrogant enough to believe they know everything and cannot learn something from Microsoft's experience here really shouldn't be in this industry)

So check out Microsoft's Security Development Lifecycle. Happy reading!

Posted by SilverStr at March 19, 2005 11:46 AM | TrackBack