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

Re: CNA Rules Announcement

I got a reply "Rejected posting to CVE-CNA-LIST@LISTS.MITRE.ORG". I imagine Chandan got his message rejected by the cve-editorial-board-list? This is awkward.


On 10/08/2016 04:26 PM, Pascal Meunier wrote:
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 

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

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


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
: > 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
: 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 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
: 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 1,000
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