Most networks are hard on the outside and soft on the inside: a strong perimeter firewall, and behind it a flat network where a compromised receptionist laptop can reach the database servers, the backup system, the printers, and the domain controllers directly. Ransomware operators depend on exactly this flatness — initial access is just the beginning; the damage comes from unrestricted lateral (east-west) movement afterward. Segmentation turns one big network into compartments, so a single compromised device no longer means a compromised organization.
Design the zones first, not the VLANs
- Group assets by trust level and function, not by physical location. A typical starting model: user workstations, servers (split further into web/app/database tiers where practical), management interfaces (iLO/iDRAC, switch management, hypervisor consoles), infrastructure services (AD, DNS, DHCP), printers and IoT, guest Wi-Fi, and backup infrastructure.
- Management interfaces and backup systems deserve the strictest isolation — they are the two zones ransomware operators target to disable recovery.
- Assign each zone a VLAN and a dedicated subnet with room to grow, and document the intended trust relationships between zones before touching a switch.
Enforce between the segments
- VLANs alone provide separation, not security — enforcement happens where routing happens. Route inter-VLAN traffic through a firewall (or use switch ACLs where a firewall is impractical) with default-deny between zones.
- Write the rules from the traffic matrix: workstations reach servers on specific application ports; nothing initiates connections to workstations; printers accept print protocols and initiate almost nothing; only the management VLAN reaches management interfaces; only backup infrastructure reaches backup targets on backup ports.
- Remember the shared dependencies: every zone needs DNS, DHCP relay, NTP, and authentication traffic to the infrastructure zone — model these explicitly or the migration will fail on day one.
Migration strategy
- Build the new VLANs and firewall zones alongside the existing network, with permissive-but-logged inter-zone rules initially.
- Migrate in low-risk waves: printers and IoT first (easy wins, minimal dependencies), then workstations, then servers — servers last because their interdependencies are the hardest to map.
- Use the logging period after each wave to refine rules, then ratchet toward default-deny once real traffic is understood.
- Plan IP addressing changes carefully; DHCP-based clients move easily, statically-addressed servers and hardcoded IP references in applications are where migrations stall.
Common pitfalls
- Segmenting without enforcing — dozens of VLANs all routed with
permit any between them is topology, not security.
- Forgetting intra-VLAN traffic: segmentation controls traffic between zones, not within them. For sensitive zones, add private VLANs or host-based firewall policies to limit peer-to-peer traffic inside the segment.
- Leaving hypervisor and storage networks unsegmented — VM escape or storage access bypasses every VLAN boundary you built.
- Skipping documentation: six months later, nobody remembers why VLAN 47 exists. Keep the zone model and traffic matrix as living documents.
Segmentation is the structural prerequisite for nearly everything else on this site: monitoring becomes meaningful (inter-zone denies are high-signal alerts), incident response gains containment options, and Zero Trust initiatives have a foundation to build on. It is a project measured in months, but every migrated zone pays off immediately.