Secure configuration baselines: CIS Benchmarks and system hardening

Reference article · 5 min read

Most agency security policies already say that systems will be securely configured. The gap is in the next sentence, which has to answer: configured according to what. Writing a hardening standard from scratch is slow, it ages badly as products change, and it gives an auditor nothing external to compare against.

Published baselines solve that by naming a specific, versioned set of settings that someone else maintains and that outside parties recognize. The two most commonly cited in state and local government are the CIS Benchmarks, published by the Center for Internet Security, and the Security Technical Implementation Guides, or STIGs, published by the Defense Information Systems Agency. Both are free. Adopting one by reference is faster and more defensible than writing your own settings, and it gives procurement a named standard to cite in solicitations instead of vague language about best practice.

What published baselines contain

• CIS Benchmarks. Consensus-developed guidance for operating systems, browsers, databases, network devices, cloud platforms, containers, and productivity suites. Each recommendation includes a rationale, a statement of operational impact, an audit procedure, remediation steps, and mappings to the CIS Critical Security Controls. Benchmarks are versioned against product versions.
• DISA STIGs. More prescriptive guidance written for Defense Department systems and distributed through the DoD Cyber Exchange. Each requirement carries a severity category and a specific check and fix, and many include machine-readable content that assessment tools can run.
• Vendor baselines. Microsoft, the cloud providers, and some vendors publish their own, often as importable policy packs. Convenient, but narrower and weaker as an external reference.

CIS has historically offered SecureSuite membership, including assessment tooling, to United States state, local, tribal, and territorial governments at no cost. Confirm terms with CIS.

Choosing a profile level you can live with

CIS Benchmarks are published in profiles. Level 1 is intended to apply broadly with limited effect on normal function. Level 2 is meant for environments where security outweighs convenience and accepts more operational impact. Some benchmarks add further profiles, including STIG-aligned ones.

• Default to Level 1 across the general estate, and reserve Level 2 for defined high-sensitivity systems, such as those handling criminal justice or federal tax information.
• Do not adopt a level the agency cannot sustain. A policy citing Level 2 with a long list of open exceptions is weaker than one citing Level 1 that holds.
• Pilot before you publish. Line-of-business applications, multifunction printers, and older integrations are where breakage shows up.
• Pin the version. Name the benchmark, product version, and profile level, and review when a new version ships.

Cloud tenants and productivity suites

Defaults in cloud platforms and productivity suites are generally tuned for adoption rather than restriction. Benchmarks exist for the major providers and suites, and this is often the fastest risk reduction available. Priority areas include multi-factor authentication coverage, legacy authentication protocols, administrative role assignment, external sharing and anonymous links, guest access, mail forwarding, audit log retention, and public exposure of storage.

Authorization of a cloud service under FedRAMP or StateRAMP speaks to the provider's platform, not to how the agency configured its own tenant. That configuration belongs to the agency and should be baselined like any server.

Exceptions and configuration drift

A hardening standard without a working exception process becomes shelfware the first time a setting breaks something. Keep the process simple and in one register.

• A named owner. A person, not a team mailbox.
• A reason and compensating control. What is relaxed, why, and what offsets the risk.
• An expiration date. Renewal should be a decision someone makes again, not an automatic rollover.
• Approval that matches severity. Minor items at the system owner level, significant ones higher.

Drift is the other half. Settings move through troubleshooting, vendor installers, break-fix work, and cloud resources created outside the standard build. Counter it by building from hardened images, expressing baselines as code where possible, rescanning on a schedule rather than only before audits, and routing security-relevant changes through change management.

Evidence auditors and insurers accept

Keep the named baseline and version in policy, a scope statement, current assessment output per system class, the exception register, and remediation tickets with dates. Assessors working under the CJIS Security Policy, IRS Publication 1075, the HIPAA Security Rule, or a state framework all ask configuration management questions, and a benchmark plus scan output answers most of them without writing narrative. Insurers ask related questions about authentication and privileged access. Requirements change, so confirm specifics with the authoritative source or counsel.

What to ask vendors and put in contract language

Questions worth asking during evaluation:

• Which published baseline does the product support, at which level? If none, what hardening guide do you publish, and when was it last revised?
• Does the application function under Level 1 as shipped? Which settings must be relaxed, and why?
• For hosted services, what baseline is applied to your infrastructure, and how is it verified?
• Does the product require local administrator rights, legacy protocols, weakened transport security, or exclusions from endpoint protection?

Terms worth requiring:

• The named baseline, version, and profile level, with a process for adopting newer versions.
• An obligation to document any deviation, with undocumented weakening treated as a defect.
• Notification when a product update changes security-relevant defaults.
• The right to scan, and timelines for remediating findings by severity.

A practical starting sequence

1. Pick one system class, such as Windows servers or the productivity tenant.
2. Read the benchmark, impact statements included.
3. Measure the current state and keep that first report.
4. Remediate in rings, starting with IT-owned systems.
5. Adopt one policy sentence naming the benchmark, version, and level, then schedule rescans.

HQT works with state and local agencies on secure configuration baselines, assessment tooling, and the documentation that supports audit and insurance review.

Frequently asked questions