CNAs using CVE IDs for Internal Bug Tracking

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

CNAs using CVE IDs for Internal Bug Tracking

Coffin, Chris

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.

 

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.

 

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

Reply | Threaded
Open this post in threaded view
|

Re: CNAs using CVE IDs for Internal Bug Tracking

jericho
On Fri, 24 Feb 2017, Coffin, Chris 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.

To me, this is a pretty simple 'fix' based on dealing with most of the
CNAs in a variety of ways, including reporting dozens of vulns.

: Some CNAs currently assign CVE IDs as a final step before publication,

e.g. Oracle. I have traded mails with Bruce about this (and after our
emails, they are evaluating my feedback), saying that I do not agree with
this policy (and others pertaining to CVE assignment). One thing he and
others bring up is what you did above. Assigning before details are
figured out or the issue is validated. The easy fix to that is assign as
soon as the vendor confirms it is a valid issue that warrants a CVE.

That will put the assignment somewhere between day 1 (reporting) and day X
(disclosure) that is not on day X or day X-1.

So I vote for flexibility... but I strongly vote against blindly assigning
on day 1, and I strongly vote against assigning day X.

.b
Reply | Threaded
Open this post in threaded view
|

Re: CNAs using CVE IDs for Internal Bug Tracking

Kurt Seifried-2
In reply to this post by Coffin, Chris


On Fri, Feb 24, 2017 at 3:11 PM, Coffin, Chris <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CNAs using CVE IDs for Internal Bug Tracking

jericho
On Fri, 24 Feb 2017, Kurt Seifried wrote:

: > 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

That would be slick, having ASSIGNED to designate that interim state.

But given the historical dismal communication between CNAs back to MITRE,
that might many years in the making before it became useful/reliable.

.b