Network Segmentation Beyond Compliance

Network segmentation divides a network into zones and controls which traffic can pass between them, so a problem in one area can't spread freely to the rest. Plenty of organizations segment just enough to satisfy an auditor, often to shrink PCI DSS scope, and leave everything else flat. The real value comes from going further: separating users from servers, isolating management interfaces, controlling east-west traffic and designing cloud networks the same way. The right place to start is a map of the traffic flows you actually have. Rules come after that.

What is network segmentation?

Segmentation groups systems into zones based on function and sensitivity, then enforces policy at the boundaries between them. Enforcement can happen at firewalls, router and switch access control lists, host-based firewalls or cloud security groups.

It pays off in several ways:

• Limits lateral movement. A compromised account or device can only reach what its zone is allowed to reach.
• Contains failures. Misconfigurations, broadcast storms and runaway jobs stay inside one segment.
• Protects sensitive systems. Domain controllers, databases and backups sit behind additional controls.
• Reduces audit scope. Fewer systems in scope for a given standard means less to assess.

Why go beyond compliance-driven segmentation?

PCI DSS doesn't require segmentation, but it's the standard way to reduce the scope of the cardholder data environment (CDE). If you rely on it, PCI DSS expects segmentation controls to be penetration tested at least annually, every six months for service providers, and after changes. That holds whether you're assessing against version 3.2.1 or the newer version 4.0, published in March 2022.

The problem is what happens outside the CDE boundary. Compliance-driven projects often draw one careful line around the payment systems and leave everything else in a single flat network. File servers, HR systems, backup infrastructure, development servers and the directory remain reachable from every laptop. One stolen credential can then go a very long way.

What's the difference between macrosegmentation and microsegmentation?

These aren't competing approaches. Most organizations need macrosegmentation first and add microsegmentation where the risk justifies it.

NIST SP 800-207, the zero trust architecture guidance published in August 2020, describes microsegmentation as one of its main approaches, alongside enhanced identity governance and software-defined perimeters.

How do you start? Map your traffic flows

Segmentation projects that begin with a firewall rule base tend to break things and lose support. Start with evidence instead.

1. Inventory and group assets. List systems and assign each to a group by function and data sensitivity, such as user endpoints, web servers, databases, directory services, backup and management interfaces.
2. Collect flow data. Use firewall logs, NetFlow or IPFIX from core switches, cloud flow logs and host connection data. Collect long enough to catch periodic jobs such as month-end processing.
3. Build a flow matrix. For each flow, record the source group, destination group, port, purpose and business owner.
4. Challenge every flow. Many will be legacy, unnecessary or far broader than needed. Anything nobody can explain is a candidate for removal.
5. Design zones and draft rules. Default deny between zones, with specific allows for each justified flow.
6. Deploy in log-only mode. Where your tools allow it, watch what would be blocked before enforcing.
7. Enforce, then tighten. Start with broad allows between zones and narrow them as confidence grows.

A simple flow matrix entry might read: user endpoints to the ERP application servers on TCP 443, for the finance team's ERP access, owned by the ERP application owner. That one line tells you what to allow and who to ask when it changes.

What segmentation patterns matter most?

Separate user networks from servers

Users need to reach applications, usually over a handful of ports. They rarely need file sharing, remote desktop or SSH access to every server. Put user endpoints in their own zones and allow only the application ports they need.

Also block workstation-to-workstation traffic on user networks where you can. Laptops seldom need to talk to each other directly, and peer traffic is a common path for lateral movement after one device is compromised.

Isolate the management network

Switches, firewalls, hypervisors, storage arrays and server out-of-band management controllers all have administrative interfaces. Those interfaces should live on a dedicated management network, reachable only from hardened admin jump hosts or privileged access workstations.

Give backup infrastructure its own restricted segment too. If an attacker or a careless script can reach backup servers from the general network, your recovery plan is exposed to the same event it's supposed to recover from.

Control east-west traffic

East-west traffic is traffic between systems inside your network, as opposed to north-south traffic in and out of it. Most perimeter firewalls never see it, which is why flat internal networks are so attractive to anyone who gets a foothold.

• Separate application tiers so databases only accept connections from their application servers.
• Restrict domain controllers to the ports clients and other directory servers actually need.
• Log denied east-west traffic. It surfaces both misconfigurations and suspicious activity.

Don't mistake VLANs for firewalls

VLANs separate broadcast domains. They don't filter traffic. If your core switch routes freely between VLANs, you have organized the network but you haven't segmented it. Put a firewall or enforced access control lists at the point where traffic moves between VLANs.

Use identity-based segmentation where IPs don't stay put

IP-based rules struggle when addresses change, as they do with DHCP, remote workers and cloud autoscaling. Identity-based segmentation writes policy around who or what is connecting.

For users and devices, port-based network access control (802.1X) can place a device in the right segment based on its identity and posture, sending unknown devices to a quarantine or guest network. For workloads, rules based on tags or labels follow the system wherever it runs.

Contain IoT, OT and guest devices

Printers, cameras, badge readers and building systems are rarely patched on the same schedule as servers. Give them their own segments with access only to the specific services they need. Guest Wi-Fi should reach the internet and nothing else.

How should you segment cloud VPCs and VNets?

Cloud networks start with a clean slate, which makes them easier to design well and just as easy to flatten.

• Use accounts or subscriptions as hard boundaries. Separate production, development and test into different accounts, subscriptions or projects, each with its own virtual networks.
• Use a hub-and-spoke design. Put shared services and traffic inspection in a hub network. Workloads live in spokes, and spoke-to-spoke traffic routes through the hub.
• Subnet by tier. Only load balancers and gateways sit in public subnets. Application and data tiers stay private.
• Write security group rules by reference. Allow the database security group to accept traffic from the application security group, rather than from a whole address range.
• Never expose management ports to the internet. Use a bastion host or brokered access instead.
• Use private endpoints for managed services. Keep storage and database traffic off public endpoints.
• Turn on flow logs. You'll need them for both troubleshooting and investigation.

Watch your hybrid connections. A site-to-site VPN or private link between a flat on-premises network and a cloud VPC can quietly undo careful cloud design.

How do you test and maintain segmentation?

Segmentation decays unless someone looks after it. Temporary rules become permanent and new systems land in the wrong zone.

• Test from inside each zone by trying to reach what should be blocked, such as the management network from a user subnet.
• Retest after significant network or firewall changes.
• Review rules on a schedule. Remove unused rules, any-to-any rules and expired temporary exceptions.
• Require an owner and a business reason for every new rule, and set an expiry date on temporary ones.

Frequently asked questions

Are VLANs enough for segmentation?

No. VLANs separate traffic logically, but without a firewall or enforced ACLs between them, traffic still flows freely. VLANs plus filtering at the routing point is the minimum.

Do we need microsegmentation?

Not everywhere. Start with macrosegmentation across the whole environment, then apply microsegmentation to your highest-value systems, such as directory services, databases holding sensitive data and backup servers.

Will segmentation break our applications?

It can if you skip the flow mapping. Collecting flow data first, deploying in log-only mode and involving application owners keeps disruption low.

How does segmentation relate to zero trust?

Segmentation is one of the foundations of zero trust. It removes implicit trust based on network location by making every flow between zones explicit, and microsegmentation extends that down to individual workloads.

Next steps

• Start collecting flow data from your core network and cloud environments now.
• Build a flow matrix for your most sensitive systems first.
• Separate user networks from servers and put a firewall at the inter-VLAN routing point.
• Move management interfaces and backups into restricted segments.
• Review cloud security groups for internet-exposed management ports and address-range rules.