Configuration management

What the requirement asks

The organization is to set, record, apply, watch and review how its hardware, software, services and networks are configured, security settings included. Purpose: keep hardware, software, services and networks working correctly with the security settings they need, and keep settings from being altered without approval or by mistake. Guidance: define and run processes and tools that enforce defined configurations for hardware, software, services such as cloud services, and networks, both on new installations and through the life of operational systems, with roles, responsibilities and procedures that keep every configuration change under control. Standard secure configuration templates should draw on public guidance such as vendor and independent security organization baselines, reflect the protection level needed, support the organization's policies and standards, and be feasible in its context; review them periodically and update them for new threats, vulnerabilities or new software and hardware versions. Templates should consider: keeping the number of privileged or administrator identities low; disabling unnecessary, unused or insecure identities; disabling or restricting unneeded functions and services; restricting access to powerful utilities and host parameters; clock synchronization; changing vendor default credentials immediately after installation and reviewing other security-relevant defaults; inactivity timeouts that log devices off; and checking licence compliance (5.32). Managing: record established configurations and log every change, stored securely, for example in a configuration database or templates, with changes going through change management (8.32); records can hold the current owner or contact, date of last change, template version and links to related assets' configurations. Monitoring: use a broad range of system management tooling (maintenance utilities, remote support, enterprise management, backup and restore) and review regularly to check settings, evaluate password strength and assess activity; compare actual settings with target templates and correct deviations by automatic enforcement or by manual analysis and corrective action. Other information: system documentation often holds configuration detail; hardening is part of configuration management; it can be joined with asset management; automation such as infrastructure as code is usually more effective; templates and targets can be confidential and should be protected. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Configuration management is the evidence base for many other controls. The guidance asks for the baseline, the drift check, the change and the exception.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep approved secure configuration templates or baselines for each platform, derived from vendor or independent guidance, with review dates and one live sample together.

Evidence an assessor asks for

• Secure baselinesApproved secure configuration templates or baselines for each platform, derived from vendor or independent guidance, with review dates
• Secure baselinesConfiguration records or a CMDB showing owner, last change date, template version and relationships between assets
• Secure baselinesChange records showing configuration changes passed through change management
• Secure baselinesConfiguration compliance scan results comparing actual settings with templates, and records of deviations corrected
• Secure baselinesEvidence of default credentials changed, unnecessary services disabled and inactivity timeouts set
• Secure baselinesInfrastructure as code repositories or automated enforcement tooling, with access restricted to protect the templates

The question an assessor will ask

An assessor will ask for approved secure configuration templates or baselines for each platform, derived from vendor or independent guidance, with review dates, then trace it to the system it protects. For A.8.9 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Baselines exist on paper but systems are never measured against them
• Cloud service configurations are outside configuration management
• Templates are not updated when new software versions are introduced
• Emergency configuration changes bypass change management and are never reconciled

Before the next audit

Before the next audit, check one live sample for this gap: baselines exist on paper but systems are never measured against them.