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

Re: CNA Rules Announcement

I would prefer less abstraction, it's easier to have more CVE's and cross reference them (this is related to the following CVEs: Z/X/Y) then it is to have less CVEs and try to ... explain what is in them (this CVE involved multiple vendors and blah de blah blah). 

I would also point out we can tell people "CVE is not a vuln DB" till we're blue in the face, but the  reality is a large portion of the community treats it as such, so we can try to push the sea back, or we can accept reality and work with it (so things like improving CVRF or some alternative so the CVE database has better data, or the data can be more easily discovered in an automated fashion). 

On Sun, Oct 9, 2016 at 7:29 AM, Scott Lawler <scott.lawler@lp3.com> wrote:

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

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

 




--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com
Page Last Updated or Reviewed: October 10, 2016