CIS Benchmarks and DISA STIGs as a hardening baseline: what they are and how to apply them selectively

What it is

The Center for Internet Security publishes CIS Benchmarks, consensus-developed configuration guides covering operating systems, cloud platforms and applications, distributed from cisecurity.org. Benchmarks are commonly split into profile levels: a baseline profile intended to be broadly applicable with limited operational impact, and a stricter profile for environments that accept more functional trade-offs, chosen per organization rather than fixed.

DISA STIGs (Security Technical Implementation Guides) are the U.S. Department of Defense's counterpart, published and indexed through the DoD Cyber Exchange at public.cyber.mil/stigs/. STIG findings are commonly graded by severity category, and remediation guidance ships alongside each check so it can be automated or reviewed manually.

Both are recommendations, not laws: an organization selects a baseline, then decides which individual checks apply to a given host or service.

Why it matters

A benchmark or STIG written for a general-purpose server can disable a setting a specific application depends on — a cipher, a legacy authentication mode, a service account behavior. Applying every recommendation unconditionally, without testing, is a frequent cause of an outage that looks unrelated to "just a hardening pass." Treating the baseline as a checklist to score against, with documented exceptions, keeps the audit trail honest about what was actually done.

How to apply

• Pick one baseline (CIS or STIG, not an ad hoc mix) per host role, and record which profile level was chosen and why.
• Read each check before applying it in a mixed or legacy environment; do not machine-apply every recommendation without review.
• For any check that is not applied, write down the reason and who approved the exception — this list is itself an audit artifact.
• Re-run the same baseline after every major OS or application upgrade; recommendations and defaults both change over time.
• Prefer automated scanning (see OpenSCAP) over manual verification once a baseline is chosen, so re-checks are repeatable.

Pitfalls

• Applying a stricter profile to a host that was never tested against it, then discovering a broken login path or backup job days later.
• Treating "100% pass" as the goal instead of "every deviation is a documented, approved decision."
• Forgetting that benchmarks and STIGs are versioned; scanning against a stale copy hides newly relevant checks.