Microsoft’s Coordinated Vulnerability Disclosure
With many companies now paying security researchers for finding vulnerabilities in their products, how will Microsoft follow suite?
Here’s what Microsoft’s Jerry Bryant had to say:
“We value the researcher ecosystem, and show that in a variety of ways, but we don’t think paying a per-vuln bounty is the best way. Especially when across the researcher community the motivations aren’t always financial. It is well-known that we acknowledge researcher’s contributions in our bulletins when a researcher has coordinated the release of vulnerability details with the release of a security update.”
“While we do not provide a monetary reward on a per-bug basis, like any other industry, we do recognize and honor talent. We’ve had several influential folks from the researcher community join our security teams as Microsoft employees. We’ve also entered into contracts directly with many vendors and sometimes individual researchers to test our products for vulnerabilities before they’re released. Many of these vendors and individuals first came to our attention based on the high-quality and unique approaches demonstrated by the vulnerabilities they reported to the MSRC.”
Microsoft has also suggested that we move towards a “Coordinated Vulnerability Disclosure” (CVD) which essentially states that we should work with the vendor to get things patched but publicly release the vulnerability should attacks on the internet start becoming rampant.
Here are some of the basic tenants of CVD (fromhttp://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspx):
Step 1: Keep it Private, Keep it Safe
● Reporting: Report the issue to the vendor, or to a CERT-CC or some other coordinator you trust who will report to the vendor privately, or sell it to a service that will.
● Communication and timelines: Under CVD, just the same as in RD, finders and vendors should try to agree to a timeframe for fixing the issue. 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. We appreciate finders being flexible when we share information with them about why a fix may take longer than the finder thinks it should.
● Status updates: Also as in traditional Responsible Disclosure, under CVD Microsoft will provide timely updates and target dates for resolution so that a finder is aware of the case status.
● Alternative to FD when a vendor is not responding at all: In some circumstances, a vendor may be unwilling or unable to respond to a vulnerability report, which is what advance security advisories are for – advisories published with limited details and no Proof of Concept, plus mitigations and workarounds. Finders can try that before resorting to publishing full details if they can. Some vulns won’t lend themselves easily to this method, but the point is to try.
Step 2: Hurry Up and Wait
Vendors and many finders know there has to be a balance between speed and quality. For Microsoft, even a 1% test failure rate could affect millions of our customers, so we take testing for functionality impact as seriously as we do the testing to make sure the update comprehensively addresses the vulnerability.
Ideally, both vendors and finders should work diligently to find a solution that will keep customers safe. If finders are only interested in working on the attack, that’s ok too, as long as they give the vendor a chance to do their investigation, engineering and testing.
Working together on the update, sharing ideas, and testing each other’s ideas is sensible.
- It’s great when a researcher offers their ideas on how the issue could be mitigated or even fully fixed, but vendors are in the best position to do the integration testing and application compatibility testing required, since they know their products and the full testing matrix that their customers require.
- When we have good relationships with finders, Microsoft will often offer our proposed solution to the finder to see if it comprehensively addresses the vulnerability from a security standpoint.
- If finders choose to, we would like to offer them a chance to share their proposed fixes with us if they want us to test against both security and application compatibility with our other products, or products typically found on our customers’ machines.
- The security testing for simple vulnerability classes like buffer overflows is typically very fast. More complex attacks, that rely on a multistep exploitation process, or vulnerabilities with multiple vectors to reach the vulnerable code require more security testing time. If security testing was all vendors had to do, we wouldn’t have as many timing disagreements.
- The other testing time will vary depending on the complexity of the functionality touched by the update, how the product is used and how other products integrate with the affected product.
Step 3: Coordinated Public Disclosure
Coordinate public release happens, ideally, when the vendor releases the update. In the case of publicly verifiable active attacks, details may be released prior to an update being released, with emphasis on giving details to protection providers.
- If there are active attacks in the wild, the finder and vendor work together on the best interim solution.
- The vendor and finder agree on what action to tell users to take to protect themselves.
So HackTalkers, how do you feel about this new “shift” in vulnerability disclosure?
