Re: The Common Vulnerabilities and Exposures taxonomy

[Adam Shostack <adam () homeport org>]

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.
| smith () securecomputing com
| "Internet Cryptography" at http://www.visi.com/crypto/

-- 
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume