Establish and enforce security configuration settings
📖 What This Means
This control requires organizations to define and maintain secure configurations for all hardware and software systems, then enforce those settings consistently. Think of it like creating a 'security blueprint' for every device and application in your network, then making sure nobody deviates from it. For example: 1) A company sets all workstations to automatically lock after 15 minutes of inactivity and enforces this via Group Policy. 2) A cloud server is configured to only allow encrypted connections, with automated tools blocking any non-compliant configurations.
🎯 Why It Matters
Misconfigured systems are the #1 cause of preventable breaches in defense contracting. A 2023 DoD report found 62% of contractor breaches stemmed from unpatched systems or default configurations. The SolarWinds attack exploited servers with unchanged admin passwords. Proper configuration management could have prevented this. From DoD's perspective, consistent configurations ensure: 1) Predictable security postures across the supply chain 2) Reduced attack surfaces 3) Faster incident response when all systems follow the same rules.
✅ How to Implement
- 1. Use CSP-native tools (AWS Config, Azure Policy, GCP Security Command Center) to define configuration baselines
- 2. Create custom rulesets using SCAP or CIS benchmarks for your specific workloads
- 3. Implement automated remediation (e.g., AWS Config auto-remediate, Azure Policy 'DeployIfNotExists')
- 4. Configure real-time alerts for configuration drift (e.g., CloudTrail+EventBridge for AWS)
- 5. Document exceptions in a change-controlled CMDB
📋 Evidence Examples
Approved Configuration Baseline Document
Configuration Compliance Scan Reports
Remediation Tickets
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For CM.L2-3.4.2 ("Establish and enforce security configuration settings"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your configuration management process, including baseline configurations, change control procedures, vulnerability management, and how configuration compliance is monitored and enforced. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"CM.L2-3.4.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to establish and enforce security configuration settings. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"CM.L2-3.4.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to establish and enforce security configuration settings. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"CM.L2-3.4.2 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all system types within the CUI boundary requiring baselines
- • Document configuration management tools and CMDB
- • Map change control workflow from request to implementation
- • Ensure this control covers all systems within your defined CUI boundary where establish and enforce security configuration settings applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Configuration Management Policy
- 📄 Baseline configuration documents
- 📄 Change management records
- 📄 CMDB/asset inventory
- 📄 Evidence artifacts specific to CM.L2-3.4.2
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will compare actual system configurations against documented baselines, review change tickets for proper approval workflow, and verify vulnerability remediation within SLA.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do you have documented configuration standards for all systems?
Question 2: Are configurations automatically enforced?
Question 3: Do weekly scans detect configuration drift?
Question 4: Is there evidence of remediation for all non-compliant systems?
⚠️ Common Mistakes (What Auditors Flag)
1. Using default configurations
2. No exception documentation
3. Scanning but not fixing
4. Inconsistent cloud vs on-prem rules
📚 Parent Policy
This practice is governed by the Configuration Management Policy