Re: CVE For Services

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

So, on the call today, we discussed this briefly, and decided that it will be an agenda item in 2 weeks.

Please look over the document and discuss on the list, or add examples, or suggest updates to the doc.

Silence will be construed as agreement with what is written there.

Andy

On Oct 4, 2017, at 10:12 AM, Andy Balinsky (balinsky) <balinsky@cisco.com> wrote:

FYI, I have updated the summary document for the CVE for Services discussion.

Feel free to make changes, comment, add to the Pros or Cons section or the Examples section if I haven't captured a good summary of the on-list discussions there.

https://github.com/CVEProject/Board-Discussions/blob/master/CVE_IDs_for_Services.md

Andy

On Sep 29, 2017, at 3:12 PM, Kurt Seifried <kseifried@redhat.com> wrote:

On Fri, Sep 29, 2017 at 2:04 PM, Art Manion <amanion@cert.org> wrote:

On 9/26/17 12:26 PM, Kurt Seifried wrote:

1) we for sure let service CNAs self assign (these are the mature ones obviously that will play nice in most cases I hope, in theory an evil company could become a CNA in order to quash any claims of CVEs in their services, but hopefully that doesn't happen)

2) we for sure assign CVEs if the claimant can prove their claim (e.g. "Do X/Y/Z and bad thing happens")

Agree with both of these, sufficient evidence of vulnerability exists (admission by vendor, PoC).

I'll note that testing live web sites in many jurisdictions, including the US, can be legally risky.

3) we consider CVEs where the claimant makes a claim but does not have strong evidence, we try to talk to the service provider, we see how that goes and depending on the evidence/etc. a CVE may or may not be assigned.

#2 is easier for product vulnerabilities.

#3 is a problem for product or service vulnerabilities where neither the vendor nor a third party can corroborate the claim.  While there's an argument to be made for "name all the things right away and later mark them disputed or rejected," CVE historically has taken an approach of "wait for the dust to settle then name whatever is left standing."  I don't see it as CVE's role to validate vulnerabilities, that is the job of (some) CNAs, vendors, researchers, and others.

I'm in favor of being able to assign CVE IDs to service vulnerabilities.  But I'd happily accept a cautious approach, generally not assigning for case #3.

Yeah, we can definitely start with the easy case(s) and then see how things go (witness the DWF: I'm trying to avoid embargoed CVEs because they're a pain =). 

 

There was discussion about a "this is a service vul" flag, is that still on the table?

If we go with CVE for this I would suggest we not only use a service flag (e.g. "product_type" is "end_user_software" and "service" for now or something along these lines) AND we set aside a block (say CVE-YEAR-2000000-2999999) for these giving people another way to ignore them if they want to.

 

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: secalert@redhat.com

Andy Balinsky (balinsky)

PSIRT Engineering

balinsky@cisco.com

Andy Balinsky (balinsky)

PSIRT Engineering

balinsky@cisco.com