Vulnerability Management

A Common Vulnerabilities and Exposures (CVE) is a publicly disclosed cybersecurity vulnerability or exposure. The concept of CVEs was introduced to provide a standardized method for identifying and cataloging security vulnerabilities in software and hardware. Each CVE is assigned a unique identifier, such as "CVE-2024-1234," which helps distinguish one vulnerability from another.

Here are the key components of a CVE:

Find out more at the MITRE website.

The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities.

They consist of the following:

Base Metrics:These metrics capture the characteristics of a vulnerability that are constant over time and across user environments.

Temporal Metrics: These metrics measure the characteristics of a vulnerability that change over time but not across user environments.

Environmental Metrics: These metrics measure the characteristics of a vulnerability that are unique to a user’s environment.

The CVSS score is computed using a formula that combines these metrics, giving more weight to the base metrics. Temporal and environmental metrics adjust the base score to reflect the current threat landscape and specific user environment considerations. The resulting scores are categorized as follows:

The structured approach of CVSS allows organizations to assess the risk of vulnerabilities consistently and to make informed decisions regarding vulnerability management and remediation prioritization. However, it does have its drawbacks, such as a Lack of context sensitivity, a static nature, and a potential for misinterpretation, to name a few.

Find out more at the NIST website.

The RHSA stands for Red Hat Security Advisory. It is a notification issued by Red Hat, a leading provider of enterprise open-source solutions, to inform users about security vulnerabilities and the corresponding updates or patches available to mitigate these risks.

Key components of RHSA:

Find out more at the link: Red Hat website

Let’s continue by looking at our customers' primary use case for RHACS, which is the Vulnerability Management features and dashboard—a familiar topic for most security teams. We are going to start with the deprecated dashboard so that you can evaluate the vulnerability management workflows for yourself.

Buttons along the top of the interface will list details by;

The Application & Infrastructure button displays a list that takes you to reports by;

Also, note the Filter CVES buttons that limit the reports to only Fixable CVEs or ALL CVEs.

The dashboard options provide several critical vulnerability breakdowns, such as:

Here, you can see the CVEs associated with containers currently running in the cluster.

The images in this dashboard are listed here in order of risk,

Risk is based on a multitude of security issues, such as

Notice which images are more exposed. Not only can we see the number of CVEs affecting the images, but which of them are fixable? We can also see:

You can move on to the next section only when the dashboard displays the image below.

The Dockerfile tab view shows the layer-by-layer view, and, as you can see, the most recent layers are also several years old. Time is not kind to images and components - as vulnerabilities are discovered, RHACS will display newly discovered CVEs. The layers that are listed as Source=OS are not showing CVE data since the CVE feeds are stale or do not have any information. However, the Python libraries that are added to the container are showing vulnerabilities. For example, the 'mercurial' package in the four layers.

The Vulnerability Management tab has recieved a lot of love over the past year. Vulnerability management in RHACS has become more focused on the categorizing vulnerabilities by workload so that it can scan RHEL CoreOS and node-level scanning and correlate it with platform and application vulnerabilities. This is because security teams want to understand at what software layer of vulnerability resides so they know what team it can reach out to to resolve a fix.

Let’s start off this section by reviewing a similar use case in the Vulnerability Management Workload CVE tab.

More important than fixing any vulnerability is establishing a process to keep container images updated and to prevent the promotion through the pipeline for images with serious, fixable vulnerabilities. RHACS displays this through the Top Risky Deployments by CVE and CVSS Score and takes the container’s configuration and vulnerability details to show you the most at risk deployments in your cluster.

The Workload CVE dashboard aims to show the same information as the deprecated vulnerability management tab but in a more scalable and systematic approach. In the UI, you will see thousands of vulnerabilities, over 200 images and over 300 deployments. This is because multiple images are being used across different deployments.

Now it’s time to find the same Java application and do some dissecting.

You will get the same information from the previous section.

However, if you click the deployments tab, you will see the specific deployments with all these vulnerabilities. This ability to see the individual deployments as well as their images is crucial. When you’re talking about multiple clusters and thousands of vulnerabilities, you’re going to have the same workloads across different clusters, and you will need to drill down into the individual deployments.

You should see that all of the critical and important vulnerabilities are fixable. This is mostly due to the age of the container image and its contents.

Now, if you care about a specific vulnerability, it is extremely useful to be able to see all of the components affected by that vulnerability.

How many deployments are impacted? How many images? Why would there be different numbers?

We will move onto vulnerability reporting workflow but take some time to think about how you and your teams would handle a situation such as log4shell.

The platform CVEs page provides information about vulnerabilities in clusters within your system. This refers to OpenShift, AKS, GKE, and other Kubernetes distribution components. The goal is to help you understand responsibility and determine the impact.

Let’s go through a simple use case to demonstrate.

Procedure

You can identify vulnerabilities in your nodes by using RHACS. The same logic that applied to the Platform CVEs applies here.

Procedure

What is the CVE associated with this RHSA? What would you do to fix it?

Internal vulnerability reporting significantly enhances software security and quality by allowing development teams to address issues early, reducing the risk of breaches and failures. This proactive approach fosters a security-aware culture and encourages best practices. Efficient reporting channels also enable teams to prioritize and promptly fix critical vulnerabilities, leading to a more robust and reliable product, which boosts user trust and satisfaction.

In this next session, we will draft up a vulnerability report around the log for Shell vulnerability, making sure that it never gets deployed into our cluster in the future.

You will see that creating a report is a three step process. It requires you to configure the report parameters and the delivery destination, and then you have to review and create your report.

The configurable parameters are the following:

You can create collection rules by deployment, namespace and cluster. The collections are setup this way so that you can easily attach policies, vulnerability reports and notifications by the logical groupings of your organization.

Since we want to target only two deployments, let’s add the two to the Collection rules.

However, you don’t have to wait until Monday to view the report.