[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CD PROPOSAL: HIGHCARD (Interim Decision 8/24)
accept -----Original Message----- From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG] Sent: Tuesday, August 17, 1999 5:52 PM To: email@example.com Subject: CD PROPOSAL: HIGHCARD (Interim Decision 8/24) Please vote on this pervasive content decision using the space provided below. This content decision is scheduled for Interim Decision on August 24. While High Cardinality has been the subject of some debate, I believe that adding the concept of "innumerability" limits the scope of high cardinality decisions to poorly understood or impossible-to-list vulnerabilities; this decision also provides the Board with the option to make exceptions. The use of Dot Notation (DOT) further mitigates the concern for using a higher level of abstraction based solely on concerns with respect to high cardinality. - Steve Content Decision: HIGHCARD (High Cardinality, Innumerable Vulnerabilities) -------------------------------------------------------------------------- VOTE: (Member may vote ACCEPT, MODIFY, REJECT, or NOOP.) Short Description ----------------- In some cases, a particular "class" may have so many vulnerabilities that it will cause a significant increase in the number of entries in the CVE (High Cardinality). If those vulnerabilities cannot be enumerated (Innumerable), then they are combined into a single higher-level vulnerability. Definitions ----------- For general guidance, any "class" of more than 100 vulnerabilities may be considered High Cardinality, unless that class is well-understood and accepted by the community (e.g. "buffer overflow.") The vulnerabilities in a "class" may be considered Innumerable if there are no well-defined ways to distinguish between the vulnerabilities, or if they are of a theoretically infinite cardinality. Rationale --------- High cardinality vulnerabilities can dominate the CVE, reducing the usefulness to the sysadmin. They can skew quantitative comparisons between databases and inherently bias the comparisons towards vulnerability databases that use high cardinality vulnerabilities extensively. In addition, they can increase the overhead for the maintenance of the CVE, as well as maintenance of mappings from databases to the CVE. High cardinality vulnerabilities are especially risky for vulnerabilities that do not have a well-understood language for describing them, e.g. configuration problems. Often, these types of vulnerabilities are also Innumerable. In some cases, the Editorial Board may agree that it makes conceptual sense to specify individual vulnerabilities, even if they are high cardinality. The Board should make these considerations on an ad hoc basis. Examples -------- The set of all "system-critical" files in Unix is Innumerable. Certain files can be identified, e.g. password files, login scripts, or batch files, but often the specific configuration of a machine includes a large number of files that are unique to that machine. The set of all default passwords may be High Cardinality, but it is Enumerable, as the password itself (a) is known, and (b) can serve as the discriminator from other passwords. Thus it will be up to the Board to determine whether it makes conceptual sense to have a single, high-level vulnerability, or divide them into specific entries.