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

RE: CVE Current States

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