Applying CIS Benchmarks on Linux Without Breaking Production

Match the version — a benchmark for Ubuntu 22.04 numbers and words things differently from the 24.04 one. Pin the benchmark version in your exception register so findings stay comparable.

Level 1 is the realistic target — for most fleets, Level 1 Server plus a short list of Level 2 controls you actually want is defensible. Full Level 2 is designed to cost functionality.

Aligned is not certified — community profiles track CIS closely, but when an auditor specifically requires CIS-CAT results, use CIS-CAT for the evidence and the free tools for day-to-day work.

The plain cis profile is Level 2 — in the SCAP Security Guide, content_profile_cis is Level 2 Server. Most people want cis_server_l1 first.

Exit codes — oscap xccdf eval returns 0 when every rule passes, 2 when at least one fails, and 1 on an error. CI jobs that treat any non-zero code as a crash need to know the difference.

Scan a representative set — a web node, a database, a container host and a bastion fail differently. Five scans by role tell you more than fifty identical ones.

Read the HTML report — each failed rule links its rationale and the exact remediation. That is the material for your exception decisions.

Firewall and Docker — Docker manages its own iptables or nftables rules, and published container ports can bypass a host firewall you thought was default-deny. Read our Docker guide for Linux admins before enforcing firewall controls on container hosts, and generate rule sets with the firewall rules tool.

SSH changes — the SSH section overlaps heavily with our SSH security best practices. Run sshd -t after every change and keep a second session open until a fresh login succeeds.

Cloud images — provider agents sometimes depend on things the benchmark disables. Azure's provisioning, for example, uses UDF-formatted media, so disabling the udf module needs testing on Azure VMs.

GUI option — SCAP Workbench (scap-workbench) opens the data stream, lets you tick rules off, and saves a tailoring file. Useful the first time, when you are still reading what each rule does.

Tailor by role, not by host — one tailoring file per server role keeps exceptions reviewable. Per-host exceptions turn into an unmaintainable spreadsheet within a year.

Values are tailorable too — many rules have variables such as password length or the audit log size. Changing a value is often better than deselecting the rule entirely.

Use the task tags — the generated tasks are tagged with the rule name and with complexity, disruption and reboot hints such as low_disruption and reboot_required. Applying the low-disruption set first gets most of the score with little risk.

--check is not proof — check mode shows intended changes, but some tasks cannot predict their effect without running. The lab ring exists because of that gap.

Define healthy before you start — SSH from the bastion, application health checks, backups, monitoring agents and scheduled jobs. Check all of them after each ring, and after the next reboot, since several controls only take effect at boot.

On Ubuntu — sudo usg fix --tailoring-file tailor.xml applies the tailored profile. Run it on a snapshot first, exactly like the Ansible path.

Keep a way back — a VM snapshot, an image you can redeploy, or at minimum an out-of-band console. A firewall or SSH control gone wrong locks out the tool that would roll it back.

Partition at build time — the separate /tmp, /var, /var/log and /var/log/audit controls are trivial in a kickstart or Packer template and painful anywhere else.

Scan results are evidence — keep the XML results with a date. Auditors usually want proof of continuous compliance, not one green report.

Review exceptions on schedule — the review date in the register matters. A reason that was true for an old kernel or Docker version may no longer hold.

Schedule it properly — build the weekly scan with our systemd timer generator or the cron generator, and pull the remaining items from the server hardening checklist.