Re: CNA Rules Announcement

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

I think that problem belongs to scanner vendors or the NVD, who should 
worry about which vendors exactly are affected, which software versions, 
and which advisories apply to which, and which to report in the scanner 
findings.  It reminds me of Steve's mantra, "the CVE is not a 
vulnerability database".  Based on that mantra and your argumentation 
being based on what a full-service vulnerability database can or should 
do ideally, I believe the CVE should not be distorted for it.  Besides, 
I bet most scanners would report *all* such CVEs if they could not 
determine the vendor, and count them as individual findings against the 
target (even if Kens suggestion of a "master" CVE was retained, which 
would make the CVE hierarchical like the CWE).

I imagine this report:  "You have 247823 vulnerabilities on your 
network!"

I am in favor of the single CVE, and avoiding anything making it 
hierarchical.

Brian thanks for copying again the cve-editorial-board-list, I never saw 
Chandan's message.

Pascal

On 10/07/2016 08:26 PM, jericho wrote:
> On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:
>
> : > For example, IBM
> : > has been using CVE-2014-8730 for their products despite the early 
> change
> : > in the entry from MITRE specifically designating it for F5 products 
> only.
> :
> : As per the new rules (CNT3), a common vulnerability in a 'protocol
> : implementation' should get a single CVE. Since this is the "same
> : specific common mistake" in the TLS protocol implementation though 
> there
> : is no problem in the protocol specification. It seems like an
> : appropriate use of the new rules to refer this vulnerability with a
> : single CVE id.
>
> Moving forward sure, but retroactively trying to enforce that for an 
> issue
> that is already abstracted to some degree does not work. The current
> abstraction and assignments that have been in place for over a year need
> to be followed.
>
> : The new rule is more in line with how consumers use CVEs to refer to
> : common vulnerabilities. When our customers ask us about "POODLE for 
> TLS"
> : they use CVE-2014-8730 to refer to this vulnerability. When
> : vulnerability scanners scan, they may find an instance of 
> CVE-2014-8730.
> : Telling customers that MITRE says that CVE-2014-8730 is limited to F5
> : products only would be confusing and may lead to wrong 
> interpretations.
>
> Not sure every scanner does that. There is a lot of value in having a
> per-vendor finding in that case, else that single finding will come 
> with a
> list of 250+ advisories that are not easily distinguished from each 
> other,
> that carry the solution. A per-vendor plugin/scan basis would allow for
> much more friendly reporting when it comes to the solution.
>
> Many people aren't aware of this because they haven't seen a VDB 
> actually
> track affected products to that degree. I can assure you that the 'mega
> entries' of VulnDB where it is a single entry for a protocol 
> vulnerability
> are unwieldy and not as user friendly as the abstracted implementation
> issues. We have entries with over 500 advisory links and well over 1,000
> products impacted. That is what many companies have been demanding for
> vulnerability management, yet most VDBs have never bothered with it.
>
> Brian