|
[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
|
||||