Re:所以一些盲点,因此CVE的服务的讨论

在星期二,2018年12月11日,马尼恩36点艺术<amanion@cert.org>写道:

在10/31/18下午1:20,丽莎奥尔森写道:
>我头脑风暴与同事这是微软。附加的文档将我们的思想,并提供了一些例子。

我通常支持至少允许cf服务漏洞问题。我的立场是:

CVE是脆弱性识别(命名、枚举),其他的都是多余的。

我很好与一个相当宽松的定义“漏洞”,基本上没有限制的产品,服务,物联网、安全至关重要的事情——任何软件系统的范围。

如果是足够接近成为一个脆弱和两个以上的人想谈论它,一个ID是一个好主意。记住其他Facebook脆弱,没有谈论的不是库尔特,第二使用的三大妥协?

OTOH,我不是立即与分配好的CVE云违反。当我接受一个松散的脆弱性的定义,没有弱点的证据,不足以分配一个CVE。我们很少知道大多数大型/公共漏洞的根本原因。

如果我们有违约的证据表明坏事脆弱/接触发生了明智的?如。https://haveibeenpwned.com/或供应商说“坏事情发生了我们早期关闭4个月Google +”(关闭https://www.google.ca/search?q=google%2B + + 4 +个月+早期)。

我很好与用户/客户需要采取行动,用户/客户能够更好的法医/事件调查,甚至“有人想为服务指定一个CVE漏洞和跟着CVE实践正确。”

有一些讨论一个“服务”的旗帜,,我很好,但是它开门分类漏洞,这很快就会变得混乱。

所以我认为我们需要的是:

1)生产/实验国旗。

2)一组尽力服务标记的旗帜,如。“软件”,“服务”,其他选项? ? ?(部分将所有上述提到的Red Hat OpenShift古典前提软件,openshift.com所使用的服务,和其他供应商在内部和外部提供服务的前提。

符合# 2将附属关系链的东西,例如OpenSSL(理论上每个OpenSSL CVE应该电话簿的大小只是列出所有电视和云服务使用它)。

——艺术

- - -

Kurt Seifried
kurt@seifried.org