再保险:CVE托管服务

我认为这(使用一个离散的、特定的块的vulns服务)是一个有用的中间地带,也许。

我认为一个清晰的区别应该为cf,不能处理除了由服务提供者,基本上,可能是因为我一直跟太多的人来说,cf =审计发现。



us - cert汤姆•米勒

从+ 1-202-631-1915
https://www.us-cert.gov

---

来自:owner-cve-editorial-board-list@lists.mitre.org代表威廉姆斯,肯
发送:2017年2月25日,星期六,1:53:07
:耶利哥;棺材,克里斯
答:cve-editorial-board-list
主题:再保险:CVE托管服务

或者我们可以保持CVE前缀就分配一个公开定义的
块在线服务,SSN用于映射
领先的3位数的地理区域,或CC公司处理
领导/ BIN 6位数的射程。

使用CVE前缀的所有漏洞,无论是在软件和
在服务中,不一定是一个问题。逻辑上是有意义的
因为它属于一个漏洞识别号码。

问候,
千瓦

> - - - - - - - - - - -原始消息
>:owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve -
> editorial-board-list@lists.mitre.org]代表耶利哥
>发送:星期五,2017年2月24日下午4:30
< ccoffin@mitre.org > >:棺材,克里斯
>答:cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org >
>主题:RE: CVE托管服务
>重要性:高
>
>我说这所有的虚拟强调我所能。我不会
>认为如果僧帽跟踪CVE-style能力的在线服务
>今天对或错的事。但我想说,如果你这样做……
>
>没有,味道中,使用“CVE”作为ID计划的一部分。有
>完全没有逻辑的或有益的理由这样做。
>
> (CVE支持两个前缀计划十年(CVE和可以)。
>——许多组织将不希望跟踪在线服务,并将混合它们
>让很痛苦的“覆盖(指标|百分比)”等。
>——一些组织可能更感兴趣的是云/服务提供跟踪
>(如公司存在多云服务本身)
>——无数vuln游客(个人和企业)
>年度统计数据完全基于CVE和不理解CVE,
>这将永远使所有数据生成完全没有价值。我
>的意思是,他们已经一文不值,但这将使它更甚。
>,我有没有提到没有合乎逻辑的理由把它们混合在一个统一的CVE
>标识符?=)
>
>我一直直言不讳地批评斜方和CVE很久了。我有
>花了更多的时间试图通过背后的董事会和帮助
>场景。如果斜方选择混合,而不是使用不同的前缀计划,我
>完全相信将是最大的僧帽曾经所犯的错误
> 17 +年的维护CVE项目。
>
>。b
>
>注。这是来自为数不多的人强
> CNA / CVE前缀分裂和斜方统一都将承受巨大的压力
>。
>
>
>在星期五,2017年2月24日,棺材,克里斯写道:
>
>:CVE团队讨论了包含托管服务
>:在CVE漏洞程序在多个场合
>:过去。然而,从来没有做出决定如何继续。的CVE
>:董事会称在2月22日包括内容非常丰富和有用的讨论
>:关于这个话题,我们觉得这个话题需要前进。
>:基于哈罗德的有效用例,输入来自其他董事会成员和
>:通过举办提供越来越多的软件
>:服务,CVE团队认为,这些漏洞
>:分配CVE id和我们没有反对在支持这些
>:CVE程序。
>:
》:我们相信仍有决定了什么样的
>:用例应该支持,但是这些可以继续被识别
>:CVE董事会和讨论列表。一旦我们有了一个有效的协议
>:用例,CVE团队和董事会可以决定在任何需要的规则
>:和指导方针。在这一点上,我们相信最好的选择
>:飞行员的想法通过一个或多个现有CNAs也
>:维护托管服务。如果谁有任何额外的或建议
>:评论一个前进的请提供。
>:
>:回答特定的问题关于风险的决心
>:基于CVE,我们同意艺术CVE的第一步
>:过程和应该只负责启动对话
>:(即。命名的)。其他组织可以添加额外的价值
>:除此之外,如风险评分,移植等。