CIS benchmarks conceptually - mapping controls to the framework

The CIS Benchmarks are the most widely-adopted security configuration standard. They provide specific, tested recommendations for hardening Linux. This lesson covers what CIS is, how to apply it, and how to handle conflicts.

What CIS Benchmarks are

The Center for Internet Security (CIS) publishes Benchmarks for many platforms: Linux, Windows, macOS, cloud services, network devices. Each Benchmark is:

• A consensus document reviewed by security experts.
• Specific, actionable recommendations.
• Two profiles: Level 1 (basic, low-impact) and Level 2 (defensive, higher-impact).

For Linux, there are CIS Benchmarks for:

• RHEL 9, Rocky 9, Alma 9
• Ubuntu 22.04, 20.04
• Debian 12

The Benchmark covers:

• Filesystem and partition configuration
• Software updates
• Filesystem permissions
• Boot settings
• Process and service configuration
• Network configuration
• Logging and auditing
• Access control
• User accounts

How to apply

Three approaches:

1. Manual: read the Benchmark and apply each recommendation. Time-consuming but educational.

2. Configuration management: encode the Benchmark in Ansible, Puppet, or Chef. Reproducible across the fleet.

3. Compliance scanning: use OpenSCAP to scan the host against the Benchmark and report non-compliance.

# Install OpenSCAP
sudo apt install openscap-scanner openscap-security-guide

# Find the benchmark
ls /usr/share/xml/scap/content/

# Scan
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results scan-results.xml \
  --report scan-report.html \
  /usr/share/xml/scap/content/ssg-ubuntu2204-ds.xml

The HTML report lists every check, with PASS or FAIL, and a description of the fix.

Profile levels

• Level 1: basic hardening. Low-impact, generally safe to apply to all hosts.
• Level 2: defensive hardening for sensitive hosts. Higher impact; may break applications.

For most production, apply Level 1 to all hosts and Level 2 to security-sensitive hosts (DMZ, prod database, etc.).

Common controls (Level 1 examples)

When CIS conflicts with applications

A CIS recommendation may break an application:

• “Set password max days to 365”: an application that uses a long-lived credential.
• “Disable root login via SSH”: a legacy automation that requires root SSH.
• “Set umask 027”: an application that expects 022.

Document exceptions:

EXCEPTION: CIS 5.2.18 - SSH MaxAuthTries 3
Application: legacy-batch-automation requires MaxAuthTries 6
Approved by: Security Team
Date: 2026-08-09
Review: quarterly

The exception is documented, reviewed, and auditable. CIS deviations without exception tracking are compliance gaps.

Compliance scanning in CI

Run OpenSCAP in CI:

- name: Run OpenSCAP
  run: |
    sudo oscap xccdf eval \
      --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
      --results scan-results.xml \
      --report scan-report.html \
      /usr/share/xml/scap/content/ssg-ubuntu2204-ds.xml

A failing scan fails the CI pipeline. This catches compliance regressions before deploy.

OpenSCAP remediation

OpenSCAP can apply fixes via SCAP profiles:

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --remediate \
  /usr/share/xml/scap/content/ssg-ubuntu2204-ds.xml

Apply only after testing. --remediate can change many settings at once; some may break applications.

Knowledge check