This morning, I read an interesting survey on the meaning of responsible disclosure conducted by Federico Biancuzzi. He did a solid job of pulling together the major players including software vendors, independent researchers and commercial vulnerability programs to solicit their opinions on what constitutes responsible disclosure.

Not surprisingly, vendors view responsible disclosure as "tell us and no one else", while researchers interpret it as "fix this as soon as possible". While I'm not sure that we need a survey to reveal that, I did find it an interesting read. People often complain that the vulnerability disclosure process is broken and badly in need of repair. I disagree. I think that it works just fine. Researchers and vendors will never agree on what constitutes responsible disclosure, that much is certain. We're wasting our time by trying to find the universal formula. At present, we have what I call the "invisible hand of responsible disclosure" regulating the process. Vendors are kept in check by a growing army of brilliant researchers with the ability to uncover vulnerabilities that the developers themselves were unable to discover. For the most part, researchers are driven by their own curiosity and are a powerful force that cannot be ignored. On the other hand, researchers are kept in check by legal threats from vendors and flames from their peers for mishandling an issue. While I'm certainly not a proponent of a vendor taking legal action to suppress information sharing, the mere threat of such activity does cause researchers to think about the way that they choose to handle information. Nature always seeks equilibrium and in the security industry it is the ongoing researcher vs. vendor battle that keeps everyone honest (or at least on their toes).

However, nothing is ever perfect and while I state that the current system works, there are failures on all sides that constantly work to break the equilibrium. Below is my top 10 list, hilightling the guilty party causing each problem, along with my proposed solution:

Top 10 Failures of Current Vulnerability Disclosure Practices

1. Lack of communication with researchers [vendors]
Problem - Vendors too often feel that communication with the researcher should end once a vulnerability has been reported to them. They fail to realize that this transfer of information does not constitute a transfer of ownership. The researcher made the discovery and has a right to know what is done with it. Researchers often complain that vendors do not produce patches in a timely fashion. Vendors counter by arguing that it takes longer than most people think to create a patch.
Solution - Break down the communication barriers. Provide the researcher with a weekly status update so that he better understands the delays and is less likely to go public before a patch is available.
2. Failure to provide credit where credit is due [vendors]
Problem - Fortunately, this is becoming a non-issue but there are still vendors that either refuse to provide credit to the researcher or do not take adequate care to ensure that the appropriate people are credited. Many researchers work their magic simply for love of it. All they ask is that they be recognized for their efforts. Not doing so only serves to increase the likelihood that they'll go public before a patch is in place. If they control the disclosure process, they don't have to worry about not receiving credit.
Solution - Give 'em a pat on the back for making your product better. It's the least you can do.
3. Unwillingness to provide interim statements [vendors]
Problem - Most vendors remain uncomfortable commenting on any vulnerability until a fix is in place. Microsoft broke with this practice about a year ago when they started commenting on current issues by posting on the MSRC blog and posting security advisories prior to the release of the final security bulletin. This was an important change. While it didn't necessarily provide the public with the fix that they're looking for, it did provide reassurance that the vendor is aware of the situation and is doing something about it. Take a look at the ongoing situation regarding vulnerabilities in wireless drivers disclosed by David Maynor and Johnny Cache at BlackHat this year. Maynor and Cache don't feel that they're able to release full details of the exploit until a vendor patch is available, and as a result, they're being bombarded by angry end users accusing them of over hyping the vulnerability. If Apple and any other affected vendors were willing to step forward and provide an interim statement updating the public on the status of a fix, we could avoid this ugly mess. Unfortunately, that doesn't appear likely as Apple was quoted in Biancuzzi's article stating that "Apple does not disclose, discuss or confirm security issues until a full investigation has occurred and any necessary patches or releases are available".
Solution - Follow Microsoft's lead.
4. Timeliness of patches [vendors]
Problem - Vendors will always argue that producing a patch takes time. I agree, but that argument falls on deaf ears when patch development exceeds six months time. Just look at the Zero Day Initiative's list of upcoming advisories to identify those vendors that are dragging their feet.
Solution - Apply appropriate human and financial resources the patch process to ensure that fixes arrive in a reasonable timeframe. See solution #1 and #3 in the interim.
5. Robustness of patches [vendors]
Problem - Nothing is more frustrating than waiting a lengthy time for a patch only to find that it doesn't work or has introduced new vulnerabilities. Look no further than MS06-042 for and example of a fix that produced a break. The patches included with this advisory led to the release of Microsoft Security Advisory (923762) which addresses a long URL buffer overflow vulnerability that was introduced by the initial patch.
Solution - Similar to solution #4, but this time, appropriate human and financial resources need to be applied to the QA process.
6. Regular release of patches [vendors]
Problem - The majority of vendors continue to release patches when they are available. While that's not necessarily a bad thing as end users want a fix as soon as possible, it does cause problems when vendors choose to release vulnerability details at midnight on the Friday preceding a long weekend. Given the global society that we work in, there is no 'good time' for a patch release when everyone is at work and ready to react to it. In October 2003, Microsoft introduced a monthly patch cycle whereby all new patches are released on the second Tuesday of each month at approximately 1pm EST. In my discussions with end users, overall this change has been applauded. While sys admins may not know what is going to be patched or how bad it will be, they do have the ability to prepare for the event by ensuring that appropriate staffing is in place. In January 2005, Oracle switched from a monthly patch cycle to a quarterly cycle. While this provides the same predictability as Microsoft's process, in my opinion, three months is too long to wait for a critical patch. A monthly cycle seems to be a good compromise between timely patch release and predictable release dates.
Solution - Once again, follow Microsoft's lead.
7. Fear of being 'scooped' on a discovery [researchers]
Problem - Researchers work hard to uncover vulnerabilities and understandably want to be recognized for their efforts. That should not however be used as an excuse for publishing vulnerability details without contacting the vendor simply because you didn't feel that they'd do anything about it.
Solution - Patience is a virtue. Give the vendor the opportunity to do the right thing by crediting you in their advisory. If they fail to do so, you have every right to go public with the failure.
8. Joy of 'shock value' [researchers]
Problem - A good vulnerability makes a big splash, a good vulnerability without a patch makes a bigger splash and an honest to goodness script kiddie exploit for an 0day can clear the pool. Yes, you will probably get your 15 seconds of fame by releasing an 0day but building your reputation by providing solutions as opposed to problems is a better long term game plan.
Solution - See solution #7. Patience is a virtue.
9. Over hyping the severity of a flaw [researchers]
Problem - All too often I see researchers create vulnerability reports that would be better off published in the National Enquirer than on a security site. When reviewing the latest advisories this morning I saw severity rankings that included terms such as "high", "dangerous" and "very dangerous". These were all in reports for products that I'd never heard of.
Solution - A vulnerability report should state the facts. If you feel the need to include a severity ranking, use CVSS to remove your bias. Let those affected by the issue determine just how severe it is.
10. Overuse of the term responsible disclosure [both]
Problem - The term "responsible disclosure" has been beaten to death and still doesn't have any meaning. Let's see just how many times the term "responsible disclosure" was used in Biancuzzi's article:
- "People who work with Apple in the responsible disclosure process are credited in advisories for reporting the issue" - Apple
- "We encourage security researchers to follow responsible disclosure practices..." - Douglas Merrill, VP of Engineering, Google
- "Microsoft continues to encourage responsible disclosure of vulnerabilities..." - Microsoft
- "...we encourage and work with researchers who use what has come to be known as responsible disclosure." - Crispin Cowan, Security Architect, Novell
- "Oracle encourages independent security researchers to follow a 'responsible disclosure' policy." - Oracle
- "I strongly encourage all independent researchers...to follow a practice of responsible disclosure." - Terri Forslof, Manager of Security Response, ZDI
Solution - There is no definition of responsible disclosure. Do us all a favor and replace "responsible disclosure" with "our disclosure policy".

"Can't we all just get along?" - Rodney King

- michael