[CVEPRI] Summary of the August 14-15 CVE Editorial Board meeting

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

All,

Below is the summary for last week's Editorial Board meeting.  Thank
you to everyone who participated!  For us at MITRE, we find that these
face-to-face meetings often clarify the appropriate direction for CVE,
at least for the next few months :-) This meeting was no different.
As a result of this meeting, we expect to make final decisions on a
number of long-drawn-out issues.  Expect this mailing list to be
pretty busy for the next few weeks as everything is documented...

As discussed at the meeting, the primary goal for the Editorial Board
will be achieving 1000 entries for CVE by September 29.  Enhanced
voting support will be provided in the coming weeks to help Board
members achieve this goal.  I am looking forward to working with the
Editorial Board to achieve this milestone.

- Steve



****************************************************************
Summary of the CVE Editorial Board meeting on August 14-15, 2000
****************************************************************

Attendees
---------

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

Ken Armstrong (EWA-Canada/CanCERT)
Andy Balinsky (Cisco)
Casper Dik (Sun)
Andre Frech (ISS)
Bryan Kingsford (AXENT; proxy for Craig Ozancin)
Scott Lawler (DoD-CERT)
David LeBlanc (Microsoft)
Ron Nguyen (Ernst and Young)

MITRE participants included Steve Christey, Dave Baker, and Margie
Zuk.


The following participated by teleconference during a portion of the
meeting:

Kevin Ziese (Cisco)
Mike Prosser (Symantec)
Barbara Pease (MITRE)



CVE Content Update
------------------

The Board was updated with the latest statistics for CVE content.  The
most recent version was 20000712, with 813 additional active
candidates as of August 11.  In recent months, the number of official
CVE entries has been about the same as the number of candidates.  This
is an indication that the Board can keep up with the current flow of
recent vulnerabilities, but may fall behind once new sets of legacy
candidates are created and proposed.

Of the 10,000 vulnerability submissions that MITRE is processing,
approximately 600 have been matched against other submissions, CVE
entries, or candidates.  The focus has been on problems discovered in
1999.  Once all remaining 1999 submissions are matched, they will be
refined into legacy candidates.  It is estimated that about 380 new
candidates would be produced from the 600+ submissions that have
already been matched.


Latest CVE Content Goals
------------------------

The latest CVE content goals were presented.  The primary goal at this
time is to have CVE contain 1000 entries by September 29.  This will
be achieved by a number of means.  Various content decisions will be
resolved by September 1, which will allow some candidates to be moved
to Interim and Final decisions.  Also, tailored voting ballots will be
sent to Board members.  This approach worked successfully in September
1999 when preparing the first public version of CVE.

MITRE also plans to finish processing submissions for the 1999
problems by September 15, with the final rounds of 1999 candidates to
be proposed by October 31.

An additional goal is to maintain more comprehensive sets of
references for new candidates and entries, with a special focus on
vendor and response team advisories.  MITRE has relied heavily on its
original data feeds, as well as votes by Board members, to provide
references.  Board members are encouraged to identify missing
references when voting.


Use of CVE Versions in Products
-------------------------------

Participating Board members were asked whether their CVE-compatible
products were up-to-date with the latest CVE version.  Participants
indicated that their products were not yet up-to-date.  Most
participants have an ad hoc process for integrating new CVE
information into their products.  It was emphasized that CVE versions
will become more important for vendors and their customers to
understand how up-to-date their products are with respect to CVE
mappings.


Submission Stage
----------------

Participating Board members were briefed on the submission stage in
the CVE process.  MITRE performs much of this work behind-the-scenes,
but since it is a critical part of CVE, it was described in more
detail.

The CVE review process is divided into 3 stages: the initial
submission stage, the candidate stage, and the entry stage.  MITRE is
solely responsible for the submission stage.  The Editorial Board
shares the responsibility for the candidate and entry stages.  During
the submission stage, MITRE collects raw information from various
sources, e.g. the various Board members who have provided MITRE with
their databases, or publishers of weekly vulnerability summaries.

Each separate item is then converted to a "submission," which is
represented in a standardized format that facilitates processing by
automated programs.  Each submission includes the unique identifier
that is used by the data source.  After this conversion phase, various
utilities are used to help find which submissions are closely related
(the "submission matching" phase).

Presently, the main focus of MITRE's CVE content team is on submission
matching.  This will allow content team members to gain familiarity
with CVE, as well as to understand how vulnerability databases may
differ with respect to inclusion and levels of abstraction.

Once matching is complete, related submissions are formed into
submission groups.  Each group is then analyzed and refined into a
single candidate template (the "submission refinement" phase).
Content decisions are applied to the submission group to determine
whether the security problem should be included in CVE, and to
determine the level of abstraction.  A CVE-style description is
written, and references are collected and presented in the
canonicalized format used by CVE.

Submission refinement is a bottleneck because deep analysis can be
required to apply the content decisions and write the descriptions.
In the future, members of the CVE content team will be participating
in the refinement of legacy submissions into candidates.

After submission refinement, each candidate template is converted to
the CMEX data format and given a candidate number, which begins the
the assignment phase of the candidate stage.  After candidate
assignment, each data source is provided with a backmap from their
submission to the associated candidates.  This in turn reduces the
amount of effort that the data source needs to perform to maintain a
mapping to CVE.  After the backmaps for the candidates are generated,
the associated submissions are removed from the submission pool.
Candidates are then grouped into clusters, proposed to the Board, and
moved through the candidate stage as described elsewhere.

In addition to backmaps, a new type of map referred to as a "gapmap"
is also provided to the information source.  The gapmap identifies the
newly created candidates that were not found in the data source's
original set of submissions, which may make the source aware of
additional security problems that they had not seen previously.

It was noted that MITRE is providing backmaps and gapmaps as a value
added for its data feeds only.  This capability may not be provided
once all legacy issues have been identified, although data sources for
new information will continue to receive them.

All CVE data sources will be credited on a web page on the new CVE web
site.


Managing CVE and Candidate Content Changes
------------------------------------------

Participating Board members discussed the processes for rejecting and
recasting CVE candidates and entries.

Candidate rejection was the initial topic.  A candidate may be
rejected for several reasons, including: (a) it is a duplicate of
another candidate/entry, (b) the security issue was incorrectly
reported, (c) as part of a RECAST, (d) due to insufficient references,
or (e) due to insufficient votes.  In the case of insufficient votes,
however, there is a concern that a security problem may still be real,
even if there are not enough Board members who believe so.

The rejection process was described as follows.  The CVE Editor
(presently Steve Christey) will case a REJECT vote and move the
candidate to Interim Decision.  If the candidate is a duplicate of
another candidate, it is left to the Editor's discretion as to which
candidate should be REJECTed.  The voting record for the candidate
will note the reason for rejection.  In addition, the description will
be modified to include a specific keyword to make it clear that the
candidate has been rejected.  The candidate will be removed from the
the list of candidates that is available for download from the CVE web
site, in order to avoid any possible subsequent use of that candidate
to identify a security problem.  A list of rejected candidates will be
made available upon request.

Board members briefly discussed the idea of rejecting candidates that
are related to very old vulnerabilities, e.g. the Sendmail WIZ
problem, that may not be present in any networks.  It was noted that
even the WIZ bug may still be present.  Also, even if such
vulnerabilities are not found in the wild any more, they may be used
for academic study or other reasons, so should remain in CVE.

The process for performing a candidate RECAST was then discussed.  A
RECAST may occur when the level of abstraction (LOA) for a candidate
is too high or too low.  Since each RECAST will increase the
maintenance costs for products that use candidates, a method needs to
be selected that reduces the amount of maintenance, while avoiding
changing the semantics of any existing candidates.  Two approaches
were discussed: (a) changing the LOA of existing candidates, or (b)
creating a new set of candidates.  All participants agreed that it
would be best to create a new set of candidates and reject the old
candidates.  This would make it more clear when a product is using an
old candidate number.

The process for performing a RECAST was described as follows:

  - perform the RECAST during the modification phase
  - create or reject additional candidates in the same RECAST action
  - move all affected candidates to Interim and Final Decisions at the
    same time
  - if any new candidates are created, Board members must vote to
    approve them.  However, these candidates would not be subjected to
    the minimum review period of 2 weeks, which is normally used for
    candidates that are newly proposed.
  - annotate the rejected candidates with the reason for the RECAST,
    and a pointer to any new candidates that were created as a result
    of the RECAST

When the LOA is too high for a candidate, the RECAST operation would
involve a SPLIT of the candidate into two or more lower-level
candidates.  The original candidate is REJECTed, and new candidates
are created which reflect the lower LOA.  If another candidate already
exists at the proper lower LOA, then it may be reused.  The original
candidates are annotated appropriately to reflect the RECAST.

In a similar fashion, when the LOA is too low for a candidate, it will
be MERGED with other candidates.  The original lower-level candidates
are REJECTed, and a new candidate is created to reflect the higher
LOA.  If another candidate already exists at the proper LOA, then it
may be reused.  The original candidates are annotated appropriately to
reflect the RECAST.

In some cases, there may be a single candidate that is described at a
low LOA, but whose description only requires a minor modification to
change the LOA.  For example, a security problem might be discovered
in one Linux distribution, and the resulting candidate may only
indicate that distribution in the description.  If other distributions
are also found vulnerable, then a "soft RECAST" could be performed by
changing the description instead of creating a new candidate.

Once a CVE entry has been added to the official list, it may also need
to be modified, rejected, or recast sometime in the future.  Board
members agreed that the process should be consistent with that for
candidates.

After publication, minor modifications may be made to an entry, e.g. a
small change to the description, or additional references.  In the
past, modifications have occurred without warning.  Board members
suggested that such modified entries should be made available for
review by the Board to provide members with an opportunity to catch
any errors.  Such a review period could automatically expire after a
period of time (e.g. a week), and the entries could be modified with
no further comment.

In the case of a potential RECAST or REJECT, the entry enters the
Reassessment phase.  The same procedure for candidates is followed
with respect to performing the RECAST/REJECT.

If the Board agrees with the decision, some entries may need to be
rejected by entering the Deprecation phase.  Participants agreed that
once a security problem becomes a CVE entry, that it should not be
deleted from the CVE lists, even if it is deprecated.  Instead, all
deprecated entries will be annotated with the reason for deprecation,
as well as a special keyword to help CVE users easily find deprecated
entries.


CVE References
--------------

General guidelines were presented for the ordering of references in
CVE entries and candidates.  The initial public announcement is listed
first, followed by incident response team advisories, vendor
acknowledgement (e.g. an advisory or patch description), and other
public sources.  Older candidates or entries may not have this
ordering.  In some cases, it can be difficult to create references for
advisories that can't easily be found on the source's web site, or for
advisories which do not have a clear identification number.

The sources for CVE references were also discussed.  Currently, only
well-established sources are included, and each source must have some
mechanism for public review, e.g. Bugtraq or NTBugtraq.  However,
vulnerability databases are beginning to include pointers to less
established sources, e.g. the informal vulnerability analysis teams.
In such cases, the CVE reference may refer to the original *Bugtraq
posting or other reviewed source.  However, since other databases are
using these sources, they should be included in some fashion in order
to allow CVE users to find the proper CVE entry.

Minimum requirements for using reference sources were discussed.
While not formalized, there was general agreement that a source should
be in existence for more than a year (indicating some degree of
stability), discover or publicize at least 3 vulnerabilities or
exposures that become CVE entries (indicating some degree of
reliability), and be used as a reference in some vulnerability
databases.

URL's for references are recorded with candidates to facilitate
voting.  However, the URL's are deleted when the candidate becomes an
entry.  Participating Board members agreed that URL's should remain
associated with references for CVE entries, as it increases the
usefulness of CVE for those who require more information.  However,
since this increases the potential for some "competition" with
existing vulnerability databases, MITRE needs to ensure that all
potentially affected parties agree with the usage of URL's.

Reference maps were also described to the Board members.  On the new
CVE web site, each source will have a mapping which links the
references from that source to the associated CVE entries or
candidates.  This allows someone who knows a particular reference to
find the CVE items that are related to it.  Reference maps are
expected to be useful for anyone who performs mappings to CVE, as well
as people who wish to quickly find all the CVE items that are
associated with a particular source, e.g. CERT advisory number or the
Bugtraq ID.


Private and Out-of-Band Candidate Assignment
--------------------------------------------

"Private candidate assignment" is the relatively new capability in
which MITRE provides a requester with a candidate number so that the
requester can include the candidate in the initial public announcement
of the associated vulnerability or exposure.  In general, the response
time for private candidate assignment is 4 business hours or less.
When MITRE has finished defining the process and infrastructure for
reliably and rapidly providing candidate numbers to requesters, it
will open private candidate assignment to all requesters.

One way to enhance this capability would be to provide additional
non-MITRE Candidate Numbering Authorities (CNA's) with a pool of
candidates which they can distribute to requesters.  However, various
issues of coordination across CNA's must be resolved first.

Some challenges that remain for private candidate assignment are:
refining the process by which the original requester makes MITRE aware
that the candidate has been publicly announced; how to reuse or expire
candidate numbers that have not been published; and how to update
advisories and other documents once the candidate becomes an entry.
Most of these challenges can be resolved by providing additional
documentation to requesters and relying on CVE diligence levels to
curttail improper use.

Out-of-band candidate assignment was also described.  The objective of
out-of-band assignment is to assign and announce candidate numbers as
soon as possible for important vulnerabilities, e.g. those that would
allow compromise of a large number of systems.  In the past, Board
members have agreed that it is not necessary to try and assign
candidates the moment that an issue is published, so rapid assignment
has been a relatively low priority for MITRE.  As a result, candidate
numbers are not immediately assigned when a significant issue is
discovered and widely publicized.  In the future, the CVE content team
at MITRE will be more proactive in assigning candidates as soon as
possible for important issues.  Board members are invited to request
candidate numbers for significant, recently published problems.

Out-of-band assignment will become less necessary as vendors adopt
candidate numbers into their advisories and private assignment becomes
more commonly used.  Therefore, MITRE will be working more proactively
with organizations who release advisories, e.g. software vendors,
security vendors and analysis teams, and response teams, to include
candidate numbers in their advisories.


Deep Analysis for Security Issues
---------------------------------

An approach for conducting deep analysis of security problems was
presented to Board members.  During the submission stage, CVE content
team members will spend a maximum of 1 hour of research per submission
group, identifying potential duplicates and applying content
decisions, and periodically consulting with other members.  During the
candidate stage, Editorial Board members and the affected software
vendors may be consulted for additional analysis.  Such candidates
will be marked for further investigation.  Results of all deep
analysis will be made publicly available and linked to the associated
candidates or entries.


Validity of CVE Candidates
--------------------------

Participating Board members discussed the validity of candidates.
Some members expressed concerns that some entries may be approved
without sufficient validation.  The new voting web site, which will
capture more detailed information for why Board members ACCEPT a
candidate, will help to make this more clean.

The general issue of confidence was discussed.  Participants agreed
that it would be very useful to CVE, and to the community as a whole,
if each CVE candidate or entry was associated with a particular
confidence level.  In cases in which the affected software vendor
publishes an acknowledgement of the problem, confidence in the
problem's existence can be high.  In cases in which vendors do not
acknowledge the problem, a Board member may have verified it
independently.

Many participants agreed that they could indicate if they have
verified the problem themselves.  However, some participants validate
a problem only before including it in a security tool; saying that the
problem has been validated could give advance notice to competitors
about enhancements to the vendor's tool.  Participants agreed that
this concern could be resolved if MITRE only publicizes that a Board
member has validated the problem, without indicating which member has
done so.


CVE and IDS Issues (CIEL)
-------------------------

MITRE presented the Board with a number of issues related to the
inclusion of IDS events in the CVE list.  Many events that are
detected by IDSes do not have a clear association with vulnerabilities
or exposures, e.g. port mapping.  In cases where there is overlap
(e.g. an IDS detect for an attempt to exploit a specific
vulnerability), CVE descriptions focus on the nature of the security
problem as opposed to how it may be exploited.  A number of Board
members and others involved in IDS work have expressed the desire to
have CVE encompass all IDS events.


Draft Common Intrusion Event List (CIEL)
----------------------------------------

MITRE is developing a draft list for IDS events, referred to as CIEL
(Common Intrusion Event List, pronounced "seal").  CIEL development
has helped to identify a number of issues that will need to be
addressed by the IDS community.  Presently, CIEL development is being
conducted through an internal IDS project led by Bill Hill, although
Steve Christey and Dave Baker are also involved.

Since the draft CVE gave the CVE Initiative some legitimacy by
providing a concrete list which Board members could work with, MITRE
is taking a similar approach by creating a draft CIEL.  This will help
to identify CIEL content decisions (e.g. issues related to level of
abstraction).  Presently, the draft CIEL is being populated from
several IDS sources, including Snort and arachNIDS, the DARPA CIDF
attack list, and signature lists for RealSecure and NetProwler.  In
many cases, MITRE will be able to reuse some of its internally
developed technologies which were developed to support CVE.

While the draft CIEL is still being developed, interested members of
the Editorial Board could begin discussion on some of the larger
issues surrounding CIEL.


Organizational Issues for CIEL
------------------------------

One fundamental question for CIEL is whether the CIEL effort should be
pursued only by CVE Editorial Board members, or if a separate group
should be created.  Participants in the Editorial Board meeting agreed
that a separate group would be useful, although there would likely be
strong overlap between a CIEL "working group" and the CVE Editorial
Board, the DARPA CIDF, and the IETF IDWG groups.  Some Board members
believed that the CIEL could ultimately become a bigger effort than
CVE.

With the creation of a new CIEL effort, there is an opportunity to
pursue a different process model than that for CVE.  For example, CIEL
could be populated in a more rapid fashion by eliminating or reducing
the "democratic" approach used for CVE, along with less review of CIEL
candidates before they become entries, less consultation with others
on content decisions, and/or no formal voting process.

Regardless of the approach that is adopted, MITRE needs to assess how
much of the CIEL effort it can directly support, especially given its
own needs for CIEL for its internal project work, and the amount of
work that remains to be done for CVE.  There is also the risk that the
Board and other participants in CIEL could be distracted from the
current CVE work on vulnerabilities, as there will be many members who
participate in both CVE and CIEL.


CIEL Technical Issues
---------------------

A sample of technical issues for CIEL was presented to the Board.

CIEL entries may be much more difficult to find or look up than CVE
entries for several reasons.  First, the terminology used in the IDS
world is less precise and consistent than that for vulnerabilities
(e.g. "port map" vs. "port scan," or the many different ways of
describing malformed packets). In addition, there are very few public
references that could be used for CIEL entries.  Accordingly, CIEL
descriptions may need to be more detailed than CVE descriptions, and a
more precise terminology may need to be defined.  This requirement was
further demonstrated by examining the CIDF attack list, whose event
names are often too sparse to understand the nature of the event that
is being described, and which contains items that may be duplicates
(perhaps due to differences in terminology).

In addition, content decisions for CIEL may be more complex and/or
more directly affect the usability of CIEL for some IDS tools and
databases.  Based on the preliminary examination of the IDS signature
lists identified above, there appears to be more variation in the
level of abstraction used by various IDSes than the LOA's used by
assessment tools and databases.


CIEL Numbering Issues
---------------------

Several numbering issues must be considered for CIEL, many of which
have been identified in CVE.

If CVE numbers are to be used to identify CIEL entries, then CIEL and
CVE users would need to be able to easily distinguish between events
and vulnerabilities or exposures.  This would require providing
separate downloads, and/or a new field which describes whether the
associated CVE number is releated to a vulnerability or an event.

There are some limitations to having a separate naming scheme for CIEL
candidates than for entries.  For example, for CVE, users must be
educated about the differences between candidates and entries.  Having
separate candidate numbers also increases the maintenance costs for
compatible products.  For example, when a candidate becomes an entry,
the product's mapping would need to be changed to reflect this.

Finally, CIEL numbers should be easily findable.  Since a CVE number
has hyphens in it, many search engines split the number into smaller
pieces, which makes it more difficult for search engine users to find
CVE items using the CVE name.  (For example, a search for
"CVE-1999-0003" would find documents that contain the separate terms
"CVE," "1999," and "0003.")  The dual numbering system for candidates
and entries poses some challenges for users of products that use both
numbers.  For example, if a user searches for CAN-1999-0003, the
product should be to find the associated CVE-1999-0003 instead.  Thus,
either user education or more tool development would be required to
support searchability in the case of dual numbering schemes.


CIEL Abstraction Issues
-----------------------

The Board was presented with some example issues related to
abstraction.  For example, one could have separate entries to identify
different decodes for specific networking protocols, e.g. FTP commands
such as USER, PASS, and CWD.  Such abstraction choices also apply to
communications protocols for Trojan Horses and DDoS utilities.

The description of malformed packets also poses some challenges.  For
example, a TCP/IP packet could contain any combination of SYN, ACK,
RST, SYN/FIN, and other flags.  Each flag could have a separate entry,
but there would also need to be a way to characterize all different
combinations of the flags.

Another area in which there are abstraction questions is that of
detects for specific tools, e.g. Whisker vs. CyberCop Scanner
vs. nmap.  CIEL could have separate entries for each tool (a high
cardinality problem), one high-level entry for any tool, or some other
entry whose level of abstraction is somewhere in the middle.

Issues such as the one described above indicate that CIEL may better
serve its users by allowing multiple levels of abstraction to be
represented.  Dot notation, which has been approved for use in CVE but
is not actively in use, may be insufficient to handle multiple levels.

Participants in the Board meeting agreed that it would be reasonable
for CIEL to be populated from what IDS tools use, which could address
some of the abstraction problems described here.

MITRE will continue to report on CIEL progress to the Editorial Board
and other interested organizations.


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

MITRE provided the Board with an update on its approaches to CVE
compatibility.  MITRE is currently designing a special logo which will
only be approved for use on CVE-compatible products.  At a high level,
the process will be as follows.  The vendor will make a formal
application for use of the logo.  MTIRE will review the vendor's
product for accuracy of the mappings, relative to a specific CVE
version.  Once approved, the vendor will be given formal approval to
use the logo.  MITRE will also be examining the possibility of
supporting advertising on the CVE web site for CVE-compatible
products.

The role of CVE versions in CVE compatibility - especially reference
versions - was discussed.  Reference versions will be assigned
approximately once per quarter.  The new CVE web site will provide
more details on specific CVE versions.  Reference versions will be
useful in providing a standard version with which users and/or MITRE
could determine how up-to-date a product's mapping is.

Guidelines for determining reference versions were presented.  A new
reference version may be created when there is a content milestone
(e.g. exceeding N-hundred entries), it has been approximately 3 months
since the last reference version, and it should be relatively
up-to-date with respect to recent security problems.

One requirement that arose out of these discussions was that for each
release of a product, vendors should advertise how up-to-date their
mappings are by specifying the most CVE version that was used to make
the mapping.  It was also agreed that for a product to be considered
"up-to-date," it would need to be mapped to a version of CVE that was
released within the previous 6 months.  A shorter time frame was
discussed, but since product development cycles can take several
months, it was agreed that 6 months was a reasonable maximum to
account for different timing windows.

The CVE compatibility requirements document will be updated to reflect
the discussions at the Board meeting.  The requirements will also be
posted to the CVE web site so that consumers may use them to help in
their purchase decision making.  In addition, MITRE will host a
teleconference related to CVE compatibility in early September.


Editorial Board Business
------------------------

The next wave of Board recruiting activities was discussed.  MITRE
will be concentrating on adding software vendors to the Board, and/or
establishing liasons with other vendors.  As security services have
become more prominent, MITRE may recruit representatives from those
types of organizations as well.

As CVE has gained acceptance in the community, MITRE has begun
receiving requests for membership from individuals who are not known
to MITRE.  In some cases, the individuals have a desire to help the
CVE Initiative, but the only apparent way of helping is to build a
CVE-compatible product or become a member of the Editorial Board.
Participating Board members discussed creating a separate mailing list
(a "CVE Working Group") which would provide a forum for non-Board
members to discuss CVE issues and contribute to the effort.  In turn,
such a group could be used for individuals to establish credibility as
potential candidates for the Editorial Board in the future.

As the size and diversity of the Editorial Board is growing, MITRE
will also work on refining the roles and responsibilities for Board
members.  This in turn will provide better guidance to new, incoming
Board members.  It would also be useful to determine which Board
members are not participating in the Initiative enough, which in turn
could make it easier to ask those members to leave and make room for
others who would participate more actively.  Since Board members
contribute in different ways to the Initiative, it may be a challenge
to formalize their roles and responsibilities and to determine
sufficient levels of activity.

The recently announced acquisition of AXENT by Symantec was also
briefly discussed, as both organizations have Board members.  As
agreed to previously, a maximum of 2 Board members can come from the
same organization, unless an existing Board member's affiliation
changes, in which case the maximum is 3.  While these original
guidelines were created because individuals would change
organizations, it seems reasonable that the same guidelines could
apply to mergers and acquisitions.

Finally, the date and location of the next face-to-face Editorial
Board meeting was discussed.  It was agreed that having a Board
meeting every six months is appropriate, so the next Board meeting
will be held around February 2001.  Possible locations included Cisco
in Austin, Texas, or Microsoft in Seattle, Washington.  Another
location would be EWA-Canada in Ottawa, although there was strong
agreement that a February meeting in Ottawa would be sub-optimal.


Software Vendor Liaisons
------------------------

An approach for establishing software vendor liaisons was discussed.
In recent months, it has become apparent that the CVE Initiative would
be greatly helped by more involvement from software vendors.  However,
due to the raw number of software vendors, not all vendors could be
part of the Editorial Board.  It is an open question as to how to
determine which software vendors would still qualify for Board
membership; but since OS vendors typically deal with a large number of
vulnerabilities in a variety of software, it is likely that OS vendors
would be able to contribute at the level of other Editorial Board
members.

The current thinking is to include "official" POC's for vendors who
will serve as liaisons.  They would not be a formal part of the
Editorial Board, but the individuals and/or their organizations would
be recognized in some other fashion.  Liaisons would be able to "vote"
and comment on security issues related to their own products, with
their comments being included in the voting record or any associated
deep analysis.  The liaison could be consulted before any CVE
candidate related to their product is ACCEPTed into the official CVE
list.  They could make themselves available for consultation with
other Board members.

Board members were asked about the degree to which they communicate
with software vendors on security issues.  There was wide variety in
the answers, although most Board members have built up relationships
with individuals working for a small number of vendors.  The
experience of CERT/CC's interaction with vendors was briefly
discussed.  MITRE will follow up with CERT/CC for guidance on how
vendor liaisons could be established within the CVE Initiative.

The funding status for CVE was also discussed.  Steve Christey and
Margie Zuk described some of the funding approaches that MITRE will be
pursuing for the next fiscal year, e.g. by creating an advisory board
or using advertising on the CVE web site.  They also discussed the
complexities of pursuing a funding model for an open effort like the
CVE Initiative.


Voting
------

Board members at the face-to-face were given a basic demo of the new
voting web site.  A version of the voting web site will be made
available to the Board within the next few weeks.  Participating Board
members agreed that it will be sufficient to use SSL with server-side
certificates to restrict access to the voting web site.  The initial
online version of the voting web site may only use HTTP Basic
authentication, but it would allow Board members to test it in an
operational environment.

All votes that are recorded on the voting web site will be extracted
and processed internally by MITRE before they are publicized.
However, each Board member's vote and comments will be immediately
visible to other Board members, which is not feasible with the current
email-only voting process.

Proposed enhancements to the voting web site included: the ability to
have a voter indicate if they have been unable to reproduce a problem,
the ability to highlight where there are voting conflicts
(e.g. candidates with both ACCEPT and REJECT votes), and the ability
to mark a candidate so that it is given "special attention" by other
voters, e.g. if a Board member has discovered a possible error or
inconsistency.

Other voting support could be provided to each Board member in the
form of automated email reminders, or separate sections on the voting
web site.  For example, the member would be able to see:

  - candidates that the member is still REVIEWING
  - candidates that the member hasn't voted on yet (with the
    possibility of prioritizing such candidates if they appear in a
    backmap for a product owned by that Board member)
  - candidates that have subsequent comments by other Board members
  - candidates marked for further investigation or deep analysis
  - conflicting votes (e.g. candidates with both ACCEPT and REJECT)
  - breakdown by OS family
  - ad hoc keyword queries

Board members also discussed the CD:VOTE content decision, which
specifies rules and guidance for voting.  Vendor acknowledgement of
security problems was discussed.  Vendor acknowledgement is not
counted as a vote unless there is some public notice in which the
vendor acknowledges the problem, usually in the form of an advisory,
post to a mailing list, or description in the software's change log.
The software vendor representatives who participated in the Board
meeting suggested that while they may post followups in some mailing
lists in which they directly or indirectly acknowledge the existence
of a problem, their posts should not be regarded as sufficient vendor
acknowledegement.  However, they agreed that their ACCEPT vote for an
issue should be counted as vendor acknowledegement.  In addition, the
vendor's vote and a separate acknowledgement should not count as 2
votes.  (In practice, such cases already count as 1 vote).

There was some discussion regarding the proper way to handle voting
conflicts.  Some Board members suggested that if the conflict cannot
be resolved, then a large majority should be required to make a final
decision.  A separate process will be defined to handle such cases.


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

Board members discussed a number of high-level issues related to CVE
content decisions.

Most participants agreed that a "SPLIT-by-default" operation would be
appropriate when there is insufficient information for determining the
level of abstraction for 2 closely related security problems.  Some
members advocated adopting a MERGE approach, since it is often a more
appropriate level of abstraction for system administrators.

It was agreed that, where possible, the vendor of the vulnerable
product should be the final authority in such matters.  Such an
approach, however, assumes that the vendor is willing and able to
respond in a timely fashion.  In addition, there is a risk that some
vendors may always request a MERGE to minimize the number of CVE
entries related to their products.

Participating Board members were asked how they handled "content
decisions" and consistency for their own vulnerability databases.
Content decisions for these databases are either dictated by a single
content authority, or by an entire group which makes a decision on a
specific vulnerability and uses it as a precedent for future
decisions.  In most cases, however, the content decisions are not
well-documented.  Most members had separate technical writers or QA
teams that helped to ensure consistency where possible.  The decision
for the level of abstraction varied across databases, being driven by
different needs.  For example, some databases would choose an LOA that
reflected the needs of system administrators, whereas others might
choose an LOA based on patches or differences in risk.

The CVE content decisions, as written, attempt to take a top-down
approach by describing rules or guidelines at a high level, then
applying the rules to specific candidates.  This made it difficult for
some participants to evaluate a content decision without knowing the
details for a specific problem that is affected by the CD.

Participants advocated taking an ad hoc, precedent-based approach, by
analyzing each candidate, making a decision, documenting the decision,
and using it as a precedent for future considerations.  This is
consistent with approaches that some Board members have taken with
respect to their own database maintenance.  However, since Board
members contribute to the effort at different times, there is a risk
that inconsistent decisions will be made based on who happens to be
voting or discussing a particular issue at one time.

MITRE will modify and document its new approach to content decisions
to reflect feedback from the Board.


CVE Accuracy and Timeliness
---------------------------

Participating Board members discussed the different ways in which CVE
could be inaccurate.  For example, a CVE entry or candidate may be
described at an improper level of abstraction, the security issue may
not be real, the security issue is described improperly in the CVE
description, or it is a duplicate of existing entries or candidates.
Accuracy could be improved by consulting with software vendors
liaisons.  In some cases, the description for a complex security
problem may be inaccurate because important details have been removed
from the short CVE style descriptions.

Participants agreed that the CVE Initiative should maintain the
minimum 2 week review period that is currently set for candidates, and
there is insufficient reason to put candidates on a "fast track" even
for the most serious vulnerabilities.

A short discussion was held regarding the factors that may delay the
final decision for candidates.  In some cases, a candidate may not
receive sufficient ACCEPT votes in the first 2 weeks after it has been
proposed.  Generally, Board members do not vote on candidates that are
more than 2 weeks old, so candidates with insufficient votes may fall
behind in the process.  Unresolved content decisions have also played
a significant role in accepting some candidates; the new approach to
less formalized content decisions may reduce such delays.

Voting conflicts also contribute to delays.  When a Board member casts
a vote to REJECT or RECAST a candidate, it is normally given a much
lower priority than other candidates.  This problem may be resolved
when voting conflicts become more visible and easily identified.
Consultation with the software vendor may also delay candidates in
some cases, as the vendor may need additional time to review the
issue.  The final factor is related to Steve Christey's multiple roles
in the CVE Initiative; other tasks not directly related to CVE content
may occasionally prevent Steve from focusing on identifying and
addressing some delays for specific candidates.  This final concern
will be mitigated as the rest of the CVE content team gains experience
in submission refinement, CD's, and other aspects of the CVE process.


Community Feedback on CVE
-------------------------

Steve Christey and Margie Zuk discussed feedback that they often
receive on CVE.  Users often assume that the data in CVE is reliable.
In practice, this is not necessarily the case, since only the number
of ACCEPT votes determines whether a candidate is accepted or not.
The voting record itself could be summarized and associated with CVE
entries to provide a better indicator of reliability.  Board members
thought that knowing which CVE entries have been actively exploited,
combined with a field that indicates whether a problem has been
acklnowledged by the vendor or reproduced by a Board member, would be
important information for CVE consumers.  Such information might be
made available as an extension to CVE.

Most feedback from the CVE web site is related to usability of the
references.  Users will often ask for additional information regarding
specific sources, or ask for URL's which could provide them with more
information.  The reference key and reference maps on the new CVE web
site will help improve the usability of the references while MITRE
works with other organizations to determine if it is reasonable to
include URL's with the references for CVE entries.

Users often ask about whether CVE includes viruses or Trojan horses.
While some of this may be due to confusion regarding the difference
between vulnerabilities and viruses, others explicitly say that the
multiple naming conventions adopted by anti-virus vendors causes
problems for them.  However, since Trojan horses and viruses are high
cardinality items, CVE probably will not include specific entries for
them, except at a high level of abstraction (e.g. CAN-1999-0660 or
CAN-1999-0661 for certain types of Trojan horses).

Some users want more rapid candidate assignment and review.  Candidate
assignment will become more rapid as private and out-of-band
assignment becomes more prevalent.  Since participating Board members
have agreed that the minimum 2 week period for candidates should stay
in place, the CVE list itself will not achieve the timeliness desired
by some of its consumers.

Other common requests from users are for additional data formats
(e.g. XML), a capability to search by OS (which could be handled by
existing online vulnerability databases that are CVE-compatible), and
the recording of a risk level.  While risk level is outside the scope
of CVE itself, some CVE users have told MITRE that it is difficult for
them to deal with the inconsistent ways in which products describe the
risk of a problem; therefore it may benefit the community as a whole
if it adopts a consistent way of describing risk.