Most regulations and industry standards require organizations to continuously monitor their systems, networks, and software to mitigate the risks arising from malicious actors evolving their methodologies. However, most organizations use a combination of products to streamline business operations. Monitoring for new vulnerabilities across diverse tools, however, only provides security protection if companies can create baselines and metrics for measuring security. Common vulnerability and exposures (CVE) are one way that organizations can track security issues across divergent software, network, and systems to gain a holistic view of their cybersecurity risks.
What is the Common Vulnerabilities and Exposures (CVE) list?
The Common Vulnerabilities and Exposures (CVE) list is a “dictionary” that created a common, standardized naming convention for system, network, and software vulnerabilities so organizations can share information about new risks and create baselines for evaluating cybersecurity tools’ and services’ effectiveness.
According to the official CVE website, a CVE is:
- A single identifier applied to a single vulnerability or exposure
- A standardized description for each vulnerability or exposure
- A dictionary rather than a database
- A common language for disparate databases and tools
- A way to support interoperability and stronger security
- A basis for evaluation among services, tools, and databases
- Free for public download and use
- Industry endorsed
For example, your organization may allow employees to choose a laptop running either Mac or Windows operating systems. Without the CVE list, your IT department would need to reconcile vulnerabilities named by Apple and by Microsoft. This process would mean monitoring new vulnerabilities to each operating system, reconciling the divergent naming conventions, and making sure to update the software appropriately.
The CVE list removes the reconciliation step which streamlines the security patching process. Since security and IT departments can monitor vulnerabilities based on a standardized name, they can more easily prioritize patches by focusing on those with the same CVE, regardless of what operating system, software, or network they use.
What is a CVE entry?
Each CVE entry includes an identification number, description, and public reference documentation.
CVE ID
The CVE ID is a number that includes the year the ID was assigned or the vulnerability was made public. When looking at the year of the CVE ID, keep in mind that the vulnerability could have been discovered earlier without being published or made public. The year only indicates when the vulnerability was added to the dictionary.
CVE Description
The CVE description provides enough details to help users find the CVE entry or be able to differentiate similar-looking vulnerabilities. Generally speaking, they incorporate information such as affected product/vendor, a summary of the different versions of the product affected, the type of vulnerability, what the vulnerability does, type of access attackers need to exploit the vulnerability, and code components/inputs involved.
For example, a recent CVE includes the following description:
Unnecessary fields in the OpenTrace/BlueTrace protocol in COVIDSafe through v1.0.17 allow a remote attacker to identify a device model by observing cleartext payload data. This allows the re-identification of devices, especially less common phone models or those in low-density situations.
What the description tells the reader is:
- Affected product/vendor: COVIDSafe
- Summary of versions: “through v.1.0.17” (meaning any versions prior to the 17th update)
- What the vulnerability does: “re-identification of devices” means that the anonymous data collected can be traced to a specific device thus undermining the user’s privacy
- Type of access attackers need: Access to unnecessary fields in the OpenTrace/BlueTrace protocol
- Code component/inputs involved: cleartext payload data
CVE Reference Documentation
The reference documentation is often provided as a link to a document or website that provides information about the researcher and research conducted. It provides the technical details about the devices impacted and programs impacted, as well as how the researcher went about finding the vulnerability.
What doesn’t the CVE list provide?
From an organizational perspective, the CVE list does not provide insight into the risk level or enterprise impact a CVE can have. The “impact” discussed in the CVE is usually how attackers can leverage the vulnerability to steal information. However, the listings give no indication about the potential likelihood of vulnerability use, data type risk level, or financial impact on organizations.
Why should companies monitor for CVE?
Even though the list provides no risk tolerance information, companies need to incorporate CVE monitoring as part of their cybersecurity strategies. Malicious actors continuously look for new ways to leverage CVE as entry points into systems, software, and networks. Generally, once providers or vendors know about a vulnerability, they release security patches to prevent cybercriminals from exploiting the CVE.
Organizations need to continuously monitor their ecosystems for CVE and apply security patch updates to reduce the risks arising from these vulnerabilities.
How do companies use the CVE list to evaluate cybersecurity products?
When looking to incorporate a security tool, organizations should start by ensuring that the service or solution can cross-reference the CVE entries with other weapons in their cybersecurity arsenal.
For example, some tools may be focused only on macOS while others on Windows. If your organization uses a combination of operating systems across the enterprise, then you need to make sure the tool is compatible with both or that you can cross-reference between multiple tools efficiently.
SecurityScorecard enables continuous monitoring for CVE risks
SecurityScorecard’s security ratings platform uses non-intrusive scan data to fingerprint services and associate products to CVE. We monitor an organization’s IT ecosystem across ten risk factor groups including DNS health, network security, IP reputation, patching cadence, endpoint security, web application security, information leaks, social engineering, and hacker chatter.
