[CVEPRI] Editorial Board Teleconference Summary - June 21, 2001

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

Editorial Board Teleconference Summary - June 21, 2001
------------------------------------------------------

Participants
------------

Participants in the teleconference included:

 Bill Fithen (CERT/CC)
 Tim Collins (NFR)
 Renaud Deraison (Nessus)
 Dana Foat (NSA)
 Andre Frech (ISS)
 Peter Mell (NIST)
 Ron Nguyen (Ernst & Young)
 Shawn Hernan (CERT/CC)
 Scott Lawler (DOD-CERT)
 Larry Oliver (IBM)
 Pascal Meunier (Purdue CERIAS)
 Marcus Ranum (NFR)
 Adam Shostack (Zero Knowledge)
 Kevin Ziese (Cisco)
 Alan Paller (SANS)
 Andy Balinsky (Cisco)
 Ben Greenbaum (SecurityFocus; proxy for Elias Levy)


MITRE participants included:

 Dave Baker
 Steve Christey
 Margie Zuk
 Bob Martin
 Andy Bair
 Barbara Pease


Content Update
--------------

Currently, there are 1510 entries and 1120 candidates.  The content
team continues to process the legacy submissions that were obtained
from databases provided by Editorial Board members.  All submissions
have been matched against each other and formed into groups of closely
related submissions.  There are roughly 4500 submission groups, from
approximately 8500 total legacy submissions.  Since there were 10
databases provided to MITRE, this shows how little overlap there was
between databases, as the average group only included submissions from
2 databases.  So far, approximately 500 of these legacy submission
groups have been refined.  About 150 legacy candidates will be created
from these groups.  The other 350 groups are duplicates of existing
CVE entries or candidates; they will help to extend the references for
those items, however.  Some content team members are working on
refining new submissions into candidates.

A description of the submission process is in the "Submission Stage"
section at http://cve.mitre.org/board/archives/2000-08/msg00013.html


CVE Naming Scheme Changes
-------------------------

There are various problems with the current CAN-YYYY-NNNN /
CVE-YYYY-NNNN scheme.  It can be difficult to find these items from
most search engines (the hyphens can be problematic).  When a
candidate changes to an entry, the CAN prefix of the name is changed
to CVE; this increases maintenance costs for CVE-compatible products,
since they need to change the name from a CAN to CVE.  One database
was observed to have some "CAN" numbers for issues that had been
converted to CVE entries about 7 months ago, and it is suspected that
this problem is typical.  Also, if a person searches a product using
the CAN-YYYY-NNNN number, but the product has the problem indexed
under CVE-YYYY-NNNN, then the person may not find that issue.  The
current naming scheme only allows for a maximum of 10,000 issues per
year, which might not be sufficient in some cases (this is the
"CAN-10K" problem).  Some CVE-compatible products drop the CAN/CVE
prefix altogether and just use a "YYYY-NNNN" scheme.  Other problems
were discussed and are documented in the next section.

Given these problems, it may be appropriate to change the current
naming scheme.  For example, a single identifier could be used for
candidates as well as entries, and the entry/candidate status could be
provided as a separate field.

Any change, however, could have a major impact on all CVE-compatible
product developers, as well as CVE users.  Participants in the
teleconference said that the impact of such a change would have
minimal effect on their own products.

Board members agreed that it is important to minimize the number of
changes to the naming scheme, otherwise CVE would lose the major
advantage of providing a common and stable identifier.  If a change
should occur, it should only happen once; so, all known problems with
the scheme should be addressed at the same time.

To assist in the transition to a new scheme, MITRE would need to
maintain the old naming scheme alongside the new scheme for a
sufficient period of time, perhaps 6 months or a year.  MITRE will
provide a mapping from the old scheme to the new scheme, which will
always be available on the CVE web site.

There could be some problems with old advisories that reference CVE
names.  Those advisories would need to be updated where possible, but
there may be older copies that cannot be changed, such as mailing list
archives.  The advisory provider already has some a small maintenance
cost for changing a CAN number to a CVE number anyway, so it makes
sense to provide a single identifier.  MITRE plans to notify advisory
authors when their CAN's become CVE's on a regular basis, but this
would not be necessary with a unified scheme.


Addressing Misuse and Information Leaks of CAN Numbers
------------------------------------------------------

CAN numbers effectively encode time, which releases potentially
sensitive information such as how soon a vendor knew of the issue.
Users may like this capability in gauging a vendor's response time,
and it may also show how long a researcher has worked with the vendor
on an issue.  For example, Rain Forest Puppy reserved CAN-2001-0001
for an issue, but the vendor was slow in fixing the problem.  RFP was
eventually forced to publicize the issue, when most candidates being
published were in the "200" range (CAN-2001-02xx).  Some Board members
agreed that it could be important to hide this information, possibly
due to previous agreements with vendors.  They agreed that while it
might be useful to some people, it was not essential to have the
candidate name effectively reflect the date of assignment.

It is also suspected that information in the CAN/CVE name is already
misused by the public.  For example, many probably assume that the
year portion of the number is when the issue was first publicized, not
when the candidate number was assigned to the issue.  There may also
be cases in which an entity reserves a block of candidates which are
not assigned to an issue for weeks or months; sometimes an "old"
candidate number may be publicized for a brand new issue, which could
cause confusion on the part of users, or make it appear that the issue
has been known for a long time.

CERT/CC has a numbering scheme that allows them to provide effectively
random numbers that don't give away any temporal information.  The
Board will discuss this approach when considering a new scheme.

While the current scheme is still being used, MITRE will provide more
prominent disclaimers that CAN/CVE numbers do not imply when an issue
was first known, when it was publicized, etc.  MITRE will add these
disclaimers to individual candidates (especially those that are
reserved) as well as the full downloads for the CVE and candidate
lists.


Discussion of Candidate Numbering Authorities (CNAs)
----------------------------------------------------

A detailed proposal for Candidate Numbering Authorities (CNAs) was
sent to the Editorial Board mailing list on June 14, 2001, with the
subject "[TECH] Candidate Numbering Authorities".

So far, various organizations have reserved a total of 170 candidate
numbers for use in first-time public announcements of vulnerabilities.
Approximately 150 of these have been published.

Some Board members have wanted more rapid response in terms of
assigning candidates to new issues, sometimes within hours after the
issue is first published.  MITRE's content team is currently unable to
meet these needs, as some members are also processing the legacy
submissions, and all are still learning how to apply CVE content
decisions appropriately (though much progress has been made in the
last 6 months).

Candidate Numbering Authorities (CNAs) could obtain blocks of
candidate numbers from MITRE and assign them to new issues, without
directly involving MITRE.  CERT/CC and SecurityFocus could be other
CNAs, as they are already involved in the disclosure process as third
parties (intermediaries between researchers and vendors).  Major IT
vendors with a large product line could also be CNAs for their own
products.  For example, Microsoft is already a de facto CNA, as MITRE
provides them with candidate blocks that they assign to issues without
consulting MITRE.

A CNA must be an Editorial Board member, since the CNA must be
familiar with CVE content decisions and the assignment process;
indeed, the CNA may be involved in modifying these.  As a side effect,
the screening process for Editorial Board membership could be used to
filter out unqualified CNAs.

It was suggested that distributing candidates across all parties could
be difficult to coordinate, especially when multiple vendors are
involved.  However, Board members did not think that it would be a
significant problem, as the process for coordinating such information
is already largely in place.

It had been proposed that each CNA could have its own "policy" that
reflects how quickly it responds to a researcher's request for a
candidate number, how closely it works with vendors, what guidelines
the researcher must follow in terms of disclosing the problem, etc.
The intention was to allow multiple CNAs who used different disclosure
policies, different response times, etc.  For example, MITRE's own
"disclosure policy" for researchers might be more restrictive than
that of SecurityFocus.

Some Board members suggested that CNAs should all follow a common
minimal policy for "responsible disclosure," such as working with the
vendor to fix the problems, or giving unresponsive vendors sufficient
time before releasing.  If researchers do not follow that policy, then
the CNA would not provide them with candidate numbers.  Participants
agreed that this was a good approach.

There was some discussion regarding the impact of current disclosure
practices on CNAs.  For example, some researchers may want anonymity
to shield them from threatened lawsuits.  If the researcher wanted to
remain anonymous, but abused the CVE process, then the proposed
approach would require the CNA to notify MITRE of this abuse; this
might not be feasible.  At the least, the CNA should avoid providing
candidates to such researchers in the future.  Some Board members said
that a CNA should publicize the conditions under which they would
protect the anonymity of disclosers.

Some Board members were concerned with how the CNA should protect the
vulnerability information before public disclosure.  It was proposed
that MITRE could set the technical policy that is specific to CVE, and
the CNA could define its own operational policies and procedures.


MITRE will still be available as a CNA to give out candidates to
requesters.  Anybody who asks for one, gets one, provided they make it
public.  To date, all requesters worked with vendors.  MITRE's
response time can be as fast as 2 to 3 hours, but MITRE can't formally
commit to less than 2 business days.  Others may advertise a
better/faster response time.  MITRE would ask the researcher who they
contacted at the vendor.

There was a brief discussion of the concept of "vendor liaisons" for
CVE.  The idea is to allow any vendor to participate in CVE by acting
as a liaison - consulting with MITRE or other Board members on
existing CVE candidates or entries, or by using candidates in its own
security advisories.  Such vendor liaisons would not need to have the
skills and resources to be full-fledged CNAs or Board members.  It
might be useful to publicize such liaisons on the CVE web site so that
researchers and other CNAs would know that they could work with the
liaisons on obtaining candidates.  MITRE will continue to clarify this
role.


Board Membership Issues
-----------------------

Formalized roles, tasks, and expectations were proposed to the
Editorial Board mailing list on June 7.  See:
http://cve.mitre.org/board/archives/2001-06/msg00002.html
http://cve.mitre.org/board/archives/2001-06/msg00003.html

The overall participation by Board members was higher than originally
thought; defining the roles, tasks, and expectations has helped to
clarify how Board members participate in the CVE Initiative.  However,
it is also clear that voting and other activities need more
participation than the current levels.  While the Board currently
consists of 40 member, it might not be enough to accomplish all the
work that is needed.

Since then, Steve Christey consulted with approximately 10 Editorial
Board members regarding their role in the CVE Initiative.  These
one-on-one discussions proved useful in clarifying the roles and tasks
for these members.  While there are too many Board members to maintain
this contact on a regular basis, Steve and other MITRE personnel will
work to maintain contact.  More frequent teleconferences might also
help in communicating with Board members.

It is expected that some members will move to Emeritus status, if they
have made significant contributions to the Board.  MITRE is still
clarifying this role.  For example, if a member occasionally makes
contributions to the CVE Initiative and then leaves, they might not
necessarily achieve the Emeritus status as currently defined by MITRE.
However, such members should be recognized in some fashion.

Some members may be asked to leave the Board.  Steve Christey has
consulted with those members.  Each member has expressed a desire to
stay on the Board.  Each member agreed to a 2 month evaluation period
during which it is expected that they will raise their level of
participation.


Adding New Members
------------------

The Board discussed a basic approach for adding new members.

In the March 2001 meeting, some Board members suggested that MITRE
could ask Board members for feedback on prospective members.  When
MITRE recommends a potential member, the Board could be given a time
limit (at least 2 weeks) to object or provide other feedback.  A
different approach would involve having Board members cast a formal
vote.  Participants anticipated several problems with a formal vote,
such as handling conflicting "accept" and "reject" votes.

Some members discussed the possibility of having a trial membership
period for new members, possibly 2 or 3 months.  This approach would
allow the new member, and MITRE, to be certain that the new member can
accomplish his or her tasks.  In the March 2001 meeting, some members
had expressed concerns with trial membership.  There was mixed
reaction during the teleconference.  In general, it was agreed that
trial membership would not be necessary; MITRE could closely monitor
new members and remove them from the Board if they could not
participate effectively.

Given the feedback by the Editorial Board, the basic process for
adding new members will probably involve the following steps:

1) MITRE will conduct the initial screening of the prospective member
   (similar to MITRE's current screening process).

2) MITRE suggests the prospective member to the Editorial Board on a
   private mailing list.

3) Board members may provide feedback as they see fit.

4) After at least a 2 week period, MITRE decides whether to add the
   member, based on feedback from the Board and its own evaluation.

Currently, MITRE is delaying the review of approximately 10
prospective members until the new process is established.


Miscellaneous
-------------

The following topics were also discussed during the teleconference.

MITRE's lawyers sent a response to the vendor who threatened to sue
MITRE for publishing a candidate for their product.  The response is
available to Board members upon request.  Other Board members had been
threatened by the same vendor, but they did not respond legally,
because the vendor didn't use formal legal channels.

The next face-to-face meeting may take place in mid-September,
possibly the week of September 17.  A hosting organization has not
been found yet.  A side meeting could be held at the RAID Conference,
and an informal meeting could take place at Black Hat.  The next
teleconference will take place in late July or early August.