Re: CNA Rules Announcement

[Scott Lawler < scott.lawler@lp3.com >]

This level of abstraction is…well…abstract.   How do we determine what should be abstracted and to what level?

This is a slippery slope to start down.  

While I concur that some level of abstraction is good.   I think that we need to carefully define for the community what level of abstraction is appropriate.    

Honestly, I’m not quite sure how to do that.   I hate to say case-by-base but…

Ideas on how to quantify and define the right level of abstraction?

Thank you,  

Scott

703-509-9330

From: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of "Williams, Ken" <Ken.Williams@ca.com>
Date: Saturday, October 8, 2016 at 11:31 AM
To: Chandan Nandakumaraiah <cbn@juniper.net>, 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

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