|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [TECH] New CVE Version and Legacy Candidates
All, A new CVE version will be created within the next 2 weeks. An Interim Decision will be made on more than 100 candidates on Monday, September 10, with a Final Decision on the 14th, and a new CVE version on the 14th or the 17th. We have also created 571 legacy candidates. After clusters are created for those candidates, I expect to propose them "en masse" on Tuesday, September 11. The clusters will probably be larger than usual, but there will still be 10 or more. While it might be nicer on your email readers to spread these out over a period of a month or so, I don't see any real reason to delay them further. Opinions on this approach are, of course, welcome. Once the candidates have been proposed, backmaps will be sent to all data sources. (Backmaps link the source's own unique ID to the associated CAN/CVE). Numbering --------- For all issues that were publicized in 1999 and earlier, CAN-1999-xxxx was used for the numbers (producing CAN-1999-1012 through CAN-1999-1568). Other issues that were discovered in 2000 were assigned CAN-2000-xxxx numbers. (There are various reasons why those candidates were not actually created in 2000.) I expect to follow this numbering pattern for as long as we continue to use the CAN-yyyy-nnnn format. (The concept of a new naming format has not been forgotten.) Details on the Sources for Candidates ------------------------------------- We started with about 8500 legacy submissions, most of which came from databases that were provided to us from Board members (sources). 902 submissions were used to create 571 legacy candidates. (This shows how little overlap there was across the 10 different sources, since only an average of 1.6 sources "contributed" to each candidate.) The oldest candidates date back to 1989. 2461 submissions were either (1) already related to existing CVE candidates or entries, or (2) did not satisfy the CVE vulnerability or exposure definition. (It's more difficult to measure the overlap across sources in this group, but I estimate that it was around 3 to 4 sources per matching candidate or entry. Still, it's less overlap than one might expect.) 3936 submissions were delayed (not fully "resolved") for processing for one or more of the following reasons: (1) it was uncertain which vulnerability or exposure was being identified by the submission. This was normally due to vague descriptions and the lack of references. We will consult with the original sources on these submissions. (2) some submissions were related to complicated issues that were not quickly resolvable by the content team member who evaluated them. For example, in summer 1999, numerous problems were found in wu-ftp. It was not necessarily obvious how many different problems there were - let alone which vendor advisories were fixing which problems. Another example involves several Oracle issues that were discovered and reported by ISS within a short time span, but for which there are insufficient details to be certain how to write distinctive descriptions. These more complex issues can be addressed with more analysis, but they have been delayed for this first round, with the hope that we will get the candidates "right" the first time we create them. (3) some submissions were related to larger questions which we want to address before proposing them to the Board. For example, many sources reported various configuration problems related to Windows NT, or UNIX. Some problems were at the OS level, and others were unique to specific applications. There are many questions regarding the appropriate level of abstraction to use, and how to "break them up" in the first place. We will devise reasonable "rules" for addressing these sorts of problems in the next round, though CAN-1999-0550 through CAN-1999-0665 may already cover many of these submissions; consequently, the next round will include a re-evaluation of those candidates. We have approximately 1000 more legacy submissions whose status is unknown. We will identify them and make sure that they are processed correctly.
|
||||