In September 2023, an announcement went out: Chrome, Firefox, Edge, and Safari all contained a vulnerability that left them open to attack. But even before the security community found out about the vulnerability, it was already being exploited in Chrome and Safari. That means attackers had also discovered the vulnerability and had started using it to gain control of users’ devices—including, in some cases, installing Pegasus spyware without the user having to do anything, an emerging attack strategy known as “zero-click malware.”
Vendors of these browsers immediately set to work releasing an emergency patch and notifying the security community. That vulnerability became officially known as CVE-2023-4863, just one of over 21,000 vulnerabilities reported by Q4 of 2023, according to CVEdetails.com, an open vulnerability database.
In this post, we’ll go behind the scenes to explore what happens when a new vulnerability is discovered, how the security community is alerted and shares information, and what organizations can do to protect themselves.
What is a CVE (Common Vulnerability and Exposure)?
The Common Vulnerabilities and Exposures (CVE) system is the common standard for identifying and referring to software vulnerabilities. It was created in the late 1990s out of a recognition that the cybersecurity community needed a standardized system to universally track vulnerabilities. Up until then, the security community had had trouble sharing information since not all organizations were tracking and logging the same data or referring to vulnerabilities in the same way.
The MITRE Corporation, a nonprofit organization, took the lead in developing the CVE system, which was launched in 1999. They designed the standard to be vendor-neutral, enabling knowledge sharing across organizations and around the world, as well as creating a common language for discussing vulnerabilities and strategic planning.
Since then, the system has taken off, with iterations and improvements over time to address feedback and changing needs; today, it is hands down the global standard, and most IT pros wouldn’t dream of referring to a vulnerability without listing its CVE identifier.
Originally, just a few organizations were able to assign CVE identifiers. However, as the program grew, MITRE established a system of authorized CVE Number Authorities (CNAs), responsible for assigning the CVE identifiers as well as publishing CVE records within their assigned scope. There are currently 317 CVE Numbering Authorities (CNAs) from 37 countries, all sharing in the work of assigning a unique identifier to every newly discovered vulnerability.
Many CNAs are single-vendor; take Microsoft, Cisco, and Google, which are all authorized to report only on issues affecting their products. Some are governmental, such as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Swiss National Cyber Security Centre (NCSC). Others, meanwhile, are open-source, for example, Docker and Eclipse, or bug bounty organizations, such as HackerOne. Still others, like VulDB, are purely research-oriented.
The next section will explore how the CVE system works in practice.
The Importance of the CVE Database
When a new vulnerability is discovered, the CNA responsible for the vulnerable product (e.g., Microsoft for Microsoft products), determines whether the vulnerability meets four specific criteria. If it meets these criteria, it will assign a new CVE:
- Independent. The vulnerability must stand alone, meaning it is not dependent on or connected to other problems or vulnerabilities. This way, each CVE addresses a specific security concern, making it easier to pinpoint and remediate the threat.
- Vendor acknowledgment. The software vendor generally acknowledges the existence of the vulnerability, which lends credibility to the CVE and helps ensure that it is based on a genuine security issue
- Proven risk. It must have the proven potential to cause harm or compromise security. This helps avoid tying up the CVE system with speculative or extremely low-impact issues.
- Single codebase affected. It must impact a single codebase or product so that the CVE is clear and precise in identifying the software or system affected.
Each CVE created must contain the following standard components:
|CVE Identifier||Unique alphanumeric code assigned by a CNA|
|References||Links to external information sources to aid further investigation and mitigation|
|Description||Concise overview of the vulnerability, including its nature and potential impact|
|Status||Public or Reserved, i.e., hasn’t yet been publicly disclosed|
The following components are deprecated, meaning they are not generally used today but may still be seen in older vulnerabilities:
|Phase||Current status in the vulnerability management process; phase for all newer CVEs is “Assigned”|
|Votes||Only used before 2006, represents a community consensus count since CVEs were reviewed by the CVE board (a process that no longer happens)|
|Comments||Additional insights and information|
|Version & Modification History||Entry creation and update details|
Because the CVE system is vendor-independent, tools including vulnerability scanners, patch management systems, and incident response tools can all use open CVE databases to identify and track vulnerabilities. This gives organizations a more unified view of their security posture and can help them prioritize remediation efforts accordingly.
Standardized CVEs can also help automate many aspects of vulnerability management, such as identification, prioritization, and remediation, saving time and resources. For instance, patch management tools can access open public databases of CVEs and determine which are applicable to the organization’s environment.
However, it’s essential to keep in mind that each vulnerability refers to a very specific product and environment. For the CVE information to actually be meaningful to an organization’s security team, they must be aware of what platforms, devices, OSes, and other equipment are present on their network. This demands an up-to-date asset inventory, which can be a challenge, as this information is constantly changing. This is especially true in cloud environments, where the size and shape of an organization’s network can shift in milliseconds.
What is the Common Vulnerability Scoring System (CVSS)?
One element is conspicuously absent from the definition of the CVE: How “bad” is the vulnerability? Meaning, how serious, dangerous, or harmful is it? In fact, the CVE system does not sort, rank, or classify CVEs; it simply records them.
So how does the security community know when a particularly dangerous vulnerability is discovered?
Sometimes it’s clear from the vendor’s response. For instance, when the browser vulnerability (CVE-2023-4863) was discovered, all four browser vendors kicked into high gear to release an emergency patch; that’s a good sign that the vulnerability is high-priority.
Unfortunately, other vulnerabilities may present a very high risk, and this is not always clear.
To address this issue, the U.S. National Institute of Standards and Technology (NIST) developed the Common Vulnerability Scoring System (CVSS), a framework for communicating the severity of computer security vulnerabilities on a scale from 1 to 10 along with a severity classification: Critical, High, Medium, or Low, based on several variables:
- Base Score: Intrinsic severity of the vulnerability, based on its potential to be exploited and the impact it could have on an affected system.
- Temporal Score: Current state of the vulnerability, such as whether it is publicly known and whether there are any exploits available.
- Environmental Score: Specific context in which the vulnerability is being exploited, such as the type of system it is affecting and the presence of any compensating controls.
For example, CVE-2023-4077, an older Chrome vulnerability that earned security researchers a bug bounty of $3,000 received a CVSS score of 8.8, meaning its severity level was High. Whereas CVE-2021-44189, one of a series of vulnerabilities in Adobe After Effects discovered in September 2023, was given a score of 3.3, a Low severity level.
However, while CVSS provides a standardized ranking, this information still may not be as helpful as it could be to an individual organization. That’s because CVSS doesn’t take into consideration a variety of other factors, such as:
- Value of assets affected: Does the device affected contain mission-critical or sensitive data?
- Exposure of assets affected: Are they online and exposed to the open internet?
- Effort required to fix: Can this vulnerability be remediated or mitigated in a fast, simple way?
Calculating the actual risk of a particular vulnerability and the potential value gained in remediating it is complicated. Indeed, the exact risk a vulnerability poses will vary from one organization to the next.
For effective prioritization, organizations need a big picture of their network, including all assets and connections between devices before taking steps to prioritize vulnerabilities or work around them (for example, through network segmentation). One way to do that is with a network detection and response platform.
Staying Safer with Network Detection & Response
Faddom is a simple network mapping tool that gets to work immediately building and maintaining up-to-date asset inventories, usually in under an hour. This enables you to be aware of which assets you need to protect and which vulnerabilities apply to your environment.
Faddom helps organizations achieve effective network detection and response by…
- Mapping all servers and applications in an environment, including cloud and on-premises, and monitoring ongoing traffic patterns
- Mapping all east-west traffic to simplify security projects like microsegmentation planning, shadow IT discovery, and SSL certificate tracking
- Sending alerts in the event of unfamiliar connections and traffic anomalies, both signs of suspicious behavior that could indicate an attempted breach
And coming soon! Faddom’s new cybersecurity module, currently in beta, will detect critical common vulnerabilities and exposures as well.
Faddom’s greatest advantage is that it collects all the data it needs from network devices without installing any agents or changing firewall rules. So it’s easy to deploy and manage, and won’t introduce any additional security risks. That’s how Faddom gives organizations the visibility they need to stay safe from vulnerabilities along with peace of mind, knowing that it will never get in the way.
As we have explored in this post, CVE and CVSS rankings are essential for security professionals to help identify, track, and manage vulnerabilities. By choosing security and network platforms that integrate with these universal resources, organizations can improve their overall security posture
Faddom helps you achieve tighter security, starting with visibility and traffic monitoring, so your business can start elevating the maturity of its vulnerability management program—more easily and faster than you ever thought possible.
To start a free trial and begin securing your network against vulnerabilities today, just fill out the form in the sidebar!