Message-ID: <200207192042.QAA24360@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Creating a publicly maintained vulnerability database

Jay D. Dyson said:

> 	Look, I have nothing against someone trying to make a buck.  That
> is the cornerstone of the capitalist system.  What burns my biscuits is
> that the monolithic security companies are not making this money off their
> own efforts[1], but by leeching off the egalitarian contributions of those
> who possess a skill set the businesses are not willing to pay for.

With organizations like CERT/CC projecting 4,000+ vulnerabilities this
year alone, the amount of research and quality-checking that is
required to maintain a good vulnerability database is growing
prohibitive, even if most of the vulnerabilities were discovered and
announced by many people in the community.

As suggested by others, a publicly maintained vulnerability database
is a possibility, but it would need a large-scale community effort to
populate and maintain, and there would be issues of quality control.

Maintaining a vulnerability database also requires some different
skills than vulnerability research or system administration:

- a stronger emphasis on writing for multiple audiences (technical
  details and high-level summaries)

- identifying different technical areas and finding/keeping skilled
  people to cover them (e.g. crypto, Linux kernels, CGI, programming
  languages, etc.)

- defining what will be in the database (this was an issue in the
  early days of CVE because everyone has different definitions of
  "vulnerability," and it's still an issue to some degree)

- ironing out details like workaround and fix information (even
  determining whether the vendor has fixed the problem can be a
  challenge; researcher-suggested patches can be broken; some
  workarounds aren't feasible)

- trying to distinguish between closely related vulnerabilities (is
  there one vulnerability or two?  Did vendor X and Y really fix the
  same issue?  Did vendor W's fix really address researcher Z's report
  from two months earlier?)

- deciding on a severity metric (IMHO, high/medium/low must die)

- getting consistent terminology (your XSS is not my XSS (or CSS)!
  Same with remote/local, directory traversal, etc.)

- ensuring accuracy of information (which is sometimes problematic
  even in "full disclosure" instances)

- actually validating whether the reported vulnerabilities are real or
  not (a daunting challenge for anything but the most commonly
  deployed products and configurations)

- then designing, implementing, and maintaining the databases and the
  server(s) that support it.



Chris Wysopal said:

>Even so a completely non-corporate and free vuln database would be
>something good for the community.

NIST's ICAT database (http://icat.nist.gov) is freely available for
download.  It is built on top of the CVE list.  Unfortunately, that
means that some of CVE's challenges pose difficulties for ICAT,
e.g. with respect to CVE's delays in making candidate numbers
available after an issue has been disclosed.  (BTW, we're focusing on
improving our timeliness, which should improve noticeably in the
coming months.)


If everyone is serious about building and maintaining their own open
vulnerability database, then consider using the following resources:

1) Working group reports from the 2nd vulnerability database workshop
   at Purdue CERIAS, January 1999, especially the appendices.

   There is some good discussion regarding issues in creating "open"
   or "federated" vulnerability databases.

   http://www.cs.purdue.edu/coast/papers/99-06.ps

   (Google offers this file in text format, but the document structure
   is lost a little.  http://citeseer.nj.nec.com/meunier99final.html
   may provide alternate formats)

2) Purdue CERIAS has done some followup work in trying to create a
   public vulnerability database.

   "Sharing Vulnerability Information using a Taxonomically-correct,
   Web-based Cooperative Database"

   https://www.cerias.purdue.edu/papers/archive/2001-03.pdf



Steve Christey
CVE Editor

Powered by blists - more mailing lists