CIS benchmarks and baselines

What a CIS Benchmark actually is

You do not want to invent “what does a hardened Ubuntu host look like?” from scratch — that is months of research per platform, and you will miss things. A CIS Benchmark is the answer someone already built: a consensus-developed, prescriptive configuration guide for a specific platform — a Linux distro, Windows Server, Kubernetes, PostgreSQL, nginx, an AWS account, a Docker daemon. There are over 100 of them, each maintained by a community of practitioners and revised against new platform versions and new attack techniques. Where a generic guide like NIST SP 800-123 tells you the principles of server hardening (minimize the attack surface, run least privilege, patch, log), a CIS Benchmark gives you the exact settings that implement those principles on the box in front of you, down to the file, line, and expected value.

Two structural features matter for how you use it. First, recommendations are split into Level 1 (practical hardening that should not break normal function — the sane default for most fleets) and Level 2 (defense-in-depth for high-security environments, accepting that some functionality or convenience is sacrificed). Second, each recommendation is tagged Automated or Manual: Automated items have a machine-checkable audit and remediation procedure, Manual items require human judgment. That split is the single most important thing a senior reads off the benchmark, because it tells you exactly which controls you can enforce continuously and which need a process instead.

From benchmark to your baseline

A benchmark is not a baseline. The benchmark is the menu; your configuration baseline is the meal you actually commit to — the specific set of recommendations, at the level you chose, minus the exceptions your environment legitimately needs, each exception written down with a reason and an owner. This distinction is where most hardening programs quietly fail. A team that treats “100% CIS compliant” as the goal hits a recommendation that breaks their app — say, disabling a kernel module their monitoring agent needs — and instead of recording a justified exception, they either ship a broken host or silently turn the whole check off. Now the baseline lies.

The senior move is to derive the baseline once, deliberately. Start from the appropriate level (Level 1 for the fleet), walk the recommendations, and for each one make an explicit decision: apply, or except-with-reason. The output is a baseline document — ideally machine-readable — where a deviation is never a surprise. The reason this matters for drift detection is causal: if you cannot say what “correct” is, you cannot detect “incorrect.” A clean, exception-annotated baseline is the reference that every running host is measured against. No reference, no drift detection — just hope.

Drift: how a hardened host un-hardens itself

You harden the golden image, you ship it, you move on. Then entropy arrives. Configuration drift is the gap that opens over time between the baseline a host was provisioned with and its actual running state. It is not usually malice — it is operations: an engineer disables a control to debug an incident at 2 a.m. and forgets to re-enable it; a package update resets a config file to its vendor default; a manual hotfix patches one box but not the other forty; two teams own overlapping config and each “corrects” the other. Each change is individually reasonable. The aggregate is a fleet where no two hosts are quite the same and the security posture you designed exists only in the image, not in production.

Drift is dangerous precisely because it is invisible by default. The host still runs. The app still serves traffic. Nothing alerts. The drifted setting only announces itself when an attacker — or an auditor — finds it. So the defender’s job is to make drift visible: continuously re-audit every running host against the baseline and surface every deviation, so a control that flipped from no to yes raises a finding the next day instead of in the post-mortem.

Compliance as code: closing the loop

Detecting drift by hand does not scale past a handful of hosts. The durable pattern is compliance as code: express the baseline as machine-readable, version-controlled rules, and run them automatically against every host on a schedule and in the deploy pipeline. CIS ships its baselines in a structured format and provides tooling (CIS-CAT), and the open ecosystem encodes benchmarks as OpenSCAP/SCAP content or as policy in tools like Chef InSpec, Ansible, or OPA. The shape is the same regardless of tool: a control is a rule with an audit (how to read the current value) and often a remediation (how to set the correct value), checked into a repo and run by CI.

Encoding the baseline as code buys you four things at once. The baseline is now reviewable (a change to a control goes through a pull request, not a 2 a.m. SSH session), versioned (you can prove what “correct” was on any date — which auditors love and incidents require), enforced uniformly (the same rules run on host 1 and host 41, so drift between hosts is caught), and fast to detect (a scheduled scan turns a six-month-old silent regression into a next-morning finding). The remaining senior decision is what to do on a deviation: alert-only for controls where auto-fixing could break a workload (let a human reconcile), versus auto-remediate for controls where the correct value is unambiguous and safe to enforce — converging the host back to the reference without waiting for a ticket.