再保险:什么是未来的CVE -范围、体积和质量呢?

> 1。能有效CVE跟上面对越来越体积的>基于英文的信息披露?在我看来,目前的资源问题是一个问题;例如我们建立稳定的积压CNA分配问题,尚未在CVE(超过300)的问题。有方法可以添加员工处理特定任务不增加CVE重复的机会吗?> 2。什么关系CVE应该与任何国际努力(IVDA等>)来识别漏洞中披露非英语基础>市场?这将是有趣的对英语有更广泛的讨论与更大的供应商披露。披露所有的工作我看到日期,天的风险,等等从英文dislosure已经公开日期,而不是计算非英语披露。问题可能不是英语披露的问题影响英语软件,而是非英语披露影响非英语供应商。 Could that be solved by having a regional CNA and making CNA's do more work (at the moment the work ends after allocating a name, there is no notification aspect to Mitre as you mentioned). > 1. Sourceshttp://www.awe.com/mark/blog/2009030319.html所以一半的问题后我们发现他们已经公开来自邮件列表“完全公开”“bugtraq”和“oss-security”。虽然另一个季度我们跟踪其他同行上游供应商和项目监控不同子集的列表。我想看到这样的东西从斜方;大多数的问题是从哪里来的,有多少被分配由CNA等> 2。报道也许规则可能是,你将涵盖供应商修复至少每年N(100 ?)漏洞通过监测他们的清单,和较小的供应商你期望他们邮件来源你定义你的班长。> 3。响应时间我很好奇在使用统计的网站(也许NVD)你可以比较你的响应时间,以确定如果你是选择合适的子集的问题感兴趣。我怀疑漏洞得到小流量的90%,那些是你处理的慢吗?您能CNA草案给你一些细节问题之前被自己的员工分析吗?例如红帽会分配一个CVE oss-security问题,输入一个简短的描述和斜接站点URL,它会显示为“初步”描述(要么是自动化的,像我们用来做NVD,或通过一些快速人工分析)。 I could even see it being tied into your log analysis so that some spike on a particular CVE would cause it to get bumped up your queue. > 4. Quality > a. What rate of duplicate CVE entries can be tolerated? > b. How consistent does CVE "counting" need to be relative to past > counting practices and content decisions? ("Counting" here means > the relationship between a given vulnerability and the number of > CVEs needed to correctly describe it and vice-versa. These may be > one-to-one, one-to-many, many-to-one, or many-to many.). We believe I believe that the duplicates tend to solve themselves over time and don't cause particular harm. Even after nearly 10 years allocating CVE's I still have difficulties with some corner cases and end up looking at the old content decision pages or trying to get hold of Steve. Perhaps some training for CNA's would help (or some yearly quiz/test/refresher). Thanks, Mark -- Mark J Cox / Red Hat Security Response