In January 2002, Bill Gates launched the Microsoft Trustworthy Computing Initiative which focused on security as one of its four pillars. One of the big achievements of this initiative was the creation and evolution of the Microsoft Security Development Lifecycle or SDL, a comprehensive approach to write secure code. Microsoft made it a company-wide mandatory policy back in 2004.
It has mainly 2 goals:
We are sharing our prescriptive guidance around the SDL methodology and tools so that other organizations can build more secure software. We also have been collaborating with other companies to help them define and adopt their own SDL and get feedback from their own experience: Adobe, Cisco, Government of India (CERTin), Financial Services Roundtable (BITS Software Assurance Framework) have also adopted SDL.
SDL guidance (5.2) is available here: http://blogs.msdn.com/b/sdl/archive/2012/05/23/now-available-microsoft-sdl-process-guidance-updates-version-5-2.aspx
I would encourage you to first read the Simplified Implementation of the SDL paper and some of the additional resources we make available on the Microsoft SDL website to begin building your own SDL framework.
Having the skills to implement the SDL is going to be something more and more valued as ISVs realize the need for security being baked into products.
Also, threat modeling can be used in IT projects to review the architecture of a given solution, so it’s not only a practice useful for developers but also for IT Pros.
The SDL Progress Report explains the evolution of the SDL from 2004 to 2010. It also contains figures like the following one showing “Availability of exploit mitigations on Windows client SKUs.”
The following diagram from Roger Halbheer shows the evolution of threats and the associated Windows built-in protection over the years.
You may have read this article that shows how SDL is paying off: “Microsoft’s security team is killing it: Not one product on Kaspersky’s top 10 vulnerabilities list” Emil Protalinski, TNW, Nov 2nd, 2012
1. “Oracle Java Multiple Vulnerabilities […]
2. Oracle Java Three Vulnerabilities […]
3. Adobe Flash Player Multiple Vulnerabilities […]
4. Adobe Flash Player Multiple Vulnerabilities […]
5. Adobe Reader/Acrobat Multiple Vulnerabilities […]
6. Apple QuickTime Multiple Vulnerabilities […]
7. Apple iTunes Multiple Vulnerabilities […]
8. Winamp AVI / IT File Processing Vulnerabilities […]
9. Adobe Shockwave Player Multiple Vulnerabilities […]
10. Adobe Flash Player Multiple Vulnerabilities”
This article also underlines the need to have the entire industry adopt SDL-like approach. This is what ISO 27034 could help you to encourage by having your procurement require vendors to provide you information about the security of their applications when they submit a proposal to you.
Finally, we recently announced during the Security Development Conference that SDL meets or exceeds the guidance published in ISO/IEC 27034-1.
ISO/IEC 27034 provides guidance for a risk based and continuously improving software security management system applied across the application lifecycle. ISO/IEC 27034-1, Annex A contains a case study illustrating how the SDL conforms to the components and processes of ISO/IEC 27034. ISO/IEC 27034-1 is published on the ISO website http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44378.
If you are interested in finding out more about ISO/IEC 27034, the paper “The emergence of software security standards: ISO/IEC 27034-1:2011 and your organization” from Reavis Consulting Group covers the value and importance of ISO 27034 for the software industry.
For latest news about the process, tools, and industry collaboration, please visit the SDL blog published here: http://blogs.msdn.com/b/sdl/
In the next posts I’ll write about threats from the wild.