再保险:CVE-10K问题

我们不能够避免开发人员改变CVE格式处理,无论我们做什么。有些可能只检查数字,有些可能会检查一个特定的字符的数量和类型。有些产品对ID作为文本引用字符串的格式验证例程可能检查细节,以确保良好的数据是被注入。一些使用正则表达式检查,通过检查每个元素的格式。任何决定,需要改变。改变了,什么时候可以取出来CVE条目状态成为一个内部元素。工具厂商并没有一个真正的问题。改变影响不同的处理,因为毕业处理代码需要被删除,搜索机制,现有的罐必须转换为cf的数据库工具。我们应该看到的是我们感觉CVE的长期最佳解决方案。就我个人而言,1或4适合我。 Hercules has it stored in a text field 50 characters in length so extending it is not an issue for us. One minor change to the validation routine and we are ready to go. The key is communication so we alert people this is coming and they should be looking for and making changes as necessary to support the decision. We still have a little time. Set a date when the decided change will be made and give people enough time to deal with it. We should just pick what is best for CVE without creating any additional limits we may see come around again. -- Kent Landfield Director, Security Research McAfee, Inc. +1 972.963.7096 Direct +1 817.637.8026 Mobile kent_landfield@mcafee.com www.mcafee.com -----Original Message----- From: owner-cve-editorial-board-list@LISTS.MITRE.ORG [mailto: owner-cve-editorial-board-list@LISTS.MITRE.ORG代表亚当Shostack派:星期五,2007点至4点:1月12日Steven m . Christey Cc: cve-editorial-board-list@LISTS.MITRE。ORG主题:Re: CVE-10K问题在星期五,1月12日,2007年在05:20:28PM -0500年,史蒂芬·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 would go | | 2) Completely randomize the year portion. 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