再保险:CVE计算文件的草稿

我想让它更通用的:

疲弱的计算逻辑(例如,代码)- >系统中的弱点

如十字路口vulns意想不到的混合行为导致的一个问题。

在星期一,2016年8月29日,中午的12点棺材,克里斯<ccoffin@mitre.org>写道:

所有人,

哈罗德·布斯和我有几个私人交流关于CNA的脆弱性的定义计算文档。下面是当前帕斯卡提出的定义,以及两个最当前的迭代和哈罗德。第二句的区别显然是涵盖Kurt和帕斯卡原始评论。我想我们更倾向第二个版本,因为它保持关注的弱点方面的定义。任何想法都是非常赞赏。

# 0.1帕斯卡(当前定义)

”一个脆弱性CVE程序的上下文中,是用代码表示可以利用,造成负面影响机密性、完整性和可用性,需要一个编码变化,规范改变或规范缓解或弃用地址。”

# 1

“一个脆弱性CVE程序的上下文中,被定义为任何疲弱的计算逻辑(例如,代码)中发现的软件或硬件设备,可以利用威胁源,导致系统的安全产生负面影响。缓解在这种情况下通常涉及修改代码的漏洞,但也可能包括规范变化甚至规范不支持(例如,删除受影响的协议或功能全部)”。

# 2

“一个脆弱性CVE程序的上下文中,被定义为任何疲弱的计算逻辑(例如,代码)中发现的软件或硬件设备,可以利用威胁源,导致系统的安全产生负面影响。一个简单逻辑的例子一个弱点列表可以发现协议的规范,对一个算法的描述,设计或产品的架构,实现,电路设计或制造的产品。”

谢谢哈!

克里斯

来自:Kurt Seifried [mailto:kseifried@redhat.com]
发送:2016年8月25日,周四,下午一点十五分

:棺材,克里斯<ccoffin@mitre.org>
答:cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
主题:再保险:CVE计算文件的草稿

在星期四,2016年8月25日21点,棺材,克里斯<ccoffin@mitre.org>写道:

库尔特,

多谢反馈……我非常感谢它。

仅供参考……我没有考虑帕斯卡反馈在下面的评论,但我添加帕斯卡脆弱性的定义,我觉得效果很好。谢谢帕斯卡!


>我们可以添加“一般要求”吗?

我添加了一些文本的定义。看一看,让我知道如果这对你有用。

>能装置(供应商确认)被扩大到包括实际验证通过概念证明/再生器为例,或通过源代码考试吗?

我会关心在包含阶段把严格的验证要求。供应商必须,我认为他们将最有可能做一些或所有这一切,也许我们可以插入这个语言中提到它。但是,也可能有其他必须阅读这个决定不是产品的供应商或维护者/代码和组装这些数据或从供应商得到它需要时间,如果它发生了。我的感觉是,包含步骤应该强调速度分配CVE id而不是把事情完美。如果一个错误,它可以清理后的事实。想法吗?

对不起我意味着是或不是,例如有人发布的脚本崩溃Linux机器,我们还不知道为什么,我认为应该尽快反暴力极端主义。

> INC3.1“证明”,这意味着我们需要一个扬声器?

与上面类似,对于供应商CNA后这这可能不是太大的问题。CNA来说不是供应商或维护者,像你这样的,很明显,这一点将变得越来越重要。我认为你已经说自己收到很多垃圾。在我看来,“证明”是指可以请求者正确地描述了脆弱性和解释它的影响。我认为如果我们强迫请求者提供一个PoC我们可能要求太多在这个阶段。粗体文本状态,这一个是关于信任研究者声称在某种程度上。

好吧,只是想让阿舒瑞我们使用相同的“证明”的价值=)

> INC4:我们能更好的定义公共/私人吗?例如如果一个医疗设备制造商计划使用CVE为一个问题,然后他们会通知用户直接的?同上航空/ SCADA /等。

你是说我们应该减轻语言现在开始包括cf问题只会被释放的空间有限的用户组吗?我知道我们有这些讨论在最近的过去,但我的理解是,我们将使这种变化等到CVE实际上带来的这些领域会出现这个问题。

我认为我们需要开始看这个和准备好答案可能在今年或明年初,特别是如果我们想扩大CVE这些行业类型,我怀疑他们至少会有问题。

> INC5:“CVE id分配给产品customer-controlled或customer-installable。”前提方案上锁定呢?我知道很多医疗设备、高端制造、等你买它,但你不要碰它,公司技术服务。同上等其他监管项目电梯(合约地大多数电梯维护涉及到“如果有人但我们触摸它,你保证是完全空白”)。

这是一个非常好!这是另一个领域,我还没有把太多的心思,我不认为任何人在黑板上养育了在最近的过去。以外的“的”类似的SaaS(可能还有其他xaaS),我想可能有这产品(如家电等)现在或将来可能属于这一类。类似于上面的评论,我们应该占这个在目前的规则,或者我们应该等到面对这个问题,如当我们在医疗设备领域带来吗?

再一次以上,我认为我们应该看看这个和早有答案,而之后。

> CNT4:我想更好的定义嵌入代码的情况,例如libxml / gzip情况(比特的到处都是!)。

我注意到一件事就是决定语言没有直接CNA报告推迟到适当的CNA的共享代码库,并不适用于接收CNA(即。后,CNA决策基于报告)。你在找更多的过程解释在这种情况下或者更多的例子吗?如果你有什么具体的请随时传递。

比如代码从哪里“同一代码库”“不同的代码库”,例如mysql /各种叉,嵌入式X(例如gzip)的副本,我认为一个好的嗅测试是“补丁没有工作或最小变化”?

克里斯


来自:Kurt Seifried mailto:kseifried@redhat.com]
发送:星期三,2016年8月24日55点
:棺材,克里斯<ccoffin@mitre.org>
答:cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
主题:Re: CVE计算文件的草稿

一些反馈:
上下文中的一个漏洞CVE程序,是可以利用的代码,导致负面影响保密,完整性和可用性,需要一个代码更改来减轻或地址。
一些vulns内部协议和唯一的代码更改,“补丁”是完全删除代码/功能。我们可以添加“一般要求”吗?我担心软件/ API的交集vulns将越来越普遍(多个实例,和人们会开始寻找)。
能装置(供应商确认)被扩大到包括实际验证通过概念证明/再生器为例,或通过源代码考试吗?
INC3.1“证明”,这意味着我们需要一个扬声器?
INC4:我们能更好的定义公共/私人吗?例如如果一个医疗设备制造商计划使用CVE为一个问题,然后他们会通知用户直接的?同上航空/ SCADA /等。
INC5:“CVE id分配给产品customer-controlled或customer-installable。”前提方案上锁定呢?我知道很多医疗设备、高端制造、等你买它,但你不要碰它,公司技术服务。同上等其他监管项目电梯(合约地大多数电梯维护涉及到“如果有人但我们触摸它,你保证是完全空白”)。
CNT4:我想更好的定义嵌入代码的情况,例如libxml / gzip情况(比特的到处都是!)。










结婚,2016年8月24日下午19时,棺材,克里斯< mailto:ccoffin@mitre.org>写道:
所有人,

附件是一个新版本的CVE计数CNAs文档。我已经做了一些修改计算决策以及提供了一些澄清在某些决策基于CVE团队的反馈。

克里斯

来自:mailto:owner-cve-editorial -board-list@lists.mitre.org[mailto:mailto:owner-cve -editorial-board-list@lists。mitre.org)代表棺材,克里斯
发送:星期一,2016年7月25日5:03点
:cve-editorial-board-list < mailto:cve-editorial-board -list@lists.mitre.org>
主题:CVE计算文件的草稿

所有人,

很抱歉延迟,这些本该上周出去。

附件是最新的标记版本的简化计算规则,以及承诺非常粗略的版本的新CVE漏洞计数CNAs文档。仍有大量的工作要做在这个新文档,但是到目前为止主要开发决策树。包括决策树是为了取代老的决策树发现https://github.com/CVEProject/文档/团/ gh-pages / cna /application-guidance.md。

目前的想法是,“独立可以解决的”概念的引入,废止的许多老数决定,但我们有兴趣听听别人的意见。同样,包含规则实际上增长了一点,但这些似乎都是相当简单的。

报告类型决定是在内部讨论,对每个人都可能是新的。早期版本的文档没有良好的覆盖独立时如何计算可确定的导致没有或不确定。报告类型可以将普通的报告病例是在一种统一的方式来处理。这个想法是为了处理最常见的报告和建议为每个计算行动。我们绝对是兴趣倾听他人的想法全部计算决定,以及常见的报告和操作定义。

就像我之前说的,这是一个非常早期版本我开放给任何反馈。提前谢谢!

克里斯棺材
CVE团队




- - -

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

- - -

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

- - -

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