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