Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Creating a publicly maintained vulnerability database
From: full-disclosure () lists netsys com (Pascal Meunier)
Date: Fri, 19 Jul 2002 16:17:36 -0500

We have just overhauled our cooperative vulnerability database 
(fixing many bugs), adding an exploit section with IDS rules, and 
modifying it to allow the use a moderation process instead of a 
3-reviewer process.  What is interesting about it is that anybody can 
improve a record by working on a copy and submitting it so that it 
will supersede the original.  As a basis it imports CVE information 
daily but it is not bound by it.  One drawback to it is that 
operational policies have not been clearly defined;  another is that 
there currently isn't enough information in it.

Please have a look;  accounts are and will remain free.  We will keep 
working on it.  Feel free to make suggestions too, for features or 
operational policies.  At this point, I would very much like to know 
what else it would take for the community to get involved in it, and 
I am willing to share the stewardship with interested individuals and 
companies.  It is publicly accessible at:

https://cirdb.cerias.purdue.edu/coopvdb/public/

Cheers,
Pascal Meunier
Assistant Research Scientist, CERIAS



At 4:42 PM -0400 7/19/02, Steven M. Christey wrote:
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

-- 
Pascal Meunier, Ph.D., M.Sc.
Assistant Research Scientist,
CERIAS
Purdue University


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]