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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Kurt Seifried-2
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Pascal Meunier
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.
>
Reply | Threaded
Open this post in threaded view
|

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

Pascal Meunier
In reply to this post by Kurt Seifried-2
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 <[hidden email]>
> Sent: Thursday, October 25, 2018 10:32 AM
> To: cve-editorial-board-list <[hidden email]>
> 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
> [hidden email]<mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Kurt Seifried-2
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 <[hidden email]> 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 <[hidden email]>
> Sent: Thursday, October 25, 2018 10:32 AM
> To: cve-editorial-board-list <[hidden email]>
> 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
> [hidden email]<mailto:[hidden email]>


--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Kurt Seifried-2
Another good example, a facebook issue:


TL;DR: you could add yourself as an admin to a business and hijack it. Probably good for people to review these for the vuln time period and I bet facebook could notify every company that had an admin added while the vuln was present. Having a CVE here would be a good example of adding awareness, e.g. a sample CVE description:

The Facebook /business/aymc_assets/admins/import/ API endpoint was vulnerable to a lack of authentication vulnerability allowing attackers to add themselves as an admin to any business on Facebook. The API was vulnerable from $DATE1 to $DATE2, all businesses are encouraged to check and verify their admin list (URL or instructions here) for potential malicious accounts. 

Also it seems like we might want to revisit allowing URL's in the description if it links to "how to fix this" kind of stuff. 





On Wed, Oct 31, 2018 at 12:48 PM Kurt Seifried <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>
> Sent: Thursday, October 25, 2018 10:32 AM
> To: cve-editorial-board-list <[hidden email]>
> 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
> [hidden email]<mailto:[hidden email]>


--
Kurt Seifried
[hidden email]


--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Art Manion
In reply to this post by Kurt Seifried-2
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
Reply | Threaded
Open this post in threaded view
|

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

Kurt Seifried-2


On Tue, Dec 11, 2018 at 5:36 PM Art Manion <[hidden email]> wrote:
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.

What if we have evidence of a breach indicating that something bad Vulnerability/Exposure wise happened? E.g. https://haveibeenpwned.com/ or the vendor says "something bad happened so we're shutting down 4 months Google+ early" (https://www.google.ca/search?q=google%2B+shutdown+4+months+early). 
 

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.

So I think what we need here is:

1) a Production/Experimental flag.

2) a best effort tagging set of flags, e.g. "software", "service", other options??? (some will be all of the above, as mentioned Red Hat OpenShift is classical on premises software, openshift.com the service, and used by other providers on their premises to provide services both internally and externally.

In line with #2 would be the dependency chain stuff, e.g. OpenSSL (in theory every OpenSSL CVE should be the size of a phone book just to list all the TV's and cloud services using it). 
 

  - Art


--
Kurt Seifried
[hidden email]