[CVEPRI] Proposal: An open letter on responsible disclosure
Some of the disagreements on this list are starting to escalate into
personal unpleasantness. Please remember that this list is public,
and while there are good points on all sides, we should try to be
respectful. Some Board members are starting to express their
displeasure with the tone of some emails. It would be damaging to the
Board as a whole if I were forced to strictly moderate posts to this
list. On the other hand, this is an important debate that the public
should be able to view.
Here's a concrete proposal for all members of the Board to consider.
Let's see if we can work together on things that we all agree about.
(I haven't heard any complaints about pursuing this "off-topic"
subject, so I assume Board members are OK with continuing to pursue
the matter on this list. I do believe that it helps CVE in the long
There appears to be agreement with respect to certain aspects of the
vulnerability disclosure problem. In a later email, I will take all
the emails and attempt to summarize them, highlighting the
commonalities and differences.
I propose that we create an "open letter" to everyone who discloses
vulnerabilities. We could highlight what the problems are, and
propose some basic guidelines for both discoverers and vendors. I've
been thinking of the concept as "responsible disclosure." This open
letter doesn't necessarily have to go through as many revisions as the
CyberCrime treaty statement, and we don't have to make this a
statement from the Editorial Board.
A coordinated announcement from well-known full-disclosure *and*
"other-disclosure" advocates, with wide distribution across the
*Bugtraq mailing lists and "media outlets," could go a long way
towards addressing some of the problem. If the participants/signers
wish to tie this in with the upcoming vulnerability summit, then I
could act as liaison for that summit.
Here's my first draft. Comments from all sides of the fence are
welcome and strongly encouraged. Board members have been challenged
to offer solutions, so here's a chance for many high-impact people to
- Security vulnerabilities appear in a large percentage of computer
software. Therefore they are a universal problem across the IT
- As the number of reported vulnerabilities has increased, the
technical quality of those reports has decreased.
- Some disclosers have motives besides improving the overall state of
security. This in turn affects how the discloser interacts with the
vendor, and how the discloser publicizes the problem.
- Some vendors are either unwilling, or unable, to publicly disclose
that vulnerabilities in their products have been detected.
- At least half of all reported vulnerabilities are announced before a
fix is available.
- The resulting "noise" makes it difficult for system administrators,
vendors, and security personnel to get good enough information to
improve the overall state of IT security.
- Previous efforts at providing high-level guidance have not reached
the level of awareness and adherence to mitigate these problems [I'm
thinking here mostly of RFP's disclosure policy].
Proposed "Best Practices"
We can probably agree that:
- Disclosers should work with the vendor to ensure that a fix is
available before announcing the vulnerability [but what should the
discloser do if the vendor doesn't cooperate?]
- Disclosers should involve a neutral third party in communications
with the vendor. That third party can serve as a mediator and an
objective witness to activities that take place.
- Disclosers should produce an accurate, clear report.
Many of us might agree that:
- Vendors should be clear in notifying their customers - and security
personnel who may "represent" those customers - as to: (a) their
level of awareness of well-publicized vulnerability reports; (b)
*precisely* which vulnerabilities they are aware of; and (c) whether
patches are available.
- Disclosers and vendors should use commonly accepted references for
specifically identifying which vulnerabilities are being disclosed
(e.g. *Bugtraq posts, Bugtraq ID and/or CVE candidate number, etc.).
[While this may appear self-serving, I find time and time again that
it is extremely difficult to distinguish between vulnerability
reports from different sources without a common reference.]
- If the discloser has acted responsibly, then the vendor should
properly provide credit to the discloser.
"Best Practices" Support Mechanisms
Some mechanisms that may support some of these "best practices" are:
- Disclosers could use vulnerability reporting services to interface
with vendors and to have a neutral third party to mediate.
- A trusted third party could provide a mechanism for hashing and
time-stamping a vulnerability report to encourage some disclosers to
delay reporting a vulnerability publicly until a patch is available.
- Extensions should be made to existing vulnerability databases, or a
separate database should be created, which tracks vendor and
discloser "status" for the reported item. [E.g.: did the discloser
use a service and/or follow a documented "best practice" to disclose
the vulnerability; did the vendor use "best practice" to respond to
it. This data, in turn, could be used to apply pressure to those
who aren't acting responsibly.]
Problems that are not resolved by this approach include:
- Disclosers with purely malicious intent, or who disclose
vulnerabilities only for name recognition or "fame," will not follow
guidance for responsible disclosure. Disclosure "Time-stamping"
might be sufficient for those who seek name recognition.
- How to deal with vendors who refuse to disclose or acknowledge any
- If someone does not perform responsible disclosure, but they are
strongly criticized by others, then it may force their information