再保险:CVE托管服务

你好,我最近一直在思考很多关于分类法的攻击一个项目,只是CVE深交,所以如果这封邮件是随机的,我道歉。当我们创建了CVE,我们花了很多时间谈论fingerd。(我记得,这就是为什么CVD [atabase]成为了CVE)。戴夫·曼已经谈了很多关于博物馆展览的例子,和它的创造者受益于能够点鸟。我想鼓励你去创建一个动物园:一组问题,可以有效的辩论,看看,这些问题收集,你可以找到共同点,比如汤姆下面的建议。最好,亚当在星期一,2017年2月27日在11:52:02PM + 0000,米勒,托马斯写道:|我认为这(使用一个离散的、特定的块的vulns服务)|可用的中间地带,也许。| |我认为cf的应该明确的区分,不能处理|除了由服务提供者,基本上,可能是因为我一直说话|太多的人来说,cf =审计发现。| | | |汤姆米勒,us - cert | |从+ 1-202-631-1915 |https://www.us-cert.gov| |━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━|:owner-cve-editorial-board-list@lists.mitre.org代表威廉姆斯肯|发送:周六,2月25日2017 1:53:07感到|:耶利哥;棺材,克里斯| Cc: cve-editorial-board-list |主题:RE: 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] >发送:2月24日,星期五,2017年下午4:30 | >:棺材里,克里斯< ccoffin@mitre.org > | > Cc: cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org > | >主题:RE: CVE托管服务| >重要性:高| > | >我说这所有的虚拟强调我所能。我不会| >认为如果横切跟踪在线服务CVE-style能力| >今天对或错的事。但我想说,如果你这样做……| | > >没有,味道中,使用“CVE”作为ID计划的一部分。| >绝对没有逻辑或有益的理由这样做。| | > >——CVE支持两个前缀计划十年(CVE和可以)。| >——许多组织将不希望跟踪在线服务,以及混合| >会非常痛苦的覆盖率(指标|百分比)等。| >——一些组织可能更感兴趣的是云/服务提供跟踪| >(如公司存在多云服务本身)| >——无数vuln游客(个人和企业)做| >年度统计数据完全基于CVE和不理解CVE | >这将永远使所有数据生成完全没有价值。我| >的意思是,他们已经一文不值,但这将使它更甚。| >,我有没有提到没有合乎逻辑的理由把它们混合在一个统一的CVE | >标识符?=)| | > >我一直直言不讳地批评斜方和CVE很久了。 I have | > spent a LOT more of that time trying to help via the board and behind the | > scenes. If MITRE opts to mix and not use diffferent prefix schemes, I | > fully believe that will be the biggest mistake MITRE has ever made in the | > 17+ years of maintaining the CVE project. | > | > .b | > | > p.s. This is coming from one of the few people who were strenously against | > the CNA/CVE prefix split and put significant pressure on MITRE to unify | > that. | > | > | > On Fri, 24 Feb 2017, Coffin, Chris wrote: | > | > : The CVE Team has discussed the inclusion of hosted service | > : vulnerabilities within the CVE program on multiple occasions in the | > : past. However, a decision was never made on how to proceed. The CVE | > : Board call on Feb 22 included a very informative and useful discussion | > : regarding this topic, and we feel this topic needs to move forward. | > : Based on Harold's valid use case, input from other Board members, and | > : the fact that more and more software is being offered via hosted | > : services, the CVE Team believes that these vulnerabilities should be | > : assigned CVE IDs and we have no objections in supporting these under the | > : CVE program. | > : | > : We believe that there are still decisions to be made on what kinds of | > : use cases should be supported, but these can continue to be identified | > : and discussed on the CVE Board list. Once we have agreement on a valid | > : set of use cases, the CVE Team and Board can decide on any needed rules | > : and guidelines. At that point, we believe that the best option would be | > : to pilot the idea through one or more of our existing CNAs who also | > : maintain hosted services. If anyone has any additional suggestions or | > : comments on a way forward then please offer them up. | > : | > : To answer the specific questions regarding the determination of risk | > : based on CVE, we agree with Art that CVE is the first step in the | > : process and should only be responsible for starting the conversation | > : (i.e., naming the thing). Other organizations can add additional value | > : on top of this, such as risk scores, mitigations, etc. -- Don't miss out on my news, which comes out roughly once a quarter.http://adam.shostack.org/newthing.html