Russ and Scott have commented on the taxonomy issue, so I'll add that the CVE is also not a database. The closest analogy is either a multi-lingual dictionary or the latin name for a species (although this is a bad analogy when you dig deep.) Lets say you want to know the French for 'Hello' You get a French-English dictionary, and it will say salut, bonjour, and maybe something else. This is useful, even though its not really precise. Similarly, what CERT calls CA-98.11.tooltalk maps onto what ISS calls tooltalk and aix-ttdbserver. Both map into CVE-1999-0003. CVE makes no claim to be a database: It doesn't contain enough data, and its clearly incomplete. Its intended to help map from one language to the next. To criticise it for not containing OS information is to ask too much of it. (Matt Bishop's DOVES database might be what you want.) The latin name analogy is that for certain common organisms (e. coli), the name is standardized, and you can lookup things about e. coli. You can also look things up about h. sapiens, but there are other names for homo sapiens that might help the average joe at the library. This analogy fails because the latin names are actually the last two components (genus and species) of the organisms' taxonomic classification. With CVE, there is no accepted taxa of vulnerabilities, and thus, no analogy for the genus and species. I am very enthusiastic about the CVE not only because it will allow tools to talk to each other, but has the potential to allow databases to be cross referenced based on a common key. If DOVES and your private database both include CVE information, you can automate the process of pulling data from each. That is a critical part of starting to share information about vulnerabilities in a structured way. Such sharing of information -- being able to agree on what you're talking about -- is a critical precursor to doing a scientific analysis of the problems that exist. (You can do science without it, but its hard. As to your specific situation, if your book is at the level of Internet Crypto, I suspect that the CVE is the wrong level of abstraction for you. Adam On Wed, Oct 20, 1999 at 10:01:43AM -0500, Rick Smith wrote: | One reason I was curious about the CVE database is that I'm trying to | figure out how it might work into varous books I'm working on (a new one on | authentication and an update of "Internet Cryptography"). | | Now that I've looked closer, I realize CVE is NOT a taxonomy, it's simply | intended as a listing of vulnerabilities or "exposures" at a particular | level of abstraction. (Since people tend to think of "vulnerabilities" as | exploitable weaknesses, an "exposure" is a weakness that may or may not be | exploitable, depending on circumstances). | | Clearly, I can use the database as a representation of identified | vulnerabilities. It's good to have a list of known problems to work from. | The descriptions aren't always very detailed, but they generally refer to | other sources and reports. So it's a good piece of reference material. If | I'm wondering how many different buffer overflows have been reported (so | far), it's a good place to work from. | | Further, there's the question of whether it's worthwhile to associate CVE | identifiers with vulnerabilities I talk about within the book. It's | probably a Bad Idea. | | Don't get me wrong -- I see some real value in what they're doing. But I | need to hit a certain level of abstraction and talk about "buffer | overflows" or "buffer overflows in Unix Internet servers." The CVE talks | about "buffer overflows in ping" and has separate identifiers for each | affected software component. That's too low a level of detail for my use. | | | Rick. | smithat_private | "Internet Cryptography" at http://www.visi.com/crypto/ -- "It is seldom that liberty of any kind is lost all at once." -Hume
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:25 PDT