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

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

Lisa,
        I like that document, except for the requirement that "there is 
something the
customer can do, post-fix, to detect earlier exploitation."  That 
assumes you have perfect
knowledge of what a customer would or could do, but the customer can 
have a different
perspective.  For example, a customer may decide that the best action 
is to change
providers!  That option will likely not be considered as something a 
customer can do, by
the provider, one reason being the conflict of interest.

Pascal

On Wed, 2018-10-31 at 17:20 +0000, Lisa Olson wrote:
> I’ve been brainstorming with colleagues here are Microsoft.  The 
> attached document
> distills our thoughts and provides some examples.
> 
> From: Kurt Seifried <kurt@seifried.org>
> Sent: Thursday, October 25, 2018 10:32 AM
> To: cve-editorial-board-list <cve-editorial-board-list@mitre.org>
> Subject: So some blindspots that came up as a result of CVE for 
> service discussion
> 
> So we had a good CVE for services discussion today and some 
> blindspots were identified,
> the biggest one (and something the board will have to deal with) 
> being:
> 
> CVE Database - practical vs. theoretical?
> 
> So in past the CVE database has largely been for exploitable 
> vulnerabilities, although
> we don't require proof of exploitation typically most are pretty self 
> explanatory, We do
> have cases like the Linux Kernel where we, out of caution, assign a 
> lot of CVE's (http:/
> /cve.mitre.org/cgi-
> bin/cvekey.cgi?keyword=linux+kernel<https://na01.safelinks.protection.outlook.com/?url=h
> ttp%3A%2F%2Fcve.mitre.org%2Fcgi-
> bin%2Fcvekey.cgi%3Fkeyword%3Dlinux%2Bkernel&data=02%7C01%7Celolson%40microsoft.com%7C559
> 77085ef7c4896844808d63a9ffe5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367608561853
> 43092&sdata=aBr1GPrl0N6oM6yXYOxgNFAPZQQ7JxWuK%2BjBNKVEjog%3D&reserved=0>;)
>  because
> typically these flaws are found to be exploitable with enough work.
> 
> However one aspect of this is that with software we can't know if it 
> has been exploited
> or not, we don't even know in some cases who is running this stuff.
> 
> This leads us to the cloud, most cloud providers do quite a bit of 
> logging, and can in
> some cases definitely say "yes there is a vulnerability in service X, 
> but we checked all
> our logs and it was never exploited/triggered", so in this case we 
> definitely have a
> vulnerability, but we also have (as far as we know) definitive proof 
> it was never
> exploited.
> 
> So in this case, if we have proof it wasn't exploited, should it get 
> a CVE or not? I can
> see arguments going both ways, but I'd like to get the Boards take on 
> this.
> 
> --
> Kurt Seifried
> kurt@seifried.org<mailto:kurt@seifried.org>