再保险:CNA规则公告

在星期二,2016年10月11日上午10:30,孩子叫Nandakumaraiah<cbn@juniper.net>写道:

10/11/16 46点,展台,哈罗德(美联储)写道:
> (HB)我认为你指的是提交CVRF成绿洲,和即将到来的修订。

是的。

> CVRF修订进入绿洲是专门关注创建一个咨询格式而不是脆弱的格式。就我个人而言,我希望它是否则,但那是发达的共识在TC的发展建议。仍然是需要有漏洞的某种特定格式交换漏洞信息,希望可以使用相同的词汇,它是有用的。

通常使用的短语“脆弱性报告”或在相关
ISO标准是指被发现者用来描述
漏洞和发送给供应商或用户。

这个名字CVRF隐含比预期范围有限。这是纠正在
TC提交会议。“咨询”有更多的围绕的范围:
可以是一个漏洞报告,通知有关漏洞
或不修复,对安全相关但non-vulnerability修复。
没有绿洲的提议,防止研究员
使用CVRF来描述一个漏洞。

作为一个供应商或漏洞发现者,我可以共享的关键信息
在拟议的CVE信息格式或CVRF(或新版本)
本质上是相同的。因此这个请求不创建一个重复的
格式编码相同的内容。

>如果CVE使用CVRF则有必要开发一个CVE的特定配置文件中每个人都需要采用。也,因为口味的变化和当前实践,JSON是或成为许多人的首选数据交换语法(NVD接收请求经常为我们实现JSON),我认为这是可能需要考虑,但我同意,使用一个公共字典/分类/本体结合多种格式是必须的。

我完全同意CVRF急需修订——简化
而。CVRF提供字典的键值,或结构
的构思。一个应该能够表达这种在其他结构化的格式
像JSON在不牺牲机器可读性。我将亲自
喜欢一只手可编辑的格式类似于HTTP协议像语法
建议在附录B——这应该很容易嵌入到邮件,
web页面,提交信息,改变日志等,消除一个巨大的障碍
对小型或开源供应商条目。

你怎么认为的

https://github.com/distributedweaknessfiling/DWF-Database-Artifacts/blob/master/JSON-file-format.md

主要观点:

“协议”版本以及实际的特定部分。主要版本(如1.0,1.1,1.2,1.3,等等)是保证向后兼容,例如我刚刚更新了协议1.2,因为我SWID字段添加到受灾地区。这是因为在某种程度上我们会有数千或数万版本1的cf。x数据,我2。x版本的数据可能不是向后兼容的。没有人想要更新,旧的数据。

协议是基于JSON和可以包含典型的JSON类型,和文本,指向其他文件在某些领域(如工件)。长期的我想找一个更好的方法来附加/嵌入数据影响的事情(比如SWID)。

数据有4个主要部分:

1)DWF:这是强烈的控制数据,定义良好的、结构化

2)供应商:这实际上是一份DWF部分,但从本质上说,供应商可以提交任何他们想要的

3)社区:这个区域将与规则、准则和最终可能还不确定

4)实验:你认为什么是一个实验性的部分。

我打开反馈/改进,我猜2。x版本将会完全不同(如果没有,那么我们失败了)。

谢谢,
的孩子叫

- - -
安全应急响应小组
瞻博网络

- - -

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