CVE for hosted services

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

CVE for hosted services

Andy Balinsky (balinsky)
I was having some internal discussions with our Incident Response team (PSIRT) at Cisco, and the issue came up of whether there are either any industry best practices, or Mitre policies regarding CVEs for hosted services. 

The situation is where a software service is hosted by a vendor on servers owned by the vendor. A vulnerability is discovered internally by the vendor. It is fixed. No action is required by the customer. She just starts using the fixed version next time she visits that webpage. 
So, should the vendor issue an advisory about it? And should a CVE be generated?

What are other vendors doing in this case? (Maybe this list isn't the best place to be discussing this).

Andy Balinsky
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

jericho
FYI, this was asked to clarify policy in December. MITRE's official
response:


From: "Evans, Jonathan L." <[hidden email]>
X-Originating-IP: [192.160.51.89]
To: jericho <[hidden email]>, cve-cna-list
<[hidden email]>
Date: Thu, 15 Dec 2016 14:10:17 +0000
Subject: RE: site-specific vulnerabilities and CVE inclusion

> First, can MITRE chime in and verify this is still current policy
regarding site-specific issues?

It is still against the rules to assign a CVE ID to a site-specific
vulnerability.  INC3 in the CNA Rules says "Is the vulnerability
site-specific?... Yes: Do not assign a CVE ID."[1]

We are not opposed to assigning CVE IDs to site-specific vulnerabilities.  
When we finalized the CNA rules, we believed that we did not understand
the use cases for site-specific vulnerabilities well
enough to write rules on how to properly count them.  We fully expect
support for site-specific vulnerabilities to be a major topic of the next
revision of the rules.

[1] http://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf

--
Jonathan Evans
Lead CVE Content Analyst
The MITRE Corporation


On Wed, 15 Feb 2017, Andy Balinsky (balinsky) wrote:

: I was having some internal discussions with our Incident Response team (PSIRT) at Cisco, and the issue came up of whether there are either any industry best practices, or Mitre policies regarding CVEs for hosted services.
:
: The situation is where a software service is hosted by a vendor on servers owned by the vendor. A vulnerability is discovered internally by the vendor. It is fixed. No action is required by the customer. She just starts using the fixed version next time she visits that webpage.
: So, should the vendor issue an advisory about it? And should a CVE be generated?
:
: What are other vendors doing in this case? (Maybe this list isn't the best place to be discussing this).
:
: Andy Balinsky
: [hidden email]<mailto:[hidden email]>
:
: [cid:[hidden email]]
:
:
Reply | Threaded
Open this post in threaded view
|

RE: CVE for hosted services

Mike Prosser
In reply to this post by Andy Balinsky (balinsky)

Hi Andy

 

Probably not the best place to get into a deep discussion, but there is a current INC rule 3 on the MITRE page

http://cveproject.github.io/docs/cna/application-guidance.html

Is the issue site-specific? Is it only in an online service (software-as-a-service), on a specific web site, or only offered through hosting solutions that are under the full control of the vendor?

 

So current answer is no, but agree that with the rise of hosted service since this rule was set, likely needs to be visited again

 

regards

-Mike Prosser

Symantec Software Security Group

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Andy Balinsky (balinsky)
Sent: Wednesday, February 15, 2017 1:17 PM
To: cve-editorial-board-list <[hidden email]>
Subject: CVE for hosted services

 

I was having some internal discussions with our Incident Response team (PSIRT) at Cisco, and the issue came up of whether there are either any industry best practices, or Mitre policies regarding CVEs for hosted services. 

 

The situation is where a software service is hosted by a vendor on servers owned by the vendor. A vulnerability is discovered internally by the vendor. It is fixed. No action is required by the customer. She just starts using the fixed version next time she visits that webpage. 

So, should the vendor issue an advisory about it? And should a CVE be generated?

 

What are other vendors doing in this case? (Maybe this list isn't the best place to be discussing this).

 

Andy Balinsky

Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Landfield, Kent B
In reply to this post by Andy Balinsky (balinsky)

This has been discussed in the past and the feeling was this was not something that would need a CVE as there is no need to identify the vulnerability outside the organization. Most host providers quickly correct those types of situations and it is generally not an external concern. 

 

That said..., if the vulnerability is in commonly used software supplying a portion of a hosted service that other providers are using as well, it would make sense to assure the vulnerability was processed appropriately.

 

The question you have to ask yourself is, does this discovered vulnerability potentially affect other companies and hosted services outside your organization? If so, a CVE is probably needed.  If it is homegrown software that no one else runs or a local configuration issue, then probably not...

 

---

Kent Landfield

+1.817.637.8026

 

From: <[hidden email]> on behalf of "Andy Balinsky (balinsky)" <[hidden email]>
Date: Wednesday, February 15, 2017 at 11:17 AM
To: cve-editorial-board-list <[hidden email]>
Subject: CVE for hosted services

 

I was having some internal discussions with our Incident Response team (PSIRT) at Cisco, and the issue came up of whether there are either any industry best practices, or Mitre policies regarding CVEs for hosted services. 

 

The situation is where a software service is hosted by a vendor on servers owned by the vendor. A vulnerability is discovered internally by the vendor. It is fixed. No action is required by the customer. She just starts using the fixed version next time she visits that webpage. 

So, should the vendor issue an advisory about it? And should a CVE be generated?

 

What are other vendors doing in this case? (Maybe this list isn't the best place to be discussing this).

 

Andy Balinsky

Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Andy Balinsky (balinsky)
That rule probably covers it. Thanks, Jericho and Mike, too. I had forgotten to consult that document. 

I don't think it would affect Cisco's decision whether to announce a vulnerability or not. It would just be a decision of whether to issue and attach a CVE to that announcement. 

I guess it gets back to the purpose of a CVE. If the primary purpose is to serve vulnerability scanners, a scanner would never detect a site-specific vulnerability, if it was patched before being announced. If it were reported to the vendor, and then took a while to be patched, then it could be something a scanner might want to warn about. Though directing a scanner at someone else's SaaS offering would be unlikely. 

I think the main benefit would be to unify discussions about an issue. If a SaaS vulnerability were disclosed and then academic or online discussions wanted to refer to the vulnerability with specificity to disambiguate from some similar vulnerability. That, I suppose is the only aspect left to debate. I don't know if it is a compelling case or not.

Thanks,
Andy

On Feb 15, 2017, at 1:36 PM, Landfield, Kent B <[hidden email]> wrote:

This has been discussed in the past and the feeling was this was not something that would need a CVE as there is no need to identify the vulnerability outside the organization. Most host providers quickly correct those types of situations and it is generally not an external concern. 
 
That said..., if the vulnerability is in commonly used software supplying a portion of a hosted service that other providers are using as well, it would make sense to assure the vulnerability was processed appropriately.
 
The question you have to ask yourself is, does this discovered vulnerability potentially affect other companies and hosted services outside your organization? If so, a CVE is probably needed.  If it is homegrown software that no one else runs or a local configuration issue, then probably not...
 
---
Kent Landfield
+1.817.637.8026
 
From: <[hidden email]> on behalf of "Andy Balinsky (balinsky)" <[hidden email]>
Date: Wednesday, February 15, 2017 at 11:17 AM
To: cve-editorial-board-list <[hidden email]>
Subject: CVE for hosted services
 
I was having some internal discussions with our Incident Response team (PSIRT) at Cisco, and the issue came up of whether there are either any industry best practices, or Mitre policies regarding CVEs for hosted services. 
 
The situation is where a software service is hosted by a vendor on servers owned by the vendor. A vulnerability is discovered internally by the vendor. It is fixed. No action is required by the customer. She just starts using the fixed version next time she visits that webpage. 
So, should the vendor issue an advisory about it? And should a CVE be generated?
 
What are other vendors doing in this case? (Maybe this list isn't the best place to be discussing this).
 
Andy Balinsky

<image001.jpg>
 

Andy Balinsky


Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Art Manion
On 2017-02-15 15:00, Andy Balinsky (balinsky) wrote:

> I think the main benefit would be to unify discussions about an issue.
> If a SaaS vulnerability were disclosed and then academic or online
> discussions wanted to refer to the vulnerability with specificity to
> disambiguate from some similar vulnerability. That, I suppose is the
> only aspect left to debate. I don't know if it is a compelling case or not.

As many on this list know, I'm in favor of any vulnerability being able
to get a CVE ID.  Vulnerabilities are abstract things, we need to
identify them to be able to talk about them, full stop.  Yes, with SaaS,
there is usually no action needed by users or vulnerability scanners.

As a CNA, CERT/CC follows INC 3.

Regards,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Kurt Seifried
Just a note:

1) Internal software (either used internally or presented as a service) sometimes get released publicly, having vulns tracked via CVE would make the entire life cycle much easier to manage when things go public.

2) The world has already moved to a services model, most apps aren't that useful without some online service/API, so there is definitely value in knowing what services I use are vulnerable. 

3) There is also a strong push for security transparency (e.g. the CloudSecurityAlliance has several hundred STARS CAIQ entries in the registry and I know that most cloud services has one as many large companies/governments now require such an entry prior to purchasing the service), so this is something the industry will be doing, ideally CVE should be a part of that.

On Thu, Feb 16, 2017 at 6:08 AM, Art Manion <[hidden email]> wrote:
On 2017-02-15 15:00, Andy Balinsky (balinsky) wrote:

> I think the main benefit would be to unify discussions about an issue.
> If a SaaS vulnerability were disclosed and then academic or online
> discussions wanted to refer to the vulnerability with specificity to
> disambiguate from some similar vulnerability. That, I suppose is the
> only aspect left to debate. I don't know if it is a compelling case or not.

As many on this list know, I'm in favor of any vulnerability being able
to get a CVE ID.  Vulnerabilities are abstract things, we need to
identify them to be able to talk about them, full stop.  Yes, with SaaS,
there is usually no action needed by users or vulnerability scanners.

As a CNA, CERT/CC follows INC 3.

Regards,

 - Art



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Art Manion
Some thoughts based on today's board meeting.

I consider CVE's primary purpose as identification.  There's a good bit
of work that goes into just doing identification.  Information
sharing/publishing/cataloging takes work too.  Identification/naming is
infrastructural and enables many additional functions.

"Vulnerability" is often abstract and subjective.

Software and tech change quickly.  The definition/boundary of what "we"
"collectively" call vulnerabilities evolves.  The current discussion (1)
started around the idea of assigning CVE IDs to web/service
vulnerabilities, which I consider natural evolution.

Lots of discussion around the definition/boundary of "vulnerability."

Also a separable discussion (2) about the use of CVE IDs for
internal-only, non-public issue tracking.  Could an organization use CVE
to track vulnerabilities with no expectation of publishing or sharing?
Does an organization want to?

To try to narrow down the services discussion (1), I'll suggest:

It should be permitted to assign CVE IDs to common web application
vulnerabilities in specific sites/services (e.g., facebook.com the site,
not WordPress the product).  "Common web application vulnerabilities"
means things in OWASP/CWE like XSS, SQLi, CSRF.  Consider this a use case.

There is no requirement for any provider, vendor, or CNA to try to be
comprehensive.

Regards,

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Pascal Meunier
I'm afraid that the description of the entries, for issues on services
like facebook.com, would be typically very vague and unverifiable.  I'm
rather annoyed by existing entries that read like "a problem in X, but
different from CVE-1234-5678 and CVE-1234-7890".  What is the issue?
What lessons could be learned from this?  What should we teach not to
do, or teach to do better?  No idea.

Pascal

On Wed, 2017-02-22 at 15:38 -0500, Art Manion wrote:

> Some thoughts based on today's board meeting.
>
> I consider CVE's primary purpose as identification.  There's a good bit
> of work that goes into just doing identification.  Information
> sharing/publishing/cataloging takes work too.  Identification/naming is
> infrastructural and enables many additional functions.
>
> "Vulnerability" is often abstract and subjective.
>
> Software and tech change quickly.  The definition/boundary of what "we"
> "collectively" call vulnerabilities evolves.  The current discussion (1)
> started around the idea of assigning CVE IDs to web/service
> vulnerabilities, which I consider natural evolution.
>
> Lots of discussion around the definition/boundary of "vulnerability."
>
> Also a separable discussion (2) about the use of CVE IDs for
> internal-only, non-public issue tracking.  Could an organization use CVE
> to track vulnerabilities with no expectation of publishing or sharing?
> Does an organization want to?
>
> To try to narrow down the services discussion (1), I'll suggest:
>
> It should be permitted to assign CVE IDs to common web application
> vulnerabilities in specific sites/services (e.g., facebook.com the site,
> not WordPress the product).  "Common web application vulnerabilities"
> means things in OWASP/CWE like XSS, SQLi, CSRF.  Consider this a use case.
>
> There is no requirement for any provider, vendor, or CNA to try to be
> comprehensive.
>
> Regards,
>
>  - Art
>
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

jericho
On Wed, 22 Feb 2017, Pascal Meunier wrote:

: I'm afraid that the description of the entries, for issues on services
: like facebook.com, would be typically very vague and unverifiable.  I'm
: rather annoyed by existing entries that read like "a problem in X, but
: different from CVE-1234-5678 and CVE-1234-7890".  What is the issue?
: What lessons could be learned from this?  What should we teach not to
: do, or teach to do better?  No idea.

Good point.

Also consider that such descriptions would almost never carry version
information and be based more on *approximate* dates. We often hear
Facebook "fixed a vuln" but days or weeks after it really happened. Since
versions are a huge tool for determining potential duplicate issues,
without that would be painful.

.b
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Art Manion
On 2017-02-22 16:19, jericho wrote:

> On Wed, 22 Feb 2017, Pascal Meunier wrote:
>
> : I'm afraid that the description of the entries, for issues on services
> : like facebook.com, would be typically very vague and unverifiable.  I'm
> : rather annoyed by existing entries that read like "a problem in X, but
> : different from CVE-1234-5678 and CVE-1234-7890".  What is the issue?
> : What lessons could be learned from this?  What should we teach not to
> : do, or teach to do better?  No idea.
>
> Good point.
>
> Also consider that such descriptions would almost never carry version
> information and be based more on *approximate* dates. We often hear
> Facebook "fixed a vuln" but days or weeks after it really happened. Since
> versions are a huge tool for determining potential duplicate issues,
> without that would be painful.

Agreed, there's likely pain for cataloging purposes (de-duplication) and
low value for engineering purposes.  But the overriding factor for me is
*identification* (and yes, for ID to work, it has to be possible to
distinguish different vulnerabilities).

CVE throws light on vulnerabilities.  Probably weekly, without looking,
I come across issues that don't have CVE IDs assigned and therefore
aren't noticed by people who might benefit from knowing.  I make a note
to send in a minimum viable entry, but haven't yet.

Oh, services have CVEs?  Airplanes?  Dentist office software?  Oh, large
services freely admit they have vulnerabilities, and fix them?
Users/customers actually like such transparency?

Vulnerabilities are common and everywhere and aren't terribly special
individually.  Name them and go about your choice of defensive
activities, probably including vulnerability management.

 - Art
Reply | Threaded
Open this post in threaded view
|

RE: CVE for hosted services

Booth, Harold (Fed)
I promised on the call to describe a use case for services. Here is one with some branching:

A popular service/site has a vulnerability for some period of time. This vulnerability created an exposure for users/consumers of the service/site. The users/consumers would like to go back and determine if they have been impacted because of this exposure. In order to do this they will need a date range and a description of the problem (i.e. what part of the service was vulnerable), potential impacts on them (the users), and potential (or actual) exploits. While it would be beneficial if the service provider had all of this information, they may not, and now there is a need to have a long-lived identifier to coordinate the discussion among several different stakeholders (I would also argue that just communicating between the service provider and the customer is enough reason for the identifier). I agree collecting this information may not be easy at the moment, but I don't think that doesn't mean it isn't desirable to have it. Minimally, I think this use case demonstrates the need for an identifier. Perhaps once it is demonstrated that this information is important then it will be more routine for it to be tracked and available.

Hopefully, I am not too far afield with this.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Art Manion
Sent: Wednesday, February 22, 2017 4:39 PM
To: jericho <[hidden email]>; Pascal Meunier <[hidden email]>
Cc: cve-editorial-board-list <[hidden email]>
Subject: Re: CVE for hosted services

On 2017-02-22 16:19, jericho wrote:

> On Wed, 22 Feb 2017, Pascal Meunier wrote:
>
> : I'm afraid that the description of the entries, for issues on
> services
> : like facebook.com, would be typically very vague and unverifiable.  
> I'm
> : rather annoyed by existing entries that read like "a problem in X,
> but
> : different from CVE-1234-5678 and CVE-1234-7890".  What is the issue?
> : What lessons could be learned from this?  What should we teach not
> to
> : do, or teach to do better?  No idea.
>
> Good point.
>
> Also consider that such descriptions would almost never carry version
> information and be based more on *approximate* dates. We often hear
> Facebook "fixed a vuln" but days or weeks after it really happened.
> Since versions are a huge tool for determining potential duplicate
> issues, without that would be painful.

Agreed, there's likely pain for cataloging purposes (de-duplication) and low value for engineering purposes.  But the overriding factor for me is
*identification* (and yes, for ID to work, it has to be possible to distinguish different vulnerabilities).

CVE throws light on vulnerabilities.  Probably weekly, without looking, I come across issues that don't have CVE IDs assigned and therefore aren't noticed by people who might benefit from knowing.  I make a note to send in a minimum viable entry, but haven't yet.

Oh, services have CVEs?  Airplanes?  Dentist office software?  Oh, large services freely admit they have vulnerabilities, and fix them?
Users/customers actually like such transparency?

Vulnerabilities are common and everywhere and aren't terribly special individually.  Name them and go about your choice of defensive activities, probably including vulnerability management.

 - Art
Reply | Threaded
Open this post in threaded view
|

RE: CVE for hosted services

jericho

just for the sake of 'argument', and more of an exercise to see what this
is leading to.

https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

Harold, how would you write a CVE-ish description of this, in the context
of moving CVE to site-specific issues? The service and info disclosed is
the easy part. Then what? Do you also mention some of the services that
use Cloudflare? Some businesses may know, where individuals do not (e.g.
1Password is hosted on it). What date range do you put down for this? You
know the fix date, but not the start date. This goes back to the problem
of making such entries useful to companies trying to determine risk.

In many ways, this entry would be one of the easiest to write given the
details, and yet lacks a critical bit of info.

.b



On Thu, 23 Feb 2017, Booth, Harold (Fed) wrote:

: I promised on the call to describe a use case for services. Here is one with some branching:
:
: A popular service/site has a vulnerability for some period of time. This vulnerability created an exposure for users/consumers of the service/site. The users/consumers would like to go back and determine if they have been impacted because of this exposure. In order to do this they will need a date range and a description of the problem (i.e. what part of the service was vulnerable), potential impacts on them (the users), and potential (or actual) exploits. While it would be beneficial if the service provider had all of this information, they may not, and now there is a need to have a long-lived identifier to coordinate the discussion among several different stakeholders (I would also argue that just communicating between the service provider and the customer is enough reason for the identifier). I agree collecting this information may not be easy at the moment, but I don't think that doesn't mean it isn't desirable to have it. Minimally, I think this use case demonstrates t
 he need for an identifier. Perhaps once it is demonstrated that this information is important then it will be more routine for it to be tracked and available.
:
: Hopefully, I am not too far afield with this.
:
: -----Original Message-----
: From: [hidden email] [mailto:[hidden email]] On Behalf Of Art Manion
: Sent: Wednesday, February 22, 2017 4:39 PM
: To: jericho <[hidden email]>; Pascal Meunier <[hidden email]>
: Cc: cve-editorial-board-list <[hidden email]>
: Subject: Re: CVE for hosted services
:
: On 2017-02-22 16:19, jericho wrote:
: > On Wed, 22 Feb 2017, Pascal Meunier wrote:
: >
: > : I'm afraid that the description of the entries, for issues on
: > services
: > : like facebook.com, would be typically very vague and unverifiable.  
: > I'm
: > : rather annoyed by existing entries that read like "a problem in X,
: > but
: > : different from CVE-1234-5678 and CVE-1234-7890".  What is the issue?
: > : What lessons could be learned from this?  What should we teach not
: > to
: > : do, or teach to do better?  No idea.
: >
: > Good point.
: >
: > Also consider that such descriptions would almost never carry version
: > information and be based more on *approximate* dates. We often hear
: > Facebook "fixed a vuln" but days or weeks after it really happened.
: > Since versions are a huge tool for determining potential duplicate
: > issues, without that would be painful.
:
: Agreed, there's likely pain for cataloging purposes (de-duplication) and low value for engineering purposes.  But the overriding factor for me is
: *identification* (and yes, for ID to work, it has to be possible to distinguish different vulnerabilities).
:
: CVE throws light on vulnerabilities.  Probably weekly, without looking, I come across issues that don't have CVE IDs assigned and therefore aren't noticed by people who might benefit from knowing.  I make a note to send in a minimum viable entry, but haven't yet.
:
: Oh, services have CVEs?  Airplanes?  Dentist office software?  Oh, large services freely admit they have vulnerabilities, and fix them?
: Users/customers actually like such transparency?
:
: Vulnerabilities are common and everywhere and aren't terribly special individually.  Name them and go about your choice of defensive activities, probably including vulnerability management.
:
:  - Art
:
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Art Manion
On 2017-02-23 19:05, jericho wrote:

> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>
> Harold, how would you write a CVE-ish description of this, in the context
> of moving CVE to site-specific issues? The service and info disclosed is
> the easy part. Then what? Do you also mention some of the services that
> use Cloudflare? Some businesses may know, where individuals do not (e.g.
> 1Password is hosted on it). What date range do you put down for this? You
> know the fix date, but not the start date. This goes back to the problem
> of making such entries useful to companies trying to determine risk.

Not answering your question, but:

This issue should get a CVE ID so the world can talk about it and have
confidence they're talking about the same "it."  The description might
be tricky, but the description is primarily to catalog/de-duplicate, not
to help assess risk.

CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
CERT, a CloudFlare customer) can add to the severity/risk assessment.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Kurt Seifried
So uhh I'll just leave this example here:


I know for example on the CloudSecurityAlliance side I now need to forcibly reset every password for all our websites, and look at the third parties we do auth from (e.g. FaceBook/Linkedin) to see if they are affected (not that there is much we can do other than notify people). 

On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <[hidden email]> wrote:
On 2017-02-23 19:05, jericho wrote:

> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>
> Harold, how would you write a CVE-ish description of this, in the context
> of moving CVE to site-specific issues? The service and info disclosed is
> the easy part. Then what? Do you also mention some of the services that
> use Cloudflare? Some businesses may know, where individuals do not (e.g.
> 1Password is hosted on it). What date range do you put down for this? You
> know the fix date, but not the start date. This goes back to the problem
> of making such entries useful to companies trying to determine risk.

Not answering your question, but:

This issue should get a CVE ID so the world can talk about it and have
confidence they're talking about the same "it."  The description might
be tricky, but the description is primarily to catalog/de-duplicate, not
to help assess risk.

CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
CERT, a CloudFlare customer) can add to the severity/risk assessment.

 - Art



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CVE for hosted services

Millar, Thomas
How do I use a CVE for a service vuln to check if my environment was affected and if so, that my ops have applied the proper remedies?



Tom Millar, US-CERT

Sent from +1-202-631-1915
https://www.us-cert.gov
 

From: [hidden email] on behalf of Kurt Seifried
Sent: Friday, February 24, 2017 3:44:39 PM
To: Art Manion
Cc: jericho; Booth, Harold (Fed); cve-editorial-board-list
Subject: Re: CVE for hosted services

So uhh I'll just leave this example here:


I know for example on the CloudSecurityAlliance side I now need to forcibly reset every password for all our websites, and look at the third parties we do auth from (e.g. FaceBook/Linkedin) to see if they are affected (not that there is much we can do other than notify people). 

On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <[hidden email]> wrote:
On 2017-02-23 19:05, jericho wrote:

> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>
> Harold, how would you write a CVE-ish description of this, in the context
> of moving CVE to site-specific issues? The service and info disclosed is
> the easy part. Then what? Do you also mention some of the services that
> use Cloudflare? Some businesses may know, where individuals do not (e.g.
> 1Password is hosted on it). What date range do you put down for this? You
> know the fix date, but not the start date. This goes back to the problem
> of making such entries useful to companies trying to determine risk.

Not answering your question, but:

This issue should get a CVE ID so the world can talk about it and have
confidence they're talking about the same "it."  The description might
be tricky, but the description is primarily to catalog/de-duplicate, not
to help assess risk.

CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
CERT, a CloudFlare customer) can add to the severity/risk assessment.

 - Art



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Kurt Seifried-2
For example someone finds another memory disclosure in CloudFlare, and then another person finds a third one. Are we talking about A, B or C? CLoudBleed 1? The thing after CloudBleed? If they had CVE's or an equivalent identifier it would be much easier. Especially as I have to now interact with other vendors (Hey Atlassian, do you deliver JIRA via CloudFlare at all and are you affected by CloudBleed?). 

Especially as the data leaked from CloudBleed is now in all sorts of data caches around the internet (search providers, maybe archive.org, etc.), so we'll need to talk about this off and on for potentially the next few years. 

On Fri, Feb 24, 2017 at 9:03 AM, Millar, Thomas <[hidden email]> wrote:
How do I use a CVE for a service vuln to check if my environment was affected and if so, that my ops have applied the proper remedies?



Tom Millar, US-CERT

Sent from <a href="tel:(202)%20631-1915" value="+12026311915" target="_blank">+1-202-631-1915
https://www.us-cert.gov
 

From: [hidden email] on behalf of Kurt Seifried
Sent: Friday, February 24, 2017 3:44:39 PM
To: Art Manion
Cc: jericho; Booth, Harold (Fed); cve-editorial-board-list
Subject: Re: CVE for hosted services

So uhh I'll just leave this example here:


I know for example on the CloudSecurityAlliance side I now need to forcibly reset every password for all our websites, and look at the third parties we do auth from (e.g. FaceBook/Linkedin) to see if they are affected (not that there is much we can do other than notify people). 

On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <[hidden email]> wrote:
On 2017-02-23 19:05, jericho wrote:

> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>
> Harold, how would you write a CVE-ish description of this, in the context
> of moving CVE to site-specific issues? The service and info disclosed is
> the easy part. Then what? Do you also mention some of the services that
> use Cloudflare? Some businesses may know, where individuals do not (e.g.
> 1Password is hosted on it). What date range do you put down for this? You
> know the fix date, but not the start date. This goes back to the problem
> of making such entries useful to companies trying to determine risk.

Not answering your question, but:

This issue should get a CVE ID so the world can talk about it and have
confidence they're talking about the same "it."  The description might
be tricky, but the description is primarily to catalog/de-duplicate, not
to help assess risk.

CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
CERT, a CloudFlare customer) can add to the severity/risk assessment.

 - Art



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]



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

Re: CVE for hosted services

Pascal Meunier
In this case you're talking about incident IDs, not CVE IDs, because the
second and third ones could be the same core vulnerability as the first,
just badly patched or badly protected.  In addition, two similar
findings at the same time could actually be different vulnerabilities so
you'd need 2 CVEs to do it properly.  Or do we not care anymore, as I
recall seeing a single CVE for multiple vaguely defined vulnerabilities?

For every incident, without visibility inside the remote black box that
is providing the service, we have little to no idea which
vulnerabilities are involved, and we can't ID them.  We can only ID the
findings of problems.  Although giving IDs to incidents and findings is
very useful, that's outside the scope of the CVE.  It's like we have a
hammer (CVE IDs) and everything looks like the proverbial nail now.

I suggest the creation of something else to identify incident, report or
finding IDs.

Pascal


On Fri, 2017-02-24 at 10:11 -0700, Kurt Seifried wrote:

> For example someone finds another memory disclosure in CloudFlare, and then
> another person finds a third one. Are we talking about A, B or C?
> CLoudBleed 1? The thing after CloudBleed? If they had CVE's or an
> equivalent identifier it would be much easier. Especially as I have to now
> interact with other vendors (Hey Atlassian, do you deliver JIRA via
> CloudFlare at all and are you affected by CloudBleed?).
>
> Especially as the data leaked from CloudBleed is now in all sorts of data
> caches around the internet (search providers, maybe archive.org, etc.), so
> we'll need to talk about this off and on for potentially the next few
> years.
>
> On Fri, Feb 24, 2017 at 9:03 AM, Millar, Thomas <[hidden email]>
> wrote:
>
> > How do I use a CVE for a service vuln to check if my environment was
> > affected and if so, that my ops have applied the proper remedies?
> >
> >
> >
> > Tom Millar, US-CERT
> >
> > Sent from +1-202-631-1915 <(202)%20631-1915>
> > https://www.us-cert.gov
> >
> > ------------------------------
> > *From:* [hidden email] on behalf of Kurt
> > Seifried
> > *Sent:* Friday, February 24, 2017 3:44:39 PM
> > *To:* Art Manion
> > *Cc:* jericho; Booth, Harold (Fed); cve-editorial-board-list
> > *Subject:* Re: CVE for hosted services
> >
> > So uhh I'll just leave this example here:
> >
> > https://www.google.ca/search?q=cloudflare+cloudbleed
> >
> > I know for example on the CloudSecurityAlliance side I now need to
> > forcibly reset every password for all our websites, and look at the third
> > parties we do auth from (e.g. FaceBook/Linkedin) to see if they are
> > affected (not that there is much we can do other than notify people).
> >
> > On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <[hidden email]> wrote:
> >
> >> On 2017-02-23 19:05, jericho wrote:
> >>
> >> > https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
> >> >
> >> > Harold, how would you write a CVE-ish description of this, in the
> >> context
> >> > of moving CVE to site-specific issues? The service and info disclosed is
> >> > the easy part. Then what? Do you also mention some of the services that
> >> > use Cloudflare? Some businesses may know, where individuals do not (e.g.
> >> > 1Password is hosted on it). What date range do you put down for this?
> >> You
> >> > know the fix date, but not the start date. This goes back to the problem
> >> > of making such entries useful to companies trying to determine risk.
> >>
> >> Not answering your question, but:
> >>
> >> This issue should get a CVE ID so the world can talk about it and have
> >> confidence they're talking about the same "it."  The description might
> >> be tricky, but the description is primarily to catalog/de-duplicate, not
> >> to help assess risk.
> >>
> >> CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
> >> CERT, a CloudFlare customer) can add to the severity/risk assessment.
> >>
> >>  - Art
> >>
> >
> >
> >
> > --
> >
> > Kurt Seifried -- Red Hat -- Product Security -- Cloud
> > PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> > Red Hat Product Security contact: [hidden email]
> >
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: CVE for hosted services

Kurt Seifried-2


On Fri, Feb 24, 2017 at 10:34 AM, Pascal Meunier <[hidden email]> wrote:
In this case you're talking about incident IDs, not CVE IDs, because the
second and third ones could be the same core vulnerability as the first,
just badly patched or badly protected.  In addition, two similar

Not necessarily. They could be completely separate things/services (TBH I have no idea how cloudflare internally operates, it could be a monolithic binary for all I know). 


 
findings at the same time could actually be different vulnerabilities so
you'd need 2 CVEs to do it properly.  Or do we not care anymore, as I
recall seeing a single CVE for multiple vaguely defined vulnerabilities?

For every incident, without visibility inside the remote black box that
is providing the service, we have little to no idea which
vulnerabilities are involved, and we can't ID them.  We can only ID the
findings of problems.  Although giving IDs to incidents and findings is
very useful, that's outside the scope of the CVE.  It's like we have a
hammer (CVE IDs) and everything looks like the proverbial nail now.

Ideally the provider would help with CVE assignment (much like cloudflare wrote a large blog entry) so that it is done correctly. A lot of these providers care about being seen as security conscious/responsible, it's a major competitive edge.
 

I suggest the creation of something else to identify incident, report or
finding IDs.

Pascal


On Fri, 2017-02-24 at 10:11 -0700, Kurt Seifried wrote:
> For example someone finds another memory disclosure in CloudFlare, and then
> another person finds a third one. Are we talking about A, B or C?
> CLoudBleed 1? The thing after CloudBleed? If they had CVE's or an
> equivalent identifier it would be much easier. Especially as I have to now
> interact with other vendors (Hey Atlassian, do you deliver JIRA via
> CloudFlare at all and are you affected by CloudBleed?).
>
> Especially as the data leaked from CloudBleed is now in all sorts of data
> caches around the internet (search providers, maybe archive.org, etc.), so
> we'll need to talk about this off and on for potentially the next few
> years.
>
> On Fri, Feb 24, 2017 at 9:03 AM, Millar, Thomas <[hidden email]>
> wrote:
>
> > How do I use a CVE for a service vuln to check if my environment was
> > affected and if so, that my ops have applied the proper remedies?
> >
> >
> >
> > Tom Millar, US-CERT
> >
> > Sent from <a href="tel:%2B1-202-631-1915" value="+12026311915">+1-202-631-1915 <(202)%20631-1915>
> > https://www.us-cert.gov
> >
> > ------------------------------
> > *From:* [hidden email] on behalf of Kurt
> > Seifried
> > *Sent:* Friday, February 24, 2017 3:44:39 PM
> > *To:* Art Manion
> > *Cc:* jericho; Booth, Harold (Fed); cve-editorial-board-list
> > *Subject:* Re: CVE for hosted services
> >
> > So uhh I'll just leave this example here:
> >
> > https://www.google.ca/search?q=cloudflare+cloudbleed
> >
> > I know for example on the CloudSecurityAlliance side I now need to
> > forcibly reset every password for all our websites, and look at the third
> > parties we do auth from (e.g. FaceBook/Linkedin) to see if they are
> > affected (not that there is much we can do other than notify people).
> >
> > On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <[hidden email]> wrote:
> >
> >> On 2017-02-23 19:05, jericho wrote:
> >>
> >> > https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
> >> >
> >> > Harold, how would you write a CVE-ish description of this, in the
> >> context
> >> > of moving CVE to site-specific issues? The service and info disclosed is
> >> > the easy part. Then what? Do you also mention some of the services that
> >> > use Cloudflare? Some businesses may know, where individuals do not (e.g.
> >> > 1Password is hosted on it). What date range do you put down for this?
> >> You
> >> > know the fix date, but not the start date. This goes back to the problem
> >> > of making such entries useful to companies trying to determine risk.
> >>
> >> Not answering your question, but:
> >>
> >> This issue should get a CVE ID so the world can talk about it and have
> >> confidence they're talking about the same "it."  The description might
> >> be tricky, but the description is primarily to catalog/de-duplicate, not
> >> to help assess risk.
> >>
> >> CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
> >> CERT, a CloudFlare customer) can add to the severity/risk assessment.
> >>
> >>  - Art
> >>
> >
> >
> >
> > --
> >
> > Kurt Seifried -- Red Hat -- Product Security -- Cloud
> > PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> > Red Hat Product Security contact: [hidden email]
> >
>
>
>





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

Re: CVE for hosted services

Pascal Meunier
On Fri, 2017-02-24 at 10:36 -0700, Kurt Seifried wrote:

> On Fri, Feb 24, 2017 at 10:34 AM, Pascal Meunier <[hidden email]
> > wrote:
>
> > In this case you're talking about incident IDs, not CVE IDs, because the
> > second and third ones could be the same core vulnerability as the first,
> > just badly patched or badly protected.  In addition, two similar
> >
>
> Not necessarily. They could be completely separate things/services (TBH I
> have no idea how cloudflare internally operates, it could be a monolithic
> binary for all I know).
>

The point is we can't know, unless as you suggest further below the
provider actively helps with CVE assignment -- in which case they are
our hmm, proxy, into the problem.  Even better if the reporter and
provider work together, but I don't think we can count on that often.
I'll fall back on the suggestion by someone else (paraphrasing) that the
CVE IDs be given when it makes sense for such cases, without trying to
systematically cover the entire space, making this an "optional scope".
To me it makes sense only when the vulnerability can be identified in
software running somewhere, not just when any security problem has been
found.

>
>
>
> > findings at the same time could actually be different vulnerabilities so
> > you'd need 2 CVEs to do it properly.  Or do we not care anymore, as I
> > recall seeing a single CVE for multiple vaguely defined vulnerabilities?
> >
> > For every incident, without visibility inside the remote black box that
> > is providing the service, we have little to no idea which
> > vulnerabilities are involved, and we can't ID them.  We can only ID the
> > findings of problems.  Although giving IDs to incidents and findings is
> > very useful, that's outside the scope of the CVE.  It's like we have a
> > hammer (CVE IDs) and everything looks like the proverbial nail now.
> >
>
> Ideally the provider would help with CVE assignment (much like cloudflare
> wrote a large blog entry) so that it is done correctly. A lot of these
> providers care about being seen as security conscious/responsible, it's a
> major competitive edge.
>
>
> >
> > I suggest the creation of something else to identify incident, report or
> > finding IDs.
> >
> > Pascal
> >
> >
> > On Fri, 2017-02-24 at 10:11 -0700, Kurt Seifried wrote:
> > > For example someone finds another memory disclosure in CloudFlare, and
> > then
> > > another person finds a third one. Are we talking about A, B or C?
> > > CLoudBleed 1? The thing after CloudBleed? If they had CVE's or an
> > > equivalent identifier it would be much easier. Especially as I have to
> > now
> > > interact with other vendors (Hey Atlassian, do you deliver JIRA via
> > > CloudFlare at all and are you affected by CloudBleed?).
> > >
> > > Especially as the data leaked from CloudBleed is now in all sorts of data
> > > caches around the internet (search providers, maybe archive.org, etc.),
> > so
> > > we'll need to talk about this off and on for potentially the next few
> > > years.
> > >
> > > On Fri, Feb 24, 2017 at 9:03 AM, Millar, Thomas <
> > [hidden email]>
> > > wrote:
> > >
> > > > How do I use a CVE for a service vuln to check if my environment was
> > > > affected and if so, that my ops have applied the proper remedies?
> > > >
> > > >
> > > >
> > > > Tom Millar, US-CERT
> > > >
> > > > Sent from +1-202-631-1915 <(202)%20631-1915>
> > > > https://www.us-cert.gov
> > > >
> > > > ------------------------------
> > > > *From:* [hidden email] on behalf of
> > Kurt
> > > > Seifried
> > > > *Sent:* Friday, February 24, 2017 3:44:39 PM
> > > > *To:* Art Manion
> > > > *Cc:* jericho; Booth, Harold (Fed); cve-editorial-board-list
> > > > *Subject:* Re: CVE for hosted services
> > > >
> > > > So uhh I'll just leave this example here:
> > > >
> > > > https://www.google.ca/search?q=cloudflare+cloudbleed
> > > >
> > > > I know for example on the CloudSecurityAlliance side I now need to
> > > > forcibly reset every password for all our websites, and look at the
> > third
> > > > parties we do auth from (e.g. FaceBook/Linkedin) to see if they are
> > > > affected (not that there is much we can do other than notify people).
> > > >
> > > > On Thu, Feb 23, 2017 at 8:36 PM, Art Manion <[hidden email]> wrote:
> > > >
> > > >> On 2017-02-23 19:05, jericho wrote:
> > > >>
> > > >> > https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
> > > >> >
> > > >> > Harold, how would you write a CVE-ish description of this, in the
> > > >> context
> > > >> > of moving CVE to site-specific issues? The service and info
> > disclosed is
> > > >> > the easy part. Then what? Do you also mention some of the services
> > that
> > > >> > use Cloudflare? Some businesses may know, where individuals do not
> > (e.g.
> > > >> > 1Password is hosted on it). What date range do you put down for
> > this?
> > > >> You
> > > >> > know the fix date, but not the start date. This goes back to the
> > problem
> > > >> > of making such entries useful to companies trying to determine risk.
> > > >>
> > > >> Not answering your question, but:
> > > >>
> > > >> This issue should get a CVE ID so the world can talk about it and have
> > > >> confidence they're talking about the same "it."  The description might
> > > >> be tricky, but the description is primarily to catalog/de-duplicate,
> > not
> > > >> to help assess risk.
> > > >>
> > > >> CVE is lower layer of infrastructure.  Someone else (NVD, CVSS, RBS,
> > > >> CERT, a CloudFlare customer) can add to the severity/risk assessment.
> > > >>
> > > >>  - Art
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Kurt Seifried -- Red Hat -- Product Security -- Cloud
> > > > PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> > > > Red Hat Product Security contact: [hidden email]
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
12