Network Segmentation Validation: From Diagram to Evidence
A network diagram describes intended separation. Segmentation is demonstrated only when expected traffic works and prohibited traffic fails under controlled tests. NIST’s zero trust architecture frames access around explicit decisions rather than trusted network location; segmentation review turns that principle into an inventory of flows, rules, tests, and owners.
Create the flow register
List source zone, source identity or workload, destination zone, destination service, protocol, port, direction, authentication requirement, business owner, rule identifier, and expiry. Include management, DNS, identity, backup, monitoring, update, and cloud control-plane flows. These are frequent hidden paths around a diagram. “Any-to-any for troubleshooting” is not a flow definition.
Start from business transactions. A web application may require app zone to database zone on one database port, database to backup service on a named path, and PAW to server management over a restricted protocol. A user VLAN should not gain the same database path merely because it can resolve the hostname. Document expected denial as carefully as expected allow.
Test layered enforcement
For each high-value boundary, test routing, network firewall or security group, host firewall, DNS, and application authentication where relevant. A denied TCP connection can still leave DNS or management exposure; an allowed port can still fail because service identity is correct. Record command or tool, test source, timestamp, destination, expected result, observed result, and rule evidence. Use approved test accounts and windows. Never turn a flow test into a denial-of-service test.
A pass is an allowed business flow that completes its narrow transaction, or a prohibited flow that is denied at expected boundary. A timeout alone is inconclusive until rule and telemetry establish why it failed. A fail includes unexpected reachability, an undocumented allow rule, blocked approved business traffic, or control evidence inconsistent with observed flow.
Completed flow matrix
| Flow | Expected result | Evidence | Result | Remediation or exception |
|---|---|---|---|---|
User zone to database 1433 | Denied | firewall log shows drop | Pass | None |
App zone to database 1433 | Allowed only for app identity | health transaction and rule ID | Pass | Revalidate after release |
| PAW to server WinRM | Allowed from management subnet | authenticated session logged | Pass | MFA policy reviewed |
| Dev zone to production database | Denied | connection succeeds | Fail | Remove security-group rule; retest |
The completed example is illustrative. A result is not transferable between environments. Record cloud route tables, security groups, network ACLs, load balancers, Kubernetes policy, and host firewall where each participates. A cloud security group may allow traffic that an on-premise firewall diagram never shows.
Handle exceptions without normalising them
An exception records asset, exact flow, business reason, owner, compensating control, approver, date, and expiry. A temporary vendor path might be constrained by source IP, time window, MFA, session logging, and a support ticket. It remains a failed baseline condition until closed. On expiry, remove rule or formally reapprove it after a new risk review.
Report denied and allowed flow evidence separately from vulnerability findings. This makes a remediation testable: “remove sg-123 rule permitting Dev CIDR to database port” has a clear retest, unlike “improve segmentation.” Re-run priority flows after firewall, route, identity, or application changes. Segmentation remains an operating control, not a one-time diagram exercise.
Review cadence and ownership
Assign a business owner to every permitted cross-zone flow and a control owner to the enforcement point. Reconcile flow register against firewall and cloud-rule exports on a scheduled basis and after migrations. Remove allows that lack an owner, purpose, or current dependency. Review logs for denied traffic that may signal broken application assumptions, but do not automatically open access from a denied log alone. First confirm asset, protocol, requester, and business need. Retest both allowed and denied cases after each approved change. A flow remains incomplete when routing, firewall, and host policy evidence disagree. This small discipline turns segmentation into a measurable control with clear remediation evidence.
Test safeguards
Use destination-safe probes and agreed rate limits. Validate no state-changing request is required to establish a denial or narrow allow. For encrypted services, test transaction outcome and security telemetry rather than relying only on a port-open result. Coordinate with operations before a production flow test so expected alerts are recognised without suppressing real incidents. When logs are unavailable, record evidence gap as a separate failure: lack of observability prevents a reviewer from distinguishing intended block from accidental outage.
Reconcile every enforcement layer
For a failed denied-flow test, compare route lookup, security-group or firewall rule ID, host listener, host firewall state, DNS answer, and application log before deciding cause. Preserve command, source identity, timestamp, and packet or flow-log reference. For an allowed flow, prove destination identity and protocol rather than only port reachability. This prevents a stale rule, alternate route, or host-local exception from being hidden by a diagram-level conclusion.