[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'd greedily like to see "everything" (within reason) that could 
potentially be exploited
get a CVE, but I'll try to provide a more nuanced answer.

If you think it's never been exploited, and it's been patched 
everywhere, it might still
be useful to have a CVE to refer to for academic goals such as 
teaching, classifying
(ontological) and research into new security approaches and 
technologies.  It could also
be useful for historical and stats-related interests.  If it's not been 
patched everywhere
yet, and an advisory or some form of communication could be useful to 
someone, then a CVE
should be standard good practice. 

At a higher level, waiting and requiring proof of exploit before 
assigning a CVE would be
at odds with the ultimate cause that the CVE contributes towards, which 
is to prevent and
limit exploits.  It could lead to the abandonment of CVE in the 
patching process, IMO a
regression in security practices.  Waiting for exploits to happen would 
be self-defeating. 
The ideal CVE to strive towards is the one that has never been 
exploited because everybody
promptly did their due diligence ahead of attackers, and not because of 
lack of interest
from potential attackers.  

Pascal

On Thu, 2018-10-25 at 11:32 -0600, Kurt Seifried wrote:
> 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.
>
Page Last Updated or Reviewed: November 01, 2018