[CVEPRI] Editorial Board Meeting Summary - March 15-16, 2001

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

Following is the summary for the CVE Editorial Board meeting.  I
apologize for taking so long to write this up, but as you will see,
there were good reasons for the delay.

Thanks to everyone who made this one of the liveliest Board meetings
yet.  It was also one of the most critical.

Many important topics were discussed at the meeting.  The most
important and timely issues will be moved to the mailing list over the
next month or so.  Those issues are: the numbering scheme for legacy
candidates, the verification/voting requirements for CVE entries, and
the definition of Board roles, tasks, and expectations.

- Steve



****************************************************************
CVE Editorial Board Meeting Summary - March 15-16, 2001
****************************************************************

Members of the CVE Editorial Board met at Cisco in Austin, Texas, USA
on March 15 and 16, 2001.

The attendees of the face-to-face meeting were:
  Andy Balinsky (Cisco)
  Troy Bollinger (IBM)
  Tim Collins (NFR)
  John Flowers (Hiverworld)
  Andre Frech (ISS)
  Scott Lawler (DOD-CERT)
  Jim Magdych (NAI)
  Pascal Meunier (Purdue CERIAS)
  Ron Nguyen (Ernst & Young)
  Mike Prosser (Symantec)
  John Rhodes (DOE-CIAC)
  Kevin Ziese (Cisco)
  Sean McAllister (DOD-CERT; not a Board member)
  Ryan Walters (Symantec; not a Board member)

Participating by teleconference were:
  Larry Oliver (IBM)
  Craig Ozancin (Symantec)

MITRE participants were:
  David Baker
  Steve Christey
  Bob Martin
  Bill Hill (via teleconference)
  Margie Zuk (via teleconference)



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

The Board was presented with a progress report on assigning candidate
numbers to legacy issues.  (See
http://cve.mitre.org/board/archives/2000-07/msg00024.html for an
explanation of terms).  Due to some errors, previous statistics had
not been accurate.  The number of legacy submissions that need to be
processed is 7794.  As of the meeting, 7696 of those submissions had
been matched against each other.  In January, only 1500 had been
matched.  All matching is expected to be completed by April 2, which
will be more than 2 months ahead of the target date of June 15.  (A
set of submissions from Cisco had been improperly imported, and thus
were not matched properly; Cisco provided an updated list of
submissions, which will be matched by April 2).

Some optimizations were made in the matching process in order to
significantly reduce the amount of time spent matching.  However, the
new approach increases the risk of producing duplicate candidates.
Where possible, MITRE will try to mitigate the risk of duplication
with the resulting legacy candidates.  If a duplicate still arises, it
could be caught in the Editorial Board review process.

Currently, the matched submissions have produced approximately 4200
submission groups (small groups of submissions from multiple sources,
all of which describe the same vulnerability, or closely related
vulnerabilities.)  Approximately 3500 of those groups have no matching
CVE entry or candidate.  This means that approximately 3500 more
legacy candidates could be created from those groups.  The actual
number is difficult to predict due to idiosyncracies in the matching
process and differences in the level of abstraction of submissions in
comparison with CVE content decisions.

There is also progress in MITRE's processing of new security issues as
they are publicly announced.  Over 100 candidates have been reserved
for use in the initial public announcement of vulnerabilities.
Approximately 80 of those reserved candidates have already been
publicized.  Some affected software vendors, e.g. Microsoft, are
becoming more involved in reserving candidates for vulnerabilities in
their own products; other vendors will also be contacted and asked to
participate.

Approximately 1200 "new" submissions - i.e. submissions for
vulnerabilities that were discovered after November 1999 - still need
to be processed.  However, many of those submissions are for the most
recently discovered vulnerabilities.

The Board was presented with the individual tasks being undertaken by
the CVE content team.  Barbara Pease and Jeff Taylor are refining the
legacy submissions.  Christine Walzer is performing submission
matching on new, incoming submissions.  Ramsay Key is matching and
refining new submissions.  Jean-Paul Otin is working on creating
candidates for Windows NT-based configuration problems.


Numbering Scheme For Legacy Candidates
--------------------------------------

Since members of the CVE content team are now performing submission
refinement, MITRE will begin to produce legacy legacy candidates on a
regular basis.  There are several numbering schemes for candidates
that could be adopted.  The Board discussed several options.  However,
since each proposed solution had strengths and weaknesses, no decision
was made.

The current approach for numbering candidates is CAN-YYYY-NNNN, where
YYYY is the year in which the candidate number is assigned - *not* the
year in which the vulnerability is publicized.  (The same applies to
CVE entry names, in which the CAN- prefix is converted to CVE-, but
the rest of the identifier remains the same).

If applied to legacy candidates, the current approach would produce
many vulnerabilities that have CAN-2001-NNNN names, but were
publicized in 1999 and earlier.  Many people may have the perception
that the "year" slot in the CVE name is actually related to the year
in which the vulnerability is publicized.  In addition, there may be
an "aesthetic" desire to have the candidate name reflect the year of
publication, as a high-level means of managing vulnerability
information based on how old it is.

Regardless of the public's misconception of the meaning of the year in
the CVE name, many of the candidates/entries with 1999-NNNN names were
actually announced earlier than 1999.  For the most part, CVE items
with 2000-NNNN names were publicized in 2000, but some 2000-NNNN names
are for older issues.  Similarly, some problems discovered in November
and December 2000 have 2001-NNNN names.  So, many of the current
CVE/CAN names are already inconsistent with respect to the year of
publication for the associated vulnerabilities.

However, depending on the number of new vulnerabilities discovered
this year, and the number of legacy candidates that MITRE produces, it
is possible that more than 10,000 candidate names will need to be
assigned this year.  The name space only supports up to 9999 different
names per yer.  (This is being referred to as "the CAN-10K problem").
There are ways of extending the name space if necessary; for example,
by moving to a hexadecimal numbering scheme instead of decimal, 65536
different vulnerabilities could be assigned per year without changing
the number of characters in the name.  However, it is not known
whether such a change would adversely impact how some CVE-compatible
products may store the CVE names.

There are several factors that need to be considered when selecting a
naming scheme for legacy candidates:

  1) It was suggested that to help users manage CVE based on date of
     publication, that a separate field could be added which lists
     such a date.  However, this information is currently in other
     databases, and thus increases the risk of CVE's competition with
     those databases.  In addition, the date of publication would
     rarely help someone in mapping a specific vulnerability to a CVE
     name, although it is occasionally useful in discriminating
     between extremely similar vulnerabilities in the same product.
     The references and description, on the other hand, are essential
     for looking up the CVE name for a problem.

  2) If a naming scheme is adopted which encodes the year of
     publication in the name, then all the entries or candidates that
     currently exist should *NOT* be renamed just to make things
     consistent, since there is such a large number of
     CAN/CVE-1999-NNNN items that were not discovered in 1999.  The
     maintenance costs would be high for CVE users and compatible
     vendors.  Thus, even if the Board adopts a "publication-based"
     encoding, it will not apply to all CVE items.

  3) If a publication-based encoding is not used, then users will need
     to be able to distinguish between new candidates and legacy
     candidates.  This information could be provided in reports that
     are accessible on the CVE web site.

Following are the different approaches that were discussed by the
Board.

  1) Assignment-based encoding: continue to use the current approach,
     i.e. assign CAN-2001-NNNN (or CVE-2001-NNNN) to the issue, since
     2001 is the year in which the candidate is assigned.

     Pro: emphasizes that the encoding of the year in the CVE name is
     not related to the year of announcement.  Simplest to implement.

     Con: increases the possibility of misuse by consumers.  For
     example, consumers might focus on the last 200 CAN-2001-NNNN
     candidates, mistakenly believing that they are the most recent
     issues that have been discovered.

     Con: susceptible to the CAN-10K problem.

  2) Publication-based encoding: assign YYYY-NNNN, where YYYY is the
     year in which the issue was first publicized.

     Pro: more likely to address common public misconceptions.

     Pro: least susceptible to the CAN-10K problem.

     Pro: will be accurate for all issues that are publicized in 2002
     and later.

     Con: 1999-NNNN, and portions of 2000-NNNN and 2001-NNNN, will not
     be consistent with the approach.

     Con: some complications if a vulnerability is publicized one
     year, a candidate is created, and then it becomes clear that the
     problem was actually publicized in earlier years.

  3) Hybrid encoding.  If the problem was published in 1999 or
     earlier, use 1999-NNNN; otherwise, use the year of publication.

     Pro: emphasizes that the encoding of the year in the CVE name is
     not related to the year of publication, for any issues that were
     publicized in 1999 or earlier.

     Pro: For 2002 and later years - and all but the first 150
     candidates of 2001 - the year of publication will be encoded in
     the CVE name.

     Con: For 2000 and 2001, some candidate names will not include the
     year of publication.

     Con: most susceptible to the CAN-10K problem, because there may
     be more than 10,000 vulnerabilities from 1999 and earlier that
     ultimately require names.

To help end users better manage or discriminate between new and legacy
issues, and highlight the differences for purposes of user education,
it was suggested that legacy candidates be assigned names with the
highest sequence numbers available.  For example, one could start at
CAN-2001-9999, CAN-2001-9998, etc. for legacy candidates that are
created in 2001.  An alternate scheme was proposed in which legacy
issues could be assigned CAN-2001-5000 and advanced upward.  However,
it is possible that these significant gaps could cause confusion.  In
addition, some people may be using the highest-numbered candidate for
other purposes, which could have unexpected consequences.  For
example, it was noted that some people mirror individual CVE entries
and candidates on the CVE web site by requesting information up to 100
"sequence numbers" above the most recent candidate; such mirrors might
immediately attempt to download 10,000 candidates for 2001, instead of
the current number of about 250.

Regardless of which approach is adopted, users will need to be
educated about it.  It is likely that additional information will be
needed on the CVE site; in addition, CVE-compatible vendors will need
to address user misconceptions.

Also, MITRE will not be able to start proposing legacy candidates
until the numbering scheme is finalized.


MITRE's CVE Content Goals
-------------------------

MITRE's CVE content goals were presented.  The last CVE version was
released in January, but there are sufficient votes to promote at
least 100 more candidates to official CVE entries.  A new CVE version
will be released within a month.  Some CVE entries will be deprecated
due to duplication.  Other entries will be modified, e.g. to add new
references.  Some candidates - mostly duplicates - will be rejected.

To address the needs of people who would like candidates to come out
more rapidly for new issues, MITRE has set a goal to create and
propose candidates for new security issues every 2 weeks.  Candidates
for legacy issues will be created and proposed on a regular basis.

Other longer-term goals remain.  By July 1, all submissions for issues
discovered in 1999 should be refined into candidates.  By December
2001, all legacy submissions should be refined into legacy candidates.


Threatened Lawsuit Regarding CVE Content
----------------------------------------

A software vendor has threatened to sue MITRE based on some CVE
content.  A CVE candidate describes a reported vulnerability (denial
of service) in the vendor's product.  The vendor says that the
reported problem is not in the product, but rather in the improper use
of the product by system administrators, who do not use OS-provided
resource limitations to reduce the effects of a DoS attack.  The
vendor says that many products who rely on OS-provided resource
limitations are also affected.  There are technical arguments on both
sides regarding whether the reported vulnerability is in the software
or in the operating system; this disagreement is reflected in the long
discussions on the vendor's mailing list regarding the reported
problem.  There also was disagreement by participating Board members
during the meeting.

The software vendor appears to be considering lawsuits against owners
of other databases that list the reported problem in the vendor's
product.  In addition, it appears that several security tools list the
reported problem in their products; thus, the software vendor's
lawsuit might extend to other organizations.  MITRE's lawyers are
preparing a response.

Specific details (i.e. the vendor and claimed vulnerability) were
provided to the Board members who participated in the meeting.  Other
members may obtain details from Steve Christey.

Ultimately, other affected software vendors may attempt similar
lawsuits.  There was some discussion of the potential chill that such
lawsuits might pose for vulnerability research and reporting.


Verification Requirements for CVE Candidates
--------------------------------------------

In the past 9 months, the Board has had several discussions regarding
how much verification of a candidate must be performed before the
candidate can be promoted to an official CVE entry.  (See
http://cve.mitre.org/board/archives/2000-06/msg00054.html as well as
the "Editorial Board Voting Status and Issues" section in
http://cve.mitre.org/board/archives/2001-01/msg00010.html for some
details.)

Ultimately, the guidelines for voting can not be completed until the
verification criteria for official CVE entries is determined.

According to one point of view held by some Board members, the
official CVE list should act solely as a "dictionary," i.e. a set of
agreed-upon names that are used to describe reported security
problems, independent of whether those problems are real or not.
External databases or vendors could clarify whether the reported
issues are real.  In some cases, it would be useful to have a CVE name
for an issue, even if it turns out to be false; for example, an issue
might be publicized in one forum, but refuted in another.  If the
issue does not have a CVE name, but it has been deleted from various
databases, then some consumers might still think that the problem is
real.  It was noted that CVE candidates could be used to record all
reported vulnerabilities, and the voting record could include a
refutation if the initial report is discovered to be wrong.

Other Board members believe that official CVE list should be
well-reviewed, and there should be some level of verification that
ensures that the issues being identified are real.  They argued that
while many databases or products may have a mixture of "real,"
"potential," and "incorrect" issues in them, CVE should strive to be
more correct.  It was also argued that the candidates, by their
nature, already imply a level of uncertainty, and there would be
little difference between entries and candidates otherwise (with the
exception of duplication and level of abstraction problems).  Also,
there is already a public perception that because of the review
process, CVE entries have been sufficiently validated.  That is not
necessarily the case currently; in addition, the small number of votes
increases the risk that an incorrectly reported issue will become an
official CVE entry.

A more stringent requirement for verification of CVE entries could
result in a large number of "permanent candidates" that are never
refuted or rejected, but never gain enough ACCEPT votes.  There are
already some candidates like this.  The original idea of candidates
was that they would be temporary numbers that formed the "to-do" list
for Editorial Board members to review.  Permanent candidates, if they
arose, would need to be managed differently.

It was proposed that if less stringent requirements are adopted, then
the Board could publicize the fact that there is still a
community-wide need for strong verification of vulnerabilities, but
CVE will not be able to fill that need.


Current Voting Activities
-------------------------

In the January teleconference, MITRE had noted that the number of
voters, and the total number of votes taking place, had dropped
sharply in recent months.  Some of the decline was related to the more
stringent guidance in Fall 2000 with respect to the level of
verification that is necessary before Board members should vote to
accept a candidate.

There has not been a noticeable increase in voting since January.  The
Board has almost 40 members, and it is difficult to get 2 or 3 votes
on a timely basis.  This delay is noticeable to the public.  Only 4
members vote regularly; another 15 members vote on a periodic basis,
usually once every 4 to 6 months.  This is insufficient for current
needs, and will become even worse when legacy candidates are added.

Since voting is the most critical task for Board members, the lack of
voting needs to be addressed.  Unless current Board members can
contribute more often, MITRE will need to keep adding Board members -
or increase minimum expectations for existing members - to ensure that
there is sufficient review of candidates in the future.  Board members
did not object to the idea of expanding the Board further; in earlier
meetings, some members had expressed concerns that the Board could get
too big.

It was proposed that voting records could be better publicized, so
that CVE end users could know which Board members are voting actively.
Voting activity can be inferred from current public information, but
it is not easily accessible.  There were no objections to this
proposal.  MITRE will consider how (and when) to most effectively
publicize this information, once the other significant voting issues
are resolved.

Since voting is affected by the verification requirements for CVE
entries, voting activities will be revisited once that issue has been
addressed.


Proposed Voting Guidelines
--------------------------

The following guidelines for voting was proposed and discussed.  A
voter could only ACCEPT or MODIFY a candidate if:
  (1) The vendor has acknowledged the problem.
  (2) The voter, or the voter's organization, has been able to replicate
      the problem.
  (3) Someone that the voter trusts has verified the problem.  This
      could include the original researcher, if the researcher is
      trusted by the Board member.
  (4) There is independent confirmation of the issue, i.e. 2 different
      sources claim to have reproduced the problem (such as an initial
      Bugtraq post and multiple follow-ups).

Participating Board members agreed that the first two requirements
were acceptable.  It was noted that "vendor acknowledgement" needed to
be clear; for example, it might not be sufficient acknowledgement if a
researcher says that there's a patch, unless that patch is tested, or
the vendor says that the patch fixes the problem being reviewed.

Some concerns were raised with respect to the trusted verification
issue.  For example, if the voting Board members all trusted the same
person or organization, then there would be a greater likelihood of an
incorrectly reported candidate being promoted to an official entry.
Some members said that this would not be a problem, because only
researchers who have established a strong reputation would be trusted
by many members.  An incorrect report could also reduce the overall
trust in future reports by the researcher.  There may be other cases
in which a Board member trusts "too many" people.  Also, only the
trust of the members who vote will be taken into account; thus the
ultimate contents of CVE could vary, depending on who is voting.

Previously, it had been proposed that Board members could publicize
who they trusted.  This could address some of the concerns outlined
above; however, members might not be willing or able to provide such
information.

In general, however, the Board agreed that "third party trust" should
be sufficient reason to accept a candidate.  This approach utilizes
the resources of others in the security community who are not on the
Editorial Board.

Due to time limitations, the Board did not discuss whether independent
confirmation should be included in the guidelines, or how it might be
measured.

Until the voting question is resolved, MITRE will only accept
candidates that satisfy the first 3 voting guidelines as described
above, i.e. vendor acknowledgement, verification by a Board member, or
verification by a party that the Board member trusts.

The voting guidelines, once finalized, will be publicized in order to
clear up any misconceptions that CVE users may have.


Other Voting Issues
-------------------

There was a concern that by voting to accept a candidate, a Board
member might be held liable if their vote is interpreted as stating
that they believe the problem is real.  This issue could be
exacerbated by situations like the potential lawsuit related to CVE
content, as described in a previous section of this summary.

Limitations of the current set of votes (Accept, Modify, No Opinion,
Reject, Recast, Reviewing) were also discussed.  It was proposed that
an additional "UNCERTAIN" vote could be used to state that a voter
believes that the candidate description and references accurately
reflect all available information, but the voter does not have
sufficient knowledge about whether the reported problem is real.
Board members disagreed with this proposal, since it implied a level
of confidence, and it was already decided that confidence levels
should not be included in CVE.  A different situation arose in which a
candidate described a vulnerability that was refuted by the vendor;
however, in the past, the researcher had discovered other
vulnerabilities that had been fixed by vendors.  The voter did not
trust the researcher and believed that since the vendor disagreed with
the issue, there should be more confidence before accepting the
candidate.  However, none of the possible votes adequately described
the voter's intent.


Formalizing Editorial Board Tasks and Roles
-------------------------------------------

For various reasons to be described below, MITRE is formalizing the
roles, tasks, and expectations for current and future Board members.
The Board discussed several related issues.

Over time, the Editorial Board has evolved.  The Board started out as
an informal organization.  An interview and review process was put in
place in late 1999.  Starting in late 2000, the expectations for new
members were more clearly defined and publicized.  Most recruitment
activities for Board members were performed by MITRE.  In rare cases,
a prospective member was nominated by an existing Board member, or the
prospective member established initial contact.

However, the number and type of participants in the Editorial Board
has changed over the years.  In addition, outsider requests for Board
membership has increased significantly.  More of the initial inquiries
come from marketing personnel instead of technical workers.  More
prospective members are not known to MITRE, or they are not qualified
to participate.  Editorial Board membership is sometimes mentioned in
marketing materials or personal biographies.  While these conditions
reflect a growing acceptance and prominence of CVE, they also indicate
a need to ensure that membership on the Editorial Board is not used
inappropriately.

Without a clear description of the tasks that are performed by the
Board, and without a more formal review mechanism, it is becoming more
difficult for MITRE to manage the incoming requests, to clearly
identify expectations of prospective members, and to fairly assess the
prospective member.  It also makes it difficult to assess the level of
participation of current membets.  Some current members have not been
able to contribute at the level which was agreed to when they first
joined the Board.  Other members who have been on the Board since fall
1999 did not join through the current process; as such, there was
never a formal discussion or recruitment period which would describe
the tasks and expectations, which evolved as CVE has changed.

In an attempt to clearly identify how current Board members
participate in CVE activities, MITRE has developed a spreadsheet which
outlines the level of contribution which each Board member has made,
in a number of different tasks.  The purpose of the spreadsheet is to
clarify how each Board member contributes, and how often; to be used
as a basis of one-on-one discussion with each member on their own
expectations for how they participate in Board activities; and to
clarify what minimum expectations could be.  In the next few weeks,
each Board member will be contacted, and their roles and tasks will be
discussed.  In turn, this will help all Board members to collectively
decide on future expectations for Board members, and to formalize such
expectations.  Ultimately, each member's tasks, roles, and
expectations will be publicized to the rest of the Board, and possibly
the public as a whole.


Board Member Roles
------------------

The following roles were discussed by the Editorial Board.  It is
believed that most members would have a single, primary role on the
Board.  By identifying the role of each member, the associated tasks
and expectations could be clarified.

Some MITRE-specific roles were identified.  The CVE Editor is
responsible for CVE content.  The Chair is responsible for Editorial
Board structure, recruitment, and activities.  Both roles are
currently performed by Steve Christey.  Technical contributors include
task leaders (i.e. Margie Zuk, Pete Tasker, Bob Martin, Bill Hill, and
Dave Baker), members of the content team (Barbara Pease, Ramsay Key,
Chris Walzer, Jean-Paul Otin, Dave Goldberg, and Jeff Taylor), and
other supporting personnel.

Four roles for Editorial Board members were identified.

Technical members participate in the design, review, and maintenance
of CVE and/or its usage.  Expectations include consistent
participation in one or more technical tasks, such as voting, ad hoc
consultation, or definition of CVE processes.

Liaisons represent a significant constituency, related to or affected
by CVE, in an area which does not necessarily have technical
representation on the Board.  This role may include software vendors.
Liaisons would need to be visible and active in their own community.
They bring a diverse perspective, a broader awareness, and
community-specific needs for CVE to the Editorial Board.  The primary
expectation for liaisons would be consistent participation in Board
activities that directly affect the liaison's community.

Advocates actively support or promote CVE in a highly visible fashion.
This role would be reserved for respected leaders in the security
community.  They help bring credibility to the CVE Initiative, and
they may give CVE a "wider reach" outside of the community.  They
might participate in strategic planning for CVE, but they wouldn't
necessarily participate at a technical level.  A current Board member
was proposed as an example Advocate.  It was suggested that the term
"Ambassador" could also be used to describe this role.

Editorial Board members agreed that the Advocate role is important for
the CVE Initiative, and it is appropriate to include advocates on the
Board.  There was some discussion regarding how a member might be
assigned an advocate role, as it may be difficult to outline specific
requirements.  Advocates could be appointed with a vote by a
significant percentage of Board members, but this approach was not
discussed in detail.

The fourth role is Emeritus, which is an individual who was formerly
active and influential in the CVE Initiative, and maintains an
"honorary" position as a result.  The expectations for the member are
minimal.  One concern was raised that the Board should only include
active members, and as such, it might not be appropriate to include an
Emeritus.  However, in some cases, an Emeritus may continue to
participate on an ad hoc basis.  While this role was not discussed
extensively, Board members agreed that it might be appropriate for
MITRE to choose which members can retain Emeritus status.



Editorial Board Member Tasks
----------------------------

The following tasks were discussed by the Editorial Board.  Members
agreed that their CVE-related activities were covered by one or more
of these tasks.

1) Voting on candidates.  Some members vote regularly; others vote on
   an ad hoc basis, e.g. when there is an effort to reach a specific
   content goal.

2) Meetings.  Some members participate actively in face-to-face
   meetings and teleconferences.

3) Ad hoc/offline consultation.  Sometimes, members are consulted
   "behind the scenes."  Their contributions, while valuable, may not
   be visible to the public or even to other Board members.

4) CVE process definition.  Activities may include discussions related
   to content decisions, the review and voting process, Board
   structure, etc.

5) Content provider.  Several Board members have provided their
   vulnerability databases for conversion into candidates, which
   ensures that CVE content is complete.  Note that this task is also
   performed by some organizations that are not on the Editorial
   Board.

6) IDS/CIEL.  In some cases, CVE does not identify events that are
   captured by intrusion detection systems.  Some Board members will
   be participating in the review and development of the Common
   Intrusion Event List (CIEL), which is currently being drafted by
   MITRE.

7) Candidate Reservation.  Some members use candidates in their
   security advisories, or they are prospective Candidate Numbering
   Authorities (CNA's).  Note that this task is also performed by some
   organizations that are not on the Editorial Board.

8) CVE compatibility.  Some members participate in the definition of
   requirements or the evaluation process for CVE compatible products.
   Note that this task is also performed by some organizations that
   are not on the Editorial Board.

9) Non-CVE activities.  Occasionally, an activity that is not directly
   related to CVE is undertaken by the Editorial Board.  The most
   prominent example is the CyberCrime Treaty Statement, which was
   drafted in May and June 2000.

10) Liaison.  It is expected that the tasks for a liaison will be ad
    hoc.

11) CVE promotion.  Some members are active, visible promoters of CVE.

12) Education about CVE.


Since the amount of participation by each Board member varies, as well
as the specific tasks that the member performs, it is difficult to
determine what the minimum level of participation should be for each
member.  There was little discussion on this topic during the meeting.
However, it will be revisited in the near future as Board members
evaluate their own roles, tasks, and expectations.


Organizations with Multiple Members
-----------------------------------

Some organizations have 2 members on the Editorial Board.  In some
cases, one member is active, but the other is not.  It was proposed
that organizations with multiple members should have a level of
activity which exceeds the minimum expectations for one member.

However, meeting participants advocated that the requirement should be
made more stringent, and each Board member should meet the minimum
requirements for participation.  This requirement was accepted by all
participating members who were in multi-member organizations.  It was
agreed that there should be allowances for extenuating circumstances;
for example, one Board member was recently injured in an accident.



New Member Recruitment Process
------------------------------

The Board discussed the process by which prospective members could be
recruited, evaluated, and added to the Editorial Board.

MITRE's current process was described as follows.  A prospect is first
identified in one of three ways.  Some prospects ask MITRE about
membership.  Other prospects are actively recruited by MITRE, often to
fill a gap in Board representation.  Other prospects are nominated by
current Editorial Board members.  Once identified, the prospect is
given a short description of Editorial Board tasks and the expected
amount of time that needs to be committed.  An interview then takes
place between MITRE and the prospect.  The interview allows MITRE to
determine if the prospect has the appropriate technical knowledge to
contribute to CVE, and to identify the specific roles and tasks that
the prospect will undertake.  The prospect can obtain more information
about Board activities and expectations.  During any of these phases,
MITRE or the prospect may decide that membership is not appropriate.
If MITRE decides to add the prospect, the prospect provides a short
professional biography.  The prospect is then announced to the
Editorial Board as a new member.  The announcement describes how the
new member will be able to contribute to CVE, lists the member's bio,
and identifies the specific tasks that the member is expected to
perform.  The prospect is then sent an introductory documentation
package that describes recent news, voting, technical rationales for
CVE, etc.

While Board members were satisfied with the types of people that MITRE
has added to the Board, there was some concern that Editorial Board
members are not included in the evaluation process.  As more and more
people request membership, there is an increased risk that a
MITRE-only recruitment process might add a Board member who is
inappropriate.

Some members advocated an approach in which MITRE "screens"
prospective members, then consults the Board for feedback on those
prospects who pass the screening.  During the screening, MITRE should
ensure that prospects have a clear understanding of expectations;
while MITRE currently does this, it will be easier to describe when
the roles and tasks are well-defined.

The Editorial Board could provide feedback via a discussion period and
a formal vote.  It was proposed that a minimum 50% of members could be
required to accept a prospect, but given the size of the Board, and
the lack of consistent participation by most members, this number is
probably too high.  A minimum 5 votes might be more reasonable, and it
still represents a little more than 10% of all members.  There would
need to be a minimum review period to give members enough time to
review the prospect, perhaps a month.

It was agreed that a private mailing list would be needed for
discussion and voting on prospective members, if such an approach is
adopted.

It was proposed that prospects should be visible or known to the
Editorial Board.  However, some current Board members were not
well-known to other members.  In addition, some members act as
liaisons for other groups, but may not be well-known if they are not
directly involved in the security industry.  Some lesser-known Board
members have made significant contributions.

Many members agreed that the prospect could be required to submit a
"resume" that outlines specific qualifications for Board membership,
in light of the tasks that the prospect is expected to perform.  This
would allow all Board members to evaluate the prospect, even if they
do not know the person.  Guidelines for a minimum amount of experience
were discussed.  There was general agreement that between 3 and 5
years' minimum experience in information security should be required,
unless the individual has made a recognizable contribution to the
information security community.

Some concern was raised that a more formal voting process could make
the Editorial Board a more exclusionary organization.  However,
MITRE's current recruitment and screening process could reduce this
risk.  There was also some side discussion regarding the diversity of
the individual members of Board, especially with respect to the lack
of women; the small percentage of women in information security may be
a factor.  There is currently one woman on the Board, but she is
expected to leave soon.  MITRE's management, content, and support
teams include women, but they are not on the Board.  Some potential
members were identified, and they will be evaluated and recruited
through the established process.

Once the tasks, roles, and expectations have been more clearly
defined, the Board will be able decide on the new approach to
recruitment and evaluation of new Board members.


Trial Membership
----------------

MITRE proposed the possibility of establishing a "trial membership,"
or review period, for new members.  This could be used to ensure that
new Board members would be able to participate as actively as
expected.  In some cases, new members would join the Board, but they
would not be able contribute at the level that was expected.  Trial
membership might be useful to ensure that the new member is active, at
least during the review period; however, it does not necessarily
guarantee the level of activity after the trial period.  Trial
membership could also limit the number of prospective members who join
the Board solely for marketing or promotional purposes.

Board members disagreed with this proposal.  Instead, they suggested
that the vetting process should be improved to minimize the risk of
"under-performing" new members.  As the roles, tasks, and expectations
are formalized, it will also be easier to request that some Board
members resign if they are not able to participate at the expected
level.


Other Board Business
--------------------

At several points during the meeting, it was noted that a non-public
mailing list could be useful for Board members to discuss certain
issues that would be inappropriate for the normal Editorial Board
mailing list, which is publicly archived.  While the Board has
committed to making its deliberations public, there has always been a
consideration that there might be a need to support private
discussions.  Members will need to be careful that the private list is
not used for any discussions which should be publicly archived.

The frequency of Board teleconferences was also discussed.  Currently,
teleconferences are held every 2 to 3 months.  Some members suggested
creating a single time slot for weekly discussions.  If members had a
planned time slot, it could allow them to participate more regularly,
and receive more timely updates.  A staggered schedule was also
proposed, since a single time slot could prevent some members from
participating at all, if they had other regular meetings that occurred
at the same time.  However, members believed that a single time would
be more easily manageable.  The topics for the meeting could be ad
hoc, and there would not need to be a formal agenda or report
afterward.  If the tasks and roles for Board membership begin to
require more involvement, more frequent teleconferences could help
ensure that everyone is up-to-date.

Since the face-to-face meetings are consistently more productive than
the teleconferences (probably due to the personal dynamics involved in
face-to-face interactions), MITRE is considering increasing the
frequency of face-to-face meetings to every 4 months, instead of every
6 months.

There was no discussion of the date and location for the next
face-to-face meeting.


Future CVE Activities
---------------------

Because the level of verification required for voting on candidates
has not been decided yet, it was difficult to set specific CVE content
goals.  The two main goals that were scheduled for discussion were to
reach 1600 entries by June 1, and to reach 2000 entries by December 1.

Many CVE goals in the past have been quantitative, focused on the
number of entries and/or candidates.  The Board identified some
qualitative goals, including:
  - making significant progress in the CIEL effort
  - making CVE content more "real time" by creating candidates more
    quickly and updating CVE versions more often
  - increasing international reach by translating CVE into other
    languages and adding more international Board members
  - establishing working relationships with the various Information
    Sharing and Analysis Centers (ISAC's)
  - adding other types of members to the Board, such as end users,
    auditing organizations, and security services.

Other future efforts were discussed.  Some upcoming conference
presentations were described; most of them will be for a different
audience than previous presentations.  Also, MITRE plans to collect
case studies in which CVE users discuss how they have integrated CVE
into their work.  Board members were asked to contribute case studies.


Senior Advisory Council Update
------------------------------

The Board was updated on the CVE Senior Advisory Council, which is
composed of senior executives in U.S. government agencies, many of
which provide funding for CVE.  MITRE has been developing the Advisory
Council for almost a year.  A list of current council members was
presented to attendees during the Editorial Board meeting.

The Council held its first meeting on January 25, 2001, in Washington,
DC.  Since then, the charter has been finalized and sent to the
Editorial Board mailing list.  The Council will hold face-to-face
meetings on a quarterly basis.  Some meetings might include
presentations from Editorial Board members.  A web page on the
Advisory Council will be added to the CVE web site.

There were some questions about the lack of commercial involvement in
the Council.  MITRE had attempted to find commercial supporters in the
early stages.  However, it was unable to find the appropriate
executives who might be interested in participating.  Editorial Board
members also suggested involving the ISAC's in the Advisory Council.
The Council has decided to limit membership to government, but it
recognizes that commercial involvement is important.  However, there
may be cases in which a commercial organization's membership on the
Editorial Board is not appropriate to the specific tasks.  MITRE may
create a separate organization with an industry focus on CVE.

The Editorial Board was also briefed on CVE's funding status.

With respect to CVE itself, one of the Council's main roles will be in
providing strategic guidance for the direction of CVE.  For example,
the Council has encouraged MITRE to involve the ISAC's more closely in
CVE, conduct outreach to large organizations outside of the security
industry, define qualitative goals, and concentrate more on CIEL.

Board members expressed an interest in receiving regular updates
regarding the status of the Advisory Council.


Issues With CVE Content Decisions
---------------------------------

MITRE presented its rationales for modifying some of the most common
and complex content decisions (CD's) in CVE.  (Content decisions are
criteria that determine which items should be included in the CVE
list, and the appropriate level of abstraction to use.)  Some CD's are
difficult to describe and formalize.  In some cases, CD's can not be
applied consistently due to the lack of available information, source
code, and/or individual expertise.  Some members have suggested taking
an ad hoc approach to each candidate.  However, now that additional
members of MITRE's content team are producing candidates, and more
people are reserving candidates for use in initial public
announcements, there is a growing need to make CD's easy to describe,
while defining them in a way that allows them to be applied
consistently to each CVE candidate.

For example, CD:SF-LOC ("software flaws/different lines of code")
suggests how many candidates should be created when there may be
multiple failure points (bugs) in a single product version.  When
applying the SF-LOC content decision, an analyst might encounter cases
in which it is difficult to identify how many failure points exist.
For example, the vulnerable product might not have source code which
could tell the analyst if several different attack vectors ultimately
reach the same failure point.  As a result, the CD would be
inconsistently applied to different vulnerabilities, depending on the
amount of information available.  In addition, later discoveries could
force a change in the level of abstraction, which would require
renumbering candidates or entries, increasing maintenance costs.

In previous discussions, the Editorial Board had suggested taking a
simple "split-by-default" approach in cases of uncertainty: i.e., if
there is insufficient information to be sure that 2 issues are the
same, then create separate candidates.  Since MITRE adopted this
approach, it produced a larger number of candidates than before, moved
CVE to a lower level of abstraction than that used by most databases
and tools, and made the effects of incomplete information even more
severe.

A more detailed description of these issues was posted to the
Editorial Board mailing list on March 13.  It is archived at
http://cve.mitre.org/board/archives/2001-03/threads.html with the
subject: [CD] Reconsidering "split-by-default" in content decisions

To address the problems described above, MITRE has since adopted a
middle-of-the road approach which is less dependent on the amount of
information that is available at the time of analysis.  The approach
is: (a) separate reported issues by the type of the vulnerability; (b)
if there appear to be multiple failure points of the same type -
e.g. buffer overflow - then they should be combined into the same
candidate; (c) write the CVE description, and use CVE's "dot
notation," to indicate the possibility of multiple vulnerabilities of
the same type; (d) if one vulnerability appears in a different product
version than another, then they should be separated.  Participants
agreed that this approach, while not perfect, was satisfactory.

Some members were concerned that the level of abstraction as specified
by CVE content decisions is too high for some uses, e.g. academic
study.  In turn, this reduces CVE's utility to such users.  Some
people wanted CVE to be more precise (i.e. use a lower level of
abstraction), as there are no other data sources that use that level.
It is believed that CVE's "dot notation" could satisfy the needs of
those users while maintaining the higher level of abstraction.
However, there may be several ways in which a CVE item could be broken
down into smaller parts, e.g. by individual failure points, or by the
different scripts that are available for exploiting the vulnerability.
Dot notation was originally accepted by the Editorial Board under the
assumption that only one type of abstraction would be needed below
CVE.  The concept might be extended to support multiple types of
abstraction.  However, it will be important to ensure that each
abstraction type has only one official notation.

There are other cases in which the level of abstraction used by CVE is
too low.  For example, a single patch could fix multiple
vulnerabilities.  Many system administrators might prefer that only
one CVE entry be used to cover all the possible issues.  This problem
is not being addressed at this time.

For each candidate, MITRE records the content decisions that affect
that candidate.  This information is accessible to Board members, but
it is not easily obtained by the public (although it is included in
candidate voting ballots, which are recorded in the mailing list
archives).  MITRE intends to make this information more easily
accessible to those people who wish to understand which candidates
were affected by such approaches to content decisions.  The data will
probably be provided as a separate extension, like reference maps.


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

MITRE provided the Board with an update on its evolving process for
establishing CVE compatibility and providing the appropriate branding,
and recent issues that have come to light.  Bob Martin of MITRE is the
task leader for CVE compatibility.

Some vendors have unquired about CVE compatibility for products whose
first versions were still in beta or alpha development.  To reduce the
risk of including CVE compatibility declarations for "vaporware,"
MITRE has decided to only post declarations for products that have had
at least one full public release.  (There is no such restriction for
products in beta development for which previous versions have already
been released.)  It was suggested that vendors with other
CVE-compatible products could be exempt from this restriction when
they are ready to release a new product line.

An additional requirement will be added in which the vendor's product
documentation must include a description of how the product uses CVE
names.  CVE-related documentation will be useful for MITRE to perform
its evaluation.  It will also help end users, because each product
will implement CVE compatibility in a different manner.  Board members
did not object to this additional requirement.

A new category of CVE-compatible "product" is also emerging - security
services.  Such services often use tools from multiple vendors, and
they provide reports to their customers.  The high-level requirements
(searchibility, output, and mapping accuracy) still apply to services.
However, the implementation of "searchability" is not necessarily
clear for services.  The current thinking is that a service is
CVE-searchable if either (a) it can provide the customer with a list
of CVE names for vulnerabilities that are identified by the service,
or (b) if a user provides a list of CVE names to the service vendor,
the vendor can list which of those CVE names are identified by the
service.

As the number of categories has grown - tools, databases, web sites,
and now services - the current requirements document is getting larger
and less easy to manage.  The requirements document will be modified
accordingly, possibly by creating separate implementation documents
for each type of product.

There was a question regarding whether compatibility applied to a
specific product and CVE version.  MITRE's evaluation of a specific
product will occur relative to a particular version, but as long as
the vendor follows the appropriate requirements for remaining
up-to-date and accurate with the product's mappings to CVE, then the
product remains compatible.  Thus, compatibility reflects the
functional implementation and the process of maintaining accuracy,
instead of being associated with a specific version.  However, there
are still some issues with respect to how CVE versions should be
properly handled and advertised within the product itself.

In cases of abuse, the requirements allow MITRE to revoke CVE
compatibility.  It was suggested that MITRE could provide an external
"complaint" mechanism for handling user's problems related to a
product's CVE compatibility; however, most problems should be handled
by the vendor's technical support capability.

MITRE is also considering performing a periodic renewal of
compatibility for a product, possibly at the vendor's request.


Process for CVE compatibility evaluation and branding
-----------------------------------------------------

MITRE's current approach for establishing compatibility involves two
stages.

Stage 1 includes:
  - the vendor's declaration of intent for compatibility
  - an endorsement quote from the vendor (if desired)
  - review of the declaration by a knowledgeable CVE team member
  - publication of the declaration on the CVE web site

Stage 1 is currently implemented for all products.  However, it does
not result in an official evaluation by MITRE that a product is
CVE-compatible.  The second stage, which MITRE is now developing,
identifies this process.

Stage 2 includes:
  - MITRE provides the vendor with a questionnaire in which the vendor
    provides details on how the requirements have been implemented in
    the product.
  - The vendor provides MITRE with a written statement of
    compatibility, i.e. the completed questionnaire.
  - The vendor provides MITRE with the CVE-related user documentation
    for the product.
  - The vendor provides MITRE with the mapping from product-specific
    vulnerability items to CVE names.
  - MITRE verifies the accuracy of the mapping, possibly by analyzing
    a random sample.
  - MITRE evaluates the vendor's statement of compatibility to ensure
    that it addresses the requirements by examining user documentation
    or screen shots, and/or running the tool itself
  - If the mapping is accurate, and the statement of compatibility and
    other materials satisfy the requirements, then MITRE establishes a
    concurrence with the statement.
  - MITRE provides the vendor with access to a CVE-compatible logo and
    other CVE promotional materials, possibly through a restricted web
    site.
  - The vendor's statement, and MITRE's concurrence, is posted on the
    public CVE web site.

If the vendor wishes, MITRE will be able to sign a non-disclosure
agreement during the second stage, until the final statement is
published.

The process is designed to minimize the expense for vendors and MITRE
in evaluating compatibility.  MITRE wants to avoid an expensive
evaluation process that makes it too expensive for freeware or smaller
software vendors to obtain compatibility.  The questionnaire and
statement of compatibility are designed so that the vendor properly
understands and implements the requirements.  The publication of the
vendor's statement on the CVE web site allows end users to compare how
different products satisfy the requirements; the market could then
decide which specific implementations are best.  There were no
objections to publicizing the statements of compatibility.

The Editorial Board agreed with this high-level approach.  MITRE will
continue to implement the details of the process.


Candidate Reservation and Candidate Numbering Authorities (CNA's)
-----------------------------------------------------------------

MITRE discussed the current process for candidate reservation,
i.e. the means by which vulnerability researchers, vendors, or third
parties can obtain CVE candidate numbers for inclusion in public
announcements of vulnerabilities.

Candidate reservation begins with a requester, i.e. the researcher,
vendor, or third party.  The requester, if new, will typically inquire
about the process; MITRE provides a description and rationale for the
process.  MITRE also asks for details of the vulnerability, in order
to apply content decisions to determine how many candidate numbers
must be assigned.  MITRE does not require such details, however; there
may be reasons why the requester is unwilling or unable to provide
such details, e.g. because of an NDA with the affected vendor.  If the
requester does not provide any details, MITRE still provides a
candidate (this is referred to as blind candidate reservation).  Blind
reservation has some benefits because the public has immediate access
to the candidate number when the issue is first publicized.  Also,
there is a reduced risk of accidental disclosure, since MITRE does not
have the information.  However, there is an increased risk that the
requester will use an incorrect number of candidates, or use a
candidate for a rediscovered issue that already has a CVE name.

Once all available details are provided, MITRE checks to see if the
problem is new, applies the CVE content decisions, and determines the
number of candidates necessary.  This may require further consultation
with the requester.  MITRE then sends the candidates to the requester,
along with descriptive text that could be included in the resulting
advisory.  Related communications, along with details of the
vulnerability, are then either encrypted or destroyed in order to
reduce the risk of accidental information exposure.  MITRE then
publishes the candidates on the CVE web site.  The description
indicates that the candidate was reserved, but it does not contain any
details about the problem (since the issue hasn't been published yet).

Sometime later, the requester publicizes the vulnerability (e.g. in a
security advisory or in a mailing list post).  The requester includes
the candidate number in the publication and notifies MITRE.  MITRE
then updates the CVE web site with the specific vulnerability details.
Since there is a delay between the publication of the vulnerability
and the update of the CVE web site, there is an increased reliance on
the requester to notify MITRE of publication; however, this does not
always happen in practice.  If the candidate was reserved blindly, it
may take longer to update it, since the vulnerability analysis must be
performed after publication.

The candidate is eventually proposed to the Editorial Board for review
and commentary, along with other candidates that are created through
the submission stage as described earlier in this document.  If the
candidate becomes an official entry, then MITRE notifies the
requester, who updates the advisory with the new CVE number, if
possible.  (This is not feasible in the case of mailing list
archives).


Blind Candidate Reservation Discussions
---------------------------------------

The Editorial Board provided some feedback on the current process,
especially the role of blind candidate reservation.

Some members expressed concerns that blind candidate reservation could
cause too many problems and weaken the credibility of CVE, especially
if the candidates are at the wrong level of abstraction relative to
CVE.  While statistics are not available, of the 100 candidates that
were reserved, approximately 20 to 25 of those reservations were
blind.

There has already been a case in which blind reservation produced an
inappropriate number of candidates relative to CVE's content
decisions.  There was also a separate case in which a candidate was
obtained for an issue that already had another candidate number
(though it did not take place through blind reservation).  CVE
diligence levels could partially address such concerns, since a
requester who uses candidates inappropriately could get a lower
diligence level, and eventually may not be allowed to reserve
candidates again.  However, some members said that diligence levels
would not help, because the candidates would already be public and
CVE's credibility would be affected even if the requester is not
allowed to obtain more candidates.  In addition, some of these errors
have been made by major researchers.  There could also be a
credibility problem if researchers obtain candidates for vulnerability
reports that turn out to be false, but Board members did not discuss
this problem in detail.

It was suggested that MITRE should not perform blind candidate
reservation unless the requester can show that they understand CVE
content decisions well enough that they can request the appropriate
number of candidates.  Board members agreed that this was a good
approach, and that the risks of blind candidate reservation outweighed
the benefits.  It was also suggested that if blind reservation occurs,
then the candidate should be clearly identified as such, so that
educated CVE users can understand that the level of abstraction may be
inappropriate.

There was some discussion regarding why some organizations do not use
blind candidate reservation, even if they have established that they
use candidates reliably.  Some requesters believe that providing MITRE
with such non-public information is an acceptable risk.  The
additional review by an outsider increases the chances of detecting a
duplicate issue that was already publicized.  MITRE also becomes a
"test subject" for the advisory that is being drafted, and as such can
identify potentially confusing descriptions.  Since there are some
subtleties with respect to content decisions in which the guidelines
are not necessarily clear, there is greater assurance of consistency
with MITRE's involvement.


Other Candidate Reservation Issues
----------------------------------

There was some discussion of situations in which multiple requesters
ask for candidates for the same issue.  This problem had been
addressed before.  Since newly discovered and unpublicized
vulnerabilities are competitive information, MITRE cannot make the
requesters aware that they have discovered the same problem.  MITRE
also cannot provide the same candidate to both requesters, because the
later requester may be able to tell that the candidate had already
been reserved.  A specific example was provided, in which ISS and NAI
both discovered buffer overflows in Network Monitor, and 2 candidates
were provided (CAN-2000-0817, CAN-2000-0885).  Including the affected
product vendor in the candidate reservation process would minimize
this risk of duplication, since the vendor would know about the
duplicate, and could provide the same candidate number to both
parties.  Since the publicized information uses candidate numbers,
educated CVE users would understand the risk of duplication; in
addition, the candidate voting process would be able to publicly
document and address the duplication.

Some members expressed concerns that candidates were being assigned to
issues too early.  There was some discussion regarding the role of
Bugtraq ID's and CVE candidates with respect to early vulnerability
information, as well as the process by which Bugtraq ID's are
assigned, but the members at the meeting did not know enough details
to have a substanive discussion.

It was also observed that the reservation process document that is
sent to the researcher, which advocates using the SecurityFocus
VulnHelp service to provide a Bugtraq ID (BID), might cause a problem
because SecurityFocus is a commercial organization.  The document
currently recommends obtaining the BID for several reasons: (a) it is
one of the most commonly used references, which ultimately helps end
users when mapping to CVE names; (b) it is expected that as the number
of people reserving candidates increases, more and more people will
not follow the normal process of resonsible disclosure; thus the
VulnHelp recommendation may increase the chance for responsible
disclosure; and (c) there are no other commercial organizations at
this time that provide such a service and offer a commonly used
identifier.  However, CERT/CC is not recommended as an option in the
current documentation.  The documentation will be reviewed and
modified to address such concerns.

The Board also discussed the distinction between Bugtraq ID's and CVE
candidates.  The difference is difficult to describe easily, and
reflects the partial overlap between how the two are used, especially
in the early stages of vulnerability information.  Much of the
discussion was hampered because critical members were not able to
participate in the meeting.  However, the distinction may become more
clearly defined as time goes on.


Candidate Numbering Authorities
-------------------------------

MITRE discussed some of its plans for creating additional Candidate
Numbering Authorities (CNA's).  Certain organizations could be given
the ability to reserve a collection of candidate numbers (a "pool")
which they could assign and use in the initial disclosure of
vulnerabilities.  CNA's could increase the number of candidates that
are used in initial vulnerability announcements, without involving
MITRE as an additional party and increasing the risk of accidental
disclosure.  CNA's could increase the speed with which candidates are
assigned to new problems and publicized.  This is presently difficult
for MITRE because it needs to process the large backlog of legacy
submissions before it can concentrate solely on new vulnerabilities.
Finally, if CNA's are the same organizations who are currently
involved in vulnerability disclosure, then they might be able to
integrate candidates into their own processes more easily than if
MITRE were directly involved.

Software vendors and certain third parties could be CNA's.  In recent
months, Microsoft has been obtaining pools of candidate numbers for
its own security bulletins, and as such is effectively a CNA already.
MITRE has begun exploring this option with other potential vendor
CNA's, primarily major operating system vendors.  Third parties who
act as an interface between the researcher and the vendor -
e.g. CERT/CC and SecurityFocus - could also be CNA's.  While it is
expected that third party CNA's should be well-known and trusted,
there are special issues with third party CNA's that need to be
addressed.

There are several issues related to general CNA operations that need
to be resolved.  Proper coordination across all involved parties is
necessary, to ensure that the same candidate number is used by all
parties.  This could be difficult for cases in which multiple vendors,
researchers, or CNA's are involved.  There is also an increased risk
of duplicate candidates as more organizations become involved.  If
diligence levels are formally adopted, then all CNA's will need to be
able to have access to that information, and possibly help maintain
it.  (Diligence levels, as currently written, need to be simplified.)
It may be difficult to publicize which CNA's, vendors, and researchers
use candidates, or to properly educate those who don't.  In addition,
the exchange of CVE names may not fit well with the current practice
in which vulnerability information is shared before publication.

CNA's will also need to follow CVE content decisions, which are not
well documented or finalized yet.  (An approach was developed with
Microsoft which ensured consistency with CVE content decisions.)
There are also potential risks of abuse by CNA's that are also
commercial organizations, whether they are vendor or third party
CNA's.  There may be complications if a vendor CNA disagrees with a
researcher's assessment of a vulnerability; in that case, the
researcher could contact MITRE or another CNA if necessary.

The discussion of CNA's was cut short due to time restrictions and the
lack of appropriate Board members who could best discuss the topic.
The idea will be developed in future discussions.


CVE Maintenance Issues
----------------------

The process for modifying and deprecating existing CVE entries, and
rejecting candidates, was briefly reviewed.  More details are in the
January teleconference summary at
http://cve.mitre.org/board/archives/2001-01/msg00010.html.

Since CVE currently has some duplicate entries, those entries will be
proposed for deprecation before the next version.  Similarly, a number
of entries will be modified, and several candidates will be rejected
(mostly because they are duplicates).


Rethinking the CVE naming scheme
--------------------------------

There was also some discussion regarding the current CVE naming
scheme.  There are two basic problems: (a) CVE names are normally not
considered atomic, and as such are not easily found by most search
mechanisms; and (b) the differing candidate and CVE numbering schemes
cause maintenance and search problems.

The current naming scheme for CVE entries is CVE-YYYY-NNNN; for
candidates, it is CAN-YYYY-NNNN.  However, many search engines
separate the name into 3 different terms (CAN, YYYY, NNNN) because the
hyphen is considered a word separator.  This makes it difficult to
easily find CVE information via search engines.  In other cases,
special quoting may be necessary.  For example, a database query for a
CVE name might need to quote the hyphen; otherwise, the query might
return items that do *not* match the YYYY or NNNN portions of the
name.  Finally, the encoding of the year in the name may cause some
problems with misuse, as indicated in a previous section on
determining a numbering scheme for legacy candidates.

Dot notation, depending on how it is implemented, could cause
additional problems for searchability.

Problems also arise because the candidate naming scheme
(CAN-YYYY-NNNN) is slightly different than the CVE naming scheme
(CVE-YYYY-NNNN).  While the name visually tells a user about the
status of a CVE item (candidate or entry), it can also cause some
problems.  For example, when a candidate becomes an official entry,
all CVE-compatible vendors would need to update their databases to
convert the candidate number to a CVE number.  This could be labor
intensive.  In addition, users might still search for the candidate
number instead of the CVE number; most CVE-compatible products will
not find the associated CVE entry if the user uses the candidate
number in the search.  To avoid this problem, each CVE-compatible
product would need to implement a specialized function.  Some products
omit the CAN- and CVE- prefixes outright, but this prevents the user
from knowing whether the item is a candidate or an entry.  The CVE web
site handles these discrepancies flexibly, but it requires some
special code.  Many CVE-compatible tools are not as flexible, and such
a capability is not required because CVE compatibility does not
require use of candidates.

A solution is to construct the CVE names in a way that minimizes these
types of implementation problems.  Using just a number would not be
appropriate, because numbers are so commonly used in so many databases
and search engines.  A scheme like the one used by the arachNIDS IDS
signature database, e.g. IDS297, might be better.  If such a scheme is
adopted, then the status of a CVE item - whether candidate or entry -
could be noted as a separate field in CVE.  There were no objections
to this proposal.

No decisions were made with respect to changing the CVE numbering
scheme.  It is uncertain how many products or web pages currently use
the existing names, and how the names are actually implemented.  There
will be high maintenance costs in some cases, along with additional
education of the public.  However, in the long term, it may be
appropriate to use a different numbering scheme.

These problems could be reduced if candidates are promoted to CVE
entries faster.  However, that would require more active participation
by the Editorial Board in voting.  Also, if stringent verification
requirements are adopted for CVE entries, there may be permanent
candidates.


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

A dynamic discussion was held regarding the progress of the Common
Intrusion Event List (CIEL), which is being developed by Bill Hill and
Steve Christey at MITRE, with additional support from other MITRE
personnel.

CIEL is sometimes informally described as "a CVE for intrusion
detection."  It is intended to provide a naming scheme for events -
whether on a network or on a host - that may be useful in detecting
intruder activities, but are not directly associated with CVE items.
For example, port mapping, ping mapping, legally structured network
requests, or failed binary integrity checks do not easily map to CVE
entries.  In addition, the process that is being used for assigning
CVE names might not be appropriate for IDS events.

MITRE has produced a draft CIEL which contains 37 entries, most of
them at a high level of abstraction, with additional fields that
support lower levels of detail.  MITRE has begun mapping various IDS
signatures to CIEL names and using those mappings for analysis.  In
one experiment, MITRE was able to reduce the number of reported events
by 15 percent, by converting the logged events to CIEL names and
removing duplicates.

MITRE has been observing the development of the data models of the
IETF Intrusion Detection Working Group (IDWG) to identify possible
conflicts with CIEL.  The IDWG efforts are more comprehensive in
scope.  A common attack name is a small but important part of the data
models, which specifically mention CVE and the Bugtraq ID as potential
naming schemes.


CIEL Assumptions and Rationales
-------------------------------

MITRE presented the assumptions and rationales for its approach in
developing the draft CIEL.  Since intrusion detection is event-focused
instead of vulnerability-focused, MITRE decided to develop it
independently of CVE.  Various "CVE lessons learned" were used to
guide the creation of the draft CIEL, but the expected use of CIEL
drove its development. MITRE's own research and operational efforts in
intrusion detection provided additional guidance.  The initial focus
was on network-based events; however, CIEL is expected to include
host-based events as well.

Several assumptions were made during development of the draft CIEL:

- there is a wider variety of IDS events than vulnerabilities

- there is more variety across IDS's in the level of abstraction (or
  level of detail) than there is in vulnerability scanners and
  databases.

- there is not much well-defined and commonly accepted terminology in
  IDS


CIEL Discoveries
----------------

It was often difficult to understand how an IDS examined and
identified an event, as details were rarely provided.  This was often
critical in deciding how to name the event.  It was recognized that
the actual method of detection might be competitive information.
Since those details may not be publicly available, users should be
able to assign a CIEL name without them.

Thus it was decided to create CIEL entries for each event as it is
reported, independent of how the IDS identifies the event.  However,
the lack of information could make it difficult for non-vendors to
create CIEL mappings, which would limit the end user's ability to make
an IDS "CIEL-compatible."  This problem is not so serious in
vulnerability scanners and databases.

MITRE examined the construction of CIEL for satisfying two main
purposes: normalizing data in order to facilitate quantitative
analysis (e.g. for comparing tools by counting how many CIEL entries
they have), and supporting the exchange of information across tools.
Often an approach would be useful for one purpose but not the other.
With the varying levels of abstraction used by tools, CIEL's use as a
data normalizer could be limited.  The focus for creating CIEL was
therefore on supporting information exchange, and the approach
addressed several important issues that were encountered in the draft
CIEL's creation.  However, this approach may have an impact on CIEL's
use in metrics.


CIEL "Content Decisions"
------------------------

Part of CVE's success is due to its simplicity.  MITRE decided that
this should be a requirement for CIEL as well.  While the CIEL name
has multiple components and is different than a CVE name, it is still
basic enough that it can be represented with a simple syntax.

Since IDSes operate at more widely varying levels of abstraction, it
was decided that CIEL would need to support multiple levels of
abstraction.  Thus, most CIEL entries are hierarchical in nature.
However, there were cases in which a type of event was unique to a
type of attack, application, or protocol.  It was decided that such
unique characteristics, if reported by IDSes, would need to be
captured by a CIEL entry, even if the entry was at a lower level of
abstraction.  For example, the FTP bounce attack is specific to the
FTP protocol, and could not be easily described by CIEL entries that
were at a higher level of abstraction.

Some difficulties in creating the first CIEL entries involved the
types of events that are reported by today's IDS technology, in
comparison with events that might only be detectable by future IDSes.
It was decided that the focus should remain on the types of events
that can be detected by current IDS technology.


CIEL Entry Data
---------------

The following information is included with each entry in the draft
CIEL.

1) Name - the CIEL name, of the form CIELn, where n is a unique
   number.

2) Description - a short description of the entry.

3) Context fields - additional fields that provide additional
   information that may help distinguish events at a lower level of
   abstraction.  Up to 3 different context fields can be used for each
   CIEL entry.  The types and values of each field are dependent on
   the specific CIEL entry.  Context fields could allow IDSes that
   operate at different levels of abstraction to share information at
   a high level, via the same base identifier (the CIEL name).

   In some cases, context fields were used to handle cases in which it
   was infeasible to use separate CIEL names for each "instance" of an
   event type.  For example, there is a single draft CIEL entry that
   is related to Trojan horse activity, with a context field whose
   value indicates the specific Trojan horse being used.

   Many context fields in the draft CIEL would require normalized
   values.  CIEL will need to include such "value mappings" to ensure
   consistency across IDSes.  (For example, one IDS might report
   "Tribe Flood Network," whereas another one reports "TFN"; such
   information, which may be recorded in a context field, needs to be
   normalized.)

4) Notes - background information on the rationale behind the CIEL
   entry, or a description of which context fields would need
   normalized values.

A short symbolic name was also provided for ease of use in mappings,
and may be included in later CIEL versions.

Most items in the draft CIEL did not have good references that would
describe the type of attack in more detail; thus, references were not
included.


Review of Draft CIEL Entries
----------------------------

MITRE presented several draft CIEL entries for discussion.  The
examples were posted to the Editorial Board mailing list, and are
archived at http://cve.mitre.org/board/archives/2001-03/threads.html
with the subject "[CIEL] Extracts from the Draft CIEL"

1) CIEL1, which is used to describe all types of ICMP events (ping,
   netmask request, etc.).  The context fields are used to identify
   the type and code, as defined in the ICMP RFC.

2) CIEL2, which describes TCP related activities.  The context field
   captures the source and destination number.  One problem with
   respect to this entry is that some IDSes may detect and report
   services on nonstandard ports.

3) CIEL22, which identifies attacks on specific vulnerabilities in the
   targeted systems.  The context fields include the name source
   (e.g. CVE), and the actual name (e.g. CVE-1999-0067).  The
   allowance for multiple naming schemes is currently being used in
   IETF Intrusion Detection Working Group (IDWG) standardization
   efforts, so it made sense to support it here.

4) CIEL23, which describes Trojan Horse activity.  The context fields
   include the name of the Trojan, the specific action being taken,
   and any arguments that may be extracted or identified.

5) Some lower-level entries.  Board members believed that these
   entries might be captured by other higher-level CIEL entries in the
   draft CIEL; or, additional high-level entries could be constructed.

Some Board members questioned the use of a single CIEL entry, CIEL22,
to describe all possible attacks on specific vulnerabilities.  This
reflects MITRE's decision to design CIEL for interoperability instead
of metrics.  Some IDS'es may detect hundreds of vulnerability
exploits, but they would only be covered by one high-level CIEL entry.
However, interoperability is still possible by using the context
fields that identify the name of the vulnerability being exploited.
It was posited that all items covered in an IDS could be described by
some vulnerability or exposure, and as such would always have some CVE
name associated with it.  Future efforts in CIEL (and CVE) will show
whether or not this is the case.

Some Board members said that the draft CIEL as presented makes it
difficult to determine the CIEL name for events that fall under the
higher-level CIEL entries, i.e. events that can only be described
using context fields.  Strong networking knowledge or research is
often needed.  For example, to determine the CIEL name for an ICMP
echo request (ping), the CIEL user would need to know that the type is
0 and the code is 8.  This significantly reduces the usability of the
draft CIEL as currently written.  A reference document could be
created that matches well-known events (such as ping) with their CIEL
names to increase usability.  It was also proposed that a naming
system similar to the Dewey decimal system could be adopted; the CIEL
name, in conjunction with its context fields, may be similar.

Many participating Board members, especially the IDS vendors, found
that the high-level draft CIEL entries did not seem to describe same
categories that they might have used.  In some cases, the problem may
have been due to MITRE's lack of information on the precise way in
which some signatures were detected.  As such, the draft CIEL may
represent more of an end-user perspective than a vendor's perspective.

Board members also discussed some CIEL entries that were at a much
lower level of abstraction than others.  Members believed that they
could create a higher-level entry which would include the lower-level
items.

Overall, the Board agreed with the hierarchical nature of the draft
CIEL.


CIEL Future Work
----------------

MITRE will create a CIEL working group and mailing list that is part
of the CVE Editorial Board.  MITRE plans to add other members to the
Board for the purposes of the working group.  The group may be
expanded to include other individuals or organizations who are not
part of the Editorial Board.

MITRE will provide the working group with the full draft CIEL as a
starting point for further discussions.

Board members discussed adapting the draft CIEL to reflect a more
natural classification of IDS-reported events.  Each member could
provide a representative list of approximately 20 signatures from
their products, and a proposal for high-level CIEL entries that would
cover those signatures.  The end result could be a draft CIEL that is
better suited to interoperability of IDS products.

MITRE will continue to use its draft CIEL to create mappings, perform
some analytical tasks, and share lessons learned with the working
group.