Re: CNA Rules Announcement

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

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.

Pascal

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 
> 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