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

[Adam Shostack <adam@netect.com>]

Accept, and a straw vote in favor of the terminology change to
'contingent'

Adam


On Tue, Aug 17, 1999 at 10:34:02PM -0700, Stuart Staniford-Chen wrote:
| "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)