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

[COMPAT] CVE Compatibility Requirements - version 0.8.1



Following is the latest version of the CVE Compatibility Requirements.
This version (or a very similar one) will likely be the basis of our
evaluations.  If you would like to help "beta test" our CVE
compatibility evaluation process, then please contact me and Bob
(ramartin@mitre.org).  You should be a product/service vendor who
believes that you already satisfy the requirements.

- Steve


============================================================================
Requirements and Recommendations for CVE Compatibility
============================================================================
Steve Christey
The MITRE Corporation
coley@mitre.org
CVE web site: http://cve.mitre.org

Document version: 0.8.1
Date: November 29, 2001


*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***
*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***
*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***

This is a draft report and does not represent an official position of
the MITRE Corporation.  (c) 2001, The MITRE Corporation.  All rights
reserved.  Permission is granted to redistribute this document if this
paragraph is not removed.  This draft is subject to change without
notice.

*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***
*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***
*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***


============================================================================
Table of Contents
============================================================================
1. Definitions
2. High-Level Requirements
3. Accuracy
4. Documentation
5. CVE Version Usage
6. Candidate Name Usage
7. Revocation of CVE Compatibility
8. Review Authority
Appendix A: Type-Specific Requirements
Appendix B: Media Requirements


============================================================================
1. Definitions
============================================================================

Capability - a security tool, database, web site, advisory, or service
that provides a security vulnerability or exposure identification
function.

User - a consumer or potential consumer of the Capability.

Owner - the owner or maintainer of the Capability.

Security Element - a database record, e-mail message, security
advisory, assessment probe, signature, etc., which is related to a
specific vulnerability or exposure.

Repository - an implicit or explicit collection of security elements
that supports a capability, e.g. a vulnerability database, the set of
signatures in an intrusion detection system (IDS), or web site.

Tool - a software application or device that examines a host or
network and produces information that is related to vulnerabilities or
exposures, e.g. a vulnerability scanner, intrusion detection system,
or a risk management product.

Task - a Tool's probe, check, signature, etc. which performs some
action that produces security information (i.e. the security element).

Map/Mapping - the specification of relationships between security
elements in a Repository and the CVE entries or candidates that are
related to those elements.

Review - the process of determining whether a capability is
CVE-compatible.

Review Version - the version of CVE that is being used for determining
CVE compatibility of a capability.

Review Authority - an entity that performs a Review.  MITRE is the
only Review Authority at this time.

Review Sample - the set of security elements in the capability's
repository that is used by the Review Authority for evaluating
accuracy.

Accuracy Percentage - the percentage of security elements in the
Review Sample that reference the correct CVE identifiers

Sampling Method - the method by which the Review Authority identifies
the set of security elements in the Review Sample.

Sample Size - the percentage and/or the number of security elements to
be examined by the Review Authority.

============================================================================
2. High-Level Requirements
============================================================================

These are the high-level requirements for all capabilities.  Many of
them are described in detail in later sections.

*************
Prerequisites
*************

2.1) The Owner MUST be a valid legal entity, i.e. an organization or a
     specific individual, with a valid phone number, e-mail address,
     and street mail address.

2.2) The capability MUST provide additional value or information beyond
     that which is provided in CVE itself (i.e. name, description,
     references, and associated candidate data).

2.3) The Owner MUST provide the Review Authority with a technical
     point of contact who is qualified to answer questions related to
     the mapping and any CVE-related functionality of the capability.

2.4) The capability MUST be available to the public, or to a set of
     consumers, in a production version.

2.5) The Owner MUST provide the Review Authority with a completed CVE
     Compatibility Requirements Evaluation Form.

2.6) The Owner MUST provide the Review Authority with free access to
     the Repository so that the Authority can determine that the
     Repository satisfies all associated requirements.

2.7) The Owner MUST agree to abide by the CVE Compatibility
     Requirements in their entirety.


*************
Functionality
*************

2.8) The capability MUST allow users to locate security elements using
     CVE names ("CVE-Searchable").

2.9) When the capability presents security elements to the user, it MUST
     allow the user to obtain the associated CVE names ("CVE-Output").

2.10) The capability's mapping MUST accurately link security elements to
      the appropriate CVE names ("Mapping Accuracy").

2.11) The capability MUST use CVE version numbers properly ("Version
      Usage")

2.12) The capability MUST satisfy any additional requirements for the
      specific type of capability, as specified in Appendix A.

2.13) The capability MUST satisfy all requirements for its
      distribution media, as specified in Appendix B.

2.14) The capability is NOT REQUIRED to do any of the following:
      - use the same descriptions or references as CVE
      - use CVE candidate names
      - include every CVE entry in its repository

*************
Miscellaneous
*************

2.15) If the capability does not satisfy all requirements, then the
      Owner MUST NOT advertise that it is CVE-compatible.


============================================================================
3. Accuracy
============================================================================

CVE compatibility only facilitates data sharing if the capability's
mapping is accurate.  Therefore, CVE-compatible capabilities must meet
minimum accuracy requirements.

3.1) The Repository MUST have an Accuracy Percentage of 90% or
     greater.

3.2) During the review period, the Owner MUST correct any mapping
     errors found by the Review Authority.

3.3) After the review period, the Owner SHOULD correct a mapping error
     within a reasonable time frame after the error was initially
     reported, i.e. within 2 versions of the repository or 6 months,
     whichever is shorter.

3.4) The Owner SHOULD prepare and sign a statement that, to the best
     of the Owner's knowledge, there are no errors in the mapping.


============================================================================
4. Documentation
============================================================================

The following requirements apply to documentation that is provided
with the capability.

4.1) The documentation MUST include a brief description of CVE and CVE
     compatibility.

4.1.1) The documentation MAY include verbatim portions of documents that
       are available on the CVE Web site.

4.2) The documentation MUST describe how the user can find individual
     security elements in the capability's repository by using CVE
     names.

4.3) The documentation MUST describe how the user can obtain CVE names
     from individual elements in the capability's repository.

4.4) If the documentation includes an index, then it SHOULD include
     references to CVE-related documentation under the term "CVE."


============================================================================
5. CVE Version Usage
============================================================================

Users must know how "up-to-date" a capability's repository is with
respect to its mapping to CVE.  The capability owner can indicate the
currency of a mapping by using CVE version numbers.

5.1) Each new version of the capability MUST identify the most recent
     CVE version that was used in creating or updating the mapping.
     The capability is "up-to-date" with respect to that version.

5.1.1) The Owner MAY use supporting documentation (such as Change logs
       or new feature lists) to satisfy 5.1.

5.2) Each new version of the capability SHOULD be up-to-date with
     respect to a CVE version that was released no more than 6 months
     before the capability was made available to its users.  If a
     capability does not satisfy this requirement, then it is
     "out-of-date."

5.3) The Owner SHOULD publicize how quickly it will update the
     capability's repository after a new CVE version is created.


============================================================================
6. Candidate Name Usage
============================================================================

A capability may include CVE candidate names, but it is not required
to do so.  CVE compatibility is only established with respect to the
entries on the official CVE list.  It is not expected that the use of
candidates will become required for CVE compatibility.  However, when
a capability uses candidates, certain recommendations must be
followed.

If the capability uses candidate names, then:

6.1) The capability MUST clearly indicate to the user that the candidate
     name is not an accepted CVE entry.  The use of the CAN- prefix
     itself is sufficient to indicate candidate status.

6.2) The capability SHOULD include additional supporting documentation
     that describes how candidates are different than official entries.

6.2.1) The documentation MAY include verbatim portions of documents that
       are available on the CVE Web site.

6.3) If a candidate has become an official CVE entry within the Review
     Version (or earlier), then the capability's repository SHOULD
     replace that candidate name with the associated CVE name/names.  In
     other words, the Owner should keep up-to-date with respect to
     candidates that become official entries.

6.4) If a user performs a search using YYYY-NNNN, the capability SHOULD
     return the security elements that correspond to CAN-YYYY-NNNN or
     CVE-YYYY-NNNN.

6.5) If the Capability contains the official entry CVE-YYYY-NNNN, but
     the user searches using CAN-YYYY-NNNN, then the Capability SHOULD
     return CVE-YYYY-NNNN, and vice versa.

6.6) The Capability SHOULD indicate the release date associated with the
     candidate information.


============================================================================
7. Revocation of CVE Compatibility
============================================================================

7.1) If a Review Authority has verified that a Capability is
     CVE-compatible, but at a later time the Review Authority has
     evidence that the requirements are not being met, then the Review
     Authority MAY revoke its approval.

7.1.1) The Review Authority MUST identify the specific requirements
       that are not being met.

7.2) The Review Authority MUST determine if the actions or claims of
     the Owner are "intentionally misleading."

7.2.1) The Review Authority MAY interpret the phrase "intentionally
       misleading" as it wishes.

7.3) Unless recommended by two Editorial Board members who do not have
     a conflict of interest, the Review Authority SHOULD NOT consider
     revoking CVE compatibility for a particular Capability more often
     than once every six months.

**********************
Warning and Evaluation
**********************

7.4) The Review Authority MUST provide the Capability Owner and
     Technical POC with a warning of revocation at least 2 months
     before revocation is scheduled to occur.

7.4.1) If the Review Authority has found that the Owner's actions or
       claims are intentionally misleading, then the Review Authority
       MAY skip the warning period.

7.5) If the Owner believes that the requirements are being met, then
     the Owner MAY respond to the warning of revocation by providing
     specific details that indicate why the Capability meets the
     requirements under question.

7.6) If the Owner modifies the Capability so that it complies with the
     requirements in question during the warning period, then the
     Review Authority SHOULD end the revocation action for the
     Capability.

**********
Revocation
**********

7.7) The Review Authority MAY delay the date of revocation.

7.8) The Review Authority MUST publicize that CVE compatibility has been
     revoked for the capability.

7.9) If the Review Authority finds that the Owner's actions with
     respect to CVE compatibility requirements are intentionally
     misleading, then revocation SHOULD last a minimum of one year.

7.10) The Review Authority MAY publicize the reason for revocation.

7.11) If the approval is revoked, the Owner MUST NOT apply for a new
      review during the period of revocation.



============================================================================
8. Review Authority
============================================================================

8.1) The Review Authority MUST review the capability for CVE
     compatibility with respect to a specific CVE version, i.e. the
     Review Version.

8.2) The Review Authority MUST clearly identify the Review Version that
     was used to determine compatibility for the capability.

8.3) The Review Authority MUST clearly identify the version of the CVE
     compatibility requirements document that was used to determine
     compatibility for the capability.

8.4) The Review Authority MUST define and publish a Sample Size.

8.4.1) The Review Authority SHOULD use a minimum Sample Size of either
       50 elements or 20% of the capability's repository.

8.4.2) The Review Authority MAY review every element in the
       capability's repository.

8.5) The Review Authority MUST publicize the Sampling Method.

8.6) The Review Authority MAY use a Review Sample that was not
     randomly selected.

8.7) The Review Authority MUST use the same Sampling Method and Sample
     Size for all capabilities that are evaluated within the same time
     frame.

8.8) The Review Authority SHOULD review a Capability at least once per
     year.


============================================================================
Appendix A: Type-Specific Requirements
============================================================================

Since a wide variety of capabilities use CVE, certain types of
capabilities may have unique features that require special attention
with respect to CVE compatibility.

A.1) The Capability MUST satisfy all additional requirements that are
     related to the specific type of capability.

A.1.1) If the Capability is a vulnerability assessment scanner,
       intrusion detection system (IDS), or a product which integrates
       the results of one or more scanners and IDSes, then it must
       satisfy the requirements as specified in A.2.

A.1.2) If the Capability is a service (such as a managed intrusion
       detection and response service, or a remote scanning service),
       then it must satisfy the requirements as specified in A.3.

A.1.3) If the Capability is an online vulnerability or signature
       database, web-based archive, or maintenance/patch site, then it
       must satisfy the requirements as specified in A.4.

*****************
Tool Requirements
*****************

A.2.1) The Tool MUST allow the user to use CVE names to locate
       associated tasks in that tool ("CVE-Searchable").

A.2.1.1) The Tool MAY satisfy this requirement by providing the user
         with a mapping between that Tool's Task names and CVE names.

A.2.2) For any report that identifies individual security elements,
       the Tool MUST allow the user to determine the associated CVE
       names for those elements ("CVE-Output").

A.2.2.1) The Tool SHOULD allow the user to include CVE names directly
         in the report.

A.2.2.2) The Tool MAY satisfy A.2.2 by providing the user with a
         mapping between that Tool's Task names and CVE names.

A.2.3) Any required reports or mappings MUST satisfy the media
       requirements as specified in Appendix B.

A.2.4) The Tool, or the Owner, SHOULD provide the user with a list of
       all CVE entries that are associated with the Tool's Tasks.

A.2.5) The Tool SHOULD allow the user to select a set of Tasks by
       providing a file that contains a list of CVE names.

A.2.6) The interface of the Tool SHOULD allow the user to browse,
       select, and deselect a set of Tasks by using individual CVE
       names.

A.2.7) If the Tool does not have a Task that is associated with a CVE
       name as specified by the user in (A.2.5) or (A.2.6) above, then
       the Tool SHOULD notify the user that it cannot perform the
       associated Task.

A.2.8) The Owner SHOULD warrant that, for each Task that is associated
       with a CVE entry, (1) the rate of false positives is less than
       100%, i.e. if a Tool reports a specific security element, it is
       at least sometimes correct, and (2) the rate of false negatives
       is less than 100%, i.e. if an event occurs that is related to a
       specific security element, then sometimes the Tool reports that
       event.

*****************************
Security Service Requirements
*****************************

Security services might use CVE-compatible tools in their work, but
they may not provide their customers with direct access to those
tools.  Thus it could be difficult for customers to identify and
compare the capabilities of different services.  The Security Service
Requirements address this potential limitation.

A.3.1) The Security Service MUST be able to use CVE names to tell a
       user which security elements are tested or detected by the
       service with one of the following capabilities
       ("CVE-Searchable")

A.3.1.1) If a user asks the Security Service for a list of CVE names
         that identify the elements that are tested or detected by
         that Service, then the Service SHOULD be able to respond with
         a list of CVE names that identifies those elements.

A.3.1.2) If a user provides the Security Service with a list of CVE
         names, then the Service SHOULD be able to identify which of
         those CVE names are tested or detected by the Service.

A.3.1.3) The Security Service MAY satisfy this requirement by
         providing the user with a mapping between the Service's
         security elements and CVE names.

A.3.2) For any report that identifies individual security elements,
       the Service MUST allow the user to determine the associated CVE
       names for those elements ("CVE-Output").

A.3.2.1) The Service SHOULD allow the user to include CVE names
         directly in the report.

A.3.2.2) The Service MAY satisfy A.3.2 by providing the user with a
         mapping between the security elements and CVE names.

A.3.3) Any required reports or mappings that are provided by the
       Service MUST satisfy the media requirements as specified in
       Appendix B.

A.3.4) If the Service provides the user with direct access to a
       product that identifies security elements, then that product
       SHOULD be CVE-compatible.


******************************
Online Capability Requirements
******************************

A.4.1) The Online Capability MUST allow a user to provide a CVE name
       into a search function and retrieve the related security
       elements from the Online Capability's repository
       ("CVE-Searchable").

A.4.1.1) The Online Capability MAY satisfy A.4.1 by providing a
         mapping that links each element with its associated CVE
         name(s).

A.4.1.2) The Online Capability SHOULD provide a URL "template" that
         allows a computer program to easily construct a link that
         accesses the search function as outlined in (1).  Examples:

         http://www.example.com/cve/my-db-cve-name.cgi?name=CVE-YYYY-NNNN
         http://www.example.com/cve/CVE-YYYY-NNNN.html

A.4.1.3) If the URL template is for a CGI program, the program MUST
         accept the HTTP "GET" method.

A.4.2) For any report that identifies individual security elements,
       the Online Capability MUST allow the user to determine the
       associated CVE names for those elements ("CVE-Output").

A.4.2.1) The Online Capability SHOULD allow the user to include CVE
         names directly in the report.

A.4.2.2) The Online Capability MAY satisfy A.4.2 by providing the user
         with a mapping between the security elements and CVE names.

A.4.3) If the Online Capability does not provide details for
       individual security elements,then the Online Capability MUST
       provide a mapping that links each element with its associated
       CVE name(s).

A.4.4) The Online Capability MAY link to specific CVE entries on the
       official CVE web site.  The URL template is:

       http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-NNNN


============================================================================
Appendix B: Media Requirements
============================================================================

B.1) The distribution media that is used by a CVE-compatible
     capability MUST use a media format that is covered in this
     appendix.

B.2) The media format MUST satisfy the specific requirements for that
     format.


******************************************************************
Electronic documents (HTML, word processor, PDF, ASCII text, etc.)
******************************************************************

B.3.1) The document MUST be in a format whose reader has a "find" or
       "search" function ("CVE-Searchable").  Example: A .PDF
       formatted file can be processed by the Acrobat reader, which
       has a search function.

B.3.1.1) A document that consists of raw ASCII text or HTML satisfies
         this requirement.

B.3.2) If the document lists details for an individual element, then
       it MUST list the CVE entries that map to that element
       ("CVE-Output").

B.3.2.1) If the document does not list details for individual
         elements, then it MUST satisfy requirement B.4.3.

B.3.3) The document SHOULD include a mapping from elements to CVE
       names, which lists the appropriate pages for each element.


******************************
Graphical User Interface (GUI)
******************************

B.4.1) The GUI MUST provide the user with a search function that
       allows the user to enter a CVE name and retrieve the related
       elements ("CVE-Searchable").

B.4.2) If the GUI lists details for an individual element, then it
       MUST list the CVE entry (or entries) that map to that element
       ("CVE-Output").

B.4.2.1) If the GUI does not list details for individual elements,
         then it MUST provide the user with a mapping in a format that
         satisfies the B.3 Media Requirements.

B.4.3) The GUI SHOULD allow the user to export or access CVE-related
       data in an alternate format that satisfies the B.3 Media
       Requirements.

 
Page Last Updated: May 22, 2007