CVE Update - Now and the Future

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

All,

We have been quiet recently, I know, but much has been happening.
Over the past couple of years, we've been working very hard on a
number of things in CVE, mostly related to content and compatibility.
Managing the Editorial Board has been a low priority, although we do
want to rejuvenate the Board and have it achieve a level of vibrancy
that it once had.

The inquiry about CVE and the Editorial Board comes at a good time.
We are at a major transition point in CVE's lifetime, when big
questions are being asked.

We have brought Dave Mann (remember him?) back into the fold as a task
leader.  While we are still determining the precise nature of his role
and his priorities, currently his primary task is to help us to
achieve a operational, non-interuptible production of CVE content.



CVE Content
-----------

Our most concrete efforts have been in improving the timeliness and
comprehensiveness of CVE content.  Compared to a year ago, we are
producing twice the number of candidates than we used to.  We have
much closer links to OVAL and CERT, as well as NVD and other US-CERT
initiatives.

In October, we successfully finalized the CVE renumbering that we've
discussed in the past.  All candidates now come out with a "CVE"
prefix, and each item is labeled with an "Entry" or "Candidate"
status.  Our initial announcement is at:

  http://cve.mitre.org/cve/renumber.html

We still have a ways to go on content, however.  We are much closer to
being timely and comprehensive than we were a year ago, and we have
made major leaps in the last 2 months.  But minor issues in minor
software still slip through the cracks.  Our references to other data
sources - e.g. Bugtraq ID, Secunia, OSVDB, ISS X-Force, etc. - are not
as complete as we would like, although we cover more references than
we used to.

We nearly produce public content on a daily basis, but sometimes there
are slow days where it occurs in bursts.  In the past this was not a
major problem, but it has become more important because regular
production makes it easier for compatible products and services to map
their items to CVE.  In addition, the lack of regular production makes
it difficult for products like NVD, since it depends so heavily on CVE
for content but has different goals than we had originally intended
for CVE.  (Note that we are working with Peter Mell as well as our
mutual sponsor, the Department of Homeland Security, to clarify and
hopefully unify our vision.)

As has happened in the past, we also must deal with regular changes in
content team membership.  We have gotten much better about training
and finding the right people for the job, and providing feedback to
analysts.  We are better at absorbing personnel changes when they come
along, to minimize disruption.

One main reason for the lack of major disruption, while retaining
quality, has been my hands-on approach while acting as CVE Editor.
Approximately 95% of all CVE candidates are still reviewed by me
before they become public, and I still generate about 40% of all
candidates.  This of course can also be a liability.  For example, I
took a vacation in November and while content production continued
behind the scenes, there were no new CVE's published for over a week.
We now realize that there is much greater operational dependence on
CVE than we had believed.  We have not yet found the proper
person/people to act as co-Editor, although we are always optimistic.
Meanwhile, we are making changes to ensure that we do not have any
more disruption like what happened in November.

I can also see the writing on the wall, and I predict that at some
point soon, the problem of accuracy in vulnerability information will
become a major point of contention for consumers and/or affected
software vendors.  There has been a marked increase in vendor disputes
of existing issues, for example, and consumers seem to be getting more
vocal about their expectations.  This will have an impact on everyone,
but especially vulnerability databases, including CVE.  (Yes, I've
decided that CVE is in fact a vuln DB, albeit a highly specialized one
that is regularly "misused" relative to its original purpose).  Our
content tasks take some of this concern into account, although it is a
problem for the industry in general; see my Bugtraq post "Why
Vulnerability Databases can't do everything" for some of my thoughts
on the problems.  Normally I would not bring this up, but I think it
could become a big driver for the industry, and it might impose some
changes on CVE.

All of this is happening with an infrastructure for content generation
that was fine in the olden days when there were 40 vulnerabilities a
month, and only me and one other person creating content.  Now there
are up to 100 vulnerabilities a week and 3 to 5 people creating
content.  This increases the numbers, but it also results in more
duplicate identifiers than we used to produce, more complexity of the
entire process, and a less clear division of labor that places more
demands on the skills of content team members.  We have not had the
time or resources to conduct a complete process overhaul, due to the
constant demands for additional content.  I am sure other people here
can relate!


Data Feed
---------

Note that as part of our work on timeliness and closer cooperation
with external sources, we developed an hourly feed to external sources
that use CVE heavily.  This feed provides the CVEs that were created
within the last hour, in either text or XML format.  I did not want to
announce this to the entire Board until it was out of beta release,
but the reality is that it has been in full production for months, so
I might as well announce it now.  We do not plan on providing this
feed to the public, although certainly any CVE-compatible source can
receive it, since it can be more closely tied to mapping.  Contact me
off-line and I will add you to our notification lists.


Voting and CVE Versions
-----------------------

MITRE has not submitted candidates for voting in quite a while, which
has delayed the production of a new CVE version.  Voting by clusters
had stopped being successful quite a while ago anyway, due to the
large volume of issues coming in.  I've been thinking that it might be
benefecial to make voting more lightweight, and to be as flexible as
possible in allowing Board members to vote.  For example, we regularly
receive updates or corrections from various Linux vendors.  Indeed,
the whole purpose of voting should be reviewed.  The fact is that the
workload was too much for the Board several years ago, so restarting
it without any changes would not be effective.  This could argue for
extending the Board, creating a separate voting group for voting and
review, or modifying the rules for when to promote an issue from a
candidate to an entry.

Similar to the voting questions, we also want to revisit whether the
concept of CVE versions really works.  It is clear that in this day
and age, most people also use candidates.  Now that the renumbering
has happened, there might be even less need to distinction.  Periodic
CVE versions would still have their uses, especially in providing
predictability and some assurance of data accuracy, or serving as a
basis of large-scale trend analyses.  However, there has not been a
new version in over a year and frankly, there has been very little
demand for one.


CVE Compatibility
-----------------

Our CVE compatibility evaluation program has continued to grow, with
Bob Martin's leadership.  Now, over 230 products and services, from
140+ organizations, have at least declared their intentions for CVE
compatibility.  53 products have obtained official "CVE Compatible"
status, with another set of products to be announced soon.

We have had several rounds of evaluations over the past couple of
years, and we better understand the complexities.  We have built much
of the infrastructure to make the evaluations efficient and effective,
although it is dependent on the content infrastructure and could
therefore benefit from some change.


Related Efforts
---------------

CVE work has not been occurring in a vacuum.  In the past year, we
have continued to explore the Common Intrusion Event List (CIEL)
concept, as well as OS/system configuration issues.  Results are still
preliminary, and funding is variable, but we can provide more details
if people are interested.

We continue to leverage our CVE experience to help us move forward in
the Common Malware Enumeration (CME) effort, although it has its own
set of unique challenges.

We have also begun work on a vulnerability classification project that
is temporarily called PLOVER.  This grew out of my "Vulnerability
auditing checklist" side project, which I periodically posted to
public mailing lists over the years.  At this stage, PLOVER includes
about 300 categories of vulnerabilities and is up-to-date enough to
include issues such as CSRF, PHP file inclusion, and eval injection.
These classes are linked to over 1500 individual CVEs.  It includes
some "vulnerability theory" that has helped improve my understanding
of vulnerabilities, and introduces some terminology for new
vulnerability classes.  Some of this has fed back into terminology
that we use for CVE descriptions.

The PLOVER work has a close tie-in to a NIST/DHS effort in
understanding source code scanners and other security analysis tools.
In future months, we hope to extend it to encompass other recent
research in taxonomies and vulnerability classification, the bulk of
which is coming from secure software development people like McGraw,
Chess, Viega, Howard, LeBlanc, etc.  Bob Martin and I are excited
about this new effort, and we are confident that our CVE experience
will help us to make solid contributions.

I still want to make some minor modifications to PLOVER before making
a wide public announcement, but the current version is at:

  http://cve.mitre.org/docs/plover/

Warning: it's huge.


Editorial Board
---------------

As you all know, there has been minimal activity with the Editorial
Board over the past couple of years, due to our focus on content
generation, as previously discussed.

It is my hope that the addition of Dave Mann as another CVE task
leader will help to free us to get the Board back on track.

Amongst many things to be covered are:

  - the future directions for CVE and related efforts

  - the role of the Board itself

  - the addition of new members

  - voting


It would be best to have a teleconference in January, after the
holidays.

As Pascal said, I too miss the kinds of discussions that we used to
have.  MITRE has been deep in the weeds of CVE content for a while
now, but this is a good time to get back into the swing of things with
the Editorial Board.


Thanks all,
Steve