[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CVEPRI] CVE candidate issues - handling new candidates
All: Now that CVE is public, we need to address some issues related to CVE candidates. It is likely that there is a backlog of 1000-2000 vulnerabilities or exposures that have not yet been assigned a candidate number. As Board members and others make their tools and databases CVE-compatible and contribute their "top 100" lists to me, I believe we will be able to address the backlog by using candidate clusters, in the way that we did earlier this year. However, we must not allow CVE to become obsolete with respect to recent or newly discovered security problems, which come in at the rate of about 1 or 2 per day. We need to take a balanced approach so that CVE can also be as current as possible with respect to new information. *** The Executive Summary *** This is a big message, so here are the most salient points: 1) We should start educating the public about candidates now. The sooner we use candidate numbers, the better. 2) Until content decisions and candidate assignment issues are well resolved, I'll remain the sole CNA to minimize "noise." 3) I could assign candidate numbers to Board members who provide me with sufficient information to write up a description and include a reference. Subsequent proposals will be sent to interested Board members on a regular basis. 4) We will restrict this approach to new problems ONLY, using established methods to deal with legacy entries. This scopes the problem while making CVE be as complete as possible from this point on. 5) Basic candidate information is provided on the web site (e.g. as a large HTML or text file), with enhancements to occur later. 6) Your feedback is appreciated. *** THE ISSUES *** 1) How - and when - to educate the public about candidates and their difference from CVE entries. CVE has been given some attention in the past month. However, it's clear that the public still needs to be educated about it (consider the recent discussions on the firewall-wizards mailing list). If we make candidates more prominent - e.g. by including them in advisories or somehow attaching them to postings to mailing lists - will we obscure the original message that this initiative even exists? Do we confuse the public with two numbering schemes (CVE numbers and candidate numbers)? How much does that increase the risk of candidate numbers becoming the de facto standard? If all major products are looking to be CVE-compatible, then this problem is probably reduced significantly. On the other hand, people will have to be educated about candidate numbers sooner or later, so why not just educate them now? In addition, the longer we delay attaching candidate numbers to early vulnerability information, the more effort everyone will have to spend coordinating all that information. 2) Identifying the best mechanism and infrastructure for making candidate information available to (a) voting Board members, (b) mappers, and (c) other interested parties, while minimizing confusion with normal CVE entries. There are several database design and implementation issues that will take some time to resolve before a viable candidate information source can be provided, whether to Board members or to the public as a whole. But there is a clear need for it. Board members need to be able to know which candidates they've voted on (or need to vote on). Mappers and other interested parties should be able to access this information to stay current, especially if they are seeking CVE compatibility. There are also some questions with respect to the best way to handle databases that use both CVE numbers and candidate numbers. In addition, the linkage between CVE numbers and candidate numbers will need to be recorded, especially for cases where a candidate is split or merged. Dissemination of candidate information could be addressed in phases. For example, I have already made some basic candidate status information available to Board members in a comma-separated format. We could make that available for download by interested parties along with other basic formats, saving other issues (e.g. database design or a good search utility) for later. 3) How to assign candidates in a way that minimizes "noise" as well as the amount of work that the Board needs to do to validate entries (both now, when so many content decisions are undecided, and later, as new CNA's are brought into the process). If there are too many sources of candidates early in the process, then there is an increased risk of (a) duplicates, (b) rejections, and (c) recasts. The more candidates there are, the more work that Editorial Board voters will have to do. This problem will be exacerbated by the lack of a good mechanism for obtaining and managing candidate information, as described above in (2). In addition, very few content decisions have been sufficiently discussed and approved by the Board, which will cause more problems in terms of being able to reliably assign candidate numbers that have a good chance of acceptance. 4) How to link announcements of new vulnerabilities/exposures (e.g. advisories) to CVE or candidate numbers without forcing the announcer to give up their real or perceived "competitive edge" for being the first to disclose the problem. There are several complexities in dealing with this particular problem. Consider "first-time advisories" in which a problem is first announced to the public in a formal advisory. In the best of all possible worlds, the advisory would be posted with a CVE number(s) included in it. However, a CVE number would require validation by the Board, which would require the advisory organization to disclose sufficient details for validation (current voting rules do not allow a candidate to be accepted with only a single Board member and confirmation by the software vendor). The organization with the advisory may not want to provide this information to their competitors. (This concern has already been expressed.) In addition, if the candidate really isn't public, then there would need to be a secure mechanism to protect the related information while it is being validated, which poses challenges for maintaining confidentiality. If such a mechanism is feasible, it will take time to set up. In short, while it might be best that an advisory could include a validated CVE number with it, there are various challenges which do not make this possible in the short term. So at this time, a "first-time advisory" would at best contain candidate numbers. But if we haven't educated the public as in (1), then the advisory would need to also take on the task of educating the public about candidate numbers. This particular issue only appears to apply to formal, well-validated first-time announcements such as advisories. However, advisories are far-reaching and typically deal with the most serious and extensive problems, so they could serve as a vehicle not only to educate the public about CVE, but to provide a name for major problems as early as possible. *** AN APPROACH *** Here's what I suggest as an approach for dealing with new vulnerability information at this time. It allows us to move forward on some issues that can be acted upon now, while taking the proper time to resolve longer-term issues. 0) We treat backlog issues independently of the issues related to new information. 1) We take steps to educate the public about candidates now. Education could take the form of (a) web pages on the CVE web site describing the differences between candidates and CVE entries, (b) short statements in any forum where candidate numbers are used (e.g. advisories or mail messages), and (c) additional clarifications by Board members in various forums where the subject comes up. 2) With me continuing to act as sole CNA, I could interact with Board members who have a desire to obtain candidate numbers for new information. - Submissions would be limited to new vulnerabilities ONLY (for now) - The submission MUST be ready for public dissemination (or already publicly known) - Submitters should only do submissions for vulnerabilities which they are the first to announce or publicize (this reduces "noise" of many Board members sending me the same submission). An alternate approach would be to have different submitters with different expertise (e.g. Windows NT vs. Unix) to focus on a set of problems - The submission includes a short description and references, i.e. looks very much like a candidate proposal - I then give them a candidate number (or numbers) to use - The candidates are packaged up and proposed to the Board list on a weekly basis (to reduce traffic on the list) - Interested Board members can request to be emailed directly when new candidates arise, instead of waiting for the weekly posting This allows for some consistency across candidates while reducing duplication and other problems. Restricting the request for candidates to new information, *and* to the original source of the information, reduces the effort required in this first step. This also allows me to continue to "schedule" and cluster content decision debates accordingly so that we avoid discussing too many technical issues at the same time. As various issues are resolved (e.g. database design, content decisions, etc.) these experiences could be used to begin a "training manual" for other CNA's. By having the candidate submitters send information to me in a "near-candidate" format, it allows prospective CNA's to begin to identify and address their own issues. 3) We provide a candidate status page on the CVE web site, including the capability to download candidate information in various formats (e.g. text, HTML, CSV). The status information should be detailed enough to allow Board members to view which candidates they've voted on. 4) We delay creating a forum for the Board to discuss non-public information until some of these other issues have been sufficiently addressed. But with the public being educated, most first-time advisories could at least include candidate numbers. What do you think about this approach?