CVE的宪章,范围和必须的角色

艺术已经引起了一些至关重要的点和问题值得解决为了保持谈话前进。戴夫写道:> >的码尺考虑这些,CVE需要捕捉>漏洞从这个来源为了full-fill章程?艺术写道:>国际海事组织,更大的讨论是CVE的未来,所以未来>(或修改,审核,刷新)宪章。艺术,我们总同意。CVE最初的宪章是涵盖所有公开已知的漏洞。我们承认这是不可能作为一个实际问题。在内部,我们已经讨论限制这公开所有已知的基于英文的漏洞信息披露。请注意,我不想过早排除非英语从考虑披露。我认为它可能最终有可能谈论英语披露,如您所指出,必须更多的参与将是一个解决方案的一部分。但我想确保我们达到球队的第一来源。 So, by all means, if you feel that there are non-English-based sources that are "must-haves", please call them out. More broadly, let's not restrict the scope or charter of CVE based on current processes in any way. Let's please discuss what needs to be covered by CVE first and then we talk about process to achieve that second. >1. Assign ID to vul report (More CNAs? More active CNAs?) >2. Manage duplicates, mistakes, etc. >3. Refine assignments (further duplicate resolution, merge/splits, final >arbitration) >4. Accurate analysis > >Don't wait for #4 to issue a CVE ID. Users need to be able to talk >about "the thing" (a vul report), even (unfortunately) if "the thing" >turns out to be a duplicate or false alarm. You're going in directions that our thinking is going too. If it's useful to think about solutions even as we discuss goals, I want to toss out 2 very, very hard problems that I think we should start thinking about now: a) Economic incentives for SME produced content (specifically applied to CNAs) b) Level of abstraction issues ECONOMIC INCENTIVES - It is worth emphasizing that MITRE continually seeks the involvement of new CNAs. We are (and y'all should be) extremely grateful for all of the CNAs that participate. Our experience is that CNA relationships work out when an organization has mature enough vulnerability information practices and, as a result, they incur relatively low marginal costs in terms of issuing CVE IDs. This level of maturity varies widely, based on what we see. In many other areas of cyber-security information provisioning, we see lots of appeals to various forms of "crowd-sourcing" content creation. The problem is, good content requires good SMEs and good SMEs are expensive. The question becomes, what are the economic incentives for organizations to fund SMEs to act as CVE CNAs? We've been looking hard at many other identification systems that have successfully federated their content creation. Economically, we see 2 primary models: ISBN and VIN. ISBN numbers are produced by publishers because they are routine and easy to assign (compared to CVEs) and there is an economic benefit for doing so. VINs are assigned by manufacturers because (in the US) the DOT mandates it. MITRE is already beating the bushes for CNAs and we have the set of CNAs that we have (and are grateful for). How do we expand that set? LEVEL OF ABSTRACTION - There are 3 LoA questions to start thinking about. First, can we deal with significant drift in level of abstraction among CNAs? Will we be able to fix duplicates from different CNAs if/when they are assigning IDs at different LoAs? Second, is CVE's current LoA (which grew out of vulnerability practices in the late 90s/early 2000s) too low for today's vulnerability management practices? Third, combining these first two questions, can we live with a CNA that is committed to the ideal of "silent patching" and, in their role as a CNA, assigns CVE IDs on a "per patch" basis with no further information? Those of us who dealt with vulnerability information back in the 90s remember the "silent patch" days. Would it be acceptable moving forward? -Dave ================================================================== David Mann | Principal Infosec Scientist | The MITRE Corporation ------------------------------------------------------------------ e-mail:damann@mitre.org | cell:781.424.6003 ================================================================== >-----Original Message----- >From: Art Manion [mailto: amanion@cert.org]>发送:周二,2011年10月04,1分54秒点>:曼,戴夫> Cc: cve-editorial-board-list >主题:Re: CVE信息来源和范围> > 2011-10-04 39,曼,戴夫写道:> > >的码尺考虑这些,CVE需要捕捉>漏洞从这个来源为了full-fill章程?> >国际海事组织,更大的讨论是CVE的未来,所以未来>(或修改,审核,刷新)宪章。> >是CVE寻找原始的来源vul信息?或覆盖广泛>吗?或有效的“最大”的报道新闻vul吗?万博下载包> >下面的列表是足够的,如果有点过时,和重复(CIAC >改变了他们的名字,CIAC和AusCERT只有再版vul IIRC的信息)。> >我们(CERT / CC)有一个类似的充足,但日期列表。我们也>可能更感兴趣的第一个暗示新的vul报告>而不是准备的一些更权威的CVE ID。> >更多新的vul信息出来这几天通过推特和博客。>似乎大部分可能达到下面的来源。>利用列表(metasploit exploitdb)其他新vul >信息来源,这取决于CVE正在寻找。 > >Back to the bigger picture, I'm on the side of issuing more CVE IDs >faster for more vul reports, having reasonable ways to distribute >assignment and manage duplicates and false alarms. Accurate analysis is >great, but can come a few days after the ID is issued. So my opinion is >that CVE should refocus on being *the* leading, fairly comprehensive >source of IDs (enumeration) for vul reports. Some other capability can >do analysis or add further value later. > >Goals, in time order (and as more information about a vul report becomes >available): > >1. Assign ID to vul report (More CNAs? More active CNAs?) >2. Manage duplicates, mistakes, etc. >3. Refine assignments (further duplicate resolution, merge/splits, final >arbitration) >4. Accurate analysis > >Don't wait for #4 to issue a CVE ID. Users need to be able to talk >about "the thing" (a vul report), even (unfortunately) if "the thing" >turns out to be a duplicate or false alarm. > >> Government Information Sources >> US-CERT Advisories (aka CERT-CC Advisories) >> US-CERT Vulnerability Notes (CERT-CC) >> US-CERT Bulletins (aka Cyber-Notes) >> DoD IAVAs >> NISCC >> AUS-CERT >> CIAC >> >> >> CNA Published Information >> CMU/CERT-CC >> Microsoft >> RedHat >> Debian >> Apache >> Apple OSX >> Oracle >> >> >> Non-CNA Vendor Advisories >> Solaris >> Suse >> Mandriva >> HP-UX >> SCO >> AIX >> Cisco IOS >> Free BSD >> Open BSD >> Net BSD >> Gentoo (Linux) >> Ubuntu (Linux) >> >> >> >> Mailing Lists & VDBs >> Bugtraq >> Vuln-Watch >> VulnDev >> Full Disclosure >> Security Focus >> Security Tracker >> OSVDB >> ISS X-Force >> FRSIRT >> Secunia >> Packet Storm >> SecuriTeam >> SANS Mailing List (Qualys) >> Neohapsis (Security Threat Watch) > > > > - Art