A.8.20

Objective

Secure networks and network devices to protect information in systems and applications.

Points of focus

• Databases and internal services have no direct public internet exposure
• Network segmentation separates production, staging, and corporate/office networks
• Admin interfaces (Kubernetes API, database consoles, internal tools) require VPN or identity-aware proxy access
• Security group and firewall rule changes go through the same review process as code
• Public-facing services sit behind a WAF and are covered by DDoS mitigation

Implementation notes

Design the network around blast-radius containment: production databases and internal services sit in private subnets with no direct route to the internet, reachable only through application load balancers or a bastion/proxy layer. Keep staging and production in separate accounts or VPCs rather than separate subnets of the same account, since account-level isolation survives far more misconfiguration scenarios than subnet-level rules alone. Put administrative interfaces — Kubernetes API servers, database management consoles, internal admin dashboards — behind an identity-aware proxy or VPN that ties access to your IdP and MFA rather than a static IP allowlist, which travels poorly with a remote or hybrid workforce. Treat security-group and firewall changes as code: manage them through the same IaC and pull-request review used for application infrastructure so every opened port has an author, a reviewer, and a reason in the commit history. Put a WAF in front of any public-facing web application and pair it with your cloud provider's or a third party's DDoS mitigation, tuning WAF rules against real traffic rather than leaving default rule sets unreviewed. Finally, review the full rule set on a fixed cadence — quarterly is common — specifically hunting for temporary rules that were never removed, since these are the single most common finding in this control area.

Audit tip: Export the live security-group or firewall rule set for your production database tier and check it live against the diagram you present — auditors increasingly pull this themselves via read-only cloud access, so make sure the diagram and reality already match before Stage 2.

Common gaps

• A database or internal admin tool was temporarily opened to 0.0.0.0/0 for a one-off debugging session and the rule was never reverted
• Staging and production share a VPC or security group set, so a staging misconfiguration can directly expose production data paths
• Security-group changes are made ad hoc in the cloud console during incidents without any linked ticket or subsequent reconciliation into IaC

Related

Primary sources

• ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.20)