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

Re: Level of Abstraction Issue: Similar Applications, "Same"Vulnerability

>Gene Spafford advocated using a lower level of abstraction than the
>current CVE content decisions for similar applications exhibiting "the
>same" vulnerability.

(...)
>I believe that the Same Attack approach has more practical, everyday
>usage than Spaf's Same Codebase perspective, since (a) it's at the
>level that IDSes and scanners would operate at; and (b) it's at the
>level that (in my experience) sysadmins like to see it at, especially
>as they pore through the voluminous results of security tools.  I
>believe that as long as we make sure that the description identifies
>all affected applications, then the current CVE content decision
>remains the most appropriate for the community at large, especially
>when considering the "end users."
>
>Comments?
Yes, although I can easily imagine some people here thinking that I am
being too strict and "scientific" (to be polite) about it.

The "Same attack, same software flaw = same vulnerability" is an empirical
approach based on observable phenotypes, and as was shown in Biology, is
sometimes wrong.  I want to impress that the question, "are they the same
or not" can't be answered without a classification scheme, and a
specification of the abstraction level within that classification ("are
they of the same *what*;  family, species, genus?") -- that is, it can't be
answered without a nomenclature.  Since it was decided to have the CVE
operate without a nomenclature, I submit to you that you can't answer the
question as to whether two vulnerabilities are truly the same or not.  This
is especially remarkable if you try to put abstraction levels into the
equation -- the way I see it an abstraction level can't exist without a
nomenclature, the same way that money can't exist without a country or
union of countries to back it up.

It seems to me that the real question is, "do we need separate entries to
list these two vulnerabilities", instead of "are they the same
vulnerability".  One approach grounded in the observables is to use "Same
attack, same results of the attack, for all attacks = same record".  This
is because the results of an attack may be different, although the attack
"works" on both (i.e., both systems are vulnerable to the same attack in a
different way).  My recommendation would be that if you don't have any
observables with which to differentiate the vulnerabilities, then use the
same record, be flexible when new data becomes available, and don't assume
that there is always an absolute equivalence between vulnerabilities and
records.  It's a "best effort" system mixed with the principle of Occam's
razor.

The basic problem encountered here reminds me of the one encountered by all
vulnerability databases that attempt to present everything at the same
level of abstraction, *and* have a nomenclature.  My thesis is that if you
have a nomenclature, then you have different levels of abstractions, and
therefore your database should have different types of objects -- at least
one type per level of abstraction, and links between the different levels
(I need a good cross-platform, open format relational database, any
suggestions?).

The overall implications of what I am saying is that the CVE has to link
the "leaves", so to speak, between vulnerability databases, because only
the leaves are independent from a nomenclature.  To do otherwise would
defacto define a nomenclature and violate your mandate.  The codebase could
help define the leaves, but could also lead to an impractically high
cardinality as discussed in the CVE draft report.  So, from a "scientific"
standpoint, please differentiate on the codebase only if it is well-known
and unambiguous.  This is an example of an ambiguous code base which
doesn't deserve separate listing:  vulnerabilities in Microsoft products
for Macintosh vs the same products for Windows.  I'm afraid that the
inclusion of the "code base" will introduce subjective factors in the
enumeration.

Pascal
Page Last Updated or Reviewed: May 22, 2007