Network Microsegmentation: Controlling East-West Traffic to Contain Lateral Movement
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Lateral movement is the defining characteristic of advanced attacks: after initial access through a phishing email, exposed RDP port, or vulnerable web application, the attacker moves horizontally through the network until reaching the target -- domain controller, backup server, financial database. Flat networks where all workloads can freely communicate east-west enable this movement. Microsegmentation applies fine-grained, workload-level policies to east-west traffic, creating containment boundaries that limit how far an attacker can move after initial compromise. This guide covers the implementation approaches available at different layers, from cloud security groups and Kubernetes network policies to host-based firewalls and SDN platforms.
Threat Model: Why East-West Traffic Matters
Most network security investment focuses on north-south traffic -- controlling what enters and exits the network perimeter. East-west controls are often absent or coarse, because historically internal network traffic was assumed to be trusted. This assumption fails in modern environments where a single compromised endpoint inside the perimeter can reach every other workload on the network.
Lateral movement after initial compromise
A threat actor who compromises a developer workstation via phishing can use that foothold to reach internal services inaccessible from the internet -- Active Directory for credential harvesting, code repositories for supply chain access, or database servers. In a flat network, the only barrier is the attacker's knowledge of what is available, not network controls.
Ransomware propagation via SMB and RDP
Ransomware families including LockBit and BlackCat use SMB lateral movement (EternalBlue, credential relay via NTLM) and RDP brute-force to spread from the initial infected host to every reachable Windows workstation and server. A flat network with unrestricted SMB and RDP between workstations enables network-wide encryption within hours.
Credential relay and NTLM attacks
Attacks like NTLM relay and credential coercion (PrinterBug, PetitPotam) require network reachability between the attacker's host and the target service. Blocking SMB (445), HTTP (80/443 for relay), and LDAP (389/636) flows between workstations and between workstations and domain controllers removes the network-layer precondition for these attacks.
Traffic Baseline Mapping Before Enforcement
Applying microsegmentation to a running environment without first understanding what traffic is legitimate will break applications. Traffic baseline mapping identifies every east-west flow currently in use so that allow rules can be built before deny-by-default is enforced.
AWS VPC Flow Logs analysis
Enable VPC Flow Logs on all VPCs with destination to CloudWatch Logs or S3. Query for accepted traffic between internal instances: use Athena to query the flow log table for traffic where srcaddr and dstaddr are both RFC1918 addresses and action=ACCEPT. Group by srcaddr, dstaddr, dstport to build a communication matrix. Run for 2-4 weeks to capture periodic and batch flows not present in a short sample.
NetFlow and sFlow collection for on-premises
Configure NetFlow export on core switches and routers to a NetFlow collector (ntopng, ElasticFlow, Cisco Stealthwatch). Analyze top talkers and unique source-destination pairs for each protocol. Focus on high-risk protocols: SMB (445), RDP (3389), WMI (135+dynamic), and database ports (1433, 3306, 5432). Document legitimate flows and question any workstation-to-workstation SMB or RDP flow.
VMware NSX Traceflow and firewall simulation
NSX Traceflow simulates traffic flows between endpoints without sending actual packets, showing which policy rules would apply. Use it to verify that planned microsegmentation policies will not break documented legitimate flows before enforcement. NSX's East-West Security dashboard also shows flow volumes between security groups.
Build a communication matrix
Organize baseline findings into a communication matrix: rows are source workload groups, columns are destination workload groups, cells contain permitted ports. This matrix becomes the specification for segmentation policy. Any cell not explicitly populated gets a deny-by-default rule. Review the matrix with application owners to confirm documented flows are complete before moving to enforcement.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Cloud-Native Microsegmentation: AWS, Azure, and GCP
Cloud security groups, NSGs, and VPC firewall rules provide native workload-level microsegmentation that does not require additional tooling. Their advantage is that policies are defined in infrastructure-as-code and are enforced at the hypervisor level, not on the workload itself.
AWS Security Groups: per-ENI stateful firewalls
Design security groups around workload roles (web-tier, app-tier, db-tier) rather than around individual instances. Write inbound rules that reference other security group IDs: allow port 5432 from the app-tier security group only. Remove all 0.0.0.0/0 inbound rules from internal security groups. Use separate security groups for each application tier and never share security groups across applications with different trust requirements.
Azure NSGs at subnet and NIC level
Azure NSGs can be applied at both the subnet level (affecting all resources in the subnet) and the NIC level (affecting a specific VM). Use subnet-level NSGs for broad zone-to-zone controls and NIC-level NSGs for individual VM exceptions. Implement Application Security Groups (ASGs) to group VMs by role and write NSG rules that reference ASG names instead of IPs -- this is Azure's equivalent to security group ID references in AWS.
GCP VPC Firewall Rules: priority-based, tag-based
GCP VPC firewall rules are stateful and support network tag-based and service-account-based targets. Apply network tags to VMs by role (web, app, db) and write firewall rules that target those tags. Set the default rule at the lowest priority (65534) to deny all. Create an ingress rule for each legitimate flow with a higher priority. Use service-account targets for service-to-service flows that should survive VM replacement.
Kubernetes Network Policies
Kubernetes clusters are a dense concentration of microservices that often communicate freely by default. Kubernetes NetworkPolicy resources provide pod-level ingress and egress controls that are enforced by the CNI plugin (Calico, Cilium, Weave Net).
Deny-all default network policy per namespace
Apply a deny-all NetworkPolicy to each namespace: spec with podSelector: {} (matches all pods) and policyTypes: [Ingress, Egress] with no ingress or egress rules. This creates a baseline of zero connectivity that all subsequent policies add exceptions to. Without a deny-all baseline, any pod not explicitly targeted by a network policy has full network access.
Namespace isolation policies
Prevent cross-namespace communication unless explicitly required by creating namespace-scoped network policies that block ingress from other namespaces by default. Allow only specific namespace-to-namespace flows using namespaceSelector in the ingress from rules. This ensures that a compromised pod in the dev namespace cannot reach services in the production namespace.
Pod selector-based ingress and egress rules
Write network policies that match source and destination pods by label selector: allow ingress port 8080 from pods with label app=frontend to pods with label app=backend. This is more durable than IP-based rules because pod IPs change on reschedule. Ensure all pods have appropriate role labels for policy targeting.
Egress DNS and internet restrictions
Restrict egress traffic to only the destinations pods legitimately need. Allow egress to kube-dns (port 53 UDP/TCP to the CoreDNS service) and specific external endpoints. Block all other egress by default. This prevents a compromised pod from performing DNS-based data exfiltration or reaching attacker-controlled infrastructure for C2 beaconing.
Monitoring for Policy Violations and Lateral Movement Detection
A microsegmented network generates detectable evidence when lateral movement is attempted -- policy violation events that correspond to connection attempts hitting a deny rule. These events require collection and alerting to be useful.
Alert on VPC Flow Log REJECT events
Create CloudWatch Metric Filters for VPC Flow Log entries with action=REJECT originating from internal source IPs targeting high-value destination ports (445, 3389, 1433, 22). A spike in internal-to-internal REJECT events is a strong indicator of lateral movement scanning. Use CloudWatch Alarms or route rejected flow events to a SIEM for correlation with other indicators.
Windows Firewall audit policy drop logging
On Windows workstations and servers, enable Windows Firewall Audit Packet Drop (Event ID 5157) via Group Policy: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy > Object Access > Audit Filtering Platform Connection. Forward 5157 events to your SIEM and alert on unusual drop patterns -- particularly SMB (445) and RDP (3389) drops from multiple source IPs to the same destination.
Kubernetes network policy violation logging
Calico and Cilium can log packets that are dropped by network policy. In Calico, enable deny action logging in GlobalNetworkPolicy with log: true on deny rules. In Cilium, enable policy audit mode or hubble flow logging. Collect these logs via the node's syslog or Hubble UI and alert on any pod that generates more than a threshold of policy drop events, which may indicate scanning or exploit attempts.
The bottom line
Microsegmentation is most valuable when applied to the highest-risk flows first: workstation-to-workstation SMB and RDP (ransomware propagation), direct workstation-to-DC communication (credential relay attacks), and unrestricted access to database servers from all application tiers. Start with traffic baseline mapping to understand current flows, then apply deny-by-default with explicit allows in audit mode before enforcing. Cloud security groups and Kubernetes NetworkPolicies are the easiest starting points in modern environments because they are native, policy-as-code, and do not require additional tools. Monitor for policy violation events -- these are lateral movement indicators that a flat network simply cannot generate.
Frequently asked questions
Where should I start with microsegmentation in a legacy flat network?
Start with traffic baseline mapping using NetFlow, VPC Flow Logs, or network packet capture to understand what is actually communicating with what. Build a communication matrix: which servers talk to which other servers, on which ports. Identify your highest-value assets (Active Directory, databases, backup systems) and segment those first with deny-by-default policies and explicit allow rules only for documented flows. Attempting to microsegment everything at once in a flat network without a traffic baseline leads to broken applications and rollback.
What is the difference between VLAN segmentation and microsegmentation?
VLAN segmentation groups workloads into broadcast domains and routes traffic between VLANs through a firewall or router where ACLs can be applied. It provides coarse segmentation at the subnet level. Microsegmentation applies policies at the individual workload level -- each VM, container, or process can have independent access controls regardless of which subnet or VLAN it is on. VLAN segmentation protects at the network zone level; microsegmentation protects at the individual workload level and can prevent a compromised web server from attacking a second web server in the same VLAN.
How do AWS Security Groups implement microsegmentation?
AWS Security Groups are stateful, per-ENI (Elastic Network Interface) firewalls. Each EC2 instance has one or more security groups that define which inbound and outbound traffic is permitted. Because security group rules can reference other security group IDs rather than IP ranges, you can define rules like 'allow inbound port 5432 from instances in the database-client security group' rather than IP-based rules. This provides workload-identity-based microsegmentation: a new instance is automatically granted or denied access based on its security group membership, regardless of its IP address.
What is a deny-all default Kubernetes network policy and why is it important?
By default, Kubernetes allows all pod-to-pod traffic within a cluster with no restrictions. A deny-all default NetworkPolicy creates a baseline of zero trust: deny all ingress and egress traffic to pods in a namespace by default, then create explicit allow policies for only the connections the application requires. Without a deny-all default, a compromised pod can reach any other pod in the cluster on any port, enabling lateral movement to other applications running in the same cluster.
How does identity-based microsegmentation differ from IP-based segmentation?
IP-based segmentation rules (allow port 443 from 10.0.1.0/24) break when workloads are rescheduled, when cloud instances are replaced, or when IP addresses change. Identity-based microsegmentation uses workload identity attributes -- security group membership, pod labels, service account, or cryptographic identity (SPIFFE/SPIRE) -- to define policies that remain valid regardless of IP address changes. A policy that says 'web tier pods can reach database tier pods on port 5432' survives pod rescheduling and auto-scaling without rule updates.
What is the recommended rollout strategy for microsegmentation to avoid breaking applications?
Use a three-phase approach. Phase 1 (observe): deploy segmentation in audit/log mode only -- NSX distributed firewall in log mode, Windows Firewall in audit mode, or Kubernetes network policies with only egress logging. Collect 2-4 weeks of data to identify all actual communication flows. Phase 2 (enforce with exceptions): enable enforcement with deny-by-default and allow rules for observed flows. Collect exception requests from application owners for flows that are legitimate but were not in the baseline. Phase 3 (tighten): remove emergency exceptions that have been resolved and tighten allow rules to minimum required ports.
How should I detect lateral movement in a microsegmented network?
In a properly microsegmented network, lateral movement generates policy violation events -- connection attempts that hit a deny rule. Configure alerts on: security group rejected flow logs in AWS (Flow Logs with action=REJECT on unexpected source-destination pairs), Windows Firewall audit drop events (Event ID 5157), NSX policy violation alerts, and Kubernetes network policy drop events (if using Calico or Cilium, which can log policy drops). A high volume of policy violations from a single source often indicates a compromised workload attempting to move laterally.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.