CVEs: What They Are, and Ways to Mitigate Their Impact

In our industry, there are many definitions of “vulnerability,” and we usually think of it in the context of physical machines or networks. But the National Information Assurance Training and Education Center defines a vulnerability as:

A weakness in automated system security procedures, administrative controls, internal controls, and so forth, that could be exploited by a threat to gain unauthorized access to information or disrupt critical processing.

It’s important to remember that a vulnerability can affect not only software and hardware, but also the procedures and controls you have set in place, which can have very real effects on your ability to respond adequately.

Weaknesses can lead to vulnerabilities, but if there is no way to exploit a weakness, it's just that — a weakness. A vulnerability, however, is a weakness that can be actively exploited. And an “exploit” is, of course, the technical manner in which a vulnerability is abused. 

All vulnerabilities rely on weaknesses, but not all weaknesses become vulnerabilities — and not all vulnerabilities get exploited. But, sometimes, there are multiple ways to exploit a vulnerability, even after a patch is issued.

CVE, or Common Vulnerabilities and Exposures, is a system of referencing publicly known information-security vulnerabilities and exposures. It's both a standardized designation and dictionary, providing a universally accepted way of naming and organizing known vulnerabilities. 

The United States' National Cybersecurity Federally Funded Research and Development Center, operated by The MITRE Corporation, maintains the system, with funding from the National Cyber Security Division of the U.S. Department of Homeland Security. The system was officially launched for the public in September 1999.

The general nomenclature goes like this: The prefix CVE-the year published-some arbitrary digits (the arbitrary digits serve as a unique identifier);

For example, in 2021, it was discovered that the SolarWinds Serv-U FTP product contained a privilege escalation vulnerability, so the CVE for this vulnerability is CVE-2021-25276.

There is no law or requirement to disclose a vulnerability when found, so if a malicious actor finds a vulnerability in a system, it can be exploited indefinitely until it’s detected, reported, and (hopefully) remediated.

OWASP provides a handy cheat sheet for guidance on the commonly accepted vulnerability disclosure process. Most important, make sure you have:

• a way (process/system) to internally report vulnerabilities (along with a triage/assign/fix process)
• a way (process/system) to report vulnerabilities to external audiences (along with a triage/assign/fix process)

Table 1. CVSS scores and their corresponding severities

A zero-day vulnerability — the proverbial monster under the bed — is a vulnerability that has been publicly disclosed, but the affected system had no time to patch it before disclosure, or a patch is just not yet available.

High or critical zero-day vulnerabilities are those that are easily exploitable, usually have a changed scope, definitely have a wide impact, and ultimately can have devastating effects — made all the worse by the unavailability of a patch to fix the issue. The famous Log4Shell vulnerability in Apache Log4j is a great example of a critical zero-day, as it was relatively easy to exploit, entailed a significant change in security scope, had a potentially devastating impact, and there wasn’t a patch immediately available.

Although there is no way to protect against every critical vulnerability, including zero-days, those like Log4Shell highlight how critical it is to have multiple layers of defense built into your systems to protect your users, your applications, and your network. This usually starts with having clear and comprehensive visibility into your IT infrastructure, the workloads running on it, your public-facing and internal applications, and the users trying to access those applications. It’s good practice to assume that a breach will happen (when, not if) and make a plan to limit the blast radius of that breach.

So, how can we go about remediating CVEs, including those that don’t have a patch yet? The four stages of the Cyber Exposure lifecycle detailed in this comprehensive blog post by Tenable outline the recommended steps for vulnerability management; that is, the steps you can take to ensure that you have the security posture and processes required to quickly and effectively mitigate vulnerabilities as they come up. 

The four stages of the Cyber Exposure lifecycle are:

1.  Discover (asset discovery and classification)
2.  Assess (comprehensive and continuous vulnerability assessment)
3.  Analyze (vulnerability analysis and prioritization)
4.  Fix (vulnerability remediation and verification)

Let’s examine each one step by step.

Discover

“Visibility” might be the most abundant promise made at marquee cybersecurity conferences, and with good reason — the importance of having and maintaining a complete and up-to-date asset inventory is still fundamentally important to vulnerability management, as well as any cybersecurity or compliance project. 

But it can be hard to reconcile the visibility you have into your devices, clouds, platforms, and systems in one solution with the visibility that’s required into all the layers of your software stack (e.g., containers) provided by another solution. Maintaining both vertical and horizontal visibility into your whole environment can be incredibly difficult for security practitioners, especially when trying to visualize that data in a meaningful way. 

Assess

Once you have your complete, updated asset inventory, you need to start looking for any vulnerabilities on the assets. The deeper your assessment goes, the more data you’ll get, but you’ll also put more strain on the assets themselves.

Analyze

Analyzing every vulnerability can put strain on your systems, as well, and the data produced can be almost unmanageable. By focusing on the vulnerabilities and assets most likely to be exploited and by prioritizing them based on business impact and risk, you can more efficiently begin to remediate them.

Fix

Remediating vulnerabilities can be even trickier than discovering, assessing, and analyzing them. Knowing which patches to apply (assuming patches are available) and dealing with system downtime while applying them are both headwinds that you will face and they need to be planned for accordingly. And when there isn’t an available patch? What then?

Working through these four steps to remediate a CVE inevitably requires juggling multiple security tools. But are there some synergies between the available tools that could give you a bigger picture and more control, without becoming too cumbersome to manage? Let’s look at what’s available to facilitate each of the framework’s steps.

Configuration management database (CMDB)

A fundamental component of every organization's IT stack is the CMDB, which is the central repository of information about your organization’s assets — software, hardware, systems, products, and even people — and the relationships among all of those assets. 

CMDBs are, by nature, excellent at asset management and configuration tracking, but they don’t provide much visibility into the network, or into connections being made with other assets that may appear unaffected at the surface. Many security solutions feature integrations with CMDBs to leverage the data for network and asset visibility and security purposes.

Cloud security tools

The most common cloud security tools we’re seeing today include:

• Cloud access security broker (CASB). This cloud security tool has become very well-established in recent years and enforces security policy between the user and the data in the cloud. This tool does everything from authenticating user sessions to single sign-on, device profiling, malware detection/prevention, and unauthorized data transfer and anomalous communications prevention. This may be a good option for cloud environments, but like all cloud-native tools, it won’t do much to protect your on-premises systems or any underlying infrastructure.

• Cloud security posture management (CSPM). Although this is a strong tool for general cloud asset discovery, normal activity baselining, as well as CVE ingestion and remediation via integration with tools like Tenable, it does not monitor cloud network traffic directly, so you’ll only get alerted after the vulnerability has likely been abused. And since CSPM is dependent on the cloud providers for the network logs required, analysis is rarely performed in near-real time. 

• Cloud workload protection platform (CWPP). These cloud security tools can cover those parts of the workload that may be on-premises as well as in the cloud, but they have their limits. They don’t cover security issues at the Layer 7 application level, nor do they do much to protect the underlying cloud infrastructure. So, if the vulnerability relies on individual processes to be exploited, or if it affects the underlying cloud infrastructure (which is managed by the cloud providers, not you), your CWPP will not be able to prevent the vulnerability from being exploited and affecting your systems.

• Cloud-native application protection platform (CNAPP). CNAPPs are a relatively new tool, combining the capabilities of CSPMs and CWPPs. They can also help identify misconfigurations and vulnerabilities in your public cloud deployments, but (again) find themselves limited to just those instances.

Identity and access management (IAM)

A strong choice to assess and potentially block user access in real-time based on risk scores, and it can provide real-time fixes for CVEs on assets or users attempting a connection. But, asset discovery is not a focus of IAM solutions, and it’s not a focus for these solutions to prioritize high volumes of alerts or CVE tags, making management more time consuming and limiting your overall time-to-remediation.

Internet of Things (IoT) security solutions

IoT security is becoming increasingly relevant, and we’re seeing solutions emerge that cater to the unique security challenges posed by these “smart” devices. But these solutions tend to be focused on device discovery, and their remediation capabilities are relatively limited.

Security information and event management (SIEM)

Pronounced “sim,” this tool combines security information management (SIM) and security event management (SEM) into one system. A SIEM tool collects event log data from a range of sources, identifies activity that deviates from the norm with real-time analysis, and takes appropriate action like limiting access attempts and generating relevant reports. It won’t do much to remediate the actual vulnerability, however, so you’ll need another solution in addition to your SIEM.

Network access control (NAC)

This tool is great at identifying new assets connecting to your network and assessing their security posture, but they’re not really helpful for identifying and mapping existing connections, and they don’t provide much in the way of remediation.

Table 2. How each of the available tools satisfies each step of the Cyber Exposure lifecycle 

Table 2 represents how popular security solutions ingest CVE data from solutions like Tenable to improve your overall security posture in various ways. They each present a good case for being included in your security stack for their particular intended use, specific coverage areas, or proven value-adds.

But where Akamai adds its own unique value across the CVE discovery and remediation process is the ability to quickly discover and isolate assets for remediation wherever they are on the network.

Akamai Guardicore Segmentation allows you to see the network traffic that is, or has been going, to and from a given asset, allowing you to further isolate a wider group of assets and significantly reduce the blast radius from an attack that may have leveraged an open CVE. Plus, our Insight feature based on osquery enables you to identify assets in your environment according to specific characteristics that you can determine.

Akamai Guardicore Segmentation provides asset discovery, network visibility, and asset isolation across different infrastructures, and integrations with CMDBs allow the solution to provide full contextual visibility into all assets that are communicating in your network. 

And with our tenable.io and tenable.sc integrations, you can query for affected assets in your environment, label them with the CVE (whether they’re in the cloud or on-premises), and quickly enforce granular policy based on the CVE label to swiftly limit communications with the affected assets until a patch or fix is made available. Whether you are looking for open CVEs in your on-premises data center, cloud-hosted workload, container, or unmanaged IoT device, we’ve got you covered.

Table 3. How Akamai Guardicore Segmentation satisfies each step of the Cyber Exposure lifecycle

For more information on how Akamai + Tenable = powerful vulnerability remediation, check out our solution brief or contact us directly.