Assessing and reporting malware signatures on RHEL systems

Understand how the role-based access control (RBAC) User Access feature of the Red Hat Hybrid Cloud Console manages user permissions through roles instead of individual user assignments. User Access simplifies permission management by assigning specific permissions to roles, which can then be assigned to user groups.

You can also create custom groups and roles to provide more fine-tuned control over specific features of Red Hat Lightspeed to suit the needs of your organization.

If you are an Organization Administrator, you can use the User Access feature under Identity & Access Management in the Hybrid Cloud Console to:

Understand the two predefined groups available in User Access: Default access and Default admin access. Create custom groups to align permissions with specific personas, job functions, or teams in your organization.

The Default admin access group includes many (but not all) predefined roles that provide update and delete permissions. The roles in this group usually include administrator in their names.

Understand how predefined roles in Red Hat Hybrid Cloud Console bundle permissions across multiple Red Hat Lightspeed applications to align with common user personas. Use predefined roles to reduce administrative effort, or create custom roles for more fine-tuned control over specific features.

The predefined roles are a starting point to help you to control and manage user permissions. You can then use these roles to create custom roles that are tailored to your specific use cases and organization. For example, you can use the predefined granular roles to create custom roles that provide more fine-tuned control over specific features of Red Hat Lightspeed.

By default, Red Hat provides a set of consolidated roles and a set of granular roles in the Red Hat Hybrid Cloud Console User Access UI. The consolidated roles significantly reduce the administrative effort required to manage user permissions, while the granular roles provide more fine-tuned control over specific features of Red Hat Lightspeed.

You can use the predefined consolidated and granular roles in User Access simultaneously, but using consolidated roles can significantly reduce the administrative effort.

Verify your current permissions and the roles or groups assigned to you in the Red Hat Hybrid Cloud Console. Check your permissions to troubleshoot access issues or understand your level of access to Red Hat Lightspeed applications.

You can also filter your permissions by application, for example, by advisor, cost management, inventory, and remediations.

If you are an Organization Administrator, you can view and manage user permissions for all users in your organization. Control access to Red Hat Lightspeed and other Red Hat Hybrid Cloud Console services through the User Access interface.

Understand the predefined roles that control access to malware detection features in Red Hat Lightspeed. Use these role definitions to assign appropriate permissions to users based on their responsibilities.

To view data or control settings in the malware detection service, users must be members of the User Access group with one of the following roles:

Malware detection administrators run the malware detection collector scan on-demand or through automation such as playbooks. Your security team sets how often to scan; long runs are common, so plan schedules accordingly.

Malware detection administrators must start the Red Hat Lightspeed malware detection service collector scan on-demand. Alternatively, administrators can run the collector command as a playbook or by using another automation method.

Use the Signatures page of the malware detection service to see matched and unmatched IBM X-Force and CrowdStrike signatures for scans on your Red Hat Enterprise Linux systems.

You can use the Signatures page of the malware detection service to see the signatures used to scan your Red Hat Enterprise Linux systems. All matched and unmatched signatures for IBM X-Force appear by default. If you have installed CrowdStrike signatures and completed the prerequisites, you can see all matched and unmatched signatures as well.

Matched signatures indicate the YARA software detected a file on a system that corresponds to a known threat. Unmatched signatures indicate the service is actively monitoring for those threats, but no corresponding files were detected during the most recent scan.

To filter by provider, click the cards with the IBM and CrowdStrike logos at the top of the Signatures page. The IBM card is enabled by default, while the CrowdStrike card is active only if you installed CrowdStrike signatures.

You can run either the on-demand collector or set up the malware detection collector to scan on a schedule that you control. To control your own schedule on RHEL, use cron, systemd timers, or your automation to run the insights-client --collector malware-detection command on a schedule that matches your security policy.

For more information about scheduling, see the additional resources.

You can disable certain malware signatures that are not relevant to your organization’s needs or are causing false positives. These results might be due to an intentional configuration, a test scan, or a high-noise situation in which the malware detection service reports matches that are not applicable to your security priorities.

For example, the signatures XFTI_EICAR_AV_Test and XFTI_WICAR_Javascript_Test are used to detect the EICAR Anti Malware Testfile and WICAR Javascript Crypto Miner test malware. They are intentional test signatures but do not represent actual malware threats. Signatures such as these can be disabled so that matches against them are not reported in the Red Hat Hybrid Cloud Console.

Once a signature is disabled, the malware detection service removes any existing matches against that signature from the Hybrid Cloud Console and ignores the signature in future scans. If the signature is re-enabled, the malware detection service again looks for the signature in future malware-detection scans and shows resulting matches.

Users with access to the malware detection signatures view can see how many signatures are disabled and filter the list to show only disabled signatures.

All users who can open the signatures page can view disabled malware signatures.

In most cases, running a malware detection scan with YARA results in no signature matches. This means that YARA did not find any matching strings or boolean expressions when comparing a known set of malware signatures to the files included in the scan. The malware detection service will send these results to Red Hat Lightspeed. You can see the details of the system scan and lack of matches in the Red Hat Lightspeed malware detection service UI.

In the case that the malware detection scan with YARA does detect a match, it sends the results of that match to Red Hat Lightspeed. You can see details of the match in the malware detection service UI, including the file and date. System scan and signature match history is displayed for the last 14 days, so you can detect patterns and provide information to your security incident response team. For example, if a signature match was found in one scan, but not found in the next scan of the same system, that can indicate the presence of malware that is detectable only when a certain process is running.

Match status, acknowledgment, and match lists in the console are covered in the topics linked under Additional resources.

You can acknowledge malware signatures at the system and signature levels, set match status, and reduce noise so your team can focus on real risk.

The Status field on the Signatures page enables you to select a status for each system or signature that you review. You can change the status of each signature match while you continue investigating and managing malware matches to help your system users stay informed about the progress of remediations or evaluations of malware matches. You can also decide which matches pose low or no threats to your systems or are irrelevant. If you are a member of a group with at least Malware detection administrator or RHEL administrator permissions, you can delete irrelevant matches from your systems.

The Total Matches column on the Signatures page includes all matches for a signature on a system. You can use the list of matches to track and review the history of malware matches on individual systems in your environment. Red Hat Lightspeed retains malware matches indefinitely, unless you delete them. Acknowledging malware matches and setting their status is one method of record-keeping. Note that if you delete a system from the malware service, the match records are discarded.

The New Matches column shows the number of new matches for a signature. A bell icon indicates each new match. A new match has a match date of up to 30 days from when the match was detected and has a Not Reviewed status. Matches older than 30 days, or those that have already been reviewed, become part of Total Matches.

Use the following to review and set match status on a signature, delete a single match from the list, or view matches grouped by system.

Assign Match status to malware signature matches in the malware detection service as you review each finding. The decisions for the match status value stay in the service with the match, helping to reduce repeat decisions and work. When you return to review the same items, you see your decision instead of starting from scratch on the same items.

When a match is not relevant to your environment, you can delete it from the list of signatures so that all malware detection administrators and RHEL reviewers see an up-to-date set of open items.

From Security > Malware > Systems, you can open a system, expand a matched signature, and acknowledge matches so your team’s view stays current.

The malware-detection-config.yml file defines allowlists, denylists, timing, and related scan behavior for the malware detection collector on RHEL systems.

The /etc/insights-client/malware-detection-config.yml file configures the malware detection collector on each host. The file uses YAML keys for scan scope, exclusions, process scanning, and timing. You can set the same keys with environment variables when you run the client; when both are present, environment variables override the file.

Your malware detection collector on each RHEL host reads /etc/insights-client/malware-detection-config.yml to decide what to scan, what to exclude, and whether to include processes. The tables describe each YAML option. When you want different values for a single run, you can set the same options as environment variables before you start the collector. If both are present, the environment variables override the file.

For an example of passing these variables when you run the collector from the command line, see Configure the malware collector with environment variables on the command line.

You can override /etc/insights-client/malware-detection-config.yml settings for a single run by exporting or prefixing environment variables when you run the insights-client collector.

You can enable the notifications service on Red Hat Hybrid Cloud Console to send notifications whenever the malware service detects a signature match on at least one system scan and generates an alert. Using the notifications service frees you from having to continually check the Red Hat Lightspeed dashboard for alerts. For example, you can configure the notifications service to automatically send an email message whenever the malware service detects a possible threat to your systems, or to send an email digest of all the alerts that the malware service generates each day.

In addition to sending email messages, you can configure the notifications service to send event data in other ways:

Notifications will trigger for Red Hat Lightspeed services based on service-specific criteria.

Malware service notifications include the following information:

Enabling the notifications service requires three main steps: