Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

Assessing and monitoring security vulnerabilities on RHEL systems with FedRAMP

Red Hat Lightspeed 1-latest

Understanding your environmental exposure to potential security threats

Red Hat Customer Content Services

Abstract

Use the vulnerability service with FedRAMP® to assess and monitor the status of security vulnerabilities on your Red Hat Enterprise Linux systems, understand the level of exposure of your infrastructure, and plan a course of action.

Chapter 1. Overview of the vulnerability service
Copiar o link

The vulnerability service enables quick assessment and comprehensive monitoring of the exposure of your RHEL infrastructure to Common Vulnerabilities and Exposures (CVEs) so you can better understand your most critical issues and systems and effectively manage remediations.

1.1. Prerequisites
Copiar o link

  • Each system has the insights-client installed and registered to the Red Hat Lightspeed application. Follow the Getting Started with Red Hat Lightspeed guide to install the client and register your system(s).
  • The vulnerability service is fully supported for RHEL systems managed by Red Hat Subscription Management (RHSM) and Satellite 6 and later. Using any other means to obtain package updates, other than Satellite 6 with RHSM or RHSM registered with subscription.redhat.com (Customer Portal), can lead to misleading results.
  • Vulnerability service remediations are not fully supported and may not work properly on Satellite 5 and Spacewalk-hosted RHEL systems.
  • Some features require special privileges provided by your organization administrator. Specifically, the ability to view Red Hat Security Advisories (RHSAs) associated with certain CVEs and systems, and to view and patch those vulnerabilities in the Red Hat Lightspeed patch service, requires permissions granted through user access.

1.2. How the vulnerability service works
Copiar o link

The vulnerability service uses the insights-client to gather information about your RHEL systems. The client gathers information about the systems and uploads it to the vulnerability service.

The vulnerability service then assesses the data against the Red Hat CVE database and security bulletins to determine if there are any outstanding CVEs that could affect the systems, and provides the results of those comparisons.

Once the data has been analyzed, you can view and sort the displayed results, assess the risks and priorities of the vulnerabilities, report their status, and create and deploy Ansible Playbooks to remediate them. The goal of the vulnerability service is to enable a repeatable process that protects against security weaknesses in your RHEL infrastructure.

Important

The vulnerability service shows all CVEs available for the major version of your RHEL system, even if the system has its release version locked to a specific minor release. To determine if the CVE was applied to the minor version of your RHEL system, in the Security → Vulnerability → Systems, locate your system. The Remediation type must be Manual.

1.3. Manage user permissions for Red Hat Lightspeed services
Copiar o link

Manage user permissions to control access to Red Hat Lightspeed applications. Use the User Access feature to apply role-based access control (RBAC). Red Hat provides predefined groups and a set of predefined roles to make it easier for Organization Administrators to assign, restrict, and remove user permissions to Red Hat Lightspeed.

1.3.1. User Access overview
Copiar o link

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:

  • Control user permissions and organize roles.
  • Create groups that include roles and their corresponding permissions.
  • Assign users to these groups, allowing them to inherit the permissions associated with their group’s roles.

All users on your account have access to most of the data in Red Hat Lightspeed.

1.3.2. Predefined groups in User Access
Copiar o link

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 access group
By default, the Default access group is assigned many granular predefined roles, so that group members have basic visibility. Because all users in your organization are members of the Default access group, they inherit all permissions assigned to that group. The Default access group is automatically updated by Red Hat.
Important

If your Organization Administrator modifies the Default access group, the group is automatically renamed to Custom default access. Once converted, this group is no longer automatically updated by Red Hat.

The Default admin access group
The Default admin access group contains only users who have Organization Administrator permissions. This group is automatically maintained, and users and roles in this group cannot be changed.

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.

Tip

For a list of explicitly defined roles that are included in the Default access and Default admin access groups, log in to the Hybrid Cloud Console, go to Groups and select the respective group.

1.3.3. Predefined roles assigned to groups
Copiar o link

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.

Tip

Across the Red Hat Lightspeed product documentation, the Prerequisites section for each procedure lists which predefined roles provide the permissions needed to use the features in that procedure. For example, if a procedure requires permissions to view and manage remediations, the Prerequisites section for that procedure lists the Remediations administrator or other valid role as a recommended predefined role to use for that procedure.

1.3.4. Check your permissions
Copiar o link

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.

Note

Only users with the Organization Administrator role can view the permissions of other users in the User Access settings and manage user permissions to Red Hat Lightspeed services. For more information, see the Configure user permissions section.

Prerequisites

  • You are logged in to the Red Hat Hybrid Cloud Console.

Procedure

  1. In the Hybrid Cloud Console, click the Settings icon (⚙), then navigate to My User Access.
  2. If you try to access Red Hat Lightspeed features and see a message that you do not have permission to perform this action, contact your Organization Administrator or a user with the User Access administrator role to request the permissions required to access those features and complete the actions you want to perform.

Results

All of the applications that you have permissions to access are listed on this page and are grouped by product, for example, RHEL, OpenShift Container Platform, and Ansible Automation Platform.

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

1.3.5. Configure user permissions
Copiar o link

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.

Important

If you are not an Organization Administrator, you will be unable to complete this task. However, you can check your own permissions for different applications by navigating to My User Access. Contact your Organization Administrator to request more permissions.

Prerequisites

  • You have logged in to the Red Hat Hybrid Cloud Console as an Organization Administrator, or you have the required administrator User Access role permissions.

Procedure

Results

From here, you can create and manage:

  • Roles to determine permissions to Red Hat Lightspeed services and features
  • Groups to include one or more roles to align with a specific persona, job function, or team in your organization
  • Users and their assignment to groups to inherit permissions from the roles assigned to those groups

1.3.6. User Access roles for permissions to vulnerability service features
Copiar o link

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

The following roles enable enhanced access to vulnerability features:

Expand
Table 1.1. Permissions provided by the User Access roles
User Access roleGrants permissions to …​Included in the Default access group

Vulnerability administrator

  • Do everything that a Vulnerability viewer can do.
  • Do any available operations against any vulnerability-service resource.
 

Vulnerability viewer

  • Read any vulnerability-service resource.

X

Chapter 2. Common Vulnerabilities and Exposures (CVEs)
Copiar o link

Common Vulnerabilities and Exposures (CVEs) are security vulnerabilities identified in publicly released software packages. Only Red Hat CVEs, those CVEs for which Red Hat issues security advisories (RHSAs), are included in the vulnerability service.

2.1. Red Hat Security Advisories (RHSAs)
Copiar o link

Red Hat Security Advisory (RHSA) errata document security vulnerabilities in Red Hat products for which there are remediations or mitigations available. The Red Hat Lightspeed vulnerability service displays the advisory identifier tied to each system exposed to a CVE.

View this information by selecting a CVE and selecting the Filter by affected systems link in the security rule card. If an advisory exists for the system, the RHSA ID is visible as a link next to the system in the Exposed systems list, Advisory column. When there are no such advisories, the Advisory column is not visible, or will show “Not available.”

When an advisory exists for a system, users can view more information about the RHSA, including a list of affected systems. In the patch service, users can select systems to create an Ansible Playbook to apply the remediation.

2.2. Security rules
Copiar o link

Security rules are CVEs given additional visibility due to the elevated risk and exposure associated with them.

These are security flaws that may receive significant media coverage and have been scrutinized by the Red Hat Product Security team, using the Product Security Incident Response Plan workflow to help determine your RHEL environment exposure. These security rules enable you to take the appropriate action to protect your organization.

Security rules provide deep threat intelligence, beyond analyzing the version of RHEL running on a system. Security rules are manually curated to determine whether you are susceptible to a security threat by analyzing system metadata collected by the insights-client. If the vulnerability service identifies a system as exposed to a security rule, there is the potential for elevated security risk and issues should be addressed with urgency.

Important

Addressing security rules on exposed systems should be your highest priority.

Finally, not all systems exposed to a CVE are also exposed to a security rule associated with that CVE. Even though you may be running a vulnerable version of software, other environmental conditions may mitigate the threat; for example, a specific port is closed or if you are running SELinux.

2.2.1. Identifying security rules in the Red Hat Lightspeed dashboard
Copiar o link

Use the following steps to view your infrastructure exposure to security rules.

Procedure

  1. Navigate to the Red Hat Lightspeed dashboard.

  2. View the Latest critical notifications on your systems panel. These are security rules with an elevated severity rating of “Important” or “Critical.” These are potentially your most critical issues and should be prioritized for remediation.

    1. To the right of each notification, click the Expand button to see associated CVEs and the number of systems exposed in your infrastructure.

      Note

      You may see security rules in your critical notifications but have zero systems exposed. In this case, even though the CVE is present in your infrastructure, the security rule conditions may not exist.

    2. Below the name of the security rule, and under Associated CVEs, click the CVE ID link.
    3. View which of your systems is impacted by the security rule CVE and optionally select exposed systems to create playbooks.

  3. Next, view the information in the vulnerability card.

    1. Note the number of “CVEs with security rules impacting systems.” This number includes security rules of any severity impacting at least one system.

      1. Click View CVEs. Consider lesser-severity security rules your second highest priority for remediation, following high-severity security rules.

2.3. Known exploits
Copiar o link

Red Hat analyzes Cybersecurity and Infrastructure Security Agency (CISA) data, to determine whether code exists publicly to exploit a CVE, or a CVE has already been exploited publicly. The vulnerability service applies the “Known exploits” label to CVEs that meet that criteria.

This enhanced threat assessment can help users identify and address those CVEs that pose the most critical risks first. Red Hat recommends users review any CVEs with the “Known exploit” label with high priority and work towards remediating those issues.

Important

The vulnerability service makes you aware that the known-exploit CVE exists on systems in your infrastructure. The “Known exploits” label does not mean that the vulnerability was exploited on your RHEL systems; the vulnerability service does not make that determination.

The vulnerability service provides you with data about individual Common Vulnerabilities and Exposures (CVEs) and their effect on your systems registered to Red Hat Lightspeed.

CVEs are categorized as vulnerable or affected but not vulnerable. This level of threat intelligence is available for CVEs that have the Security Rule label or for those that have gone through Red Hat Product Security’s rigorous analysis.

This increased threat intelligence enables you to triage issues and address the most urgent ones first. When managing a large fleet of servers, this translates into expedited protection and significant efficiencies.

An affected but not vulnerable CVE status indicates that you are running software that has a vulnerability in it but is not currently exploitable. This system will need remediation but does not require immediate attention.

A vulnerable CVE status indicates flawed code with an open path to exploitation. An open path could be a port or an OS version that permits one of the following: confidential information to be leaked, the integrity of the system to be compromised or availability of the system to be hindered.

Let us look at an example of a vulnerable server versus an affected but not vulnerable server:

Suppose that Server A is running vulnerable software that allows root access to the system. Server A would be considered vulnerable and require immediate patching.

In contrast, suppose that Server B’s current configuration prevents the vulnerability from manifesting, even when present in the affected code. Server B would be considered affected but not vulnerable. This would mean that Server B could be relegated to the to-do list, so that the more immediate threat, Server A could be remediated.

Important

You should patch Server B once Server A has been addressed since it is running potentially vulnerable code. Version updates and other events could render it vulnerable in the future.

2.4.1. Identifying known-exploit CVEs in the Red Hat Lightspeed dashboard
Copiar o link

You can identify known-exploit CVEs in the Red Hat Lightspeed dashboard vulnerability card.

Procedure

  1. Navigate to the Red Hat Lightspeed dashboard.
  2. On the Vulnerability card, note the CVEs with Known exploits impacting 1 or more systems and the number displayed.
  3. Click View Known exploits.
  4. View the filtered list of Known-exploit CVEs in the CVEs list.

Chapter 3. Refining vulnerability-service results
Copiar o link

The vulnerability service enables many ways to refine the views of your data, helping you and others focus on your most critical systems, workloads, or issues.

3.1. CVE-list and systems-list filters
Copiar o link

Filtering narrows the visible list of CVEs and associated systems, helping you to focus on specific issues.

You can apply filters to the CVEs list to focus on CVEs by criticality or business risk, for example. After selecting an individual CVE, apply filters to the resulting list of affected systems to focus on those of a specific RHEL major or minor version, for example.

To activate filters, select a primary filter from the drop-down list of filters on the left, and then select a secondary subfilter from the filter options drop-down list on the right. Selected filters are visible below the Filters menu. To deactivate filters, click the X next to each one.

CVEs list filters

Shows several filter options in the filter drop-down

The following primary filters are accessible from the CVEs page. Select the primary filter, then define a parameter in the subfilter:

  • CVE. Search ID or description.
  • Security rules. Show only CVEs with the "Security rule" label.
  • Known exploit. Show only CVEs with the "Known exploit" label.
  • Severity. Select one or more values: Critical, Important, Moderate, Low, or Unknown.
  • Applies to OS. Select up to five minor versions of Red Hat Enterprise Linux to view vulnerability exposure for those versions to a specific CVE.
  • CVSS base score. Select one or more ranges: All, 0.0-3.9, 4.0-7.9, 8.0-10.0, N/A (not applicable)
  • Business risk. Select one or more values: High, Medium, Low, Not defined.
  • Systems exposed . Select to only show CVEs with systems currently affected, or with no systems affected.
  • Publish date. Select from All, Last 7 days, Last 30 days, Last 90 days, Last year, or More than 1 year ago.
  • Status. Select one or more values: Not reviewed, In review, On-hold, Scheduled for patch, Resolved, No action - risk accepted, Resolved via mitigation.
Systems list filters

Primary filters on the CVE details page

The following primary filters are accessible from the top of the list of systems on the CVE details page:

  • Name. Find a specific CVE by entering the CVE ID.
  • Security rules. If the CVE has a security rule associated with it, filter by other systems vulnerable to the same security rule, or show systems not affected by the security rule.
  • Status. Show systems in specific status or workflow categories.
  • Advisory. Show systems to which a Red Hat advisory applies for this CVE.
  • Operating system. Show systems running specific RHEL (minor) versions.
  • Remediation. Show systems included in an Ansible Playbook, a manual remediation, or that are not included in a current remediation plan.

3.1.1. Filtering security-rule CVEs
Copiar o link

Security rules, especially high-severity security rules, pose the greatest potential threat to your infrastructure and must be considered the highest priority for identification and remediation. You can view only high-severity security-rule CVEs in the CVEs list and identify affected systems.

Important

Not all systems exposed to a CVE are also exposed to a security rule associated with that CVE. Even though you may be running a vulnerable version of software, other environmental conditions may mitigate the threat; for example, a specific port is closed or SELinux is enabled.

Procedure

  1. Navigate to Security > Vulnerability > CVEs in Red Hat Lightspeed.

  2. Click the filters dropdown list in the toolbar.

    1. Apply the Security rules filter.
    2. Apply the Has security rule subfilter.
  3. Scroll down to view security-rule CVEs. CVEs with security rules display the security-rule label located immediately below the CVE ID.

3.1.2. Remediating vulnerabilities with security rules on RHEL Systems
Copiar o link

CVEs with security rules are CVEs prioritized by Red Hat because they focus on issues that have elevated risk to your systems. Remediating these issues helps support a security posture that prioritizes the most important issues for your organization.

Using the vulnerability service and the remediations service, you can prioritize and remediate some of the most important threats to your systems by:

3.1.3. Filtering known-exploit CVEs
Copiar o link

CVEs with the Known exploit label are determined by Red Hat to have exploits that are known to the wide audience. That means either the code exists publicly to exploit the CVE, or an exploit is known publicly to have already happened.

For these reasons, known-exploit CVEs should be prioritized for identification and remediation.

Important

Red Hat does not determine whether any of your registered systems have been exploited. We are simply identifying CVEs that may pose an extraordinary risk.

You can filter known-exploit CVEs in the CVEs list.

Procedure

  1. Navigate to Security > Vulnerability > CVEs in Red Hat Lightspeed.

  2. Click the filters drop-down list in the toolbar.

    1. Apply the Known exploit filter.
    2. Apply the Has a known exploit subfilter.
  3. Scroll down to view the list of known-exploit CVEs.

3.1.4. Filtering CVEs without associated advisories
Copiar o link

Some CVEs do not have associated advisories, also called errata. This might happen for any of the following reasons:

  • No fix is available for the CVE
  • Product Security analysis determines that the CVE affects your environment, but has no errata available for your environment (although the same CVE can have errata in other environments)
  • Your system is no longer under support
Important

CVE information is currently available for RHEL 6, 7, 8, and 9. No information is available for RHEL 5 systems.

Being able to identify the CVEs without advisories enables you to take measures to protect your organization from exposures associated with those vulnerabilities, so that you can take the necessary steps to address the issues.

If your version of RHEL does not have a fix available and is listed as “Will not fix,” consider the following criteria:

  • The impact of the vulnerability (severity)
  • The life cycle phase of your version of RHEL

If you decide that a fix is necessary for a CVE without an associated advisory, the following options are available:

  • Accept the risk
  • Upgrade to a supported product version that includes a fix for this vulnerability, if available (recommended)
  • Apply a mitigation (if one exists)

Additional resources

3.1.4.1. Enabling CVEs without advisories
Copiar o link

Enabling CVEs without advisories allows you to access systems affected by CVEs without advisories in Red Hat Lightspeed.

This feature is enabled by default, but CVEs without advisories are hidden by default in the main view. This means that you must use filters to display and view CVEs without advisories.

Important

Red Hat’s policy requires Red Hat Lightspeed to display all high priority, critical, and important CVEs, regardless of whether those CVEs have associated advisories.

Prerequisites

  • Vulnerability administrator access to your environment in Red Hat Lightspeed

Procedure

  1. From the Red Hat Lightspeed dashboard, navigate to Security > Vulnerability > CVEs.
  2. Click the More options icon (⋮) and select Show CVEs without Advisories. The list of advisories includes CVEs without advisories.
3.1.4.2. Disabling CVEs without advisories
Copiar o link

To disable the CVEs without advisories feature, deselect the Show CVEs without Advisories option.

The CVEs without advisories option is enabled by default, but the default view hides CVEs without advisories.

Note

Red Hat’s policy requires Red Hat Lightspeed to display all high priority, critical, and important CVEs, regardless of whether those CVEs have associated advisories.

Prerequisites

  • Vulnerability administrator access to your environment in Red Hat Lightspeed
  • The list of advisories includes CVEs without advisories

Procedure

  1. From the Red Hat Lightspeed dashboard, navigate to Security > Vulnerability > CVEs.
  2. Click the More options icon (⋮) and select Hide CVEs without Advisories.
3.1.4.3. Viewing CVEs without advisories
Copiar o link

The Show CVEs without Advisories option enables or disables CVEs without advisories. To view CVEs without advisories, the Show CVEs without Advisories option must be enabled.

Prerequisites

  • The Organization Administrator has enabled the CVEs without advisories option.

Procedure

  1. From the Red Hat Lightspeed dashboard, navigate to Security > Vulnerability > CVEs.
  2. From the filter drop-down, select Advisory.
  3. From the Filter by Advisory drop-down, select Not Available. The list of advisories shows all CVEs without advisories.
3.1.4.4. Identifying systems affected by a CVE without advisories
Copiar o link

The CVE details page displays the list of all systems affected by the selected CVE. You can filter the list of systems to display the systems affected by the CVE where an advisory is not present.

Prerequisites

  • The Organization Administrator has enabled the CVEs without advisories option.

Procedure

  1. Identify a CVE without advisories for which you want to see systems that it affects. For more information about identifying CVEs without advisories, refer to Identifying systems with CVEs without Advisories.

  2. Select the identified CVE to navigate to the CVE details page. The CVE details page for that CVE displays. The page lists all the systems affected by that CVE.

    1. If you apply the Filter by Advisory filter and Not Available option when you select a CVE, these filters persist to the CVE details page.
    2. Otherwise, when you navigate to the CVE details page, select Advisory from the filters at the top of the page, and then Select Filter by Advisory, and click the Not Available checkbox. The list of systems updates to show only systems affected by that CVE without advisories. The Advisory column shows Not Available for each system in the list.
  3. Optional: To view details for the system, select the name of the system you want to view. The details page for the system displays.
3.1.4.5. Viewing CVEs without advisories in system details
Copiar o link

The system details page displays the list of all CVEs that affect the selected system. You can filter the list of CVEs to display the CVEs without advisories.

Prerequisites

  • The Organization Administrator has enabled the CVEs without advisories option.

Procedure

  1. From the Red Hat Lightspeed dashboard, navigate to Security > Vulnerability > Systems. The Vulnerability systems page displays.
  2. Select a system ID from the list. The system details page for that system displays. The page lists all the CVEs that affect the selected system.
  3. Select Advisory from the filters at the top of the page.
  4. Select Filter by Advisory, and select the Not Available checkbox. The list of CVEs updates to show only CVEs without advisories. The Advisory column shows Not Available for each CVE in the list.
  5. Optional: To view details for the CVE, select the CVE ID for the CVE you want to view. The details page for the CVE displays.

3.2. Filtering CVEs by RHEL version
Copiar o link

You can view and manage systems running a specific version of RHEL that are exposed to the selected CVE in the Applies to OS column on the CVEs page.

It lists the major and minor versions of RHEL that each CVE affects. By viewing this information, you can understand the degree of vulnerability exposure for those systems, and make informed decisions about possible upgrade paths.

Note

The vulnerability exposure feature supports RHEL major and minor versions from RHEL 6.9 to RHEL 10.1 and later.

Prerequisites

  • You are logged in as an Organization Administrator, or you have Vulnerability Administrator access to your environment in Red Hat Lightspeed.

Procedure

  1. From the Red Hat Lightspeed dashboard, navigate to Security > Vulnerability > CVEs. The CVEs page displays a list of CVEs that could affect systems in your environment.
  2. Select the Applies to OS filter.

  3. In the Filters by Applies to OS subfilter, click the drop-down menu and select the versions of RHEL you want to view. The list of CVEs displays the RHEL versions you selected.

    Note

    For a quick view of all RHEL versions affected by a specific CVE, navigate to the row that shows the CVE and hover your cursor over the ellipsis (…​) in the Applies to OS column. A tooltip appears with a list of all affected RHEL versions.

Additional resources

3.3. Filtering lists of systems exposed to security rules
Copiar o link

After filtering the list of CVEs to view only your most critical potential threats, select an individual CVE to view the list of exposed systems and apply a filter to the list.

Procedure

  1. After selecting a security-rule CVE, scroll down to the Exposed systems list. Not every system in the list has the security rule conditions present for the CVE to be a security rule. Apply the following filter to see only the systems with security rule conditions present.
  2. Select the Security rules filter from the primary filter dropdown list.
  3. Check the Has security rule box in the secondary subfilter dropdown list.
  4. View the systems with exposure to that CVE that also have the conditions present for the security rules.

3.4. Red Hat Lightspeed group filters
Copiar o link

You can view only those systems that belong to a specific group by filtering the vulnerability service results by groups of systems or workloads. These can be systems running SAP workloads or SAP ID, by Satellite host groups, or by custom tags added to the insights-client configuration file.

Group filtering can be set globally in Red Hat Lightspeed using the Filter results box located at the top of the page throughout the Red Hat Lightspeed application. Group selection persists when changing from service to service and page to page. However, the functionality varies within the different Red Hat Lightspeed services.

Group filtering works in the vulnerability Dashboard and vulnerability service CVEs and Systems lists.

Learn more about group tags and configuring custom tags in Tags and system groups section of this document.

3.4.1. Filtering Dashboard, CVEs, and Systems lists by group
Copiar o link

Use the following procedure to filter vulnerability service CVE and Systems lists by group.

Procedure

  1. Navigate to Red Hat Hybrid Cloud Console and log in.
  2. Open the Red Hat Lightspeed application.
  3. Click the down arrow on the Filter results box located at the top of any page in the Red Hat Lightspeed application.

  4. Select a group by which to filter your systems.

    Search or scroll to view available tags. To browse the full list of available tags, scroll to the bottom of the list and click View more.

    Optionally,

    1. Select SAP workloads.
    2. Select systems by specific SAP IDs.
    3. Select Satellite host collections.

    4. Select systems identified by custom group tags.

      To learn more about creating custom tags, see section, Custom system tagging, in this document.

  5. Navigate to the service and view only systems or CVEs that belong to your selected group or groups.

3.5. Defining a business risk for a CVE
Copiar o link

The vulnerability service allows you to define the business risk of a CVE with the following options: High, Medium, Low, or Not Defined (default).

While the list of CVEs shows the severity of each CVE, assigning a business risk lets you rank CVEs based on the impact they could have on your organization. This can give you more control in managing your risk efficiently in a large environment, and enable you to make better operational decisions.

By default, the business risk field for a specific CVE is set to Not Defined. After you set the business risk, it is visible in the Security > Vulnerability > CVEs list, in the CVE row.

CVE with a Medium business

Business risk is also visible on the details card for each CVE, which shows more information and lists affected systems.

Details card in the vulnerability service that shows a CVE showing a Medium business risk

3.5.1. Setting a business risk for a single CVE
Copiar o link

You can set the business risk for a single CVE by using the vulnerability service.

Important

The business risk for that CVE will be the same on all systems impacted by it.

Procedure

  1. Navigate to the Security > Vulnerability > CVEs page and log in if necessary.
  2. Identify a CVE for which to set a business risk.

  3. Click the more-actions icon (three vertical dots) on the right end of the CVE row and click Edit business risk.

    Shows two CVEs with the option to Edit business risk highlighted on the CVE page

  4. Set a business risk value to the appropriate level and, optionally, add a justification for your risk assessment.
  5. Click Save.

3.5.2. Setting a business risk for multiple CVEs
Copiar o link

You can set the same business risk on multiple CVEs that you select by using vulnerability service.

Procedure

  1. Navigate to Security > Vulnerability > CVEs and log in if necessary.
  2. Check the boxes for the CVEs for which you want to set a business risk.

  3. Perform the following steps to set a business risk:

    1. Click the more-actions icon (three vertical dots) to the right of the Filters drop-down menu in the toolbar and click Edit business risk.
    2. Set an appropriate business risk value and, optionally, add a justification for your risk assessment.
    3. Click Save.

3.6. Excluding systems from vulnerability service analysis
Copiar o link

The vulnerability service allows you to exclude specific systems from vulnerability analysis. This can save you the time and attention required to review and re-review issues on systems that are not relevant to your organization’s goals.

As an example, if you have the following category of servers: QA, Dev, and Production, you may not care to review the vulnerabilities for your QA servers and therefore want to exclude these systems from the analysis performed by the vulnerability service.

When you exclude systems from vulnerability analysis, the insights-client still runs as scheduled on the system, but the results for the system are not visible in the vulnerability service. The continued operations of the client ensure that other Red Hat Lightspeed services can still upload the data they need. It also means that you can still view results for those systems using filtering.

Procedure

  1. Navigate to the Security > Vulnerability > Systems tab and log in if necessary.
  2. Check the box for each system you want to exclude from vulnerability analysis.

  3. Click the more-actions icon in the toolbar, at the top of the list of systems, and select Exclude systems from vulnerability analysis.

    Vulnerability service showing three systems on the systems page that are selected to be excluded from a vulnerability analysis

  4. Optionally, you can exclude a single system by clicking the more-actions icon in the system row and selecting Exclude system from vulnerability analysis.

    Vulnerability service showing one system on the systems page that can be selected to be excluded from a vulnerability analysis

3.7. Showing previously excluded systems
Copiar o link

Complete the following steps to show a previously excluded system:

Procedure

  1. Navigate to the Security > Vulnerability > Systems tab and log in if necessary.
  2. Click the more-actions icon in the toolbar, at the top of the list of systems, and select Show systems excluded from analysis.
  3. See systems excluded from vulnerability analysis. This can be verified by the value of Excluded in the Applicable CVEs column.

3.8. Resuming vulnerability analysis for a system
Copiar o link

Complete the following steps to resume vulnerability analysis for a system:

Procedure

  1. Navigate to the Security > Vulnerability > Systems tab and log in if necessary.
  2. Click the more-actions icon in the toolbar, at the top of the list of systems, and select Show systems excluded from analysis.
  3. In the list of results, check the box for each system for which you want to resume vulnerability analysis.
  4. Click the more-actions icon again and select Resume analysis for system.

3.9. CVE status
Copiar o link

Another method of managing CVEs impacting your systems is by setting a status for CVEs. The vulnerability service enables the following ways of setting a status for a CVE:

  • Set a status for a CVE for all systems.
  • Set a status for a specific CVE + system pair.

Status values are preset and include the following options:

  • Not reviewed (default)
  • In-review
  • On-hold
  • Scheduled for patch
  • Resolved
  • No action - risk accepted
  • Resolved via mitigation

Setting a status for a CVE can facilitate better triaging through its life-cycle, from becoming aware of it to remediating it. Defining a status allows your organization to keep better tabs on where the most critical CVEs are in their life-cycle and where you should focus your efforts to address the most critical issues per your business need. The status for a CVE is visible in all CVE tables in the vulnerability service and in individual CVE views.

3.9.1. Setting a status for a CVE on all affected systems
Copiar o link

You can set a status for a CVE and have that status apply to that CVE on all of the systems it impacts.

Procedure

  1. Navigate to the Security > Vulnerability > CVEs tab and log in if necessary.
  2. Click the more-actions icon located on the right end of the CVE row and select Edit status.
  3. Select the appropriate status and, optionally, enter a rationale for your decision in the Justification text box.
  4. Check Do not overwrite individual system status if there are statuses set for this CVE on individual systems and that you want to preserve. Otherwise, leave the box unchecked to apply this status to all of the systems it is impacting.
  5. Click Save.

3.9.2. Setting a status for a CVE and system pair
Copiar o link

Complete the following steps to set a status on a CVE and system pair:

Procedure

  1. Navigate to the Security > Vulnerability > Systems tab and log in if necessary.
  2. Identify the system and click the system name to open it.
  3. Select a CVE from the list and check the box next to the CVE ID.

  4. Click the more-options icon in the toolbar and select Edit status.

    One system selected on the Systems page with the More options icon expanded to show options to Edit status or Expand all CVEs

  5. In the popup card, take the following actions:

    1. Set a status for the CVE and system pair.

      Note

      If the box to Use overall CVE status is checked, you cannot set a status for the pair.

    2. Optionally, enter a justification for your status determination.
    3. Click Save.
  6. Locate the CVE in the list and verify the status is set.

3.11. Sorting CVE list data
Copiar o link

The sorting functions in the vulnerability service differ based on the context of the page you are viewing.

Procedure

  1. In the CVEs tab, you can apply sorting to the following columns:

    • CVE ID
    • Publish date
    • Severity
    • CVSS base score
    • Systems exposed
    • Business risk
    • Status

  2. In the Systems tab, the following column can be sorted:

    • Name
    • Applicable CVEs
    • Last seen

  3. After selecting a system in the Systems tab, the system-specific list of CVEs allows the following sorting options:

    • CVE ID
    • Publish date
    • Impact
    • CVSS base score
    • Business risk
    • Status

Chapter 4. System tags and groups
Copiar o link

Red Hat Lightspeed enables administrators to filter groups of systems in inventory and in individual services using group tags. Groups are identified by the method of system data ingestion to Red Hat Lightspeed. Red Hat Lightspeed enables filtering groups of systems by those running SAP workloads, by Satellite host group, by Microsoft SQL Server workload, and by custom tags that are defined by system administrators with root access to configure the insights-client on the system.

Note

As of Spring 2022, the inventory, advisor, compliance, vulnerability, and patch services enable filtering by groups and tags. Other services will follow.

Important

Unlike the other services that enable tagging, the compliance service sets tags within lists of systems in the compliance service UI. For more information, see the following section Group and tag filters in the compliance service.

Use the global, Filter results box to filter by SAP workloads, Satellite host groups, MS SQL Server workloads, or by custom tags added to the insights-client configuration file.

Prerequisites

The following prerequisites and conditions must be met to use the tagging features in Red Hat Lightspeed:

  • The insights-client is installed and registered on each system.
  • You must have root permissions, or their equivalent, to create custom tags or change the /etc/insights-client/tags.yaml file.

4.1. Group and tag filters in the compliance service
Copiar o link

The compliance service enables users to apply tag and group filters to systems that report compliance data. However, they are not set by using the Filter by status drop-down.

Unlike most of the other services in the Red Hat Lightspeed application, the compliance service only shows data for systems under the following conditions:

  • The system is associated with a compliance service security policy.
  • The system is reporting compliance data to Red Hat Lightspeed using the insights-client --compliance command.

Because of those conditions, compliance-service users have to set tag and group filters using the primary and secondary filters located above lists of systems in the compliance service UI.

4.2. SAP workloads
Copiar o link

As Linux becomes the mandatory operating system for SAP ERP workloads in 2025, Red Hat Enterprise Linux and Red Hat Lightspeed are working to make Red Hat Lightspeed the management tool of choice for SAP administrators.

As part of this ongoing effort, Red Hat Lightspeed automatically tags systems running SAP workloads and by SAP ID (SID), without any customization needed by administrators. Users can easily filter those workloads throughout the Red Hat Lightspeed application by using the global Filter by tags drop-down menu.

4.3. Satellite host groups
Copiar o link

Satellite host groups are configured in Satellite and recognized automatically by Red Hat Lightspeed.

4.4. Microsoft SQL Server workloads
Copiar o link

Using the global Filter by tags feature, Red Hat Lightspeed users can select groups of systems running Microsoft SQL Server workloads.

In May of 2019, the Red Hat Lightspeed team introduced a new set of Red Hat Lightspeed recommendations for Microsoft SQL Server running on Red Hat Enterprise Linux (RHEL). These rules alert administrators to operating system level configurations that do not conform to the documented recommendations from Microsoft and Red Hat.

A limitation of these rules was that they primarily analyzed the operating system and not the database itself. The latest release of Red Hat Lightspeed and RHEL 8.5, introduces Microsoft SQL Assessment API. The SQL Assessment API provides a mechanism to evaluate the database configuration of MS SQL Server for best practices. The API is delivered with a rule set containing best practice rules suggested by the Microsoft SQL Server Team. While this rule set is enhanced with the release of new versions, the API is built with the intent to give a highly customizable and extensible solution, which enables users to tune the default rules and create their own.

The SQL Assessment API is supported by PowerShell for Linux (available from Microsoft), and Microsoft has developed a PowerShell script that can be used to call the API and store its results as a JSON formatted file. With RHEL 8.5, the insights-client now uploads this JSON file and presents the results in an easy-to-understand format in the Red Hat Lightspeed UI.

For more information about SQL Server assessment in Red Hat Lightspeed, see SQL Server database best practices now available through Red Hat Lightspeed.

4.4.1. Setting up SQL Server assessments
Copiar o link

To configure the Microsoft SQL Assessment API to provide information to Red Hat Lightspeed, the database administrator needs to take the following steps.

Procedure

  1. In the database you wish to assess, create a login for SQL Server assessments using SQL Authentication. The following Transact-SQL creates a login. Replace <*PASSWORD*> with a strong password: 

    USE [master]
GO
CREATE LOGIN [assessmentLogin] with PASSWORD= N'<*PASSWORD*>’
ALTER SERVER ROLE [sysadmin] ADD MEMBER [assessmentLogin]
GO

  2. Store the credentials for login on the system as follows, again replacing <*PASSWORD*> with the password you used in step 1. 

    # echo "assessmentLogin" > /var/opt/mssql/secrets/assessment
# echo "<*PASSWORD*>" >> /var/opt/mssql/secrets/assessment

  3. Secure the credentials used by the assessment tool by ensuring that only the mssql user can access the credentials. 

    # chmod 0600 /var/opt/mssql/secrets/assessment
# chown mssql:mssql /var/opt/mssql/secrets/assessment

  4. Download PowerShell from the microsoft-tools repository. This is the same repository you configured when you installed the mssql-tools and mssqlodbc17 packages as part of SQL Server installation. 

    # yum -y  install powershell

  5. Install the SQLServer module for PowerShell. This module includes the assessment API. 

    # su mssql -c "/usr/bin/pwsh -Command Install-Module SqlServer"

  6. Download the runassessment script from the Microsoft examples GitHub repository. Ensure it is owned and executable by mssql. 

    # /bin/curl -LJ0 -o /opt/mssql/bin/runassessment.ps1 https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/manage/sql-assessment-api/RHEL/runassessment.ps1
# chown mssql:mssql /opt/mssql/bin/runassessment.ps1
# chmod 0700 /opt/mssql/bin/runassessment.ps1

  7. Create the directory that will store the log file used by Red Hat Lightspeed. Again, make sure it is owned and executable by mssql. 

    # mkdir /var/opt/mssql/log/assessments/
# chown mssql:mssql /var/opt/mssql/log/assessments/
# chmod 0700 /var/opt/mssql/log/assessments/

  8. You can now create your first assessment, but be sure to do so as the user mssql so that subsequent assessments can be run automatically via cron or systemd more securely as the mssql user. 

    # su mssql -c "pwsh -File /opt/mssql/bin/runassessment.ps1"

  9. Red Hat Lightspeed will automatically include the assessment next time it runs, or you can start the insights-client by running this command: 

    # insights-client
4.4.1.1. Setting up the SQL Assessment on a timer
Copiar o link

Because SQL Server Assessments can take 10 minutes or more to complete, it may or may not make sense for you to run the assessment process automatically every day. If you would like to run them automatically, the Red Hat SQL Server community has created systemd service and timer files to use with the assessment tool.

Procedure

  1. Download the following files from Red Hat public SQL Server Community of Practice GitHub site.

    • mssql-runassessment.service
    • mssql-runassessment.timer

  2. Install both files in the directory /etc/systemd/system/: 

    # cp mssql-runassessment.service /etc/systemd/system/
# cp mssql-runassessment.timer /etc/systemd/system/
# chmod 644 /etc/systemd/system/

  3. Enable the timer with: 

    # systemctl enable --now mssql-runassessment.timer

4.5. Custom system tagging
Copiar o link

By applying custom grouping and tagging to your systems, you can add contextual markers to individual systems, filter by those tags in the Red Hat Lightspeed application, and more easily focus on related systems. This functionality can be especially valuable when deploying Red Hat Lightspeed at scale, with many hundreds or thousands of systems under management.

In addition to the ability to add custom tags to several Red Hat Lightspeed services, you can add predefined tags. The advisor service can use those tags to create targeted recommendations for your systems that might require more attention, such as those systems that require a higher level of security.

Note

To create custom and predefined tags, you must have root permissions, or their equivalent, to add to, or change the /etc/insights-client/tags.yaml file.

4.5.1. Tag structure
Copiar o link

Tags use a namespace/key=value paired structure.

  • Namespace. The namespace is the name of the ingestion point, insights-client, and cannot be changed. The tags.yaml file is abstracted from the namespace, which is injected by the insights-client before upload.
  • Key. The key can be a user-chosen key or a predefined key from the system. You can use a mix of capitalization, letters, numbers, symbols and whitespace.
  • Value. Define your own descriptive string value. You can use a mix of capitalization, letters, numbers, symbols and whitespace.
Note

The advisor service includes Red Hat-supported predefined tags.

4.5.2. Creating a tags.yaml file and adding a custom group
Copiar o link

Create and add tags to /etc/insights-client/tags.yaml simply by using insights-client --group=<name-you-choose>, which performs the following actions:

  • Creates the etc/insights-client/tags.yaml file
  • Adds the group= key and <name-you-choose> value to tags.yaml
  • Uploads a fresh archive from the system to the Red Hat Lightspeed application so the new tag is immediately visible along with your latest results

After creating the initial group tag, add additional tags as needed by editing the /etc/insights-client/tags.yaml file.

The following procedure shows how to create the /etc/insights-client/tags.yaml file and the initial group, then verify the tag exists in the Red Hat Lightspeed inventory.

Procedure to create new group

  1. Run the following command as root, adding your custom group name after --group=: 

    [root@server ~]# insights-client --group=<name-you-choose>

Example of tags.yaml format

The following example of a tags.yaml file shows an example of file format and additional tags added for the new group: 

# tags
---
group: eastern-sap
name: Jane Example
contact: jexample@corporate.com
Zone: eastern time zone
Location:
- gray_rack
- basement
Application: SAP

Procedure to verify your custom group was created

  1. Navigate to Red Hat Lightspeed > RHEL > Inventory > Systems and log in if necessary.
  2. Click the Filter results dropdown menu.
  3. Scroll through the list or use the search function to locate the tag.
  4. Click the tag to filter by it.
  5. Verify that your system is among the results on the advisor systems list.

Procedure to verify that the system is tagged

  1. Navigate to Red Hat Lightspeed > RHEL > Inventory > Systems and log in if necessary.
  2. Activate the Name filter and begin typing the system name until you see your system, then select it.
  3. Verify that, next to the system name, the tag symbol is darkened and shows a number representing the correct number of tags applied.

4.5.3. Editing tags.yaml to add or change tags
Copiar o link

After creating the group filter, edit the contents of /etc/insights-client/tags.yaml as needed to add or modify tags.

Procedure

  1. Using the command line, open the tag configuration file for editing.

    [root@server ~]# vi /etc/insights-client/tags.yaml

  2. Edit content or add additional values as needed. The following example shows how you can organize tags.yaml when adding multiple tags to a system. 

    # tags
---
group: eastern-sap
location: Boston
description:
- RHEL8
- SAP
key 4: value
    Note

    Add as many key=value pairs as you need. Use a mix of capitalization, letters, numbers, symbols, and whitespace.

  3. Save your changes and close the editor.

  4. Optionally, generate an upload to Red Hat Lightspeed. 

    # insights-client

Red Hat Lightspeed advisor service recommendations treat every system equally. However, some systems might require more security than others, or require different networking performance levels. In addition to the ability to add custom tags, Red Hat Lightspeed provides predefined tags that the advisor service can use to create targeted recommendations for your systems that might require more attention.

To opt in and get the extended security hardening and enhanced detection and remediation capabilities offered by predefined tags, you need to configure the tags. After configuration, the advisor service provides recommendations based on tailored severity levels, and preferred network performance that apply to your systems.

To configure the tags, use the /etc/insights-client/tags.yaml file to tag systems with predefined tags in a similar way that you might use it to tag systems in the inventory service. The predefined tags are configured using the same key=value structure used to create custom tags. Details about the Red Hat-predefined tags are in the following table.

Expand
Table 4.1. List of Supported Predefined Tags
KeyValueNote

security

normal (default) / strict

With the normal (default) value, the advisor service compares the system’s risk profile to a baseline derived from the default configuration of the most recent version of RHEL and from often-used usage patterns. This keeps recommendations focused, actionable, and low in numbers. With the strict value, the advisor service considers the system to be security-sensitive, causing specific recommendations to use a stricter baseline, potentially showing recommendations even on fresh up-to-date RHEL installations.

network_performance

null (default) / latency / throughput

The preferred network performance (either latency or throughput according to your business requirement) would affect the severity of an advisor service recommendation to a system.

Note

The predefined tag keys names are reserved. If you already use the key security, with a value that differs from one of the predefined values, you will not see a change in your recommendations. You will only see a change in recommendations if your existing key=value is the same as one of the predefined keys. For example, if you have a key=value of security: high, your recommendations will not change because of the Red Hat-predefined tags. If you currently have a key=value pair of security: strict, you will see a change in the recommendations for your systems.

Additional resources

4.5.5. Configuring predefined tags
Copiar o link

You can use the Red Hat Lightspeed advisor service’s predefined tags to adjust the behavior of recommendations for your systems to gain extended security hardening and enhanced detection and remediation capabilities. You can configure the predefined tags by following this procedure.

Prerequisites

  • You have root-level access to your system
  • You have insights-client installed
  • You have systems registered within the insights-client
  • You have created the tags.yaml file. For information about creating the tags.yaml file, see Creating a tags.yaml file and adding a custom group.

Procedure

  1. Using the command line, and your preferred editor, open /etc/insights-client/tags.yaml. (The following example uses Vim.) 

    [root@server ~]# vi /etc/insights-client/tags.yaml

  2. Edit the /etc/insights-client/tags.yaml file to add the predefined key=value pair for the tags. This example shows how to add security: strict and network_performance: latency tags. 

    # cat /etc/insights-client/tags.yaml
group: redhat
location: Brisbane/Australia
description:
- RHEL8
- SAP
security: strict
network_performance: latency
  3. Save your changes.
  4. Close the editor.

  5. Optional: Run the insights-client command to generate an upload to Red Hat Lightspeed, or wait until the next scheduled Red Hat Lightspeed upload. 

    [root@server ~]# insights-client

Confirming that predefined tags are in your production area

After generating an upload to Red Hat Lightspeed (or waiting for the next scheduled Red Hat Lightspeed upload), you can find out whether the tags are in the production environment by accessing Red Hat Lightspeed > RHEL > Inventory > Systems. Find your system and look for the newly created tags. You see a table that shows:

  • Name
  • Value
  • Tag Source (for example, insights-client).

Example of recommendations after applying a predefined tag

The following image of the advisor service shows a system with the network_performance: latency tag configured.

shows a recommendation that has a higher Total Risk that is Important and another recommendation that has a Total Risk of Moderate

The system shows a recommendation with a higher Total Risk level of Important. The system without the network_performance: latency tag has a Total Risk of Moderate. You can make decisions about prioritizing the system with higher Total Risk.

Chapter 5. References
Copiar o link

See the following references materials to learn more.

5.1. Reference materials
Copiar o link

To learn more about the vulnerability service, see the following resources:

Providing feedback on Red Hat documentation
Copiar o link

Provide feedback on Red Hat documentation to report issues or request enhancements. Submit detailed feedback through the Red Hat Customer Portal to help improve documentation quality.

Prerequisites

  • You are logged in to the Red Hat Customer Portal.

Procedure

  1. Click the following link: Create Issue
  2. Describe the issue or enhancement in the Summary text box.
  3. Provide details about the issue or requested enhancement in the Description text box.
  4. Type your name in the Reporter text box.
  5. Click the Create button.

Results

This action creates a documentation ticket and routes it to the appropriate documentation team. Thank you for taking the time to give feedback.

Legal Notice
Copiar o link

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red HatVoltar ao topo