[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Dot Notation Proposal WAS: Exploding CVE entries
Pascal Meunier wrote:
>
> Sounds fine to me, although the notation could be lighter, i.e., it could
> be understood that if a CVE entry has a list at the end like:
>
> 1. Digital Unix 3.0x, 3.2x, 4.0, 4.0a and products based on these
> 2. FreeBSD v prior to 2.1.6
> 3. HPUX 9.x, 10.00-10.20,
> 4. AIX 3.2, 4.1, 4.2
>
> then referring to CVE-1999-0128.3 means the vulnerability instance of
> CVE-1999-0128 in
> HPUX 9.x, 10.00-10.20.
Right!
Steve and I see 2 fundamentally different approaches
for implementing the dot notation. The difference hinges
entirely one what we mean by a CVE entry. These models are:
1) THE CERT ADVISORY MODEL - In this model, a CVE entry is
a high, "same attack" level description of a vulnerability.
The label for each CVE entry would be of the form CVE-DDDD-N
with no dot. In a manner similar to a typical CERT Advisory,
the description for each CVE entry would contain numbered
references to each known instance of the vulnerability
at the lower, "same codebase" level. Hence, a CVE number
of the form CVE-DDDD-N.x would refer to a particular instance
of the CVE entry CVE-DDDD-N.
2) THE CARD CATALOG MODEL - In this model, a CVE entry
is either a high, "same attack" level description of a
vulnerability or a low level, "same codebase" level
description. The label for each CVE entry would be
of the form CVE-DDDD-N.x where:
(x = 0) implies that the entry is a high level entry and
(x > 0) implies that the entry is a low level entry.
Clearly, the existence of an entry of the form CVE-DDDD-N.3
(a low level entry) would imply the existence of an entry of
the form CVE-DDDD-N.0 (the corresponding high level entry).
This model is somewhat akin to the old fashioned Title card
catalogs in a library where each card (corresponding to a
CVE entry) describes a particular instance of a title with
respect to edition information.
Speaking only for myself at the moment, I am somewhat
ambivalent as to which implementation scheme is preferable.
Since the 2 approaches are logically equivalent, I would
suggest that the decision should be based on a consideration
as to which scheme will allow better automated CVE referencing
and external db interoperability.
Thoughts? Preferences? Other suggestions?
Dave
--
=========================================================
David Mann || phone: (781) 271 - 2252
INFOSEC Engineer/Scientist, Sr ||
Enterprise Security Solutions || fax: (781) 271 - 3957
The MITRE Corporation ||
Bedford, Mass 01730 || e-mail: damann@mitre.org