Microsegmentation in Cloud and SDN

Microsegmentation is a security technique that divides a network or cloud environment into isolated segments at the individual workload or virtual machine (VM) level, rather than at the traditional subnet or VLAN level. In a traditional network, once an attacker compromises a host on a subnet, they can often scan and pivot to other hosts on the same subnet using ARP spoofing or simple IP reconnaissance. Microsegmentation eliminates this by enforcing firewall rules per workload, effectively creating a micro-perimeter around each resource. For SY0-701, you must understand that microsegmentation is a core implementation of the zero-trust model—never trust, always verify—applied to network traffic.

In an SDN environment, a centralized controller manages the forwarding behavior of virtual switches. When a VM sends a packet, the virtual switch consults the controller or a local flow table to determine if the packet is allowed. The rules are based on five-tuple information (source IP, destination IP, source port, destination port, protocol) but can also include identity attributes like user ID, VM name, or security group tag. For example, in VMware NSX, a distributed firewall (DFW) is installed as a kernel module on each hypervisor. When a packet leaves a VM's virtual NIC, the DFW intercepts it and checks against a rule set that is synchronized from the NSX Manager. If the packet matches an allow rule, it is forwarded; otherwise, it is dropped. The key is that this check happens at the source hypervisor, not at a central firewall, which eliminates bottlenecks and allows for line-rate filtering.

Attackers often exploit flat networks by performing lateral movement after an initial breach. For example, the NotPetya worm (2017) spread via EternalBlue (MS17-010) and then used WMI and PsExec to move laterally within the same subnet. Microsegmentation would have stopped this because even if one VM was compromised, it could not initiate SMB connections (port 445) to other VMs unless explicitly allowed. Defenders deploy microsegmentation by first mapping all application dependencies—which services talk to which—using tools like VMware vRealize Network Insight or Microsoft Azure Network Watcher. Then, they create allow rules that mirror these dependencies and deny all other traffic. A common approach is to use a 'default deny' rule at the end of the policy. In NSX, you can enable 'micro-segmentation' by creating a distributed firewall rule that blocks all traffic except specific flows.

In AWS, you might create a security group for a web tier using the AWS CLI:

aws ec2 create-security-group --group-name WebSG --description "Web tier security group" --vpc-id vpc-12345
aws ec2 authorize-security-group-ingress --group-id sg-12345 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-12345 --protocol tcp --port 443 --cidr 0.0.0.0/0

For the app tier, you would create an AppSG that only allows traffic from WebSG:

aws ec2 authorize-security-group-ingress --group-id sg-67890 --protocol tcp --port 8080 --source-group sg-12345

In VMware NSX, a distributed firewall rule might look like this in the API or UI: Source: Web-VM, Destination: App-VM, Service: HTTP, Action: Allow. The rule is pushed to all ESXi hosts via the NSX Manager.

Microsegmentation primarily addresses lateral movement (also called east-west traffic). It also helps contain VM escape attacks—if a hypervisor is compromised, microsegmentation limits the blast radius. Additionally, it reduces the attack surface for internal reconnaissance (e.g., port scanning) because each VM only sees traffic it is allowed to receive.

Scenario 1: Healthcare Organization with Cloud Migration A hospital migrates its patient records system to AWS. The security engineer creates separate security groups for the web servers, application servers, and database servers. The web SG allows HTTPS from the internet, the app SG allows HTTP from the web SG, and the DB SG allows MySQL (TCP 3306) from the app SG. All other traffic is denied by default because security groups have an implicit deny. One day, a vulnerability in the web application allows an attacker to execute arbitrary code. The attacker tries to connect directly to the database server on port 3306, but the DB SG only allows traffic from the app SG. The attacker's source IP is not in the app SG, so the connection is dropped. The attacker then tries to scan other subnets, but since no outbound rules allow scanning, the packets are dropped. The security team sees the denied traffic in VPC Flow Logs and triggers an incident response. The correct response is to isolate the compromised web instance, patch the application, and verify that no lateral movement occurred. A common mistake is to assume that because the web server is compromised, the database is also compromised—but microsegmentation prevented that.

Scenario 2: Enterprise SDN Deployment with NSX A financial company uses VMware NSX to microsegment its data center. The security team creates security groups for 'Trading-Apps' and 'Settlement-DB'. A distributed firewall rule allows Trading-Apps to talk to Settlement-DB on TCP 1433 (MSSQL). All other traffic is blocked. An analyst notices that a server in the Trading-Apps group is sending ICMP echo requests to servers in the HR group. The distributed firewall drops these packets because no rule allows ICMP between those groups. The analyst sees the dropped packets in the NSX logs and investigates the trading server. It turns out the server was infected with a worm that tried to propagate via ICMP. The microsegmentation contained the worm to the Trading-Apps group. The correct response is to quarantine the infected VM, analyze the worm, and update the policy if needed. A common mistake is to create overly broad rules like 'allow all traffic between groups' to avoid troubleshooting, which would defeat the purpose.

Scenario 3: Kubernetes Environment A tech startup runs its microservices on Kubernetes. They implement network policies to microsegment pods. The frontend pod has a label 'tier: frontend' and the backend pod has 'tier: backend'. A network policy allows ingress to backend only from frontend on TCP 8080. An attacker compromises a frontend pod via a vulnerable library. The attacker tries to access a database pod directly, but the database pod's network policy only allows ingress from backend pods. The connection is blocked. The attacker then tries to scan the cluster, but Kubernetes network policies deny all traffic not explicitly allowed. The security team uses kubectl to view network policies and checks the logs of the CNI plugin (e.g., Calico) for denied packets. The correct response is to isolate the compromised pod and patch the vulnerability. A common mistake is to rely on Kubernetes default 'allow all' policy, which would have allowed the attack.