Re: Creating a publicly maintained vulnerability database

[full-disclosure () lists netsys com (Pascal Meunier)]

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