What is a CVE?

In this article, we will take a look at the CVE system and how the information may be used to keep track of, and manage, vulnerabilities.

CVE definition

The Common Vulnerabilities and Exposures (CVE) system aims to provide a consistent naming scheme for information security vulnerabilities, similar to that of the periodic table and animal classification. This makes it easier to both keep track of vulnerabilities and help communicate information to others using the same references.

According to NIST, a vulnerability is:

“A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.”

The CVE system is maintained by the Mitre Corporation, a nonprofit organization funded by the U.S. Dept. of Homeland Security, and has been running since 1999. Mitre is also behind other security-related resources like:

• CWE – an enumeration of weakness types in software and hardware
• CPE – a naming scheme for uniquely identifying software, systems, and packages
• CAPEC – an enumeration and classification of attack patterns for applications, such as SQL injections and clickjacking
• ATT&CK – a set of network defense tactics

When a vulnerability is discovered, it is assigned a CVE identifier, known as a CVE-ID. The CVE-ID is of the form “CVE-YEAR-XXXX”, e.g., CVE-2014-6271. Since 2015, the length of “XXXX” is variable, but at least 4, to prevent the Y10K problem. The graph below shows the number of identified vulnerabilities from 1999 to 2019.

What are CNAs?

Organizations that are authorized to assign CVE numbers are known as CVE Numbering Authorities (CNAs), with Mitre as primary CNA. Participation is voluntary and CNAs have the ability to control the disclosure of information about vulnerabilities. At the time of writing, there are 129 organizations from 21 countries participating as CNAs. A CNA may be security researchers, bug bounty programs, and vendors. Many vendors assign CVE-IDs to their own products, such as Apple and IBM.

How to become a CNA

Some of the benefits of becoming a CNA include the ability to assign CVE-IDs, streamline the disclosure process, communicate information regarding vulnerabilities to customers, and to show maturity in the vulnerability management process.

So, how do you become a CNA?

The following requirements need to be fulfilled:

• You must be a vendor with a significant user base along with established security advisory capabilities, or an organization acting as a neutral interface between researchers and vendors.
• Have a public vulnerability disclosure policy. The policy should include the expected timeframe and conditions to publish the vulnerability information. Here, the scope should also be stated, i.e., what components are covered and not covered, and whether end-of-life components will be covered or if other CNAs then should take responsibility instead.
• Have a public source for new vulnerabilities.
• Agree to the CVE Terms of Use.

If you meet the aforementioned requirements, you can contact the CNA coordination team and attend an introductory session.

CVE information

A CVE entry contains the following information:

• CVE-ID – the unique identifier for the vulnerability.
• Description – a short summary of the vulnerability, usually containing information about the affected version(s) of the product and what an attack might lead to.
• References – a list of references to complementary information about the vulnerability or exploit code.
• Assigning CNA – which authority that assigned the vulnerability a CVE-ID.
• Date Entry Created – the date when the CVE-ID was allocated. This date does not necessarily indicate when the vulnerability was discovered. This is due to CNAs often requesting a block of unassigned CVE-IDs beforehand, to be used when new vulnerabilities get discovered.

Assigning CVEs

Before assigning a CVE-ID to a vulnerability, we must first determine if the claimed vulnerability is an actual vulnerability. There are numerous definitions of what a vulnerability is depending on the industry, regime, and culture. To make determination and assignment fair and adaptive, there are rules determining who gets to claim a vulnerability. There are three rules for entities able to claim a vulnerability, described next.

Product owners

If the product owner acknowledges the vulnerability, then it is a vulnerability, even if the vulnerability is inherited and upstream vendors disagree.

If the software owner does not acknowledge the vulnerability, if the software owner can not be contacted, or if the software owner is unknown, the other entity rules may be used.

CNAs – policy-based model

Here, the CNA decides if there has been a security policy violation, i.e., if it is a vulnerability. This is known as a policy-based model. The benefits of this model are that the accuracy tends to be high, and the assignments are more consistent. However, users and vendors might not agree on security policies, and the policies may be undocumented.

Reporters – claim-based model

Here, the reporter claims that there is a vulnerability present, and the reporter shows that the vulnerability has a negative impact. This is known as a claim-based model. The benefits of this model are the speed and ease. However, it requires trust in the reporters, the results may vary in levels of abstraction, and opinions differ on the interpretation of negative impact.

NVD

There are multiple sources from where you can retrieve CVEs. The most used source is the National Vulnerability Database (NVD) by NIST, which derives from Mitre. NVD is a public U.S. government database providing additional information to that of Mitre. For example, NVD staff perform analysis on published CVEs. This results in additional information such as a CVSS score that may be used as one information source when prioritizing vulnerabilities. The CVEs are also categorized according to the corresponding weaknesses using CWE, and they are also assigned a CPE name to connect the CVEs to the vulnerable products and versions. Debricked has now released its own Vulnerability Database for public vulnerabilities, with multiple sources for extra accuracy and precision!

An example of a CVE analyzed by NVD is the ShellShock vulnerability, with information such as:

• The CVE-ID, CVE-2014-6271.
• A short description of the vulnerability.
• The severity, given as a CVSS score. The score for ShellShock is 9.8, putting it in the “critical” category.
• A list of references to mailing lists, third-party advisories, issue trackers and exploits.
• A weakness category given as a CWE number. Here, it is CWE-78 – Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’).
• A list of affected software configurations, given as CPEs, such as “cpe:2.3:a:gnu:bash:1.14.0:*:*:*:*:*:*:*”.

Due to the CVEs being analyzed by humans, there might be a substantial delay from the discovery of a vulnerability until information such as CVSS and CPE is provided.

Data analysts at Debricked have developed machine learning algorithms for immediately and accurately identifying vulnerable software, see this research paper. Based on this, we can provide our customers with timely vulnerability information, allowing remediation even before the CPEs are provided by NIST.

Risks of CVEs

With public databases, such as NVD, moral questions arise, like “Does this give hackers a free list of vulnerabilities?”. While the short technical answer is yes, it is not as bad as it seems. Only publicly known vulnerabilities are listed which means that hackers already know about them anyway. There is also a growing agreement in the security community that information sharing is beneficial for all parties. However, this transparency assumes a responsible disclosure model, a model where  a vulnerability is publicly disclosed after a period of time. This is done to allow the affected parties to have time to patch the products. There is no standardized time for disclosure, and several policies are used, such as:

• Google Project Zero has a 90-day disclosure policy, starting after notifying the vendors, after which the information is released to the public.
• The Zero Day Initiative (ZDI) has a 120-day policy, starting after receiving a response from the vendor.

The time also varies based on how severe the vulnerability is. For example, the Meltdown vulnerability affecting several Intel x86 CPUs was disclosed 7 months after discovery.

In conclusion, the CVE system is a great initiative, and a useful tool for any organization working with software and hardware. The public databases allow for instant lookup of vulnerabilities in software/hardware components, which every company should do before using third-party components. Debricked automates this process in an efficient manner. This way, companies can spend their valuable time elsewhere.