Differences between CIS benchmarks and SCAP Security Guide rules

Rules within the SCAP Security Guide (SSG) are shared across multiple security profiles that implement different policies. This necessitates writing broadly applicable rules. Each policy has a distinct approach and varies in the level of strictness required for configuration checks. While policies typically share similar requirements, you can often use more than one valid way to check or remediate them.

A good example is the difference between the Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) and the Center for Internet Security (CIS) requirements. The DISA STIG mandates strict, explicit configuration settings. In contrast, CIS benchmarks might pass if system defaults remain unchanged.

Because SSG uses the same rules and checks for both STIG and CIS profiles, the checks are generally written to a stricter standard to align with STIG requirements. Although these strict rules ensure compliance with CIS requirements, they can be met with less stringent checks.

The SCAP Security Guide's methodology is to require a specific configuration value to be present, rather than relying on system defaults. This approach has two main reasons:

• Resilience to change: Default configuration values can change in new versions of products or components. Requiring explicit configuration makes the content more resistant to these unpredictable changes.
• Auditable proof: The explicit presence of a configuration setting in a file provides clear, auditable proof of compliance with a policy requirement.

SSG rules also verify the static, persistent system configuration rather than checking the current runtime state. The runtime state is volatile and can easily change after a reboot. For instance:

• Mount options: Remounting partitions with the correct options causes rules to pass during a scan, but after a reboot, the partitions revert to the options defined in the /etc/fstab file.
• Sysctl settings: You can change these settings at runtime, but the persistent configuration is loaded from configuration files.

Furthermore, checking runtime status is technically impossible in some use cases, such as when building a hardened bootable container image for RHEL Image Mode systems. In this scenario, the runtime state during hardening is the container's, which is fundamentally different from the state of the running, deployed system.

Consequently, SCAP security guide rules are often stricter than CIS. Examples of where the SCAP Security Guide is Stricter than CIS:

• Kernel modules: SSG rules require kernel modules to be explicitly disabled through an entry in a configuration file (for example, in the /etc/modprobe.d file). CIS benchmarks pass if the module does not exist or is unavailable on the system, without requiring a special configuration file entry. Consequently, the rule evaluates as fail even if the CIS requirement is met, because the module is not present.
• Systemd services: SSG requires masking the systemd service. CIS passes if the service is disabled. Masking the service prevents it from being loaded, even accidentally, as a dependency of another systemd unit.
• Mount options: SSG requires settings defined in /etc/fstab, verifying persistent configuration. CIS checks the runtime mount status by using the findmnt command. While the CIS requirement might be met at the moment of scanning, compliance vanishes after the next reboot if the setting is not persistent. Additionally, CIS passes if a given path is not a separate partition, whereas SSG rules are evaluated as "notapplicable" if the separate partition is absent.
• Cryptographic policies: SSG requires a specific configuration through a custom cryptographic policy module. CIS checks pass if the current cryptographic policy in the /etc/crypto-policies/state/CURRENT.pol file contains the correct algorithms or excludes problematic ones. The CIS auditing approach is generally more accurate because CURRENT.pol is a generated file for inspection and contains complete information on policy modifications. The CIS approach is aligned with the crypto-policies documentation. On the other hand, the SSG checks are designed to align with corresponding remediations and the ability to verify their success. A system might be correctly configured but still fails the SSG check if the custom cryptographic policy modules are named differently than SSG expects.
• DConf configuration: If the system does not contain the GNOME desktop environment, CIS checks return "pass", while SCAP Security Guide checks return "notapplicable".