Organizational and technical issues for CVE

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

All:

Below is a writeup of some of the technical and organizational issues
that the Editorial Board will need to deal with.  While some of these
were mentioned in a previous email, they were all brought up at one
time or another during SANS.

Other Board members may have additional issues that arose during last
week.  Andre Frech has also written something up, but I don't want to
forward it without his approval.

- Steve



*** Organizational/Board-level Issues ***

1) Editorial Board structure, membership, and participation needs to
be reconsidered.  Approximately 20 additional organizations have
requested membership on the Editorial Board.  Requests have come from
individuals at the technical and management levels, from a broad range
of organizations including consulting firms, US government, incident
response teams, security vendors, and "end users" (e.g. security
analysts).  It is clear that a number of different roles and/or
functions for the Board need to be devised in order to accommodate a
broad range of participation levels.  MITRE is re-evaluating the
Board's structure and membership rules, but any suggestions by the
current Board are of course welcome.  A small number of individuals or
organizations are being "grandfathered" because we started discussions
with them well before CVE became public, but we are freezing all other
membership until this issue is formalized.

2) "CVE compatibility" needs to be made more explicit and objective.
As mentioned earlier, informally we'd like "CVE compatibility" to be a
label that has a significant meaning.  A number of Board members have
asked that we be more specific about how CVE compatibility can be
objectively measured.  Dave Mann and I believe that CVE compatibility
should include the following at a minimum:
  - (a) A user should be able to use a CVE name to locate related
    records/probes/signatures;
  - (b) The database/tool output should be able to report CVE names;
  - (c) There is some guarantee of accuracy (e.g. for tools, a claim
    to check for CVE-XXXX-YYYY should imply that the tool does a
    "reasonably good" job of detecting CVE-XXXX-YYYY.)
Obviously, (c) is the most difficult to formalize and verify, but it
is necessary in order to prevent abuse.

See my earlier email titled "CVE compatibility and future Editorial
Board activities" for a more detailed writeup of this issue.

3) We will provide links on the CVE web site to organizations that
"declare" that their tools/databases will become CVE compatible.  At
this point in time, only CERT, CyberSafe, and NTBugtraq have made
public declarations to this effect.  Security Focus' database already
includes requirement (b) of the requirement stated above.  Obviously,
other Board members intend to do the same.  I think a URL to a web
page containing the declaration would be sufficient.

4) We should schedule an Editorial Board teleconference (a la the
August CVE Review meetings) shortly after next week's NISSC
conference, e.g. the last week of October or the first week of
November.  In addition, we should have a face-to-face meeting sometime
in December or January.

5) OS/application vendors, consulting firms, government organizations,
and "end users" have very little representation on the Board at this
time.  This will need to be addressed.


*** Technical Issues ***


1) See my earlier email titled "CVE compatibility and future Editorial
Board activities" for a number of technical issues that I won't repeat
here.

2) There have been some questions as to the next milestone for the CVE
Initiative to achieve.  In the audio press conference, Steve Northcutt
indirectly issued a challenge to achieve 1000 CVE entries.  Scott
Blake apparently posed an even bigger milestone of "CVE2K by Y2K."
Following a CVE entry from Bugtraq/NTBugtraq to tools to response
teams could be another concrete milestone.  Keeping up with all newly
discovered problems would be another.  A more concrete
Interoperability Demo that people besides me can explain ;-) would be
another milestone.

3) A number of people expressed concerns with the time frame that it
takes from candidate proposal to CVE acceptance.  With the process
I've currently defined, the minimum amount of time is 2 weeks.  This
may be sufficient for full CVE acceptance, but it is also clear that
many people want candidate numbers generated as soon as possible (one
person wanted something on the order of hours or minutes to be able to
handle emergency situations, e.g. Melissa).  We can deal with this
issue as we cover CNA-related issues over the next few months.

4) There are some questions as to the best approach for back-filling
old CVE entries, in combination with dealing with new entries.  As
mentioned in the earlier email, candidate clusters appear to be the
way to go at this point in time.  There will need to be some
coordination across databases to minimize the amount of "candidate
noise" that's generated (e.g. duplicate candidates or those at an
inconsistent level of abstraction).  Some end users at SANS expressed
the need to assign candidate numbers to all known issues as soon as
possible.

5) It is clear that at the very least, a number of mailing lists or
alternate distribution mechanisms need to be provided.  For example, a
"cve-announce" or similar mailing list could be useful to post all
Final Decisions, upcoming events, etc.  Another mailing list, open to
anyone and perhaps unmoderated, could be used to discuss CVE-related
issues.

6) There will be a need to define a CVE mapping language to facilitate
sharing CVE mappings.  I'll take a first stab at such a language.
Simplicity will be paramount.