[TECH] Timeliness of candidate assignment for recent issues

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

All:

In the past month, I have received 2 requests for candidate numbers
for serious security issues that were already publicly known.  In both
cases, the issue was significant, and the affected vendors had
published advisories before a candidate number was even made public
(and in one case, before a candidate number had even been assigned
internally).  The requesters asked for a candidate number so they
could annotate their own database.  A number was quickly assigned and
provided to each requester.

In the past, Board members have agreed that it is not necessary to try
and assign candidates the moment that an issue is published.  Thus
rapid assignment has been a relatively low priority for us at MITRE.
As a result, candidate numbers are not immediately assigned when a
significant issue is discovered and widely publicized.  While we are
not yet prepared to provide instant assignment on a large scale, it
seems reasonable to provide candidate numbers as soon as possible for
the most serious problems.  We are exploring how to inject candidates
into initial vendor advisories, but we have not found any satisfactory
solutions yet.

Therefore I invite Editorial Board members (and diligent folks who are
reading this message from the mailing list archives) to feel free to
request candidate numbers for recently published problems *if* (a) the
problem has a significant impact such as a root compromise, and (b) it
affects a large number of systems (50,000 or more?).  Recent examples
of such problems include the Outlook email header buffer overflow
(CAN-2000-0567) and the untrusted format string problems in wu-ftpd
and other FTP servers (CAN-2000-0573, CAN-2000-0574).  Turnaround time
should be less than one business day; if I'm sitting at my
workstation, it's closer to 5 minutes ;-) I will also work with the
rest of the content team to be more proactive about assigning
candidate numbers for serious problems, though the content team's
focus will continue to be on legacy problems.

Following is some background information on how candidate numbers are
assigned to newly discovered security problems, and why this approach
incurs some delays.  It provides more details of the "submission
stage," which is a labor-intensive effort that takes place behind the
scenes at MITRE.


Background on the Submission Stage
----------------------------------

The CVE review process is divided into 3 stages: the initial
submission stage, the candidate stage, and the entry stage.  MITRE is
solely responsible for the submission stage; the Editorial Board
shares the responsibility for the candidate and entry stages.

During the submission stage, we collect raw information from various
sources, e.g. the various Board members who have provided us with
their databases.  Each separate item is then converted to a
"submission," which is represented in a standardized format that
facilitates processing by automated programs.  After this conversion
phase, we use various utilities to help find which submissions are
closely related (the "submission matching" phase).

Once matching is complete, related submissions are formed into
submission groups.  Each group is then analyzed and refined into a
single candidate template (the "submission refinement" phase).
Submission refinement is a bottleneck because deep analysis can be
necessary for creating descriptions, distinguishing between closely
related submissions, applying content decisions, etc.

Each candidate template is then converted to the CMEX data format and
given a candidate number (the "candidate assignment" phase), which
begins the candidate stage.  After candidate assignment, backmaps are
generated and provided to the data sources, and the associated
submissions are removed from the pool.  Candidates are then grouped
into clusters and proposed to the Board.  The candidates then move
from the Proposal to the Final Decision phases, and into the entry
stage if they are added to the official CVE list.

In the submission stage, we at MITRE are effectively taking on the
labor-intensive task of creating mappings between several sources of
vulnerability information.  The irony of this is that CVE names would
greatly help us with the integration of submissions, so we still face
the same problem that Dave Mann and I described in the original CVE
paper ;-) This is one of the reasons why I believe that having
candidate numbers in initial public announcements is important.  It
can help reduce the labor for submission matching and refinement for
us.  But in general, it could help anyone who populates their
vulnerability databases from raw information sources such as *Bugtraq
instead of more refined sources.


Candidate Assignment for New Problems
-------------------------------------

The CVE content team has focused on submission matching for the nearly
10,000 legacy submissions we have received, instead of doing rapid
candidate assignment for newly discovered problems.  Currently I am
the only person with enough CVE knowledge to perform refinement, so
there can be delays if I need to tend to other business.  Once content
decisions are finalized and content team members gain CVE expertise,
they will be able to help out with refinement.

In addition, candidate reservation (formerly called pre-publication
candidate assignment) is not being used extensively yet, so there are
few initial public announcements that include candidate numbers.  In
general, candidate reservation can be done pretty quickly because it
skips the submission stage entirely.  However, we are not actively
promoting this new reservation capability because we have not finished
building the underlying utilities that would make candidate
reservation a reliable, multi-user capability that could support 1 to
3 new issues per day.

In recent months, we have come to rely more heavily on publishers of
vulnerability summaries to act as data feeds for newly discovered
problems.  The summaries provide us with the submissions, which are
then matched and refined into candidates.  (I'd like to take a moment
to recognize the contributions from Security Focus, Network
Computing/SANS, ISS, and the NIPC CyberNotes.)

The result of our reliance on vulnerability summaries is that, in
general, a candidate number is assigned 1 to 2 weeks after the initial
announcement of the problem.  Typically the candidate is proposed to
the Board less than a week after assignment, and often the same day.
I estimate that these delays are too long for approximately 10% of CVE
users.

Despite the delays that are introduced, this approach has had two
significant benefits.  The primary effect is that we often have access
to several different items regarding the same problem, which helps us
to create better candidates with more references and a more mature
understanding of the underlying problem.  Secondly, we avoid
duplication of effort - instead of concentrating on scouring the
voluminous information sources for new security problems, we rely on
the output of the vulnerability summary reporters.

In the longer term, the CVE backlog will be cleared - the content team
will finish matching the legacy submissions and refining them into
candidates, content decisions will be resolved, etc.  I also expect
that candidate reservation will be used more often as time goes on.
As this happens, candidate numbers will be assigned more rapidly as a
natural occurrence of CVE's growing maturity.

As usual, questions or comments are welcome.

- Steve