📘 CIS Benchmarks for Linux

hardening & compliance / survival guide

CIS Benchmarks for Linux: what they are, which profile to pick, and how to apply them
Publisher: Center for Internet Security (CIS)      Not a law or a certification: a widely used, consensus-built configuration baseline

CIS Benchmarks are prescriptive configuration guides: for each recommendation they say what to set, why, how to check it (audit) and how to fix it (remediation). CIS describes them as consensus-based work by a community of experts, covering more than 25 vendor product families. For Linux they exist for Ubuntu, Red Hat Enterprise Linux, Debian, Oracle Linux, AlmaLinux, Rocky Linux, Amazon Linux, SUSE and others. They are the most common "baseline" people mean when they say "harden it to CIS".
Nothing here is required by law. CIS is often what PCI DSS assessors, auditors, cyber insurers and customers accept as your written configuration standard.
Facts and versions below were checked on 2026-09-29. Benchmarks are revised often: always download the current version for your exact release from https://www.cisecurity.org/cis-benchmarks

What CIS publishes (do not mix these up)

CIS Benchmarks               The guides (PDF, with machine-readable versions for members). One per product and version, for example "CIS Ubuntu Linux 24.04 LTS Benchmark".
CIS-CAT Lite / Pro           CIS's assessor tool. CIS-CAT Lite is the free one (limited benchmarks). CIS-CAT Pro and the machine-readable content are for CIS SecureSuite members. Check CIS's current licence terms before using content commercially.
CIS Build Kits               Scripts and policies that configure a system to a benchmark.
CIS Hardened Images          Ready-made cloud images already hardened to a benchmark (sold through cloud marketplaces).
CIS STIG benchmarks          CIS-published benchmarks that map DISA STIG content (see the DISA STIG sheet).
The free alternatives that implement the same ideas: OpenSCAP with scap-security-guide on the Red Hat family, and the Ubuntu Security Guide (usg, needs Ubuntu Pro) on Ubuntu. See the OpenSCAP, USG and Lynis sheet.

Recent versions seen (as of 2026-09-29)

CIS Ubuntu Linux 24.04 LTS Benchmark v2.0.0 was published in June 2026 (v1.0.0 was the first release).
CIS Debian Linux 12 Benchmark v2.0.0 was published in June 2026 as the final update.
CIS Red Hat Enterprise Linux 10 STIG Benchmark v1.0.0 and CIS Oracle Linux 9 STIG Benchmark v1.0.0 were announced in June 2026.
CIS lists many other releases (RHEL 8/9/10, Rocky, Alma, SUSE, Amazon Linux). Look up your release on the CIS site for its current version number.
Important: the tool you use may implement an OLDER benchmark version than the newest one. When checked, Ubuntu's USG documentation listed profile version 1.0.0 for Ubuntu 24.04 while CIS had already published v2.0.0. Run man usg-cis (or oscap info on your data stream) to see which version YOUR tool implements, and say so in your audit notes.

Profiles: Level 1 vs Level 2, Server vs Workstation

Level 1   The practical baseline: sensible, limited impact on how the system works. Start here.
Level 2   Defence in depth for higher-risk environments. Stricter, and some items can reduce functionality. Read each item before turning it on.
Server / Workstation   Separate profiles: a server does not need a desktop, printing or Bluetooth, and a workstation does. Pick the one that matches the machine's job.
Ubuntu 24.04 profile names in usg:  cis_level1_server, cis_level2_server, cis_level1_workstation, cis_level2_workstation
Red Hat family profile IDs in scap-security-guide include cis (list them with oscap info on your data stream: names vary by release).

What a Linux benchmark covers (typical chapters)

1  Initial setup           Unused filesystems and kernel modules, package and repository setup, mandatory access control (AppArmor or SELinux), bootloader, process hardening (ASLR, core dumps), login banners.
2  Services                Do not install or enable what you do not need (servers, clients, mail transfer agents, time synchronisation done right).
3  Network                 Disable unused protocols, sysctl network hardening.
4  Host firewall           Have one, default deny, loopback rules.
5  Access, authentication  SSH server settings, sudo, PAM (password quality, lockout), user and group settings, session timeouts.
6  Logging and auditing    journald/rsyslog, auditd rules, log file permissions, integrity checking such as AIDE.
7  System maintenance      File permissions on system files, local user and group settings, no empty passwords or UID 0 extras.
Exact numbering and content change between benchmarks and versions, so always cite the benchmark name and version when you write down "CIS 5.1.4".

The workflow (apply it, do not just download it)

   1. Pick the benchmark for your exact distribution and release, then the profile (usually Level 1 Server to start).
   2. Audit first. Run a scan and save the report (see the scanning-tools sheet). That is your "before".
   3. Go through every failure: fix it, tailor it out with a written reason, or accept the risk with a named approver.
   4. Fix on a test copy with a snapshot. Test logins, backups, monitoring and the application.
   5. Roll out gradually, then re-audit and save the "after" report.
   6. Put the baseline into your build (image, Ansible, cloud-init) and re-scan on a schedule.
Ubuntu (USG, needs Ubuntu Pro):
   sudo pro enable usg ; sudo apt install usg
   sudo usg audit cis_level1_server
   sudo usg generate-tailoring cis_level1_server tailoringfile.xml
   sudo usg audit --tailoring-file tailoringfile.xml
   sudo usg fix cis_level1_server                   # changes the system: test machine and snapshot first (see man usg for using a tailoring file when fixing)
   # audit reports land in /var/lib/usg/
Red Hat family (OpenSCAP):
   sudo dnf install openscap-scanner scap-security-guide
   sudo oscap xccdf eval --profile cis --results cis-results.xml --report cis-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
   # Red Hat provides no automated undo for remediation: generate the fix script, read it, test it, snapshot first
Manual is fine too: the benchmark PDF has an exact audit command and fix command for every item. It just takes longer.

Handling the ones that do not fit

Every real environment has exceptions. Common ones: disabling IPv6 on a network that uses it, noexec on /tmp when an installer needs it, blocking USB storage on a machine that reads backups from USB, or restricting SSH ciphers in a way old clients cannot handle.
Write each exception down: the recommendation number and benchmark version, what you did instead, why, who approved it and when it is reviewed. A documented exception passes an audit far better than a silent one.

Common problems

"My scan says 62% and my colleague's says 91% on the same server": different benchmark versions, different profile (Level 1 vs Level 2, Server vs Workstation), or different tools counting "not applicable" differently. Compare like with like.
"The tool implements an older benchmark than the one on the CIS site": normal. Say which version you scanned against, or use CIS-CAT for the newest one.
"Remediation broke something": that is why you snapshot and test. Restore, then remove the offending rule from a tailoring file and re-run.
"A rule wants me to disable something my application needs": tailor it out and document it. Do not switch the app off to get a green tick.
"I hardened it once and it drifted": builds and config management (Ansible, image pipelines) keep it hardened. Manual fixes rot.
"Cloud image already 'CIS hardened'": still scan it. Hardened images are a starting point, and your own packages and settings change the result.

Tips

Start with Level 1 Server. Move to Level 2 only where the data or the threat justifies it and you can test.
CIS is a good baseline for PCI DSS 2.2.x configuration standards, ISO 27001 configuration management and SOC 2 change and hardening evidence. It is not a substitute for those frameworks (see their sheets).
Track benchmark releases: a new benchmark version means new rules to re-check.
Save every report with its date. "We scanned quarterly and here are the four reports" is a very good sentence in an audit.
CIS scores measure how many rules pass, not how secure you are. Patching, backups and good logs still matter.

Sources (checked 2026-09-29)

CIS Benchmarks:                          https://www.cisecurity.org/cis-benchmarks
CIS Benchmarks June 2026 update:         https://www.cisecurity.org/insights/blog/cis-benchmarks-june-2026-update
CIS Ubuntu Linux benchmarks:             https://www.cisecurity.org/benchmark/ubuntu_linux
Ubuntu, CIS compliance with USG:         https://ubuntu.com/security/certifications/docs/usg/cis
Ubuntu, USG for 24.04 (commands):        https://ubuntu.com/blog/hardening-automation-for-cis-benchmarks-now-available-for-ubuntu-24-04-lts
Red Hat, compliance scanning (RHEL 9):   https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening