What Is Vulnerability Management?

Vulnerability management is an ongoing program that relies on technologies and practices to identify vulnerabilities and remediate them in a timely way to secure an organization’s infrastructure and resources. The objective is to establish systematic processes for detecting and mitigating vulnerabilities no matter where they arise. When integrated into CI processes while continuously monitoring hosts, images, and functions in the cloud-native environment, vulnerability management plays an integral role in detecting and preventing vulnerabilities across the application lifecycle. As such, vulnerability management lays the foundation for a healthy cybersecurity strategy by ensuring that security teams can reliably find and fix vulnerabilities before they lead to system intrusions, data breaches or other adverse security incidents.

Figure 1: Vulnerability management comprises diverse technologies and security measures across the application lifecycle.

Vulnerability Management Explained

Network devices, servers, storage systems, workstations, legacy applications, virtual machines, containers, cloud applications, microservices, databases, APIs, cloud infrastructure services, cloud platform services, security configurations — the list is seemingly endless. With the increasing prevalence of agile methodologies and cloud services broadening IT environments, vulnerability management has become increasingly complex. As with traditional IT environments, vulnerability management for cloud workloads is a continuous, multifaceted process that involves the identification, assessment, prioritization and mitigation of security vulnerabilities to ensure the protection of sensitive data, maintain cloud compliance, and reduce the risk of cyberattacks.

The process begins with maintaining an up-to-date asset inventory and employing vulnerability scanning to discover potential threats in cloud resources. Vulnerabilities are then assessed based on their severity and impact, allowing for prioritization of remediation efforts. Patch and configuration management address software vulnerabilities and misconfigurations, while continuous monitoring and incident response ensure the rapid detection and containment of emerging threats. Lastly, reporting and auditing activities provide visibility and accountability, ensuring the effectiveness and compliance of the vulnerability management program.

Understanding Vulnerabilities, Threats and Risks

To understand why vulnerabilities are important and how they can impact your business, you must understand the relationship between vulnerabilities, threats and risks.

A vulnerability is any flaw, weakness, misconfiguration or oversight in an IT system that attackers could exploit to take control of the system, exfiltrate data from it, disrupt its operations, or otherwise cause harm to the business.

What this means is that vulnerabilities create an opportunity for cyberthreats to be carried out. A threat is any entity that seeks to — and potentially could — execute a cyberattack of some kind. To carry out a cyberattack, however, threats need to find vulnerabilities that they can take advantage of.

When a vulnerability exists and a threat actively seeks to exploit it, the organization is at risk.

So, vulnerabilities make it possible for threats to become actual risks. Without vulnerabilities, threats — such as hackers who want to steal sensitive data from your organization for financial gain, or state-sponsored threat actors who seek to disrupt critical systems for geopolitical purposes — can still exist. It's only when vulnerabilities are present, however, that the risk of threats actually being exploited exists.

Why Cloud Vulnerability Management Is Challenging

Vulnerability management isn’t simple for any type of workload, but when you’re dealing with cloud workloads, detecting and mitigating vulnerabilities is especially challenging.

Cloud Services Are Complex And Varied

Cloud workloads can vary tremendously. They may include VMs, containers, serverless functions, orchestration services, or all of the above. Each type of cloud workload could be subject to different types of vulnerabilities, so you need a vulnerability management strategy that can recognize different threats based on workload context.

The Cloud Is Constantly Changing

More so than most on-premises environments, cloud environments are typically dynamic. Configurations change constantly as workloads scale up and down, users are added or removed, applications are updated, and so on. For this reason, the ability to continuously monitor for vulnerabilities is paramount.

Cloud Risks Vary in Scope

Not all vulnerabilities are created equal. Some — like those that enable remote code execution exploits — are riskier than those that can only be exploited under rare configurations. You need to know which ones are severe so you can address them first.

Vulnerability Management Vs. Patch Management

In some respects, the vulnerability management process is akin to other security processes that IT organizations have practiced for decades, such as patch management. Like vulnerability management, patch management involves systematically finding and reacting to potential security risks (namely, unpatched software that attackers could exploit) before they become active problems.

But the vulnerability management process goes beyond patch management.

• Unpatched software is one way that vulnerabilities can be introduced into IT environments, but it's not the only way. Vulnerability management also addresses other entry points for vulnerabilities, such as insecure configurations.
• Whereas patch management typically involves the periodic installation of software patches, vulnerability management is a continuous process. You don't — or shouldn't — scan for vulnerabilities just once a week or even once a day. Instead, you should scan continuously so that you can find and react to vulnerabilities in real time, whenever and wherever they appear.
• The vulnerability management process applies not just to assets (like applications) that can be patched but also to cloud services, infrastructure and other types of resources your IT team typically can't patch in the conventional sense.

Overview of Common Vulnerabilities and Exposures (CVEs)

When security researchers identify a vulnerability in software that is used publicly, they typically report it to a Common Vulnerabilities and Exposures (CVE) database. CVE databases are lists of known vulnerabilities. They include details on what causes the vulnerability, how it can be exploited, how severe it is, and how to patch or update systems to mitigate the vulnerability.

Most CVE databases define this information using the Common Vulnerability Scoring System (CVSS), an open framework for sharing details about vulnerabilities and the severity they pose. By making vulnerability data accessible, CVEs and CVSS provide a critical resource that organizations can use to determine which vulnerabilities affect the systems or software they use. Additionally, it can tell teams how serious those vulnerabilities are and whether they can be exploited based on the specific configuration that the business uses.

The National Vulnerability Database and the MITRE CVE database are among the most popular public CVE databases. However, organizations can also maintain private or enhanced CVE data, which they may provide to other organizations as part of threat intelligence offerings.

Figure 2: CVE identification process

An important limitation of CVEs is that they typically only list threats that affect publicly available software, such as open-source applications. The main reason why is that anyone can inspect public software and potentially find vulnerabilities within it. Software that an organization reserves for internal use is more difficult for third-party researchers to study. As a result, vulnerabilities within the software haven't necessarily been found or disclosed within CVE databases.

This means you should never assume an application is free of vulnerabilities just because a CVE database shows no record of known vulnerabilities within it. There’s always a chance that vulnerabilities exist — and are known to threat actors — but simply haven’t been reported yet.

But security vulnerabilities, as mentioned above, come in many forms.

Broken Authentication

Ineffective access control processes or configurations within software may allow malicious actors to access the software or escalate privileges beyond those of the user.

SQL Injection

SQL injection vulnerabilities allow attackers to inject malicious queries into a database to manipulate data or exfiltrate information from it. SQL injection vulnerabilities typically occur due to lack of proper input validation within an application that interfaces with a database.

Cross-Site Scripting

A cross-site scripting vulnerability allows attackers to run malicious scripts. This type of vulnerability most often affects websites that contain poorly written Javascript code. If attackers find the vulnerable code, they can trick the site into running scripts of their choosing, potentially giving them access to resources on the endpoints that connect to the website.

Cross-Site Request Forgery

Attackers can exploit cross-site request forgery vulnerabilities to cause users to inject malicious code into a website or application with which they're currently authenticated. They're similar to cross-site scripting vulnerabilities, with the major difference being that cross-site request forgery vulnerabilities center on impersonating authenticated users to perform malicious actions rather than executing malicious code through insecure Javascript.

Security Misconfigurations

Any type of security configuration mistake or oversight could trigger a vulnerability. For example, admins might inadvertently make sensitive data accessible via the internet due to a firewall configuration mistake, or they may forget to require multifactor authentication when configuring a new application deployment.

Vulnerability Management Vs. Vulnerability Assessment

Vulnerability management is the strategy that IT organizations use to identify and react to vulnerabilities. When an individual vulnerability is discovered, however, they use a process known as vulnerability assessment to understand which level of risk the vulnerability poses and to help determine how to remediate it.

Vulnerability assessment is important because not all vulnerabilities pose the same level of risk. For example, a vulnerability that can only be exploited by attackers who have direct physical access to a vulnerable system poses less risk, generally speaking, than one that can be exploited over the network, because the number of threat actors who operate over the network is usually much higher than those who have physical access to IT assets.

In addition, in some cases, vulnerabilities can only be exploited under specific configurations or environments. For instance, a vulnerability in an application might be exploitable if the application is hosted on a Windows server but not on a Linux server, or vice versa.

Based on factors like these, vulnerability assessment allows organizations to determine the specific level of risk that each vulnerability poses to them. They can then prioritize responding to the most severe vulnerabilities first to minimize their overall level of risk.

Setting Up a Vulnerability Management Framework

Although vulnerability management programs need to be tailored to the unique requirements of the organizations they serve, Gartner offers a vulnerability management guidance framework that provides a helpful starting point for getting started with vulnerability management.

The key components of Gartner's framework include:

• Define the scope of the program: Businesses start their vulnerability management strategy by determining how many IT assets and vulnerability types they need to address.
• Define roles and responsibilities: Determining who does what and when is a critical component of vulnerability management. From frontline staff, like IT engineers, to CISOs and CTOs, everyone has a role to play in finding, reporting and managing vulnerabilities.
• Select vulnerability assessment tools: Businesses must decide which tools they'll use to find and assess vulnerabilities, as well as how vulnerability remediation will factor into their workflows and tooling.
• Create and refine policy SLAs: SLAs determine how quickly organizations will react to vulnerabilities and which level of active vulnerabilities they can tolerate. SLAs are an especially important resource to tailor to the business, since different organizations can tolerate different levels of risk.
• Identify asset context sources: Asset context sources provide complementary information — such as data about the role that a system or application plays in the business — that can be critical for assessing vulnerabilities and their severity.

By addressing each of these requirements, organizations can establish vulnerability management programs that empower them to find and react to vulnerabilities across all systems of concern.

The Four Key Steps of Vulnerability Management

When fully implemented, an effective vulnerability management program should allow your business to perform each of the following steps in the vulnerability management process.

Identify Vulnerabilities

You can't fix what you can't see. Finding vulnerabilities involves scanning all IT assets in your organization and determining whether they (or any component of them) are subject to vulnerabilities. CVE databases are a critical resource for this purpose, although again, not every vulnerability is detailed in public CVE lists.

Evaluate Vulnerabilities

After discovery, each vulnerability must be assessed to determine which level of risk it poses to the business. Manual vulnerability evaluation may be necessary in some cases, but vulnerability management tools can accelerate the process by automatically determining the severity of each vulnerability and assessing how likely it is that the vulnerability can be exploited in the business's environment.

Treat Vulnerabilities

Vulnerabilities can be treated in three main ways:

• Remediation: Remediation involves the total elimination of a vulnerability, usually by updating or patching the affected asset so that the vulnerability no longer exists.
• Mitigation: Mitigation allows organizations to minimize the risk that a vulnerability can be exploited or to reduce the potential harm that it can cause. Mitigation is a good strategy in cases where remediation isn’t possible or feasible. For example, if you can't update a vulnerable legacy application because patches aren’t available for it, you may still be able to mitigate the vulnerability by changing the application's configuration.
• Acceptance: In some instances, IT organizations may decide that vulnerabilities are not serious enough to merit either remediation or mitigation. In that case, they simply accept the vulnerability.

Report Vulnerabilities

Vulnerability reporting is the process of disclosing vulnerabilities to external stakeholders. It often involves submitting vulnerability reports to public CVE databases, but organizations may also be required by compliance mandates or contractual agreements to report vulnerabilities directly to regulators, customers or partners. Either way, the goal of reporting is to share information about which vulnerabilities exist, what causes them, and how they can be fixed so that others can react to the vulnerabilities before they lead to exploits.

Improving Your Vulnerability Management Program

Having a vulnerability management program in place doesn't mean you can stop worrying about vulnerabilities and move on to other concerns. Instead, vulnerability management should benefit from a strategy of continuous improvement, meaning that IT organizations continuously look for ways to improve their vulnerability management strategies.

Common examples of vulnerability management program improvements include:

• Making more extensive use of automations to add efficiency and consistency to vulnerability management.
• Bringing additional systems or applications within the scope of vulnerability management to increase the comprehensiveness of coverage.
• Leveraging additional vulnerability databases and/or asset context sources to increase the data available when assessing vulnerabilities.
• Deploying new or enhanced vulnerability management tools to detect types of vulnerabilities that previous systems couldn’t support.

Steps like these allow organizations to make vulnerability management more effective and efficient, bringing them closer to the goal of ensuring real-time detection and remediation of all vulnerabilities, no matter what they entail or where they exist.

Best Practices for Managing Cloud Workload Vulnerabilities

There’s no simple trick for ensuring that you can catch and remediate all cloud vulnerabilities before they turn into critical threats. However, strategies such as the following can help you mitigate your risk of serious cloud-related cyberattacks.

Integrate Vulnerability Scanning into CI Processes

The earlier in the development lifecycle you catch vulnerabilities, the lower the risk that they’ll lead to breaches in production environments.

For that reason, vulnerability scanning should be integrated into your CI processes. Instead of waiting until workloads are in production to scan them, scan your hosts, containers, serverless functions and other resources in development and staging environments. Even if your configurations change between dev/staging and production, monitoring for vulnerabilities predeployment still maximizes your chances of preventing vulnerabilities from creeping into production.

Keep Scanning in Production

Of course, you should also perform continuous vulnerability monitoring after your workloads have been deployed to production. No amount of predeployment scanning is a substitute for checking for risks in production workloads.

Scan All Layers of Your Cloud Environment

A typical cloud workload includes multiple layers of configuration. Vulnerabilities can exist in each of them.

For example, if you deploy containers, you could have vulnerabilities in the container image. Vulnerabilities could also linger in the RBAC policies you configure in the container orchestrator. On top of this, policies that you configure using your cloud provider’s IAM framework could create risks for the containerized workload.

This is why it’s critical to scan all layers of your cloud workloads. Wherever data can exist, a vulnerability can also exist.

Use CVEs to Gain Vulnerability Context

As noted above, some vulnerabilities are more severe than others. But it’s not always obvious which ones require immediate attention.

Nonetheless, to make vulnerability alerts as actionable as possible, you need to know the severity level of each one. You can do this using Common Vulnerabilities and Exposures (CVE) databases, which list known vulnerabilities and “score” them according to the amount of risk they pose.

By pairing vulnerability detection with CVE data, you get contextualized, actionable insights into cloud workload risks.

Vulnerability Management FAQs