Organizations across the globe continue to focus on managing security and risk compliance as the threat landscape evolves. Funding for IT security remains the top priority for many enterprises, as reported in the 2022 Global Tech Outlook report, published by Red Hat earlier this year.
When it comes to managing security and regulatory compliance risks, enterprises face an increasing number of challenges. One of these is managing the regulatory compliance of IT infrastructure to various cybersecurity policies (e.g. PCI, HIPAA, CIS, etc.). This is an ongoing, constantly-evolving need. As an enterprise, managing the regulatory compliance of your infrastructure without any disruption to the business has become a critical exercise.
Red Hat Insights is a managed service that continuously analyzes platforms and applications to help enterprises manage hybrid cloud environments. Included with Red Hat Enterprise Linux (RHEL) subscriptions, Insights uses predictive analytics and deep domain expertise to reduce the time required to perform complex operational tasks from hours to minutes. This includes identifying security and performance risks, tracking licenses and managing costs.
How Insights can help with these challenges has been addressed in multiple blog posts including:
This article focuses on two recent but important changes made to the Insights Compliance service to provide a comprehensive set of reporting and alerting for Compliance policies. Specifically:
the ability to see which servers have not reported any results at all
the ability to be notified via email when certain conditions/triggers are met that require your attention
Servers that have not reported any results
The Policy Reports view of the Compliance service now displays systems that have never sent any compliance reports. Systems in this category are those that are included within a policy but have never uploaded any results, either because the report failed to upload due to a parsing error, or because they simply never had a report to send. In either case, this is relevant information to have available automatically without having to pull it together manually and, more importantly, it’s an important component of a solid compliance program.
This new feature provides a more complete and accurate visualization of the policy at hand. It is necessary for this data to be displayed because it can be difficult to keep track of which systems have and have not been reported on, especially for customers that have large (100+ systems) environments.
For example, if I have 500 systems that have to comply with PCI, Insights will now let me know:
which systems are compliant
which systems are non-compliant
which are in an unsupported configuration
which systems that should be reporting their compliance status have not reported
This gives me a complete view of my regulatory compliance status.
Figure 1 below shows the different types of systems that are displayed on the Policy Report page. The compliance score is calculated by considering all of the systems assigned to the policy, including systems that have never reported:
The dark blue sections of the chart identify the reporting systems that are compliant.
The light blue sections of the chart identify the reporting systems that are non-compliant.
The yellow section details the systems that are running an unsupported configuration.
Examples of this non-support include systems running a version of RHEL and a version of the system security guide (SSG) that is either too old OR too new to provide accurate compliance results.
Finally, the gray section of the chart indicates the systems that have not reported anything back at all.
Figure 1. Compliance now highlights systems that have never reported any results
Figure 2 below shows the table on the Policy Report page that lists all of the systems assigned to the policy. The gray rows indicate systems that have never reported on their compliance, which is evident through the values for the corresponding columns. For example, the “Last scanned” column will display “Never,” indicating that the system has never been scanned for this policy.
The benefits of being able to see these systems highlighted separately include being able to determine where your team needs to focus to become compliant with the policy. It makes troubleshooting easier and reduces operational overhead. There are several possible reasons why a system has not uploaded any reports:
It could be due to the fact that the “insights-client --compliance” command has not been run yet for that system.
It could be that the command was run but didn’t finish (i.e. report failed to upload) because there was an issue during this process.
It could also be the system is down or somehow has been disconnected from the network.
If you notice that you have one or more systems that are not reporting, you can check the systems table on the Policy Report page, shown in Figure 2 above, and see exactly which systems are not reporting. Once you discover which system(s) are not reporting, you can run “insights-client --compliance” on that system to generate the report and obtain the results or observe any errors that occur while generating the report and troubleshoot the issues further.
In addition to the above feature, the Insights Compliance service has also added a feature to notify users proactively if specific conditions are met that require attention for systems to become compliant. Let’s have a closer look at how this feature works below.
Alerting and notifications for specific conditions
The Compliance service has another new feature that allows customers to receive notifications for certain events or conditions being triggered within their Compliance policies. The purpose of this is to give customers more insight into their current policies and to be notified promptly when a significant event occurs. These notifications let users take the appropriate action based on the state of the policy and their system(s).
Configuration of notifications for Compliance service
Currently, there are two events users can subscribe to in order to receive notifications (if they have Compliance notifications enabled):
If the compliance level for a given system falls below the compliance threshold specified by the customer for a given policy
If one or more of the systems fail to upload policy reports to Insights Compliance
Figure 3 below shows the Notifications settings where organization administrators can configure the Compliance notifications and specify which notifications users will receive.
Figure 3: Notifications Settings where Compliance notifications are configured by org admins
Configuration of user preferences
Individual Compliance users can choose to receive either “instant notifications” or “consolidated daily digests”. If you enable daily digest emails, you will receive a daily summary of every triggered Compliance event that occurred on your account in the last 24 hours. If you enable instant notifications, you will receive an email for each triggered Compliance event immediately after it occurs. These two types of notifications can be enabled at the same time, or you can choose to enable one or the other.
By default, every user account is opted-out of receiving Compliance notifications. If you would like to enable the Compliance notifications, you can follow these steps:
Log in to https://console.redhat.com/
Click on your username in the top right corner
Click “User Preferences” in the dropdown list
Click “Notifications” on the left sidebar, under “User Preferences”
Click “Red Hat Enterprise Linux”, under “Notifications”
Click the “Daily digest” and/or “Instant notification” box in the Compliance section to enable notifications (see Figure 4 below)
Figure 4. Notifications page where customers can opt-in/out of Compliance notifications
Instant notification examples
If you have “Instant notification” enabled, you will receive an email immediately after either of these events occur. One notification email will be sent for each system that triggers an event.
For example, suppose you have two registered systems assigned to one policy, and they both trigger an event. In that case, there will be two notification emails sent for each of the systems that need attention. This feature is useful because you will be notified promptly when an important event occurs so that you can take immediate action to resolve the issue. See Figure 5 below for examples of the two possible instant notification emails.
Figure 5. Examples of the two possible instant notification emails for Compliance events
Daily digest example
If you have “Daily digest” enabled, you will receive one consolidated email notifying you that one or both of these events have occurred in the last 24 hours. This option can be beneficial if you would rather receive one daily email notifying you that your system(s) triggered one or more events, rather than a separate email every time an event is triggered. See Figure 6 below for an example of the consolidated daily digest email.
Figure 6. Example of the consolidated daily digest email for Compliance events
Here we’ve shown you how to use the new Compliance feature for systems that are not reporting, as well as how to configure compliance notifications. Being aware of which systems are not reporting any results and receiving insights as to why that may be the case can help with effective troubleshooting. Additionally the ability to be notified automatically — as opposed to manually checking/polling Insights Compliance — reduces operational overhead.
About the authors
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.