Full Disclosure mailing list archives
Creating a publicly maintained vulnerability database
From: full-disclosure () lists netsys com (Steven M. Christey)
Date: Fri, 19 Jul 2002 16:42:13 -0400 (EDT)
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
Current thread:
- Creating a publicly maintained vulnerability database Steven M. Christey (Jul 19)
- Re: Creating a publicly maintained vulnerability database Pascal Meunier (Jul 19)
- <Possible follow-ups>
- Creating a publicly maintained vulnerability database H D Moore (Jul 19)
- Creating a publicly maintained vulnerability database full-disclosure () lists netsys com (Jul 19)