再保险:必须使用CVE IDs内部缺陷跟踪

上星期五,2017年2月24日下午三11点,棺材,克里斯<ccoffin@mitre.org>写道:

作为2月22日的一部分CVE董事会,董事会讨论必须使用CVE id作为其内部缺陷跟踪的一部分。具体来说,当分配CVE IDs CNA在脆弱性管理过程的早期,CVE IDs可以转让的细节问题还没有完全理解(例如,问题是后来发现不是一个漏洞,多个漏洞是一个,等等)或者没有一个打算公开它们。我们知道有软件维护人员,想以这种方式功能。CVE想接触董事会作为一个整体,必须更好地通知任何决定关于这是否应该被允许。

目前一些CNAs分配CVE id作为最后一步在出版之前,我们绝不说这是错误的或试图引导这些必须远离继续这种做法。相反,问题是如果CNAs应灵活地分配CVE id以任何方式最适合他们的。为了支持这种灵活性,当前CNA规则需要改变。

的主要好处指出这一观点的支持者声称,在过程的早期使用CVE id允许必须在它们的整个生命周期过程中更容易跟踪他们的弱点。例如,附加CVE ID作为第一步在这个过程中避免了需要分配一个内部ID(例如,内部错误ID),然后不得不内部ID映射到一个CVE ID。另一个点在董事会电话讨论的事实让这个任务的灵活性可以促进将来额外使用CVE ID。

也分享当处理嵌入式组件(例如开源,也是商业的东西现在在容器中。其他系统如后端数据库),或与软件广泛供应量由多个供应商(例如ISC DHCP,绑定等)。

这种灵活性的一个缺点是,下游CVE用户将无法确定CVE ID是在使用。我们已经有这个问题的保留CVE id列表,但是横切是努力减少保留CVE id。然而,拟议的改变将使这个问题变得更糟。

一个建议是由董事会称,可能有助于缓解一些问题与允许这种灵活性CNAs有关。建议是创建一个新的CVE ID状态覆盖CNA块保留。而不是保留,我们可能会将他们称为CNA-ASSIGNED或其他标记,它们有别于其他目前保留CVE id。这可能有助于CVE终端用户区分CVE id指定为块必须与CVE id分配给研究人员公开或非公开但已确定漏洞。

我建议我们有几个主要国家:

保留的CNA计划使用它(例如,可能是一块的一部分),我不确定我们需要明确提及这个(如我的100万块…)

分配CNA但尚未公开

公共

DWF的我的计划是简单地列出CNA的及其块,这样人们知道谁“拥有”什么,保留的CVE将上市DWF一旦CNA私下分配(如禁运问题)。理想一旦上市就会很快了公共与细节。

除了上述之外,另一个缓解可能建议必须重新CVE id。如果错误是后来发现漏洞,他们可以释放的CVE ID使用在后面的问题。我们也可以执行,必须报告他们的未使用的CVE id(即。那些未公开的CVE id)至少每年的CVE IDs可以拒绝为未使用的。CVE id可能有效地生活在中央社内,但它可以被认为是未使用的,被斜方如果不报道一个上游CNA和公开。

我们正在考虑开始讨论CNA-list从其他必须得到反馈,但是我们认为将由董事会第一次因为并不是每个人都在打电话。其他董事会反对允许必须灵活地分配CVE id作为提出了吗?

CVE团队

- - -

Kurt Seifried
kurt@seifried.org