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

Re: CNA Rules Announcement



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



Page Last Updated or Reviewed: October 10, 2016