The new era of vulnerability disclosure - a brief chat with HD Mooreby Steve Ragan - Aug 16 2010, 12:45
Recently there have been several notable changes to the vulnerability disclosure landscape. Google, Microsoft, TippingPoint, and Rapid7 have recently issued guidelines and statements addressing how they will deal with disclosure going forward.
We talked to HD Moore, someone who has had to deal with disclosure his entire professional career, to get his take.
Disclosure is a hot topic. Like politics, the topic of disclosure can turn a simple meeting of the minds into an emotionally fuelled debate in the security world. When it comes to researchers, who have tried “Responsible” Disclosure over Full Disclosure, there is a mix of experiences from pleasant to frustrating. For example, when a company who has a vulnerability threatens to sue the researcher if they go public
Rapid7, where HD Moore is Chief Security Officer and Chief Architect of Metasploit, recently revamped their disclosure policy. In short, they will hold a vulnerability for 15 days after contacting the vendor, before sending it to CERT, who will give the vendor another 45 days to address the issue.
This cycle is similar to the one announced by Google [link]. Google announced last month that critical issues reported by their security team will have 60 days to be fixed before public disclosure is made. According to the blog post on the topic, creating pressure towards more reasonably-timed fixes “…will result in smaller windows of opportunity for blackhats to abuse vulnerabilities. In our opinion, this small tweak to the rules of engagement will result in greater overall safety for users of the Internet.”
Earlier this month, Tipping Point announced that their Zero Day Initiative (ZDI) will start publishing vulnerability details no later than six months after the flaws are submitted to the program. According to the announcement, the policy update makes ZDI one of the first “vendor-agnostic research organizations to impose a time limit on vulnerability disclosure cycles.”
In each of the three policy examples, the research teams making the disclosure will do everything they can to work with the impacted vendor. If more time is needed, there can be exceptions made, but this will not be the norm. However, one vendor simply doesn’t agree with fixed timelines.
“Some will say that we take too long to fix our vulnerabilities. But it isn't all about time-to-fix: Our chief priority with respect to security updates is to minimize disruption to our customers and to help protect them from online criminal attackers,” Mike Reavey, the Director of the MSRC said in a blog post before BlackHat last month.
“But why don't we commit to fixed timelines? Because it is important to consider the overall customer risk when focusing on updating software for security issues. Most security updates released by the MSRC will be rapidly deployed to hundreds of millions of systems worldwide helping to protect customers from attacks in a very short timeframe,” he explained.
“And the software being updated is being used by hundreds of thousands of applications on all sorts of hardware in all sorts of scenarios. So it is imperative that the update has been rigorously engineered and tested in order to avoid creating any type of disruption to these systems.”
Around the same time that Google made their announcement on disclosure, Microsoft announced CVD, or Coordinated Vulnerability Disclosure. CVD isn’t “a huge departure from the current definition of ‘responsible disclosure,’ Microsoft said, “we would still view vulnerability details being released broadly outside these guidelines as putting customers at unnecessary levels of risk.”
“CVD does allow for more focused coordination on how issues are addressed publicly…However, we fundamentally believe (and our experience over the last 10 years has shown) that once vulnerability details are released publicly, the probability of exploitation rises significantly. Without coordination in place to provide a security update or tested workarounds, risk to customers is greatly amplified.” [Source]
With that said, we emailed three questions to HD Moore to get his opinions on the new era of disclosure. We’ve posted his responses on page two, un-edited, and we welcome comments on them.
If you are a security vendor, IT professional, security enthusiast, or just have an opinion on the disclosure debate, email us at firstname.lastname@example.org and share your thoughts. We only ask that you grant us permission to use them in future articles on the subject.
The Tech Herald (TTH): ZDI, Microsoft, Google, and now Rapid7, are announcing changes to disclosure policies. Yet, while close, they are not the same. Is this a good or a bad thing from your view point?
HD Moore (HD): Each of these companies is in a different position; ZDI is a division of TippingPoint, which was bought by 3Com, which was bought again by HP. In addition to vendor relationships at the HP and 3Com levels, TippingPoint is also part of the MAPP program.
This program, managed by Microsoft, offers early access to vulnerability details for vendors of security solutions. By drawing a line in the sand, this is placing the ZDI department in a position that is sometimes at odds with the rest of the organization's business relationships. Due to these constraints, a 6-month timeframe may make more sense to ZDI than a shorter 60-day schedule.
Google has less dependence on other organizations and is less likely to back down in the face of intimidation by vendors seeking to prevent a vulnerability from being disclosed. A 60-day schedule works because they can stand behind it in the face of opposition.
Rapid7, as a small security company, takes a different approach to specifically address back pressure from vendors. While we have a 60-day disclosure schedule similar to Google’s, we coordinate the disclosure process through CERT, who serve as a neutral third party between Rapid7 and the vendor whose vulnerability is being reported.
This relationship with CERT makes it harder for a large company to pressure Rapid7 into not disclosing a vulnerability. 15 days after Rapid7 contacts the vendor, we share this information with CERT, which in turn release an advisory 45 days later. While CERT has a provision for extenuating circumstances, this card can only be played so often by affected vendors.
TTH: How are researchers impacted by the new policies on disclosure used by the previously mentioned companies?
HD: Fixed disclosure schedules are great for researchers; they provide a clear timeline for when a vulnerability will become public, and ensure that both the vendor and the reporting organization can prepare for this release.
If fixed disclosure schedules become the norm, we will likely see a surge in bounty programs, with the caveat that vulnerabilities purchased under a bounty agreement are not bound by a fixed schedule. Paying researchers to improve other people’s products is never a bad thing.
TTH: In your opinion, can you explain the pros and cons of disclosure, as you have seen in your career?
HD: The consistent argument against disclosure is that instead of making the vendor responsible for the problem, it shifts the burden onto the end users of the affected product.
This argument makes the assumption, however, that the researcher and the vendor are the only people in the know about a particular flaw. Again and again, we see instances where a vulnerability was found in the wild, but had already been reported by a researcher that was willing to work with the vendor.
What one researcher finds, another, with less benign motives, may also discover. The core issue is that the product has a security flaw; debating about the correct disclosure process shouldn’t take away from the fact that the vendor is indeed responsible for anyone exploiting a problem in their product.
The argument for disclosure is simple; the more the end user knows about the problem, they better they can defend against it. With the sheer number of Zero-Day vulnerabilities turning up in the wild, most organizations already know how to handle vulnerabilities with no fix available.
You can bet that these customers will demand a fix from the vendor and that the vendor will do their best to meet these expectations. In short, disclosure of a bug always results in a fix being released as quickly as possible.