CVE回顾会议(周四)——总结

:这是一个高级的总结今天的会议,我认为这就很好。令人惊奇的会发生什么当你让人们说在一起在一个房间:)有很多富有成效的反馈。更多细节将在这些讨论之际,我们的行为,如通过内容决定投票,但世界性的反馈是受欢迎的。Non-MITRE与会者安德烈·弗雷希,迈克·普罗塞和比尔Fithen和克雷格•Ozancin通过电话会议。与会者在不同时期被戴夫·曼冠冕,史蒂夫•Christey玛吉祖克,戴夫•戈德伯格(观察者),比尔•希尔和戴夫·贝克。我们开始与原有的提醒(继续)目标CVE独立的多个角度,使用,作为理由的“包容性”脆弱性定义CVE用途。出席的董事会成员是支持这个概念。我们还讨论了一些我们面临的更广泛的挑战。我们主要有良好的响应处理脆弱性的定义问题,建议使用CMEX "普遍"属性。虽然这不会让每个人都高兴,这是一个合理的妥协。 There was also agreement on the use of dot notation, and addressing high cardinality in a reasonable fashion. The implementations still need to be worked out a little bit, but I believe we've got enough of a solid basis for being able to move forward on these issues. We spent a lot of time on the EXCLUSION content decisions. The shortest summary is, the group agreed that EX-BETA, EX-BRUTE, and EX-CLIENT are too restrictive, especially in the broader context of the "inclusive" (more general) vulnerability definition. I will be putting these content decisions up for a vote, but it appears that they will be REJECTed, or heavily modified. While there isn't a specifically named content decision for privacy issues, they will likely also remain in the CVE, as they're extremely important in an e-commerce context. There was a lot of discussion on the validation of vulnerabilities as well. It's clear that for a candidate to be accepted into the CVE, its existence will have to be sufficiently proven, e.g. by being validated by several Board members. In the cases where the details of a vulnerability are not publicly known, it's possible that more secure discussion channels might be useful to allow Board members to share enough information to sufficiently validate something. However, this goes against the notion of a fully public discussion of vulnerabilities, so the issue of private channels needs more consideration. I discussed my rationales for the simplified "model" of configuration problems, and there seemed to be general agreement that it was a reasonable first step. I think it's becoming clear to everyone that we need better language to effectively describe configuration problems, but at least the simplified model is a start. While discussing the content decision voting process, it was agreed that it is not sufficient to go public with only 93 vulnerabilities that have been accepted into the "real" CVE. It was agreed that 300 vulnerabilities was a reasonable goal. However, this places pressure on us to resolve the active content decisions, so proposal and voting will being early next week, with an interim decision scheduled for August 23. We then discussed the idea of the CVE Interoperability Demo. Nobody liked the "CID" acronym, so we're looking for something better. Each attendee saw a roles that they could play within the demo. I believe it is flexible enough to accommodate all participating Board members. We discussed what the initial "demo" for the big CVE splash at SANS-NS might look like. It became clear that we need to act on this idea quickly, in order to get marketing departments involved and to refine the scenario enough for an effective presentation at SANS. During the day, I had a separate meeting with Mike Prosser, and another with Andre Frech, to discuss their tools and the CVE mappings that I created. I compared the tool to the CVE, to an abstraction of the tool's "competition," and to a set of exploits accessible on various hacker sites. I believe that actually seeing the mappings helped them to understand some of their power (and the implications). I think it also helped to see how vendors' "numbers games" could be filtered through the CVE - and some of the limitations of that filter. It will be very interesting to compare tools and databases using real, validated mappings. - Steve