I’m always asked “How can you claim the SDL is working when Microsoft still issues security updates?” So I want to make sure people understand the goals of the SDL and perhaps more importantly, the non-goals.
There are three major security-related disciplines here at Microsoft and people outside the company often confuse the three.
- 1. Security feature development
- 2. Security response
- 3. Secure software engineering
The first is all about building security features such as authentication technologies, firewalls and such. This is not SDL. At Microsoft the SDL obviously impacts the design and code that goes into these security features, however.
Next is the response process. All software has security vulnerabilities at some stage, and it’s important that quality updates for all supported versions of the software in all supported languages be available as soon as possible. But no sooner! You can’t rush a security fix out with minimal testing or on a subset of supported platforms or languages because you run the risk of releasing sub-quality fixes, or protecting some customers, but not all.
Finally, we come to secure software engineering. When we set out on the SDL journey, we realized that we needed to achieve two main objectives. The first is to reduce the number of vulnerabilities that creep into the software’s design and code. I want to emphasize this point because this is the single most important goal of the SDL: To reduce the number of vulnerabilities in software products. This is not about who can fix bugs faster, SDL is about reducing the chance that vulnerabilities are added to the software in the first place. Writing lots of code quickly, shipping it and then racing to fix security bugs later is not engineering, it’s chaos, and it’s not good for customers. A question I like to ask software developers outside of Microsoft is, “what are you doing to reduce the chance an engineer will add a new security bug to the system?” The answer to this question must be holistic and include:
- Secure design and attack surface reduction
- Threat modeling
- Secure coding requirements (note the word, “requirements” not “best practices”)
- Static analysis tools
- Testing requirements
- End-user security documentation.
- Response Planning
In a nutshell, this is a high-level view of SDL process.
The next goal of the SDL is to reduce the impact of security vulnerabilities missed during the software development process. Security is an ongoing arms race where attackers constantly devise new attacks to thwart the defender’s defenses. Which means you can never hope for zero security vulnerabilities. We have seen many of these forward-looking defenses in action in Windows Vista, IIS6, SQL Server 2005 and Office 2007.
Look carefully at the list of products I just mentioned, they are all products that had a full release after the implementation of security process improvements at Microsoft. They are not service packs, and this is where I need to make a critically important point about the SDL. To gain the full impact and benefit of the SDL, you must apply the SDL to a product at its inception. With the exception of Windows XP SP2, (which was a security-focused release, but predates the SDL), service packs at Microsoft include fixes and perhaps some opportunistic feature enhancements requested by customers. Such releases cannot get the full benefit of the SDL, because security is not just about bug fixes, it is a holistic property that goes beyond fixing implementation vulnerabilities to encompass sound design and defense in depth.
Ultimately, this means that newer Microsoft code is more secure than the older Microsoft code, and that is the trend we’re seeing across the board. Don’t expect to see a marked drop in the vulnerability count in older code. You won’t see it, because we can’t dramatically improve the security of an already released product.