During the late 1990s, security professionals were using information assurance tools in concert with vulnerability scanners to detect and remove vulnerabilities from the systems for which they are responsible. There’s just one problem – each security vendor has its own database with little to no crossover. Each vendor’s tool generates its own alert for detected vulnerabilities, and these alerts must be manually cross-referenced between the tools to determine if they are separate issues or multiple alerts for the same issue. This is the scenario which spawned the Common Vulnerability and Exposures, or CVE, List. In January 1999, David E. Mann and Steven M. Christey of The MITRE Corporation published “Towards a Common Enumeration of Vulnerabilities” at a workshop at Purdue University. In addition to wanting to know if multiple tools had identified the same vulnerability or not, Mann and Christey had a desire to compare the breadth and depth of coverage provided by each tool. To facilitate these needs, their whitepaper proposed creating a unified vulnerability and exposure reference list that could be used across participating assessment/IDS tools: the CVE List.
Towards a Common Enumeration of Vulnerabilities
According to the whitepaper, the original plan for the CVE List was for each vulnerability to be uniquely identifiable with no need for manual cross-referencing. The CVE List was also intended to be a complete list of known vulnerabilities and to be publicly accessible without worrying about distribution restrictions. With the CVE List as a vendor-independent resource, it would enable those vendors to make the decisions about how much of an impact the vulnerability would have on their products or systems. The List itself would not provide impact scoring. In the CVE List, vulnerabilities would be limited to showing their standardized ID number, a status indicator (candidate vs accepted/rejected), a brief description of the vulnerability and any reference links to related vulnerability reports and advisories.
How MITRE grew the CVE List
After the presentation of the whitepaper, the group that would become the CVE Editorial Board was created in May 1999 to pull the initial CVE List together. The very first CVE List contained 321 vulnerabilities, chosen after careful deliberation and consideration of duplicates. In September 1999, the first CVE List was made public. MITRE announced the creation of the CVE List during a press conference. It also placed a booth at SANS 1999 to help introduce the List and promote its adoption. In the summer of 2000, MITRE put out a request for legacy vulnerability information with the intent of adding it to the CVE List. This would create a more complete list of known vulnerabilities, especially prior to the inception of the List. MITRE received more than 8,400 submissions, which they whittled down to 900 after accounting for duplicates and by setting aside any submissions with insufficient information or that needed further consideration. By September 2001, those 900 had been further reduced to 562 CVE List candidates. Similarly, as the end of 2000 neared, almost thirty organizations and persons had agreed to participate in the CVE List. Many of these organizations would later form the earliest CVE Numbering Authorities (CNA): Internet Security Systems (ISS), BindView, Compaq, Silicon Graphics, IBM, CERT/CC (Computer Emergency Response Team Coordination Center), Microsoft, Hewlett-Packard, Cisco Systems and Red Hat Linux. Members of these organizations also helped form the CVE Editorial Board and later formed the CVE Senior Advisory Council in 2001.
Taking CVEs to the next level
At a conference in Hawaii in June 2002, Christey delivered a progress report on the CVE Initiative along with Robert A. Martin. Among other information, the report noted that by May of 2002, the CVE List had 2,032 entries, and CVE/MITRE was receiving 150 to 200 new CVE submissions each month. Adoption of the CVE List was further boosted when NIST (National Institute of Standard and Technology) released its Special Publication 800-51 in 2002, where it recommended that U.S. agencies prefer the use of tools that use CVE Identifiers. Two years later, the U.S. Defense Information Systems Agency mandated that information assurance products used in the department use CVE Identifiers, as well. A well-known counterpart to CVE List, the National Vulnerability Database (NVD), was formed in 2005. NVD expands on the CVE List and, like CVE, is sponsored by the Department of Homeland Security’s Cybersecurity and Infrastructure Agency, though they are separate projects. Unlike the CVE List, which intentionally excludes scores for vulnerabilities so as to remain apart from environmental factors, NVD provides vulnerability scoring, which it bases on risk and impact. When provided by vendors, NVD attaches information on fix versions, patches and updates that resolve the vulnerability. Both CVE List and NVD will add reference links to the originating vendor advisories and any other vendor advisories that apply to the specific CVE. When the CVE Senior Advisory Council was formed in 2001, its stated goal was to ensure that the CVE program received the funding and guidance required to maximize the effectiveness and adoption of the CVE program, especially in regards to the US government. Membership in the Council was and is primarily restricted to the senior executives of relevant government organizations. The Council also influences decisions made within the CVE program, though most items not relating to government sponsorship are instead handled by the Editorial Board. By contrast, the CVE Editorial Board has a much broader membership that includes information security specialists such as commercial security-tool vendors, government agencies and academic/research institutions. The Board makes content decisions regarding the CVE List, and many of its members also do outreach work towards expanding the adoption of the List.
The Evolution of Assigning CVE Numbers
In January of 2014, the board determined that the method by which CVEs were assigned needed change; in the then-current state, only up to 9,999 CVEs were allowed per year. Prior to 2014, CVE IDs were assigned using the CVE-YYYY-NNNN format (eg CVE-2020-0791). The January 2014 vote by the Board updated the CVE ID syntax by extending the N portion so that more than four digits could be assigned as needed: CVE-YYYY-NNNNN. Only a year later in January 2015, CVE-2014-10001 was assigned. The Distributed Weakness Filing, partnered with CVE in 2016 to act as a Root CVE Numbering Authority (CNA) for the open source community. At the time, the category of Root CNA didn’t officially have status. Participants were either an organization or individual researchers who reached out to MITRE directly for CVE IDs. The addition of the DWF prompted the CVE board to expedite what they referred to as a federated CVE system where MITRE is the primary CNA that oversees Root CNAs, which in turn oversee sub-CNAs. In addition to re-organizing CNAs into the federated system, the CVE board also updated the rules for how CNAs are allowed to assign CVE IDs. Included in the update were stronger guidelines for CVE submissions to help reduce the potential for issuing CVE IDs for duplicate or invalid issues. By 2018, CVE celebrated the addition of their 100th CVE Numbering Authority and further refined the CNA guidelines and CVE reporting schema. The CVE Board also discussed how to handle cloud service vulnerabilities by reflecting on when a flaw or security issue “counted” for a CVE and who was responsible for issuing the ID if the service was Infrastructure vs. Platform vs. Software. As of 2020, there did not appear to be an official consensus on this matter despite CVEs being issued for cloud service vulnerabilities.
CVE – A core part of vulnerability and patch management
Last year, in 2019, CVE celebrated 20 years of vulnerability enumeration. According to the anniversary press release, CVE had more than 100 organizations participating as CNAs from 18 countries and had enumerated more than 124,000 vulnerabilities. A lot has changed in the 21 years since the CVE List’s inception – both in terms of technology and vulnerabilities. Without the CVE List, it’s possible that security professionals would still be using multiple tools from multiple vendors just to ensure complete coverage. It’s also possible that someone else would have created a service similar to the CVE List. Either way, from idea to whitepaper to database, the CVE List has become a core part of vulnerability and patch management.
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.
