The Common Vulnerabilities and Exposures (CVE) turns 21 this year and, just like any 21-year-old, there have been growing pains along the way. There was even a growth spurt.
In the case of CVE, this happened between 2016 and 2017, when the number of vulnerabilities assigned a CVE ID skyrocketed from 6,447 to 14,714.
Why the sudden increase? Let's start at the beginning ...
In September 1999, MITRE Corporation published a paper titled The Development of a Common Enumeration of Vulnerabilities and Exposures.
"(We are) building a system that can integrate and manage vulnerability information from different sources, such as network assessment tools, intrusion detection systems, and archives, in a database for supporting enterprise security operations," stated MITRE.
MITRE's desire to establish an independent naming authority stemmed from the fact there were already numerous vulnerability databases, all with differing naming protocols. Not surprisingly, this caused confusion among researchers and vendors because, among other things, they were unable to determine if these databases were referring to the same vulnerability.
"The goals of having CVE are to ... assign a standard, unique name to each vulnerability, and exist independently," stated MITRE, also realising that "for CVE to have any impact ... (it) must be openly available to the public, without restrictions on distribution."
MITRE recognised that a public vulnerability database might assist hackers but argued the benefits outweighed the risks. In a pre-social media world, one interesting benefit given was: "Community opinion is shifting towards sharing information ...".
When CVE officially came into being (Oct. 1999), it was designed to deal with a maximum of 1,000 vulnerabilities a year. The year after CVE's arrival the number of vulnerabilities exceeded the 1,000 mark - 1,020 - and, as the years progressed, the quantity of software and hardware ... and vulnerabilities ... escalated. By 2005 the number of assigned vulnerabilities was a whisker away from 5,000 (4,935). Dealing with this volume was proving an issue for CVE and it began looking at ways to address the expanding vulnerability landscape.
CANDIDATE NAMING AUTHORITIES
The September 1999 paper identified a Candidate Naming Authority (CNA) as an entity that could assist identifying and naming vulnerabilities. However, CNAs didn't necessarily speed up the process. This is because between 1999 and 2005 there was a three-step process to naming (assigning) a vulnerability.
First a 'problem' was identified as a candidate - potential vulnerability - and given the prefix CAN e.g. CAN-1999-0345. This step could be done by a CNA, of which there were 23 in 2005. However, for a candidate to become a published vulnerability, the CVE Board had to discuss, review, and vote on whether a candidate was a vulnerability. This had to be done for every candidate. If the Board agreed, a candidate was given CVE status and the prefix changed accordingly, so CAN-1999-0345 became CVE-1999-0345. The final step, populating the CVE ID on the master, published list, was also done solely by CVE.
As a first step to speeding up the process, in 2005 the board vote was eliminated and all entries were automatically given a CVE ID. However, CNAs could still only identify but not populate the list and the multi-step process system remained in place until 2016, by which time 'all things internet' - and the corresponding amount of software/hardware - had continued to increase dramatically. This was matched by a sharp rise in the number of vulnerabilities, the sheer weight of which had once again slowed the process of assigning CVE IDs, resulting in some researchers not receiving a CVE assignment/s.
This was because, at the time, the CVE program operated to a scope (list) of software types for which it would assign CVEs. This scope was created to focus resources on the most important products and, if a product wasn't within the scope, CVE didn't assign and populate the list.
THE WINDS OF CHANGE
"A recent discussion of problems with the CVE system ... has led some to wonder about its future," wrote Linux Weekly News on March 9, 2016. "The problems stem from the difficulty, sometimes impossibility, of getting CVEs assigned for real vulnerabilities. That, in turn, has led some to stop even requesting CVE numbers for vulnerabilities that they find, which further reduces their usefulness."
It's hard to imagine that this was the state of play less than four years ago. But it was. To the point where the online community was beginning to contemplate alternatives, such as OVE IDs: "unique IDs that you may use to refer to software security vulnerabilities (one ID per vulnerability), much like we use CVE IDs", and the Open Source Vulnerability Database (OSVDB): "OSVDB's goal is to provide accurate and unbiased information about security vulnerabilities in computerized equipment."
Thousands of vulnerabilites were going un-assigned and, therefore, unpatched. Additional change was needed.
On March 21, 2016, CVE wrote: "The recent explosion of Internet-enabled devices - known as the Internet of Things - as well as the propagation of software-based functionality in systems has led to a huge increase in the number of CVE requests ... We did not anticipate this rate of growth ... The result has been some of the delay in CVE assignments that the software security community has recently witnessed."
A few months later (June 2016), the Distributed Weakness Filing system (DWF) launched. As the name suggests, the DWF distributed the task of assigning CVE IDs and gave control of cataloguing vulnerabilities to, among others, independent experts, software vendors, and academic institutions.
"Rather than having to submit security reports through a single funnel, anyone within the community can work through a more streamlined reporting mechanism and receive a DWF number," said Kurt Seifried, a security researcher at Red Hat, who built and launched the DWF (which lasted nearly three years, shutting down in March 2019).
While the DWF eased the burden for CVE, it - CVE - already had plans afoot to improve the system in place.
"By the time 2016 came around, CVE was wanting to not only introduce new CNAs, but implement process improvements," said Chris Levendis, the MITRE CVE Project Lead, while speaking with SecAlerts.
One of these improvements was the new-look CNA program, with CNA now standing for "CVE Numbering Authority".
Whereas 'old' CNAs (Candidate Naming Authorities) could only identify a potential vulnerability - candidate - and name it with the CAN prefix, the new CNAs could do what only CVE had been tasked with doing i.e. assigning CVE IDs. Additionally, CVE did away with scope restrictions on what types of vulnerabilities it would publish.
Participation in the CNA program was (and still is) voluntary and organisations must provide CVE IDs for free. They must also have a "public vulnerability disclosure policy" and a "public source for new vulnerability disclosures." If there are any naming disputes, MITRE is the primary CNA and the "CNA of last resort".
CVE AS WE NOW KNOW IT
Allowing CNAs to assign CVE IDs, and eliminating scope restrictions, worked, and this resulted in the growth spurt (6,447 to 14,714) between 2016 and 2017.
"Before the introduction of CVE Numbering Authorities in 2016, CVE populated 100% of CVE entries," said Levendis. "Now the ratio is 60-40 in favour of CNAs. CVE continues to modernize the rules and underlying technologies to make it easier for CNAs to publish CVEs and it's intended that, over time, CNAs will populate all entries."
The list of CNAs grows constantly and, as of July 7, 2020, there were 130 organizations - including Google, Apple, Microsoft, Adobe, IBM, Cisco and Red Hat - in 21 countries.
Publishing times for CVEs are typically down to days or even hours. Where there is variability in publishing times, it is more often due to human factors rather than the CVE operational model.
For example, a vulnerability researcher working with a vendor might take time to validate the CVE in order to make sure it is 'legitimate'. Or it could be something even simpler.
"A researcher might collect a CVE ID for a vulnerability but move on to another project before coming back to the vulnerability," says Levendis. "CVE discourages this but it happens."
CVE has come a long way in its relatively short lifetime. From 894 assigned CVE IDs in 1999 to a high (so far) of 16,556 in 2018, CVE, like any 21yo, continues to change with the times.
"CVE isn't just about MITRE," concludes Levendis. "It's a public-private partnership that grows every day."
