[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CNA Rules Announcement

On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:

: > For example, IBM 
: > has been using CVE-2014-8730 for their products despite the early 
: > in the entry from MITRE specifically designating it for F5 products 
: 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 
: 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 
that is already abstracted to some degree does not work. The current 
abstraction and assignments that have been in place for over a year 
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 
: they use CVE-2014-8730 to refer to this vulnerability. When 
: vulnerability scanners scan, they may find an instance of 
: Telling customers that MITRE says that CVE-2014-8730 is limited to F5 
: products only would be confusing and may lead to wrong 

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 
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 
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 
are unwieldy and not as user friendly as the abstracted implementation 
issues. We have entries with over 500 advisory links and well over 
products impacted. That is what many companies have been demanding for 
vulnerability management, yet most VDBs have never bothered with it.


Page Last Updated or Reviewed: October 10, 2016