News

Microsoft on Its Security Response

</i>MCP Magazine<i> asked Stephen Toulouse, security program manager, Microsoft Security Response Center, about the flaw and resulting controversy about the time delay.

• By Keith Ward
• 04/08/2004

Is the discovery of the ASN.1 flaw a big setback for Microsoft, considering its Trustworthy Computing efforts over the last two years?

Stephen Toulouse: The Security Business and Technology Unit is working across Microsoft to help improve software security by making it more secure by design, by default and in deployment, but we never expected to perfect security overnight. The results of Microsoft's commitment are clearly evident in the newest versions of Microsoft's flagship Windows, Office and Exchange products and these products are yielding fewer vulnerabilities than previous versions.

A Microsoft spokesperson was quoted in a news story as saying, "Security response requires a delicate balance of speed and quality." But, according to Marc Maiffret of eEye Digital Security, the vulnerability was reported to Microsoft more than six months ago. A) Is Maiffret's estimate of when the vulnerability was reported accurate? B) Has it ever taken Microsoft this long to come out with a patch for a vulnerability? C) What special circumstances required such a long wait?

A) Yes. eEye reported this vulnerability to Microsoft in late July of 2003.

B) Each vulnerability is different, and therefore the time to produce an update is likewise, different. When a vulnerability is reported to Microsoft, we investigate the breadth of the technology affected and its impact on customers. We then begin an engineering phase that aims to achieve a comprehensive and quality fix. For a technology as integral to Windows as ASN.1, we felt it was important to take as much time as necessary to ensure we produced a quality fix to protect customers.

C) This investigation required us to evaluate several aspects and instances of this functionality in order for our engineers to create a comprehensive and high quality fix. This was an instance in which due diligence required us to very carefully evaluate the broadest possible implications of a single anomaly reported to us. The investigation, in combination with testing to ensure the fix was quality, resulted in the overall length of time spent on this update. We appreciate that eEye worked with us responsibly during this entire process so that customers could be protected.

Can we assume that this flaw will be fixed in Windows XP Service Pack 2?

Yes, this update will be included with Windows XP Service Pack 2.

If Windows Server 2003 was built "from the ground up" with security in mind, how did this flaw get in the code and evade the $200 million code review of several years ago?

We never expected to perfect security overnight. Windows Server 2003 has already demonstrated that the code review made significant improvements to security, as evidenced by the reduced number of bulletins issued compared to Windows 2000. Windows Server 2003 is more secure by default, includes innovative security features such as IE hardening, and continues to yield fewer vulnerabilities than previous operating systems.

How do you answer people who say "Microsoft talks a good game about security, but these sorts of things keep popping up constantly. I don't trust them."

Security is not a quick fix solution—we realize that improving security requires a fundamental shift in the way we develop code and build products. This is a long-term initiative and change does not happen overnight. In fact, industry analysts have cited Microsoft's commitment to a long-term strategy as evidence of our sincerity. We have every confidence that our efforts will result in more secure code. This is just the beginning. You should continue to watch for changes over time.