Posted on Jun 8, 2020
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.
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:
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.
Each CVE entry includes an identification number, description, and public reference documentation.
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.
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:
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.
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.
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.
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’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.
Check out our list of 3 top third party risk management (TPRM) challenges, and the actions you can take to bolster your program. Learn more.
Performing cybersecurity risk assessments is a key part of any organization’s information security management program. Read our guide.
Templates and vendor evaluations are needed to level that playing field, in a time efficient and fair way, so that the best vendors are chosen.
Co-founder and CEO, Alex Yampolskiy, speaks about the importance of measuring and acting on key indicators of cybersecurity risk.
You’ve invested in cybersecurity, but are you tracking your efforts? Check out our list of 20 cybersecurity KPIs you should track. Read more.
No waiting, 100% Free
Get your free scorecard and learn how you stack up across 10 risk categories. Answer a few simple questions and we'll instantly send your score to your business email.