Yes I am beating this dead horse, why do you ask?
Dino at Matasano posted some great thoughts on vulnerability disclosure (here) the point of which calls into question the motivations of some researchers and states the need for a mechanism that enforces accountability and transparency into the vuln process. Suggesting an independent or objective 3rd party (there goes that word again – I ain’t mad at cha’ Thomas🙂 ) such an entity acting as a vuln broker would resolve the issue.
Anway I was reading through the comments having posted a question around how such a 3rd party would work and what the motivations would be for the various constituencies to participate and “ivan” replied that the situation will self-correct if a representative set of researchers and vendors pressured by end-users drive the needed transparancy and accountability.
I don’t think a viable 3rd party vuln broker or market self-correction will happen anytime soon. The reality is that researchers will continue to antagonise large vendors. Vendors will impede the process and not provide a process to deal with researchers furthering the antagonism and end users will blindly go on with the business of IT without exerting the neccessary market pressure.
One of the last research notes I wrote before leaving Gartner concerned responsible disclosure. Although I cannot post the full text, here are some excerpts from “Responsible Vulnerability Disclosure: Guidance for Researchers, Vendors, and End Users”, which echoes much of what ivan suggested the market should do. Bear in mind the audience includes non-technical, non-security folks so refrain with some of the “Captian Obvious” comments.
- Attackers looking to exploit vulnerabilities in IT will focus their efforts in the area in which a critical vulnerability may exist, increasing the potential that the vulnerability is identified and an exploit made available. Suggesting that a vulnerability exists in a vendors product, without naming the product or providing specifics can increase the risk of exploitation.
- When a vulnerability is publicly announced, attackers and researchers generally find more vulnerabilities in the product(s) or similar vulnerabilities in other products soon after.
- It is a common practice for hackers to reverse-engineer both patches to better understand how to exploit vulnerabilities, and this can be extended to security product signatures. Security vendors that provide “zero-day” protection for their clients, prior to release of a patch, can put the broader IT community at risk if they don’t take precautions.
- IT vendors that do not provide adequate information on the nature of a vulnerability will impact the ability of their user base to make decisions on how to proceed with a work-around, patch or deployment of a new version. This delays patching and increases risk.
- End-user IT organizations absorb most of the risk if disclosure is done irresponsibly, and they have limited influence over the process. Enterprises should not buy security products from companies that do not practice responsible disclosure. There are also situations that arise in which disclosure can and should impact how an organization reacts.
Guidance for Security Researchers
Provide all necessary information to the ISV and obtain a positive indication that the appropriate function within the vendor has received the information. An appropriate amount of time (typically at least 30 days) should be allowed for the ISV to respond before releasing any information, even information without details. If the vendor requests a reasonable amount of additional time (another four to six weeks), no information should be released. Work closely with the vendor to ensure a timely response and be prepared to publicly announce the vulnerability details when the vendors has provided a patch, work-around or software update, but not before. Exploit code should never be released.
Guidance for ISVs
Provide a well-publicized means of accepting vulnerability information from researchers, as well as a published policy for how your organization will respond and work with security researchers. Researchers that follow responsible reporting protocols should be credited when the patch is publicly released. ISVs have responsibility to their user base to provide adequate information that allows their clients to make the appropriate decisions about implementation of a work-around, distribution of a patch, or upgrade to a new version.
Guidance for End-User IT Organizations
There’s little that an end-user organization can do to affect who finds or discloses vulnerabilities. However, these events are recognizable in the press and through vulnerability information sources. Remember that no patch will be available. Organizations must respond to these occurrences by absorbing the available information as soon as possible and adjusting their controls — including reconfiguring firewall, intrusion detection system, intrusion prevention system, security information and event management, and network behavior analysis technologies — to detect suspicious behavior or block affected protocols if possible. Limit the use of affected applications where they are not mission-critical.
Organizations should not conduct business with vendors or security research companies that do not follow responsible disclosure. These entities must not be allowed to manipulate, intentionally or not, enterprise security postures.
Some third parties produce patches for popular software. These patches are typically available free or sold through services with the intent of filling the gap between disclosure and the availability of the vendor patch. Most of the organizations that produce these patches are also vulnerability research organizations, so there is an inherent conflict of interest. Gartner does not recommend using third-party patching for security issues. The cure may be worse than the disease: Third-party patches can create havoc in a large organization because of inconsistent quality, which may result in service or application disruption, limited ability to manage them remotely and the need to uninstall them when the vendor-approved patch is available. In the worst-case scenario, they may contain backdoors or other malicious software.
There is a lot more to it than that, but you get the idea…