Configuration Baselines: CIS, STIG, Custom

The forensics report for the 2017 Equifax breach traced the initial compromise to an unpatched Apache Struts server — but the deeper failure was that the server's configuration had never matched any hardening baseline in the first place. Default settings, unnecessary services enabled, verbose error pages leaking stack traces: the missing patch was the proximate cause, the missing baseline was the systemic one. Seven years later, CVE-2024-21762 in FortiOS proved the same pattern holds for network devices — organizations with configuration baselines detected the pre-auth RCE exposure in hours because they knew exactly which firmware versions and SSL-VPN settings their fleet was supposed to be running.

Why This Matters Right Now

Three timelines are converging on configuration management in 2026:

CMMC Phase 2 assessments begin November 2026. The CM (Configuration Management) domain in CMMC Level 2 requires documented baselines, tailoring rationale, and evidence of drift detection. C3PAOs are already signaling that "we use CIS" without a maintained tailoring document and scan evidence will not satisfy CM.L2-3.4.1 and CM.L2-3.4.2.

CIS Benchmark version churn. CIS continuously revises individual benchmarks -- each technology's benchmark moves on its own version cycle. If your baselines reference a superseded benchmark version and you haven't mapped the delta, your compliance scans are measuring against an outdated standard. That gap shows up in auditor reports.

DISA STIG quarterly updates. DISA publishes new STIG revisions every quarter. The Q2 2026 release added over 40 new rules across Windows Server 2025 and RHEL 9 STIGs alone. Each new rule is a potential finding if you haven't updated your scanning profiles.

The common thread: a configuration baseline is only useful if it's maintained as a living document that tracks the standard it references. A baseline frozen in time is a compliance artifact, not a security control.

CIS Benchmarks vs STIGs vs Custom Baselines

CIS Benchmarks

The Center for Internet Security publishes hardening benchmarks for operating systems, cloud platforms, databases, network devices, containers, and middleware. Coverage is broad — nearly every technology stack in enterprise use has a CIS Benchmark.

CIS uses a two-level profile system:

Level 1 targets practical security settings with minimal operational disruption. These are the "you should be doing this regardless" settings. Disabling unused protocols, enforcing password complexity, restricting remote access defaults.
Level 2 adds defense-in-depth settings that may impact functionality. Aggressive audit logging, disabling legacy crypto suites, restricting administrative shares.

Here's the contrarian take: a 100% CIS Level 2 score is a red flag, not a badge of honor. It means either your environment is simple enough that Level 2 settings don't conflict with anything, or nobody tested what broke. In any production environment running real workloads — legacy applications, third-party integrations, performance-sensitive services — some Level 2 settings will conflict with operational requirements. The mature posture is a documented tailoring that achieves 90-95% Level 2 with explicit, risk-accepted exceptions for the remainder.

CIS Benchmarks include CIS Controls mapping, making it straightforward to trace a specific setting back to a higher-level security requirement. CIS-CAT Pro provides automated scanning against CIS Benchmarks and exports results in standardized formats.

STIGs (Security Technical Implementation Guides)

DISA STIGs are mandatory for DoD systems and widely adopted across the federal civilian space. They're more prescriptive than CIS — each check has a specific V-ID (Vulnerability ID), a CAT severity (I/II/III), and step-by-step verification procedures.

Key differences from CIS:

Severity classification. CAT I findings are critical (system compromise). CAT II are medium (degraded security). CAT III are low (best practice). There's no equivalent "level" concept — every rule applies unless you document a formal exception in a Plan of Action and Milestones (POA&M).
SCAP automation. STIGs ship with SCAP (Security Content Automation Protocol) content, enabling automated scanning via tools like SCC (SCAP Compliance Checker) or OpenSCAP. Advisedly does not run oscap, does not claim SCAP 1.3, and does not evaluate OVAL on the agent.
Regulatory weight. For any system processing CUI in a DoD context, STIGs aren't optional. The authorizing official expects STIG scan results as part of the RMF authorization package.

STIGs can be more current than CIS for DoD-specific technology (military middleware, tactical systems) but often lag behind CIS for rapidly-evolving commercial tech.

Custom Baselines

Most organizations end up here eventually. A custom baseline typically:

Starts with CIS or STIG as the foundation
Adds organization-specific requirements (internal standards, contractual obligations)
Removes or modifies settings that conflict with operational requirements, with documented justification per exception
Incorporates application-specific hardening that no generic benchmark addresses

The maintenance burden is the tradeoff. CIS and DISA maintain their benchmarks — your custom baseline is your responsibility to keep current. If the underlying CIS Benchmark bumps a version and adds 15 new rules, your custom baseline has a 15-rule gap until someone reviews and incorporates them.

Selection Criteria

The right baseline depends on your regulatory context, operational complexity, and staffing:

Factor	CIS Benchmark	STIG	Custom
DoD/Federal mandate	Sometimes accepted	Required for DoD systems	Must reference CIS or STIG
Commercial compliance	Widely accepted (SOC 2, ISO 27001, PCI DSS)	Exceeds most requirements	Acceptable with documentation
Prescriptiveness	Moderate (two levels)	High (every rule applies)	Variable (you decide)
Automation support	CIS-CAT, broad tool ecosystem	SCAP, SCC, OpenSCAP (Advisedly does not run oscap / SCAP 1.3)	Depends on your tooling
Maintenance responsibility	CIS maintains	DISA maintains	You maintain
Tailoring overhead	Low (pick Level 1 or 2)	High (must document every exception)	Medium (you control scope)

For CMMC and DoD: STIGs are the expected standard. A C3PAO won't reject a CIS-based approach outright, but you'll spend more time justifying equivalence than you'd spend just using the STIG.

For commercial compliance: CIS Benchmarks Level 1 satisfies virtually every commercial framework requirement for NIST 800-171 SC and CM controls, SOC 2 CC6, and PCI DSS v4 Requirement 2.

For mixed environments: Start with CIS for commercial systems, STIGs for anything touching DoD data, and a custom overlay that normalizes reporting across both. This is more common than people admit.

Implementation Workflow

Phase 1: Inventory and Categorize

You can't baseline what you can't enumerate. Start with a complete asset inventory categorized by system type, data classification, and applicable regulatory requirements. Each category gets its own baseline — a web server baseline differs from a database server baseline differs from a developer workstation baseline.

Map each system category to its baseline source:

Windows Server 2022 (CUI processing) → Windows Server 2022 STIG
Ubuntu 22.04 (web tier) → CIS Ubuntu 22.04 Level 1 + custom overlay
FortiGate firewalls → CIS Fortinet Benchmark + vendor hardening guide
PostgreSQL (application database) → CIS PostgreSQL 16 Benchmark Level 1

Phase 2: Tailor and Document

Review every setting in the selected baseline against your operational environment. For each setting, document one of three dispositions:

Implement as-is. The setting applies without modification.
Implement with modification. The intent applies but the specific value needs adjustment (e.g., session timeout of 30 minutes instead of the prescribed 15 because of clinical workflow requirements).
Do not implement (risk accepted). The setting conflicts with a validated operational requirement. Document the risk, the compensating control, and the approving authority.

This tailoring document is your actual baseline. The CIS Benchmark or STIG is the reference standard; the tailoring document is what you scan against.

Phase 3: Automate Deployment

Apply baselines through infrastructure-as-code and configuration management:

Windows: Group Policy Objects (GPO), DSC (Desired State Configuration), or Ansible with win_security_policy modules
Linux: Ansible roles (e.g., ansible-lockdown), Puppet modules, or Chef cookbooks that implement CIS/STIG settings
Cloud resources: Terraform/CloudFormation with security-group rules, IAM policies, and service configurations baked in
Network devices: Configuration templates pushed through network automation (Ansible network modules, Nornir, or vendor-specific APIs)
Containers: Hardened base images with CIS Docker/Kubernetes Benchmarks applied at build time

The goal is that no system enters production without its baseline applied. New deployments should inherit the baseline automatically through the provisioning pipeline.

Phase 4: Validate

Scan every system against its assigned baseline within 72 hours of deployment and on a recurring schedule:

SCAP scanning for STIG baselines (SCC or OpenSCAP — Advisedly does not run oscap and does not claim SCAP 1.3)
CIS-CAT Pro for CIS Benchmarks
Cloud-native tools (AWS Config Rules, Azure Policy, GCP Security Health Analytics) for cloud resource baselines
Custom scripts for application-specific settings that no standard tool covers

Store scan results in a system of record that tracks compliance percentage over time, flags new findings, and ties each finding to the specific baseline rule it violates.

Phase 5: Remediate and Accept

Not every finding gets remediated. The workflow:

New finding surfaces from scan
Triage: is this a true deviation, a scan error, or an already-accepted exception?
If true deviation: remediate, or document a risk acceptance with compensating controls
Re-scan to confirm remediation
Update the tailoring document if the exception is permanent

This is where configuration management intersects change management. Every baseline deviation should be traceable to either a change ticket (intentional) or an incident (unintentional).

Drift Detection and Response

A baseline deployed once and never monitored is a snapshot, not a control. Configuration drift — the gradual divergence of a system from its assigned baseline — is the normal state of any environment under active use.

Sources of Drift

Emergency changes applied outside the change management process
Software updates that reset or override hardened settings
Administrator workarounds that disable security controls to troubleshoot an issue and never get reverted
Automated processes (backup agents, monitoring tools, update mechanisms) that modify system configuration as a side effect

Detection Methods

Method	Latency	Coverage
Scheduled compliance scans (weekly)	Days	Full baseline
File integrity monitoring (FIM)	Minutes	Critical config files
Configuration change detection (real-time)	Seconds	Instrumented settings
Continuous monitoring platform	Hours	Framework-mapped controls

Response Workflow

When drift is detected:

Classify. Is this an authorized change (change ticket exists) or unauthorized drift?
Assess impact. Does the drift create an exploitable vulnerability? Reference vulnerability scanning data to correlate.
Remediate or accept. Auto-remediate low-risk drift. Escalate high-risk drift for immediate attention.
Trace the root cause. Was this a one-time manual change, or a systemic issue (broken GPO, failed Ansible run, misconfigured CI/CD)?

Organizations with mature device trust scoring integrate baseline compliance as a signal — a device that has drifted from baseline gets a lower trust score and may lose access to sensitive resources via Comply-to-Connect policies.

Compliance Mapping

Configuration baselines satisfy controls across virtually every compliance framework. Here's how the requirement surfaces in each:

Framework	Control ID	Requirement
NIST 800-53 Rev 5	CM-2, CM-6	Baseline Configuration; Configuration Settings
NIST 800-171	3.4.1, 3.4.2	Establish and enforce configuration settings
CMMC Level 2	CM.L2-3.4.1, CM.L2-3.4.2	Same as 800-171
FedRAMP	CM-2, CM-6, CM-7	Baseline, settings, least functionality
PCI DSS v4	Req 2.2	Secure configuration standards for all system components
SOC 2 Type II	CC6.1, CC6.6	Logical and physical access controls; system boundaries
ISO 27001	A.8.9	Configuration management

The mapping is deeper than single controls. A well-maintained baseline program simultaneously generates evidence for patch management (CM-3), access control (AC-3), audit logging (AU-2), and system integrity (SI-7) requirements. A single scan result — showing that audit logging is enabled, default accounts are disabled, and unnecessary services are removed — touches four or five control families at once.

This is why configuration baselines are among the highest-leverage compliance investments. One program, multiple framework satisfactions. Advisedly maps 500+ compliance frameworks against baseline findings automatically through crosswalk logic, so a single STIG scan result can generate evidence for NIST 800-53, CMMC, and FedRAMP simultaneously without manual re-mapping.

Key Takeaways

A configuration baseline is only a security control if it's maintained, scanned, and enforced. A document sitting in SharePoint is an artifact, not a control.

Choose CIS for commercial compliance, STIGs for DoD, and expect to end up with a custom tailoring document regardless.

Automate deployment and scanning. Manual baseline checks don't scale past a handful of systems.

Drift detection is more important than initial deployment. Systems drift within days of hardening; the question is whether you detect it in hours or at the next annual audit.

Tailoring documentation is the compliance artifact that auditors actually want to see. Not the scan report — the rationale for what you changed and why.

CMMC Phase 2 assessments in November 2026 make this urgent for any organization in the defense supply chain.

Frequently Asked Questions

How often should configuration baselines be reviewed and updated?

At minimum, review baselines quarterly to incorporate new STIG releases or CIS Benchmark versions. In practice, trigger a review whenever the underlying standard updates, when a significant vulnerability is disclosed that relates to a baseline setting, or when a major software upgrade changes the configuration surface. The tailoring document should carry a revision date and a "next review" date.

Can we use CIS Benchmarks instead of STIGs for CMMC?

Technically yes — CMMC doesn't mandate STIGs specifically. But the practical answer is that C3PAOs conducting Level 2 assessments are overwhelmingly familiar with STIGs, and the CMMC assessment guide references STIG language. Using CIS creates extra work to demonstrate equivalence. If you're processing CUI for a DoD contract, use STIGs for systems in the CUI boundary and CIS for everything else.

What's the difference between a baseline and a hardening guide?

A hardening guide is a set of recommendations. A baseline is a hardening guide that's been tailored to your environment, formally approved, and enforced through scanning and remediation. The CIS Benchmark is a hardening guide. Your tailoring document — CIS Benchmark Level 1 minus three exceptions plus two additional settings — is your baseline. The distinction matters for auditors: they want to see your baseline (tailored, approved, enforced), not a generic reference document.

How do we handle baseline exceptions without creating compliance gaps?

Every exception needs three things: a documented business justification (why the setting can't be applied), a compensating control (what you're doing instead), and an approval authority signature (who accepted the residual risk). Store exceptions in a structured format that maps to your POA&M process. When an auditor asks about a deviation, the answer shouldn't be "we couldn't make it work" — it should be "we accepted this risk on this date for this reason with this compensating control in place."

Should container and serverless workloads have baselines?

Yes, but the enforcement point shifts. Traditional baselines apply to long-lived systems; container baselines apply to the image build process. Harden the base image, scan it in CI/CD, and enforce that only compliant images deploy to production. For serverless, the baseline is the function configuration — memory limits, timeout values, IAM role scope, network access. The principle is identical: define the approved configuration, scan for deviation, remediate drift.

How Advisedly Helps

Advisedly integrates configuration baseline management into the broader compliance lifecycle — importing scan results from SCAP, CIS-CAT, and cloud-native scanners, mapping findings to 500+ framework controls through automated crosswalk, tracking tailoring decisions alongside risk acceptances, and surfacing drift as compliance events that trigger remediation workflows rather than waiting for the next audit cycle. The platform generates the evidence artifacts that C3PAOs and auditors expect (scan history, tailoring rationale, exception approvals, remediation timelines) without requiring your team to manually re-package scan outputs for each framework. If configuration management is the gap between your current state and your next assessment, reach out: begin@advisedly.ai