再保险:CVE-10K问题

在星期五,2007年1月12日,在-0500年05:20:28PM, Steven m . Christey写道:|,| |好吧,那就是时间。2006年到目前为止,我们已经近7000分配CVE |标识符。我们没有100%的完整性,但我想说,对于|常见的来源(主要vuln DBs,供应商报告,Bugtraq等等)|可能有另一个100年到1000年CVE的2006年。| |考虑到脆弱的持续增长的趋势,这是一个真正的|可能性,在2007年,我们运行的风险分配9999 CVE |问题。如何处理10000个条目CVE-10K问题。| |这里有一些可能的解决方案。感谢反馈。我们可以在即将到来的telecon覆盖|这个话题,太。| | 1)保持和移动hex-based……cve - 2007 - 9999会| | 2)完全随机部分。 We've considered this for a | | 3) Adding 1000 to the year. Benefit: introduces predictability, and | | 4) Keeping the year, and extending the numeric portion to 5 digits. | | | Handling over, say, 20K issues in a year would likely require a | paradigm shift within the entire vulnerability information management | industry. As Dave Mann has pointed out to me numerous times, the | growth in the number of vulns is outpacing the growth in CVE funding, | which has been mostly flat with respect to content generation itself, | with increasing risks of our funding actually being reduced (I don't | think most people understand why good vulnerability information isn't | cheap.) Anyway, I suspect that this growth problem is hurting other | vuln databases/products, too. We're already seeing some of that | paradigm shift; the Board gave up voting a while ago due to the amount | of effort, you're seeing more generic vulnerability database entries | with more mistakes (probably being made by less experienced analysts | with less editorial oversight), the percentage of verified issues is | probably smaller, etc. (Speaking for myself) I don't think we should be tying a CVE shift to the possible need to address huge changes in the vulnerability management space. What those changes will look like is hard to predict, and it may be that having a large CVE namespace will make it easier. I think 1 is the right direction, and would like to advocate for 1', which is that the last 4 characters of the CVE be 0-9 and the alphabet, perhaps case sensitive. (I would urge that the first two to be issued would be 2007-000a and 2007-000A to drive home the point, and then work to avoid use of capitals, I, O, and S for readabbility reasons.) This gives us a large namespace without needing to redefine data tables. I think (3), adding to the year simply shifts the problem out 1000 years, and is thus shortsighted. Adam