Re: CNA Rules Announcement

[jericho <jericho@attrition.org>]

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