Skip to content

Latest commit

 

History

History
84 lines (47 loc) · 5.33 KB

CVE-Assignment-HOWTO.md

File metadata and controls

84 lines (47 loc) · 5.33 KB

The DWF is a federated CVE Numbering Authority (CNA), which can assign CVE numbers on the behalf of a requester. This HowTo document provides the procedure for a person working in the DWF to assign a CVE for single or multiple issues.

This procedure must be followed for all DWF-issued CVEs and is strongly suggested for CNAs under the DWF. If you are unsure at any step, please ask the requester for more information or contact your parent CNA for help.

CVE-Assignment Procedure

Step 1: Determine the product and CNA

The DWF handles requests for open-source software unless there is a more specific vendor for the application (for example, Debian or Red Hat), in which case the CVE request should be routed to that CNA. For a list of CNAs, go to: https://cve.mitre.org/cve/cna.html

In the case of dual-license vendors (both open and closed source), the DWF can also handle assignments for closed-source software.

For software which is fully closed source, route the request to the vendor's CNA.

If the CVE request can be handled by the DWF, go to step 2.

Step 2: Decide whether the flaw is a vulnerability

Decide on the type of vulnerability:

  • Is a trust boundary crossed (what does that even mean)?
  • Is there privilege escalation, remote access, information disclosure, or denial of service?
  • Does it cross an arbitrary rule like “web applications must use httponly on cookies”?
  • Does it violate the stated security policy for the system or application?

Typically a vulnerability will map to a CWE identifier (see http://cwe.mitre.org/data/index.html), but not always. For more information, see CVE Assignment Is It a Vulnerability?

If you determine that the issue is a vulnerability, go to step 3. If the issue is not a vulnerability, go to step 7.

Step 3: Confirm the report and its artifacts

If the request is coming from another party, confirm the report and artifacts (if available). Depending on your trust level with the requester, this can be highly involved or completely trust based. A solid rule of thumb is to look at the number of correct CVE requests the person has made in the past.

Note that trust data will be added to the DNA (DWF Numbering Authority) registry as time goes on. After confirming the request (or deciding the requester is highly trusted), go to step 4. If the report is denied, got to step 7.

Step 4: SPLIT/MERGE the vulnerabilities

If you have only one vulnerability, this is a simple CVE assignment; go to step 5.

If you have multiple vulnerabilities, you must SPLIT/MERGE them so that CVEs can be properly assigned.

Remember that the CVE standard is a pragmatic one; although it would be “correct” to assign one CVE per vulnerability instance, it wouldn’t be practical or add much value (because people tend to fix things at once rather then dribble out fixes). Group the vulnerabilities by code base, vulnerability type (for example, CWE type), affected version, and the reporter (researcher or organization) in the case of multiple reporters reporting similar flaws at the same time.

Ideally each group of CVEs should have a unique codebase, vulnerability, the same affected version, and originate from the same researcher(s). Once you have everything sorted out, proceed to step 5.

For more information, see CVE Assignment SPLIT and MERGE Vulnerabilities.

Step 5: Assign CVE in DWF database as RESERVED

The DWF uses a two-stage commit process. We first mark the CVE as reserved, and then add the details later (if available). Other CNAs use a similar process because it makes embargo handling simpler.

To reserve the CVE, update the DWF-Database for the current year (for example, DWF-Database-2016.csv).

After the CVE has been RESERVED:

  • If the CVE is public, please proceed to step 6.
  • If the CVE is embargoed, please proceed to step 7.

Step 6: Store artifacts and mark PUBLIC

If the data for this CVE is public:

  1. Add the artifacts in the artifact database and create the JSON file entry (see DWF-Database-Artifacts).

  2. Optionally, add the title and a copy of the description can be added to the CVE Database (TODO: DWF-CVE-Integration?).

  3. Mark the entry as PUBLIC (TODO: DWF-Database?).

Proceed next to step 7 and notify the requester that the CVE has been made public.

Step 7: Provide CVE feedback to requester

After the CVE is assigned, it must be communicated back to the original requester. If you are a CNA in the DWF CNA hierarchy, you must also report the CVE “upstream” to the DWF.

Embargoed vulnerabilities

Currently the DWF does NOT handle embargoed CVE assignments. In order to do this, the DWF would have to have (at a minimum):

  • Service Level Agreements (SLAs) around public release times
  • A secure storage mechanism for the embargoed information
  • Technology to ensure automation and ensure humans don't accidentally release the information early

In other words, if you currently request a CVE from the DWF, it will go public as soon as we assign it.

Tooling Notes

In the future, the majority of the CVE-assignment process will be automated using well-formed submissions, tools to accept and store artifacts, and tooling to assign the CVE and update the relevant databases as needed and then notify the CVE requester. However, at this time we have not yet deployed this technology and are still mostly using a manual process.