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

[Art Manion <amanion@cert.org>]

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.

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.

 - Art