[CVEPRI] Proposal: An open letter on responsible disclosure

["Steven M. Christey" <coley@linus.mitre.org>]

All,

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
term.)

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
do so.


The Situation
-------------

- Security vulnerabilities appear in a large percentage of computer
  software.  Therefore they are a universal problem across the IT
  industry.

- 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
  vulnerability information?

- If someone does not perform responsible disclosure, but they are
  strongly criticized by others, then it may force their information
  underground.



- Steve