NIST 800-53 CM-6 Configuration Settings Evidence and Hardening Guide

CM-6 is the hardening control. It asks you to pick secure settings for the components in your system, apply them, approve any exceptions and watch for changes. If CM-2 is the baseline, CM-6 is the detail of what goes inside it.

800-53 binds US federal systems and others by contract. For a small or mid size company it is a reference, and hardening evidence is one of the most common requests in customer security reviews.

What the control asks

The statement has four parts.

• Establish and document configuration settings for components in the system, set to the most restrictive mode consistent with operational requirements, using a source of common secure configurations that you choose.
• Implement those settings.
• Identify, document and approve any deviations from the established settings for the components you define, based on operational requirements you define.
• Monitor and control changes to the settings in line with your policies and procedures.

NIST's guidance defines configuration settings as the parameters you can change in hardware, software or firmware that affect security and privacy posture or functionality. Examples include registry settings, account, file and directory permissions, and settings for functions, ports, protocols, services and remote connections. Privacy parameters count too, such as access control settings, data processing preferences and retention permissions.

The guidance also describes common secure configurations, also called checklists, lockdown and hardening guides or security reference guides. These are recognized, standardized benchmarks for specific products and platforms. You choose which one applies and record the choice.

What it means in practice

Choose a benchmark per platform. A cloud provider's foundations benchmark for accounts, a vendor hardening guide for the operating system, a container benchmark for the runtime and a database hardening guide each play this role. Then turn the benchmark into enforced settings through images, infrastructure code and policy as code.

Deviations are normal. A benchmark may call for a setting that breaks a workload. What the control wants is a record: what differs, why, who approved it and when it expires.

Evidence to collect

• The list of benchmarks or hardening guides in use, per platform, with versions.
• The documented settings, as code, images or a configuration management repository.
• A scan or assessment report showing actual systems against the benchmark.
• The exception register with rationale, approver and expiry.
• Change monitoring output, such as alerts on drifted settings, and the tickets that followed.
• Review dates for the benchmark selection.

Common gaps

• A benchmark is named in policy but not applied to any system.
• Settings exist as code, but hand edits in the console drift away and nobody notices.
• Exceptions live in chat threads, so no one can say who approved them.
• Scans run, but results are not triaged, so failures accumulate.
• Privacy parameters, such as retention defaults, are never treated as configuration settings.

How to implement it

1. Inventory the platform types you run, then pick one benchmark each.
2. Write the settings into your build. Prefer image builds and infrastructure code over runbooks.
3. Run a scan weekly or on each deploy, and keep the reports.
4. Open a ticket for every failed check, with an owner and a date, or an approved exception.
5. Alert on out of band changes to critical settings and tie the alert to a response step.

This is where the enhancements help. CM-6.1 is Automated Management, Application, and Verification. CM-6.2 is Respond to Unauthorized Changes. CM-6.3 is Unauthorized Change Detection. CM-6.4 is Conformance Demonstration. A monitoring loop that detects, tickets and verifies is the practical form of all four.

The demo below walks through a continuous monitoring view, which is the same pattern applied to settings.

Click through it at your own pace, or open it full screen.

Mapping to other frameworks

Hardening requirements appear in SOC 2, ISO 27001, PCI DSS and other frameworks under different wording. Mappings vary, so confirm against an authoritative crosswalk for the versions you use.

Quick check

Sources

• NIST SP 800-53 Rev 5, CM-6 Configuration Settings
• NIST OSCAL SP 800-53 Rev 5 catalog