RE: CVE Current States

["Coffin, Chris" <ccoffin@mitre.org>]

Beverly,

 

Ø  You mentioned ALLOCATED when talking about UNASSIGNED state.  Is ALLOCATED a state or would this be same as RESERVED?

 

Emphasizing ALLOCATED was actually not intended and was a mistake in that first list, and I do consider it synonymous with RESERVED. This is especially the case when thinking in terms of CNA allocated blocks or pools of CVE IDs. However, if we go with the second option, allocation seems appropriate within the STATE_DETAIL, e.g., STATE:RESERVED, STATE_DETAIL:CNA_ALLOCATION.

 

Ø  For REJECT, if there is not a defined list of reject reasons, I encourage the team to define them (for consistency in reporting).  Add ‘other’ as a catchall for anything missed. 

 

With the exception of the catchall category, I think the list I provided is pretty close. They are defined, but only through descriptive prose at this point. Agree that we just need to pick some names and go with it. We will probably identify more in the future.

 

Ø  For REJECT, if there is not a defined list of reject reasons, I encourage the team to define them (for consistency in reporting).  Add ‘other’ as a catchall for anything missed. 

 

As discussed in the Board call, if we set an expiration on RESERVED CVE IDs, it seems appropriate to add a STATE_DETAIL to REJECT for expired or stale reservations.

 

Chris

 

From: Beverly Finch [mailto:beverlyfinch@lenovo.com]
Sent: Friday, May 26, 2017 9:00 AM
To: Coffin, Chris <ccoffin@mitre.org>; Kurt Seifried <kseifried@redhat.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: CVE Current States

 

Chris,

 

I prefer the second option.  Keep RESERVED as the state and add STATE_DETAIL. 

I can’t think of any other possible state details but we should consider any reporting requirements/stats that may be helpful to Mitre or CNAs in the future.

 

You mentioned ALLOCATED when talking about UNASSIGNED state.  Is ALLOCATED a state or would this be same as RESERVED?

 

For REJECT, if there is not a defined list of reject reasons, I encourage the team to define them (for consistency in reporting).  Add ‘other’ as a catchall for anything missed.  Some ‘fault’ needs to be associated with each reason in order to be actionable in the future.

For this reject reason, I think this means CNA pulled CVE from old list?  CNA expired pool

 

Finally, and related to the last question, what STATE would cover deactivation of unused CVEs for the previous year?  For instance, someone searches for deactivated CVE, as opposed to expired one that was assigned by mistake and then rejected. Perhaps DEACTIVATED or EXPIRED would work.  I think there is some value in assigning a state so they don’t think it may ever be published at a future time.

 

 

Regards,

 

Beverly M Finch, PMP PSIRT Program Manager Product Security Office 7001 Development Drive Office 3N-C1 Morrisville, NC  27560	+1 919 294 5873 beverlyfinch@lenovo.com
Lenovo.com  Twitter | Facebook | Instagram | Blogs | Forums

 

 

From: Coffin, Chris [mailto:ccoffin@mitre.org]
Sent: Friday, May 26, 2017 9:37 AM
To: Beverly Finch; Kurt Seifried
Cc: cve-editorial-board-list
Subject: RE: CVE Current States

 

Kurt,

 

This seems perfectly reasonable and I like the idea. What do others think?

 

In addition, both you and Art Manion had mentioned in a previous thread that we should expand the RESERVED state to cover the different scenarios. We agree and believe that this would help consumers of CVE to better understand the status of a non-populated CVE ID, as opposed to just marking everything as RESERVED. There are a few options for implementing this as was previously pointed out.

 

-          One option is to split RESERVED into multiple states as was described by Art. RESERVED would be used only for CVE IDs given to CNAs but not yet attached to a vulnerability. The next step would be to create a new state for CVE IDs that are actually attached to a vulnerability, such as ASSIGNED.

-          The other option would be to keep RESERVED as the state, but implement STATE_DETAIL that would include the various stages of a CVE ID. Kurt had mentioned this in the previous thread. The stages would include CNA block allocation and vulnerability assignment. I don’t believe that there would be other STATE_DETAILS beyond these two, but would be interested if others have additional thoughts.

 

Chris

 

From: Beverly Finch [mailto:beverlyfinch@lenovo.com]
Sent: Thursday, May 25, 2017 8:49 PM
To: Kurt Seifried <kseifried@redhat.com>; Coffin, Chris <ccoffin@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: CVE Current States

 

I like that.  Will help fine-tune the reporting.

 

 

 

Regards,

 

Beverly M Finch, PMP PSIRT Program Manager Product Security Office 7001 Development Drive Office 3N-C1 Morrisville, NC  27560	+1 919 294 5873 beverlyfinch@lenovo.com
Lenovo.com  Twitter | Facebook | Instagram | Blogs | Forums

 

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Kurt Seifried
Sent: Thursday, May 25, 2017 9:02 PM
To: Coffin, Chris
Cc: cve-editorial-board-list
Subject: Re: CVE Current States

 

Currently we have "STATE" in the "CVE_data_meta", can I suggest we add STATE_DETAIL and STATE_DESCRIPTION, e.g.:

 

"STATE": "REJECT",

"STATE_DETAIL": "DUPLICATE_ASSIGNMENT"

"STATE_DESCRIPTION": "it all went horribly wrong"

 

So basically we'd have to agree on the tags for STATE_DETAIL and then STATE_DESCRIPTION can be free form explanation of what happened for humans.

 

 

On Thu, May 25, 2017 at 4:21 PM, Coffin, Chris <ccoffin@mitre.org> wrote:

All,

 

As discussed in the Board meeting on 5/24, here are the current CVE states along with some descriptions (some exist in the CVE FAQ). In the case of POPULATED and UNASSIGNED, I don’t think we have ever treated these as states in the past, but I think it makes sense to do so for this exercise and moving forward.

 

UNASSIGNED: A CVE that has never been ALLOCATED or RESERVED. The CVE master list provides an error message in the case that someone attempts to view this CVE ID.

Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2001-10000

 

RESERVED: A CVE Identifier (CVE ID) is marked as "RESERVED" when it has been reserved for use by a CVE Numbering Authority (CNA) or security researcher, but the details of it are not yet populated.

Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1253

 

REJECT: A CVE ID listed as "REJECT" is a CVE ID that is not accepted as a CVE ID. The reason a CVE ID is marked REJECT will most often be stated in the description of the CVE ID.

Reject reasons (not an inclusive list):

·       Duplicate assignment

·       Duplicate reservation

·       Duplicate Typo in Sequence or year

·       Mixed issues or Dual use

·       Merged (same vuln type/ versions)

·       Withdrawn by CNA (not a vuln)

·       CNA expired pool

Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784

 

DISPUTED: When one party disagrees with another party's assertion that a particular issue in software is a vulnerability, a CVE ID assigned to that issue may be designated as being "DISPUTED". In these cases, CVE is making no determination as to which party is correct. Instead, we make note of this dispute and try to offer any public references that will better inform those trying to understand the facts of the issue.

Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8912

 

POPULATED: The CVE entry has been published with at least a minimum amount of detail and at least one public reference.

Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0002

 

 

Chris Coffin

The CVE Team

 

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com