CVE Current States

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

CVE Current States

Coffin, Chris

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

Reply | Threaded
Open this post in threaded view
|

Re: CVE Current States

Kurt Seifried
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 <[hidden email]> 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: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CVE Current States

Beverly Finch

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

 

 

 

Regards,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CVE Current States

Coffin, Chris

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:[hidden email]]
Sent: Thursday, May 25, 2017 8:49 PM
To: Kurt Seifried <[hidden email]>; Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: RE: CVE Current States

 

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

 

 

 

Regards,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: [hidden email] [[hidden email]] 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 <[hidden email]> 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: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CVE Current States

Beverly Finch

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,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: Coffin, Chris [mailto:[hidden email]]
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 [[hidden email]]
Sent: Thursday, May 25, 2017 8:49 PM
To: Kurt Seifried <[hidden email]>; Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: RE: CVE Current States

 

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

 

 

 

Regards,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: [hidden email] [[hidden email]] 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 <[hidden email]> 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: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CVE Current States

Coffin, Chris

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:[hidden email]]
Sent: Friday, May 26, 2017 9:00 AM
To: Coffin, Chris <[hidden email]>; Kurt Seifried <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
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,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: Coffin, Chris [[hidden email]]
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 [[hidden email]]
Sent: Thursday, May 25, 2017 8:49 PM
To: Kurt Seifried <[hidden email]>; Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: RE: CVE Current States

 

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

 

 

 

Regards,

 

http://lenovocentral.lenovo.com/marketing/branding/email_signature/images/gradient.gif

Beverly M Finch, PMP
PSIRT Program Manager

Product Security Office

7001 Development Drive

Office 3N-C1

Morrisville, NC  27560

Phone+1 919 294 5873
[hidden email]

Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums

DifferentBetter-Pink

 

 

From: [hidden email] [[hidden email]] 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 <[hidden email]> 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: 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CVE Current States

Kurt Seifried
In reply to this post by Beverly Finch
On 05/26/2017 07:59 AM, Beverly Finch wrote:

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

One concern there is defining behavior. E.g.:

REJECT: something went wrong, don't use this.
RESERVED: this is planned for use, you will see it at some future point
(either PUBLIC or REJECTED)
PUBLIC: this is used and here's the info.

I can't think of an "Other" situation (either we're planning to use the
CVE, using it, or explicitly not using it). My thought is if we really
truly run into a situation that isn't covered we need to define it
officially, I don't want data that is not defined and requires human
interaction ideally.



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CVE Current States

Coffin, Chris
Here is what I think we are driving to in this thread. We can discuss more on the call today if needed.

Format (Note that not all STATEs will need STATE_DETAIL or STATE_DESCRIPTION):
"STATE": "<state_name>",
"STATE_DETAIL": "<sub-state_name>" // e.g., duplicate assignment, merged, etc.
"STATE_DESCRIPTION": "<prose_desc>" // could be almost anything, but would be needed for REJECT explanations e.g., a reference to the new CVE, etc.

Example:
"STATE": "REJECT",
"STATE_DETAIL": "DUPLICATE_ASSIGNMENT"
"STATE_DESCRIPTION": "it all went horribly wrong"

STATE:UNASSIGNED: A CVE that has never been 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
STATE_DETAIL:N/A (I don't believe it would ever be needed)

STATE: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
STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a CNA
STATE_DETAIL:ASSIGNED - assigned to a vulnerability

STATE: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.
Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
STATE_DETAIL:DUPLICATE_ASSIGNMENT
STATE_DETAIL:DUPLICATE_RESERVATION
STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
STATE_DETAIL:MERGED
STATE_DETAIL:WITHDRAWN
STATE_DETAIL:EXPIRED
STATE_DESCRIPTION: // probably the only STATE where this is required

STATE: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
STATE_DETAIL:N/A (I don't believe it would ever be needed)

STATE: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
STATE_DETAIL:N/A (I don't believe it would ever be needed)

Chris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, May 26, 2017 11:33 AM
To: Beverly Finch <[hidden email]>; Coffin, Chris <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: CVE Current States



On 05/26/2017 07:59 AM, Beverly Finch wrote:

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

One concern there is defining behavior. E.g.:

REJECT: something went wrong, don't use this.
RESERVED: this is planned for use, you will see it at some future point (either PUBLIC or REJECTED)
PUBLIC: this is used and here's the info.

I can't think of an "Other" situation (either we're planning to use the CVE, using it, or explicitly not using it). My thought is if we really truly run into a situation that isn't covered we need to define it officially, I don't want data that is not defined and requires human interaction ideally.



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CVE Current States

Art Manion
On 2017-06-14 10:25, Coffin, Chris wrote:
> Here is what I think we are driving to in this thread. We can discuss more on the call today if needed.

I won't make the call today, here's some input.

1. When we're ready, publicly document states, including a state transition diagram.  A colleague of mine started one but it's not quite ready to share.

> STATE:UNASSIGNED: A CVE that has never been 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
> STATE_DETAIL:N/A (I don't believe it would ever be needed)

This is the default state, correct?  This state should never appear in a CVE data record?

> STATE: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
> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a CNA
> STATE_DETAIL:ASSIGNED - assigned to a vulnerability

Are these finite state details?  If reserved, must also be cna_allocated or assigned, state detail can't be empty?

> STATE: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.
> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
> STATE_DETAIL:DUPLICATE_ASSIGNMENT
> STATE_DETAIL:DUPLICATE_RESERVATION
> STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
> STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
> STATE_DETAIL:MERGED
> STATE_DETAIL:WITHDRAWN
> STATE_DETAIL:EXPIRED
> STATE_DESCRIPTION: // probably the only STATE where this is required

Again, is state detail required?

If duplicate or merged, must description note the other IDs involved?

> STATE: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
> STATE_DETAIL:N/A (I don't believe it would ever be needed)

There is currently a PUBLIC state I think.  Is populated replacing public?

Regards,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE Current States

Landfield, Kent
Sadly I too will not make the call today.

Kent Landfield
[hidden email]
+1.817.637.8026

> On Jun 14, 2017, at 12:17 PM, Art Manion <[hidden email]> wrote:
>
>> On 2017-06-14 10:25, Coffin, Chris wrote:
>> Here is what I think we are driving to in this thread. We can discuss more on the call today if needed.
>
> I won't make the call today, here's some input.
>
> 1. When we're ready, publicly document states, including a state transition diagram.  A colleague of mine started one but it's not quite ready to share.
>
>> STATE:UNASSIGNED: A CVE that has never been 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
>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>
> This is the default state, correct?  This state should never appear in a CVE data record?
>
>> STATE: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
>> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a CNA
>> STATE_DETAIL:ASSIGNED - assigned to a vulnerability
>
> Are these finite state details?  If reserved, must also be cna_allocated or assigned, state detail can't be empty?
>
>> STATE: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.
>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
>> STATE_DETAIL:DUPLICATE_ASSIGNMENT
>> STATE_DETAIL:DUPLICATE_RESERVATION
>> STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
>> STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
>> STATE_DETAIL:MERGED
>> STATE_DETAIL:WITHDRAWN
>> STATE_DETAIL:EXPIRED
>> STATE_DESCRIPTION: // probably the only STATE where this is required
>
> Again, is state detail required?
>
> If duplicate or merged, must description note the other IDs involved?
>
>> STATE: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
>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>
> There is currently a PUBLIC state I think.  Is populated replacing public?
>
> Regards,
>
> - Art
Reply | Threaded
Open this post in threaded view
|

RE: CVE Current States

Coffin, Chris
In reply to this post by Art Manion
> 1. When we're ready, publicly document states, including a state transition diagram.  A colleague of mine started one but it's not quite ready to share.
Great idea, and please share when ready. This also very much applies to the other email in regards to how the REJECT state is used.

>> STATE:UNASSIGNED: A CVE that has never been RESERVED. The CVE master list provides an error message in the case that someone >>attempts to view this CVE ID.
> This is the default state, correct?  This state should never appear in a CVE data record?
It would never appear in a record that is used, but my feeling was that we should give it a name. As well, there may be an unseen use for it in the future.

>> STATE: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
>> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a
>> CNA STATE_DETAIL:ASSIGNED - assigned to a vulnerability
> Are these finite state details?  If reserved, must also be cna_allocated or assigned, state detail can't be empty?
My current opinion is that the state detail would be required, though it raises the question of what happens when something doesn't fit. Should we always have an "Other" state detail? Same for the following comment. In regards to the state description being required, my current thought would be no since it would be difficult to enforce the prose around it. Open to thoughts on this for sure.

>> STATE: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
>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>There is currently a PUBLIC state I think.  Is populated replacing public?
I don't believe that we have used terms for this or the previous UNASSIGNED. However, I believe there used to be a CVE status that included public way back in the day (2004 being that last occurrence I think). We should be fine using PUBLIC if that is what others feel has been used and is more appropriate.


Chris


-----Original Message-----
From: Art Manion [mailto:[hidden email]]
Sent: Wednesday, June 14, 2017 11:09 AM
To: Coffin, Chris <[hidden email]>; [hidden email]; Beverly Finch <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: CVE Current States

On 2017-06-14 10:25, Coffin, Chris wrote:
> Here is what I think we are driving to in this thread. We can discuss more on the call today if needed.

I won't make the call today, here's some input.

1. When we're ready, publicly document states, including a state transition diagram.  A colleague of mine started one but it's not quite ready to share.

> STATE:UNASSIGNED: A CVE that has never been 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
> STATE_DETAIL:N/A (I don't believe it would ever be needed)

This is the default state, correct?  This state should never appear in a CVE data record?

> STATE: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
> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a
> CNA STATE_DETAIL:ASSIGNED - assigned to a vulnerability

Are these finite state details?  If reserved, must also be cna_allocated or assigned, state detail can't be empty?

> STATE: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.
> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
> STATE_DETAIL:DUPLICATE_ASSIGNMENT
> STATE_DETAIL:DUPLICATE_RESERVATION
> STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
> STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
> STATE_DETAIL:MERGED
> STATE_DETAIL:WITHDRAWN
> STATE_DETAIL:EXPIRED
> STATE_DESCRIPTION: // probably the only STATE where this is required

Again, is state detail required?

If duplicate or merged, must description note the other IDs involved?

> STATE: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
> STATE_DETAIL:N/A (I don't believe it would ever be needed)

There is currently a PUBLIC state I think.  Is populated replacing public?

Regards,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE Current States

Art Manion
On 2017-06-14 12:36, Coffin, Chris wrote:
>>> STATE: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
>>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>> There is currently a PUBLIC state I think.  Is populated replacing public?

> I don't believe that we have used terms for this or the previous
> UNASSIGNED. However, I believe there used to be a CVE status that
> included public way back in the day (2004 being that last occurrence
> I think). We should be fine using PUBLIC if that is what others feel
> has been used and is more appropriate.
I think I saw STATE : PUBLIC in the MITRE CoDev git repo, but can't check right now.

I don't feel strongly about PUBLIC vs. POPULATED, but agree there should be a state to indicate a correct (syntactically and to the best of current knowledge materially) and published entry.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE Current States

Kurt Seifried
In reply to this post by Landfield, Kent
Ditto.

On 06/14/2017 10:19 AM, Landfield, Kent wrote:

> Sadly I too will not make the call today.
>
> Kent Landfield
> [hidden email]
> +1.817.637.8026
>
>> On Jun 14, 2017, at 12:17 PM, Art Manion <[hidden email]> wrote:
>>
>>> On 2017-06-14 10:25, Coffin, Chris wrote:
>>> Here is what I think we are driving to in this thread. We can discuss more on the call today if needed.
>>
>> I won't make the call today, here's some input.
>>
>> 1. When we're ready, publicly document states, including a state transition diagram.  A colleague of mine started one but it's not quite ready to share.
>>
>>> STATE:UNASSIGNED: A CVE that has never been 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
>>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>>
>> This is the default state, correct?  This state should never appear in a CVE data record?

Agreed.

>>
>>> STATE: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
>>> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a CNA
>>> STATE_DETAIL:ASSIGNED - assigned to a vulnerability
>>
>> Are these finite state details?  If reserved, must also be cna_allocated or assigned, state detail can't be empty?

I think so, unless there are other RESERVED states (I can't think of any
though).

>>
>>> STATE: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.
>>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
>>> STATE_DETAIL:DUPLICATE_ASSIGNMENT
>>> STATE_DETAIL:DUPLICATE_RESERVATION
>>> STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
>>> STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
>>> STATE_DETAIL:MERGED
>>> STATE_DETAIL:WITHDRAWN
>>> STATE_DETAIL:EXPIRED
>>> STATE_DESCRIPTION: // probably the only STATE where this is required
>>
>> Again, is state detail required?

I think we should require this, otherwise "it's broken. can't tell you
why or how. Maybe there's another CVE related to this (duplicate) or
maybe not."

>>
>> If duplicate or merged, must description note the other IDs involved?

I'm going to say yes, as you must submit that data to MITRE anyways
currently AFAIK.

>>
>>> STATE: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
>>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>>
>> There is currently a PUBLIC state I think.  Is populated replacing public?

I think perhaps this is to distinguish between "PUBLIC" being someone
published it somewhere, and it showing up in the CVE database?

>> Regards,
>>
>> - Art

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]