Under NIST SP 800-53 controls CM-2 and CM-6, how does a hardening baseline become a documented standard with approved deviations?

## From a guide to a standard A CIS Benchmark or a DISA STIG is a published guide. A **hardening baseline** is what the organization actually commits to: the guide it chose, the settings it applies, the ones it does not and why, and how the whole is kept current. Auditors, assessors and future engineers read the baseline, not the guide. NIST SP 800-53 Rev. 5 describes the required pieces in two configuration management controls, and they are the cleanest way to answer this question. ## CM-6: configuration settings `CM-6` has four parts: 1. **Establish and document** configuration settings for system components that reflect the **most restrictive mode consistent with operational requirements**, using organization-defined **common secure configurations**. 2. **Implement** the settings. 3. **Identify, document and approve any deviations** from the established settings for defined components, based on defined operational requirements. 4. **Monitor and control changes** to the settings in line with organizational policies and procedures. The discussion explains that common secure configurations - also called security configuration checklists, lockdown and hardening guides, and security reference guides - can come from product developers, federal agencies, consortia and others, and it names STIGs among them. A CIS Benchmark fits the same description. Organizations set organization-wide settings first and derive specific settings for each system; the established settings become part of the system's **configuration baseline**. ## CM-2: baseline configuration `CM-2` requires the organization to: - **develop, document and maintain under configuration control** a current baseline configuration of the system; and - **review and update** it at an organization-defined frequency, when required by defined circumstances, and **when system components are installed or upgraded**. The discussion describes baselines as documented, formally reviewed and agreed-upon specifications. That is the key word for interviews: **agreed-upon**. A baseline no one approved is just a snapshot. ## What the documented standard contains | Element | Why it is there | |---|---| | The chosen guide, with product and version | Anchors the standard to a named common secure configuration | | The profile or level adopted per system role | Records the risk decision, for example Level 1 for general servers | | The list of deviations | Each with the setting, affected components, operational reason, approver and date | | Compensating measures where relevant | Shows how the risk of a deviation is reduced | | Review triggers and cadence | Satisfies CM-2's review on schedule and on install or upgrade | ## Handling a deviation well Suppose a Benchmark recommendation disables a service that a legacy application needs. A good deviation record: - names the recommendation and the components it affects; - states the **operational requirement** that makes the setting unworkable; - records **who approved** it and when; - notes any compensating measure, for example restricting network access to that service; - says when it will be revisited, such as at the application's next upgrade. A poor one is a comment saying "breaks app" or, worse, a silently skipped setting. CM-6 treats undocumented deviation as a failure of the control. ## Why the review triggers matter A baseline that is not revisited decays. New Benchmark or STIG versions add and change recommendations, component upgrades change defaults, and the operational reason behind an old deviation may no longer hold. Tying reviews to CM-2's triggers - the set frequency, defined circumstances such as a significant security event, and every install or upgrade - keeps the standard and its exception list honest. ## The same pattern elsewhere - **SP 800-171 Rev. 3** requirement **03.04.02 Configuration Settings** asks for settings reflecting the most restrictive mode consistent with operational requirements, and for deviations to be identified, documented and approved; **03.04.01** covers the baseline configuration. - **CIS Control 4** asks organizations to establish and maintain secure configuration of enterprise assets and software. The framework language differs, but the shape is the same: choose a standard, apply it, document and approve exceptions, and keep it current. A strong answer names both controls, quotes "most restrictive mode consistent with operational requirements", lists what a deviation record must contain, and shows how the baseline is kept current through review triggers.