Segmentation and firewalls

Blast radius: the number segmentation actually moves

Start from the assumption a senior never drops: something will be compromised. A dependency CVE, a leaked credential, an SSRF that pivots inward — eventually one host is the attacker’s. The only question left is how far that foothold reaches. That reachable surface is the blast radius, and it is the metric segmentation exists to shrink.

A flat network — one big subnet, every host able to dial every other host on any port — maximizes blast radius by construction. Compromise of any single node equals reachability to all of them. This is exactly the structure that turns a contained web-tier bug into a lateral-movement spree: the 2013 Target breach famously began with credentials stolen from an HVAC vendor and reached the point-of-sale network because the segments that should have separated vendor access from card-processing systems weren’t enforced. The lesson generalizes: lateral movement is only possible across paths the network permits, so the defense is to permit fewer paths.

Segmentation slices that flat space into zones with controlled crossings. A classic three-tier cut is web / app / data: the web tier accepts traffic from the internet on 443, the app tier accepts traffic only from the web tier, and the data tier accepts traffic only from the app tier. Now a compromised web box can reach the app tier on one port — not the database, not the secrets store, not CI. The attacker has to find a second vulnerability at each border to keep moving, and every border is a place you get to detect and stop them.

The enforcement layers: firewalls, security groups, microsegmentation

A zone boundary is only as real as the thing enforcing it. Three layers do the work, at three different granularities.

A network firewall sits at a subnet or perimeter boundary and filters traffic by 5-tuple (source IP, destination IP, source port, destination port, protocol). The non-negotiable posture is default-deny: the ruleset starts by dropping everything, and you explicitly allow only the flows the architecture requires. A default-allow firewall with a few block rules is a sieve — it fails open the moment a new service appears that nobody wrote a block rule for. Default-deny fails closed: a flow nobody allowed simply doesn’t happen.

Security groups (the cloud’s native primitive — AWS, GCP, Azure all have an equivalent) push that filter down to the instance and make it identity-based instead of IP-based. Instead of “allow 10.0.2.0/24 → 5432,” you write “allow the app-sg source group → the db-sg on 5432.” The rule references roles, not addresses, so it survives autoscaling and IP churn, and it is stateful: you allow the inbound request and the response is permitted automatically. Security groups are deny-by-default by nature — an instance with no inbound rule accepts nothing.

Microsegmentation takes it to the limit: policy per workload, often per service or pod, enforced regardless of where it runs. In Kubernetes this is a NetworkPolicy (or a service-mesh authorization policy) that says pods labeled app=checkout may receive traffic only from pods labeled app=gateway on 8080 — and the default in a namespace with any policy is deny all else. This is the structural core of zero trust (NIST SP 800-207): the network location of a request grants it nothing; every flow is authorized on its own identity. Microsegmentation is what shrinks east-west blast radius from “the whole namespace” to “the one neighbor this service legitimately talks to.”

Defense in depth, and where segmentation stops helping

Segmentation is one layer of defense in depth, not the whole defense. It controls who can reach whom; it does not validate what they send once allowed. If the app tier is permitted to query the database and the app has a SQL injection flaw, the firewall waves the malicious query straight through — the 5-tuple is on the allowlist. So segmentation must be paired with controls at the next layer in (parameterized queries, authn/authz on the service, input validation) and the layer above (WAF, TLS). The point of depth is that no single control failing should be game over.

Two honest costs keep this from being free. Operational drag: fine-grained policy is a lot of rules, and rules drift — a stale allow nobody removed becomes the exact path the attacker uses. The discipline is to treat policy as code, review it, and audit for unused allows. The failure mode of doing it badly: over-segment without good observability and you get mystery outages where a legitimate flow is silently dropped, the team can’t tell a misconfiguration from an attack, and — worst of all — under pressure someone “fixes” it by adding an allow all rule that quietly re-flattens the network you spent a quarter segmenting.

Reading a policy like a senior

When you review a segmentation design, you’re really asking two questions. First, is it default-deny? If the baseline is allow-with-exceptions, the design is already lost — find the implicit any-any rule and you’ve found the whole network’s true reachability. Second, what does a single compromise reach? Pick the most exposed node (the internet-facing tier), assume it’s owned, and trace every flow it’s allowed to make. That set is your blast radius. If it includes the database, the secrets store, or CI, you have lateral-movement paths to cut.