[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about CVE to vendor mappings


Andre Frech asked:

>For example, "Windows NT 4.0 prior to Service Pack 4" involves many
>potential CVEs, possibly subsuming the CVEs in SP3, 2, and 1. How
>would a vendor handle these, considering that it is probably out of
>the scope of the CVE to reconcile these entries?

I believe it's out of the scope of the CVE to record such "high-level"
vulnerabilities.  Whatever the "level of abstraction" is that's
decided on, I believe that there shouldn't be any "higher-level" CVE
vulnerabilities that subsume others.  (I make an exception with
"GENERIC" category vulnerabilities, simply because of their usage in
recording discrepancies between a database and the CVE.  What we do
with GENERICs is a later topic for discussion, but I'll introduce an
example below.)

>I envision this question raising several points:
>
>- Can a vendor go about assigning multiple CVEs to a vulnerability or
>check outside of the framework of the CVE?

In almost all of the mappings I've created, I've had to make such an
assignment.  (As an example, mylog and mlog were always represented as
a single vulnerability in those databases, whereas my draft CVE
content decision required that they be split.)

In "Towards a Common Enumeration of Vulnerabilities," Dave and I
suggested using "mapping relations" to represent this discrepancy.  My
understanding of these relations has evolved somewhat since that paper
because now I've actually *done* some mappings, but the general logic
holds.

Consider a vulnerability database entry V, and CVE vulnerabilities C1
and C2.

  V SUBSUMES C1 and C2 when V includes both C1 and C2

  V is SUBSUMED BY C1 if C1 SUBSUMES V

These relations handle most of the discrepancies between a database
and the CVE (then consequently, between a database and another
database).  There's the ugly case where V might "intersect" a portion
of C1 and a portion of C2, but I haven't really seen that in practice.

In the case Andre quoted, then, "Windows NT 4.0 prior to Service Pack
4" would subsume a number of CVE vulnerabilities, but it would not
have its own CVE number.

However, I believe you'll need additional information when mapping.
Consider if the mapper can't decide whether V is really C1, or it's C2
- but they know it's not both.  (I had this problem when trying to do
a mapping from simple vulnerability lists in product literature.
"which rdist are they talking about here?"  etc.)  In this particular
case, I defined a GENERIC-MAP-UNKNOWN entry in the draft CVE to
represent the mapper's uncertainty.  Other such "modifiers" may be
necessary to describe the nature of the relationship between the CVE
and a vulnerability database.  See GENERIC-MAP-OTHER and
GENERIC-MAP-NONE, for example.  I anticipate other GENERIC-MAP
descriptors may become necessary to handle some of the other aspects
of trying to "unify" two different databases with different content
decisions and different entries.

>Can almost everything in a VDB get a CVE? I know there are rules on
>what a 'vulnerability' is, but the draft CVE is a lot less stringent
>about the definition than, say, the Common Criteria (CC).

I believe that if something in a VDB satisfies the CVE definition of
"vulnerability," then it should have a CVE number, *or* subsume (or be
subsumed by) another CVE number.  If it doesn't satisfy the
definition, then it might map to GENERIC-MAP-NONE or some other
GENERIC entry, which will reflect a substantial difference between the
CVE and that VDB.

- Steve
Page Last Updated or Reviewed: May 22, 2007