How Microsoft Develops and Releases Software Patches
When we launched our first security newsletter in December, I asked you to send me your comments and feedback so that I could be your advocate at Microsoft for security issues—and you delivered! I appreciate the many e-mail messages with comments and questions, and we will begin answering them this month.
One particular question raised by many of you focused around the Microsoft process for patching known vulnerabilities. This is an important topic to many of you, so this month I will describe the lifecycle of a software vulnerability from time of disclosure until a patch and Security Bulletin release.
The Microsoft security response process follows the general steps of reporting, investigation, development, test, and release.
The security response process starts with the reporting of a potential issue. Microsoft uses our membership in the Organization for Internet Safety to strongly promote the principles of responsible reporting. A central principle is the belief that the best way to minimize customer risk is for security researchers to work closely with vendors to identify issues and fix them before they are publicized.
When Microsoft releases a patch concurrently with an announcement of a vulnerability, it is a result of having identified the issue and worked through the patch release process prior to communicating publicly. This means our customers will have an opportunity to protect themselves from malicious hackers seeking to exploit the vulnerability. However, when vulnerabilities are announced publicly at the same time Microsoft is notified, customers remain exposed to malicious attackers.
Once a potential issue is reported to Microsoft, either privately or publicly, our team immediately begins an investigation to reproduce and verify the reported issue and to identify any associated or variant issues. Historically, only about 1 out of 10 reported issues turns out to be a new and unique security issue that warrants opening an investigation, while the other 9 fall into categories of known issues, non-security issues, or errors.
If an issue is replicable, a priority is assigned to it and potential fixes, mitigations, and workarounds are developed. We’ve learned over time that mitigations and workarounds are very important for empowering users to control when and how they manage their risk. Chartered with defining and implementing the process for responding to reported software security issues, the Microsoft Security Response Center works closely with the affected product group to do this investigation, and, further, to expand the investigation to other supported versions of products so that we can gain a complete understanding of how an issue may affect customers.
One of the most challenging elements of this process is testing. It is critical to our customers that whatever changes we make to a product have little to no impact on existing installations and applications. For a product such as Internet Explorer, for example, the breadth can be significant. Microsoft currently supports three major versions of Internet Explorer (5.01, 5.5, 6) across several minor versions (for example, Internet Explorer 6 “gold” and Service Pack 1) across several operating systems (Windows 98, Windows Me, Windows XP, Windows 2000, and Windows Server 2003) for more than 25 languages. In total, to fix one Internet Explorer issue, Microsoft builds and releases more than 400 unique packages, tested on an even larger number of combinations.
Complementary to taking these steps to help customers more ably protect themselves from malicious attackers, the Security Response Center and Security Business Unit offer outreach programs and prescriptive guidance through our Web properties, through support channels, and directly through our interactions with customers.
Most importantly, what this means to us is that, even as we are driving urgently for timely delivery of a patch for serious security issues, we are motivated to focus as much on the “quality” part as the “timely” part so that we can deliver the quality and protection our customers demand. It is essential that each patch installs properly, addresses the security issue, and does not disrupt other existing functionality. It is a job Microsoft takes very seriously.
To learn more about Microsoft Security Response Center policies or to report suspected security vulnerabilities, visit the Microsoft Security Response Policy and Practices website.
Again, thanks for the comments and feedback, and I encourage you to keep it coming. Let me know if this article helped answer some of the questions you had.