Network Segmentation Design: How to Segment a Flat Legacy Network Without a Full Redesign

Understanding why flat networks exist is a prerequisite for designing a segmentation approach that will actually get implemented. The technical debt of flat networking has three root causes: organizational, economic, and operational. Organizationally, network engineering and security engineering are frequently separate teams with separate priorities. Network engineering measures success by uptime and deployment speed; security engineering measures it by risk reduction. When those metrics conflict, uptime wins. A proposed VLAN change that could disrupt application connectivity is a political risk that network teams reasonably resist.

Economically, the cost of network redesign is immediate and visible while the cost of a flat network breach is probabilistic and deferred. Every year that passes without a major lateral movement incident reinforces the implicit conclusion that the flat network is acceptable. The accounting for this decision changes dramatically after the first breach in which an attacker moves from a compromised workstation to a domain controller in 18 minutes because there was nothing between them.

Operationally, flat networks are easier to troubleshoot. When an application breaks in a segmented network, the cause is often a missing firewall rule between segments. The debugging process requires flow analysis, rule review, and coordination between teams. In a flat network, everything can talk to everything by default, which simplifies troubleshooting but eliminates the chokepoints that would contain a breach. The operational convenience of flat networking is a real productivity benefit that any segmentation program must account for: if segmentation adds two weeks to every application deployment, it will be circumvented.

The cost of a flat network during a breach is measured in lateral movement scope. In a flat network where workstations can communicate directly with servers, a single compromised workstation gives an attacker SMB access to every other workstation in the same subnet, access to file servers and database servers on the same broadcast domain, and the ability to scan for and access domain controllers, backup infrastructure, and administrative management systems without traversing a single firewall rule. The average ransomware operator reaches domain administrator privileges within four hours of initial access in a flat enterprise network, at which point recovery requires rebuilding the entire environment.

To design effective segmentation, you need to understand the specific techniques attackers use to move laterally in flat enterprise networks. The techniques are well-documented in MITRE ATT&CK and are not particularly sophisticated in most ransomware incidents because sophistication is unnecessary when there are no internal network controls.

The most common lateral movement sequence in a flat enterprise network follows a predictable pattern. After gaining initial access through a phishing email or exploited internet-facing service, the attacker runs discovery commands from the compromised host: net view, arp -a, and nmap or similar tools to enumerate hosts on the local subnet. Because workstations can communicate with workstations directly, the attacker can attempt SMB authentication against every discovered host using credentials harvested from the initially compromised system. If local administrator passwords are shared across workstations (a configuration still common in environments that predate Microsoft LAPS), a single credential gives access to every workstation on the subnet.

From any compromised workstation, the attacker can access file shares on servers in the same broadcast domain because there are no firewall rules blocking SMB traffic from workstations to servers. Discovery of a domain controller address, which is trivially accomplished via DNS or LDAP queries, allows direct network access to Active Directory services. Kerberoasting, AS-REP roasting, and LDAP enumeration all work from any host that can reach a domain controller on port 389 and 88, which in a flat network is every workstation.

Backup infrastructure is consistently targeted in ransomware incidents because destroying backups eliminates the recovery option. In a flat network, backup servers are typically reachable from any workstation. An attacker with domain administrator credentials can connect to the backup server, delete the backup catalog, and begin encrypting the backup data before the primary encryption sweep starts. The segmentation controls that prevent this are straightforward: workstations should not be able to reach backup servers on any port, and backup servers should communicate only with specific server subnets through tightly controlled rules.

The phased approach to segmentation starts with the assets where a breach would be most catastrophic, not with a comprehensive VLAN redesign. This is the key departure from traditional network redesign projects that attempt to segment everything simultaneously and frequently stall. By identifying the five to ten assets or asset classes that represent the highest breach impact and isolating those first, you deliver measurable security value within the first 90 days while the longer-term segmentation project continues.

The first priority tier for isolation includes domain controllers and Active Directory infrastructure, backup servers and backup management consoles, privileged access workstations (PAWs) and jump servers used for administrative access, and financial systems or systems containing payment card data or regulated data. These assets should be isolated into dedicated segments with deny-all default firewall rules and specific permit rules only for the protocols and source addresses required for their operation. Domain controllers, for example, need inbound Kerberos (88), LDAP (389), LDAPS (636), DNS (53), and RPC ports from other domain controllers and from servers that need to authenticate. They do not need inbound SMB from workstations. Workstations authenticate to domain controllers through Kerberos and LDAP; they do not need SMB or RPC access to DC addresses, and those connections should be blocked.

The second priority tier covers server-to-server segmentation: separating the server network from the workstation network to eliminate the most common lateral movement path. A single firewall rule permitting workstations to communicate with servers only on specific application ports, with a deny-all default for all other traffic, blocks SMB, RPC, WMI, and other administrative protocols from workstations to servers. This single control eliminates the most damaging lateral movement vector in most flat enterprise networks.

OT and ICS environments represent a specific high-priority isolation case. Industrial control systems, SCADA servers, and engineering workstations running industrial protocols should be isolated from the corporate IT network on a fully separate segment with only specific, documented connections permitted through a dedicated industrial demilitarized zone. The consequence of ransomware reaching OT networks is operational disruption that extends well beyond data loss, and the latency sensitivity and legacy protocol requirements of industrial systems make firewall rule design more complex but no less necessary.

VLAN design for security segmentation follows different principles than VLAN design for network performance. Performance-driven VLAN design organizes broadcast domains by physical location or network capacity planning. Security-driven VLAN design organizes them by security zone: the grouping criterion is the trust level and communication requirements of the systems in the segment, not their physical location or organizational ownership.

The fundamental VLAN architecture for a segmented enterprise network consists of a workstation VLAN, a server VLAN, an infrastructure VLAN (domain controllers, DNS, DHCP), a management VLAN (out-of-band management interfaces, iDRAC, iLO, IPMI), a DMZ VLAN (internet-facing services), a backup VLAN, and a privileged access VLAN for administrative workstations. Each VLAN is a separate Layer 3 subnet. Communication between VLANs is controlled by a firewall or Layer 3 routing device with access control lists.

The choice between a Layer 3 switch with ACLs and a dedicated firewall for inter-VLAN routing has direct security implications. Layer 3 switches route traffic between VLANs at wire speed using hardware-based ACLs, but they lack the stateful inspection, application-layer visibility, and logging granularity of a dedicated firewall. For east-west traffic between the workstation VLAN and server VLAN in a large environment, a Layer 3 switch with ACLs provides a workable baseline that can be implemented quickly. For traffic to and from high-value segments like the backup VLAN, privileged access VLAN, and infrastructure VLAN, a dedicated firewall provides the stateful inspection, detailed logging, and application-aware rules that the security value of those segments justifies.

Firewall rule design for east-west traffic differs from perimeter firewall design in several important ways. East-west rules must account for application dependency flows that are not externally visible: a database server that needs to connect to an LDAP server for authentication, a backup agent that needs to connect from servers to the backup server, and monitoring systems that need to poll all servers via SNMP. These flows must be explicitly permitted, which requires application dependency mapping before you implement deny-all defaults.

The most common failure mode in network segmentation projects is cutting legitimate application traffic when firewall rules go live. An application that has been working for five years by communicating freely across the flat network will break immediately when inter-VLAN rules are applied, generating an incident that creates organizational pressure to roll back the segmentation change. Preventing this failure requires application dependency mapping: documenting every network flow that legitimate applications require before the firewall rules are implemented.

The most practical approach to application dependency mapping in a flat network uses network flow data. If your network devices export NetFlow, sFlow, or IPFIX data, use a flow analysis tool to capture 30 to 60 days of traffic and identify every source-destination-port combination that is in active use. This produces the raw material for firewall rule design: every flow that appears in the flow data with sufficient frequency to represent a legitimate application dependency becomes a candidate permit rule in the segmentation policy. Flows that appear in the data but are not accounted for by any known application are candidates for investigation before segmentation is implemented.

For environments without flow data, network tap or SPAN port packet capture can generate equivalent information, though the volume of raw packets requires filtering to extract useful flow summaries. Commercial tools for application dependency mapping, including those built into VMware NSX, Illumio, and Guardicore, provide automated flow analysis with application-layer identification that makes the mapping process faster and more accurate than raw flow data analysis.

The application dependency map should be validated with application owners before firewall rules are implemented. Schedule a review with each team responsible for a critical application and confirm that the flows identified in the traffic data match their understanding of how the application communicates. This validation step frequently surfaces undocumented dependencies that would have caused outages if missed: backup agents, monitoring probes, scheduled reporting jobs, and legacy integration points that communicate on non-standard ports and are not documented anywhere.

When network-level VLAN segmentation is not yet deployed and the timeline to deployment is months away, host-based firewalls provide immediate workstation-to-workstation segmentation that can be implemented in days. Windows Firewall with Advanced Security (WFAS), managed via Group Policy or Microsoft Endpoint Configuration Manager, can enforce rules that block inbound SMB, RPC, and WMI connections between workstations before any network infrastructure change is required.

The core host-based firewall policy for workstation isolation blocks inbound connections on TCP 445 (SMB), TCP 135 and dynamic RPC ports (WMI), TCP 3389 (RDP), and TCP 5985-5986 (WinRM) from all source addresses except defined administrative subnets. This policy does not prevent workstations from communicating with servers in the server subnet, but it prevents direct workstation-to-workstation lateral movement over the administrative protocols that ransomware operators rely on. Applying this policy via Group Policy to the Workstations OU implements it across the entire workstation fleet within one Group Policy refresh cycle.

The operational risk of host-based firewall policy is breaking legitimate software that communicates between workstations. Peer-to-peer collaboration tools, printer sharing, and some legacy applications communicate directly between workstations and will break when SMB inbound is blocked. Audit mode allows you to log what the policy would block before enforcing it: set the WFAS profile to log dropped packets for 72 hours before switching from audit to enforce, and review the log for unexpected legitimate flows. The logging output feeds back into the application dependency mapping process and ensures the host-based policy is scoped correctly before enforcement.

Host-based micro-segmentation also covers server-to-server lateral movement, which VLAN-based segmentation alone does not address if all servers are in the same VLAN. A web server, an application server, and a database server in the same server VLAN can communicate freely at the network level. Host-based firewall rules on the database server that only permit inbound TCP 1433 (SQL Server) or TCP 5432 (PostgreSQL) from specific application server IP addresses, and deny all other inbound traffic, implement micro-segmentation at the server tier without requiring separate VLANs for each application.

Segmentation limits lateral movement but does not eliminate it. Attackers who compromise a privileged account or find a permitted firewall rule they can abuse will still move between segments. East-west network detection using a Network Detection and Response (NDR) platform provides visibility into inter-segment traffic that perimeter firewalls and perimeter-focused IDS cannot see.

NDR sensors placed at inter-VLAN chokepoints or aggregated via SPAN ports on core switches see the full traffic flow between segments and can detect behavioral anomalies: a workstation that has never previously connected to a domain controller suddenly making LDAP queries, a server in the application tier connecting to the backup server using administrative protocols it has never used before, or lateral movement via Kerberos ticket abuse that looks like normal authentication traffic but follows patterns inconsistent with that account's historical behavior. Commercial NDR platforms including Darktrace, ExtraHop, and Vectra AI use unsupervised machine learning baselines that make these behavioral anomalies detectable without requiring manual rule writing for every lateral movement technique.

For OT and ICS environments, the segmentation architecture follows the Purdue model as a reference framework, though modern ICS security acknowledges that the Purdue model's strict hierarchical segmentation is frequently not achievable in existing environments. The practical objective is establishing a defensible boundary between Level 2 (supervisory control systems, HMI workstations) and Level 3 (manufacturing operations management) on one side, and the corporate IT network on the other. This boundary should be enforced by a dedicated industrial firewall with specific permit rules for the protocols and data flows required for operations, with all other traffic denied by default. Industrial-specific protocols including Modbus, DNP3, EtherNet/IP, and OPC-UA should be inspected using firewalls capable of deep packet inspection for those protocols rather than treated as opaque TCP flows.