[CVEPRI]添加CVE信心水平

,这是一个长长的电子邮件的背景。简短的故事是,我建议每个CVE候选人或条目,我们记录的自信程度,CVE物品是真实的。这种方法可以解决许多问题,影响了CVE倡议。你们很多人都知道在过去的几个月里,从编辑委员会讨论不同的董事会成员想要不同的东西从CVE的质量和准确性(回忆一些讨论董事会名单在今年夏天,以及各种董事会会议)。一个阵营希望绝对证明安全问题使其官方CVE条目之前是真实的。另一个阵营希望我们很快达成一个名称和“修复”的事情后如果发现漏洞报告是错误的。这直接影响CVE的及时性和准确性,以及我们所做的在主教法冠。它会不便一个阵营将满足另一个。此外,用户的脆弱性信息来源有很多困惑或坏假设这些信息的质量。他们可能会错误地假设源验证他们生产的每一项。 For example, many people assume that if they see an item reported in a database, that means that the database owners have verified that item. I had this assumption until I started talking directly to the information sources. In addition, many items don't have clear vendor acknowledgement of the problem. As I reported previously, 50% of all candidates don't have acknowledgement. A more detailed study of over 100 non-acknowledged candidates indicated that only about 10% of them had any acknowledgement by the vendor, if you spent a lot of time looking for it. But in some cases, those candidates were reported by reliable sources, but didn't have any acknowledgement. Since there is a community-based review process for CVE, it is highly likely that CVE consumers also assume that each entry has been fully validated. However, that is not necessarily the case, as the only requirement for inclusion in CVE is that the item get enough ACCEPT votes. (Of course there's also avoiding duplication, making sure the item passes the vulnerability or exposure definition, and ensuring that there are no content decisions that state that the item shouldn't be in CVE). I would not be surprised if some CVE entries are not real but "become real" by virtue of showing up in a large number of tools and databases. CAN-1999-0205 is a good example of such an alleged vulnerability that's in a lot of products but might not be real. (Seehttp://cve.mitre.org/cgi - bin/cvename.cgi?name=can - 1999 - 0205)进行一些更改投票过程,选民可以记录一个信心的基本概念,安全问题是真实的。看到下面的复习:CVE-BOARD: 20000919 (CVEPRI)重要的变化CVE候选人和投票http://cve.mitre.org/board/archives/2000-09/msg00003.html然而,当前的方法仍然是一个小“笨重”选民,他们是否正在使用CVE网站或在电子邮件投票。同时,接受选民的原因没有被公开的记录,直到我们可以解决这个问题,有一些成员透露太多信息的研究,他们为自己所做的产品。我建议我们CVE扩展到包括一个置信水平。这可能是一个voter-determined水平的信心,一个特定的CVE条目存在。记录的置信度CVE条目(或候选人)会CVE直接相关的几个优点:1)可能有助于满足“fast-and-noisy CVE营地和“slow-and-validated”阵营,其偏好是互斥的。无论选择哪种方法,它将对其中一个阵营如何使用CVE造成负面影响。如果CVE水平有信心,那么slow-and-validated倡导者可以使用最高的信心水平只提取部分的CVE“证明是正确的,”和fast-and-noisy支持者能够看到他们可以处理多少噪音。2)它可以使投票和审查过程更有效率。选民可能更容易接受一个候选人投票,即使他们没有复制它自己;他们可以记录一个置信水平较低,检查候选人反映最初的报告准确,和接受投票。 I've noticed that the number of NOOP's has increased significantly since we've updated the voting guidelines, which in turn is delaying the whole process even further. 3) Confidence levels would make it clear to CVE users about the level of noise that's being dealt with in CVE, and it would reduce the number of incorrect assumptions that are out there. 4) CVE diligence levels, as currently written, are difficult to describe easily. This is becoming more important as more unknown people ask MITRE for candidates to include in their initial public announcement. I believe that diligence levels could be more naturally described in terms of the level of confidence of items that the candidate requester has publicized in the past. 5) It could make it easier for me as the CVE Editor to decide when to ACCEPT candidates. If a candidate has high confidence, then I could ACCEPT it more readily in the minimum review period; if it has low confidence, then it might be reasonable to delay the item a little more. There are some community-wide benefits (independent of CVE) for confidence levels that might consider: 1) It provides consumers of vulnerability information with a tool to reduce information overload. Several participants in the recent eWeek/Guardent vulnerability summit expressed a need for knowing which vulnerability reports could be "trusted." 2) It could open a dialog among security professionals about how they determine their own confidence in specific vulnerability reports. (For example, it would be interesting to know why security vendor X has high confidence in something while vendor Y has low confidence). 3) Confidence levels could become the basis of a "web of trust" (or "web of confidence") that allows individuals to use third party confidence ratings to filter information, without having to go through the labor-intensive effort of verifying every report themselves. In addition, confidence levels could be used to "evaluate" different people/organizations that report vulnerabilities and establish a simple notion of peer review. If the Board agrees that confidence levels could benefit CVE and the community as a whole, then we would need to decide how to disseminate confidence information. For example, should CVE itself be extended to include a confidence level? Or should it be "physically" separated from the official CVE and provided as an alternate resource on the CVE web site, a la reference maps and CVE version difference reports? And how would confidence be recorded as part of the voting process? My next email will have specific suggestions for confidence levels that could be used, within CVE or by others in the community. - Steve