“来源“:{ | |
“data_version“:“3.0“,,,, | |
“dissiveed_by“:“细绳“,,,, | |
“discusiged_with“:“细绳“,,,, | |
“确认“:“细绳“,,,, | |
“CNA_CHAIN“:[[ | |
“字符串初始CNA“,,,, | |
“字符串母体CNA“,,,, | |
“弦根CNA“ | |
这是给予的 | |
} |
首先,对定义的一些想法。在这种情况下,我不确定每个人是否会说相同的语言。
分配者:将CVE ID分配给漏洞的组织或个人。组织可能会发现也可能没有发现漏洞。默认情况下,每当他们使用分配的块中的CVE ID时,CVE CNA都会成为分配者。DWF导师可能是一个特别的例外。
资料来源:报告漏洞详细信息并要求CVE ID的组织或个人。消息来源将报告详细信息,并索取CVE ID,但在某些情况下可能是CNA本身,如果在内部发现。另外,这将与漏洞的发现者相匹配。
对于分配者,MITER今天已经根据谁提供详细信息提供了此信息。我们没有提出最小格式中要求分配者的问题。推理可以包括下面的项目符号列表。
-出于当前用例的目的,CNA与MITER共享JSON数据意味着分配程序始终是CNA。正确的?
-MITER现在已经跟踪CNA的电子邮件地址了,但是在未来的任何提交中,CNA都不会有CNA在CNA中包括CNA名称和电子邮件。
-正如库尔特(Kurt
CVE的来源也很有趣,但是我们可能并不总是能得到这个,因为某些消息来源可能会选择保持匿名。另外,在当前将CNA提交给MITER的用例中,我目前尚不认为这是一项要求,尽管我肯定对其他人愿意。我不确定我们是否想实际列出源电子邮件或名称,因为在某些情况下这可能很难维护(例如,关于谁发现漏洞等的争议等)。
一个想法是,我们可以只是尝试了解源是否是受影响的软件维护者与其他人。请求此信息的好处在于为漏洞及其详细信息提供一种有效性检查。对于MITER CNA,如果CNA提供了漏洞,则具有一定的信任。尽管随机研究人员向MITER Web表格报告的漏洞可能没有相同的信任。想法?
艺术:如果我们只是确保将分配者作为最低JSON格式的一部分,您可以向前迈进吗?
克里斯
从:所有者cve-editorial-board-
list@lists.mitre.org [Mailto:所有者cve-editorial-board-list@lists.mitre.org 这是给予的代表Kurt Seifried
发送:2017年3月22日,星期三,下午3:02
到:艺术马尼昂<amanion@cert.org>
CC:布斯,哈罗德(美联储)<harold.booth@nist.gov>;CVE编辑板列表<cve-editorial-board-list@lists.mitre.org >
主题:回复:CVE-CNA JSON格式提案
从理论上讲,我会对两者都说是因为:
源是自动创建的,例如链中的每个CNA都应用其来源。
至于分配者,在DWF世界中,我们使用签名的git consits和/或签名的JSON文件(因此您可以创建一个JSON文件并坐在其上以进行禁运,然后提交以进行自动处理),因此必须签署它由有效的CVE导师的人(因为我们需要证明其来自何处的证明),因此再次将数据自动收获/添加到条目中(一旦我们获得自动化)。
在2017年3月22日星期三,下午1:45,艺术品<amanion@cert.org>写道:
库尔特·塞弗里德(Kurt Seifried)在17年3月22日下午3:31写道:
>因此,DWF将需要分配者,理想情况下也需要
>
>“源”:{
来源相同的问题。应该需要分配者和来源
在CVE最小条目中?
我真正感兴趣的是谁分配了该条目(而且很可能
如果有问题)和(最好合理可用)
来源公众参考。
也许我想的是一个单独或特殊情况
“参考”或最低条目必须至少包含一个公众
漏洞的源“参考”。
- 艺术
>在2017年3月22日星期三,下午12:52,艺术品<amanion@cert.org
>amanion@cert.org>>写道:
>
>作为最小示例的一部分,是否需要分配者?我会说
>是。
>
>分配者当前是一个电子邮件地址,应该是CNA名称吗?ID
>说,也许,否则就必须将电子邮件地址映射到CNA。
>
> - 艺术
>
>
>
>
> -
> kurt seifried
>kurt@seifried.orgkurt@seifried.org>
- -
Kurt Seifried
kurt@seifried.org