design-network-segmentation

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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