[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CVEPRI] Editorial Board Review Meeting Summary - 11/4/1999
Below is a writeup of the CVE review teleconference on November 4, 1999. I've omitted some details that are provided in the Powerpoint slides I sent out a few days ago. Participants ------------ The following Board members participated in the teleconference: Mike Prosser Eric Cole Tom Stracener Craig Ozancin Pascal Meunier Andre Frech Dave Balenson Stuart Staniford-Chen Kelly Cooper Scott Blake Andy Balinsky Participants from MITRE included Margie Zuk, Bill Hill, Pete Tasker, Dave Mann, and Steve Christey. Recent Activities ----------------- We first discussed the recent Board activities, including the SANS and NISSC conferences in October. Board members who participated in the CVE booth said that they got strong positive reactions from conference attendees, although some expressed concerns about whether CVE would ultimately be successful or not. Board members often had to educate people that CVE is not a "canonical" database, and some people had a hard time believing that vendors were working together on this initiative. Proposed CVE Goals ------------------ We then proposed some concrete technical goals for CVE. With respect to CVE content, there were several goals that the Board agreed to. The first goal is to have CVE contain 500 entries by January 1, 2000. Some Board members considered this goal slightly aggressive, but achievable. A second goal is to assign candidate numbers for all publicly known problems discovered in 1999 and 2000. Finally, other measurable goals would be to begin using candidate numbers (or CVE numbers) in CERT advisories, security vendor advisories, software vendor advisories, mailing lists, etc. We also discussed some high-level goals of having a positive impact on industry and academia. These goals include: customers having requirements for CVE compatibility of their security tools, achieving CVE compatibility in N% of all tools or databases, CVE being used to support some tool analysis (e.g. by the press such as InfoWorld or in demonstrations such as ID'Net), and CVE playing a role in some academic research (e.g. by providing a list from which a researcher could take a sample to test some analytical approach). We also discussed the goal of having the Editorial Board grow more diverse and reach a critical mass which will allow the Board as a whole to engage in active and timely participation. One suggestion was made to provide a "CVE Wish List" that the Board could post to the public. The wish list could include small projects or other efforts that other members of the community could take on. This might foster more extensive community participation and allow the Board to focus on specific goals. We presented MITRE's near-term goals, which include: finalizing CVE compatibility issues, preparing for upcoming candidate submissions, establishing communication mechanisms such as announcement mailing lists or discussion forums, and updating the web site. We intend to make regular updates to the web site and allow for rapid response in rare cases. The next few weeks' updates will likely include an introduction to candidates for end users, supporting quotes, some optional registration, and graphics from the CVE booth. With respect to CVE content, we presented a roughly prioritized list of tasks. The highest priority item is to add more CVE entries and candidates. We also intend to provide additional support to Board members by making voting and candidate information available in an accessible format, with a longer-term goal of building a full-fledged support database. We will then formalize phase changes for CVE entries (e.g. to deprecate or modify CVE entries), define MIF (Mapping Interchange Format), and guide ongoing discussions of content decisions, many of which have not yet been sufficiently discussed by the Board. Candidate Issues ---------------- We spent a good amount of time on candidate issues. We proposed that now is a good time to educate the public about candidates. As we attach candidate numbers to new information, it will become easier in the future to create CVE mappings and establish CVE compatibility, so the earlier we start using candidates, the better. A challenge is to avoid confusion between candidates and validated CVE entries. If there is a reasonable assurance that there is a one-to-one mapping between a candidate number and the resulting CVE number, then this problem could be minimized somewhat. CNA's should help to ensure this. Below are some suggested ways of presenting candidates when they are used in advisories, summaries, etc.: CVE Candidate Number: CAN-1999-9999 [pending validation] supporting text: "This number is a temporary number assigned by the CVE Editorial Board. It will be validated by the Board before it is given a final CVE number." link or reference to a candidate page on the CVE web site We presented a process for Board members to submit new candidates. This process is described in more detail in the slides and in recent emails to the Board. One issue involved the desired "turnaround time," i.e. when the submission is first made and how quickly the CNA should respond with a candidate number. In general, Board members thought that turnaround times could range between a day and several weeks. It was suggested that a priority level could be attached to each submission, where each priority level had an expected turnaround time associated with it. Extremely rapid turnaround, i.e. on the order of hours, might become feasible in the future, especially as more CNA's become available. We discussed the process for legacy candidate submissions. Board members were asked to provide either a "top 100 list" and/or a "six month list" of submissions that they want to see included in CVE, given a relatively hard deadline of November 12. The resulting candidates could then be used to help us accomplish the 500 entry goal. At least 9 Board members believed that they would be able to provide some list by November 12. Finally, we explored some issues related to non-public candidates. Some Board members - mostly vendors who do their own vulnerability analysis - wanted the ability to obtain a candidate name for a problem that is not yet public, in order to attach the name to an advisory or other formal announcement. While it would be optimal to associate a validated CVE number with the advisory, there are several complications associated with this approach. The problem would need to be reviewed by any Board member who would vote on it, but if the information is released to other Board members, it could remove the competitive advantage. In addition, Board-wide secure communication channels poses a challenge in terms of technical implementation, assurance of confidentiality, timely provision of the information to the public, and "fair play" between competitors. As long as the CNA can assure that there will be a one-to-one relationship between a candidate number and the resulting CVE number in most cases, then a candidate number would be sufficient for use in a public announcement. This would only require secure communications between the submitter and a CNA that they trust. Another concern was related to additional threats with respect to disclosure of the information, e.g. the locations of the confidential information could themselves be subjected to attack. While these issues were not fully resolved, at this time it appears that submitters of non-public candidates can work things out directly with MITRE, since at this time MITRE is the only CNA. CVE Compatibility ----------------- We proposed an idea for having two "levels" of CVE compatibility. The intention was to handle separate but conflicting interests: - some will speak CVE simply because they want to support it. But they don't necessarily want it to be difficult or expensive to obtain a "CVE-compatible" logo - others expressed the desire for a strong "label" that they could use for marketing purposes, to protect against abuse, or provide some high degree of assurance to the consumer We proposed the idea of two levels of "speaking CVE." The first level, CVE Compatibility, would be simple, informal, and easy to obtain. There would not be any formal evaluation by MITRE. They would then be granted permission to use a logo. MITRE would reserve the right to rescind permission to use the logo if it is believed that the organization is abusing it, e.g. they claim they're CVE compatible but the quality turns out to be very low. We proposed a second level, CVE Certification. This would have a formal application and certification process. MITRE or another approved authority would conduct a detailed analysis of the mapping to ensure accuracy. As certification would be more expensive to conduct, it might require an evaluation fee, though steps would be taken to prevent it from unfairly excluding some organizations. Both levels included a requirement that the organization should provide MITRE with their database mapping. The mapping would serve two functions: (a) it would identify items in the database which still need to be added to CVE, and (b) it would allow MITRE to review the mapping and provide feedback to the organization. It was emphasized that these mappings would not be made available to any organization outside MITRE, however it is highly likely that consumers may request the mapping from the organization, e.g. to help them compare products for purchase. Board members believed that at this time, only the "CVE Compatible" level is necessary. As long as there is some protection against abuse, consumers might find compatibility sufficient for their needs. It was pointed out that compatibility problems (such as inaccurate mappings) would be obvious both to competitors and to end users. As long as the abuse was limited, e.g. by rescinding the rights to use the logo, then this level might be sufficient. As the market matures and CVE compatibility is obtained - perhaps in a year or more - certification may need to be revisited. However, at this time, Board members were satisfied with the informal, simple approach for CVE compatibility. Some issues were raised as to how CVE might begin to play a role in the marketing of products. End users would have to be educated on how CVE could be misused in comparing products. The "numbers games" of tools (e.g. whether a tool has 500 checks or 300 checks) could still be played, even using CVE as a standard. For example, a tool that focuses on Windows NT should not be compared with one that focuses on Unix. The idea of CVE "sublists" could play a role here, i.e. a tool could be compared against a particular subset of CVE entries that might be a "gold standard" of sorts. As tools and databases become CVE compatible early next year, we will need to address the issue of marketing using CVE, and educating the public about the nature of how CVE should be used when comparing tools or databases. Editorial Board Issues ---------------------- We discussed MITRE's approach to communications and relations with Board members. Our experiences with many Board member organizations have posed some communications challenges. Besides the technical contacts on the Board, there is a need to establish contacts for marketing, PR, and management departments so that we can make sure that everyone involved gets the appropriate information. There is also a need to develop a good business case for participation in the CVE Initiative. As the Board has grown, there has been a greater reliance on sending email to the entire list, instead of email or phone calls to individuals. While the Editorial Board has been an informal organization, there is a need to provide better descriptions of Board roles and responsibilities. These will help current or prospective Board members to understand what their contributions to the Board should be. The basic responsibilities have been identified as: - discuss and vote on specific CVE entries - discuss and vote on content decisions - discuss CVE update/maintenance issues - identify and accomplish high-level goals for CVE - educate the public about CVE - express strong support for CVE compatibility - advocate CVE Board members considered requiring that any member with a tool or database should make it CVE compatible. However, it was decided that making it a requirement was too stringent. Some concerns were expressed that some Board members may want to make their tools or databases CVE compatible, but may be prevented due to external factors (e.g. product development cycles or reticence of their management). It was agreed that members should make every reasonable effort to make their databases CVE compatible. We outlined different roles that Editorial Board members might take, with the notion that these roles can provide guidance to members on how to participate in Board activities. These roles have not been formalized, although they may need to be in the future. *Technical* members deal with CVE content itself by voting on CVE entries, discussing content decisions and CVE maintenance, etc. *Advisory* members might be high-visibility or high-impact individuals who can advocate CVE and introduce it to a large audience. *Liaisons* may directly or indirectly represent a significant constituency that doesn't necessarily require full participation in Board activities. Finally, *Observers* are not official Board members, but they may wish to follow Board activities closely or be involved indirectly. We described our current approaches for adding new members, which includes an interview of the prospective member to determine technical skills and ability to commit time to the effort. MITRE postponed most recruiting activities until they were reviewed by the Board. We only concentrated on recruiting prospective members who had expressed an interest in CVE before RAID '99 (early September). We have been focusing on filling in a number of gaps in Board membership, including: - "End users," i.e. consumers of security information - Windows NT experts - OS/applications vendors - Consultants/auditors - Freeware tool vendors - Incident response teams - Government agencies - International organizations Board members were satisfied with this approach and saw no need to formalize membership at this time (e.g. through voting by the entire Board). There was also some discussion of how to conduct removal of Board members - e.g. if a member abuses their position on the Board and acts against the spirit of the CVE Initiative. It was suggested that MITRE should consult with the Board member to determine if removal is required, and do this consultation in private. Overall, Board members continued to be satisfied with the informal nature of the Board and did not express concerns with how MITRE has been conducting Board business. There was a recognition that as the Board matures or as new events occur, there may be a need to formalize membership rules, but it is not necessary at this time. Next Meeting ------------ We discussed the need to hold regularly scheduled meetings, especially in these early days when CVE is so dynamic and there are so many unresolved issues. We proposed having a monthly teleconference, with face-to-face meetings on a less frequent basis. We will try to hold a teleconference in early December, and give Board members at least 2 weeks' notice so they can schedule appropriately. In addition, the next face-to-face meeting needs to be scheduled. A February meeting somewhere near the US West Coast was suggested. Board members from AXENT and UC Davis have suggested that they may be able to host such a meeting; however, there has been no formal commitment at this time by either member.