再保险:CNA需求

2016年5月17日星期二,上午8:54,Waltermire David a .(美联储)<david.waltermire@nist.gov>写道:

恕我直言,我认为我们需要解决这个问题的方式支持无等级,图的区域之间的通信。这个模型在现实世界中发生了什么。应该有可能对任何CNA找到其他CNA,得到他们的联系信息,然后向他们伸出我们的CVE分配协调。依靠父母始终不做这项工作。

问候,
戴夫

我一直在思考这个问题,回顾某些情况下在过去的5000年左右CVE我分配,有些事是显而易见的:

1)作为一个中央社需要你有一个成熟安全的过程,如果你没有这个你无法函数作为CNA更不用说CVE然后做一些有用的东西。所以从DWF的观点很简单,你必须这么高(高度决定的要求)的骑,成为中央社。

2)我们有四个主要类型的CVE相关组:

研究人员发现vulns

b)协调人帮助处理vulns

修复vulns c)供应商

d)最终用户使用CVE数据/修复/等

a组)这很简单,如果他们是成熟的,表现好他们意义成为中央社,然后他们的vulns cf从第一天起,更容易跟踪。有一些潜在的并行发现和重复,但这是罕见的足够它不会是一个巨大的问题。

b组)这很简单,如果他们是成熟的,表现好他们意义成为中央社,与vulns人来到他们,他们得到一个CVE极大帮助协调。有一些潜在的并行发现和重复,但这是罕见的足够它不会是一个巨大的问题。平行的发现也可以在这里得到解决,如果使用相同的证书的问题。

c组)这很简单,如果他们是成熟的,表现好他们意义成为中央社,与vulns人来到他们,他们得到一个CVE极大帮助协调。平行的发现也可以解决,这里假设cf报道供应商(如果他们没有,我们有更糟糕的问题)。

d组)并不是如此简单,但我可以看到一个例子,一个庞大的消费潜力的安全更新想要确保他们都有cf。我怀疑在这种情况下,我建议人们去DWF /斜接,我看不出我们铸造CNA只是一个消费者的安全更新没有一些很有趣的情况下(这可能发生,我知道什么?)。

至于联系信息我只是要求CNA的DWF创建与我们注册,他们必须有一个有效的电子邮件地址,几乎总是一个URL发布cf(虽然不是必须的,我可以看到有一个潜在的例外)。我也决定不设立最低人数(超出了“1”的明显的答案)由于许多项目有时一个核心开发人员驾驶的安全工作,根据以往的经验很多做一个很好的工作。我肯定会不会需要一个电话号码。

至于“子CNA的”,我没有考虑到大量的思想,但我认为最好的/简单的将主要有DWF政策“流过”,所以我们有一致性,好联系资料等。

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