[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What is the future of CVE - Scope, Volume & Quality?
> 1. Can CVE effectively keep up in the face of an increasing volume of > English-based disclosures? It seems to me that the resource issue is a problem at the moment; for example we are building up a steady backlog of CNA allocated issues that are not yet in CVE (over 300 issues). Are there ways you can add staff to deal with specific tasks without increasing the chance of CVE duplications? > 2. What relationship should CVE have with any international effort (such > as IVDA) to identify vulnerabilities disclosed in non-English based > markets? It would be interesting to have a wider discussion with the bigger vendors about non-English disclosures. All the work I've seen on disclosure dates, days of risk, and so on have taken a public date from an english dislosure, and not counted non-English disclosures. The problem probably isn't non-english disclosures of issues that affect english software, but rather non-english disclosures affecting non-english vendors. 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. Sources http://www.awe.com/mark/blog/2009030319.html So half of the issues we find out about after they are already public are from the mailing lists "full disclosure" "bugtraq" and "oss-security" only. Although another quarter are by us tracking other peer vendors and upstream projects who monitor different subsets of lists. I'd like to see something like this from Mitre; where did the majority of your issues come from, how many were assigned by a CNA, etc. > 2. Coverage Maybe the rule could be that you will cover vendors that fix at least N (100?) vulnerabilities a year by monitoring their lists, and for smaller vendors you expect them to mail to one of the sources you define that you monitor. > 3. Response Time I'd be curious in usage stats from the web site (and perhaps NVD) which you could compare to your response times to determine if you are choosing the right subset of issues to be interested in. I suspect that 90% of the vulnerabilities get little traffic, are those the ones you dealt with slower? Could you make a CNA give you some draft details of an issue prior to it being analysed by your own staff? For example Red Hat would assign a CVE to an issue on oss-security, enter a brief description and URL to the Mitre site, and it would appear as a 'preliminary' description (either automated like we used to do on NVD, or via some quick human analysis). 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