Current and future CVE states

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

Current and future CVE states

Kurt Seifried-2

So we currently have several defined CVE States, some of which are overloaded (e.g. REJECT), we also need some new states potentially. We also need to define the JSON format for these states (e.g. for REJECT not a vuln we can't have an impact type), so once we define which states we want, then we can define the JSON format(s). First I'd like to confirm that we have a list of all the common states we need, so:


PUBLIC - currently covered by the minimum JSON format


REJECT - currently not covered by JSON format, needs specific sub states?


CVE-2017-7319,Candidate,"** REJECT **  DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: none.  Reason: This candidate was withdrawn by its CNA.  Further investigation showed that it was not a security issue.  Notes: none.","",Assigned (20170329),"None (candidate not yet proposed)"


CVE-2017-7469,Candidate,"** REJECT **  DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-2017-7466.  Reason:  This candidate is a reservation duplicate of CVE-2017-7466.  Notes: All CVE users should reference CVE-2017-7466 instead of this candidate.  All references and descriptions in this candidate have been removed to prevent accidental usage.","",Assigned (20170405),"None (candidate not yet proposed)"


DWF had these states for REJECT’ed CVEs:

  • DUPLICATE_OF [CVE]

  • SPLIT_TO [list of CVEs]

  • MERGED_TO [lCVE]

  • REJECT (classic, e.g. not a vuln)


RESERVED - currently not covered by JSON format, needs specific sub states?


CVE-2017-8761,Candidate,"** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided.","",Assigned (20170503),"None (candidate not yet proposed)"


We would generally want to split:

  • RESERVED as part of CNA block, not used yet (do we want to actually list this uniquely?)

  • RESERVED as an actual CVE assignment that will become public (most useful for MITRE “Retail” assignments?)

  • Other RESERVED states?


--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Current and future CVE states

Art Manion
On 2017-05-03 15:36, Kurt Seifried wrote:

> DUPLICATE_OF [CVE]
>
> SPLIT_TO [list of CVEs]
>
> MERGED_TO [lCVE]

If we're going to get into relationships between vulnerabilities --
which is related to, but possibly a bit beyond state -- I'd like to
brief the board (or automation group) on vxref, which is a structured
relationship system.

https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/tree/master/vxref

https://github.com/CERTCC-Vulnerability-Analysis/Vulnerability-Data-Archive-Tools

Regards,

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

Re: Current and future CVE states

Landfield, Kent
Yes, Yes, and Yes....  vxref is what we should be using.

--
Kent Landfield
817-637-8026
[hidden email]

On 5/3/17, 5:12 PM, "[hidden email] on behalf of Art Manion" <[hidden email] on behalf of [hidden email]> wrote:

    On 2017-05-03 15:36, Kurt Seifried wrote:
   
    > DUPLICATE_OF [CVE]
    >
    > SPLIT_TO [list of CVEs]
    >
    > MERGED_TO [lCVE]
   
    If we're going to get into relationships between vulnerabilities --
    which is related to, but possibly a bit beyond state -- I'd like to
    brief the board (or automation group) on vxref, which is a structured
    relationship system.
   
    https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/tree/master/vxref
   
    https://github.com/CERTCC-Vulnerability-Analysis/Vulnerability-Data-Archive-Tools
   
    Regards,
   
     - Art
   

Reply | Threaded
Open this post in threaded view
|

Re: Current and future CVE states

Kurt Seifried
I agree in principle but I needed something basic now, and merged to/duplicate of/split from covers, well, basically every case I've seen in several thousand CVEs.

On Wed, May 3, 2017 at 4:20 PM, Landfield, Kent <[hidden email]> wrote:
Yes, Yes, and Yes....  vxref is what we should be using.

--
Kent Landfield
<a href="tel:817-637-8026" value="+18176378026">817-637-8026
[hidden email]

On 5/3/17, 5:12 PM, "[hidden email] on behalf of Art Manion" <[hidden email] on behalf of [hidden email]> wrote:

    On 2017-05-03 15:36, Kurt Seifried wrote:

    > DUPLICATE_OF [CVE]
    >
    > SPLIT_TO [list of CVEs]
    >
    > MERGED_TO [lCVE]

    If we're going to get into relationships between vulnerabilities --
    which is related to, but possibly a bit beyond state -- I'd like to
    brief the board (or automation group) on vxref, which is a structured
    relationship system.

    https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/tree/master/vxref

    https://github.com/CERTCC-Vulnerability-Analysis/Vulnerability-Data-Archive-Tools

    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]
Reply | Threaded
Open this post in threaded view
|

Re: Current and future CVE states

Art Manion
In reply to this post by Kurt Seifried-2
On 5/3/17 3:36 PM, Kurt Seifried wrote:

> PUBLIC - currently covered by the minimum JSON format

Published by the appropriate CNA(s), fully public, known to the
master/MITRE list.  Implies RESERVED and ASSIGNED.

> REJECT - currently not covered by JSON format, needs specific sub states?

Was ASSIGNED (and RESERVED) but has now been REJECTed.

> Reason: This candidate was withdrawn by its CNA.

WITHDRAWN?

> Reason:  This candidate is a reservation duplicate of CVE-2017-7466.
> Notes: All CVE users should reference CVE-2017-7466 instead of this
> candidate.

> DWF had these states for REJECT’ed CVEs:

>     DUPLICATE_OF [CVE]
>     SPLIT_TO [list of CVEs]
>     MERGED_TO [lCVE]
>     REJECT (classic, e.g. not a vuln)

REJECT:NOTAVULN?

These all seem useful.

> RESERVED - currently not covered by JSON format, needs specific sub states?
>
>     RESERVED as part of CNA block, not used yet (do we want to actually
>     list this uniquely?)
>
>     RESERVED as an actual CVE assignment that will become public (most
>     useful for MITRE “Retail” assignments?)

ASSIGNED: Assigned by a CNA to a vulnerability, but not public yet,
likely under embargo.  ASSIGNED implies RESERVED.

RESERVED: Reserved by a CNA for future assignment, but not ASSIGNED, and
not in the UNASSIGNED pool.

UNASSIGNED: Default state?  In the pool of infinite available IDs but
not in any other state?  Needed at all?

 - Art