How does OpenSCAP assessment and remediation work and why can't it be automatically reverted once applied?

Updated -

Environment

  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9

Context

Customers who are required to comply with security benchmarks can enhance their system configuration using the OpenSCAP scanner and the pre-defined hardening profiles included in the scap-security-guide package. These tools enable users to achieve a state that aligns closely with their chosen benchmark, such as CIS or STIG.

Each benchmark encompasses specific requirements for different system components, each with its unique structure. Consequently, both assessment and remediation processes vary depending on the case. For example, evaluating package installation differs significantly from assessing file content, and their respective remediation methods also differ.

To accurately evaluate a system against a particular requirement, the OpenSCAP tool relies on precise instructions provided by the scap-security-guide package. These instructions adhere to the SCAP standard, ensuring a secure system scanning process.

Likewise, when applying remediation to a system, the OpenSCAP scanner requires instructions in the form of Bash Scripts while the scap-security-guide package also provides equivalent remediation as Ansible Playbooks.

The following questions and answers aim to provide a better understanding of how OpenSCAP works.

How does the OpenSCAP assessment work?

The assessments conducted using the OpenSCAP scanner prioritize maintaining system stability by intentionally adopting a conservative approach. This approach ensures that the assessment process itself does not introduce any changes to the system. The scanner (oscap) achieves this by employing the OVAL language, a declarative language that encapsulates the necessary logic for requirement checks. The scanner interprets this logic and collects only the essential information needed for testing.

While some assessments can be fully automated, others, particularly those involving more complex scenarios, may pose challenges or even be impossible to automate. Certain benchmarks explicitly require manual assessments to be performed, acknowledging these limitations.

Given this context, it is important to recognize that automated assessments may not achieve 100% coverage of all benchmark requirements. Technical limitations of the involved components or resource constraints in developing new assessment rules can contribute to this. For instance, verifying the presence of a specific line in /etc/bashrc could be challenging if the line exists within a conditional statement or after an exit command, rendering it ineffective in meeting the benchmark requirement. In such cases, manual verification becomes a safer approach.

One positive aspect is that multiple benchmarks often share many requirements, sometimes being identical or exhibiting minor variations. To ensure accurate, flexible, updated and consistent coverage across benchmarks, each requirement is usually represented by a unique rule, composed by its own OVAL and remediation. Finally, a benchmark is represented by a respective profile, which ultimately is formed by many rules which together cover the benchmark requirements.

How does the OpenSCAP remediation work?

For different reasons, it may not be possible to deliver system components with their default settings already compliant with all benchmarks. Consequently, benchmark assessments may identify gaps in compliance. To address these gaps, it is sometimes necessary to install or remove packages, modify default settings, or perform manual actions adjusted to the specific environment.

To address these compliance gaps automatically, when technically feasible, SCAP Security Guide (SSG) provides remediation options. These remediation options come in two flavors:

Bash Scripts
These scripts are designed to fix compliance gaps in the most compatible and straightforward manner.
Ansible Playbooks
Leveraging the power of Ansible, these playbooks provide a robust mechanism to remediate compliance gaps.

Note that when executing remediation actions through the OpenSCAP scanner tool, the underlying mechanism primarily utilizes the bash script.

It is important to be aware that automated remediation can lead to unexpected results when applied to already modified systems. Therefore, it is strongly recommended that administrators carefully assess the potential impact of remediation actions on their specific systems.

Furthermore, it is crucial to note that benchmark requirements, system components, and their corresponding remediation techniques may evolve over time. This means that assessment and remediation approaches may be adjusted to align with relevant changes and updates.

Common Questions about Post Remediation

Why can’t an OpenSCAP remediation be automatically reverted?

The inability to automatically revert an OpenSCAP remediation is due to the nature of the remediation process itself. As mentioned earlier, OpenSCAP utilizes Bash Scripts or Ansible Playbooks to implement the remediation actions on the target system. The resources and changes introduced by these remediation actions are dependent on the technologies used.

Currently, there is no safe and reliable method to revert the changes made by Bash Scripts or Ansible Playbooks in a target system. This limitation applies especially in the context of hardening systems and at the component level. The primary reason for this limitation is the lack of active tracking for configuration changes made to components. These changes can originate from various sources, including OpenSCAP, the components themselves, or system administrators. It is not uncommon for system administrators to make changes before or after OpenSCAP has performed its remediation actions. Consequently, attempting to reverse configuration changes in such scenarios can lead to unpredictable outcomes, as subsequent changes may depend on settings introduced through other means. Additionally, accurately identifying changes specifically made by OpenSCAP during the remediation process can be challenging and unreliable.

In practice, only a few specific components may offer capabilities for reversibility, and even then, these capabilities are often implemented on a case-by-case basis. For example, the authselect tool in RHEL8 and RHEL9 is used to modify PAM settings and includes a backup feature before making any changes. OpenSCAP remediation uses this feature for PAM related rules. However, this is not a universal standard applicable to all components in a system.

Therefore, it is strongly recommended to thoroughly analyze the assessment reports and review the findings and corresponding remediations before applying remediations to a production system. While it is advantageous to perform remediation as early as possible, particularly during the provisioning phase of a new system, in critical and established production environments, it is recommended to carry out remediations on an individual basis. This approach reduces the scope of changes and makes it easier to manually revert them if necessary.

What would be possible alternatives to reverting undesired changes?

As mentioned earlier, it is currently not feasible to establish a universal mechanism to selectively revert changes made by Bash Scripts or Ansible Playbooks that would be applicable to all components in a system.

However, there are some potential techniques, albeit with limitations, that could be explored to achieve the desired outcome. It is important to note that these are simply conceptual ideas on how it might be technically possible to revert changes made by Bash Scripts or Ansible Playbooks. Their effectiveness can vary depending on the specific context, and therefore, they have not been extensively tested, generally recommended, or officially supported by Red Hat. Our intention is to provide insights that can be analyzed and researched by system administrators who are interested in exploring alternative approaches.

VM Level Snapshot

A convenient option to revert system changes is to utilize the snapshot feature available in many hypervisors. When a snapshot exists prior to applying changes, it provides a straightforward method to restore the entire system state to that snapshot. This can effectively undo modifications made by Bash Scripts, Ansible Playbooks, or any other alterations made to the system.

For comprehensive information regarding the usage, support, and limitations of the snapshot feature, it is recommended to refer to the official documentation of the specific hypervisor being used. The documentation will provide detailed guidance on creating and managing snapshots, as well as any specific considerations or restrictions that should be taken into account.

LVM Level Snapshot

If the system employs LVM (Logical Volume Manager), the LVM snapshot feature can be particularly helpful when changes are made to files within a LVM mount point. In such cases, an LVM snapshot can be created as a testing mechanism, allowing configuration changes to be evaluated and easily reverted if necessary.

It is important to note that the use of LVM snapshots is specific to systems utilizing LVM and is primarily applicable to file-level changes within LVM mount points. The effectiveness and feasibility of using LVM snapshots for reverting changes should be thoroughly evaluated and tested in the specific system context.

References:

Snapshot of logical volumes in RHEL 9 Configuring and managing logical volumes

Snapshot of logical volumes in RHEL 8 Configuring and managing logical volumes

Snapshot Volumes in RHEL 7 Logical Volume Manager Administration

File System Control Version

In certain cases, the implementation of a version control system for the file system can provide a trackable and reversible approach to managing changes. One such open-source project that offers this functionality is etckeeper (etckeeper.branchable.com).

By utilizing a file system version control system like etckeeper, changes made to the file system can be effectively tracked and documented. This enables the ability to revert modifications if necessary, offering an additional layer of control and oversight.

It is important to note that the applicability of a file system version control approach, such as etckeeper, may vary depending on the specific requirements and environment. It is recommended to thoroughly evaluate the project, its capabilities, and limitations to determine its suitability for individual use cases.

Please keep in mind that etckeeper is an open-source solution provided by a third party and should be reviewed and assessed according to your specific needs and requirements.

Additional References

Comments