Network Segmentation, Architecture, and Cloud Security Controls
Network Segmentation, Architecture and Cloud Security Controls
This domain tests whether you can build and prove boundaries that reduce scope, and select controls that satisfy Requirement 1.
Segmentation reduces scope only when it is enforced and validated. In cloud, boundaries come from separate accounts or subscriptions, VPCs or VNets, subnet tiers, security groups and network ACLs, route tables, private endpoints and centralised egress. Requirement 1.3.1 restricts inbound traffic to the CDE, 1.3.2 restricts outbound, and 1.4.1 requires controls between trusted and untrusted networks. If you rely on segmentation to keep systems out of scope, 11.4.5 requires penetration testing of the segmentation controls at least every 12 months and after any change to segmentation methods.
A workable pattern: no public IPs on data tiers; database security groups referencing only the application security group; administration through a bastion or session manager in a separate account with MFA and session recording; private service endpoints so traffic never traverses the internet; default-deny egress.
Worked example. A container platform runs CDE and non-CDE namespaces on one cluster, and the team claims segmentation by namespace. The assessor asks for the test proving a compromised non-CDE pod cannot reach the CDE database. None exists. Namespaces are a mechanism, but without enforced network policy or service-mesh authorization and a validated test, the whole cluster including the node pool falls into CDE scope. Reasoning: PCI asks for effective, evidenced isolation; the mechanism is your choice, the proof is not optional.
Traps. Treating shared tenancy as automatic isolation; 0.0.0.0/0 rules on management ports; testing segmentation only from the internet rather than from a neighbouring non-CDE workload; forgetting to retest after a network change; mixing CDE and non-CDE workloads on shared hosts without compensating controls.