A CIS Benchmark Linux compliance checklist is a structured inventory of security controls mapped to your infrastructure. It's not a one-time audit—it's a living runbook that tells you what to verify, how to verify it, and what breaks when you skip a step.
The CIS Benchmark itself is a consensus-driven standard published by the Center for Internet Security. For Linux, it covers 250+ controls across nine sections: initial setup, filesystem configuration, network parameters, logging, access control, system maintenance, software updates, file permissions, and user accounts. Compliance means you've implemented and verified each relevant control for your environment.
The Three-Tier Model
CIS organizes controls by profile:
- Level 1 (Server): Essential hardening. Minimal performance impact. Protects against most common attacks. Start here.
- Level 1 (Workstation): Same intent, different tuning (e.g., USB restrictions). Use for desktop systems.
- Level 2: Defense-in-depth. Higher operational overhead. Requires monitoring and tuning. Add after Level 1 is solid.
Each control has a unique ID (e.g., 1.1.1.1), a description, remediation steps, and audit commands. Your checklist maps controls to your systems and tracks implementation status.
Building Your Checklist
Step 1: Scope your systems. Decide which controls apply. A public-facing web server doesn't need workstation controls. A database server may skip some network hardening if it's behind a firewall. Document exceptions—this is your compliance boundary.
Step 2: Map controls to your infrastructure. Create a table: control ID, description, applicable systems, implementation status, verification method, owner, due date. Start with Level 1. Use a spreadsheet or YAML inventory.
Step 3: Automate verification where possible. Write scripts that run the audit commands from the benchmark. Example:
#!/bin/bash
# Verify 1.1.1.1: Ensure mounting of cramfs filesystems is disabled
modprobe -n -v cramfs 2>&1 | grep -E "install /bin/true"
if [ $? -eq 0 ]; then
echo "PASS: cramfs disabled"
else
echo "FAIL: cramfs not disabled"
fi
Run this monthly or on every deployment. Parse output and feed to your compliance dashboard.
Step 4: Document manual controls. Some controls require human judgment: reviewing sudo logs, auditing user accounts, checking change management processes. For these, create a checklist with sign-off fields and a review schedule.
Step 5: Plan remediation. For each failed control, assign ownership and a deadline. Prioritize by risk: failed authentication controls before failed logging controls. Test changes in non-production first.
Common Control Categories
Filesystem & Partitioning
Controls 1.1–1.3 ensure separate partitions for /tmp, /var, /var/tmp, /var/log, and /var/log/audit. This limits damage from a disk-filling attack or privilege escalation.
Verification: mount | grep -E '\s(/tmp|/var|/var/tmp|/var/log)' and check mount options (nodev, nosuid, noexec).
Gotcha: Implementing this on a live system requires downtime or LVM reconfiguration. Plan during a maintenance window.
Bootloader & Kernel Parameters
Controls 1.4–1.5 harden GRUB, restrict kernel module loading, and tune network stack parameters (IP forwarding, ICMP redirects, SYN cookies).
Verification: Check /etc/default/grub, /etc/modprobe.d/, and sysctl -a.
Gotcha: Disabling IP forwarding breaks NAT and container networking. Verify your architecture before applying.
Authentication & Access
Controls 5.1–5.7 cover password policy, sudo logging, SSH hardening, and PAM configuration.
Verification: Check /etc/login.defs, /etc/pam.d/, /etc/ssh/sshd_config, and visudo -c.
Gotcha: SSH key-only auth is more secure than passwords, but locks you out if you lose the key. Keep a recovery mechanism.
Logging & Auditing
Controls 4.1–4.4 ensure auditd is running, rsyslog is configured, and logs are protected from tampering.
Verification: systemctl status auditd, check /etc/audit/audit.rules, verify log file permissions (640 or more restrictive).
Gotcha: Audit logs grow fast on busy systems. Set rotation and retention before you run out of disk.
Automation Patterns
Ansible playbook: Use community.general.sysctl, ansible.posix.firewalld, and custom modules to enforce controls. Idempotent—run it repeatedly without side effects.
Bash script + cron: Simple shell scripts that audit and report. Less overhead, less abstraction. Suitable for 5–10 systems.
Compliance tools: Lynis, OpenSCAP, or Chef InSpec can scan and report CIS compliance automatically. These integrate with CI/CD and compliance platforms. If you're also evaluating terminal environments for running these tools interactively, the comparison on techjournaler.com covers the best terminal multiplexer alternatives worth considering.
When This Breaks
Overly strict controls disable legitimate workflows. Example: disabling all kernel modules breaks drivers. Solution: whitelist required modules, document the exception.
Compliance drift. You pass the audit, then a new engineer disables SELinux to debug an issue and forgets to re-enable it. Solution: automated re-verification on every boot or daily, with alerts on failure.
Conflicting controls. Hardening sudo logging might conflict with performance requirements. Solution: measure the impact, document the trade-off, get stakeholder sign-off.
Outdated benchmark versions. CIS releases updates annually. Your checklist may reference controls that no longer exist. Solution: version your checklist, track changes, plan annual reviews.
False negatives in automation. A script passes because it checks for the wrong string or a system behavior changed. Solution: pair automated checks with spot manual audits quarterly.
Compliance Workflow
- Baseline: Run full audit on all systems. Document current state.
- Prioritize: Rank controls by risk and effort. Level 1 first.
- Remediate: Implement controls, test, deploy.
- Verify: Run audit scripts. Manual review for exceptions.
- Report: Track completion, publish to stakeholders monthly.
- Maintain: Re-verify quarterly. Update for new systems, new CIS versions, new threats.
This is a 6–12 month effort for a medium infrastructure. Ongoing maintenance is 2–4 hours per month.
Trade-Offs
Full CIS compliance adds operational complexity: more monitoring, stricter access controls, higher disk usage for logs. The benefit is reduced attack surface and faster incident response. For regulated workloads (healthcare, finance), compliance is non-negotiable. For internal tools, you may skip Level 2 controls.
Don't aim for 100% compliance on day one. Implement Level 1, stabilize, then add Level 2. Document every exception and review it quarterly.
One-Line Takeaway
A CIS Benchmark Linux compliance checklist is a versioned inventory of hardening controls, automated where possible, manually reviewed where it matters, and re-verified on a fixed schedule.