[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

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) 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

Attachment: INC3-5 Proposal.docx
Description: INC3-5 Proposal.docx

Page Last Updated or Reviewed: November 01, 2018