|
|||||
This document provides information on how to reserve a CVE ID(s) from the MITRE CNA of Last Resort (CNA-LR) before publicizing a new vulnerability so that CVE IDs can be included in the initial public announcement of the vulnerability and can be used to track vulnerabilities. Other CVE Numbering Authorities (CNAs) and other CNA-LRs have their own processes.
Some important things to note:
The CVE is then published by the MITRE CNA-LR Team, and will appear on the CVE List.
Also see:
Appendix A: Documents on Disclosure Practices
Appendix B: Determining if CVE IDs Are Needed
Appendix C: PGP Key
The steps above are detailed in the sections below.
CVE IDs are currently only assigned to vulnerabilities that are going to be publicly announced.
You should make a good faith effort to notify the affected vendor and work with them to ensure that a patch is available prior to publicly disclosing the vulnerability. Information is more accurate and complete when researchers and vendors work together. This practice also reduces the likelihood of a duplicate CVE ID being issued, which can happen when both a researcher and vendor request CVE IDs.
Without independent confirmation or vendor acknowledgment, it may not be possible to determine if the vulnerability is real, which could result in a request for a CVE ID being denied.
There are several documents that provide guidelines on disclosure. See Appendix A: Documents on Disclosure Practices for more details.
In general, you should do the following:
a) Work with the vendor to explain the problem, conduct further analysis if necessary, test any patches that the vendor proposes, and ensure the accuracy of both your, and the vendor's, advisory.
When possible, do not announce a vulnerability until the vendor has provided a patch. This could take between one day and six months, depending on the vendor and the nature of the problem. If you believe that the issue is urgent and the vendor is not responding quickly enough, try using a coordinator as described in #4. Also, you should avoid releasing precise details of the vulnerability until system administrators have time to apply the patch.
Software vendors participating as CNAs assign CVE IDs for their own products. If the vulnerability is related to a CNA product, contact the appropriate CNA organization directly. If the request is accepted, the organization will assign a CVE ID for the issue and include it in its initial public announcement.
If a CVE ID cannot be requested through a CNA, consider contacting a third-party coordinator such as an emergency response or vulnerability analysis team (e.g., CERT/CC), especially when there are problems in contacting the affected vendor. If the request is accepted, that organization will work to have a CVE ID assigned to the issue. Or, you may post the information to mailing lists such as Bugtraq or oss-security and, if accepted, the issue will eventually be assigned a CVE ID by a CNA.
If you are unable to obtain a CVE ID via the methods cited above, you may request a CVE ID from the MITRE CNA-LR as a last resort using the CVE Request web form and selecting "Request a CVE ID" from the dropdown menu (view guidance). Complete the "Request a CVE ID" web form.
The "Request a CVE ID" selection on the MITRE CNA-LR's CVE Request web form requires the following information:
The required information is the minimum information required to request a CVE ID. However, you can also provide optional information which can be used to provide additional detail for your CVE ID request and may be valuable to creating the CVE Record as well as for downstream consumers.
Optional information includes:
Upon completion of the CVE Request web form, the requester will receive a confirmation email that the request was received and a reference number. If you need to communicate with the MITRE CNA-LR about this request, reply to the confirmation email without changing the subject line, as it contains the reference number associated with your request.
Continue to use email to provide additional information or to follow up on a request(s), as each new message is linked to the reference number for tracking purposes. If you do not seem to have received a confirmation email, please check your spam folder.
If the MITRE CNA-LR Team requires any additional clarification, they will contact the requester via email, referencing the confirmation number for the submitted CVE Request.
Once there is enough information to confirm the vulnerability exists and that it affects a covered product, the CVE Team will reply to the requester with a CVE ID. The CVE ID is considered "RESERVED" at this stage. Descriptions with details of the vulnerability will only be added when the vulnerability is made public (see step 12).
If the vulnerability is not confirmed, or if it is not in a covered product, a CVE ID request may be rejected. In this case, the requester will receive a response from the MITRE CNA-LR notifying them of the decision.
Once a CVE ID is obtained, provide it to all affected vendors and other parties (such as CERT/CC) with whom you are communicating. This makes it easier to share information about the vulnerability and reduces the risk that different parties may assign different CVE IDs to the same vulnerability.
When publishing a vulnerability with an associated CVE ID, include the CVE ID in the announcement. Announcements containing multiple CVE IDs should delineate which CVE ID is associated with which vulnerability.
The following information may be contained in the vulnerability announcement:
Some tips:
After your announcement has been publicized, contact the MITRE CNA-LR via the CVE Request web form. Select "Notify CVE about a publication" and provide the following information:
Until this information is provided to the MITRE CNA-LR, only a reserved CVE Record may be recorded on the CVE website. No description or details of the vulnerability will be made available in the CVE Record until the vulnerability has been publicized.
When notified of a publication, the MITRE CNA-LR will then publish the CVE Record with a Description and References. This information will be made available on the CVE List.
The CVE information will also be updated in the U.S. National Vulnerability Database (NVD).
The following documents describe processes and provide guidelines for coordinated vulnerability disclosure practices.
There are several factors to consider to determine whether one or more vulnerabilities require a CVE ID when providing information to the MITRE CNA-LR:
A. Duplicates
Duplicates may be found by searching the CVE List on the CVE website and also by general web searches. Also, if a researcher previously contacted another organization on the CNA list about a vulnerability, a CVE ID assignment may already exist. The vulnerability should not be duplicated by the assignment of two CVE IDs.
B. Origination
CVE IDs are assigned to issues for which the primary method of addressing the vulnerability is for the vendor to take an action to remediate the vulnerability in their product. CVE IDs are not for cases in which the primary method of addressing the vulnerability is for an action to be taken by the operator of a single website or online service.
C. Establishing a policy violation
CVE IDs are needed when the vendor agrees that the observed product behavior violates a security policy, such as an unintended loss of confidentiality, integrity, or availability. CVE IDs are not for cases in which a reporter unilaterally believes that product hardening is desirable, such as a different approach to abuse prevention, or a different display of security-relevant data.
D. Establishing whether the vulnerabilities differ
In cases of multiple findings reported at the same time for a single product, separate CVE IDs are sometimes needed when there is a difference in the primary vulnerability types or affected versions.
E. Cross-vendor coordination
Separate CVE IDs are not assigned solely because vulnerable code is shipped in more than one product. Particularly in the case of open-source software, it is common for multiple vendors to use the same CVE ID in any scenario in which they have bundled, repackaged, or copied a piece of vulnerable code.
You may encrypt any post-web form communications using PGP or GnuPG (gpg), with the MITRE CNA-LR's PGP key, which can be downloaded from various PGP key servers.