A.8.22
Segregation of networks
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
Segregation of networks partitions a single network into zones with different trust levels, business functions, and data sensitivity, using logical and/or physical separation so that a compromise or fault in one zone does not spread to others. By separating service networks, management networks, development/test networks, the DMZ, and internal user networks, and by limiting inter-zone traffic to the minimum necessary, the control reduces the attack surface and hinders lateral movement. This protects the confidentiality, integrity, and availability of critical information assets and, when an incident occurs, contains its impact within a specific zone.
Key checkpoints
- Is the network divided into zones/segments by trust level, business purpose, and data sensitivity, with the criteria documented?
- Is inter-zone communication configured to block by default and permit only required traffic (default deny)?
- Are necessary boundaries between public services, internal business, management, development/test, and production enforced physically or logically to restrict unauthorized communication?
- Are guest/untrusted wireless access and business access separated, with identity- and device-appropriate policies for approved corporate wireless connections?
- In cloud/virtualized environments, is logical separation applied via VPCs/subnets/security groups and reviewed periodically?
- Are the segmentation policy and firewall rules reviewed regularly to remove unnecessary or overly permissive allow rules?
Implementation guidance
- Define trust boundaries and design zones based on asset identification and risk assessment results.
- Place firewalls/router ACLs/next-generation firewalls at zone boundaries and manage allow rules on an allowlist basis after applying default deny.
- Protect management traffic through dedicated management networks, bastions, or equivalent logical access controls. Verify administrator and target authentication, permitted paths and privileges, and logging so ordinary business access does not grant administrative access.
- In the cloud, build zones with VPCs/subnets/security groups/network ACLs/service endpoints and manage configuration as code (IaC).
- Consider workload-level micro-segmentation and East-West traffic control from a zero-trust perspective.
- Set a regular review cycle for inter-zone allow rules and tie changes to the change management process with approvals and records.
Evidence
- Network diagrams and zone design documents (trust zones, IP ranges, VLAN configuration)
- Firewall/ACL rule lists and default deny configuration screens
- Results of periodic firewall policy reviews and records of unused/excessive rule cleanup
- Management network/bastion configuration and access control settings
- Cloud VPC/subnet/security group/network ACL configuration details
- Change management records (approvals for zone/rule changes)
Nonconformity examples
- Public-facing services lack enforced boundaries to internal business systems, permitting unnecessary internal communication.
- Firewall policy contains any-any allow rules, effectively nullifying segmentation.
- The development/test network is not separated from production, so test traffic reaches production systems.
- Management traffic lacks necessary authentication and access restrictions, allowing unauthorized access from ordinary business-network users.
- A cloud security group exposes management ports (22/3389) to 0.0.0.0/0.
- Inter-zone firewall rules are not reviewed periodically, leaving rules for departed staff or decommissioned systems in place.