[TECH] Assigning Candidates to Not-Yet-Published Security Problems

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

All,

As you may know, several security advisories have included candidate
numbers.  ISS, rain.forest.puppy, and BindView have all released such
advisories.  Another entity (not a Board member) has also requested
candidate numbers.  I believe that requests from non-Board members
will increase over time.

The interest in candidates by non-Board members has raised some issues
with respect to the "proper" way to assign candidate numbers to
security problems before they are publicly announced.  This email and
the next one describe a new process that opens candidate assignment to
non-Board members, while reducing the amount of potentially sensitive
information that is required.  (Until today, a draft advisory had to
be reviewed before a candidate was assigned).  We will be refining
this process over the next few months.

The process, outlined below, allows candidates to be assigned more
quickly for non-public issues.  It makes it easier for interested
parties to obtain a candidate number even if they aren't a Board
member.  It limits the amount of interaction between MITRE and the
requester, which reduces the amount of overlap with the activities of
other entities like *Bugtraq and CERT.  In addition, a rough concept
of "trust" is included which may support a small degree of
"self-policing" within the vulnerability analysis community.

Note that we are not actively publicizing this new approach so that we
have some time to test it with analysts who show the initiative to
request a candidate number.

Thanks to Bill Fithen, Russ Cooper, and Elias Levy for making
incredible contributions to this new approach.  I hope that this
document captures their ideas effectively.

- Steve



Assigning Candidates to Not-Yet-Published Security Problems
-----------------------------------------------------------
Last updated: May 22, 2000


Recently, there have been requests by security experts to obtain
candidate numbers for new security problems that they are about to
publicly announce.  Some of these people are not Editorial Board
members.  Their requests have highlighted a need to develop an
effective process of assigning numbers that can support non-Board
members and minimize the overlap between CVE and existing notification
capabilities provided by Bugtraq, NTBugtraq, CERT, etc.

This document outlines an approach that MITRE is currently taking with
respect to assigning candidates for security problems that are slated
for publication, i.e. nearly ready to be posted to the *Bugtraq
mailing lists or through other means.

We are not proactively advertising this approach yet, but we will
follow it when someone requests a candidate number.  This will allow
us to incrementally improve the process as more and more candidate
"requesters" participate.


Underlying Rationales For This Approach
---------------------------------------

1) Before now, MITRE has worked closely with the requester to
   determine the proper level of abstraction for a new issue, whether
   it falls under the CVE vulnerability/exposure definition, and
   whether it is truly new or not.  This approach required a review of
   an early version of the advisory.  While it minimized the potential
   amount of "noise," it made MITRE aware of non-public information.
   Extending candidate assignment to non-Board members is a reasonable
   approach, but it would significantly increase the amount of
   non-public vulnerability information that is provided to MITRE.
   This is an overlap with *Bugtraq, CERT, and other organizations
   that already have the infrastructure to handle non-public
   information.  This new approach reduces the amount of review that
   is necessary before assigning a candidate.  The benefit is a faster
   response, minimized interference with current processes, and the
   ability to allow a broader audience to obtain a candidate number
   which may then be included in advisories or other early
   announcements.

2) If a security problem is not reviewed before a candidate is
   assigned to it, there will be an increase in "noise" - duplicate
   candidates, rejected candidates, wrong level of abstraction, etc.
   This increases the workload for MITRE to maintain CVE, and for
   Board members to vote on it.  So the risk must be minimized as much
   as possible.

3) If we only make candidates available to certain "trusted" people,
   then we face a slippery slope of deciding who can be trusted, and
   who can't.  Some organizations or individuals may be reliable
   sources of new vulnerability information, but might not be
   "trusted" per se.  An organization/individual should be able to
   acquire candidate numbers, provided they perform due diligence in
   avoiding duplication and ensuring that the candidate is appropriate
   for CVE.  (See below).

4) The approach must minimize interference with the current way that
   new vulnerabilities are announced.  For example, it shouldn't delay
   announcements any further than the current review processes that
   are in place at CERT, *Bugtraq, vulnerability analysis teams, etc.

5) Requesters should perform due diligence to ensure that the
   candidate has a strong probability of becoming an official entry
   without major modifications.  Such requesters should be "rewarded"
   for due diligence.



Due Diligence for Candidate Number Requests
-------------------------------------------

Before requesting a candidate, the requester should perform due
diligence in determining that the request is appropriate for CVE,
i.e.:

 - the problem is genuine and reproducible by the requester

 - the problem does not already have an associated CVE number
   (candidate or entry)

 - the problem satisfies the vulnerability/exposure definition

 - the problem is represented at the CVE level of abstraction, as
   dictated by *approved* or *documented* content decisions.  (CD's
   that are still under discussion by the Board are exempt, except
   where documented on the web site.)

It is the requester's responsibility to perform due diligence in
determining whether a new candidate number needs to be assigned, and
the appropriate level of abstraction to use.  If the requester does
not perform due diligence, future requests for a candidate number may
be denied.  Because CD's are evolving and may change before final
approval by the Editorial Board, and they are not currently
well-documented on the web site, exemptions may be made with respect
to CD-related discrepancies in candidates.

The requester should only request a candidate when their announcement
is almost ready for publication.

The requester may consult with MITRE if they need additional
information to ensure that they are assigning a candidate properly.

A *Diligence Level* is recorded for the requester.  The diligence
level identifies how well an individual or organization performs due
diligence for candidates.  Diligence levels are described in a
separate document.


Candidate Request Process
-------------------------

Before making a request, the requester should perform due diligence in
ensuring that a new candidate number is required (see above).

1) The requester emails MITRE with a request for a candidate number.
   They do not need to provide any details about the associated
   security problem.

2) The requester's identity is verified to ensure that the request is
   legitimate, e.g. based on their email address.  For new requesters,
   a verification email could be sent to the requester to verify the
   email address.

3) Each requester gets a *QUOTA* which defines the maximum number of
   "outstanding" (non-public) CAN's that the requester can have.  New
   or unknown requesters get a quota of 1, and others get larger
   quotas based on accuracy and reliability.  A separate document on
   diligence levels provides initial guidelines for determining
   quotas.

4) If the requester's quota is exceeded, their request for a new CAN
   is denied.  Otherwise...

5) A new CAN is quickly assigned, and the requester is recorded in
   CMEX.  The number of "outstanding candidates" for the requester is
   incremented.  The CAN is published on the CVE web site with a
   default description saying that it is "reserved."  No other
   information is provided.  (This provides some basic information if
   someone looks up the CAN before the CVE web site has been updated
   with the full information).

6) The requester is emailed the new CAN, along with a boilerplate
   description of candidates that they should include in their
   announcement.  The current boilerplate is:

     The Common Vulnerabilities and Exposures (CVE) project has
     assigned the name CAN-YYYY-NNNN to this issue. This is a
     candidate for inclusion in the CVE list (http://cve.mitre.org),
     which standardizes names for security problems.  Candidates may
     change significantly before they become official CVE entries.

7) The requester must notify MITRE upon publication of the candidate,
   and include at least one refererence to an established public
   source (*Bugtraq, news site article, etc.)  Until this notification
   takes place, the CAN is considered "outstanding."

8) If the candidate is ultimately REJECTed or RECAST, then the
   discrepancy is noted.  If the requester repeatedly requests
   candidates for issues that are RECAST or REJECTed, then the
   requester's quota may be lowered, possibly to 0.  Exceptions are
   made in cases where a RECAST/REJECT is related to a CD that was
   unresolved or undocumented at the time the candidate number was
   assigned.

9) If the vendor acknowledges and/or fixes the problem, the requester
   should notify MITRE, since vendor acknowledgement improves the
   chances of a candidate's acceptance into the official CVE list.
   (Vendor acknowledgement counts as an ACCEPT vote in some
   situations).


Diligence Levels and Assignment Quotas
--------------------------------------

A separate document will provide informal guidelines for establishing
the *diligence level* for a requester, i.e. how consistent they are
with respect to publicizing candidates that ultimately become official
CVE entries.  Initially the document will be used by MITRE in
determining quotas for new requesters, but the Editorial Board may
review and modify them if appropriate.

MITRE and/or Editorial Board members may evaluate the due diligence of
requesters on an ad hoc basis, e.g. by reviewing the number of
requested candidates that are REJECTed or RECAST.  The guidelines
provided above may provide a basis.  This process will be refined as
the need arises, and formal rules may be adopted if necessary.


Open Questions
--------------

The Editorial Board should consider whether or not the name of the
requester should be published, and if so, how.  Publishing the
requester's email address may provide additional impetus for them to
perform due diligence.

The degree of authentication of the requester needs to be decided.  At
a minimum, an email address may be sufficient.  In the longer term,
support for PGP signatures would provide stronger authentication for
the requesters who want it.


Actions to be Taken
-------------------

The following actions need to be taken to ensure that this process
works properly.

MITRE needs to establish a way for someone to request a new candidate,
e.g. via email, and ensure that sufficient resources are set up so
that a member of the CVE content team can make a candidate available
within an acceptable time frame, e.g. 4 business hours after initial
receipt of the email.

The Editorial Board needs to review the "Diligence Levels" document
and consider ways of determining diligence levels.

MITRE needs to document content decisions and make them publicly
available, so that candidate requesters can determine the appropriate
level of abstraction and requirements for inclusion in CVE.  In the
early days of this new assignment capability, we should be "forgiving"
about inconsistencies that are related to content decisions.

The Editorial Board needs to review, modify, and approve (or reject)
CVE content decisions when they are proposed.  Until CD's are approved
by the Board, candidates have an increased risk of a RECAST or REJECT.