# Microsegmentation: — Stopping Lateral Movement Before It Starts Source: https://ai.techclick.in/blog_microsegmentation_zero_trust Markdown: https://ai.techclick.in/blog_microsegmentation_zero_trust.md Publisher: Techclick Infosec Pvt Ltd Microsegmentation for L1/L2 engineers and the NIST SP 800-207 / CCNP Security exam: why flat networks let attackers move laterally, what microsegmentation is, how it is enforced (agent, agentless, identity), and a safe monitor-then-block rollout. Microsegmentation: — Stopping Lateral Movement Before It Starts student learning map A visual study map for Microsegmentation: — Stopping Lateral Movement Before It Starts showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsegmentation: — Stopping Lateral Movement... Zero Trust · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The flat-network problem — why... 4. Practice ② What microsegmentation is — a... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers first hear "segmentation" and think "we already have VLANs and a firewall, so we're segmented." They picture the firewall at the edge as the thing that keeps attackers out. Wrong — and it's the exact gap attackers love. Your edge firewall guards north-south (in/out of the data centre), but inside, a VLAN is one big trusted room: every host can talk to every other host. That east-west traffic is unguarded, which is why Verizon's 2025 DBIR and CrowdStrike both show the majority of real breaches involve lateral movement . Microsegmentation is the opposite move: shrink the trust zone to a single workload and check every internal connection by identity, so one phished laptop can't become a whole-data-centre ransomware event. ## ① The flat-network problem — why one breach becomes a hundred Picture Sneha, an L1 SOC analyst at Infosys . At 09:04 an employee in the sales team clicks a phishing link and an attacker lands on that laptop ( 10.20.5.21 ). Annoying, but contained — right? Not on a flat network . The laptop sits in the same broad zone as the file server, the HR app and — three hops away — the customer database. Nothing inside checks whether sales-laptop should be opening SMB to a server. By 09:30 the attacker has read credentials off the file server and is querying the database. That walk from host to host is called lateral movement , and the traffic it rides on is east-west traffic — server-to-server, inside the perimeter. Your edge firewall never sees it, because it never leaves the building. This is the single most important picture in the whole lesson: the firewall guards the door; the attacker is already in the corridor. How common is this? Recent breach data is blunt about it. Verizon's 2025 DBIR and multiple 2025–2026 reports put lateral movement in roughly 60% of successful breaches ; CrowdStrike's 2026 Global Threat Report measured the average eCrime breakout time at about 29 minutes — meaning you have under half an hour from the first click before they're on a second machine. Flat networks turn that 29 minutes into a free run. 👉 So far: a flat LAN is one trust zone, so the attacker walks east-west to the crown jewels in minutes. Next: why VLANs and the firewall — macro-segmentation — are too coarse to stop it. "But we have VLANs!" Sure — that's macro-segmentation , and it helps a little: it separates big zones (guest Wi-Fi from servers, DMZ from internal). But a typical server VLAN holds dozens of unrelated workloads — web, app, database, backup, HR — and inside that VLAN everything can talk to everything. The firewall only sits between zones, on the north-south path, not between two servers in the same zone . So macro-segmentation is a few big rooms with no internal doors. The attacker who lands in the server room reaches every server in it. Figure 1 — Flat LAN vs microsegmented — same breach, very different blast radius Two columns for the same data centre. Left, a flat network: web, app, database and HR servers all sit in one VLAN, so an attacker who phishes the laptop moves host to host freely east-west until they reach the crown-jewel database. Right, a microsegmented network: each workload is ring-fenced with an allow-list, so the same phished laptop can only reach what its policy permits and the lateral move to the database is denied. Red marks the attacker and the open lateral path; green marks the contained, allowed paths; amber marks the policy decision point. Flat LAN vs microsegmented — same breach, very different blast radius Flat network — one trust zone phished laptop web srv app srv HR / file srv DB — crown jewels 10.20.0.50 - no internal door → attacker walks host→host east-west is wide open (RDP/SMB/445) 1 laptop phished = whole DC at risk Microsegmented — door on every workload phished laptop web srv app srv DB — ring-fenced only app srv :5432 ✗ ✗ allow :5432 allow-list per tier: web→app→db only everything else default-denied breach stops at one segment untrusted / attacker trusted / inspected policy / decision key insight allowed Read both columns for the same data centre. Left (red): one trust zone, so the phished laptop walks host→host to the DB. Right (green): a door on every workload, so the same breach stops at one segment. ### Why the flat network keeps losing — four tap cards Tap each card — these are the four facts every interviewer and every breach post-mortem keeps coming back to. 🚪 One trust zone tap to flip Inside a VLAN, every host trusts every host. So: the firewall at the edge never sees the attacker's east-west moves. 🏃 29-minute breakout tap to flip CrowdStrike clocks average breakout at ~29 min. So: you can't out-click an attacker who's already inside a flat LAN. 🦠 Ransomware loves it tap to flip ~60% of breaches use lateral movement. So: a flat network turns one infected host into an enterprise-wide encryption event. 🧱 VLANs are too coarse tap to flip A server VLAN holds dozens of unrelated apps. So: macro-segmentation leaves the whole server room open inside. Daily-life analogy — the society gate-pass register A flat network is a housing society with a guard at the main gate and nothing else. Once a visitor clears the gate, they can wander into any flat — the watchman never checks again. Microsegmentation is the same society where every flat also has its own lock , and the register at each door only lets in people that flat actually expects (the cook, the maid, family). One stranger who talks their way past the main gate still can't open flat 3B's door. The gate is north-south; the per-flat lock is east-west. Pause & Predict Predict: a company has a perfectly configured perimeter firewall and modern antivirus, but a flat internal network. Why can a single phished laptop still lead to the whole data centre being ransomwared? Type your guess. Reveal answer Answer: Because both controls miss the east-west path. The perimeter firewall only inspects north-south traffic (in/out of the data centre), so it never sees server-to-server moves. Antivirus may catch the malware on one host, but if it doesn't, nothing internal stops the attacker reaching the next host — there's no policy between workloads. The breach spreads laterally across the flat zone until it hits the database. That gap is exactly what microsegmentation closes. Quick check · Q1 of 10 Rahul at TCS asks: "We have VLANs and a next-gen firewall at the edge. Why is our internal network still considered flat from an attacker's point of view?" a) Because the firewall only inspects east-west traffic, never north-south b) Because inside a VLAN every host can reach every other host, and the firewall only sits between zones, not between two servers in the same zone c) Because VLANs encrypt all internal traffic by default d) Because antivirus already blocks all lateral movement Correct: b. A VLAN is one trust zone: hosts inside it talk freely, and the edge firewall guards north-south (between zones), not server-to-server inside a zone. So the interior is effectively flat. The firewall inspects north-south, not east-west (option 1 is backwards); VLANs don't encrypt traffic; and antivirus is host-level detection, not a network policy that stops lateral movement. ## ② What microsegmentation is — a locked door on every workload Here is the clean definition to memorise. Microsegmentation is security policy pushed all the way down to the individual workload , governing east-west traffic by identity or label — not by IP address or subnet. Instead of "this whole VLAN trusts itself," you say "the App servers of the Payments app may open TCP 5432 to the DB servers of the Payments app, and nothing else may." Every other connection is denied by default. Two words do the heavy lifting. First, by identity/label : you tag each workload with what it is (its role, app, environment, location) and write rules between tags. If the database's IP changes or it moves to the cloud, the rule still holds because it was never about the IP. Second, allow-list (default-deny) : you list only what's allowed, and everything unlisted is blocked. That flips the old default — a flat network is default- allow inside; microsegmentation is default- deny inside. 👉 So far: microsegmentation = per-workload, identity-based, default-deny. Next: the classic three-tier allow-list that makes it concrete. The textbook example is a three-tier app : a web tier, an app tier, and a database tier. The only east-west conversations that should ever happen are web → app (e.g. 443/8080) and app → db (e.g. 5432 for Postgres, 3306 for MySQL). A web server should never talk straight to the database, and two web servers shouldn't talk to each other at all. Microsegmentation writes exactly those two allow rules and denies the rest — so even if the web server is popped, the attacker can't jump the tier to the DB. This is why microsegmentation is the enforcement arm of Zero Trust. NIST SP 800-207 says to shrink implicit trust zones and move the policy decision as close to the resource as possible — assume the network is already breached, and check every request. "Same subnet" is exactly the implicit trust NIST tells you to delete. Microsegmentation is how you delete it at the workload level. Figure 2 — One east-west connection, checked by identity at the workload A five-step policy-evaluation flow for one east-west connection. Step 1 the app server tries to open a connection to the database on TCP 5432. Step 2 the enforcement point at the database workload — a host agent, hypervisor firewall or cloud security group — intercepts it before it reaches the kernel. Step 3 it looks up the connection by identity and label, not by IP or subnet: source label Role equals App, Application equals Payments. Step 4 the allow-list is checked; a matching rule says App to DB on 5432 is allowed, everything else is denied by default. Step 5 the allowed flow is logged and forwarded while an unlabelled or wrong-role source is dropped. Amber marks the decision point, green the allowed path, red the denied lateral attempt. One east-west connection, checked by identity at the workload App server Role=App · 10.20.0.30 opens TCP 5432 Enforcement point host agent / hypervisor FW / cloud security group at the DB workload Database Role=DB · 10.20.0.50 crown jewels 1· connect 5432 2· decide by IDENTITY, not subnet ✓ src Role=App · App=Payments → 5432 ALLOW ✗ src Role=Laptop / unlabelled → DENY ✗ src Role=Web (skips the tier) → DENY 3· no matching allow rule = default-deny 4· allowed → forward + log 5· Same subnet ≠ trusted. The label decides — that is the Zero Trust move. untrusted / attacker trusted / inspected policy / decision key insight allowed Follow the numbered flow: the App server's connection to the DB is intercepted at the workload, matched by LABEL not IP, allowed only if a rule exists, then logged. An unlabelled or wrong-role source is denied. A microsegmentation allow-list, written by identity (vendor-neutral policy) # Payments app — east-west allow-list (everything else default-deny) allow: - from: { role: web, app: payments } to: { role: app, app: payments } ports: [tcp/443, tcp/8080] - from: { role: app, app: payments } to: { role: db, app: payments } ports: [tcp/5432] default: deny # web->db, laptop->db, db->internet : all blocked Expected output $ segctl policy lint payments.yaml parsed 2 allow rules, default-deny web->app tcp/443,8080 OK app->db tcp/5432 OK no shadowed rules; no any-any allow found policy OK — 2 allows cover 100% of observed legit flows Common mistake — "we put it all in one VLAN with an any-any allow at the top" Symptom: you label everything and feel segmented, but an attacker still pivots web → db freely. Cause is almost always a leftover broad rule — an any → any allow or a subnet-based rule like allow 10.20.0.0/24 → 10.20.0.0/24 sitting above your tight identity rules. On an allow-list, one broad allow re-opens the whole room. Fix: remove every subnet-wide and any-any allow, write rules tag → tag with explicit ports , and lint for shadowed/any-any rules before you enforce. Identity rules only help if nothing broader is overriding them. Arjun at Flipkart faces this Arjun, an L2 engineer, is asked to prove the new 'Payments' app can't be reached from a random server in the same subnet — only from its own app tier. Security wants evidence, not a promise. Likely cause The app and database sit in a shared server VLAN (10.20.0.0/24) with no per-workload policy, so by default any host in that subnet can open 5432 to the DB. 'Same subnet' is implicit trust — exactly what NIST SP 800-207 says to remove. Diagnosis He labels the workloads (Role + Application), maps which flows actually exist today, and writes a tag→tag allow-list: only Role=App, App=Payments may reach Role=DB, App=Payments on 5432; everything else denied. Illumio PCE > Illumination (map flows) > Workloads (apply Role/App labels) > Rulesets (write the allow rules) > set state to Test (monitor), then Enforced Fix Run the ruleset in Test/monitor first to confirm no legit flow is dropped, then move the DB workloads to the Enforced state so non-app sources hit default-deny. Verify From a non-app server in the same subnet, a connection to the DB's 5432 now times out and shows as a blocked flow in the traffic log; from an app-tier server it still succeeds — proof the policy is identity-based, not subnet-based. Quick check · Q2 of 10 Priya at Wipro defines a rule: "Role=App (app=Payments) may reach Role=DB (app=Payments) on TCP 5432; deny everything else." The DB later gets a new IP and moves to AWS. What happens to the rule? a) It breaks — rules are tied to the old IP b) It must be rewritten as a subnet rule c) It now allows any host on the new subnet d) It still works — the rule matches by identity/label, not by IP, so it follows the workload Correct: d. Identity/label-based policy is decoupled from the IP, so when the DB's address changes or it moves to the cloud, the rule still matches Role=DB, app=Payments and keeps holding. That portability is the whole point. A subnet rule would have broken on the move and would wrongly trust the whole new subnet — the opposite of microsegmentation. Pause & Predict Predict: in a strict three-tier allow-list (web→app→db only), an attacker fully compromises a web server. Why can't they read the database directly, and what is the most they can do toward it? Type your guess. Reveal answer Answer: They can't reach the DB directly because there is no web→db allow rule — that connection is default-denied at the DB workload, so the packets are dropped. The most they can do is talk to the app tier on the allowed ports (443/8080), because web→app is permitted. To reach the DB they'd now have to also compromise an app-tier server and abuse the app→db rule — two hops and far more noise, which is exactly the friction (and detection chance) microsegmentation is designed to create. ## ③ How it is enforced — agent, agentless, identity, and the build path A locked door is only as good as the lock. There are three ways to actually enforce a microsegmentation policy, and on the job you'll meet all three. The choice depends on where your workloads live . Agent-based (host). A small software agent runs on each workload and programs the host firewall (iptables, Windows Filtering Platform) from central policy. Illumio is the well-known example: its VEN enforces while the central PCE computes policy. Finest granularity, follows the workload to any cloud — but you must deploy and patch an agent, and some appliances/IoT can't run one. Agentless / network. The hypervisor or cloud platform enforces, with no agent inside the guest OS. VMware NSX does this with its Distributed Firewall (DFW) right at each VM's vnic , driven from NSX Manager using Security Groups and tags. In the cloud the same idea is an AWS Security Group or Azure NSG on the instance's interface. Nothing to install, but you're tied to that platform. Identity-based (fabric). The network itself tags traffic by identity and enforces on the tag. Cisco TrustSec assigns a Security Group Tag (SGT) via ISE, and switches enforce a SGACL matrix between tags. Policy is decoupled from IP and scales across a campus — but you need SGT-capable infrastructure and ISE. (This is the angle the CCNP Security SCOR 350-701 blueprint tests under secure network access.) Figure 3 — How microsegmentation is enforced — pick by where your workloads live A three-column comparison of microsegmentation enforcement models. Column one, agent-based: a software agent or host firewall runs on each workload, for example Illumio VEN, giving the finest granularity and working anywhere including cloud, but you must deploy and maintain an agent. Column two, agentless or network: the hypervisor or cloud platform enforces, for example VMware NSX distributed firewall at the vnic or an AWS security group, needing no agent but tied to that platform. Column three, identity-based: the network fabric tags traffic by identity, for example Cisco TrustSec security group tags, decoupling policy from IP but needing capable infrastructure. A bottom band shows the shared build path: map flows, baseline, ring-fence, then enforce in monitor-then-block. How microsegmentation is enforced — pick by where your workloads live Agent-based (host) Agent / host firewall on each workload enforces locally. e.g. Illumio VEN, host iptables, Windows Defender Firewall ✓ finest granularity (per process) ✓ follows the workload to any cloud ✗ must deploy + patch an agent ✗ no agent on appliances / IoT best: servers, hybrid + multi-cloud Agentless (network) Hypervisor or cloud platform enforces — no agent in the OS. e.g. VMware NSX DFW (vnic), AWS security group, Azure NSG ✓ nothing to install in the guest ✓ enforced at the vnic / ENI ✗ tied to that platform / cloud ✗ coarser inside one VM best: virtualised DC, single cloud Identity-based (fabric) Network tags traffic by identity; policy follows the tag, not the IP. e.g. Cisco TrustSec SGT, ISE-assigned group tags ✓ policy decoupled from IP/subnet ✓ scales across the campus fabric ✗ needs SGT-capable switches/ISE ✗ steeper design + onboarding best: Cisco campus + users + IoT Whichever model you pick, the build path is the same ① map flows → ② baseline what is normal → ③ ring-fence the app → ④ enforce in monitor-then-block untrusted / attacker trusted / inspected policy / decision key insight allowed Compare the three columns: agent-based (Illumio VEN on the host), agentless/network (NSX DFW at the vnic, or a cloud SG/NSG), identity-based (Cisco TrustSec SGT in the fabric). The bottom band is the build path they all share. 👉 So far: three enforcement models, same goal. Next: how you actually build the policy from real traffic — map, baseline, ring-fence, enforce. Whatever the model, you never write a microsegmentation policy from imagination — you build it from observed flows . The path is: map (turn on visibility and watch who really talks to whom — Illumio calls this map the Illumination view), baseline (decide which of those flows are legitimate "normal"), ring-fence (draw the allow-list around one app so only its real flows are permitted), then enforce in monitor-then-block (run the rules in a test/monitor state that logs what it would drop, fix the surprises, and only then switch to blocking). ### ▶ Watch a policy go from blind to blocking — safely Follow one app, Payments, through the four build stages. The break shows the classic disaster: skipping straight to block. Press Play for the healthy path, then Break it to see the failure. ① Map visibility ON : log every flow — web → app :443, app → db :5432, plus a backup job at 02:00 ▼ ② Baseline mark the real flows as normal; the nightly backup app→db:5432 is legit too, keep it ▼ ③ Ring-fence write allow-list: web → app 443/8080, app → db 5432; default-deny the rest ▼ ④ Enforce state = monitor → confirm zero legit drops in the log → flip to block Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Illumio PCE → Workloads → (select workload) → Edit Labels . Label first; rules between labels come next. (Recreated for clarity — your console matches this.)"> 🖥️ This is where you label a workload so policy can follow identity — Illumio PCE → Workloads → (select workload) → Edit Labels . Label first; rules between labels come next. (Recreated for clarity — your console matches this.) pce.illumio.lab · Workloads → Edit Labels 1 Workload pay-db-01 (10.20.0.50) 2 Role Database 3 Application Payments Environment Production Location Mumbai-DC1 4 Enforcement state Test (Visibility-only → monitor) Save Labels AWS CLI — the cloud version of an east-west allow rule (DB security group: only the app SG may reach 5432) aws ec2 authorize-security-group-ingress \ --group-id sg-0db5432payments \ --protocol tcp --port 5432 \ --source-group sg-0appayments \ --region ap-south-1 Expected output { "Return": true, "SecurityGroupRules": [ { "SecurityGroupRuleId": "sgr-0a1b2c3d4e5f", "GroupId": "sg-0db5432payments", "IpProtocol": "tcp", "FromPort": 5432, "ToPort": 5432, "ReferencedGroupInfo": { "GroupId": "sg-0appayments" } } ] } Prove the policy is identity-based, not just 'up' A rule existing isn't proof it works. Test it from two sources: from an allowed app-tier host, the DB's 5432 should connect; from a non-app host in the same subnet , it should time out and appear as a blocked flow in the traffic log. If the non-app host can still reach 5432, you have a broader subnet/any-any rule overriding your identity rule (see the mistake above) — hunt it down before you call the segment enforced. Quick check · Q3 of 10 Meera at HCL is rolling out microsegmentation on a busy production app. Which build order is the safe one? a) Map flows → baseline normal → ring-fence the allow-list → enforce in monitor, then block b) Block first, then watch what breaks and add allows reactively c) Write rules from the design doc and enforce immediately d) Delete the VLANs, then label workloads afterwards Correct: a. You build from observed reality: map who actually talks, baseline what's legitimate, ring-fence the tight allow-list, then run it in monitor mode to confirm nothing legit drops before you block. Block-first or design-doc-first breaks flows you never saw (like a nightly backup); deleting VLANs first removes a useful coarse layer for no reason and doesn't give you per-workload policy. Pause & Predict Predict: your shop is mostly VMware VMs in one data centre today, but you're moving half the workloads to AWS next year. Which enforcement model keeps the SAME policy working across both, and why? Type your guess. Reveal answer Answer: Agent-based (e.g. Illumio VEN). Because the agent lives on the workload and enforces from central, label-based policy, the rule 'Role=App → Role=DB:5432' follows the VM whether it runs on a VMware hypervisor on-prem or as an EC2 instance in AWS. NSX DFW only enforces on VMware's hypervisor, and AWS Security Groups only exist in AWS — each is tied to its platform — so a host agent (or a tool that abstracts both) is what gives you one consistent policy across the hybrid move. ## ④ Practical rollout — high-value first, monitor before you block You don't microsegment the whole estate on day one — that's how you break production and lose the room. The pattern every successful rollout follows: start with the single highest-value app (the crown jewels — payments, the customer DB, the domain controllers), ring-fence that first, prove it, then expand. One tight ring-fence around your most valuable app, per Illumio's own guidance, closes most of the east-west attack surface for that app with very little policy. Three rules keep the rollout from blowing up. (1) Label before you rule. Tag every workload (Role, Application, Environment, Location) so policy is about identity, not IP. (2) Use flow visibility before enforcing. Watch real traffic for days/weeks; the flows you forget are the ones that break — backup jobs, monitoring agents, AD replication, health checks. (3) Monitor-then-block, with a rollback ready. Run every new policy in a test/monitor state, read the would-block log, fix the surprises, and keep a one-click revert before you enforce. 👉 So far: high-value first, label, watch, monitor-then-block. Next: the before/after that makes the whole point, then the cheat-sheet and the exam angle. Here's the before/after in one line, because it's the slide that sells the project. Before (flat LAN): ransomware lands on one host and encrypts the data centre in hours — one breach becomes a hundred. After (microsegmented): the same ransomware lands on one host, tries to spread east-west, and hits default-deny at every neighbour — it's contained to one segment while you respond. That containment of the blast radius is the entire value proposition, and it's why microsegmentation is a named pillar of every Zero Trust model. Common mistake — enforcing on the busiest app first to 'show impact' Symptom: you pick the loud, high-traffic monolith for the pilot, flip to block, and within minutes a forgotten flow (a monitoring poll, a license check, a cross-app API call) breaks and a VP is on the phone. The project gets paused. Cause: highest traffic ≠ best first . Fix: pilot on a high- value but well-understood app with clean, mappable flows; run a long monitor window; expand only after a clean enforcement. Win trust with a boring success before you touch the monolith. Figure 4 — Microsegmentation on one glance — tiers, models, rollout, terms A nine-tile cheat sheet. Tiles cover the core idea, the three-tier web-app-db allow-list, the four Illumio labels, the three enforcement models, the segmentation scopes, the monitor-then-block rollout, the policy states, the key terms, and a one-line interview answer. Each tile has a short role line. Microsegmentation — your one-glance card Core idea policy down to one workload governs east-west by identity/label not by IP / subnet / VLAN 3-tier allow-list web → app (443/8080) app → db (5432/3306) web → db = DENIED Illumio labels (4) Role · Application Environment · Location label first, then write rules Enforcement models agent (Illumio VEN, host FW) agentless (NSX DFW, SG/NSG) identity (TrustSec SGT) Scopes (coarse→fine) env split → app ring-fence → tier (web/app/db) → per-workload / nano Rollout (safe order) 1 map flows · 2 baseline 3 ring-fence · 4 monitor 5 then block — never block-first Policy states Idle → Build (visibility) → Test (monitor) → Enforced read the log before you enforce Key terms east-west · lateral movement blast radius · ring-fence default-deny / allow-list Interview one-liner "Macro-seg guards north-south; micro-seg guards east-west per workload by identity — to kill lateral movement." Your one-card map of the whole lesson: the core idea, the three-tier allow-list, the four labels, the three enforcement models, scopes, the safe rollout order, the policy states, the key terms, and the interview one-liner. Keep it open in week one. For your certifications, this lesson sits in two blueprints at once. On the vendor-neutral side it's straight NIST SP 800-207 Zero Trust: shrink implicit trust zones, enforce per-resource, assume breach — microsegmentation is the network pillar that makes that real. On the Cisco CCNP Security (SCOR 350-701) side, segmentation and secure network access are exam domains — VLAN/VRF macro-segmentation, and identity-based microsegmentation via Cisco TrustSec + ISE with Security Group Tags. Knowing the why (lateral movement) and the how (allow-list by identity) covers both the concept questions and the TrustSec questions. Related: ZTNA Explained Next: Secure Web Gateway (SWG) Prove you own this lesson Cold, in 30 seconds: say what east-west traffic and lateral movement are; define microsegmentation (per-workload, identity-based, default-deny) and how it differs from VLAN macro-segmentation; name the three enforcement models (agent / agentless / identity) with one product each (Illumio VEN / NSX DFW or AWS SG / Cisco TrustSec); and give the safe rollout order (map → baseline → ring-fence → monitor → block). If you can do that without notes, you're ready for the NIST 800-207 and SCOR 350-701 questions on segmentation. Quick check · Q4 of 10 An interviewer asks Karthik: "In one sentence, what does microsegmentation actually buy a business that a perimeter firewall doesn't?" Best answer? a) Faster internet for branch offices b) It encrypts all internal traffic automatically c) It contains the blast radius — east-west enforcement by identity stops a single breach from spreading laterally across the data centre d) It removes the need for VLANs and firewalls entirely Correct: c. Microsegmentation's value is blast-radius containment: by enforcing per-workload, identity-based, default-deny policy on east-west traffic, one compromised host can't move laterally to the crown jewels. A perimeter firewall only guards north-south. It doesn't speed up internet, doesn't inherently encrypt traffic, and doesn't replace VLANs/firewalls — it layers on top of them (defence in depth). ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. East-west vs north-south — how do I keep these straight? What's the real difference between macro-segmentation and microsegmentation? Agent vs agentless — which enforcement model should I pick? Why is 'monitor mode first' such a big deal — can't I just write good rules? If I have microsegmentation, do I still need a perimeter firewall and VLANs? How does this map to NIST 800-207 and the CCNP Security exam? Pre-curated from Zero Trust docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember In a data centre, what does 'east-west traffic' refer to? a) Traffic entering and leaving the data centre through the perimeter firewall b) Server-to-server (workload-to-workload) traffic inside the data centre c) Encrypted VPN traffic between branch offices d) Traffic between the user's browser and a public website Correct: b. East-west is server-to-server traffic inside the data centre — the path attackers use for lateral movement, and exactly what a perimeter (north-south) firewall never inspects. The other options describe north-south or WAN traffic, not east-west. Q6 · Apply A three-tier app at Zomato has web, app and database tiers. To microsegment it, which allow-list is correct (everything else default-denied)? a) Allow web→app and app→db on their app ports; deny web→db and all the rest b) Allow any host in the subnet to reach any other host c) Allow web→db directly so the page loads faster d) Allow db→web and db→internet for updates Correct: a. The only legitimate east-west flows are web→app and app→db on their specific ports; web→db must be denied so a popped web server can't jump the tier to the database. A subnet-wide any-any allow re-opens the flat network; web→db and db→internet are exactly the dangerous flows you want blocked. Q7 · Apply You're rolling microsegmentation onto a production app and want to avoid breaking a forgotten nightly backup flow. What do you do before switching the policy to 'block'? a) Enforce immediately and add allow rules only after users complain b) Delete the backup job to remove the variable c) Move the app to a new VLAN first d) Run the policy in monitor/test (visibility) mode and read the would-block log, then fix surprises before enforcing Correct: d. Monitor/test mode runs your allow-list but only logs what it would drop, so you can spot the legitimate-but-forgotten backup flow and add a rule before any real blocking. Enforcing first breaks production; deleting the backup or re-VLANing doesn't validate the policy against real traffic. Q8 · Analyze After labelling and writing tag→tag rules, a non-app server in the same subnet can STILL reach the database on 5432. Identity rules look correct. Most likely root cause? a) The database agent is offline so nothing is enforced b) Microsegmentation can't work within a single subnet c) A broader rule (a subnet-wide or any→any allow) sits above the identity rules and overrides them d) TCP 5432 is encrypted so policy can't match it Correct: c. On an allow-list, one broad allow (a subnet-wide or any-any rule) re-opens the room and overrides your tight identity rules — the classic cause of 'segmented but still reachable'. Microsegmentation works precisely within a subnet (that's the point); an offline agent would block, not allow; and encryption on 5432 doesn't stop policy matching by identity/port. Q9 · Analyze Two enforcement choices for a shop moving half its VMware workloads to AWS next year: (A) VMware NSX DFW only; (B) a host-agent model (e.g. Illumio VEN). Which keeps ONE consistent east-west policy across both environments, and why? a) The host-agent model — the agent travels with the workload, so the same label-based policy enforces on the VMware VM and the EC2 instance b) NSX DFW only — it enforces in AWS as well as on-prem c) Neither — policy must be rewritten per platform d) NSX DFW only — Security Groups and NSX are the same product Correct: a. A host agent enforces from central, label-based policy on the workload itself, so 'Role=App→Role=DB:5432' follows the VM whether it's on a VMware hypervisor or an EC2 instance. NSX DFW only enforces on VMware's hypervisor (not in AWS), and AWS Security Groups are AWS-only — so the agent model is what gives one consistent hybrid policy. Q10 · Evaluate Two pitches to leadership: (A) "Microsegmentation replaces our firewall and VLANs with one simpler system." (B) "Microsegmentation adds per-workload east-west enforcement to contain a breach's blast radius — defence in depth alongside the firewall and VLANs." Which is the stronger, more accurate case and why? a) A — fewer systems is always the best business case b) B — it states the real value (blast-radius containment of lateral movement) and correctly positions microseg as an added layer, not a replacement c) A — microsegmentation does make firewalls and VLANs unnecessary d) Identical — both describe the same thing Correct: b. B is accurate and aligned with Zero Trust/NIST 800-207: microsegmentation contains the blast radius by stopping east-west lateral movement, and it layers on top of (not replaces) the perimeter firewall and VLANs — defence in depth. A is wrong on the facts: microseg guards east-west and does not remove the need for north-south or coarse segmentation. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why does microsegmentation stop a single phished laptop from becoming a data-centre-wide ransomware event? Then compare to the expert version. Compare with expert answer Expert version: Because it enforces per-workload, identity-based, default-deny policy on east-west traffic, so the attacker who lands on one host hits a locked door at every neighbour and can't move laterally to the crown jewels — the breach is contained to one segment instead of spreading across a flat trust zone. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsegmentation at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Microsegmentation Security policy down to the individual workload, governing east-west traffic by identity/label on a default-deny basis. East-west traffic Server-to-server traffic inside the data centre, as opposed to north-south traffic in and out of it. North-south traffic Traffic in and out of the data centre/perimeter — what the edge firewall inspects. Lateral movement An attacker moving host to host inside the network after the first compromise, to reach higher-value targets. Macro-segmentation Coarse segmentation by VLAN/subnet/firewall between big zones; can't see inside a zone. Allow-list / default-deny Permit only explicitly listed flows; block everything else. The opposite of default-allow. Ring-fencing Drawing a tight allow-list around one application so only its real flows are permitted. Blast radius How far a single breach can spread before something stops it; microsegmentation shrinks it to one segment. Illumio PCE / VEN Illumio's Policy Compute Engine (central brain) and Virtual Enforcement Node (host agent) that enforce per-workload policy. VMware NSX DFW NSX Distributed Firewall — enforces east-west rules in the hypervisor kernel at each VM's virtual NIC (vnic). Cisco TrustSec (SGT) Tags traffic with a Security Group Tag via ISE; switches/firewalls enforce on the tag, decoupled from IP. NIST SP 800-207 The US Zero Trust Architecture standard: shrink implicit trust, verify every access, enforce close to the resource, assume breach. #### 📚 Sources NIST SP 800-207 "Zero Trust Architecture" — core tenets: shrink implicit trust zones, enforce per-resource access close to the asset, assume the network is breached (microsegmentation as the network enforcement pillar). csrc.nist.gov/pubs/sp/800/207/final · nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf - Illumio Docs — "Application Ringfencing" + "Labeling Workloads" (PCE/VEN, the four labels Role/Application/Environment/Location, allow-list/default-deny, Illumination flow map, Visibility-only/Test/Enforced states). docs.illumio.com/core · illumio.com/cybersecurity-101/microsegmentation - VMware NSX Documentation — Distributed Firewall (DFW): kernel/vnic-level east-west enforcement, dynamic Security Groups by tag/VM-name, central policy from NSX Manager (Security → Distributed Firewall). docs.vmware.com (NSX Security) · techtarget.com — NSX firewall best practices - Verizon 2025 Data Breach Investigations Report + CrowdStrike 2026 Global Threat Report — lateral movement present in the majority (~60%) of successful breaches; average eCrime breakout time ~29 minutes (why flat networks fail). verizon.com/business/resources/reports/dbir/ · crowdstrike.com/global-threat-report/ - Cisco CCNP/CCIE Security SCOR 350-701 exam blueprint — segmentation (VLAN/VRF macro-segmentation) and secure network access with Cisco TrustSec + ISE (Security Group Tags / SGACLs) for identity-based microsegmentation. learningnetwork.cisco.com/s/scor-exam-topics · learningcontent.cisco.com/documents/exam-topics/350-701+SCOR+Exam+Blueprint.pdf - CISA Zero Trust Maturity Model v2.0 + community/practitioner guidance (r/networking, r/cybersecurity, ColorTokens/Elisity/Akamai) on a safe rollout: map flows → baseline → ring-fence high-value app → monitor-then-block with a rollback. cisa.gov/zero-trust-maturity-model · elisity.com/microsegmentation/how-to-implement ### What's next? You've locked the doors between your servers. But your users still click links and your apps still reach out to the internet all day — and that outbound traffic is where data leaks and malware phones home. Next we sit a guard on every outbound click. Next · Secure Web Gateway (SWG): Inspecting Every Outbound Click → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt