[CVEPRI] March 9-10 Editorial Board Meeting Summary

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

All:

Below is a high-level summary of some of the discussions that the
Editorial Board had during last week's Board meeting.  I believe that
the meeting went very well.

Since many important issues were discussed that may affect all Board
members, all non-participants should read the full summary and provide
their feedback.

Other participants are encouraged to present their perspective of what
happened during the meetings.  For those who participated via
teleconference, I would appreciate your feedback as well.  This was
the first meeting in which there were more face-to-face participants
than in the teleconference, and I know that some people had problems
hearing the discussions over the phone.  Hopefully we will be able to
address these problems in future meetings.

This summary omits some detailed points that are included in the
slides that were sent to the Board mailing list before the meeting.

- Steve


===========================================================================
Summary of the CVE Editorial Board meeting on March 9-10, 2000
===========================================================================

This summary omits some detailed points that are included in the
slides that were sent to the Board mailing list before the meeting.


Attendees
---------

The attendees of the face-to-face meeting were:

Eric Cole (Vista IT)
Craig Ozancin (AXENT)
Andy Balinsky (Cisco)
David Balenson (NAI)
David LeBlanc (Microsoft)
Tom Stracener (Hiverworld)
Marvin Christensen (IBM ERS)
Ronson Nguyen (Ernst & Young)
Andre Frech (ISS)
Jim Magdych (NAI)

Dave Baker (MITRE)
Steve Boyle (MITRE)
Steve Christey (MITRE)
Margie Zuk (MITRE)


Several people participated by teleconference at various times during
the meeting:

Scott Blake (BindView)
Dave Mann (MITRE)
Pascal Meunier (CERIAS)
Mike Prosser (L-3/Symantec)


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

An update on CVE content was presented.  503 CVE entries had been
approved as of CVE version 20000118, and 634 active candidates had
been proposed.  78 candidates were ready to be moved to Interim
Decision, and 251 candidates were being held back by unresolved
content decisions.  Finally, 92 candidates could be accepted with one
more vote.

Attendees discussed public interest and knowledge about candidates.
On the CVE web site, the number of candidate-related downloads was
about 15% of the number of CVE entry-related downloads.  Some
attendees expressed a need for better explanations of candidates on
the web site, and a description of the fundamental differences between
candidates and entries.


Voting
------

Several important issues related to candidate voting were discussed.
Many attendees said that a web-based interface would help them
significantly with respect to voting.  They would like to be able to
select candidates based on priority, OS family, level of confirmation
(e.g. advisory or Bugtraq posting), service, and other options.  MITRE
will re-evaluate its internal priorities to see when it can support
this need.

The attendees also stated that they did not see a problem with having
MITRE be included as a legitimate voter (current voting rules do not
allow this).  The voting requirement could be modified to allow for "3
ACCEPT votes, not including the discoverer of the problem."

Also, participants outlined a requirement that a voter should be
"reasonably certain" that a candidate has been verified as a real
issue before voting to ACCEPT it.  This certainty could be as definite
as having the voter validate the issue themselves, or as indefinite as
trusting the source of the information; no explicit requirements for
"certainty" were specified.  The voting-related web site could be used
to allow Board members to annotate their votes in order to describe
their level of confidence in whether an issue exists or not.

Attendees also discussed adopting a new ABSTAIN vote, which could be
used for Board members who should not vote against problems in their
competitors' products (or their own, if voting is not appropriate).  A
request was also made to support a "conditional REVIEWING" vote in
which a Board member is REVIEWING a candidate but does not wish to
delay its acceptance in CVE.

There were some discussions regarding voter comments.  Some voters
could be prevented from making some important technical comments if
the comments were to be available to the public.  Mechanisms for
recording private comments were discussed.


CVE-Compatibility
-----------------

Experiences with CVE-Compatibility were discussed.  Several vendors
stated that they are getting asked by their customers about whether
their product is CVE-compatible or not.  One of the obstacles to
achieving compatibility was related to marketing, which may drive
product development more than engineering.

Several vendors discussed issues and problems they encountered while
making their products compatible.  In general, it was easier to make a
product CVE-Reportable (aka CVE-Output) than it was to make it
searchable.  In the process, some vendors were able to discover
duplicates in their own database, use CVE to validate their own
information, or expand the references they used.

Attendees reviewed a portion of the requirements list for
CVE-Compatibility.  Tool vendors expressed a concern that the
Searchability requirement would impose too much of a development cost
at this time, as it could be difficult to design a tool that would
select probes or signatures based on a CVE name.  The requirement for
tool searchability was weakened so that if the vendor provides a
mapping to the user, it is regarded as satisfying the searchability
requirement.  Attendees agreed to let the market decide whether this
approach is sufficient.

In general, while there was concern that the use of the
CVE-compatibility term could be abused, attendees believed that the
market (and competitors) would be self-policing in terms of
determining whether competitors were compatible or not.  They
advocated an increased reliance on the Good Faith efforts of
organizations who seek to provide CVE-compatible products, with less
emphasis on MITRE or other organizations determining the quality of
the compatibility.

Specific requirements for types of repositories (e.g. tools or
databases) were not discussed.


Board Business
--------------

The attendees agreed that August 2000 is a good time frame for the
next face-to-face meeting.  They considered several potential meeting
sites, including: Microsoft during the LISA NT conference (Seattle),
CERT (Pittsburgh), the USENIX Security conference (Denver), and Black
Hat (Las Vegas).

The issue of Board member affiliations was revisited, i.e. whether
Board members were to be viewed as individuals or as representatives
for their company.  The issue was left largely unresolved.  However,
attendees believed that a private mailing list would allow Board
members to raise potentially sensitive concerns or issues without fear
of being seen as representing a company view.  Since the Board has in
the past advocated having discussions be publicly available, some
actions may need to be taken to ensure that the private mailing list
is used sparingly, and only for issues that *must* remain private.

MITRE also presented its guidelines for restricting the maximum number
of Board members that could be represented by a single organization to
two, with some ad hoc exceptions (e.g. if an existing Board member
moves to an organization that already has two members that serve
complementary roles).  MITRE re-introduced the concept of "one
organization, one vote."  Attendees agreed with this approach.

Attendees were comfortable with allowing Board members to consult the
Editorial Board mailing list on non-CVE issues, provided the issues
were related to sharing information and/or discussing "best practices"
related to vulnerability information.  In cases where the Board as a
whole is consulted, it may be appropriate to recognize the
contributions of specific "members of the CVE Editorial Board" instead
of the Editorial Board itself.


CVE-Based Analyses
------------------

Several CVE-based analyses conducted by MITRE were presented.  The
rationales for the analyses were discussed, such as using them to
highlight a concrete "success story" for CVE, to show other potential
analysts what could be done with CVE, and to explore the applicability
of CVE to these analyses in the first place.

Attendees were provided with the results from ID'Net at SANS NS '99.
Some IDS vendors expressed concerns that since CVE was focused on
vulnerabilities and exposures, that it was not necessarily useful for
conducting a full-fledged comparison of IDSes, which focus more on
signatures related to attack patterns rather than the exploitation of
specific vulnerabilities.

Some discussion was also held regarding the vulnerability summary
comparison.  Since the results were anonymized, and details omitted,
attendees could not effectively interpret the results.  In general, it
was believed that a longer-term effort would provide more reliable
data, and that such an analysis should include topics in the summaries
that do not map to CVE entries or candidates.  MITRE has not yet
decided whether it will continue this analysis or not.

The role of MITRE, and of Steve Christey in particular, was discussed
in relation to the execution and publication of these sorts of
analyses.  However, strong concerns were expressed with respect to how
closely these analyses should be tied to the CVE Initiative and to the
Board itself.  In general, attendees seemed to agree that it was
reasonable to conduct such analyses for the purposes of educating the
public about the possibilities of CVE, provided (a) the results were
anonymized, and (b) the activities were disassociated from the Board
and the CVE Initiative itself.  The upcoming use of CVE in ID'Net was
discussed.  MITRE also told the Board that it expects to conduct
CVE-based analyses in the future, for its internal use or for its
sponsors, and that Steve Christey might play a part in such analyses.


Content Decisions
-----------------

This summary assumes that the reader has reviewed the Content
Decisions section of Day 2 of the PowerPoint slides for the meeting,
which includes a description of each Content Decision as well as some
examples.

Each of these content decisions (CD's) will be proposed and reviewed
over the course of the next few months.

As expected, content decisions made for some of the liveliest
discussions during the two day meeting.  Several CD's were discussed,
but some examples did not include enough information for the Board to
make well-informed decisions.  Some attendees advocated that
candidates should be evaluated on an ad hoc basis due to the
complexity of the problem, instead of attempting to define more
principled approaches.

The CD's that were already approved by the Board were reviewed,
including CD:DEFINITION, CD:INCLUSION, CD:DIFFUNC, CD:HIGHCARD, and
CD:DOT.

A long discussion was held relative to CD:CF-DEF-PASS.  Most attendees
agreed that having a single entry for each different default password
would result in a large number of entries and make CVE unmanageable.
It was discussed that in some cases, the owner of a password
"dictionary" might not even know if a password is a default password
or not.  Some attendees advocated using a single, high-level entry for
"use of a default password."  In general, however, attendees agreed
that it would be best to use a medium level of abstraction.  Breaking
down the passwords by service type (e.g. POP, SNMP, login, etc.) was
regarded as a reasonable approach.  A brief discussion was held with
respect to the issue of potential overlap between services that use
the same authentication mechanism (e.g. FTP and login using the same
password file), but attendees in general seemed to be willing to live
with having separate entries even if they produced some overlap.
Attendees also discussed the use of Dot Notation for specifying
individual default passwords in CVE candidates/entries.  Some people
advocated that including the specific password would support CVE name
lookup, comparison of tools, and user education.  Others did not see a
need to be specific.  Back door passwords were considered a different
issue than the one addressed by CD:CF-DEF-PASS, so were not included
in the discussion.  In general, attendees agreed that it made sense to
distinguish between "default" passwords and "blank or easily
guessable" passwords.

The Board also spent a significant amount of time on the Same
Attack/Same Codebase debate (CD:SF-CODEBASE).  The initial discussion
of CD:SF-CODEBASE was intended to decide what to do in the cases when
there is not sufficient information to determine if two problems arise
from the same codebase or not.  Most of the discussion, however,
focused on whether the Same Attack or Same Codebase approach was
better for CVE, even though the issue had been finalized in July 1999.
(See http://cve/Board_Sponsors/archives/msg00142.html,
http://cve/Board_Sponsors/archives/msg00182.html,
http://cve/Board_Sponsors/archives/msg00213.html,
http://cve/Board_Sponsors/archives/msg00217.html,
http://cve/Board_Sponsors/archives/msg00232.html, and all followups to
these emails.)  It was noted that many of the Board members at the
face-to-face had not been on the Board during the time of the initial
discussions.  There was not a clear way to resolve the dilemma in
which later Board members may strongly disagree with decisions that
were made by an earlier "version" of the Board, or how to address the
inconsistencies in CVE if changes were adopted.

CD:SF-EXEC was also discussed, but the examples did not provide
sufficient details to make any concrete decisions.  In general,
attendees believed that if problem A in one executable was always
present with problem B in another executable, and A and B were fixed
by the same patch, that it made sense to keep A and B within the same
entry.

The Board also reviewed CD:EX-BETA.  Attendees agreed that CVE should
include problems in beta software, provided that the beta code was
intended for public dissemination.

CD:EX-CLIENT-DOS was also discussed.  Most attendees agreed that it
was reasonable to exclude a client-side DoS from CVE, provided: (a)
the DoS was limited to the client application itself, and (b) the DoS
could only be triggered by a passive attack (i.e. in some way it must
be initiated by the client).

CD:EX-ONLINE-SVC was also discussed.  While most tools would not
include problems related to online service providers such as Hotmail
or DoubleClick etc., the attendees recognized that these types of
problems could be of concern to consumers.  A general rule of thumb
was discussed, namely: if the "fix" to the problem can be performed by
the online provider on a universal basis without any user
intervention, then the problem should be excluded.  Anything that
required "client-side" action (such as installing a patch) should be
included.

Finally, the attendees discussed CD:DESIGN-WEAK-ENCRYPTION.  Most
attendees agreed that vulnerabilities related to trivial encryption
such as XOR should be included in CVE.  There were no concrete
conclusions made as to whether "weak" encryption should be included in
CVE or not, although in general it seemed that the attendees favored
excluding weak encryption from CVE.

There was not sufficient time to discuss the other content decisions.
They will be proposed to the Board and discussed at a later date.


Future Efforts
--------------

MITRE presented some of its internal goals for CVE, which includes an
attempt to expand CVE so that it provides 80% coverage of security
tools.  A concerted effort could take place in which participants
would work more closely to achieve this level of coverage.
Participants would receive backmaps and could help determine which
legacy candidates get created and proposed first.  Participants would
be required to vote more actively on those candidates.  Some members
expressed interest in this effort, which could take place within a
"working group" of the Editorial Board.

MITRE also asked participants to send a full database dump so that it
could better prepare the next clusters of legacy candidates for voting
by the Board.  This would help MITRE to prioritize which legacy
candidates to propose first, as well as providing extensive backmaps
to potential voters which could in turn speed up voting.  A more
limited effort was performed in November (with the "top 100 lists"),
but there was very little overlap in all the submissions that were
sent in.  Several organizations agreed to provide their databases.
MITRE is willing to sign non-disclosure agreements if necessary.

Other goals were identified, including: (a) achieve 700 entries by May
1, (b) resolve 15 content decisions by May 1, (c) create candidates
(and then entries) for all security advisories published in 1999, (d)
achieve 1000 entries by September 1 (with an intermediate goal of 850
by July 1), and (e) have MITRE propose a total of 1000 additional
legacy candidates by September 1.

The attendees also expressed a strong desire that CVE should encompass
non-vulnerability-related IDS signatures, e.g. port scanning
activities.  The attendees agreed that the current focus should remain
on vulnerabilities and exposures.  An IDS "working group" of the Board
may be created to discuss IDS-related issues.