A.8.9
Configuration management
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control requires the organization to define and document the configurations (including security configurations) of hardware, software, services, and networks as standardized baselines, and to apply, monitor, and review them consistently. The objective is to detect and correct unauthorized configuration changes and the configuration drift that accumulates over time, so that systems continuously maintain their intended security posture. It helps reduce the attack surface created by insecure defaults, unnecessary functions, and inconsistent settings.
Key checkpoints
- Are secure configuration baselines/templates defined and documented per asset type (server OS, network devices, DBMS, middleware, cloud services, endpoints, and so on)?
- Are the defined baselines built into deployment procedures so they are actually applied when systems are newly introduced, reinstalled, or provisioned?
- Is the live configuration of running systems periodically checked against the baseline to detect drift and unauthorized changes?
- Is configuration information (settings, versions, interdependencies, owners, and so on) kept current and linked to the change management process?
- Is access to sensitive configuration information (credentials, keys, detailed settings) controlled, and is it stored/transmitted securely?
- Are configuration baselines reviewed and updated periodically in line with changes in threats/vulnerabilities?
Implementation guidance
- Establish configuration baselines/templates per asset type that reflect hardening requirements, and document the rationale (vendor guidance, industry benchmarks, internal policy).
- Standardize replacement of default passwords/secrets, disabling unnecessary default accounts, minimizing services/ports/functions, and enabling logging and time synchronization. Renaming accounts does not substitute for credential protection.
- Use golden images, infrastructure as code (IaC), and configuration management tools to apply baselines automatically, reducing manual errors and drift.
- When drift is detected, investigate its cause and operational impact and preserve necessary evidence. Route suspected compromise to incident response, then determine safe restoration or formal change approval. Do not accept detected drift as a new baseline without review.
- Keep configuration items (CIs), versions, dependencies, and owners current in a CMDB/configuration repository, integrated with change and asset management.
- Avoid hardcoding credentials/keys in configuration files; protect them with secret management (vault), access control, and encryption.
- Periodically re-review and revise baselines to reflect the evolving threat landscape and new vulnerability information, and keep a revision history.
Evidence
- Secure configuration baseline/hardening standard documents per asset type
- Configuration management tool/IaC code, golden images/templates, and deployment records
- Configuration drift check results and corrective action records
- CMDB/configuration repository records of configuration items/versions/dependencies
- Configuration change approvals and change-management linkage records
- Periodic review/revision history of configuration baselines
Nonconformity examples
- No secure configuration baseline is defined, so settings differ from server to server and whether hardening was applied cannot be confirmed.
- Default administrator passwords remain in use or access through unnecessary default accounts is unrestricted.
- With no procedure to check for configuration drift, unauthorized setting changes go unaddressed for a long time.
- The CMDB is not kept current, so the actual configuration does not match the documented configuration.
- Database passwords/API keys are hardcoded in plaintext in configuration files and exposed in the repository.
- A baseline is established only once at the start and is never updated to reflect changes in threats/vulnerabilities.