CVE Review Meeting (Thursday) - Summary

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

All:

Here is a high-level summary of today's meeting, which I think went
pretty well.  It's amazing what can happen when you get people talking
together in one room :) There was a lot of productive feedback.  More
details will come as we act on these discussions, e.g. through content
decision voting, but feedback from non-participants is welcome.

Non-MITRE attendees were Andre Frech, Mike Prosser, and Bill Fithen
and Craig Ozancin via teleconference.  MITRE attendees at various
times were Dave Mann, Steve Christey, Margie Zuk, Dave Goldberg
(observer), Bill Hill, and Dave Baker.

We began with a reminder of an original (and continuing) goal of the
CVE to be independent of multiple perspectives, using that as the
rationale for the "inclusive" vulnerability definition that the CVE
uses.  The Board members in attendance were supportive of the notion.
We also discussed some of the broader challenges we've faced as a
result.

We got a largely favorable response to our proposals for handling the
vulnerability definition problem by using a "universal" attribute in
CMEX.  While this won't make everyone happy, it is a reasonable
compromise.  There was also agreement on the use of dot notation, and
addressing high cardinality in a reasonable fashion.  The
implementations still need to be worked out a little bit, but I
believe we've got enough of a solid basis for being able to move
forward on these issues.

We spent a lot of time on the EXCLUSION content decisions.  The
shortest summary is, the group agreed that EX-BETA, EX-BRUTE, and
EX-CLIENT are too restrictive, especially in the broader context of
the "inclusive" (more general) vulnerability definition.  I will be
putting these content decisions up for a vote, but it appears that
they will be REJECTed, or heavily modified.  While there isn't a
specifically named content decision for privacy issues, they will
likely also remain in the CVE, as they're extremely important in an
e-commerce context.

There was a lot of discussion on the validation of vulnerabilities as
well.  It's clear that for a candidate to be accepted into the CVE,
its existence will have to be sufficiently proven, e.g. by being
validated by several Board members.  In the cases where the details of
a vulnerability are not publicly known, it's possible that more secure
discussion channels might be useful to allow Board members to share
enough information to sufficiently validate something.  However, this
goes against the notion of a fully public discussion of
vulnerabilities, so the issue of private channels needs more
consideration.

I discussed my rationales for the simplified "model" of configuration
problems, and there seemed to be general agreement that it was a
reasonable first step.  I think it's becoming clear to everyone that
we need better language to effectively describe configuration
problems, but at least the simplified model is a start.

While discussing the content decision voting process, it was agreed
that it is not sufficient to go public with only 93 vulnerabilities
that have been accepted into the "real" CVE.  It was agreed that 300
vulnerabilities was a reasonable goal.  However, this places pressure
on us to resolve the active content decisions, so proposal and voting
will being early next week, with an interim decision scheduled for
August 23.

We then discussed the idea of the CVE Interoperability Demo.  Nobody
liked the "CID" acronym, so we're looking for something better. Each
attendee saw a roles that they could play within the demo.  I believe
it is flexible enough to accommodate all participating Board members.
We discussed what the initial "demo" for the big CVE splash at SANS-NS
might look like.  It became clear that we need to act on this idea
quickly, in order to get marketing departments involved and to refine
the scenario enough for an effective presentation at SANS.

During the day, I had a separate meeting with Mike Prosser, and
another with Andre Frech, to discuss their tools and the CVE mappings
that I created.  I compared the tool to the CVE, to an abstraction of
the tool's "competition," and to a set of exploits accessible on
various hacker sites.  I believe that actually seeing the mappings
helped them to understand some of their power (and the implications).
I think it also helped to see how vendors' "numbers games" could be
filtered through the CVE - and some of the limitations of that filter.
It will be very interesting to compare tools and databases using real,
validated mappings.

- Steve