Message-ID: <p05010411b95e2c29934d@[128.10.243.30]>
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Subject: Re: Creating a publicly maintained vulnerability database

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

Powered by blists - more mailing lists