[CVEPRI] Editorial Board Review Meeting Summary - 11/4/1999

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

Below is a writeup of the CVE review teleconference on November 4,
1999.  I've omitted some details that are provided in the Powerpoint
slides I sent out a few days ago.


Participants
------------

The following Board members participated in the teleconference:

Mike Prosser
Eric Cole
Tom Stracener
Craig Ozancin
Pascal Meunier
Andre Frech
Dave Balenson
Stuart Staniford-Chen
Kelly Cooper
Scott Blake
Andy Balinsky

Participants from MITRE included Margie Zuk, Bill Hill, Pete Tasker,
Dave Mann, and Steve Christey.


Recent Activities
-----------------

We first discussed the recent Board activities, including the SANS and
NISSC conferences in October.  Board members who participated in the
CVE booth said that they got strong positive reactions from conference
attendees, although some expressed concerns about whether CVE would
ultimately be successful or not.  Board members often had to educate
people that CVE is not a "canonical" database, and some people had a
hard time believing that vendors were working together on this
initiative.


Proposed CVE Goals
------------------

We then proposed some concrete technical goals for CVE.  With respect
to CVE content, there were several goals that the Board agreed to.
The first goal is to have CVE contain 500 entries by January 1, 2000.
Some Board members considered this goal slightly aggressive, but
achievable.  A second goal is to assign candidate numbers for all
publicly known problems discovered in 1999 and 2000.  Finally, other
measurable goals would be to begin using candidate numbers (or CVE
numbers) in CERT advisories, security vendor advisories, software
vendor advisories, mailing lists, etc.

We also discussed some high-level goals of having a positive impact on
industry and academia.  These goals include: customers having
requirements for CVE compatibility of their security tools, achieving
CVE compatibility in N% of all tools or databases, CVE being used to
support some tool analysis (e.g. by the press such as InfoWorld or in
demonstrations such as ID'Net), and CVE playing a role in some
academic research (e.g. by providing a list from which a researcher
could take a sample to test some analytical approach).

We also discussed the goal of having the Editorial Board grow more
diverse and reach a critical mass which will allow the Board as a
whole to engage in active and timely participation.  One suggestion
was made to provide a "CVE Wish List" that the Board could post to the
public.  The wish list could include small projects or other efforts
that other members of the community could take on.  This might foster
more extensive community participation and allow the Board to focus on
specific goals.

We presented MITRE's near-term goals, which include: finalizing CVE
compatibility issues, preparing for upcoming candidate submissions,
establishing communication mechanisms such as announcement mailing
lists or discussion forums, and updating the web site.  We intend to
make regular updates to the web site and allow for rapid response in
rare cases.  The next few weeks' updates will likely include an
introduction to candidates for end users, supporting quotes, some
optional registration, and graphics from the CVE booth.

With respect to CVE content, we presented a roughly prioritized list
of tasks.  The highest priority item is to add more CVE entries and
candidates.  We also intend to provide additional support to Board
members by making voting and candidate information available in an
accessible format, with a longer-term goal of building a full-fledged
support database.  We will then formalize phase changes for CVE
entries (e.g. to deprecate or modify CVE entries), define MIF (Mapping
Interchange Format), and guide ongoing discussions of content
decisions, many of which have not yet been sufficiently discussed by
the Board.


Candidate Issues
----------------

We spent a good amount of time on candidate issues.  We proposed that
now is a good time to educate the public about candidates.  As we
attach candidate numbers to new information, it will become easier in
the future to create CVE mappings and establish CVE compatibility, so
the earlier we start using candidates, the better.

A challenge is to avoid confusion between candidates and validated CVE
entries.  If there is a reasonable assurance that there is a
one-to-one mapping between a candidate number and the resulting CVE
number, then this problem could be minimized somewhat.  CNA's should
help to ensure this.

Below are some suggested ways of presenting candidates when they are
used in advisories, summaries, etc.:

  CVE Candidate Number: CAN-1999-9999 [pending validation]

  supporting text: "This number is a temporary number assigned by the
  CVE Editorial Board.  It will be validated by the Board before it is
  given a final CVE number."

  link or reference to a candidate page on the CVE web site


We presented a process for Board members to submit new candidates.
This process is described in more detail in the slides and in recent
emails to the Board.  One issue involved the desired "turnaround
time," i.e. when the submission is first made and how quickly the CNA
should respond with a candidate number.  In general, Board members
thought that turnaround times could range between a day and several
weeks.  It was suggested that a priority level could be attached to
each submission, where each priority level had an expected turnaround
time associated with it.  Extremely rapid turnaround, i.e. on the
order of hours, might become feasible in the future, especially as
more CNA's become available.

We discussed the process for legacy candidate submissions.  Board
members were asked to provide either a "top 100 list" and/or a "six
month list" of submissions that they want to see included in CVE,
given a relatively hard deadline of November 12.  The resulting
candidates could then be used to help us accomplish the 500 entry
goal.  At least 9 Board members believed that they would be able to
provide some list by November 12.

Finally, we explored some issues related to non-public candidates.
Some Board members - mostly vendors who do their own vulnerability
analysis - wanted the ability to obtain a candidate name for a problem
that is not yet public, in order to attach the name to an advisory or
other formal announcement.  While it would be optimal to associate a
validated CVE number with the advisory, there are several
complications associated with this approach.  The problem would need
to be reviewed by any Board member who would vote on it, but if the
information is released to other Board members, it could remove the
competitive advantage.  In addition, Board-wide secure communication
channels poses a challenge in terms of technical implementation,
assurance of confidentiality, timely provision of the information to
the public, and "fair play" between competitors.  As long as the CNA
can assure that there will be a one-to-one relationship between a
candidate number and the resulting CVE number in most cases, then a
candidate number would be sufficient for use in a public announcement.
This would only require secure communications between the submitter
and a CNA that they trust.  Another concern was related to additional
threats with respect to disclosure of the information, e.g. the
locations of the confidential information could themselves be
subjected to attack.  While these issues were not fully resolved, at
this time it appears that submitters of non-public candidates can work
things out directly with MITRE, since at this time MITRE is the only
CNA.



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

We proposed an idea for having two "levels" of CVE compatibility.  The
intention was to handle separate but conflicting interests:
  - some will speak CVE simply because they want to support it.  But
    they don't necessarily want it to be difficult or expensive to
    obtain a "CVE-compatible" logo
  - others expressed the desire for a strong "label" that they could
    use for marketing purposes, to protect against abuse, or provide
    some high degree of assurance to the consumer

We proposed the idea of two levels of "speaking CVE."  The first
level, CVE Compatibility, would be simple, informal, and easy to
obtain.  There would not be any formal evaluation by MITRE.  They
would then be granted permission to use a logo.  MITRE would reserve
the right to rescind permission to use the logo if it is believed that
the organization is abusing it, e.g. they claim they're CVE compatible
but the quality turns out to be very low.

We proposed a second level, CVE Certification.  This would have a
formal application and certification process.  MITRE or another
approved authority would conduct a detailed analysis of the mapping to
ensure accuracy.  As certification would be more expensive to conduct,
it might require an evaluation fee, though steps would be taken to
prevent it from unfairly excluding some organizations.

Both levels included a requirement that the organization should
provide MITRE with their database mapping.  The mapping would serve
two functions: (a) it would identify items in the database which still
need to be added to CVE, and (b) it would allow MITRE to review the
mapping and provide feedback to the organization.  It was emphasized
that these mappings would not be made available to any organization
outside MITRE, however it is highly likely that consumers may request
the mapping from the organization, e.g. to help them compare products
for purchase.

Board members believed that at this time, only the "CVE Compatible"
level is necessary.  As long as there is some protection against
abuse, consumers might find compatibility sufficient for their needs.
It was pointed out that compatibility problems (such as inaccurate
mappings) would be obvious both to competitors and to end users.  As
long as the abuse was limited, e.g. by rescinding the rights to use
the logo, then this level might be sufficient.  As the market matures
and CVE compatibility is obtained - perhaps in a year or more -
certification may need to be revisited.  However, at this time, Board
members were satisfied with the informal, simple approach for CVE
compatibility.

Some issues were raised as to how CVE might begin to play a role in
the marketing of products.  End users would have to be educated on how
CVE could be misused in comparing products.  The "numbers games" of
tools (e.g. whether a tool has 500 checks or 300 checks) could still
be played, even using CVE as a standard.  For example, a tool that
focuses on Windows NT should not be compared with one that focuses on
Unix.  The idea of CVE "sublists" could play a role here, i.e. a tool
could be compared against a particular subset of CVE entries that
might be a "gold standard" of sorts.  As tools and databases become
CVE compatible early next year, we will need to address the issue of
marketing using CVE, and educating the public about the nature of how
CVE should be used when comparing tools or databases.


Editorial Board Issues
----------------------

We discussed MITRE's approach to communications and relations with
Board members.  Our experiences with many Board member organizations
have posed some communications challenges.  Besides the technical
contacts on the Board, there is a need to establish contacts for
marketing, PR, and management departments so that we can make sure
that everyone involved gets the appropriate information.  There is
also a need to develop a good business case for participation in the
CVE Initiative.

As the Board has grown, there has been a greater reliance on sending
email to the entire list, instead of email or phone calls to
individuals.

While the Editorial Board has been an informal organization, there is
a need to provide better descriptions of Board roles and
responsibilities.  These will help current or prospective Board
members to understand what their contributions to the Board should be.

The basic responsibilities have been identified as:
  - discuss and vote on specific CVE entries
  - discuss and vote on content decisions
  - discuss CVE update/maintenance issues
  - identify and accomplish high-level goals for CVE
  - educate the public about CVE
  - express strong support for CVE compatibility
  - advocate CVE

Board members considered requiring that any member with a tool or
database should make it CVE compatible.  However, it was decided that
making it a requirement was too stringent.  Some concerns were
expressed that some Board members may want to make their tools or
databases CVE compatible, but may be prevented due to external factors
(e.g. product development cycles or reticence of their management).
It was agreed that members should make every reasonable effort to make
their databases CVE compatible.

We outlined different roles that Editorial Board members might take,
with the notion that these roles can provide guidance to members on
how to participate in Board activities.  These roles have not been
formalized, although they may need to be in the future.  *Technical*
members deal with CVE content itself by voting on CVE entries,
discussing content decisions and CVE maintenance, etc.  *Advisory*
members might be high-visibility or high-impact individuals who can
advocate CVE and introduce it to a large audience.  *Liaisons* may
directly or indirectly represent a significant constituency that
doesn't necessarily require full participation in Board activities.
Finally, *Observers* are not official Board members, but they may wish
to follow Board activities closely or be involved indirectly.

We described our current approaches for adding new members, which
includes an interview of the prospective member to determine technical
skills and ability to commit time to the effort.

MITRE postponed most recruiting activities until they were reviewed by
the Board.  We only concentrated on recruiting prospective members who
had expressed an interest in CVE before RAID '99 (early September).

We have been focusing on filling in a number of gaps in Board
membership, including:
  - "End users," i.e. consumers of security information
  - Windows NT experts
  - OS/applications vendors
  - Consultants/auditors
  - Freeware tool vendors
  - Incident response teams
  - Government agencies
  - International organizations

Board members were satisfied with this approach and saw no need to
formalize membership at this time (e.g. through voting by the entire
Board).  There was also some discussion of how to conduct removal of
Board members - e.g. if a member abuses their position on the Board
and acts against the spirit of the CVE Initiative.  It was suggested
that MITRE should consult with the Board member to determine if
removal is required, and do this consultation in private.

Overall, Board members continued to be satisfied with the informal
nature of the Board and did not express concerns with how MITRE has
been conducting Board business.  There was a recognition that as the
Board matures or as new events occur, there may be a need to formalize
membership rules, but it is not necessary at this time.



Next Meeting
------------

We discussed the need to hold regularly scheduled meetings, especially
in these early days when CVE is so dynamic and there are so many
unresolved issues.

We proposed having a monthly teleconference, with face-to-face
meetings on a less frequent basis.  We will try to hold a
teleconference in early December, and give Board members at least 2
weeks' notice so they can schedule appropriately.  In addition, the
next face-to-face meeting needs to be scheduled.  A February meeting
somewhere near the US West Coast was suggested.  Board members from
AXENT and UC Davis have suggested that they may be able to host such a
meeting; however, there has been no formal commitment at this time by
either member.