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

Re: CNAs using CVE IDs for Internal Bug Tracking





On Fri, Feb 24, 2017 at 3:11 PM, Coffin, Chris <ccoffin@mitre.org> wrote:

As part of the Feb 22 CVE Board call, the Board discussed CNAs using CVE IDs as part of their internal bug tracking. Specifically, when assigning CVE IDs early in the vulnerability management process by the CNA, CVE IDs may be assigned to issues where the details are not fully understood yet (e.g., the issue is later found to not be a vulnerability, multiple vulnerabilities turn out to be one, etc.) or for which there is never an intention to make them public. We know there are software maintainers that would like to function in this way. CVE would like to reach out to the Board as a whole and CNAs to better inform any decision made regarding whether this should be allowed.

 

Some CNAs currently assign CVE IDs as a final step before publication, and we are in no way stating that this is wrong or attempting to guide these CNAs away from continuing this practice. Instead, the question is if CNAs should be given the flexibility to assign CVE IDs in whatever way works best for their them. In order to support this flexibility, the current CNA Rules would need to be changed.

 

The main benefit pointed out by the proponents of this idea claim that using CVE IDs early in the process allows the CNAs to more easily track their vulnerabilities throughout their lifecycle. For example, attaching a CVE ID as a first step in the process avoids the need for assigning an internal ID (e.g., internal bug id) and then having to later map that internal ID to a CVE ID. One additional point brought up in the Board call discussion was the fact that allowing this flexibility in assignment could promote additional use of CVE IDs in the future.


Also for sharing when dealing with embedded components (e.g. Open Source, but also commercial stuff now that is in containers.other systems like back end databases), or with software that is widely reshipped by multiple vendors (e.g. ISC DHCP, BIND, etc.). 
 

 

One downside of this flexibility would be that downstream CVE users will not be able to determine if a CVE ID is in use.  We already have this problem with number of RESERVED CVE IDs in the list, but MITRE is making an effort to reduce the number RESERVED CVE IDs.  However, the proposed change would make this problem worse.

 

One suggestion was made on the Board call that might help mitigate some of the problems associated with allowing this flexibility to CNAs. The suggestion was to create a new CVE ID status to cover CNA block reservations. Instead of RESERVED, we might refer to them as CNA-ASSIGNED or some other tag that differentiates them from other currently RESERVED CVE IDs. This could help CVE end-users differentiate between CVE IDs assigned as blocks to CNAs versus CVE IDs assigned to researchers for public or non-public but already identified vulnerabilities.


I would suggest we have several main states:

RESERVED by a CNA that plans use it (e.g. may be part of a block) - I'm not sure we need to explicitly mention this (e.g. my block of 1 million...)
ASSIGNED by a CNA but not yet public
PUBLIC

With the DWF my plan is to simply list the CNA's and their blocks so that people know who "owns" what, a CVE would be listed as RESERVED by the DWF once a CNA has privately assigned it (e.g. embargoed issue). Ideally once it goes public it will be flipped to PUBLIC very quickly with details. 
 

 

In addition to the above, another mitigation might be to recommend that the CNAs repurpose CVE IDs whenever possible. If the bug is later found NOT to be a vulnerability, they could release the CVE ID for use in a later issue. We could also enforce that CNAs report their unused CVE IDs (i.e., those CVE IDs that were NOT made public) on at least a yearly basis so that the CVE IDs can be REJECTED as unused. The CVE IDs may effectively live on within the CNA, but it would be considered unused and REJECTED by MITRE if it was not reported to an upstream CNA and made public.

 

We are considering starting a discussion on the CNA-list to get feedback from other CNAs, but figured we would run it by the Board first since not everyone was on the call. Do others on the Board object to allowing CNAs the flexibility to assign CVE IDs as has been proposed here?

 

The CVE Team




--
Kurt Seifried
kurt@seifried.org

Page Last Updated or Reviewed: February 25, 2017