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

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


I would like to give my .02 regarding the CVE Level of Abstraction
question.  As an introduction, for some time my focus has been on
network intrusion detection systems.   In this note I make a suggestion
for the level of abstraction problem, give you a little background on my
view of the CVE, and then address specific issues surrounding my choice.
Also, I respond here to the survey regarding other databases.

General Opinion
----------------------
I think that for the CVE we should declare that a vulnerability is
distinguished by "attack + outcome".   The prototype for this suggestion
was "same attack, same software flaw = same vulnerability", but I think
using software flaw has many of the same problems as codebase, so I
specifically drop it here.  Further, I make explicit the differentiation
based on outcome that seems to run through the discussion to date.

As an aid to our understanding, we can list the OSs and applications
known to be affected at the time, with the understanding that such a
list is not comprehensive.  Further, perhaps we could agree that
additional OSs and applications could be added without actually
"changing" the CVE entry.

Background
----------------
I think a primary benefit of CVE is that it promotes interoperability
and useful information exchange, in any combination between tools,
databases, and people (i.e. tool-tool, person-person,
tool-person,...).   Additionally, having a definitive (at some level)
list of vulnerabilities is promising for several other uses as well.
However, for CVE to be useful, it should be:
- stable: the meaning of existing entries must not change.  Additions
will, of course, be required
- timely: given discovery of a new vulnerability, it should be
relatively easy to add a new entry.
- unambiguous: given that we decide issues like the present one, others
should be able to repeat and/or understand our decisions.

We should be conservative about extra purposes and burdens we add to the
CVE effort.  As originally conceived, CVE was to be simply and only a
list of vulnerabilities and a unique tag.  As it developed, we have
added things like external references and a basic categorization, but
those things are meant to aid the editorial group in understanding and
differentiating between entries.

While capturing more information might seem better, CVE is not a
replacement for general purpose security or vulnerability databases.  We
need those, and I believe that having a variety of  fundamental
orientations (or layers of abstraction) in them is good, and useful.

When you think about it, who are the "consumers" for the CVE?  I see two
groups.  First, there those doing theoretical work, system integration,
or tool development.  We need the CVE for its usefulness in deciphering
and integrating vulnerability information from various sources and
perspectives.  The second group is the system administrators, incident
handlers, bug reporting email list people, etc., who could make good use
of the CVE tags we can give new vulnerabilities, but are unlikely to be
"using" the CVE per se; they will be focused on some other data source.

Specific Points
--------------------
The points discussed here are culled from many of the previous messages,
in no particular order.

On the subject of Vendors attempting to distort CVE information for
advertising purposes, I agree with Aleph One, it will of course be
attempted, and I do not believe our decision should be based on an
attempt to circumvent that.  That said, I think Attack + Outcome is
better here.  Under Attack + Outcome,  there must be fewer "extra"
vulnerabilities vendors could claim to have.  Once an attack + outcome
is entered as a vulnerability, then all OS and application bases are
covered, vs. Codebase, where every application and OS represents a new
CVE entry that must be created, validated, etc.  Further, should CVE
(and its Attack + Outcome basis) become widely known, then the concepts
of how CVE relates to completeness and cardinality will be discerned
also.  So even if tool A and B detect the same number of CVE
vulnerabilities, but tool B detects 100 more cases or instances of some
vulnerabilities, then in some sense tool B is more capable than A, and I
think people will understand that.

Re: Adam's comment that "...as a sysadmin, I'd be suprised to see the
same vulnerability in a MS client and a Sun client, and my fix
activities and scheduling would be different."  I disagree.  Biggest
example: Y2K.  Same "problem" affecting all too many systems.   There
are plenty of cross UNIX vulnerabilities that have sysadmins patching
different OSs for the "same" vulnerability too.  So I think it is
reasonable to expect sysadmins to understand this, and deal with the
fact that corrective measures will vary with OS etc.  A similar problem
is presented even when multiple versions of an application or OS are in
use; corrective measures will vary.

"Codebase" is unsuitably complex as it requires us make judgments about
source code, which we often will not have access to.  Further, as
previous notes have illustrated, interactions with libraries and the
operating system complicate matters, requiring us to delve into them as
well.  Even if we had full access to all source code, I do not believe
we could get timely review from enough members of the review group to
sustain the CVE.

"Attack + Outcome" is the simplest of the choices.  Further, I think it
will resonate with a lot of people in the trenches, who are dealing with
exploits and signatures (attack) and what they do (outcome).


The Survey
---------------
My database uses the Attack decision, and I believe the database is
fairly consistent.  It is a collaborative operation, though, so it would
be interesting to review the consistency there...

All IMHO, of course!
Bill

begin:vcard 
n:Hill;William
tel;work:703-883-6416
x-mozilla-html:TRUE
org:The MITRE Corporation
adr:;;1820 Dolley Madison Blvd;McLean;VA;22102;
version:2.1
email;internet:bill@mitre.org
title:INFOSEC Engineer
fn:Bill Hill
end:vcard
Page Last Updated or Reviewed: May 22, 2007