再保险:关于双重来源供应商的问题

似乎这个对话是变形从简单澄清一些更广泛的东西。我看看可以解剖这个…。库尔特问道:>我想建议供应商,开源是一个主要>他们船的一部分,或他们的商业的核心;产品> DWF能够带他们在它的庇护下。这是一个游泳巷的讨论。个人这应该由父母决定CNA的东西。在这种情况下,斜接。我建议将没有问题。当有更多的根CNAs只是DWF,我认为我们应该让“管理链”建立的层次结构决定。丹写道:>如果没有这些情况合适,这将取决于DWF管理>他们的受托人。 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. I am sorry but I have heard this trust argument before and have never believed it when it came to MITRE. I do believe it when it comes to a Vulnerability Coordinators such a US-CERT. Coordination requires much more active hands on with highly sensitive information, working closely with vendors and researchers to address issues and assure a coordinated release. MITRE touches some sensitive information but trust is not why people come to MITRE for a CVE. Just not. You do bring up a great topic, CNA Shopping. Pascal’s comments are exactly how I feel as well. Requesters should go to an identifiable CNA as a normal course of action. I don’t believe we should completely lock someone in to only 1 CNA. In a hierarchy, the requester should be able to walk the tree to circumvent a CNA that is refusing to work with the requester. The requester should indicate the reason to the secondary CNA as to why they are making the request to a CNA other than their primary. That is valuable information as to the behavior of the CNAs acceptance and activities. --- Kent Landfield +1.817.637.8026 On 6/17/16, 11:18 AM, "owner-cve-editorial-board-list@lists.mitre.org on behalf of Pascal Meunier"  wrote: 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 > mailto: dadinolfi@mitre.org> >中写道:> >思考这个问题:> >在理想的情况下,供应商将自己CNA,覆盖>产品无论许可模式的类型。> >不是每个公司都可以或想成为CNA,当然,我们>怎么处理这些?> >如果有另一个基于CNA(例如,医疗系统)或>区域CNA(例如,JPCERT),该公司可以直接处理>那些区域将促进CVE分配和信息披露>。> >如果这些情况符合,它将取决于DWF管理>他们的受托人。主教法冠作为CNA的优势是脆弱的信任>第三方披露。当闭源软件>,这种信任可能是重要的。如果DWF创建相同>和闭源供应商的信任度,他们也可以实现>这个角色。但这将导致一些棘手的范围问题,它可以>创建情况类似于“CNA购物”或介绍其他>协调问题。> >其他人如何看待这些范围的问题吗?> >谢谢。 > > -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> > >代表Kurt Seifried > < kseifried@redhat.com <mailto: kseifried@redhat.com> > >发送:周四,6月16日2016年7:13:58点>:cve-editorial-board-list >主题:关于双重来源供应商> >我们越来越有“双重来源”供应商,与>从供应商完全OSI开放源码完全闭源。>已经基本上任何大型商业供应商(微软,甲骨文,>等等),越来越多的人(证人的扩散> GitHub项目)。> >我说,不是一个中央社,他们想做的cf >他们的开源的,和他们的闭源。但是没有简单>方法目前除了问> cve-assign@mitre.org <mailto: cve-assign@mitre.org>直接(>似乎在他们阅读>https://cve.mitre.org/cve/data_sources_product_coverage.html他们的印象> cve-assign@mitre.org <文件>mailto: cve-assign@mitre.org>不可能做到)。> >我想建议供应商,开源是一个主要>他们船的一部分,或他们的商业的核心;产品> DWF能够带他们在它的庇护下。> >一个假设的例子,适合这个模型将是一个公司> Ansible(让我们忽略了一个事实,Red Hat收购它,等> Ansible属于Red Hat CNA),目前Ansible >“Ansible”,这是开源核心,和Ansible塔>目前闭源管理/仪表板。我认为在这样的情况下>这是有意义的一个公司像Ansible CNA下> DWF开源部分和闭源部分。> >想/评论吗?> > - - > Kurt Seifried——红帽产品安全——云> PGP A90B F995 7350 148 f 66高炉7554 160 d 4553 7993 > e26红帽产品安全联系:> secalert@redhat.com <mailto: secalert@redhat.com> >