-----BEGIN PGP SIGNED MESSAGE----- As a member of the Editorial Board, and someone who serious debated the value of the CVE with Dave and Steve (of Mitre) before it got off the ground, I'd like to throw a little input into this thread. As Scott said, its not a taxonomy. A taxonomy infers a structure, and there is no structure to the CVE used outside of its own methods of presentation/searching. The number is, simply, an enumeration. We attempt to assign a unique value to a unique "thing" (thing, because we don't have a taxonomy which we can use to refer to the CVE entities). The "thing" may be an exploit, a vulnerability, a threat, risk, etc... It is NOT a Vulnerability Database, so does not include many of the things which VdB maintainers see as incredibly valuable information (signatures, codebase, tool names, etc...) The primary intent of the CVE effort is to provide everyone with a unique identifier which can be used when referencing anything to do with the particular "thing". So, for example; 1. A scanner may include the CVE number in the output of a scan. 2. The software vendor may include CVE number in their fix information, making it available to search engines. 3. On-line resources can include the CVE number in informational texts about issues. If I could go to Altavista and search on CVE-1999-0332 and get all information pertaining to a buffer overflow in NetMeeting, from its discovery announcement, what products can detect it, what tools exploit it, and all pertinent fix information, I'd be a happy camper. As it is, if I call it a buffer overrun, instead of a buffer overflow, I might very well exclude the majority of useful information about it due to the restrictions on search engines. When we get into things like Land, Boink, Bonk, Teardrop, etc... the idea should become even more obvious. While the press release may have embellished the hoped-for results of the effort somewhat, in my mind the CVE represents the first very real step towards formalizing the security sciences. As far as people not being willing to share information (Marcus' claim that NFR would have to put 500 new entries into the CVE for them to be able to map to it), so be it. I hosted what we called the "Balkan VdB Owners" discussion at the last CERIAS conference. We came up with many reasons why people would not want to share information. We also recognized, and the CVE Editorial Board was formed as a result of this recognition, that many vendors will claim to detect far more "vulnerabilities" than they actually do. The CVE Editorial Board's stated purpose is to determine whether or not a "thing" is merely a representation of an existing "thing", or in fact, something new. It may very well be that NFR knows of 500 more unique "things" than the combined members of the Editorial Board...however I suspect the number would probably be somewhat less after review. That said, there's the very real issue of "review". However, we, the CVE Editorial Board, certainly hope that scanner vendors will not try and market their products on unrevealed or undisclosed exploits or vulnerabilities. Its highly unlikely that any such "thing" will remain proprietary to a given vendor for very long anyway. Spaf is working on a public VdB, and of course there are seemingly hundreds of other VdBs around. We've had a tough time keeping people convinced that the CVE is not intended to replace any of these (or even rival them). Its hoped, however, that anyone who does maintain such a VdB will make an effort to incorporate the CVE numbers into their VdB, and provide a facility to search based on CVE numbers (where a search facility already exists). So if you take a moment and look past the press release, and reign in your ideas about what should be to what can we get done now, CVE will likely come as one datapoint in the progression of security science research. At least that's how I see it fwtw. FYI, I'm in the process of mapping my NTBugtraq archive messages against CVE numbers. Cheers, Russ - NTBugtraq Editor -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 iQCVAwUBOA34ehBh2Kw/l7p5AQGq2wP/dpCD8G3M1oLWYAJtCg+0QuzbYS+vDY/P wUh7y3x9sued6zoDP/JNRZ/GnzxUbc5d9OaKEHTg2mNSuISzqSbM17KjVA/SjV2+ +gC5A/NLK7uutuJaKYrW9894gkz2uRzsu7nq8Co3aJmDFbP6fi8tXIUcnHDiFie5 QCL677Lu+dc= =vlgt -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:23 PDT