Vulnerability management that’s actually manageable

Cloud environments are dynamic, with short container lifespans and new code deploying daily, if not continuously. Identification, assessment, prioritization, management, and remediation are different in the cloud compared with on-premises data centers or end-user devices, requiring purpose-built solutions.

Vulnerability management solutions include a set of capabilities to identify, assess, prioritize, manage, and remediate vulnerabilities. Yet in dynamic cloud environments – with typical container lifespans of mere hours and new code deploying daily, if not hourly or continuously – each component of that workflow differs significantly from vulnerability management for on-premises data centers or end-user devices.

• Identification is different. Network and authenticated scans won’t work with the cloud. You need to scan code early and often, within the developer workflows, and also correlate and assess what gets deployed to production. Assessment is different. The software bill of materials for your application replaces ‘vulnerability pack upgrades’ and is your new source of truth.
• Prioritization is different. You need to understand the internet exposure of assets, contraindicating risks like compliance violations and overly-permissive IAM privileges, and even whether that vulnerable package is actually being executed by that application!
• Management and remediation are different. Since the system you’re patching is immutable (eg. container images or Amazon Machine Images (AMIs), vulnerability findings need to be easily accessible by development teams so they can rebuild images with patches quickly.

All of these differences require a fundamentally different approach to vulnerability management in the cloud, and you need a purpose-built solution to solve these challenges.

Traditional security tools cannot keep up with the growing volume of vulnerabilities in the cloud. Vulnerability management solutions can close visibility gaps by preventing the exploitation of software vulnerabilities that put your data at risk. They can also uncover ample lists of CVEs.

Vulnerabilities, both known and unknown, are growing with the increased usage of open source software. In dynamic cloud environments, traditional security tools cannot keep up with the volume of vulnerabilities. Without a vulnerability management solution, you could have visibility gaps that leave the door open for exploitation of software vulnerabilities and put your data at risk.

In addition, many vulnerability management solutions are able to uncover ample lists of CVEs, but a lack of runtime context and skilled resources can make it challenging to discern the true risks within your unique environment.

Continuously identify, assess risk, and remedy high-risk vulnerabilities with a four-step process: scan and identify your assets for vulnerabilities; evaluate the impact and prioritize; treat and patch via remediation, mitigation, or patch management; and measure and report with regular assessments.

In order to continuously identify, assess risk, and remedy high-risk vulnerabilities, there are four steps to take in the vulnerability management process.

Scan and Identify Vulnerabilities

The first step is to identify which assets are considered high value and critical to assess for vulnerabilities throughout your cloud infrastructure. Define each asset that you’d like to assess with your vulnerability management solution, choose the right method of scanning for each asset type and begin scanning your assets.

Evaluate and Prioritize Vulnerabilities

Once the vulnerabilities have been identified from your scans, the next step is to assess the level of impact, exploitability, and risk posture of each asset, so that you can prioritize which vulnerabilities to focus on.

The Common Vulnerability Scoring System (CVSS) is a framework for rating the severity of software vulnerabilities and their risk scores provide a good approximation of the relative importance of vulnerabilities. However, it’s important to understand the potential business impact of the affected system to your organization itself. One indicator you can use to assess the level of impact is to gauge how many images are affected by a vulnerability. For example, a high-severity vulnerability present on hundreds of running containers should likely be fixed before a critical vulnerability that only shows up in a couple of containers.

With so many vulnerabilities to patch, it’s critical to consider the exploitability of a vulnerability. The key factor for exploitability is to determine whether an asset is exposed to the internet. Your solution should be able to gauge if a workload configuration is exposed to the internet and then factor in internet exposure as part of the risk score. Ideally, this value is available as a filter for prioritization as well. In addition, when thinking about prioritization for containers, you should target the images that are actually deployed in production. By correlating vulnerability risk data with runtime observations, you can better prioritize which vulnerabilities to fix first.

Treat and Patch Vulnerabilities

The third step is to take action on the identified vulnerabilities. This can be done via remediation, mitigation or patch management, or not taking an action at all.

For high-risk vulnerabilities, remediation typically requires upgrading the vulnerable package in a code repository. Vulnerability mitigation reduces the potential impact of an exploit while the vulnerability remains in your environment. This means that the vulnerable parts of an asset receive security patches because a fix is not yet available or cannot be taken at that time. When the vulnerability poses a low risk or no risk, then it’s possible that no action is taken at all.

Measure and Report on Vulnerabilities

Conducting regular assessments is vital in understanding how well your vulnerability management practice and patch management process are performing.

The assessment or report summarizes key findings regarding assets, security flaws, and overall risk to the organization. Common KPIs include the measurement of scan coverage and patch turnaround times. For example, scan coverage refers to the percentage of assets that have complete and accurate data available. Patch turnaround times can include the measurement of mean time to detect, mean time to remediate, the rate of issue recurrence, and a look at how these numbers change over time. It is also valuable to measure the weighted rate of risk, which summarizes the identified vulnerabilities and compares them to the criticality of the data connected to those vulnerabilities.