Re: CVE For Services

["Andy Balinsky (balinsky)" <balinsky@cisco.com>]

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