Re: CNA Rules Announcement

[Art Manion <amanion@cert.org>]

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