回复：CVE计数文件的粗略草稿

2016年8月29日星期一，下午1:10，Pascal Meunier<pmeunier@cerias.purdue.edu>写道：

更改为＃1和＃2，甚至随着Kurt提出的其他变化（“系统中的弱点”）的变化将大大增加CVE的范围。例如，CNA将发布CVE的任何易受“行锤效应”的硬件，而不仅仅是特别脆弱的软件（例如CVE-2015-0565）。这可能会造成IDS请求的爆炸，因为某些硬件组合可能会使情况变得更糟或更好 - 我们会跟踪所有组合吗？接下来，我们将获得超频硬件的ID请求（如果允许超频）或在边界或异常温度下的硬件，肮脏的硬件，BrownOuts下以及每个悬挂，崩溃或重新启动的设备，因为它可能表示脆弱性。有普通芯片的董事会会在同一CVE ID下分组吗？与众不同，因此您将发行2或2000个不同的ID？我认为，计数文档无法解决硬件。看来我们几乎跌跌撞撞，现在我们想解决一场战斗机。

太快的变化可能是灾难的秘诀，或者至少是混乱和不足。我建议自己有点步调（双关语），等到最近的变化才证明自己可行，稳定，然后再改变范围。至少，该项目范围的变化应该是计划和直接决定的，而不是偶然地修改定义。

作为一个非常小的措辞评论，与上述内容相比很少，我认为“由威胁来源”包含，无济于事，也可以被删除。

一些评论：

1）使用SWID将有助于减轻许多与识别有关的问题

2）我们总是可以拥有“协议”级别的CVE，Rowhammer似乎是该类型类型的良好候选人

3）人们必须要求这些CVE/想要创建它们，我们不必说是，或者我们只需要一个非常完美的请求（例如，详细信息，Swid等），因此“成本很少”“分配CVE

至于BrownOut的内容，我将其放入与“程序打开文件并崩溃”的同一类中/如果您希望它的表现正确，请在烤箱中煮”，我还要说，这些东西已经在大多数电子设备记录的操作条件下已经得到很好的覆盖/记录（例如，非凝结湿度，以及它将在其上运行的温度）。

帕斯卡



克里斯（Chris）在2016年8月29日下午02:01写道：

全部，

哈罗德·布斯（Harold Booth）和我进行了几次有关CNA计数文件漏洞定义的私人交流。以下是帕斯卡尔（Pascal）提出的当前定义，以及哈罗德（Harold）和我的两个最新迭代。显然，第二句话涵盖了Kurt和Pascal的原始评论。我认为我们更倾向于第二版，因为它一直集中在定义的弱点上。对此的任何想法将不胜感激。

＃0.1（Pascal的当前定义）
“ CVE程序上下文中的漏洞是由可以利用的代码指示的，从而对机密性，完整性或可用性产生负面影响，并且需要进行编码更改，规范更改或规范贬值以减轻或地址。透明

＃1
“ CVE程序上下文中的漏洞被定义为在软件或硬件设备中发现的计算逻辑（例如代码）中的任何弱点，可能会被威胁源利用，并对安全性产生负面影响系统。在这种情况下，缓解漏洞通常涉及编码更改，但还可能包括规范更改甚至规格折旧（例如，删除受影响的协议或全部功能）。”

＃2
“ CVE程序上下文中的漏洞被定义为在软件或硬件设备中发现的计算逻辑（例如代码）中的任何弱点，可能会被威胁源利用，并对安全性产生负面影响系统。可以在逻辑上找到弱点的示例的非竭力清单，是在协议的规范中，算法的描述，产品的设计或架构，实现，电路布局或产品的制造。”

谢谢哈罗德！

克里斯

来自：Kurt Seifried [Mailto：kseifried@redhat.com这是给予的
发送：2016年8月25日，星期四1:15 pm
到：棺材，克里斯<ccoffin@mitre.org>
CC：CVE-编辑板列表<cve-editorial-board list@lists.mitre.org>
主题：回复：CVE计数文件的粗略草稿



2016年8月25日，星期四，上午10:21，Coffin，Chris <ccoffin@mitre.orgCCOFfin@mitre.org>>写道：
库尔特，

感谢您的反馈...我非常感谢。

仅供参考...在下面的评论中我没有考虑到Pascal的反馈，但是我添加了Pascal对脆弱性的定义，因为我认为它的效果很好。谢谢帕斯卡！

我们可以添加“通常需要”吗？

我在定义中添加了一些文本。看看，让我知道这是否适合您。

可以扩展Inc2（供应商确认）以通过概念证明/复制器或通过源代码检查包括实际验证？

我将担心在包容阶段提出严格的验证要求。对于供应商CNA，我认为他们很可能会做一些或全部，也许我们可以在这里插入此语言。但是，也可能会有其他CNA阅读此决定，而不是产品/代码的供应商或维护者，也不是该数据或从供应商那里获取该决定，如果它完全发生，可能会花费时间。我的感觉是，包容性步骤应强调分配CVE ID的速度，而不是前面使事情变得完美。如果犯了错误，则可以在事实后清理。想法？

对不起，我的意思是或不，例如有人发布了撞车机器的脚本，我们还不知道为什么要尽快获得CVE。

inc3.1“证明”这是否意味着我们需要一个复制品？

与上述类似，对于此后的供应商CNA而言，这可能不是很多问题。对于不是供应商或维护者（例如您自己）的CNA，这显然变得更加重要。我想您已经说过自己已经有很多垃圾了。在我看来，“演示”意味着请求者可以正确描述脆弱性并解释其影响是什么。我认为，如果我们强迫请求者提供POC，我们可能在此阶段要求太多。正如粗体文本所述，这是关于在一定程度上信任研究人员的主张。

好的，只是想让ASURE我们使用相同的“演示” =的值

inc4：我们可以更好地定义公共/私人吗？例如。如果医疗设备制造商计划将CVE用于一个问题，然后他们将直接通知用户？同上航空航天/SCADA/等。

您是说我们现在应该软化语言以开始包括CVES问题的空间，而CVE问题只会发布给有限的用户？我知道我们在最近的过去进行了这些讨论，但是我的理解是，我们要等待这种变化，直到CVE实际带来了这些问题将出现的一些领域。

我认为我们需要开始研究这一点，并准备在明年年初或明年年初回答，尤其是如果我们想将CVE扩展到这些行业类型，因为我怀疑他们至少会有疑问。

INC5：“ CVE ID分配给了由客户控制或客户安装的产品。”锁定的房屋解决方案呢？我知道您购买的许多医疗设备，高端制造等，但是您不会触摸它，公司技术服务。同上其他受监管的物品，例如电梯（从合同上大多数电梯维护中，除了我们以外的任何人触摸它，您的保修，您的保修完全无效”）。

这是一个很棒的观点！这是我并没有真正考虑过的另一个领域，我认为董事会上的其他人都没有在最近的过去提出。除了SaaS（可能还有其他XAA）的“类似”的“类似”思想之外，我想现在或将来可能会生产出IT产品（例如，电器等），可能会属于这一类别。但是，与上述评论类似，我们应该在当前规则中考虑到这一点，还是应该等到出现此问题，例如当我们带上医疗设备域名？

同样，我认为我们应该研究一下，然后更早地得到答案。


> CNT4：我想更好地定义嵌入式代码情况，例如libxml/gzip情况（这些地方无处不在！）。

我注意到的一件事是，在不适用于接收CNA的共享代码库的情况下，决策语言没有指示CNA将报告推迟到适当的CNA（即，基于决策的CNA（即，基于决策）报告）。您是在寻找这种情况下的更多流程说明还是更多示例？如果您有具体的内容，请随时通过。

因此，例如，代码从“同一代码库”移动到“不同的代码库”，例如mySQL/各种叉子，X的嵌入式副本（例如GZIP），我认为一个很好的嗅探测试是“该补丁程序是否无需更改或最小更改”？



克里斯


来自：Kurt Seifried [Mailto：kseifried@redhat.comAilto：kseifried@redhat.com>]]
发送：2016年8月24日，星期三下午3:55
到：棺材，克里斯<ccoffin@mitre.orgCCOFfin@mitre.org>>
CC：CVE-编辑板列表<cve-editorial-board list@lists.mitre.orgcve-editorial-board-list@lists.mitre.org>>
主题：回复：CVE计数文件的粗略草稿

一些反馈：
CVE程序上下文中的一个漏洞是可以利用的代码，从而对机密性，完整性和可用性产生负面影响，并且需要更改代码以减轻或地址。
某些漏洞是协议内部的，而“修复”的唯一代码是完全删除代码/功能。我们可以添加“通常需要”吗？我担心软件/API漏洞的交集将变得越来越普遍（更多的实例，人们会开始寻找它们）。
可以扩展Inc2（供应商确认）以通过概念证明/复制器或通过源代码检查包括实际验证？
inc3.1“证明”这是否意味着我们需要一个复制品？
inc4：我们可以更好地定义公共/私人吗？例如。如果医疗设备制造商计划将CVE用于一个问题，然后他们将直接通知用户？同上航空航天/SCADA/等。
INC5：“ CVE ID分配给了由客户控制或客户安装的产品。”锁定的房屋解决方案呢？我知道您购买的许多医疗设备，高端制造等，但是您不会触摸它，公司技术服务。同上其他受监管的物品，例如电梯（从合同上大多数电梯维护中，除了我们以外的任何人触摸它，您的保修，您的保修完全无效”）。
CNT4：我想更好地定义嵌入式代码情况，例如libxml/gzip情况（这些地方无处不在！）。










2016年8月24日，星期三，下午2:19，棺材，克里斯ccoffin@mitre.org<邮件到：ccoffin@mitre.org>>写道：
全部，

附件是CNAS文档的CVE计数的新版本。我已经对计算决策进行了一些更改，并根据CVE团队的反馈提供了一些澄清。

克里斯

来自：mailto：所有者cve-editorial-board-list@lists.mitre.org：所有者cve-editorial-board-list@lists.mitre.org> [mailto：mailtomailto>：：所有者cve-editorial-board-list@lists.mitre.org所有者-cve-editorial-board-list@lists.mitre.org>]代表棺材，克里斯
发送：2016年7月25日，星期一下午5:03
到：cve-editorial-board list CVE-EDITORIAL-BOARD-LIst@lists.mitre.orgCVE-editorial-board-list@lists.mitre.org>>
主题：CVE计数文件的粗略草稿

全部，

抱歉，这些延迟应该上周出去。

附件是简化计数规则的最新标记版本，以及CNAS文档的新CVE漏洞计数的非常粗糙的版本。在这份新文档上仍然有很多工作要做，但是到目前为止，主要的重点是开发决策树。包含的决策树旨在替换在https://github.com/cveproject/DOCS/BLOB/GH-PAGES/CNA/申请tion-guidance.md。

当前的想法是，引入了“独立固定”概念的引入，这涉及许多较旧的计数决定，但我们很想听听其他人对此的看法。同样，包含规则实际上也有所增长，但所有这些规则似乎都很简单。

报告类型的决策是在内部讨论中出​​现的，可能是每个人的新事物。较早的DOC版本对如何计数时没有良好的覆盖范围。报告类型允许以某种统一的方式处理常见的报告案例。这个想法是处理最常见的报告和每个人的建议计数动作。我们绝对有兴趣听到其他人对整个计数决定以及定义的共同报告和行动的想法。

就像我之前说的那样，这是一个非常早的版本，所以我对所有反馈都开放。提前致谢！

克里斯·科芬
CVE团队




- -

- -
Kurt Seifried-红色帽子 - 产品安全 - 云
PGP A90B F995 7350 148F 66bf 7554 160d 4553 5E26 7993
红帽产品安全联系人：Mailto：secalert@redhat.comLTO：secalert@redhat.com>



- -

- -
Kurt Seifried-红色帽子 - 产品安全 - 云
PGP A90B F995 7350 148F 66bf 7554 160d 4553 5E26 7993
红帽产品安全联系人：secalert@redhat.com秒alert@redhat.com>

- -

- -
Kurt Seifried-红色帽子 - 产品安全 - 云
PGP A90B F995 7350 148F 66bf 7554 160d 4553 5E26 7993
红帽产品安全联系人： secalert@redhat.com