[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[CVEPRI] Request for vulnerability databases to populate CVE

All:

If you have a vulnerability database or product, you are requested to
provide your full database to MITRE so that we can generate and
propose more legacy candidates.  Note that this is already being
considered as a requirement for CVE compatibility, since CVE must be
made complete with respect to compatible databases.  (See Section 3.2
of the first draft of CVE Compatibility requirements, at
http://cve.mitre.org/Board_Sponsors/archives/msg00627.html).  We are
not asking for any non-public vulnerabilities you may have in your
database.

Participants who contribute their databases will be acknowledged on
the CVE web site.

As you may recall, in November 1999, 10 Board members sent in "top
100" lists of vulnerabilities from their databases, referred to as
*submissions*.  (Submissions are raw data items that are being
considered for candidates).  Unfortunately, there was very little
overlap between all those submissions (almost 800 unique issues were
identified!).  As a result, many of them were for a problem that
nobody else submitted.  Many haven't been converted to legacy
candidates yet due to lack of information.  (During candidate
creation, having multiple submissions available improves the quality
of the candidates, as well as their chances for acceptance by the
Board.)

Having all the data available at the same time will help us to
integrate all submissions related to a new candidate.  We will be able
to create better candidates for the Board to review.  It will help us
to tailor your voting, e.g. for candidates you've already got in your
database, and/or for candidates that are in many databases.  Tailored
voting proved to be very effective during last August/September when
we were preparing for the first release of CVE.

Copyright restrictions will be followed, of course, and you can send
it to us encrypted if you wish.  If you are not comfortable with
directly providing us with your database, we can work with you to sign
an NDA.


INFORMATION NEEDED
------------------

For each *submission* in your database, the following information is
needed:

1) Your internal identifier for the submission.  With this identifier,
   we can provide you with a *backmap* to the candidate numbers that
   are generated.  This will further simplify your mapping efforts,
   since you will have the link from your ID to the candidate name.
   Backmap information will not be used for any other purpose without
   permission of the owners.

2) Description text and/or details.  This information will be used to
   find submissions from other databases and create a candidate (if
   there isn't already a match).  Description text will *not* be used
   in any resulting CVE candidates; we will write our own CVE-style
   descriptions.

3) References.  References are critical for being able to correlate
   information from multiple sources.  URLs are also requested for
   these references, if available.  References will be added to the
   candidates.

The following information is optional:

1) Associated CVE names.  This only applies to those who have made
   their products CVE-compatible (or CVE-searchable or CVE-Reportable,
   a.k.a. CVE-Output).  This will help us to (a) filter out those
   elements in your database when we do our submission matching, and
   (b) give us more data to help determine how to measure the quality
   and comprehensiveness of mappings.

2) Date of the public announcement of the problem.  Some vulnerability
   databases have this information.  It is useful for prioritizing
   which candidates to propose, and it may help other types of CVE
   maintenance.



MITRE'S USE AND PROTECTION OF THE INFORMATION
---------------------------------------------

Any other information in your submissions will be deleted.

All individual submissions and backmaps will be clearly marked with a
copyright statement.  Their distribution will be limited to MITRE's
CVE content team, who performs various tasks related to submissions.
They will take steps to ensure that submissions are not inadvertently
released or made accessible to anyone else.  (As an example of this
"need-to-know" in action, David Mann never saw a submission while he
was at MITRE.)  Anonymized submissions may also be provided to
selected MITRE personnel with expertise in information retrieval and
natural language; they can help to make the integration problem more
manageable.



FORMAT OF THE INFORMATION
-------------------------

We will accept any format as long as it is formatted well enough that
we can write a program, or use a commonly available application, to
extract the information.  ASCII text is preferred.

The format can be comma-separated, HTML, XML, raw text, Excel
spreadsheet, etc.

We want to reduce the amount of work that you need to do as much as
possible.  In November, we found that our request for a specific
format made it more difficult for contributors to provide us with the
information.  So we'll take care of the processing on our end.


TARGET DEADLINE
---------------

We would like to receive these databases by June 1.  Last November,
some Board members submitted their databases late in the process,
during the *refinement* phase (i.e., after the submissions were
grouped, they are *refined* into candidates).  It is difficult to
integrate new submissions into the refinement phase, so it is
preferred that you provide us with your database by June 1.



Thanks to all contributing Board members ahead of time.  With enough
people participating, we can identify and create the bulk of legacy
candidates with this one large, focused effort.


- Steve
Page Last Updated or Reviewed: May 22, 2007