|
|
Editorial Board Teleconference - October 31, 2012 ================================================= Attendees --------- Editorial Board: - Kent Landfield, McAfee - TK Keanini, nCircle - Brian Martin, OSVDB - Art Manion, CERT/CC - Ken Williams, CA - Adam Shostack, Microsoft - Harold Booth, NIST - Andy Balinsky, Cisco Non-Board: - Dave Waltermire (NIST) - Kurt Seifried, Red Hat (representing Board member Mark Cox) MITRE: - David Mann - Steve Christey - Bob Martin - Jonathan Evans CVE Scope --------- David Mann reviewed the definition of CVE's scope in terms of sources and products, as covered in more detail in mailing list discussions. David asked for final feedback on the list of sources and products. Nobody had additional feedback. Harold Booth asked whether this list would remain static, and whether there will be an opportunity for Board members to provide additional suggestions for potential sources. MITRE intends to review and revise the list periodically . perhaps once a year - but Board members can also provide input, which will ensure a feedback loop to ensure consistent review of this list between MITRE and the Board. ITSAC Global Vulnerability Reporting (GVR) Recap ------------------------------------------------ David Mann presented recent GVR activities, including the GVR panel at the ITSAC conference as held earlier in October. ITSAC topics included the notion of promiscuous or global ID syntax, the need for changes to CVE ID syntax to support more than 10,000 IDs in a year, MITRE.s intention to help in GVR discussions without leading it. Kent Landfield stated that the ITSAC panel was a good starting point and a useful lead-in to the upcoming meeting in Kyoto. CVE ID Syntax Changes --------------------- Steve Christey covered potential changes to the current CVE ID scheme, which only supports 10,000 unique identifiers per year (the .CVE-10K Problem.). With MITRE’s content production team growing, and with various process improvements taking place, it is possible that in late 2013, CVE could exceed 10,000 identifiers for that year. There is a working assumption that any modification to the current scheme will force changes by CVE consumers and providers. However, the community was able to handle the "CAN-" prefix change without much problem. Multiple criteria for a "good" syntax were outlined, including a large ID space, good usability and ease of adoption by consumers, low maintenance/adoption costs for providers, and immediate versus delayed impact of any scheme change. For example, some schemes would not have any apparent changes until 10,000 identifiers are produced in a single year, which could give some extra time for providers to adjust. Several options for ID syntax were provided. Details will be posted to the mailing list for full discussion by all Editorial Board members, but they are summarized below: 1) Year plus arbitrary digits, no leading 0.s (examples: CVE-2013-1234, CVE-2013-12345; CVE-2013-0056 would be preserved) 2) Year plus extra digits, with leading 0.s (e.g. CVE-2013-01234 or CVE-2013-012345) 3) Year-plus-4: non-standard year plus 4 digits (e.g. CVE-1013-nnnn, CVE-3013-nnnn) 4) Year-plus-4: Year plus 4 hex digits (CVE-2013-A9E4) 5) Year-plus-4: Year plus 4 alphanumeric (CVE-2013-ZW1K) 6) Year plus arbitrary digits plus check bit, aka CCE style (CVE-2013-12345-6) 7) CERT-VU/JVN style (CVE#12345678) While there was insufficient time to discuss the subtleties and ramifications of each scheme, here were some themes: 1) Backward compatibility for older IDs was needed . i.e., for CVEs released before the ID change, they should not necessarily be renumbered. This would preserve usability of IDs in older academic papers, advisory documents, mailing list and web site archives, etc. 2) Some participants were supportive of making the new ID scheme appear as similar as possible as the old scheme. This would minimize adoption costs and reduce consumer confusion. 3) Kent Landfield talked about adding additional digits to the end. He believed this would be the least impactful from a coding perspective for just about anybody. This wouldn't change the sorting, display, usage, or retrieval of IDs - mainly the same format. For some of the newer or more radical syntax, this would change how CVE numbers are parsed initially, which would have a larger impact on the community, and it would be less intuitive for users. It would introduce new issues they have to deal with (e.g. bad year encoding). It would lose the ability to discern identifiers from a human perspective. The "New School" items (i.e., CCE-style, CERT-VU-style) would require more effort for adoption. 4) Art Manion explained that the CERT-VU structure served a different purpose; they did not want IDs to be sequential or to reflect when an ID was assigned. There were underlying mathematical formulas, but they helped CERT/CC to ensure that a unique ID could be generated. Art did not think that these requirements were relevant to CVE. 5) Harold Booth asked other Board members what their requirements for the ID are. There was not sufficient time to explore this with all participants, however. 6) TK Keanini suggested that the proposed schemes did not have an important property. He suggested that a "CVE 2.0" ID syntax should be able to make it very obvious to consumers that the ID is not a "CVE 1.0" style ID. To support backward compatibility, a CVE-2.0 identifier could add a suffix to the end of a CVE-1.0 style identifier. As long as the new format for CVE-2.0 identifiers is "outside the boundaries" of a CVE-1.0 identifier, then all CVE-1.0 identifiers would be backward-compatible. 7) Adam Shostack agreed that the old-style format should not be broken. (After the telecon, David Mann told the CVE team that ISBN numbers were extended from 10 to 13 characters to increase the space of potential identifiers while preserving backward compatibility, and it was easy to distinguish between identifier versions based solely on their length.) CVE ID Transition Plan ---------------------- Assumption - many consumers/providers will need 6 months or more to fully adopt a new syntax. MITRE could support old and new IDs beginning in January 2013, and possibly move to only new IDs for January 2014. However, simultaneous support for dual schemes could still have an impact on CVE providers, since some consumers would begin using (or searching for) new IDs as soon as they were published. Andy Balinsky asked if the idea for the new ID scheme was to have it finalized and up-and-running by 2013. From Kent's perspective, it could take 8 or 9 months for products to adopt and get supported. Also need a PR effort to get the community to understand that CVE 2.0 is a new thing that requires some preparation. Kurt Seifried advocated use of a 6-digit approach with leading 0 characters, and thought that an alphanumeric scheme would not work well. FIRST GVR Summit Discussion --------------------------- David Mann told the Board about the upcoming Forum of Incident Response and Security Teams (FIRST) technical colloquium in Kyoto, Japan, from November 13 to 15. This colloquium will feature a "Future of Global Vulnerability Reporting Summit," hosted by JP-CERT and the Japanese IPA. A detailed description and request for comments will be posted to the mailing list. MITRE will attend this summit, but we would like to get feedback from Editorial Board members before then, with the hope of representing an Editorial Board consensus at the summit. The MITRE CVE team believes that FIRST is the appropriate venue to have GVR discussions, but also emphasized that MITRE CVE itself needs to continue to focus on achieving consensus on its defined scope - i.e., focusing on the English-based software market, using a list of full and partial coverage sources and products, based on input from the Editorial Board. MITRE recognizes the effort that Masato Terada and JP-CERT/IPA has put into supporting CVE, such as providing English translations for Japanese-only product vulnerabilities and advocating a global dialogue about vulnerability identifiers. Note that disclosure practices appear to differ by region. For example, disclosure in Japan is largely coordinated, and there is no equivalent to Bugtraq and the full-disclosure movement. With regulatory and cultural differences, disclosure practices may evolve differently. We have identified 3 main options for approaching the GVR problem in the coming months. Additional details, along with strengths and limitations of each option, will be posted separately to the mailing list. Option 1 - "Global CVE" - borrowing from the current relationship between CVE and JP-CERT, establish relationships with other CERTs or ID-issuing organizations in foreign markets, then train them as Candidate Numbering Authorities (CNAs). Option 2 - "Create a new ID Syntax" - Extend the current GVR discussions for "promiscuous" IDs to create a new ID syntax that could be used globally. Option 3 - "Wait, Let Markets Mature, and Reassess" - Let disclosure practices and coordination continue to evolve in different markets; postpone definition of a new ID scheme until there is more maturity and clarity. ** Board Discussion ** Harold Booth - doesn't think options 1 or 2 are feasible; is working within IETF on a format for exchanging vulnerability information that is similar to CVRF but also contains support for cross-referencing different ID schemes. He will post a pointer to the Editorial Board mailing list. Kent - the Kyoto meeting is intended to start the discussion, use the 3-day meeting to discuss the issues in depth, get perspectives beyond the USA, and begin the dialog. Art Manion - agrees that MITRE/CVE scope cannot be global. FIRST is a good place to try to start off - some non-US opinions would be good. Since the 2012 ITSAC meeting, a way forward might be allow the markets to develop. Asked Harold Booth - is there a format to relate vulnerabilities and share information? Harold will forward his ideas (IETF track) to the Editorial Board mailing list. It is similar in concept to CVRF but contains a separate section for aliasing, which would support a global ID scheme. Harold believes that neither Option 1 nor Option 2 is feasible at this time. Dave Waltermire suggested that part of the outcome of this effort might be to support different vulnerability-exchange formats. Andy Balinsky asked whether there was synergy between the new CVE ID scheme and what could happen in GVR? Ideally, CVE could follow the same scheme that is adopted by GVR. Steve Christey said that the timing isn't right. The CVE-10K will happen soon (maybe in 2013), and the global ID scheme could take years to develop. So, the timing is not ideal. Also, the current issues with CVE IDs can be distractions in the larger GVR discussions, so addressing the CVE ID problems now would be helpful. The teleconference ended with a comment implying that the delay between Editorial Board meetings has been too long lately. MITRE will take this into consideration. |