|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] CVE Update - Now and the Future
All, We have been quiet recently, I know, but much has been happening. Over the past couple of years, we've been working very hard on a number of things in CVE, mostly related to content and compatibility. Managing the Editorial Board has been a low priority, although we do want to rejuvenate the Board and have it achieve a level of vibrancy that it once had. The inquiry about CVE and the Editorial Board comes at a good time. We are at a major transition point in CVE's lifetime, when big questions are being asked. We have brought Dave Mann (remember him?) back into the fold as a task leader. While we are still determining the precise nature of his role and his priorities, currently his primary task is to help us to achieve a operational, non-interuptible production of CVE content. CVE Content ----------- Our most concrete efforts have been in improving the timeliness and comprehensiveness of CVE content. Compared to a year ago, we are producing twice the number of candidates than we used to. We have much closer links to OVAL and CERT, as well as NVD and other US-CERT initiatives. In October, we successfully finalized the CVE renumbering that we've discussed in the past. All candidates now come out with a "CVE" prefix, and each item is labeled with an "Entry" or "Candidate" status. Our initial announcement is at: http://cve.mitre.org/cve/renumber.html We still have a ways to go on content, however. We are much closer to being timely and comprehensive than we were a year ago, and we have made major leaps in the last 2 months. But minor issues in minor software still slip through the cracks. Our references to other data sources - e.g. Bugtraq ID, Secunia, OSVDB, ISS X-Force, etc. - are not as complete as we would like, although we cover more references than we used to. We nearly produce public content on a daily basis, but sometimes there are slow days where it occurs in bursts. In the past this was not a major problem, but it has become more important because regular production makes it easier for compatible products and services to map their items to CVE. In addition, the lack of regular production makes it difficult for products like NVD, since it depends so heavily on CVE for content but has different goals than we had originally intended for CVE. (Note that we are working with Peter Mell as well as our mutual sponsor, the Department of Homeland Security, to clarify and hopefully unify our vision.) As has happened in the past, we also must deal with regular changes in content team membership. We have gotten much better about training and finding the right people for the job, and providing feedback to analysts. We are better at absorbing personnel changes when they come along, to minimize disruption. One main reason for the lack of major disruption, while retaining quality, has been my hands-on approach while acting as CVE Editor. Approximately 95% of all CVE candidates are still reviewed by me before they become public, and I still generate about 40% of all candidates. This of course can also be a liability. For example, I took a vacation in November and while content production continued behind the scenes, there were no new CVE's published for over a week. We now realize that there is much greater operational dependence on CVE than we had believed. We have not yet found the proper person/people to act as co-Editor, although we are always optimistic. Meanwhile, we are making changes to ensure that we do not have any more disruption like what happened in November. I can also see the writing on the wall, and I predict that at some point soon, the problem of accuracy in vulnerability information will become a major point of contention for consumers and/or affected software vendors. There has been a marked increase in vendor disputes of existing issues, for example, and consumers seem to be getting more vocal about their expectations. This will have an impact on everyone, but especially vulnerability databases, including CVE. (Yes, I've decided that CVE is in fact a vuln DB, albeit a highly specialized one that is regularly "misused" relative to its original purpose). Our content tasks take some of this concern into account, although it is a problem for the industry in general; see my Bugtraq post "Why Vulnerability Databases can't do everything" for some of my thoughts on the problems. Normally I would not bring this up, but I think it could become a big driver for the industry, and it might impose some changes on CVE. All of this is happening with an infrastructure for content generation that was fine in the olden days when there were 40 vulnerabilities a month, and only me and one other person creating content. Now there are up to 100 vulnerabilities a week and 3 to 5 people creating content. This increases the numbers, but it also results in more duplicate identifiers than we used to produce, more complexity of the entire process, and a less clear division of labor that places more demands on the skills of content team members. We have not had the time or resources to conduct a complete process overhaul, due to the constant demands for additional content. I am sure other people here can relate! Data Feed --------- Note that as part of our work on timeliness and closer cooperation with external sources, we developed an hourly feed to external sources that use CVE heavily. This feed provides the CVEs that were created within the last hour, in either text or XML format. I did not want to announce this to the entire Board until it was out of beta release, but the reality is that it has been in full production for months, so I might as well announce it now. We do not plan on providing this feed to the public, although certainly any CVE-compatible source can receive it, since it can be more closely tied to mapping. Contact me off-line and I will add you to our notification lists. Voting and CVE Versions ----------------------- MITRE has not submitted candidates for voting in quite a while, which has delayed the production of a new CVE version. Voting by clusters had stopped being successful quite a while ago anyway, due to the large volume of issues coming in. I've been thinking that it might be benefecial to make voting more lightweight, and to be as flexible as possible in allowing Board members to vote. For example, we regularly receive updates or corrections from various Linux vendors. Indeed, the whole purpose of voting should be reviewed. The fact is that the workload was too much for the Board several years ago, so restarting it without any changes would not be effective. This could argue for extending the Board, creating a separate voting group for voting and review, or modifying the rules for when to promote an issue from a candidate to an entry. Similar to the voting questions, we also want to revisit whether the concept of CVE versions really works. It is clear that in this day and age, most people also use candidates. Now that the renumbering has happened, there might be even less need to distinction. Periodic CVE versions would still have their uses, especially in providing predictability and some assurance of data accuracy, or serving as a basis of large-scale trend analyses. However, there has not been a new version in over a year and frankly, there has been very little demand for one. CVE Compatibility ----------------- Our CVE compatibility evaluation program has continued to grow, with Bob Martin's leadership. Now, over 230 products and services, from 140+ organizations, have at least declared their intentions for CVE compatibility. 53 products have obtained official "CVE Compatible" status, with another set of products to be announced soon. We have had several rounds of evaluations over the past couple of years, and we better understand the complexities. We have built much of the infrastructure to make the evaluations efficient and effective, although it is dependent on the content infrastructure and could therefore benefit from some change. Related Efforts --------------- CVE work has not been occurring in a vacuum. In the past year, we have continued to explore the Common Intrusion Event List (CIEL) concept, as well as OS/system configuration issues. Results are still preliminary, and funding is variable, but we can provide more details if people are interested. We continue to leverage our CVE experience to help us move forward in the Common Malware Enumeration (CME) effort, although it has its own set of unique challenges. We have also begun work on a vulnerability classification project that is temporarily called PLOVER. This grew out of my "Vulnerability auditing checklist" side project, which I periodically posted to public mailing lists over the years. At this stage, PLOVER includes about 300 categories of vulnerabilities and is up-to-date enough to include issues such as CSRF, PHP file inclusion, and eval injection. These classes are linked to over 1500 individual CVEs. It includes some "vulnerability theory" that has helped improve my understanding of vulnerabilities, and introduces some terminology for new vulnerability classes. Some of this has fed back into terminology that we use for CVE descriptions. The PLOVER work has a close tie-in to a NIST/DHS effort in understanding source code scanners and other security analysis tools. In future months, we hope to extend it to encompass other recent research in taxonomies and vulnerability classification, the bulk of which is coming from secure software development people like McGraw, Chess, Viega, Howard, LeBlanc, etc. Bob Martin and I are excited about this new effort, and we are confident that our CVE experience will help us to make solid contributions. I still want to make some minor modifications to PLOVER before making a wide public announcement, but the current version is at: http://cve.mitre.org/docs/plover/ Warning: it's huge. Editorial Board --------------- As you all know, there has been minimal activity with the Editorial Board over the past couple of years, due to our focus on content generation, as previously discussed. It is my hope that the addition of Dave Mann as another CVE task leader will help to free us to get the Board back on track. Amongst many things to be covered are: - the future directions for CVE and related efforts - the role of the Board itself - the addition of new members - voting It would be best to have a teleconference in January, after the holidays. As Pascal said, I too miss the kinds of discussions that we used to have. MITRE has been deep in the weeds of CVE content for a while now, but this is a good time to get back into the swing of things with the Editorial Board. Thanks all, Steve
|
||||
