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

Re: So some blindspots that came up as a result of CVE for service discussion



On Tue, Dec 11, 2018 at 5:36 PM Art Manion <amanion@cert.org> wrote:
On 10/31/18 1:20 PM, Lisa Olson wrote:
> I’ve been brainstorming with colleagues here are Microsoft.  The attached document distills our thoughts and provides some examples.

I'm generally in favor of at least allowing CVEs to be issues for service vulnerabilities.  My stance is:

CVE is about vulnerability identification (naming, enumeration) -- everything else is extra.

I'm OK with a fairly loose definition of "vulnerability" and basically no restrictions on product, service, IoT, safety critical thing -- any software system is in scope.

If it's close enough to being a vulnerability and more than two people want to talk about it, an ID is a good idea.  Remember that other Facebook vulnerability, no not the one Kurt was talking about, the second of the three used in the big compromise?

OTOH, I'm not immediately OK with assigning a CVE to a cloud breach.  While I'll accept a loose definition of vulnerability, having no evidence of a vulnerability is, well, not enough to assign a CVE.  We rarely know the root causes of most large/public breaches.

What if we have evidence of a breach indicating that something bad Vulnerability/Exposure wise happened? E.g. https://haveibeenpwned.com/ or the vendor says "something bad happened so we're shutting down 4 months Google+ early" (https://www.google.ca/search?q=google%2B+shutdown+4+months+early). 
 

I'm OK with users/customers needing to take action, users/customers being able to do better forensic/incident investigations, and even "someone wanted to assign a CVE for a service vulnerability and followed the CVE practices correctly."

There was some discussion about a "service" flag, which I'm OK with, but it does open the door to classifying vulnerabilities, which gets messy very quickly.

So I think what we need here is:

1) a Production/Experimental flag.

2) a best effort tagging set of flags, e.g. "software", "service", other options??? (some will be all of the above, as mentioned Red Hat OpenShift is classical on premises software, openshift.com the service, and used by other providers on their premises to provide services both internally and externally.

In line with #2 would be the dependency chain stuff, e.g. OpenSSL (in theory every OpenSSL CVE should be the size of a phone book just to list all the TV's and cloud services using it). 
 

  - Art


--
Kurt Seifried
kurt@seifried.org
Page Last Updated or Reviewed: December 17, 2018