| name | design-network-segmentation |
| description | Use when designing network architecture for systems that handle sensitive data, require regulatory compliance, or need to contain blast radius from breaches |
| source | NIST SP 800-125B network security guidelines; CIS Controls v8 Control 12; PCI DSS v4.0 network segmentation requirements |
| tags | ["networking","security","architecture","compliance"] |
| verified | true |
Design Network Segmentation
Partition networks into isolated zones so that a compromised segment cannot pivot laterally to compromise others.
Why This Is Best Practice
Adopted by: PCI DSS mandates it for cardholder data environments; HIPAA requires it for ePHI isolation; DoD mandates zero-trust segmentation; every major financial institution
Impact: Reduces breach blast radius by 60-80% (IBM Cost of a Data Breach 2023); PCI DSS compliance requires segmentation to reduce audit scope; lateral movement limited to compromised segment
Why best: Flat networks allow attackers who breach any host to reach all hosts; segmentation enforces least-privilege at the network layer and contains compromise
Sources: NIST SP 800-125B (2016); CIS Controls v8 Control 12 (2021); PCI DSS v4.0 (2022)
Steps
-
Identify and classify assets — Inventory all systems and classify by data sensitivity (public, internal, confidential, restricted) and function (web tier, app tier, database, management). This classification drives segment boundaries.
-
Define security zones — Establish standard zones: DMZ (public-facing services), application tier, database tier, management/bastion, and DevOps CI/CD. Each zone has a defined trust level and allowed traffic flows.
-
Apply the principle of least-privilege to network flows — Define an allowlist of required traffic flows between zones. Default-deny all other traffic. Document every allowed flow with business justification. Deny-by-default is the foundational rule.
-
Implement VPC/VNET segmentation — Use cloud-native constructs: separate VPCs per environment (dev, staging, prod) and per security domain. Use VPC peering or Transit Gateway only for explicitly needed cross-VPC flows. Never peer dev VPC to prod.
-
Deploy security groups and NACLs — Security groups: stateful, applied at instance level, source/destination specific. NACLs: stateless, applied at subnet level, for subnet-boundary enforcement. Layer both; NACLs catch security group misconfigurations.
-
Isolate database tier — Database subnets must have no route to the internet (no NAT gateway, no IGW). Access only from application tier security group. Deny direct admin access; route through bastion host with session recording.
-
Implement a dedicated management zone — All administrative access (SSH, RDP, kubectl, cloud console) flows through a hardened bastion/jump host or VPN. The management zone has no internet access. Log all sessions with tools like AWS Systems Manager Session Manager.
-
Design micro-segmentation for critical workloads — For PCI or highly sensitive data: implement host-based firewall rules (iptables, Windows Firewall, Calico for Kubernetes) to restrict east-west traffic within a subnet. Service mesh (Istio) provides mTLS between services.
-
Validate with traffic flow analysis — Use VPC Flow Logs (AWS), Cloud Flow Logs (GCP), or NSG Flow Logs (Azure) to verify only allowed traffic flows exist. Scan for unexpected cross-segment flows. Run this analysis after every architecture change.
-
Document and review segment topology — Maintain a network diagram showing all segments, routing, and firewall rules. Review quarterly and after major changes. Treat undocumented traffic flows as security findings.
Rules
- Default-deny is non-negotiable; allowlist only, never blocklist-only for inter-zone traffic.
- Production and non-production networks must never be peered without a documented, reviewed exception.
- The database tier must have zero direct internet access; any route to the internet is a critical finding.
- All traffic crossing a zone boundary must traverse a firewall or security group; routing around security controls defeats segmentation.
Common Mistakes
- Overly broad security group rules —
0.0.0.0/0 on port 443 in internal segments; specify exact source security groups, not CIDR ranges.
- Flat VPC with subnets as only isolation — subnets in the same VPC can route to each other unless NACLs or security groups block them; subnets alone are not segmentation.
- Forgetting VPC endpoint security — S3 VPC endpoints require endpoint policies; without them, all instances in the VPC can access any S3 bucket including those in other accounts.
- Developer access to production databases — direct prod DB access from dev workstations bypasses application-layer controls; always route through the application tier.
When NOT to Use
- Single-tier applications with no sensitive data and no compliance requirements (simple static sites)
- Local development environments where segmentation overhead adds no security value
- Proof-of-concept systems with no sensitive data and a defined decommission date
