再保险:杜松添加到官方列表区域

2016年4月26日,星期二,在十一28点,耶利哥<jericho@attrition.org>写道:

马尼恩在结婚,2016年4月27日,艺术写道:


:说到后果,如果Juniper不遵守规则?
:撤回CNA状态?那么谁会问题CVE id
:杜松漏洞?如果一个CNA分配不正确,拒绝他们
:作业。如果CNA实际上希望他们的CVE id数,他们会
:形状。如果他们不这样做,他们退市。是的,这听起来确实像
:自由放任。当前的模型没有规模。

我说这一点。我们不需要规则,我们所需要的
一个清晰的路径上斜方如何处理他们,如果他们不是
规则。除非横切后循环的决定让我报道
CNAs多次不遵守规则,那么我不相信横切
跟踪他们。或者我的一小部分
投诉。

我不能想象会撤销CNA冠冕,因为它违背
他们自私的利益(CVE是一个数百万美元的合同的一部分
他们享受每年)。这是一个残酷的现实,我们需要记住我们
讨论这个问题。我只把它,因为我们中的许多人已经提出
斜方带来更多CNAs几年前,那是会见了
沉默或反对(通常在私人)。现在他们被称为
项新CNAs任务,似乎可能是他们的答案,即使
供应商有坏的历史任务和董事会成员对象。

我宁愿看到教育/等等,而不是撤销(经典的改造与惩罚)。撤销中央社也会导致“损害”,假设前CNA还是CVE他们将需要更长的时间(我认为),或者他们完全停止做CVE。

DWF我的计划是去想它,最好避免这个问题,但是如果它发生开始教育,如果不工作,我们加大。

事实上,每一个中央社,当前或提议,应每年审计一次,
确保他们遵循作业指导方针。看起来小,
行人在表面上很多(如分配2016 ID 2015
问题),也可以在巨大的雪球方面,如2016年的Verizon DBIR
报告(pg13,“漏洞”部分)的方法
定义,他们可能使用的ID属性披露
属性。即使他们不,* *人历史上做了而已
每年,当生成基于CVE vuln总数的数据。这些统计数据
只有你看到任何媒体,行业或主流。因为CVE
不认为的披露日期1999年跟踪很重要,意味着什么
几乎每一个漏洞统计今天是荒谬的和错误的。

审计会有问题的供应商有很多cf (Red Hat)或供应商有限的信息披露(没有名字,但我们都知道至少有一个…)。我更感兴趣的是确保CVE过程和CNAs /斜方提供反馈我们可以识别和解决这些问题。也许这样的例子应该被张贴到列表中(假设我们不洪水)?

- - -
Kurt Seifried——红帽产品安全——云
PGP A90B F995 7350 148 f 66高炉7554 160 d 4553 5 e26 7993
红帽产品安全联系: secalert@redhat.com