Understanding the NCSC's Third Cloud Security Principle: Secure Configuration Management

What the third principle means

The National Cyber Security Centre (NCSC) defines its third cloud security principle as the need for robust configuration management. It requires organisations to maintain secure, documented, and continuously monitored configurations for all cloud resources, ensuring that defaults and changes do not introduce vulnerabilities.

Why configuration matters in the cloud

Cloud services are highly dynamic; resources can be spun up, modified, or de‑commissioned in minutes. Without a disciplined approach, mis‑configurations—such as overly permissive storage buckets, open network ports, or disabled logging—become common attack vectors. Consistent configuration management reduces the attack surface, supports compliance, and enables rapid response when a breach is detected.

Key components of secure configuration management

• Baseline standards: Define a secure baseline for each service (e.g., IAM policies, encryption settings, network segmentation) and store it in version‑controlled code.
• Automated enforcement: Use Infrastructure‑as‑Code (IaC) tools, policy‑as‑code frameworks, or cloud‑native guardrails to prevent drift from the baseline.
• Continuous monitoring: Deploy scanning tools that regularly compare live configurations against the baseline and raise alerts on deviations.
• Change control: Require peer review, testing, and documented approval for any configuration change.
• Audit trails: Keep immutable logs of who changed what, when, and why, to satisfy forensic and regulatory needs.

Practical steps to implement the principle

1. Document a configuration baseline for each cloud service you use. Include required encryption, access controls, logging, and network rules.

2. Adopt Infrastructure‑as‑Code (e.g., Terraform, CloudFormation) so that the baseline lives in code repositories that can be reviewed and versioned.

3. Integrate policy‑as‑code tools such as Open Policy Agent, AWS Config Rules, or Azure Policy to enforce the baseline automatically during deployment.

4. Schedule regular scans with tools like Scout Suite, Prowler, or native security posture managers to detect drift.

5. Establish a change‑management workflow that mandates peer review, testing in a non‑production environment, and documented justification before any configuration alteration reaches production.

6. Maintain immutable audit logs using cloud provider logging services (CloudTrail, Activity Log) and forward them to a SIEM for long‑term retention and analysis.

Common pitfalls to avoid

• Relying on manual checks – they are error‑prone and cannot keep pace with rapid cloud changes.
• Treating the baseline as a one‑time document – configurations evolve, so the baseline must be reviewed regularly.
• Neglecting third‑party services – SaaS integrations often have separate configuration settings that need the same governance.

Comparison of tools for automated enforcement

Measuring compliance with the principle

Compliance can be assessed through three metrics: configuration drift rate (percentage of resources deviating from baseline), time to remediate drift, and audit‑log completeness (percentage of changes with full metadata). Regular reporting on these metrics demonstrates adherence to the NCSC's third principle and highlights areas for improvement.