[TECH] Assigning Candidates to Not-Yet-Published Security Problems
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.
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
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
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
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,
- 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
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
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
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
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
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
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.
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
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.