RE: CVE For Services

["Coffin, Chris" <ccoffin@mitre.org>]

• 2. The user of the service can take a discrete action to remove the vulnerability, or to have it removed

 

We have traditionally assigned CVEs only to those products that are “customer-controlled” (i.e., the software is installed locally and is patched/updated by the end user). However, in prior discussions it was pointed out that more and more software is breaking this model. There are obviously more SaaS offerings, but there are also hybrids between the two, and it may not always be clear what software exists locally and what doesn’t.

 

Going back to number 2 though, maybe we could think of this not in the sense that the end user can take an action to remove it from their system or keep it updated, but maybe in that they could simply stop using the service based on CVEs present, or a complete lack of CVEs at all.

 

If we have certain CNAs who are interested in reporting ViaS, it’s probably worth putting together a plan and trying it out. Would be happy to discuss in the meeting today.

 

Regards,

 

Chris C

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Millar, Thomas
Sent: Wednesday, September 6, 2017 8:35 AM
To: Andy Balinsky (balinsky) <balinsky@cisco.com>; kseifried@redhat.com
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: RE: CVE For Services

 

Thoughts:

Vulnerabilities-in-a-Service (ViaS) might be CVE worthy if:

1. They can and should be scanned or audited for
2. The user of the service can take a discrete action to remove the vulnerability, or to have it removed
3. The same ViaS is available from (exploitable in) multiple SPs, possibly including multiple LoBs in the same company
4. Plus whatever we said 6 months ago; I'm in transit so the archives are not readily accessible



Tom Millar, US-CERT

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

 

---

From: owner-cve-editorial-board-list@lists.mitre.org on behalf of Andy Balinsky (balinsky)
Sent: Wednesday, September 06, 2017 2:24:06 PM
To: kseifried@redhat.com
Cc: cve-editorial-board-list
Subject: Re: CVE For Services

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.

 

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

balinsky@cisco.com