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

[CVEPRI] Editorial Board Teleconference Summary - October 17, 2002

Editorial Board Teleconference Summary - October 17, 2002


Participants in the teleconference included:

  Jimmy Alderson (e-Security)
  Stu Green (Tiger Testing)
  Bill Wall (Harris)
  Tim Collins (NFR)
  Dave Mann (BindView)
  Andy Balinsky (Cisco)
  Dana Foat (NSA)
  Andre Frech (ISS)
  Ron Nguyen (Ernst & Young)
  Pascal Meunier (Purdue CERIAS)

MITRE participants included:

  Margie Zuk
  Steve Christey
  Barbara Pease

Topics of Discussion

 - Candidate Reservation
 - Content Decisions (CDs)
 - Additional CVE/CAN Data Fields
 - Use of References in CVE
 - Large-Scale Changes to the Next CVE Version
 - Major Editorial Board Membership Changes
 - CVE Compatibility Update

Candidate Reservation

There has been a noticeable increase in the number of candidates being
reserved before the issue is public, primarily from additional
research groups.  More vendors are starting to use candidates in their
advisories, especially open source vendors.  MITRE has worked closely
with Mark Cox of Red Hat in reserving many candidates, also discussing
the application of content decisions.  Red Hat is now a Candidate
Numbering Authority and has a pool of "empty" candidates for it to
assign to new issues without consulting MITRE.

Recently, Microsoft reserved and published a new candidate for a
well-known issue that already had a candidate.  The normal CVE rules
for duplication would say to prefer the Microsoft-generated candidate,
since it was more authoritative than the original announcement, which
was not coordinated with Microsoft.  However, the older candidate had
been out for a few months, and since the issue was well known, the
older candidate was probably in heavy use.  It was decided that MS
would change its bulletin to point to the original candidate.  The
MS-assigned reservation duplicate will be REJECTED.

A separate post on reservation duplicates was sent to the Editorial
Board on October 9.

Content Decisions (CDs)

Several content decisions will be finalized.  They have been
well-tested over the last year.  All content decisions will be
published on the CVE web site, with individual CVE's linked to their
CDs.  This will "release" a large number of candidates and allow them
to be promoted to official CVE entries.  Some affected candidates will
need to be RECAST to reflect the new CDs.  The mechanics for
performing the RECAST operation are still uncertain.

Additional CVE/CAN Data Fields

MITRE is considering publishing, or otherwise making accessible,
several additional data fields that are ot easily accessible to the
public at this time.  These fields will help certain CVE consumers in
how they manage the CVE list.  However, any possible concerns about
"competing" with other information sources should be addressed.  As
the fields will have important uses but for a limited audience, they
will not be included in the regular downloads, but as a separate

All feedback is welcome.

  CVE-specific fields

  These fields are specific to the maintenance and management of CVE
  and as such do not directly compete with any other information

  1) ANALYSIS - This field includes information on how content
     decisions were applied, how vendor acknowledgement was determined
     if it is not immediately clear from the references, records of
     email acknowledgements from vendors, and issues related to
     accuracy.  This information is technically public in the CVE
     Editorial Board archives, as it is part of the voting ballot that
     is sent out to Board members.  The information is important for a
     small but expert set of consumers, mostly CVE-compatible vendors.

  2) CONTENT DECISIONS - This field identifies which content decisions
     affect a CVE item.  Technically public since it is part of the
     voting ballot, this field is important in exposing to end users
     how CVE distinguishes between similar vulnerabilities.

  3) VENDOR ACKNOWLEDGEMENT - This field, which is also technically
     public, says whether the vendor has publicly acknowledged the
     issue or not.  This may help some consumers understand why some
     candidates do not receive sufficient votes, and provide a "clean"
     way to compare the responsiveness of various vendors.

  Other useful fields

  These fields are not specific to CVE, but they may be useful to
  certain consumers, or provide valuable information to the public
  which is not otherwise available.

  4) VULNERABILITY TYPE - This field identifies the vulnerability type
     of the CVE item (buffer overflow, format string, etc.)  This
     information could provide a rich data set for the community to
     use in studying vulnerabilities at a greater level of detail than
     previously possible.  We have been tracking these flaw types
     since 2000, and is unaware of any other efforts that have this
     level of information.  While we are comfortable releasing summary
     information for groups of issues, we have had to "hold back" on
     some studies that would provide this information to outsiders on
     a CVE-by-CVE basis; it would be best to provide this information
     to everyone.

  5) ANNOUNCEMENT DATE - This field is used to generate candidate
     clusters.  It may be helpful for certain consumers to obtain CVE
     items that were published after a certain date.  I have also used
     it heavily in various unpublished studies of disclosure

Use of References in CVE

Some vulnerability researchers have been requesting that the
references for CVE items directly link to advisories that are archived
on their site.  The general CVE approach has been to identify the
posts fo well-known mailing lists instead, as they are archived in
multiple places and less likely to disappear than an individual web
site.  However, with CVE reference sources such as "ATSTAKE" and
"ISS," there is an implicit "preference" of certain research groups
over others.

Since many research groups don't last very long, or they do not
consistently produce new information, there is some reluctance to
provide a new reference source name for each group.  Consistent
"rules" need to be developed to determine when a group is given its
own source name.  Until those rules are completed, MITRE will use the
"MISC" reference to point directly to the advisory on the group's web
site, while simultaneously listing any related mailing list posts.

Large-Scale Changes to the Next CVE Version

Almost all CVE entries will be modified in the next version, including
fixed typos, changes to reference names, and additional references.
ISS changed their reference naming scheme about a year ago, and this
affects almost all CVE entries.  SecurityFocus also contributed a
number of changes in the BID references.

Because of the large number of changes, MITRE will only notify Board
members of the substantive differences ahead of time.

At some time in the future, MITRE will begin to include URLs in the
official CVE list.  All potential concerns have been addressed in
private discussions with the relevant parties.

Major Editorial Board Membership Changes

Starting in November, MITRE will be making numerous changes in
Editorial Board membership.  Approximately 10 individuals or
organizations have requested membership and are in the evaluation
stage.  This includes some prospective members for the CIEL effort.  A
number of members will also be leaving the Board.

In some cases, an individual may leave the Board, but want to have a
replacement from the same organization.  It seems reasonable to give
some preference to these replacements, who still must go through the
same review process as new prospects.  Practically speaking, such a
preference would not provide substantive benefits, as it would only
affect the order in which prospects are contacted.

Several departing Board members will be given an "Emeritus" status in
recognition of major contributions to the CVE effort.  It will be up
to Emeritus members as to how "active" they wish to remain.

Past discussions have considered omitting departing members who did
not provide some minimum level of support to the CVE effort.  However,
there has been some difficulty in devising criteria for distinguishing
between "contributing" members and those who did not contribute.
MITRE may decide not to make this distinction and recognize all former
members regardless of their level of contribution.

CVE Compatibility Update

The beta test for the CVE compatibility evaluation process is nearly
complete.  MITRE has contacted nearly all vendors who have publicly
declared their intentions to become CVE compatible.  MITRE plans to
evaluate a number of products, then unveil a large group all at once.

The CVE compatibility section of the CVE web site was recently
modified.  See http://cve.mitre.org/compatible


After the Editorial Board teleconference, MITRE discussed its new Open
Vulnerability Assessment Language (OVAL) project with members of the
OVAL Board, most of whom are also members of the CVE Editorial Board.
Details on this project, which MITRE regards as a follow-on activity
to CVE, are now publicly available at http://oval.mitre.org.

Page Last Updated or Reviewed: May 22, 2007