Sometimes you don’t know how much you will miss something until you (almost) lose it. That is certainly the case with the news on Tuesday that the MITRE Corporation had not received the funding necessary to continue operating the Common Vulnerabilities and Exposures (CVE) Program past April.
Fortunately, the Cybersecurity Infrastructure Security Agency (CISA) stepped in and extended the contract to continue operating for 11 additional months, buying the community time to establish alternative funding and governance to secure its future. This is necessary; not only are we unlikely to return to the US-funded, MITRE-run CVE-assignment system the industry has known for a quarter-century, we’re better off moving on.
What is the CVE Program?
Similar to the popular tactics-and-techniques MITRE program, ATT&CK, the CVE Program establishes a common language for the security community to communicate in a standardized way about vulnerabilities — a lingua franca for flaws. This ensures that all parties know they are talking about the same flaw, and it disambiguates amongst similar vulnerabilities when necessary.
Tracking vulnerabilities is critically important for all sorts of security-related functions, like attack surface management, intrusion prevention systems, and creating compensating controls and mitigations where patching isn’t always possible. In-house, Sophos consumes CVEs in various ways, including:
- Vulnerability identification and prioritization
- Building detection rules that efficiently target specific indicators of compromise
- Prioritizing protections for Sophos’ own estate, including understanding of the potential impact and consequences of vulnerability exploit and/or the patches needed to address it
- Guiding multiple Sophos processes (including incident response) to keep containment and remediation efforts operating in parallel across the Security Operations and Incident Response teams
- Facilitating communication (including Patch Tuesday work) with vendors and customers
- As a CNA (CVE Numbering Authorities — more on that in a second)
What do the numbers mean?
CVEs are issued by CVE Numbering Authorities (CNAs). These are often software vendors – including Sophos — who issue them to identify vulnerabilities in their own products and then inform MITRE as each number is assigned. Alternately, CVEs can be assigned by CERTs (Computer Emergency Response Teams, generally existing at a national level), or by the CNA-LR — the CNA of last resort, which is the MITRE Corporation at the moment. (The name “MITRE” isn’t an acronym for anything, despite the firm’s origins at MIT.)
CVEs can be issued for any software vulnerability, even if the software vendor does not participate in the CNA program. They are usually notated as CVE-YYYY-NNNNN, where YYYY is the year and NNNNN is the number. They are not issued strictly sequentially, so the number is simply a unique identifier, not a counter of found vulnerabilities. (The numbering system isn’t perfect; larger CNAs issuers are assigned blocks of numbers for convenience, so now and then there will be a “gap” in the numbers between blocks, and sometimes two CVEs are assigned to vulnerabilities that turn out to be the same vulnerability.)
CVEs themselves are not without controversy as there is always some debate as to what constitutes a “software vulnerability,” and it can often be difficult to tell if a given vulnerability is exploitable when a software component that is vulnerable is used in a larger project. (This is a topic for a potential future post, where we can talk about what happens when a CVE gets tangled up in Software Bills of Material (SBOMs) and other well-meaning attempts at governance.)
What happens in a world without CVEs?
Do you ever find it confusing that the same threat actors known as APT29 are also known as IRON RITUAL, IRON HEMLOCK, NobleBaron, Dark Halo, NOBELIUM, UNC2452, YTTRIUM, The Dukes, Cozy Bear, CozyDuke, SolarStorm, Blue Kitsune, UNC3524, and Midnight Blizzard? Welcome to a world where we all describe something in a way that is convenient for ourselves, but in an uncoordinated fashion. This also applies to malware names, especially in the past — just look at a list of detections on Virus Total. Not pretty.
Having a centralized authority to uniquely “name” and describe vulnerabilities, and to provide the result in a machine-readable format, enables both people and tools to address the same root problems without ambiguity. There have been ongoing problems with the National Vulnerability Database (NVD), operated by the National Institute of Science and Technology (NIST), and any further disruption to the CVE system could make it even more difficult for defenders to effectively monitor and protect vulnerable systems.
A better future
Now, with the here-then-gone-then-here-for-now drama around CVE Program funding this week, we have arrived at the fork in the road. There are three probable ways to proceed, and it is still unclear which, if any, will gain consensus.
We could of course proceed, at least for the next 11 months (the duration of the funding allotment announced Wednesday), with business as usual. The US government in one form or another has funded the operation of the CVE Program for 25 years. The industry could breathe a sigh of relief and assume they will continue to do so, but this seems unlikely and shortsighted. A system that is important to the entire globe should not rely on a single government for its operations. This week’s funding scare made this clear.
There is an alternative path. Long-time board members active in the CVE Program have developed a plan to transition its governance to a non-profit foundation independent of the US government. The CVE Foundation would be more international in nature and have independent funding for its operations. This is likely the best approach, even if many of the CVE board members would likely still be US-centric. Diverse sources of funding combined with a more global-minded board would likely result in a more stable and trustworthy system, albeit with more bureaucracy and with a different public-private mix of influences.
The third “fork” was put forth by CIRCL – Computer Incident Response Center Luxembourg, a CERT of the type mentioned above. Known as GCVE, it proposes a decentralized system for CVE issuance and governance. The proposal has many interesting ideas, including backward compatibility, but it likely creates other challenges. Sometimes you need a common set of definitions and a board to enforce them. Allowing for variable guidelines per CNA sounds like a recipe for disaster and confusion. Within the existing CVE system, we have consistency, which may not always be to everyone’s liking, but it is a set of rules, and we know how they work.
Conclusion
The CVE Program, like any system created by a committee, is flawed. Yet, it is the least flawed we have been able to derive, and it is led by a group of industry experts who truly understand the problem space and want to deliver the best outcomes possible. This would be a terrible time to throw out the baby with the proverbial bath water.
We should all throw our weight behind a more financially independent and internationally representative version of what we have. Balkanization of this space, as Russia and China have attempted, will result in a less informed community tilted toward offensive threat actors rather than defenders.
The CVE Program has served us so well that most of us have taken it for granted and just assumed it will always be there. The CVE Board’s volunteers are respected industry figures and have refined and improved this system for 25 years, and we would be privileged to see it serve and continue to improve for the next 25.
Acknowledgements
Darshan Raghwani contributed to the development of this post.
