[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CVEPRI] March 9-10 Editorial Board Meeting Summary
All: Below is a high-level summary of some of the discussions that the Editorial Board had during last week's Board meeting. I believe that the meeting went very well. Since many important issues were discussed that may affect all Board members, all non-participants should read the full summary and provide their feedback. Other participants are encouraged to present their perspective of what happened during the meetings. For those who participated via teleconference, I would appreciate your feedback as well. This was the first meeting in which there were more face-to-face participants than in the teleconference, and I know that some people had problems hearing the discussions over the phone. Hopefully we will be able to address these problems in future meetings. This summary omits some detailed points that are included in the slides that were sent to the Board mailing list before the meeting. - Steve =========================================================================== Summary of the CVE Editorial Board meeting on March 9-10, 2000 =========================================================================== This summary omits some detailed points that are included in the slides that were sent to the Board mailing list before the meeting. Attendees --------- The attendees of the face-to-face meeting were: Eric Cole (Vista IT) Craig Ozancin (AXENT) Andy Balinsky (Cisco) David Balenson (NAI) David LeBlanc (Microsoft) Tom Stracener (Hiverworld) Marvin Christensen (IBM ERS) Ronson Nguyen (Ernst & Young) Andre Frech (ISS) Jim Magdych (NAI) Dave Baker (MITRE) Steve Boyle (MITRE) Steve Christey (MITRE) Margie Zuk (MITRE) Several people participated by teleconference at various times during the meeting: Scott Blake (BindView) Dave Mann (MITRE) Pascal Meunier (CERIAS) Mike Prosser (L-3/Symantec) Content Update -------------- An update on CVE content was presented. 503 CVE entries had been approved as of CVE version 20000118, and 634 active candidates had been proposed. 78 candidates were ready to be moved to Interim Decision, and 251 candidates were being held back by unresolved content decisions. Finally, 92 candidates could be accepted with one more vote. Attendees discussed public interest and knowledge about candidates. On the CVE web site, the number of candidate-related downloads was about 15% of the number of CVE entry-related downloads. Some attendees expressed a need for better explanations of candidates on the web site, and a description of the fundamental differences between candidates and entries. Voting ------ Several important issues related to candidate voting were discussed. Many attendees said that a web-based interface would help them significantly with respect to voting. They would like to be able to select candidates based on priority, OS family, level of confirmation (e.g. advisory or Bugtraq posting), service, and other options. MITRE will re-evaluate its internal priorities to see when it can support this need. The attendees also stated that they did not see a problem with having MITRE be included as a legitimate voter (current voting rules do not allow this). The voting requirement could be modified to allow for "3 ACCEPT votes, not including the discoverer of the problem." Also, participants outlined a requirement that a voter should be "reasonably certain" that a candidate has been verified as a real issue before voting to ACCEPT it. This certainty could be as definite as having the voter validate the issue themselves, or as indefinite as trusting the source of the information; no explicit requirements for "certainty" were specified. The voting-related web site could be used to allow Board members to annotate their votes in order to describe their level of confidence in whether an issue exists or not. Attendees also discussed adopting a new ABSTAIN vote, which could be used for Board members who should not vote against problems in their competitors' products (or their own, if voting is not appropriate). A request was also made to support a "conditional REVIEWING" vote in which a Board member is REVIEWING a candidate but does not wish to delay its acceptance in CVE. There were some discussions regarding voter comments. Some voters could be prevented from making some important technical comments if the comments were to be available to the public. Mechanisms for recording private comments were discussed. CVE-Compatibility ----------------- Experiences with CVE-Compatibility were discussed. Several vendors stated that they are getting asked by their customers about whether their product is CVE-compatible or not. One of the obstacles to achieving compatibility was related to marketing, which may drive product development more than engineering. Several vendors discussed issues and problems they encountered while making their products compatible. In general, it was easier to make a product CVE-Reportable (aka CVE-Output) than it was to make it searchable. In the process, some vendors were able to discover duplicates in their own database, use CVE to validate their own information, or expand the references they used. Attendees reviewed a portion of the requirements list for CVE-Compatibility. Tool vendors expressed a concern that the Searchability requirement would impose too much of a development cost at this time, as it could be difficult to design a tool that would select probes or signatures based on a CVE name. The requirement for tool searchability was weakened so that if the vendor provides a mapping to the user, it is regarded as satisfying the searchability requirement. Attendees agreed to let the market decide whether this approach is sufficient. In general, while there was concern that the use of the CVE-compatibility term could be abused, attendees believed that the market (and competitors) would be self-policing in terms of determining whether competitors were compatible or not. They advocated an increased reliance on the Good Faith efforts of organizations who seek to provide CVE-compatible products, with less emphasis on MITRE or other organizations determining the quality of the compatibility. Specific requirements for types of repositories (e.g. tools or databases) were not discussed. Board Business -------------- The attendees agreed that August 2000 is a good time frame for the next face-to-face meeting. They considered several potential meeting sites, including: Microsoft during the LISA NT conference (Seattle), CERT (Pittsburgh), the USENIX Security conference (Denver), and Black Hat (Las Vegas). The issue of Board member affiliations was revisited, i.e. whether Board members were to be viewed as individuals or as representatives for their company. The issue was left largely unresolved. However, attendees believed that a private mailing list would allow Board members to raise potentially sensitive concerns or issues without fear of being seen as representing a company view. Since the Board has in the past advocated having discussions be publicly available, some actions may need to be taken to ensure that the private mailing list is used sparingly, and only for issues that *must* remain private. MITRE also presented its guidelines for restricting the maximum number of Board members that could be represented by a single organization to two, with some ad hoc exceptions (e.g. if an existing Board member moves to an organization that already has two members that serve complementary roles). MITRE re-introduced the concept of "one organization, one vote." Attendees agreed with this approach. Attendees were comfortable with allowing Board members to consult the Editorial Board mailing list on non-CVE issues, provided the issues were related to sharing information and/or discussing "best practices" related to vulnerability information. In cases where the Board as a whole is consulted, it may be appropriate to recognize the contributions of specific "members of the CVE Editorial Board" instead of the Editorial Board itself. CVE-Based Analyses ------------------ Several CVE-based analyses conducted by MITRE were presented. The rationales for the analyses were discussed, such as using them to highlight a concrete "success story" for CVE, to show other potential analysts what could be done with CVE, and to explore the applicability of CVE to these analyses in the first place. Attendees were provided with the results from ID'Net at SANS NS '99. Some IDS vendors expressed concerns that since CVE was focused on vulnerabilities and exposures, that it was not necessarily useful for conducting a full-fledged comparison of IDSes, which focus more on signatures related to attack patterns rather than the exploitation of specific vulnerabilities. Some discussion was also held regarding the vulnerability summary comparison. Since the results were anonymized, and details omitted, attendees could not effectively interpret the results. In general, it was believed that a longer-term effort would provide more reliable data, and that such an analysis should include topics in the summaries that do not map to CVE entries or candidates. MITRE has not yet decided whether it will continue this analysis or not. The role of MITRE, and of Steve Christey in particular, was discussed in relation to the execution and publication of these sorts of analyses. However, strong concerns were expressed with respect to how closely these analyses should be tied to the CVE Initiative and to the Board itself. In general, attendees seemed to agree that it was reasonable to conduct such analyses for the purposes of educating the public about the possibilities of CVE, provided (a) the results were anonymized, and (b) the activities were disassociated from the Board and the CVE Initiative itself. The upcoming use of CVE in ID'Net was discussed. MITRE also told the Board that it expects to conduct CVE-based analyses in the future, for its internal use or for its sponsors, and that Steve Christey might play a part in such analyses. Content Decisions ----------------- This summary assumes that the reader has reviewed the Content Decisions section of Day 2 of the PowerPoint slides for the meeting, which includes a description of each Content Decision as well as some examples. Each of these content decisions (CD's) will be proposed and reviewed over the course of the next few months. As expected, content decisions made for some of the liveliest discussions during the two day meeting. Several CD's were discussed, but some examples did not include enough information for the Board to make well-informed decisions. Some attendees advocated that candidates should be evaluated on an ad hoc basis due to the complexity of the problem, instead of attempting to define more principled approaches. The CD's that were already approved by the Board were reviewed, including CD:DEFINITION, CD:INCLUSION, CD:DIFFUNC, CD:HIGHCARD, and CD:DOT. A long discussion was held relative to CD:CF-DEF-PASS. Most attendees agreed that having a single entry for each different default password would result in a large number of entries and make CVE unmanageable. It was discussed that in some cases, the owner of a password "dictionary" might not even know if a password is a default password or not. Some attendees advocated using a single, high-level entry for "use of a default password." In general, however, attendees agreed that it would be best to use a medium level of abstraction. Breaking down the passwords by service type (e.g. POP, SNMP, login, etc.) was regarded as a reasonable approach. A brief discussion was held with respect to the issue of potential overlap between services that use the same authentication mechanism (e.g. FTP and login using the same password file), but attendees in general seemed to be willing to live with having separate entries even if they produced some overlap. Attendees also discussed the use of Dot Notation for specifying individual default passwords in CVE candidates/entries. Some people advocated that including the specific password would support CVE name lookup, comparison of tools, and user education. Others did not see a need to be specific. Back door passwords were considered a different issue than the one addressed by CD:CF-DEF-PASS, so were not included in the discussion. In general, attendees agreed that it made sense to distinguish between "default" passwords and "blank or easily guessable" passwords. The Board also spent a significant amount of time on the Same Attack/Same Codebase debate (CD:SF-CODEBASE). The initial discussion of CD:SF-CODEBASE was intended to decide what to do in the cases when there is not sufficient information to determine if two problems arise from the same codebase or not. Most of the discussion, however, focused on whether the Same Attack or Same Codebase approach was better for CVE, even though the issue had been finalized in July 1999. (See http://cve/Board_Sponsors/archives/msg00142.html, http://cve/Board_Sponsors/archives/msg00182.html, http://cve/Board_Sponsors/archives/msg00213.html, http://cve/Board_Sponsors/archives/msg00217.html, http://cve/Board_Sponsors/archives/msg00232.html, and all followups to these emails.) It was noted that many of the Board members at the face-to-face had not been on the Board during the time of the initial discussions. There was not a clear way to resolve the dilemma in which later Board members may strongly disagree with decisions that were made by an earlier "version" of the Board, or how to address the inconsistencies in CVE if changes were adopted. CD:SF-EXEC was also discussed, but the examples did not provide sufficient details to make any concrete decisions. In general, attendees believed that if problem A in one executable was always present with problem B in another executable, and A and B were fixed by the same patch, that it made sense to keep A and B within the same entry. The Board also reviewed CD:EX-BETA. Attendees agreed that CVE should include problems in beta software, provided that the beta code was intended for public dissemination. CD:EX-CLIENT-DOS was also discussed. Most attendees agreed that it was reasonable to exclude a client-side DoS from CVE, provided: (a) the DoS was limited to the client application itself, and (b) the DoS could only be triggered by a passive attack (i.e. in some way it must be initiated by the client). CD:EX-ONLINE-SVC was also discussed. While most tools would not include problems related to online service providers such as Hotmail or DoubleClick etc., the attendees recognized that these types of problems could be of concern to consumers. A general rule of thumb was discussed, namely: if the "fix" to the problem can be performed by the online provider on a universal basis without any user intervention, then the problem should be excluded. Anything that required "client-side" action (such as installing a patch) should be included. Finally, the attendees discussed CD:DESIGN-WEAK-ENCRYPTION. Most attendees agreed that vulnerabilities related to trivial encryption such as XOR should be included in CVE. There were no concrete conclusions made as to whether "weak" encryption should be included in CVE or not, although in general it seemed that the attendees favored excluding weak encryption from CVE. There was not sufficient time to discuss the other content decisions. They will be proposed to the Board and discussed at a later date. Future Efforts -------------- MITRE presented some of its internal goals for CVE, which includes an attempt to expand CVE so that it provides 80% coverage of security tools. A concerted effort could take place in which participants would work more closely to achieve this level of coverage. Participants would receive backmaps and could help determine which legacy candidates get created and proposed first. Participants would be required to vote more actively on those candidates. Some members expressed interest in this effort, which could take place within a "working group" of the Editorial Board. MITRE also asked participants to send a full database dump so that it could better prepare the next clusters of legacy candidates for voting by the Board. This would help MITRE to prioritize which legacy candidates to propose first, as well as providing extensive backmaps to potential voters which could in turn speed up voting. A more limited effort was performed in November (with the "top 100 lists"), but there was very little overlap in all the submissions that were sent in. Several organizations agreed to provide their databases. MITRE is willing to sign non-disclosure agreements if necessary. Other goals were identified, including: (a) achieve 700 entries by May 1, (b) resolve 15 content decisions by May 1, (c) create candidates (and then entries) for all security advisories published in 1999, (d) achieve 1000 entries by September 1 (with an intermediate goal of 850 by July 1), and (e) have MITRE propose a total of 1000 additional legacy candidates by September 1. The attendees also expressed a strong desire that CVE should encompass non-vulnerability-related IDS signatures, e.g. port scanning activities. The attendees agreed that the current focus should remain on vulnerabilities and exposures. An IDS "working group" of the Board may be created to discuss IDS-related issues.