[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Organizational and technical issues for CVE
All: Below is a writeup of some of the technical and organizational issues that the Editorial Board will need to deal with. While some of these were mentioned in a previous email, they were all brought up at one time or another during SANS. Other Board members may have additional issues that arose during last week. Andre Frech has also written something up, but I don't want to forward it without his approval. - Steve *** Organizational/Board-level Issues *** 1) Editorial Board structure, membership, and participation needs to be reconsidered. Approximately 20 additional organizations have requested membership on the Editorial Board. Requests have come from individuals at the technical and management levels, from a broad range of organizations including consulting firms, US government, incident response teams, security vendors, and "end users" (e.g. security analysts). It is clear that a number of different roles and/or functions for the Board need to be devised in order to accommodate a broad range of participation levels. MITRE is re-evaluating the Board's structure and membership rules, but any suggestions by the current Board are of course welcome. A small number of individuals or organizations are being "grandfathered" because we started discussions with them well before CVE became public, but we are freezing all other membership until this issue is formalized. 2) "CVE compatibility" needs to be made more explicit and objective. As mentioned earlier, informally we'd like "CVE compatibility" to be a label that has a significant meaning. A number of Board members have asked that we be more specific about how CVE compatibility can be objectively measured. Dave Mann and I believe that CVE compatibility should include the following at a minimum: - (a) A user should be able to use a CVE name to locate related records/probes/signatures; - (b) The database/tool output should be able to report CVE names; - (c) There is some guarantee of accuracy (e.g. for tools, a claim to check for CVE-XXXX-YYYY should imply that the tool does a "reasonably good" job of detecting CVE-XXXX-YYYY.) Obviously, (c) is the most difficult to formalize and verify, but it is necessary in order to prevent abuse. See my earlier email titled "CVE compatibility and future Editorial Board activities" for a more detailed writeup of this issue. 3) We will provide links on the CVE web site to organizations that "declare" that their tools/databases will become CVE compatible. At this point in time, only CERT, CyberSafe, and NTBugtraq have made public declarations to this effect. Security Focus' database already includes requirement (b) of the requirement stated above. Obviously, other Board members intend to do the same. I think a URL to a web page containing the declaration would be sufficient. 4) We should schedule an Editorial Board teleconference (a la the August CVE Review meetings) shortly after next week's NISSC conference, e.g. the last week of October or the first week of November. In addition, we should have a face-to-face meeting sometime in December or January. 5) OS/application vendors, consulting firms, government organizations, and "end users" have very little representation on the Board at this time. This will need to be addressed. *** Technical Issues *** 1) See my earlier email titled "CVE compatibility and future Editorial Board activities" for a number of technical issues that I won't repeat here. 2) There have been some questions as to the next milestone for the CVE Initiative to achieve. In the audio press conference, Steve Northcutt indirectly issued a challenge to achieve 1000 CVE entries. Scott Blake apparently posed an even bigger milestone of "CVE2K by Y2K." Following a CVE entry from Bugtraq/NTBugtraq to tools to response teams could be another concrete milestone. Keeping up with all newly discovered problems would be another. A more concrete Interoperability Demo that people besides me can explain ;-) would be another milestone. 3) A number of people expressed concerns with the time frame that it takes from candidate proposal to CVE acceptance. With the process I've currently defined, the minimum amount of time is 2 weeks. This may be sufficient for full CVE acceptance, but it is also clear that many people want candidate numbers generated as soon as possible (one person wanted something on the order of hours or minutes to be able to handle emergency situations, e.g. Melissa). We can deal with this issue as we cover CNA-related issues over the next few months. 4) There are some questions as to the best approach for back-filling old CVE entries, in combination with dealing with new entries. As mentioned in the earlier email, candidate clusters appear to be the way to go at this point in time. There will need to be some coordination across databases to minimize the amount of "candidate noise" that's generated (e.g. duplicate candidates or those at an inconsistent level of abstraction). Some end users at SANS expressed the need to assign candidate numbers to all known issues as soon as possible. 5) It is clear that at the very least, a number of mailing lists or alternate distribution mechanisms need to be provided. For example, a "cve-announce" or similar mailing list could be useful to post all Final Decisions, upcoming events, etc. Another mailing list, open to anyone and perhaps unmoderated, could be used to discuss CVE-related issues. 6) There will be a need to define a CVE mapping language to facilitate sharing CVE mappings. I'll take a first stab at such a language. Simplicity will be paramount.