RE: CD PROPOSAL: HIGHCARD (Interim Decision 8/24)

["Frech, Andre (ISSAtlanta)" <AFrech@iss.net>]

Are we still accepting discussion on this proposal? If so, I have some
questions and comments.

A type of potentially innumerable HIGHCARDs seems to lie in the
monotonically increasing list of certain types of vulnerabilities, as in the
'buffer overflow' class listed below (which has some possible solutions).
Another example could be the 'weak encryption' class, which as of last year
didn't include DES, but now does, and in the future would include more and
more algorithms (AES, anyone?)

I would propose an ad hoc decision of the board concerning the treatment
(inclusion, exclusion, or whatever other actions) of any of the 'slippery
slope' class of high cardinality issues that aren't high now, but might most
likely be large in the near future.

> 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.") 

Would a class such as 'buffer overflow' not be addressed by the 'Different
Function, Different Vulnerability' content decision? Or is this an issue
because the DFDV content decision is still pending in the voting stage?

Thanks for your patience and understanding.
=====================================
Andre Frech
X-Force Security Research
afrech@iss.net 

Internet Security Systems, Inc.
678.443.6241 / fax 678.443.6479
www.iss.net

Adaptive Network Security for the Enterprise
===================================== 


> -----Original Message-----
> From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
> Sent: Tuesday, August 17, 1999 6:52 PM
> To: cve-editorial-board-list@lists.mitre.org
> 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.
>