Author's note: I'm testing the service as part of my job at the Bielefeld IT Service Center (BITS) at Bielefeld University. This article reflects my personal view of Red Hat Insights. Furthermore, I would like to clarify that I am a member of the Red Hat Accelerators community.
The dashboard shows a box called Vulnerability. Fig. 1 shows that we are obviously affected by 13 vulnerabilities. We are now able to take a closer look at these. This is done as usual via the link in the box or via the menu on the left.
In the vulnerability view, the usual tabular view awaits us (see Fig. 2). Here, CVEs are listed with their ID, the date of publication, an impact assessment, the CVSS base score, and the number of affected systems. In addition, you have the option of assigning a business risk and a status for selected or all CVEs (see yellow marking in Fig. 2).
The business risk gives you the opportunity to rate a specific CVE or a group of CVEs on how they might affect your business or have a negative impact on it (see Fig. 3). This status might differ from the Impact in the second column depending on certain security measures you already have in place. The status indicates how the vulnerabilities are processed (see Fig. 4).
As in the Advisor, you get a detailed view with a description of every CVE, evaluation, and overview of the attack vectors (see Fig. 5), as well as links to the Red Hat knowledge base, where detailed information about the CVE and existing errata can be found.
Assessment of the vulnerability management
As of today, we don’t have an active vulnerability management. We try to ensure a certain level of security with a patch management for RHEL with Ansible, which I developed with tools included in RHEL and the Ansible Engine. This ensures that available Red Hat Security Advisories are compulsorily installed on all RHEL systems once a month if they are missing.
Thanks to this patch management, there are only 13 vulnerabilities on the connected test systems, and none of them had a score greater than eight.
Among the systems listed in the dashboard were systems of a test infrastructure that are not connected to the central patch management and are only irregularly patched. Insights showed me here that the risk is far too great, and that these systems will simply be forgotten. For this reason, these hosts were now immediately included in the patch management.
These vulnerabilities have in common that they cannot be closed simply by installing an update. Since these are virtual machines (VM) on a vSphere cluster, a combination of measures is required to mitigate the vulnerabilities.
In this specific case, the affected VMs only have to be switched off and on again once. This propagates new CPU functions to the guest operating system and mitigation is complete.
I have to admit that these vulnerabilities would have remained undiscovered for a long time without insights.
Now I have to assume that there are other vulnerable systems in our environment. Since I’m not allowed to connect these to Insights, I will use a script provided by Red Hat to find these. I really appreciate that Red Hat provides such scripts to help its customers here. There are still a few companies out there that can safely follow this example.
Personally, I think active vulnerability management makes sense. Vulnerabilities can only be found, assessed, and dealt with accordingly through continuous control. At the same time, it can be used to check whether or not measures have already been taken to improve the structural safety level (e.g., a patch management).
Fig. 6 shows that there are currently no open vulnerabilities. This should always be the goal.
I enjoyed the test of the vulnerability management function myself and the vulnerabilities found could be closed within a short time.
[ Attend a Red Hat Insights Ask Me Anything with product manager Jerome Marc, focused on comparing systems with Drift, on July 23, 2020. ]