Re: CNA Rules Announcement

["Landfield, Kent B" <kent.b.landfield@intel.com>]

Art,

You wrote: 
    In my view, the role of CVE is to identify/name vulnerabilities, and
    nothing further.  Other downstream users, like NVD, can build on 
CVE.
    Of course CVE needs to make abstraction decisions and contain enough
    information to de-duplicate entries.
    
I could not agree more.  The power of CVE is that it is simply a means 
for naming vulnerabilities. Others should build on it as their use 
cases require. 
---
Kent Landfield
+1.817.637.8026

On 10/10/16, 9:28 AM, "owner-cve-cna-list@lists.mitre.org on behalf of 
Art Manion" <owner-cve-cna-list@lists.mitre.org on behalf of 
amanion@cert.org> wrote:

    On 2016-10-10 05:32, Pascal Meunier wrote:
    
    > I agree with Brian, it makes sense to have one ID for a flaw in 
the 
    > specification of a protocol, and multiple IDs for vendor 
implementations 
    > with different code bases, even if they happen to have made 
similar 
    > mistakes.  I think Kurt's suggestion to cross-reference them 
"(this is 
    > related to the following CVEs: Z/X/Y)" would be helpful although 
not 
    > necessary.
    
    Noting the disagreement about level of abstraction, I suspect that
    beyond individual opinion, different vulnerability 
analysis/management
    use cases prefer different abstractions.  VRDX-SIG at FIRST has a
    proposed answer for this, which is basically a protocol (working 
title:
    vxref) for relationships between vulnerability IDs.
    
    
https://www.first.org/resources/papers/conf2015/first_2015_-_manion-_uchiyama-_terada_-_vrdx-sig_20150619.pdf
    
    So one could say CVE-X is a subset of CVE-Y.  Or similar to.  If 
VDBs
    were to use the protocol, a user could construct a graph of IDs.  
vxref
    isn't limited to CVE IDs.
    
    In a world of, at the very minimum, 14K publicly disclosed
    vulnerabilities per year, a way to deal with different abstractions
    within or across VDBs is more than helpful, it's essential, unless 
one
    VDB is going to cover the entire world's uses.
    
    In my view, the role of CVE is to identify/name vulnerabilities, and
    nothing further.  Other downstream users, like NVD, can build on 
CVE.
    Of course CVE needs to make abstraction decisions and contain enough
    information to de-duplicate entries.
    
     - Art