CVE Review Meeting summary - Friday Aug. 13

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

Below is the summary for the CVE Review Meeting.  I welcome any
feedback.

The most salient points are related to use of the term "CVE
compatible" instead of "CVE compliant," the recognition of a greater
responsibility for members to vote (even if it's a NOOP) and for the
Moderator to ensure adequate voting, keeping most aspects of the
Editorial Board informal, publication of references, and the possible
benefits of private channels for discussion of some candidates.

- Steve




Attendees
---------

Craig Ozancin (Axent), Bill Fithen (CERT), Mike Prosser (L-3), Andre
Frech (ISS), Steve Christey (MITRE), Margie Zuk (MITRE), Dave Baker
(MITRE), Bill Hill (MITRE)

Lunch with Pete Tasker (Director, MITRE Security & Information
Operations Division) and Jeff Sebring (Department Head, MITRE
Enterprise Security Solutions Department)


Introduction
------------

Margie Zuk and Steve Christey presented thoughts on how the Editorial
Board is evolving, and included some proposals for further refinement
of the process and structure.  These proposals were intended to begin
the dialog on these issues and gain feedback.  This review summarizes
those discussions, but any of the presented issues may be addressed by
the Board.


Roles and Responsibilities
--------------------------

Board attendees were comfortable with leaving roles and
resonsibilities fairly undefined at this time, since most participants
play multiple roles, and the process seems to be working fine at this
time.  The one distinction is the Moderator, who will be the focal
point through which some Board activities will take place.  Members
can be voting members, or non-voting members (observers).  Observers
could be on the Board's mailing list, but generally wouldn't
participate directly in Board activities.

While responsibilities will not be specifically identified at this
time, there should be overall guidelines and guidance.  Some of those
are already discussed in the slides, and cover "minimum" participation
for members (to be interpreted by the Moderator).  While Board members
should show an appropriate level of participation, the Moderator
should interface with members to keep their participation active, or
accommodate situations where they may need to be inactive.

Attendees had no problem with multiple people from the same
organization being on the Board and voting, e.g. if multiple
individuals bring their technical expertise to Board activities.  A
number of active organizations have more than one member; generally,
one is a voting member, and another is an observer.  Attendees were
comfortable with this approach, and did not believe that it posed a
significant problem if one vendor had more members on the Board than
another.



Voting
------

In many cases, the "Silence = Assent" rule is not appropriate and
could produce inaccurate results.  Therefore, members should be
encouraged to vote on specific issues.

It was suggested that to effectively decide an issue, at least 75% of
active members should vote - though in practice up to this time, the
percentage has rarely been that high.  A "No Opinion" or "Abstain"
vote should be allowable, and voters should be allowed to respond
personally to the moderator if they wish.  Voting activities should be
public where possible, although in some cases they could be held in
private, e.g. for acceptance or removal of a member, or for some other
(hopefully rare) issues.

It became clear during the Review meeting discussions that sufficient
validation for a candidate is a requirement for its acceptance.
Independent validation by 2 Editorial Board members, or more, should
be used to provide a sufficient guarantee that the vulnerability being
discussed truly exists.  The voting "ballot" provided for individual
candidates could be modified to allow Board members to register
whether or not they have independently confirmed a vulnerability.



Member Acceptance/Removal
-------------------------

While largely informal, it was recommended that the Moderator should
initiate Board discussions for either acceptance or removal.  A
private vote is held in either case, to avoid potential embarrassment.
In the case of removal, the "public" face of the removal may merely
indicate that someone has become a non-voting member, or an observer;
the percentage of yes/no votes should not be provided.

Attendees did not believe it was important to overly formalize the
criteria for the removal of a member; the reasons outlined in the
slides were useful (e.g. abuse of membership, insufficient
participation, etc.)



Size
----

No limits for the size of the Board were discussed - play it by ear at
this time, and reevaluate if the Board's size becomes too unwieldy.


Periodic Meetings
-----------------

A meeting will be held Oct. 3 before SANS, in order to discuss the CVE
"big splash" to be held that week.

Meetings should be regularly scheduled; at this time, quarterly seems
appropriate since the CVE and the Board are still under rapid change.
They could be held before or after a conference at which some Board
members may be present.  A teleconferencing capability may be useful
to allow other non-attending Board members to participate.

Meetings could also be moved around different Board member facilities.
This would allow Board members to talk to other people in the host's
organization.



Voting and Affiliation
----------------------

Review meeting attendees were comfortable with having both
"individual" and "representative of company" roles, though they did
not see a need to formalize those roles.  The individual should make
it clear which "voice" they are using when they speak, and MITRE
should make certain to reflect that voice.

Strongly related to the Editorial Board may be a "CVE
Alliance/Partnership" which consists of *organizations* that are
actively participating in the public release of the CVE, and/or
release of vendor mappings.  The CVE Alliance/Partnership may be
useful in introducing the Interoperability Demo at SANS Network
Security '99.



Speaking for the Board
----------------------

The Moderator speaks for the Board, or appoints someone else to do so.
In some cases, it may be appropriate for the Editorial Board itself to
make statements as a group on various issues, e.g. "publicly sharing
data is good, even if sometimes it helps the hackers."  The Board may
provide an opportunity to present a unified voice for a broad variety
of perspectives and constituencies.

There are no restrictions to Board members for talking about their
activities on the Board, provided they are speaking for themselves or
their company.  For the initial CVE release, it's agreed that press
releases, statements, or other "promotional" considerations should be
coordinated to have the most significant impact in the community.  In
general, it is recommended that organizations should verify their
press releases where possible, e.g. when describing what type of
company MITRE is.



CVE Searchability
-----------------

What terminology should be used when describing how a database/tool
"speaks" CVE?  CVE "compliance" implies some degree of verification.
"CVE searchability" is descriptive of web sites or databases, but not
interoperability.  "CVE compatible" seems appropriate, and should
indicate a good-faith effort to use CVE names where possible, maintain
accuracy, and fix inaccuracies when discovered.  We may also want a
phrase for "milder" conformance or support, e.g. CVE-Friendly (or
"CVE-supportive").  So supporters of the CVE, or people who reference
CVE but don't have databases, can indicate support.

To prevent abuse of this phrase, it was recommended that MITRE should
trademark the CVE term (to prevent it from being co-opted by another
entity who trademarks it, forcing MITRE to change to the term) and use
a service mark for "CVE-compatible" and possibly other phrases.  The
Board doesn't think this will reflect negatively on MITRE in terms of
"preparations" for commercial gain.  MITRE will need to assume
liability and take steps to protect the trademark (e.g. by preventing
its abuse, as well as verifying the claims.

There was a question about how specific the criteria for "CVE
compatibility" should be.  We should be specific enough to distinguish
the MITRE evaluation of compatibility from evaluations that others
might do.

With respect to testing for compatibility, random sampling was
suggested.  However, a more "focused" sample might be better, i.e. a
sample that's designed to reflect significant content decisions or places
where inaccuracy can be a problem.

All testing *MUST* be specific to a CVE version, since the CVE can
change significantly from week to week, especially as we try to
back-fill older vulnerabilities.




CVE vs. CMEX
------------

There was strong support for making the references available to the
public, since they help to verify that you know what vulnerability
you're really looking at.  But how can we cleanly separate the
references (a CMEX item) from the "pure" CVE?

With respect to universal attributes and categories, they are
extremely useful to people who map to the CVE; but they aren't
necessary to the general public.  Therefore we can make this portion
of CMEX available to those mappers who request it.  With respect to
the Universal attribute, we could use it to create a "Universal
sublist" which could be downloaded from the site, for those
individuals who prefer using the Universal vulnerability definition.

References to private information sources may be useful, but they
should be kept in a separate extension (not CMEX).  Distribution of
these references was not discussed.




Private Channels to Discuss Candidates
--------------------------------------

There are a few situations where private communications may help to
facilitate the proposal, discussion, and acceptance of some
candidates.  Private channels may be useful for discussing emerging
(but not publicly known) vulnerability information, in order to (a)
present a candidate whose acceptance is nearly guaranteed, or even (b)
to hold private votes on some candidates, in order to present an
accepted CVE name in advisories.  Both uses may help to reduce the
lifetime of a candidate number for some newly discovered
vulnerabilities, which may prevent some confusion between CVE
candidates and CVE vulnerabilities.  If a full vote for acceptance is
conducted in a private channel, those votes must still be made public
upon acceptance.

Some candidates may be proposed for which public information is not
available (e.g. when a vendor discovers a vulnerability in their own
software, or a response team is notified of a new problem that has not
yet been publicly discussed).  Private discussions may be useful for
other Board members to understand the candidate, or to validate it
independently.  This could streamline the candidate's acceptance.
Thus when an advisory is released, that advisory may reference a
candidate number or, in some cases, a CVE number.  A Board member may
have private discussions with other "trusted" Board members.  In some
cases, the proposer of the candidate may be prevented from releasing
too much information about the vulnerability.