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

RE: CVE Current States

> 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:amanion@cert.org] 
Sent: Wednesday, June 14, 2017 11:09 AM
To: Coffin, Chris <ccoffin@mitre.org>; kseifried@redhat.com; Beverly 
Finch <beverlyfinch@lenovo.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
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
Page Last Updated or Reviewed: June 14, 2017