RE: CNA Rules Announcement

["Coffin, Chris" <ccoffin@mitre.org>]

All,

I agree completely with what Art and Kent are saying here. In my 
opinion, CVE's role should be focused on naming vulnerabilities and 
getting the conversation started. Other programs (e.g., NVD) can build 
upon the CVE entries as the needs arise.

I am impressed by the amount and level of feedback that has been 
provided through this email thread. Thanks to all who have 
participated, specifically Chandan and jericho for the many useful 
thoughts and suggestions. This is exactly the kind of feedback we were 
looking for. 

We will incorporate all of the comments into a marked up version of the 
CNA Rules document and try to post that to Github or something similar. 
We'll try to get this done before the next Board meeting.

Regards,

Chris Coffin
The CVE Team

-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of 
Landfield, Kent B
Sent: Monday, October 10, 2016 10:00 AM
To: Art Manion <amanion@cert.org>; Pascal Meunier 
<pmeunier@cerias.purdue.edu>; jericho <jericho@attrition.org>; Chandan 
Nandakumaraiah <cbn@juniper.net>
Cc: cve-cna-list <cve-cna-list@lists.mitre.org>; 
cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CNA Rules Announcement

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