New deep threat intelligence in Red Hat Insights: Helping to prioritize what matters the most with system vulnerabilities

Red Hat Insights has added new functionality that helps users determine which of their registered Red Hat Enterprise Linux systems are “affected” with a vulnerability but are not “vulnerable.” Yes, “affected but not vulnerable” is a thing, and having this level of threat intelligence is meaningful and can make a significant difference when time is of the essence and you have to protect your organization against the next big vulnerability.

Let’s break this down and look at it systematically. We’ll first define what “affected” and “vulnerable” mean in the context of Insights. We’ll then review the most common challenges enterprises typically face, and finally we’ll review how having this level of threat intelligence will help. Let’s define these terms:

• Affected means a system has a package with vulnerable code. This can also be stated as affected and vulnerable. For the context of this blog and within the Red Hat Insights Vulnerability service, all systems that are identified to be affected are by default vulnerable unless otherwise stated, which leads to the other option, which is being introduced by this feature.
• An affected but not vulnerable label for a system indicates that you are running software that has a vulnerable code in it but is not currently exploitable. The reason it may not be currently exploitable could be because the security bug is mitigated by something on the system, for example the deployment of SELinux or a port being closed. In other words, a bad actor cannot take advantage of the vulnerability with the system configured in its current state.
  • It’s important to note the use of the words “current state.” It’s possible for a configuration adjustment to change things such that the same vulnerability could be exploited. This is explained further below.

How can this information be used to help protect an organization against threats?

The threat intelligence provided by this feature helps users to prioritize and focus first on those systems that are most exposed, as determined by Red Hat, and deprioritize others that can wait.

It’s important to note that systems identified as affected but not vulnerable still need to be updated, but just not with the same sense of urgency as those that are affected. The reason these systems still need to be patched is because the affected software package running on those systems is still a threat, and a configuration update or an event could change things such that the system becomes vulnerable, leaving the organization exposed.

Let’s take a look at an example. Recently the Retbleed vulnerability was reported and Red Hat’s Product Security Incident Response Team (PSIRT) picked it up as part of our Incident Response Plan (IRP) process. When a vulnerability goes through this process, it is carefully scrutinized and receives the focused attention from our team. The goal is to help protect customers by giving them as much threat intelligence as possible about the vulnerability. In many cases, but not all, vulnerabilities that go through the IRP process are identified with a “Security Rule” label within Red Hat Insights, indicating that they are of special importance and should be taken seriously as they are generally associated with a higher level or exposure and risk.

Getting back to Retbleed. In Figure 1, it’s clear that even though the vulnerability affects a total of 194 systems, 162 of those systems have been identified as affected but not vulnerable and the remaining 32 systems are affected (and vulnerable). In terms of putting these insights into action, a user should prioritize the 32 affected systems first,and then deal with the 162 affected but not vulnerable systems afterwards.

Figure 1: In this example of the Retbleed vulnerability, quite a few systems are “affected but not vulnerable”

What is the impact of having this type of threat intelligence?

The practical benefits of having this level of information are significant, including but not limited to:

• Equipping users with intelligence that helps them prioritize vulnerabilities and focus resources to address the most vulnerable assets first.
• Making a material difference in terms of how users are able to protect their organizations against bad actors or malicious attacks for the most critical security vulnerabilities.

Is this level of threat intelligence available for all vulnerabilities within Red Hat Insights?

No. At this time, this level of threat intelligence is only provided to a select set of Common Vulnerabilities and Exposures (CVEs) within Red Hat Insights, specifically those that are identified with the “Security Rule” label and that have gone through the rigorous IRP process mentioned above.

Want more information?

Red Hat Insights is included as part of your Red Hat Enterprise Linux subscription. Find more information and get started today by visiting Red Hat Insights.

Mohit Goyal is a Senior Principal Product Manager for Red Hat Insights. Mohit brings a wealth of experience and skills in enterprise software having held roles as a software engineer, project manager, and as a product manager across software and travel industries. Goyal has a bachelor’s degree in Computer Science from the Institute of Technology, University of Minnesota and a MBA from the Carlson School of Management, University of Minnesota. With his technical skills and business acumen, he helps build products to address problems faced by enterprises, with a focus on security, user experience, and cloud computing. When he’s not writing user requirements, engaging with customers, or building product roadmaps, Mohit can be found running, cooking, or reading.

Read full bio