Re: CD PROPOSAL: DEFINITION - Interim Decision 8/23

[Stuart Staniford-Chen <stuart@silicondefense.com>]

"Steven M. Christey" wrote:

> 
> Content Decision: DEFINITION (Use "Inclusive" Vunerability Definition)
> ----------------------------------------------------------------------
> 
VOTE: ACCEPT
> 

My rationale is this: consider the example of a vulnerability in a firewall
which only involved one rule primitive that might or might not appear in the
firewall rules of a particular organization depending on its security
policy.  (I'm thinking, suppose there was a bug in the "keep state" feature
of ipfilter.  A particular instance of an ipfilter firewall might or might
not have a problem depending on its rules).  It appears to me that this would
be an "inclusive" vulnerability according to the definitions below.  But I
definitely think it should be a CVE vulnerability.

Note: I find the term "inclusive vulnerability " unclear.  I would suggest
that "contingent vulnerability" would be a better and clearer counterpoint to
"universal vulnerability".

Stuart.


> (Member may vote ACCEPT, MODIFY, REJECT, or NOOP.)
> 
> Short Description
> -----------------
> 
> The CVE uses an Inclusive vulnerability definition, but CMEX indicates
> whether each entry is also a Universal vulnerability.  Editorial Board
> members must therefore vote on candidates in accordance with the
> Inclusive vulnerability definition.
> 
> Definitions
> -----------
> 
> A "universal" vulnerability is one that is considered a vulnerability
> under any commonly used security policy which includes at least some
> requirements for minimizing the threat from an attacker.  (This
> excludes entirely "open" security policies in which all users are
> trusted, or where there is no consideration of risk to the system.)
> 
> The following guidelines, while imprecise, provide the basis of a
> "Universal vulnerability definition."  A Universal vulnerability is a
> state in a computing system (or set of systems) which either:
>   - allows an attacker to execute commands as another user
>   - allows an attacker to access data that is contrary to the
>     specified access restrictions for that data
>   - allows an attacker to pose as another entity
>   - allows an attacker to conduct a denial of service
> 
> An "inclusive" vulnerability is not a universal vulnerability, but it
> may be considered a vulnerability under at least some commonly used
> security policies.
> 
> Rationale
> ---------
> 
> Discussions on the Editorial Board mailing list, and during the CVE
> Review meetings indicate that there is no definition for a
> "vulnerability" that is acceptable to the entire community.  However,
> there appears to be a "minimal" definition of vulnerability which is
> common to all definitions.  In general, the "minimal definition" is
> strongly advocated by those with an academic perspective, while many
> of those who represent operational constituencies (e.g. tool vendors
> or response teams) advocate an approach that has a less stringent
> definition, since the term is broadly used by the constituencies that
> they serve.
> 
> In accordance with the original stated requirements for the CVE, the
> CVE should remain independent of multiple perspectives.  Since the
> definition of "vulnerability" varies so widely depending on context
> and policy, the CVE should avoid imposing an overly restrictive
> perspective on the vulnerability definition itself.  Therefore, the
> CVE should not use a "universal" vulnerability definition that is
> acceptable to all, but instead use an inclusive definition.
> 
> There is a good use for both definitions, however.  But maintaining
> completely separated enumerations is not feasible.
> 
> In recognition of the utility of a "universal" vulnerability
> definition, CMEX should contain an attribute which indicates whether a
> vulnerability is "universal" or not.  Voters for individual candidates
> may identify whether they believe a candidate is a "universal"
> vulnerability; acceptance of a candidate by all voters implies
> universality.
> 
> Advocates of a "universal" vulnerability definition can easily extract
> the appropriate portion from the CVE, while allowing the CVE to be
> used by those who need a more inclusive definition.  Thus the CVE can
> adequately serve both "universal" and "inclusive" advocates.  To take
> the opposite approach, i.e. to only include universal vulnerabilities,
> would only adequately serve "universal" advocates.
> 
> Examples
> --------
> 
> Examples of universal vulnerabilities include:
>   - phf (remote command execution as user "nobody")
>   - rpc.ttdbserverd (remote command execution as root)
>   - world-writeable password file (modification of system-critical
>     data)
>   - default password (remote command execution or other access)
>   - denial of service problems that allow an attacker to cause a Blue
>     Screen of Death
>   - smurf (denial of service by flooding a network)
> 
> Examples of inclusive vulnerabilities include:
>   - running services such as finger (useful for information gathering,
>     though it works as advertised)
>   - inappropriate settings for Windows NT auditing policies (where
>     "inappropriate" is enterprise-specific)
>   - running services that are common attack points (e.g. HTTP, FTP, or
>     SMTP)
>   - use of applications or services that can be successfully attacked
>     by brute force methods (e.g. use of trivially broken encryption,
>     or a small key space)

-- 
Stuart Staniford-Chen --- President --- Silicon Defense
                   stuart@silicondefense.com
(707) 822-4588                     (707) 826-7571 (FAX)