|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[COMPAT] CVE Compatibility Requirements - version 0.8.1
- To: cve-editorial-board-list@lists.mitre.org
- Subject: [COMPAT] CVE Compatibility Requirements - version 0.8.1
- From: "Steven M. Christey" <coley@linus.mitre.org>
- Date: Fri, 30 Nov 2001 18:46:28 -0500 (EST)
- Delivery-Date: Fri Nov 30 18:46:45 2001
- Sender: owner-cve-editorial-board-list@lists.mitre.org
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.
- Prev by Date: [PROPOSAL] Cluster RECENT-74 - 29 candidates
- Prev by thread: [PROPOSAL] Cluster RECENT-74 - 29 candidates
- Index(es):