[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[CVEPRI] CVE candidate issues - handling new candidates

All:

Now that CVE is public, we need to address some issues related to CVE
candidates.

It is likely that there is a backlog of 1000-2000 vulnerabilities or
exposures that have not yet been assigned a candidate number.  As
Board members and others make their tools and databases CVE-compatible
and contribute their "top 100" lists to me, I believe we will be able
to address the backlog by using candidate clusters, in the way that we
did earlier this year.

However, we must not allow CVE to become obsolete with respect to
recent or newly discovered security problems, which come in at the
rate of about 1 or 2 per day.  We need to take a balanced approach so
that CVE can also be as current as possible with respect to new
information.


*** The Executive Summary ***

This is a big message, so here are the most salient points:

1) We should start educating the public about candidates now.  The
   sooner we use candidate numbers, the better.

2) Until content decisions and candidate assignment issues are well
   resolved, I'll remain the sole CNA to minimize "noise."

3) I could assign candidate numbers to Board members who provide me
   with sufficient information to write up a description and include a
   reference.  Subsequent proposals will be sent to interested Board
   members on a regular basis.

4) We will restrict this approach to new problems ONLY, using
   established methods to deal with legacy entries.  This scopes the
   problem while making CVE be as complete as possible from this point
   on.

5) Basic candidate information is provided on the web site (e.g. as a
   large HTML or text file), with enhancements to occur later.

6) Your feedback is appreciated.


*** THE ISSUES ***

1) How - and when - to educate the public about candidates and their
   difference from CVE entries.

   CVE has been given some attention in the past month.  However, it's
   clear that the public still needs to be educated about it (consider
   the recent discussions on the firewall-wizards mailing list).  If
   we make candidates more prominent - e.g. by including them in
   advisories or somehow attaching them to postings to mailing lists -
   will we obscure the original message that this initiative even
   exists?  Do we confuse the public with two numbering schemes (CVE
   numbers and candidate numbers)?  How much does that increase the
   risk of candidate numbers becoming the de facto standard?  If all
   major products are looking to be CVE-compatible, then this problem
   is probably reduced significantly.

   On the other hand, people will have to be educated about candidate
   numbers sooner or later, so why not just educate them now?  In
   addition, the longer we delay attaching candidate numbers to early
   vulnerability information, the more effort everyone will have to
   spend coordinating all that information.

2) Identifying the best mechanism and infrastructure for making
   candidate information available to (a) voting Board members, (b)
   mappers, and (c) other interested parties, while minimizing
   confusion with normal CVE entries.

   There are several database design and implementation issues that
   will take some time to resolve before a viable candidate
   information source can be provided, whether to Board members or to
   the public as a whole.  But there is a clear need for it.  Board
   members need to be able to know which candidates they've voted on
   (or need to vote on).  Mappers and other interested parties should
   be able to access this information to stay current, especially if
   they are seeking CVE compatibility.  There are also some questions
   with respect to the best way to handle databases that use both CVE
   numbers and candidate numbers.  In addition, the linkage between
   CVE numbers and candidate numbers will need to be recorded,
   especially for cases where a candidate is split or merged.

   Dissemination of candidate information could be addressed in
   phases.  For example, I have already made some basic candidate
   status information available to Board members in a comma-separated
   format.  We could make that available for download by interested
   parties along with other basic formats, saving other issues
   (e.g. database design or a good search utility) for later.

3) How to assign candidates in a way that minimizes "noise" as well as
   the amount of work that the Board needs to do to validate entries
   (both now, when so many content decisions are undecided, and later,
   as new CNA's are brought into the process).

   If there are too many sources of candidates early in the process,
   then there is an increased risk of (a) duplicates, (b) rejections,
   and (c) recasts.  The more candidates there are, the more work that
   Editorial Board voters will have to do.  This problem will be
   exacerbated by the lack of a good mechanism for obtaining and
   managing candidate information, as described above in (2).  In
   addition, very few content decisions have been sufficiently
   discussed and approved by the Board, which will cause more problems
   in terms of being able to reliably assign candidate numbers that
   have a good chance of acceptance.

4) How to link announcements of new vulnerabilities/exposures
   (e.g. advisories) to CVE or candidate numbers without forcing the
   announcer to give up their real or perceived "competitive edge" for
   being the first to disclose the problem.

   There are several complexities in dealing with this particular
   problem.  Consider "first-time advisories" in which a problem is
   first announced to the public in a formal advisory.  In the best of
   all possible worlds, the advisory would be posted with a CVE
   number(s) included in it.  However, a CVE number would require
   validation by the Board, which would require the advisory
   organization to disclose sufficient details for validation (current
   voting rules do not allow a candidate to be accepted with only a
   single Board member and confirmation by the software vendor).  The
   organization with the advisory may not want to provide this
   information to their competitors.  (This concern has already been
   expressed.)  In addition, if the candidate really isn't public,
   then there would need to be a secure mechanism to protect the
   related information while it is being validated, which poses
   challenges for maintaining confidentiality.  If such a mechanism is
   feasible, it will take time to set up.

   In short, while it might be best that an advisory could include a
   validated CVE number with it, there are various challenges which do
   not make this possible in the short term.  So at this time, a
   "first-time advisory" would at best contain candidate numbers.  But
   if we haven't educated the public as in (1), then the advisory
   would need to also take on the task of educating the public about
   candidate numbers.

   This particular issue only appears to apply to formal,
   well-validated first-time announcements such as advisories.
   However, advisories are far-reaching and typically deal with the
   most serious and extensive problems, so they could serve as a
   vehicle not only to educate the public about CVE, but to provide a
   name for major problems as early as possible.


*** AN APPROACH ***

Here's what I suggest as an approach for dealing with new
vulnerability information at this time.  It allows us to move forward
on some issues that can be acted upon now, while taking the proper
time to resolve longer-term issues.

0) We treat backlog issues independently of the issues related to new
   information.

1) We take steps to educate the public about candidates now.
   Education could take the form of (a) web pages on the CVE web site
   describing the differences between candidates and CVE entries, (b)
   short statements in any forum where candidate numbers are used
   (e.g. advisories or mail messages), and (c) additional
   clarifications by Board members in various forums where the subject
   comes up.

2) With me continuing to act as sole CNA, I could interact with Board
   members who have a desire to obtain candidate numbers for new
   information.

   - Submissions would be limited to new vulnerabilities ONLY (for
     now)

   - The submission MUST be ready for public dissemination (or already
     publicly known)

   - Submitters should only do submissions for vulnerabilities which
     they are the first to announce or publicize (this reduces "noise"
     of many Board members sending me the same submission).  An
     alternate approach would be to have different submitters with
     different expertise (e.g. Windows NT vs. Unix) to focus on a set
     of problems

   - The submission includes a short description and references,
     i.e. looks very much like a candidate proposal

   - I then give them a candidate number (or numbers) to use

   - The candidates are packaged up and proposed to the Board list on
     a weekly basis (to reduce traffic on the list)

   - Interested Board members can request to be emailed directly when
     new candidates arise, instead of waiting for the weekly posting

   This allows for some consistency across candidates while reducing
   duplication and other problems.  Restricting the request for
   candidates to new information, *and* to the original source of the
   information, reduces the effort required in this first step.

   This also allows me to continue to "schedule" and cluster content
   decision debates accordingly so that we avoid discussing too many
   technical issues at the same time.  As various issues are resolved
   (e.g. database design, content decisions, etc.) these experiences
   could be used to begin a "training manual" for other CNA's.

   By having the candidate submitters send information to me in a
   "near-candidate" format, it allows prospective CNA's to begin to
   identify and address their own issues.

3) We provide a candidate status page on the CVE web site, including
   the capability to download candidate information in various formats
   (e.g. text, HTML, CSV).  The status information should be detailed
   enough to allow Board members to view which candidates they've
   voted on.

4) We delay creating a forum for the Board to discuss non-public
   information until some of these other issues have been sufficiently
   addressed.  But with the public being educated, most first-time
   advisories could at least include candidate numbers.


What do you think about this approach?
Page Last Updated or Reviewed: May 22, 2007