CVE Announce e-newsletter — September 30, 2020
Welcome to the latest issue of the CVE Announce e-newsletter. This newsletter is intended to keep you up to date on recent news about CVE, such as advancements in the program, new CNAs, CVE in the news, and more. Common Vulnerabilities and Exposures (CVE®) is the de facto international standard for vulnerability identification and naming. The CVE Board provides oversight and input into CVE’s strategic direction, ensuring CVE meets the vulnerability identification needs of the global technology community. CVE Numbering Authorities (CNAs) consist of vendors, open source projects, vulnerability researchers, industry and national CERTs, and bug bounty programs authorized to assign CVE Identifiers (CVE IDs) to newly discovered issues and include the CVE IDs in the first public disclosure of the vulnerabilities.
Contents:
1. CVE Partners with CISA to Protect Industrial Control Systems and Medical Devices
2. Crafter CMS, Mattermost, Nozomi Networks, and TianoCore.org Added as CVE Numbering Authorities (CNAs)
3. CVE Blog: “Our CVE Story: Ancient History of the CVE Program – Did the Microsoft Security Response Center have Precognition?”
4. CVE in the News
5. Keeping Up with CVE
CVE Partners with CISA to Protect Industrial Control Systems and Medical Devices
The CVE Program recently announced it is expanding its partnership with Cybersecurity and Infrastructure Security Agency(CISA) for managing the assignment of CVE Identifiers (IDs) for the CVE Program.
CISA is now designated a Top-Level Root CVE Numbering Authority for industrial control systems (ICS) and medical device vendors participating as CVE Numbering Authorities (CNAs). CNAs are organizations authorized to assign CVE IDs for vulnerabilities affecting products within a distinct scope. A Top-Level Root CNA, such as CISA, manages a group of CNAs within a given domain or community and may assign CVE IDs to vulnerabilities.
As the Top-Level Root for ICS and medical devices, CISA is responsible for ensuring the effective assignment of CVE IDs, implementing the CVE Program rules and guidelines, and managing the CNAs under its care. It is also responsible for recruitment and onboarding of new CNAs and resolving disputes within its scope.
Establishing CISA as a Top-Level Root consolidates the vast expertise required to effectively assign CVE IDs to ICS and medical device vulnerabilities. This designation as a Top-Level Root enables the rapid identification and resolution of issues specific to those environments. “This is consistent with the CVE Program’s federated growth strategy to scale the CVE Program in a sustainable, stakeholder driven way. The CVE Program is excited to partner with CISA to grow the program to better meet stakeholder needs,” said Chris Levendis, CVE Program Board Member and a principal systems engineer at MITRE.
As the nation’s risk advisor, CISA serves the unique role as a trusted information broker across a diverse set of public and private stakeholders. In this role, CISA fosters increased information sharing to help these stakeholders make more informed decisions to better understand and manage risk from cyber and physical threats.
“Continuing to encourage public and transparent disclosure of industrial control systems and medical device vulnerabilities is a critical mission for CISA. This expansion will encourage more vendors to participate in the CVE Program and allow CISA to better support stakeholders as they become more engaged,” said Bryan Ware, Assistant Director for Cybersecurity, CISA.
CISA ICS will be the Top-Level Root CNA for the following seven CNAs initially:
“The CVE Board is extremely pleased to see CISA step up and provide the capabilities needed to properly address and support the ever-expanding ICS and medical control ecosystems. Vulnerabilities are not just in the IT platforms the CVE Program has covered in the past. Vulnerabilities today can potentially affect life and limb. Being able to quickly assign CVEs to these vulnerabilities allows the communities to work together to rapidly mitigate them,” said Kent Landfield, a founding CVE Board Member.
Read on CVE website or share:
https://cve.mitre.org/news/press_release/CVE_Program_Partners_with_Cybersecurity_Infrastructure_Security_Agency_to_Protect_Industrial_Control_Systems_and_Medical_Devices.html
Crafter CMS, Mattermost, Nozomi Networks, and TianoCore.org Added as CVE Numbering Authorities (CNAs)
Four additional organizations are now CNAs: (1) Crafter CMS for Crafter CMS issues only; (2) Mattermost, Inc. for all Mattermost issues, and vulnerabilities discovered by Mattermost that are not in another CNA’s scope; (3) Nozomi Networks Inc. for all Nozomi Networks products, as well as vulnerabilities in third-party software discovered by Nozomi Networks that are not in another CNA’s scope; and (4) TianoCore.org for software vulnerabilities related to the TianoCore Open Source.
To date, 140 organizations from 24 countries participate in the CVE Program as CNAs. CNAs are organizations from around the world that are authorized to assign CVEs to vulnerabilities affecting products within their distinct, agreed-upon scope, for inclusion in first-time public announcements of new vulnerabilities.
To request a CVE ID number from a CNA, visit Request a CVE ID.
Read on CVE website or share:
https://cve.mitre.org/news/archives/2020/news.html#September182020_TianoCore_Added_as_CVE_Numbering_Authority_CNA
https://cve.mitre.org/news/archives/2020/news.html#September162020_Crafter_CMS_Added_as_CVE_Numbering_Authority_CNA
https://cve.mitre.org/news/archives/2020/news.html#September152020_Mattermost_Added_as_CVE_Numbering_Authority_CNA
https://cve.mitre.org/news/archives/2020/news.html#September152020_Nozomi_Networks_Added_as_CVE_Numbering_Authority_CNA
CVE Blog: “Ancient History of the CVE Program – Did the Microsoft Security Response Center have Precognition?”
Guest author Lisa Olson of Microsoft is a CVE Board Member and Microsoft is a CNA.
Let me tell you something that seems rather strange: Microsoft has been a CVE Numbering Authority (CNA) since before written 
records on such things. How is that possible? Actually, early participants weren’t labeled CNAs until February 1, 2005.
Well, here is a link to our first CVE: CVE-1999-0007. This was documented in our second security bulletin issued June 26, 1998. I wasn’t around the Microsoft Security Response Center (MSRC) then, but it must have been an interesting feat to issue a 1999 CVE six months before 1999 began. Needless to say, Microsoft has been an active participant in the CVE Program for a long time, and we’ve issued a lot of CVEs. As you can see by the chart, the numbers keep growing significantly every year. This crazy year of 2020 we are almost over 100 CVEs per month on average. We think this might have something to do with the fact that researchers might have more time on their hands due to the pandemic, but it also has to do with Microsoft’s bounty programs. The recent changes in the CVE Program having to do with automated Pull Requests to instantiate the CVE corpus definitely help with this growth.
I’ve been in the MSRC and working with CVEs for the last seven years and in that time, the most impressive thing about the CVE Program to me is how nimble it is. We all know how technology is always in a rapid state of change. The combination of Moore’s Law and Metcalfe’s Law that seem to be holding true in the 2020s dictate that we are in a dizzying period of evolution. The wide-spread remote working brought on by the COVID-19 pandemic is fueling this even more.
When a company becomes a CNA, they agree to follow a set of rules that outline when a CVE should be assigned to a vulnerability that is found. In 2019, the CVE Board and the CVE Working Groups took on the challenge of updating the CNA Rules. All of the individuals from CNAs that were participating in the Working Groups were encouraged to bring their unique points of view to the process. There were many robust discussions. Here are some significant changes:
- Clarification was made around assigning CVEs for unsupported products.
- Flattened the process for obtaining CVE IDs and publishing CVEs.
- Changed the rule that restricted CVEs to software that is maintained on premises by the customer (i.e., customer-controlled software). This change allowed coverage of certain cloud, service, and related software vulnerabilities.
This last one caused much debate among the interested parties. Some believed that we needed to document every vulnerability that was found in any service. Others thought that we should keep the rule as it has been and never document service-related vulnerabilities because there would be no action for the customer to protect themselves as the action is taken by the service provider. Eventually, a compromise was reached to allow CNAs to decide if assigning the CVE would be beneficial to the program and the wider industry participants: Does a customer of the service need to do something to protect itself against the vulnerability? Is it important for an industry peer (e.g., another cloud provider) to be aware of the vulnerability? Is it important to the research community that this be publicly documented?
For more information, you can see the relevant CVE Numbering Authority (CNA) Rules here.
We do expect, of course, that the landscape will change over the next decade. Hybrid Cloud deployment is already starting to blur the lines between on premises software and in the cloud. The good news is that the CVE Program can continue to evolve the rules based on these changes in technology. The people that are on the Board and those committed to participating in the Working Groups are empowered to suggest changes and convince others why that change is good for the program.
The thing that is exciting to me is that in all of the meetings that I’ve participated in over the last few years, each and every participant seems sincere in their desire to improve the program. Diverse opinions and robust discussions are welcome. We encourage you to come participate and continue making the CVE Program thrive.
Lisa Olson
Senior Security PM
Microsoft Security Response Center
Comments or Questions?
If you have any questions about this article, please use the CVE Request Web Form and select “Other” from the dropdown menu to contact the CVE Program. We look forward to hearing from you!
Read on CVE website or share:
https://cve.mitre.org/blog/September222020_Our_CVE_Story_Ancient_History_of_the_CVE_Program_-_Did_the_Microsoft_Security_Response_Center_have_Precognition.html
CVE in the News
Microsoft clarifies patch confusion for Windows Zerologon flaw
https://www.bleepingcomputer.com/news/security/microsoft-clarifies-patch-confusion-for-windows-zerologon-flaw/
Cisco Patch-Palooza Tackles 29 High-Severity Bugs
https://threatpost.com/cisco-patches-bugs/159537/
Google Chrome Bugs Open Browsers to Attack
https://threatpost.com/google-chrome-attack/159466/
Vulnerability reporting is returning to normal
https://www.helpnetsecurity.com/2020/08/28/vulnerability-reporting-is-returning-to-normal/
The History of Common Vulnerabilities and Exposures (CVE)
https://www.tripwire.com/state-of-security/featured/history-common-vulnerabilities-exposures-cve/
Keeping Up with CVE
Follow us for the latest from CVE:
@CVEnew - Twitter feed of the latest CVE Entries
@CVEannounce - Twitter feed of news and announcements about CVE
CVE-CWE-CAPEC - LinkedIn showcase page
CVE Blog - CVE main website
CVEProject - GitHub
CVE Documentation - GitHub
CVE Program Channel - YouTube
CVE Announce Newsletter - Email
If this newsletter was shared with you, subscribe by sending an email message to LMS@mitre.org with the following text in the SUBJECT of the message: “subscribe cve-announce-list” (do not include the quote marks). You may also subscribe on the CVE website at https://cve.mitre.org/news/newsletter.html. To unsubscribe, send an email message to LMS@mitre.org with the following text in the SUBJECT of the message “signoff cve-announce-list” (do not include the quote marks).
Common Vulnerabilities and Exposures (CVE®) is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). Copyright © 2020, The MITRE Corporation. CVE and the CVE logo are registered trademarks of The MITRE Corporation. MITRE maintains CVE and provides impartial technical guidance to the CVE Board, CVE Working Groups, and CVE Numbering Authorities on all matters related to ongoing development of CVE.
