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

Or part of the attack is that the attacker could delete or alter the log files (e.g. a flaw in CloudTrail on AWS for example puts us into that catch-22). 

On Wed, Oct 31, 2018 at 12:20 PM Pascal Meunier <pmeunier@cerias.purdue.edu> wrote:

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="">
> ttp%3A%2F%2Fcve.mitre.org%2Fcgi-
> bin%2Fcvekey.cgi%3Fkeyword%3Dlinux%2Bkernel&data="" href="http://40microsoft.com" rel="noreferrer" target="_blank">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>

--

Kurt Seifried
kurt@seifried.org