8.3.1. Configuration Management and Baselines
💡 First Principle: A security baseline is the documented, approved minimum security configuration for a system type. Without a baseline, you cannot detect drift — because you have not defined what "correct" looks like. Configuration management is the continuous process of comparing actual system state against the baseline and remediating deviations.
Configuration management lifecycle:
- Identify — Inventory all configuration items (CIs): servers, network devices, applications, security tools, cloud resources. Each CI has a unique identifier and an owner.
- Baseline — Establish and document the approved secure configuration for each CI type. Sources: CIS Benchmarks, DISA STIGs, vendor hardening guides, organizational security policy.
- Control — All changes to CIs must go through the change management process. Unauthorized changes are security findings.
- Audit — Continuously compare live configurations against baselines using automated tools (SCAP scanners, Ansible, Puppet, Chef, DSC). Alert on drift.
- Report — Configuration compliance metrics feed into security dashboards and audit evidence.
Baseline sources and automation:
| Source | Applies To | Depth |
|---|---|---|
| CIS Benchmarks | OS, databases, cloud platforms, network devices | Detailed — specific registry keys, file permissions, service states |
| DISA STIGs | US DoD systems | Extremely detailed — CAT I/II/III severity classification |
| Vendor hardening guides | Specific products | Product-specific best practices |
| Organizational policy | All systems | Overrides/supplements vendor guidance for local requirements |
Automated compliance scanning using SCAP (Security Content Automation Protocol) enables organizations to define baselines in machine-readable format and scan thousands of systems continuously. SCAP components include OVAL (vulnerability definitions), XCCDF (benchmark checklists), and CVE (vulnerability identifiers). The output feeds directly into vulnerability management and audit reporting.
Configuration drift detection and response:
When drift is detected, the response depends on whether the change was authorized:
- Authorized change with no change ticket — Process failure. The change itself may be acceptable, but the governance failure must be addressed.
- Unauthorized change with no business justification — Security incident. May indicate compromise — an attacker modifying firewall rules, disabling logging, or installing backdoors.
- Authorized change that weakens security — Risk acceptance decision. The change requestor must justify why the security reduction is acceptable and what compensating controls are in place.
⚠️ Exam Trap: Configuration management is not a one-time activity. Scanning systems at deployment and never again allows drift to accumulate undetected. The exam tests whether you understand that continuous monitoring — not periodic assessment — is required to maintain security posture.
Reflection Question: An automated compliance scan reveals that 23% of production servers have deviated from the approved CIS Benchmark baseline. Investigation shows most deviations are services enabled by administrators for troubleshooting that were never disabled afterward. What does this reveal about the organization's change management process, what immediate remediation should occur, and what process improvement prevents recurrence?
