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

Re: Question about dual source vendors

I very much like the idea of someone being able to get an identifier 
from an alternate CNA, when the CNA nominally responsible for an area 
is 
disfunctional or unwilling to perform, say due to a conflict of 
interest 
like refusing to admit that an issue is a real concern or trying to 
delay disclosure.  These conflicts of interests are quite possible when 
the CNA is also the vendor, which seems to be the model going forward. 
There should ideally be alternate, secondary or "backup" CVE issuers 
for 
all domains.

Pascal

On 06/17/2016 11:32 AM, Andy Balinsky (balinsky) wrote:
> Regarding "CNA shopping" Is this a problem, as long as only 1 CVE 
> gets issued?
> Andy
> On Jun 16, 2016, at 7:37 PM, Adinolfi, Daniel R 
> <dadinolfi@mitre.org<mailto:dadinolfi@mitre.org>> wrote:
>
> Thinking through the issue:
>
> Ideally, the vendor would themselves be a CNA, covering their 
> products regardless of the type of licensing model.
>
> Not every company can be or wants to be a CNA, of course, so how do 
> we handle those?
>
> If there is another sector-based CNA (e.g., Healthcare systems) or a 
> regional CNA (e.g., JPCERT), the company could work directly with 
> those CNAs, who will facilitate the CVE assignment and disclosure 
> regardless.
>
> If neither of these situations fit, it will depend on how DWF manages 
> their assignees. MITRE as a CNA has the advantage of being a trusted 
> third party for vulnerability disclosure. When closed-source software 
> is involved, that trust can be important. If DWF creates that same 
> level of trust with closed-source vendors, they could also fulfill 
> that role. But this leads to some tricky scoping issues, and it could 
> create situations similar to "CNA shopping" or introduce other 
> coordination issues.
>
> How do other folks feel about these scoping issues?
>
> Thanks.
>
> -Dan
>
>
> ________________________________
> From: 
> owner-cve-editorial-board-list@lists.mitre.org<mailto:owner-cve-editorial-board-list@lists.mitre.org>
>  
> <owner-cve-editorial-board-list@lists.mitre.org<mailto:owner-cve-editorial-board-list@lists.mitre.org>>
>  on behalf of Kurt Seifried 
> <kseifried@redhat.com<mailto:kseifried@redhat.com>>
> Sent: Thursday, June 16, 2016 7:13:58 PM
> To: cve-editorial-board-list
> Subject: Question about dual source vendors
>
> So increasingly we have "dual source" vendors, that is vendors with 
> everything from fully OSI Open Source to completely closed source. 
> Basically any large commercial vendor already (Microsoft, Oracle, 
> etc.) and a growing number of others (witness the proliferation of 
> GitHub projects).
>
> I am talking to one that is not a CNA, and they want to do CVEs for 
> both their Open Source, and their closed source. But there is no easy 
> way to do this currently other than ask 
> cve-assign@mitre.org<mailto:cve-assign@mitre.org> directly (and it 
> seems after they read the 
> https://cve.mitre.org/cve/data_sources_product_coverage.html document 
> they were under the impression 
> cve-assign@mitre.org<mailto:cve-assign@mitre.org> could NOT do it).
>
> I would like to propose that for vendors where Open Source is a major 
> part of what they ship, or the core of their commercial; product that 
> the DWF be able to take them under it's wing as it were.
>
> One hypothetical example that fits into this model would be a company 
> like Ansible (let's ignore the fact that Red Hat acquired it and as 
> such Ansible falls under the Red Hat CNA), Ansible currently has 
> "ansible" which is the Open Source core, and Ansible tower which is a 
> currently closed source management/dashboard. I think in a case like 
> this it makes sense to have a company like Ansible be a CNA under the 
> DWF for both the Open Source parts and the closed source parts.
>
> Thought/comments?
>
> --
> 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<mailto:secalert@redhat.com>
>
Page Last Updated or Reviewed: June 17, 2016