CVE Board Meeting summary - 23 January 2019

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

CVE Board Meeting summary - 23 January 2019

Jo E Bazar

CVE Board Meeting – 23 January 2019

Board Members in Attendance

Mark Cox, Red Hat, Inc.

William Cox, Synopsys, Inc.

Kent Landfield, McAfee

Pascal Meunier, CERIAS/Purdue University

Beverly Miller, Lenovo Group Ltd.

Scott Moore, IBM

Lisa Olson, Microsoft

Kurt Seifried, Cloud Security Alliance

Takayuki Uchiyama, Panasonic Corporation

Kathleen Trimble, U.S Department of Homeland Security (DHS)

Members of MITRE CVE Team in Attendance

Jo Bazar

Chris Coffin

Jonathan Evans

Chris Levendis

Lew Loren

Joe Sain



2:00 – 2:15: Introductions, action items from the last meeting

2:15 – 2:30: Working Groups

  • Strategic Planning – Kent Landfield/Chris Coffin
  • Automation – Chris Johnson
  • Cloud Security Alliance – Kurt Seifried

2:30 – 2:45: CNA Update

  • DWF – Kurt Seifried 
  • MITRE – Jonathan Evans
  • JPCERT – Taki Uchiyama


2:45 – 3:00: GDPR update from MITRE (Chris Levendis)


3:00 – 3:30: CNA Virtual and Face-to-Face Summits: Board Suggestions for Topics and Discussions (Chris Coffin)


3:30 – 3:50: Open Discussion Board

3:50 – 4:00: Action items, wrap-up

Review of Action Items from Board Meeting held on 9 January 2019

  • Previous Action Item: MITRE (Levendis) will discuss the impact of GDPR on the CVE Program with its Office of General Council
    • Status: Done. On the agenda to discuss.
  • Previous Action Item: MITRE (Evans/Sain) to work with Microsoft on starting the automated submission process (similar to IBM’s) and document that process
    • Status: Will begin once Microsoft is ready. Targeting February Patch Tuesday based on prior discussion.
  • Previous Action Item: MITRE (Evans) to send out an email to the Board list to initiate the CNA Rules revision process.
    • Status: In process. A list of items is assembled and under review prior to sending to the Board.  Will also target discussions of these items in the CNA Virtual Summit. MITRE (Evans) to draft CNA Rules regarding EOL Scoping issue and Note Field in JSON. MITRE (Evans) will draft up clarifications to CNA rules on the RBP rules and send to the Board for review.
  • Previous Action Item: Schedule 2019 CNA Summit dates and locations.
    • Status: Done. The CNA Virtual Summit will be Tuesday, February 26, 2019 from 4-8PM ET. The CNA Face-to-Face Summit will be at the MITRE McLean campus Wednesday, May 22 and Thursday, May 23, 2019 (times are TBD).  
  • Lisa Olson will reach out to GitHub about being a CNA.


Working Group Updates

  • Strategic Planning – Kent Landfield/Chris Coffin
    • The SPWG meeting is scheduled for Thursday, January 24, 2019. The group will review the Root CVE Numbering Authority (CNA) Roles and Responsibilities.
  • Automation – Chris Johnson
    • No Automation WG meeting this week
  • Cloud Security Alliance (CSA) – Kurt Seifried
    • The CSA is developing an industry survey to gather data about CVE for services. The survey will include recommendations and an overview of the cloud services ecosystem. Kurt will send survey to the CVE Board for review.
  • Quality Working Group (QWG): Dave Waltermire/Chris Coffin
    • QWG Kickoff meeting has been scheduled for Thursday, February 7, 2019, 2:00pm – 3:00pm.
  • CNA Coordination Working Group (CCWG): Tod Beardsley/Chris Coffin
    • Chris Coffin will follow up with Tod about scheduling kickoff meeting.


CNA Updates

  • DWF – Kurt Seifried 
    • DWF announced 2 new Sub-CNAs, Jenkins and PHP, in January 2019. 
    • Kurt expressed the need for more detailed instructional materials for GitHub and associated scripts. MITRE (Evans) took the action to develop a step-by-step checklist.
      • MITRE (Evans) took the action item to develop a step-by-step checklist and perhaps an instructional video or webinar that root CNAs can reference at any time. This is a top priority, due to the CVE Board in 3-6 months.  
    • Kurt recommend using GitHub as the canonical source of data. The way in which CVE has fielded the GitHub pilot is non-standard, which causes confusion with some users. Currently, the MITRE-managed CVE list is the canonical data source, and the GitHub data feeds the MITRE list.
      • MITRE (Levendis) took the action to determine the implications of making GitHub the canonical source of data and what adjustments need to be. MITRE (Levendis) will report back to the CVE Board.  
  • MITRE – Jonathan Evans
    • Johnson Controls resubmitted their CNA example problems, and there are still issues with their answers. This is the third iteration of the submission and approval process. JCI is improving with each submission; the Board recommended that MITRE meet with them and report back to them.
      • Chris Levendis recommended a 3-strike policy (example problems are still incorrect after 3 submissions) where after 3 incorrect submissions a conversation must occur to discuss the path forward. 
    • CNCERT resubmitted their example problems but submitted answers that contained publicly available information rather than writing the descriptions themselves. 
    • ASUSTOR was removed as a CNA due to unresponsiveness.
      • MITRE (Evans) took the action to inform prospective CNAs during the on-boarding process that non-responsive CNAs will be removed from the program. MITRE (Evans) will also ensure that there are multiple contacts for each CNA.
    • Booz Allen Hamilton has been inactive as a CNA for over a year. MITRE will follow up with BAH to determine whether they are capable and want to continue to be a CNA.
    • Several CNAs are completing their Reserved but Public (RBP) backlog for 2018, which is required before they can obtain new ID blocks for 2019.
  • JPCERT – Taki Uchiyama
    • MITRE (Coffin/Evans) met with JPCERT to understand the issues that they are facing as a root CNA. JPCERT requested additional materials on the roles and responsibilities associated with being a Root CNA.

Special Topics

GDPR Update (Chris Levendis)


The GDPR issue was raised because DWF was contacted about removing Personally Identifiable Information (PII) from a CVE ID stored on GitHub. However, the PII information is in the change logs and can only be removed by GitHub. DWF removed the PII information per the users request from the CVE ID.

  • Guidance from MITRE Office of General Counsel (OGC) is that an organization/business is only required to purge PII information from systems that they control. 
  • PII contained in open source project names or URLs falls under the legitimate use provision of GDPR. This means that if CVE entry contains this data, it does not require removal
  • Kurt made the point that even though the PII (email address in this case) is removed from the repository, the email is still accessible from GitHub through the history. This is the way that the GitHub protocol works and there is no way around it. A repository owner could remove this data from the history, but it would require rolling back the repository to when the PII was added, cutting out the transaction that included the PII, and applying all transactions that occurred afterwards. This process would be expensive and still would not remove the PII from any forks of the data that were created by external users.
  • Kurt acting under the DWF Root CNA collects the email address of requesters as part of his terms of use. He stores this email address within his GitHub repository.
  • Because there are several issues involving the DWF Root CNA and because there are some specific GDPR concerns from Kurt, the Board agreed to setup a meeting to discuss the next steps for the DWF Root CNA.  

CNA Virtual and Face-to-Face Summits: Board Suggestions for Topics and Discussions (Chris Coffin)

  • To be discussed at next Board Meeting on February 6.

Open Discussion Items

  • None

Meeting Action Items

Board Decisions

  •   None


Future Discussion Topics

  1. How can we better communicate our future vision of the CVE program? How can we better market the CVE program and communicate the great changes that are taking shape?
  2. How do we provide more status information to the public around metrics and ongoing activities we are engaged in?
  3. CNA Process – Front Door or Back Door; How should CNAs communicate with each other, and how would that information be managed?
  • Set up an excel spreadsheet to share contact info amongst the CNAs
  1. CNA Scope Issues 
  • The Board discussed that CNA documentation around roles and responsibilities are needed. Current documentation is not clear, CNAs assign and populate CVEs within their scope. Scope may or may not cover CVEs for their customers.
  • CNA Rules - The rules state CNAs must be responsive but does not provide a specific timeframe. The rules state if a CNA plans to assign a CVE for a vulnerability another vendor’s product, to the assigning CNA should contact the vendor.  The vendor would then make a determination.
  • New Approach to CNAs and Roots - A given Root has a scope. A portion of the scope gets delegated to a CNA (i.e., product or area of research). If a portion of the scope is not delegated to a CNA, that scope stays with the Root. It is the Root’s responsibility to assign and populate as the CNA of last resort.
  • Action Item – CNA Rules must be updated to reflect this new approach.
  1. Eliminate duplicate CVEs discussion
  • The Board discussed that specifying CNA scope will help eliminate duplicate CVE assignments. Art explained that having open communication with other CNAs when making CVE assignments is critical; keeping this communication at the CNA level (not at Root/Primary level) will help prevent duplication.
  • Recommendation 1: Process recommendation needs to be added to CNA guidance.
  • Recommendation 2: CNA rules must be updated to minimize duplicate assignments.
  • Jonathan Evans explained that duplication of CVE assignments occurs the most with DWF.
  1. Researcher CNAs
  • The Board discussed researcher CNAs that have ambiguous scopes. These CNAs have issued thousands of CVEs.
  • Recommendation 1: Avoid adding any new researcher CNAs until there are specific qualifications and guidelines for what qualifies as a researcher CNA. This includes defined scope rules yet to be discussed.
  • Recommendation 2: Make the scope naturally programmatic for researcher CNAs.
  • Recommendation 3: Change the process for researcher CNAs. Who is responsible for coordinating the assignment of the IDs? Who issues the CVE ID and who populates the information? There should be an easier way for companies to request a CVE ID.
  • Recommendation 4: Better define roles and responsibilities for researcher CNAs.
  • Recommendation 5: Explore the possibility of researchers participating in the CNA program without becoming CNAs.
  • Recommendation 6: Need a testing/certification program for CNAs to make sure they can adequately perform their role, especially researchers.
  • The Board agreed to explore better solutions regarding the researcher CNA ambiguous scope issue.
  1. Operationalize Root CNAs effectively
  • Further discussion is needed regarding how to operationalize Root CNAs more effectively.
  • Additional discussion regarding MITRE’s role in operationalizing roots is needed.
  1. Product Type Tagging/Categorization
  • As the production numbers for CVEs go up, there will be an increasing need to view a subset of the overall CVE master list
  • Define a list of common product areas/domains to be used for categorizing CVE entries (e.g.., Medical devices, automotive, industrial, etc.)
  • The tags/categories should be attached to the products and not to the CVE entries directly.
  • Product listings in CVE User Registry would be a potential location.
  • Can it be automated?
  1. Future of CVSS
  • Assigning multiple CVSS to a single CVE.
  • Hill discussions around CVSS.