IMPORTANT: CVE - Common Vulnerabilities and Exposures?

["Steven M. Christey" <coley@linus.mitre.org>]

As the recent discussions on the DEFINITION content decision indicate,
the term "vulnerability" is prone to terminological debate.  We
propose a new term "exposure" to allow us to move forward from these
debates, and rename the CVE accordingly to refer to "Common
Vulnerabilities and Exposures."

At least two different definitions of vulnerability have arisen and
been discussed.  There appears to be a universally accepted,
historically grounded, "core" definition which deals primarily with
specific flaws that directly allow some compromise of the system.
Along these lines, Gene Spafford has expressed concerns that any
loosening of the definition may result in the term being coopted in
much the same way as "hacker" has.  (Note that a cursory review of
*Bugtraq postings indicates that the term is *not* currently "misused"
on these lists, perhaps due to pre-posting editing suggestions by Russ
and Elias?  On the other hand, other Board members have mentioned
cases where a constituent has used the term in a way that the Board
member did not agree with.)

On the other hand, there is the "inclusive" definition, which includes
things that don't directly allow compromise, but could be an important
component of a successful attack.  For example, some have argued for a
definition of vulnerability as "a feature of a computer system that
permits or constitutes a violation of a reasonable security policy."

Since reasonable security policies differ from site to site (and
machine to machine), it is clear that this definition would include
things that would not be covered by the "universal" definition,
e.g. finger on a boundary machine.

The Board has tried to come up with different terms to discriminate
between these universal and inclusive "vulnerabilities."  "Risk" and
"policy violation" could be useful, except they are fairly general and
encompass both universal and inclusive "vulnerabilities."  We've seen
modifiers to the vulnerability term itself, e.g. "environmental
vulnerability" or "contingent vulnerability" or "macrovulnerability,"
but they still have the term "vulnerability" in them.

We suggest that the Board adopt the term "exposure" to refer to these
contingent/environmental vulnerabilities.  Loosely defined, an
"exposure" is a feature or state in a system that is not a "universal
vulnerability" in itself, but allows a violation of a reasonable
security policy.

Consider running a service like finger.  By design, it provides useful
information (account names, etc.) that could help an attacker to
perform password guessing.  Some reasonable security policies for
certain systems require that finger should not be run, and as such the
presence of finger is an exposure.  Another exposure might be a system
that accepts dialups to its modem while it's also connected to an
internal network.  A shopping cart program whose configuration
inadvertently releases private customer data would be considered an
exposure, since an e-commerce site's security policy is likely to
consider this a concern.  Even running a web server is an exposure,
since it opens the system to many potential CGI attacks (or other
attacks) that could successfully compromise the system.

The term "exposure" is not overly used in this community.  It
effectively indicates that something is a "risk" without going so far
as to label it a "vulnerability."

Elias Levy had suggested that we change the name of the CVE and call
it something else, since MITRE intends for the CVE to cover both
vulnerabilities and exposures.  We propose doing just that.  We can
keep the CVE acronym, but call it "Common Vulnerabilities and
Exposures" instead.  Thus the "vulnerability" term will not be diluted
by the CVE name itself.

We should defer discussion of the mechanism for discriminating between
vulnerabilities and exposures until after the CVE's initial public
release.  While there are several approaches that could be taken to
address this (e.g. extending CMEX by implementing the "universal"
attribute or something similar), each approach will require some time
to evolve.  The concept itself is relatively new, and it could impact
how the Editorial Board performs some of its tasks.

Let's concentrate on validating the remaining draft CVE entries
(whether they are vulnerabilities or exposures), adapt the DEFINITION
content decision using this new terminology, then move on to the task
of ACCEPTing 300 CVE entries by the big splash at SANS.

Comments?


- Steve and Dave