News

Microsoft Revises Policy on Reporting Security Flaws

Microsoft has adopted a variant of its "responsible disclosure" policy for reporting security flaws in its software, the company announced last week.

The new approach is called "coordinated vulnerability disclosure" (CVD). However, the policy is not too different from responsible disclosure, which depended on keeping reports by security researchers private until a fix or workaround was available from the software vendor. Microsoft had been an advocate of responsible disclosure because it conceived of secrecy about software flaws as the best way to protect its customers, company officials have explained.

A separate philosophy, at odds with responsible disclosure, is the "full disclosure" camp. Full disclosure advocates believe that rapid public disclosure of software vulnerabilities will spur researchers and software companies into action to fix the flaws.

The ongoing debate between the two views became highlighted in an ugly fashion last month when Tavis Ormandy, a security researcher who works for Google, disclosed a Windows XP help function flaw after giving Microsoft a four-day advance notice. Ormandy defended his action as enabling collaboration on the issue, while Microsoft contended that it just empowered hackers to spread malware more quickly.

In announcing Microsoft's new CVD policy, Matt Thomlinson, general manager for Microsoft's trustworthy computing security, admitted that CVD "does not represent a huge departure from the current definition of 'responsible disclosure.'" The main difference centers on whether the active attacks are happening or not. If they are, public disclosure should happen, but within limits,    he contended.

"Only in the event of active attacks is public disclosure, focused on mitigations and workarounds, likely the best course of action -- and even then it should be coordinated as closely as possible," Thomlinson stated in a blog post.

The point was reiterated in a detailed description of Microsoft's CVD policy by Katie Moussouris, senior security strategist at Microsoft.

"Make no mistake about it, CVD is basically founded on the initial premise of Responsible Disclosure, but with a coordinated public disclosure strategy if attacks begin in the wild," she wrote in her blog entry. With its policy change, Microsoft's main emphasis is on coordination. It's dropping the "responsible" term as too loaded with implications, Moussouris explained.

However, the main complaint by full disclosure advocates -- that software companies take too long to fix vulnerabilities, allowing hackers a chance to quietly exploit them -- seems to be a sticking point. Mike Reavey, director of the Microsoft Security Response Center, said that the complexity and widespread use of Microsoft's products requires testing to ensure that a fix is not issued that causes greater problems for Microsoft's customers. In some cases, that means that Microsoft may require a year or more to produced a fix.

"And there have also been cases that are such deep architectural changes that they can take multiple years to fully resolve or may not be able to be resolved in some of our older products," Reavey stated in an MSRC blog post.

Such a time period seems at odds with policy descriptions by Google, which suggest that critical vulnerabilities should remain undisclosed for no more than 60 days. Google's view is that software vendors have abused the responsible disclosure approach to simply ignore fixing their software.

"We've seen an increase in vendors invoking the principles of 'responsible' disclosure to delay fixing vulnerabilities indefinitely, sometimes for years; in that timeframe, these flaws are often rediscovered and used by rogue parties using the same tools and methodologies used by ethical researchers," a Google security blog stated

Microsoft, in contrast, has not stated how long a vulnerability should remain under wraps under its new CVD policy.

"Under CVD, just the same as in RD [responsible disclosure], finders and vendors should try to agree to a timeframe for fixing the issue," Moussouris explained. "Complex cases may take longer to fix, and Microsoft will be as transparent about our investigation with finders as we can be, to let them know where we are in the investigation and resolution process."

Moussouris promised that Microsoft would issue "timely updates and target dates for resolution so that a finder is aware of the case status." She also described security advisories as the mechanism of response for software vendors when "a vendor may be unwilling or unable to respond to a vulnerability report."

The Microsoft Security Response Center now provides a description for researchers or individuals to report a software flaw under its "coordinated vulnerability and acknowledgment policy for Security Bulletins." The steps on how to proceed are described here.

About the Author

Kurt Mackie is senior news producer for 1105 Media's Converge360 group.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube