Segmentation & lateral movement
Segmentation is the discipline of deciding what inside your cloud is allowed to talk to what — and lateral movement is what an attacker does when that decision was never really made. Most cloud estates start flat: a handful of subnets in a single VPC or VNet where every workload can reach every other, and where production, development, CI runners, and the management plane all share one trust boundary. That works until the first compromise, at which point a single foothold — a vulnerable web tier, a leaked container credential, a poisoned build agent — inherits reach across the whole environment. This page focuses specifically on east-west reachability: how the network is partitioned between environments and tiers, how far a compromised workload could actually travel, and whether the paths that connect otherwise-separate estates (peering, transit gateways, VPNs, shared VPCs) quietly recombine what segmentation was supposed to keep apart. It is distinct from ingress hardening — you can lock every front door and still have a house with no interior walls.
Overview
What this check looks like in practice
Segmentation determines how far an attacker can travel after the first compromise. Flat networks — where every workload can reach every other — mean one foothold is effectively a foothold everywhere, and production, dev, and management planes often share a trust boundary that should not exist. We look at how the network is partitioned between environments and tiers, and how much lateral reach a single compromised workload would actually have.
Why it matters
From an attacker's perspective, initial access is rarely the goal — reach is. A phished credential or an exploited service is only valuable if it can pivot to the datastore, the secrets manager, or the account that controls everything else, and flat networks hand that pivot over for free. From an auditor's perspective, segmentation is one of the few network controls with an explicit, testable requirement: PCI-DSS treats network segmentation as the mechanism that shrinks cardholder-data scope, and if a general-purpose subnet can route to your CDE, the whole flat network is in scope. The consequence of getting this wrong is measured in blast radius — a contained incident stays one workload, while an un-segmented one becomes an estate-wide compromise with longer dwell time and a breach notification that must assume everything reachable was touched. Segmentation also degrades silently: a peering link added for one integration, a rule widened to unblock a deploy, a management subnet never isolated — so posture that was sound at launch drifts open without anyone touching the perimeter.
What we assess
What we look for
- Production, development, staging, and management workloads sharing a single flat VPC/VNet or subnet with no isolation boundary between them
- Intra-VPC/VNet rules that permit broad east-west traffic — security groups referencing the default group, or rules allowing the whole VPC CIDR between application tiers that should only talk on specific ports
- Sensitive datastores (databases, caches, secrets stores) reachable from general-purpose, public-facing, or CI/CD subnets rather than isolated data subnets
- VPC/VNet peering, transit gateway, hub-spoke, or VPN links that over-connect otherwise separate environments — especially non-prod able to route to prod, or a shared-services hub with unrestricted transitive reach
- Missing subnet-level or firewall-based isolation between app, web, and data tiers (no per-tier security groups, NSGs, or firewall policies enforcing a tiered trust model)
- Management and orchestration planes — Kubernetes API servers, CI runners, bastions, admin subnets — that can reach production workloads without a scoped, justified path
- Overly permissive route tables and the absence of network ACLs / hierarchical firewall policies as a second enforcement layer beyond instance-level rules
- No egress restriction between segments, so a compromised tier can initiate connections outward to peers rather than only receiving expected inbound traffic
Across your clouds
AWS, Azure & Google Cloud
AWS
We map east-west reach across VPCs: security-group references (SG-to-SG rules), subnet-level network ACLs, and route tables that determine what is actually routable. Cross-environment paths get particular attention — VPC peering (non-transitive but often over-scoped), Transit Gateway route tables and their route propagation, and shared-services hubs. Isolation patterns we look for include per-tier security groups, PrivateLink for service-to-service access instead of open routing, and separate accounts or VPCs per environment rather than one flat network.
Azure
We review network security groups (NSGs) and application security groups (ASGs) as the tier-boundary enforcement, subnet design, and user-defined routes. Hub-spoke topology is the common Azure pattern, so we check VNet peering settings (allowForwardedTraffic, and gateway transit via allowGatewayTransit/useRemoteGateways) and whether Azure Firewall or an NVA actually constrains spoke-to-spoke traffic rather than letting the hub become an any-to-any transit. Private Link and service endpoints are assessed as the private path to PaaS data services instead of routable exposure.
Google Cloud
We assess VPC firewall rules and hierarchical firewall policies, which unlike per-instance rules are evaluated by priority and can enforce org- or folder-level isolation. Network tags and service accounts used as firewall targets are checked for scoping. Cross-environment reach is examined through VPC Network Peering (non-transitive) and especially Shared VPC, where a host project's subnets can grant service projects broad reach; we also look at Private Service Connect and Private Google Access as the private path to managed data services.
Example finding
Non-production subnet can route to the production database tier
Risk: The development and CI/CD subnets share a VPC with production and the data-tier security group accepts traffic from the entire VPC CIDR, so a compromised build runner or a vulnerable dev workload — the least-hardened surfaces in the estate — can open a direct connection to the production database. This collapses the blast radius of any non-prod compromise into a production data breach and, for regulated data, pulls the non-prod environment into audit scope because it is not genuinely segmented from the sensitive tier.
Fix: Replace the VPC-wide allow with a security-group reference that permits only the production application tier to reach the database on its specific port, and remove any route or peering path between non-prod and prod. Where environments must stay in one account, enforce the boundary with per-tier groups and subnet-level ACLs; the stronger pattern is separate accounts/projects per environment with no default connectivity between them.
Remediation
How to close it
- 1 Inventory the real east-west reach: for each sensitive tier (data stores, secrets, management plane), enumerate every source that can currently reach it via security groups/NSGs/firewall rules, route tables, peering, and transit links — not just the perimeter rules.
- 2 Define an explicit tier and environment model (web → app → data, and prod vs. non-prod vs. management) and treat every allowed path between them as a decision that needs a named workload behind it.
- 3 Rewrite intra-network rules to reference specific source groups/tags on specific ports instead of broad CIDRs or default groups, so each tier only accepts the connections its function requires.
- 4 Sever or tightly scope over-connecting links: audit peering, transit gateway/hub route tables, shared VPC assignments, and VPNs so non-prod cannot route to prod and the shared-services hub is not an any-to-any transit.
- 5 Move sensitive datastores onto isolated subnets reachable only from their owning app tier, and prefer private connectivity (PrivateLink/Private Link/Private Service Connect) over routable exposure for service-to-service traffic.
- 6 Add a second enforcement layer and detection: subnet-level ACLs or hierarchical firewall policies beneath instance rules, plus flow-log review so unexpected east-west connections surface rather than pass silently.
Questions
Isn't a locked-down perimeter enough — why does internal segmentation matter if nothing is exposed to the internet?
No. Perimeter controls only decide who gets in; segmentation decides how far they get once they're in, and a foothold rarely comes through the front door — it comes from a phished credential, a leaked container secret, a vulnerable dependency, or a poisoned build runner already inside the network. If every workload can reach every other, that one internal foothold inherits reach to your databases, secrets, and management plane. Segmentation is what turns a single compromise into a contained event instead of an estate-wide one.
How do you assess lateral movement without running an attack or pen test?
We read the configuration rather than exploit it. Reachability in the cloud is fully described by security groups/NSGs/firewall rules, route tables, network ACLs, peering, transit gateways, and shared-VPC assignments — so from that recorded state we can reconstruct, for any sensitive tier, exactly which sources could open a connection to it and by what path. That produces a concrete map of east-west reach and blast radius with nothing changed in production and no active probing. A pen test complements this by validating from the outside; the health check shows the reachable paths that exist by design.
We run everything in one account or VPC — is that automatically a finding?
Not automatically, but it raises the bar for the internal controls. A single account can be segmented well using per-tier security groups, isolated data subnets, subnet-level ACLs or hierarchical firewall policies, and least-privilege east-west rules. What we flag is the combination of one flat network with permissive intra-network rules — production, non-prod, and management sharing a trust boundary with broad any-to-any reach. The stronger pattern is separate accounts or projects per environment with no default connectivity, but a well-partitioned single account with enforced tier boundaries can be sound.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
