RE: CNA Rules Announcement

["Williams, Ken" <Ken.Williams@ca.com>]

Solution:  Assign a master/primary/original CVE for the 
"POODLE for TLS" vulnerability, and then assign CVEs as needed 
for all affected products-vendors.  Each of these "secondary" 
POODLE CVEs should reference/"hashtag" the primary POODLE CVE 
in their description.

Regards,
Ken Williams
Vulnerability Response Director, Product Vulnerability Response Team
CA Technologies | 520 Madison Avenue, 22nd Floor, New York NY 10022


> -----Original Message-----
> From: owner-cve-cna-list@lists.mitre.org [mailto:owner-cve-cna-
> list@lists.mitre.org] On Behalf Of Chandan Nandakumaraiah
> Sent: Saturday, October 08, 2016 12:16 AM
> To: cve-cna-list <cve-cna-list@lists.mitre.org>
> Cc: cve-editorial-board-list 
> <cve-editorial-board-list@lists.mitre.org>
> Subject: Re: CNA Rules Announcement
> 
> > Moving forward sure, but retroactively trying to enforce that for an
> issue
> > that is already abstracted to some degree does not work.
> 
> Agreed. We need a statement or rule on the interaction between new
> assignments and assignments based on previous rules.
> 
> If we discover a new product with "POODLE for TLS" vulnerability:
>  (a) do we assign a new CVE id with its use limited to that product
> alone (old rule)?
>  (b) use CVE-2014-8730 (based on INC5 and Appendix E rules)?
>  (c) assign a new CVE entirely for the "POODLE for TLS" vulnerability?
> 
> > 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.
> 
> We can not solve that problem by assigning 250+ different CVEs for a
> common vulnerability. That would be like going back to pre-CVE era,
> isn't it?
> 
> What if the product-vendor being scanned had never produced an 
> advisory
> or fix for the 'POODLE for TLS' issue? Which of the many CVEs should 
> the
> scanner use to reference that unique issue?
> 
> Thanks,
> -Chandan
> --
> Security Incident Response Team
> Juniper Networks