再保险:CVE-CNA JSON格式的建议

在星期一,2017年3月27日下午5:01,棺材,克里斯<ccoffin@mitre.org>写道:

首先,一些思想定义。我不确定每个人都说同一种语言。

指定人:组织或个人分配一个ID CVE漏洞。组织可能有也可能没有发现了漏洞。默认情况下,CVE CNA的指定人只要他们使用了CVE ID分配块。DWF导师可能是一个特殊的例外。

啊要明确主要有三个选项”,“CVE来自:

1)主要DWF池——“零售CVE请求”,DWF CVE-Mentor可以签署CVE请求,然后传递到DWF,作业的优势可以很快发生,因为请求签署了(因此至少在理论上是正确的)

2)DWF CNA池——“CNA使用CVE导师”请求,例如一个开源项目有一个专用的CVE导师(s),并已足以让自己CVE块(例如Kubernetes在不久的将来我希望)从项目池(CVE)

3)“像CNA CVE导师”,所以CVE导师也可以有一个CVE块(例如Josh医学),并分配CVE的东西没有一个CNA有关。(所以CVE的CVE导师个人池)

在所有3例指定人的CVE导师签署了请求,和# 2的CVE池可以使用不同的CVE导师个人池(例如如果拉里,一个人CNA签署了一次请求Kubernetes Kubernetes有自己的CVE块)。

基本上任何迹象在JSON /请求被“正确”是指定人,还要注意这可能是(如一个组织的作用。secalert@redhat.com例如)而不是一个独特的个体。

来源:组织或个人报告的细节漏洞和请求CVE ID。源报告细节和要求尽管CNA的CVE ID,或者在某些情况下可能是CNA本身如果发现内部。同时,这将匹配的发现者脆弱性。

源容器有两个字段,例如:“源”:{

“DATA_VERSION”: XYZ,

“DISCOVERED_BY”: XYZ,

“DISCOVERED_WITH”: XYZ,

“验证”:XYZ,

“CNA_CHAIN”:(

“字符串初始CNA”,

“父CNA字符串”,

根“中央社”

]

}

所以CNA_CHAIN,。DISCOVERED_BY将实体的数据,等等。

指定人,斜方已经有了今天这个信息基于提供的细节。我们就没有问题表明最小内的指定人需要的格式。的原因可能包括以下项目符号列表。

- - - - - -对当前用例的目的,必须与斜方分享JSON数据意味着分配人总是CNA。对吧?

从DWF的角度来看:没有。CNA只是定义为:一个实体,已同意遵守CNA规则,并且是CVE导师(例如,一个人如拉里Cashdollar或Josh医学)或有一个或多个CVE导师(可以是专用的,或共享)签署CVE请求,换句话说他们或有人在CVE作业训练。他们将几乎总是有自己的CVE块(但这并不一定是要求)。

- - - - - -斜方已经记录的电子邮件地址必须现在,但不会认为它会是非常困难的,必须包括CNA名称和电子邮件在任何提交。

很明显当你说CNA的名字意味着实体的名称,这可能是一个名字像拉里•Cashdollar或实体,像“红帽”?

- - - - - -建议由库尔特,指定人信息可以自动创建为提交CNAs用任何工具

反暴力极端主义的来源也会有趣的获得,但我们可能不总是因为一些可以选择匿名来源。同时,在当前用例CNA提交斜接,我不认为这是一个要求,虽然我当然愿意在他人的意见。我不确定我们想要源电子邮件或名单,因为这可能会难以维护在某些情况下(例如,谁发现了一个漏洞,纠纷等)。

所以DISCOVERED_BY例如可以是匿名的。但CNA_CHAIN数据例如应该是正确和完整的(当然我可以想象角落的情况下最终CNA希望/需要匿名,但CVE ID是一个赠品,所以我猜他们必须做一个请求通过DWF真正的匿名)。

一个想法是,我们可以简单地试图理解源是否影响软件维护人员和其他人。好处请求这些信息将提供一种有效性检查的漏洞及其细节。CNA冠冕,如果提供的漏洞是CNA还有一定程度的信任。而随机研究报告的漏洞的横切web表单可能没有相同级别的信任。想法吗?

CNA_CHAIN数据的优势,你知道CNA分配它,可以很容易地确定自己的或人基于他们的声明数据吧。

艺术:你没事吧,前进,如果我们一定要包括分配人最低JSON格式的一部分吗?

克里斯

来自:owner-cve-editorial-board -list@lists.mitre.org[mailto:owner-cve-editorial -board-list@lists.mitre.org]代表Kurt Seifried
发送:周三,2017年3月22日还有3点
:马尼恩艺术<amanion@cert.org>
答:布斯,哈罗德(美联储)<harold.booth@nist.gov>;cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
主题:再保险:CVE-CNA JSON格式的建议

理论上我认为是的,因为:

源是自动创建的,如链中的每个CNA适用他们的来源。

DWF世界至于分配人,我们使用git提交签署和/或签署了JSON文件(这样你可以创建一个JSON文件,坐在被禁运的情况下,然后提交自动化处理),所以它必须签字的人是一个有效的CVE导师(因为我们需要证明它是从哪里来的),所以,数据自动收获/添加到条目(一旦我们得到自动化)。

2017年结婚,3月22日下午1:45,马尼恩艺术<amanion@cert.org>写道:

在3/22/17下午3:31,Kurt Seifried写道:
>所以DWF需要指定人,理想情况下也
>
>“源”:{

同样的问题然后来源。要指定人和源
最低CVE条目吗?

我真正感兴趣的是谁分配条目(和可能
负责任的如果有问题)和(最佳合理可用)
公共参考来源。

也许我想的是一个单独的或特殊情况
“引用”,或者至少条目必须包含至少一个公众
“引用”的脆弱性来源。

——艺术

2017年>结婚,3月22日下午12:52,马尼恩艺术<amanion@cert.org
> < mailto:amanion@cert.org> >中写道:
>
>要指定人作为最小的一部分例子吗?我想说的
>是的。
>
>指定人目前一个电子邮件地址,它应该是一个CNA的名字吗?我
>说也许,有人将电子邮件地址映射到美国。
>
>——艺术
>
>
>
>
>——
> Kurt Seifried
>kurt@seifried.org< mailto:kurt@seifried.org>

- - -

Kurt Seifried
kurt@seifried.org

- - -

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