[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVE For Services

Folks,

 

To connect this to the discussion of required information for CVE entry submissions, if we were to consider a typical service vulnerability, could we describe it in the minimal CVE entry information?

 

CVEID

PRODUCT

VERSION

PROBLEM TYPE

PUBLICATION DATE (of the vulnerability information becoming public; or a timeline of specific events related to the vulnerability being made public)

ASSIGNING CNA (or chain of assigning CNAs if there is a Sub-CNA under a Root doing the assignment)

IMPACT

 

CVEID - Yes.

PRODUCT - Which product would this be? The service? The affected component? We will need to specify this in the Rules.

VERSION - If a service doesn't follow a public versioning scheme, would using the date-based method (that Kurt had mentioned) work? Should there be another scheme?

PROBLEM TYPE - We haven't adopted any particular scheme for the data to be included here, so there is no current problem. Whatever scheme that may be chosen or developed in the future would have to include language that could be applied to both software and service vulnerabilities. For example, I believe CWE would still work as well as it works now for software weaknesses.

ASSIGNING CNA - Yes.

IMPACT - Yes.

 

So, no problems there, but we may need a little refinement of terminology. That is straightforward.

 

For a CNA assigning CVE IDs for their own products, they should have enough information to determine the existence of unique vulnerabilities and the number that should be assigned. For a CNA like MITRE or a vulnerability researcher, who often doesn't have complete information, many assumptions would have to be made during counting.

 

Let's say MITRE receives a report from a vulnerability researcher that there is a vulnerability in cloud service's provisioning system. The researcher can demonstrate that some kind of security policy can be circumvented. But the guts of that provisioning system are not visible to the researcher or MITRE. There has been no response from the cloud vendor after attempts at contacting them.

 

So, we follow the counting rules. For CNT1, we cannot tell if it is independently fixable (CNT1). We can determine CNT2.1, vendor acknowledgement. In this case, we have none, so we move on to CNT2.2A and CNT2.2B. We perceive a security-model-based vulnerability, CNT2.2B, so we move on to CNT3.

 

For CNT3 (which asks if there are shared codebases, libraries, or protocols), we do not know, so we assign a CVE ID for each product that may be affected. We then move on to Inclusion.

 

Stepping through the Inclusion rules (and assuming they are amended to allow for services in INC3), when we hit INC5 we get the "not sure" result as to whether or not the vulnerability has been assigned a CVE ID yet. Therefore, we assign a CVE ID to it.

 

Having done this, we can successfully navigate the Counting Rules with the minimal information given by the researcher. There is a danger that because we have such limited info, though, we may have miscounted. We cannot know for sure until the vendor publishes more information about the issue, and we can then update, split, merge, or reject the assignment.

 

This is all well and good, but let's fast forward a month. Another researcher contacts us with a very similar issue. Over the last month, the vendor's service has changed appearance, but the vendor offers no indicating that the underlying code has been changed, so we can't say it is a different version or not. Should we assign a new CVE ID, using date in lieu of service version? What if another researcher shows up a week later with something that is very similar to the previous two issues, but, again, we have no hard evidence that there has been a code change in the service?

 

Right now, without additional information, MITRE would treat all these as the same CVE ID. We may update the CVE entry with the latest date it was reported (since we have no versioning).

 

Ideally, the vendor will wake up at some point and start coordinating with its customers and researchers. But if they do not, the likelihood of creating many duplicates is higher than it currently is since we have more variables that are hidden from the public's view. Is that risk acceptable to the Board?

 

If not, should we limit CVE assignment for services only to vendor CNAs who are assigning to their own services? Is that "have/have not" structure manageable, since it creates inconsistencies on how CVE IDs are assigned and for what?

 

In this case, MITRE could say, "we will not assign to services, but anyone who wishes to be a CNA for services (or individual services) can under the Rules". Is that acceptable?

 

Thoughts?

 

Thanks.

 

-Dan

 

From: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of Kurt Seifried <kseifried@redhat.com>
Date: Wednesday, September 6, 2017 at 11:16
To: "Andy Balinsky (balinsky)" <balinsky@cisco.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CVE For Services

 

 

 

On Wed, Sep 6, 2017 at 7:24 AM, Andy Balinsky (balinsky) <balinsky@cisco.com> wrote:

Cisco has many services, regularly issues advisories on them, and does not pay anyone any bounties. Cisco doesn't really distinguish between a shipped product and a service. Many of our products come with management services (e.g. Meraki routers that are entirely dependent on cloud management). Many of our services include a physical piece of hardware as a data collector, or are services that use physical installed products as their data sources, their management targets. 

 

I agree that services CVEs for third party researchers are a much more murky area (how do they legally do testing, how do they confirm, what do they use for version numbers, etc.), but for vendors who have open disclosure policies, I would argue that issuing CVEs should be an option for them.

 

API's can and should do versioning (link to docs example, a lot of other products also do this):

 

 

And at a minimum you have dates, e.g. a vendor can say "it was vulnerable from Date X until Date Y, so any use/transactions/whatever done in that period should be redone/considered possibly exposed, whatever."

 

But really, people need to version APIs. It's basic sanity. 

 

 

 

Andy

 

On Sep 5, 2017, at 10:33 PM, kseifried@redhat.com wrote:

 



On 2017-09-05 09:02 PM, Andy Balinsky (balinsky) wrote:

I plan to bring up discussion of this topic at tomorrow's board meeting.
It lead to a healthy online discussion, but has languished for 6 months.
Whether we make a change to the INC3 rule or not, we need to do so
deliberately, not by neglect of discussion.

Thanks,

Andy Balinsky (balinsky)
PSIRT Engineering
balinsky@cisco.com <mailto:balinsky@cisco.com>


I am in favor of this (more transparency is better IMHO), however I see
two main obstacles:

1) Many services don't want to admit to flaws, and they can generally
hide them (only if someone's blog posting goes viral do we usually find
out), it's hard to test and hold them accountable (especially with many
jurisdictions having laws against poking away at services).

2) The services that do care about this kind of thing are running bug
bounties and thus already getting a lot of the benefit that CVE would
provide in the form of having a mature security process, and having a
service CVE doesn't give them much benefit (at this time).

I would suggest if we are going to go ahead with this we talk to the
service bug bounty companies as, by definition, they have all the people
that would care about this.


--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com

 

Andy Balinsky (balinsky)

PSIRT Engineering

 

 

 



 

--


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com

Page Last Updated or Reviewed: September 26, 2017