Case Study 1: Segmenting Meridian — From One Open Room to a Building of Locked Rooms

"Show me a flat network and I'll show you a single bad Tuesday away from a federal disclosure." — Sam Whitfield, Security Engineer, Meridian Regional Bank (constructed)

Executive Summary

When Sam Whitfield finally diagrammed Meridian's actual internal network — not the tidy version in the old documentation, but what the cables and switches really did — he found something that is true of more banks than anyone likes to admit: the inside was mostly flat. A teller workstation in a branch in one state could, in principle, open a connection straight to a server holding card data in the data center. Nothing in the network said no. The perimeter firewall was excellent. The interior was an open floor.

This case study follows Sam and junior analyst Theo Brandt as they turn the open floor into a building of locked rooms — the network architecture (version 1) that this chapter's Project Checkpoint contributes to Meridian's security program. It is a design and build exercise: you will watch the team inventory what talks to what, group systems into trust zones, place firewalls, write the first default-deny inter-zone policy, and — crucially — carve the cardholder data environment (CDE) out of the core so that PCI-DSS scope shrinks and the blast radius of any single compromise collapses. Along the way the chapter's vocabulary stops being definitions and becomes a working tool: segmentation, VLAN, subnet, DMZ, NAT, east-west and north-south traffic. All details are constructed for teaching (Tier 3).

Skills applied: mapping a real network's trust relationships; designing trust zones; placing perimeter and internal firewalls; writing a default-deny inter-zone policy; isolating a cardholder data environment for PCI-DSS scope reduction; reasoning about east-west containment and "assume breach" at the network layer; using netfilter.py to read the resulting firewall logs.

Background

Two months after the phishing near-miss of Chapter 1, CISO Dana Okafor's program-maturation initiative reached the network. The risk register from Meridian's first assessment (Case Study, Chapter 1) carried a finding that had quietly terrified Sam since he read it: "Weak segmentation lets a foothold reach the cardholder data environment — likelihood 3, impact 5, score 15, CRITICAL." The phishing attack had failed at authentication. The next one might not, and if it succeeded against any internal user, the question was no longer "will they get in?" but "how far can they go once they do?"

Meridian's environment is the one frozen across this book: roughly 1,800 employees; 120 branches across three Midwestern states; an on-premises data center running the legacy core-banking system, a Windows Active Directory domain with twenty years of sediment, and VMware; plus AWS and a Microsoft 365 tenant with Entra ID. About 200 ATMs and a cardholder data environment in scope for PCI-DSS. The compliance surface — GLBA, PCI-DSS, SOX, FFIEC, state breach laws — meant that "we'll segment it eventually" was not just a security debt; it was an audit finding waiting to be written.

Dana gave Sam two constraints that shaped everything. First: "Design for the breach you'll actually have, not the one in the brochure. Assume someone gets a foothold on an ordinary workstation. Show me that it doesn't matter much." Second: "Don't boil the ocean. I want a version 1 we can build this year, that an examiner can understand, and that we can extend — not a perfect design we never finish." That second instruction is the difference between security architecture that ships and security architecture that lives forever on a whiteboard.

The Analysis

Phase 1 — Mapping what actually talks to what

Sam refused to start with a product or a zone diagram. He started with a question the chapter built toward: which systems must talk to which, and what is the blast radius if any one of them is compromised? He and Theo spent three days building a flow inventory — not exhaustive, but honest — of the real conversations on the network. A condensed sample of their working notes:

WHO TALKS TO WHOM (observed + required)
  Teller workstation  -> banking application (core front-end)   tcp/443   REQUIRED
  Teller workstation  -> file share, print, AD auth             various   REQUIRED
  Teller workstation  -> EVERYTHING ELSE                        any       observed, NOT required
  Public web server   -> back-end app server                    tcp/8443  REQUIRED
  Public web server   -> internet (inbound)                     tcp/443   REQUIRED
  Online-banking FE   -> core-banking systems of record         narrow    REQUIRED
  Card-processing sys -> payment network, core                  narrow    REQUIRED
  Card-processing sys -> shares same flat segment as corporate  any       observed, DANGEROUS
  Admin laptop        -> switch/router admin (ssh)              tcp/22    REQUIRED
  Anyone              -> switch/router admin (ssh)              tcp/22    observed, DANGEROUS

The pattern that jumped out was not any single dangerous flow. It was the gap between required and observed: nearly every system could reach nearly every other system, and almost none of that reach was needed. The teller workstation needed four or five destinations and could reach thousands. The card-processing systems lived on the same flat segment as the corporate network. The network gear's administrative interfaces were reachable from ordinary user space. This is what a flat network looks like from the inside: not a single open door, but the absence of doors between rooms that should never have been one room.

🛡️ Defender's Lens: Sam's first artifact was not a diagram of zones — it was a diagram of flows. Experienced architects segment by asking "what conversations are required?" and then denying everything else, rather than "what zones should exist?" and hoping the flows fit. The required-versus-observed gap is the raw material of least privilege on the network: every observed-but-not-required flow is a path an attacker can use and you do not need. Segmentation is, at bottom, the project of closing that gap.

⚠️ Common Pitfall: Theo's first instinct was to start drawing VLANs immediately. Sam stopped him: "A VLAN is a mechanism. We don't know what to separate yet." Designing the mechanism (VLANs, subnets) before understanding the trust relationships produces tidy-looking segments that still allow the wrong traffic — logical separation with no security benefit. Map the flows first; choose the mechanism second.

Phase 2 — Grouping systems into trust zones

With the flows mapped, the zones almost defined themselves. Sam grouped systems by two questions: how much do we trust this, and what does it need to talk to? Systems that are internet-exposed go together (and far from the crown jewels). Systems holding the most sensitive, regulated data go together (and behind the most boundaries). Everything else sorts by function. The result was the zone model this chapter presents as Figure 6.4 — here is how Sam justified each one to Dana:

The CDE deserved its own line in the conversation, because it is where security and compliance meet. Sam explained the leverage to Dana in business terms: PCI-DSS applies to every system that stores, processes, or transmits cardholder data — and every system connected to those. On a flat network, "connected to" means almost everything, which is why a flat bank's entire network can fall into PCI scope. By segmenting the CDE into its own tightly controlled zone, Meridian removes the corporate and branch networks from scope: they can no longer reach the card systems, so they are no longer "connected" in the sense the standard means. The same control that shrinks the attacker's blast radius shrinks the auditor's scope. Dana, who would present this to the board, wrote that sentence down verbatim.

🔗 Connection: This is Theme 5 — compliance is the floor, not the ceiling — working in the defender's favor for once. Meridian is not segmenting the CDE because PCI-DSS says to; it is segmenting because containing card data is genuinely good security, and the compliance benefit (reduced scope) is a bonus. When a control is both more secure and less work to audit, you have found the rare win-win. The full PCI-DSS treatment comes in Chapter 28; here, segmentation is its foundation.

Phase 3 — Placing the firewalls and writing the first policy

Zones without enforced boundaries are just labels (the Chapter 6 pitfall). Sam placed two firewall tiers. The perimeter firewall governs north-south traffic between the internet and the DMZ, denying inbound by default and permitting only the specific DMZ services on their specific ports. The internal firewall governs east-west traffic between every internal zone, denying by default so that any cross-zone conversation must be explicitly permitted and is logged when it occurs. (In Chapter 7, Sam will refine this with stateful and next-generation capabilities, IDS/IPS, and microsegmentation; version 1 establishes the structure.)

Then came the part that makes segmentation real: the inter-zone policy. Sam wrote it default-deny — the last rule denies everything, and every permitted flow is an explicit exception above it, ordered so that the most specific allowances come first. A condensed version of the version-1 internal policy:

# Meridian internal inter-zone policy v1 (first match wins; default-deny at the bottom)
#  zone-to-zone           protocol/port     action   log
 1 branch    -> banking-app(core-fe)  tcp/443    ALLOW   yes
 2 branch    -> ad/file/print         defined    ALLOW   yes
 3 corporate -> internet(via DMZ)     tcp/443,80 ALLOW   yes
 4 online-fe(DMZ) -> core(systems-of-record) tcp/<narrow> ALLOW yes
 5 cardsys(CDE) -> payment-net,core   tcp/<narrow> ALLOW   yes
 6 management -> network-devices      tcp/22     ALLOW   yes
 7 guest     -> internet              tcp/443,80 ALLOW   yes
 8 guest     -> any-internal          any        DENY    yes   # explicit, for clarity
 9 any       -> management            any        DENY    yes   # protect the control plane
10 any       -> CDE                   any        DENY    yes   # CDE reachable only via rule 5's peers
11 any       -> any                   any        DENY    yes   # DEFAULT-DENY

Theo's job was to read this policy adversarially — to try to find the flow an attacker would want that the rules accidentally allowed. He found one in Sam's first draft: an early version had a broad corporate -> any tcp/443 rule "so HTTPS just works," which would have let a compromised corporate workstation reach the core-banking systems on 443. Sam tightened it to route corporate internet traffic through the DMZ proxy and denied corporate-to-core entirely. That catch — a single over-broad rule that re-flattened part of the network — is exactly the kind of error that turns a "segmented" network back into an open floor, and it is why every ruleset needs a second reader.

🛡️ Defender's Lens: Notice rules 8, 9, and 10. The default-deny at rule 11 already blocks guest-to-internal, any-to-management, and any-to-CDE — so those explicit DENY rules are technically redundant. Sam wrote them anyway, above the catch-all, for three reasons: they make the intent legible to an auditor and the next engineer, they log those specific attempts with clear context, and they protect against a future edit accidentally permitting that traffic higher in the list. Defense in depth applies to your own ruleset: state the critical denials explicitly, do not rely solely on the implicit one at the bottom.

Phase 4 — Validating containment: the breach that doesn't matter much

Dana's first constraint was "show me a foothold doesn't matter much." So Sam ran the design through the scenario that haunts every bank: an attacker phishes a branch teller and lands on their workstation. Tracing the path through version 1:

ATTACKER on a branch teller workstation (branch zone). Attempts:
  -> core-banking systems of record        => DENIED by rule 11 (default), LOGGED, alert
  -> cardholder data environment (CDE)      => DENIED by rule 10 (explicit), LOGGED, alert
  -> network device admin (ssh/22)          => DENIED by rule 9 (explicit), LOGGED, alert
  -> other branch/corporate workstations    => DENIED (no inter-zone allow), LOGGED, alert
  -> banking application (tcp/443)           => ALLOWED (rule 1) — the one thing a teller may do
RESULT: the attacker controls ONE workstation, can reach ONE application a teller is meant to reach,
        and every probe toward anything valuable is denied and surfaced to the SOC as an alert.

Compare this to the flat-network outcome that opened the chapter, where the same foothold could reach every system directly. The architecture does not prevent the phish — Meridian's people will still occasionally click (Chapter 1, Theme 3), and pretending otherwise is fantasy. What it does is make the phish survivable: one click becomes one contained workstation and a flurry of denied, logged attempts that turn a silent breach into a noisy, detectable one. The attacker's required next move — east-west lateral movement — now runs straight into a wall that also raises an alarm.

Theo fed the resulting firewall logs through the netfilter.py parser he built in this chapter's checkpoint, to confirm the denials were being captured in a form the SOC could use:

input lines (from the internal firewall):
  action=DENY src=10.20.10.5 dst=10.50.1.10 dport=445 proto=tcp   # teller -> core, blocked
  action=DENY src=10.20.10.5 dst=10.60.1.4  dport=22  proto=tcp   # teller -> mgmt, blocked
  action=ALLOW src=10.20.10.5 dst=10.40.1.2 dport=443 proto=tcp   # teller -> banking app, ok

parse_fw_log() output (one dict per line), summarized:
  DENIED   10.20.10.5 -> 10.50.1.10:445/tcp
  DENIED   10.20.10.5 -> 10.60.1.4:22/tcp
  allowed  10.20.10.5 -> 10.40.1.2:443/tcp

The two denials, from a single branch source reaching toward the core and the management zone within seconds, are precisely the signal a SOC wants: a workstation behaving like an attacker, contained by the architecture and visible because the architecture logs its containment. Segmentation did not just block the lateral movement — it generated the evidence of it, turning the network itself into a sensor. That dual role (prevention plus detection) is why segmentation is the highest-leverage network investment most banks can make.

🚪 Threshold Concept: A well-segmented network is not only a set of walls — it is a set of tripwires. Because legitimate traffic stays within its allowed flows, any attempt to cross a zone boundary is, by definition, anomalous, and a default-deny boundary that logs its denials converts every lateral-movement attempt into an alert. The flat network is silent precisely because everything is allowed; the segmented network is loud precisely because crossings are rare. Designing for containment and designing for detection turn out to be the same act.

Discussion Questions

1. Sam insisted on mapping flows (required vs. observed) before drawing zones. What goes wrong when a team designs zones first and fits flows to them afterward? Give a concrete example from the case.
2. The case argues that segmenting the CDE both improves security and reduces PCI-DSS scope. Are there situations where a compliance-driven boundary and a security-driven boundary would conflict rather than align? How would you decide?
3. Rules 8–10 in the policy are redundant with the default-deny at rule 11, yet Sam kept them. Argue for and against including explicit denials above an implicit catch-all. When does the redundancy help, and when does it add risk (e.g., a long ruleset that is hard to audit)?
4. Dana required a "version 1 we can build this year" over a perfect design. What are the risks of shipping an admittedly incomplete segmentation design, and how does the team mitigate them (consider what Chapter 7 adds)?
5. The validated breach scenario shows containment but still leaves the attacker on one workstation able to reach the banking application. What further controls (from later chapters) would reduce even that residual risk, and why can the network layer alone not eliminate it?

Your Turn

Take a small organization you know (or invent one with 5–10 system types) currently on a flat network. Reproduce Sam's process end to end: (1) build a short required-vs-observed flow inventory and identify the gap; (2) group the systems into three to six trust zones with a one-line justification each; (3) place your firewall tier(s) and write a default-deny inter-zone policy of 6–10 ordered rules, with the catch-all at the bottom; (4) pick the one foothold you most fear and trace what it can and cannot reach under your design; (5) name the single most sensitive zone and confirm it requires crossing the most boundaries. Keep the whole thing to two pages. If any zone needs to reach "everything," treat that as a signal you have not finished mapping the flows.

Key Takeaways

• Map flows before zones. The gap between required and observed connectivity is the raw material of network least privilege; segmentation is the project of closing it.
• Choose the mechanism (VLAN/subnet) after the trust model, not before — otherwise you build tidy segments that still permit the wrong traffic.
• Isolating the cardholder data environment both contains a fraud magnet and reduces PCI-DSS scope by removing other zones from "connected to" — a rare security-and-compliance win.
• Place enforced, default-deny boundaries between zones; state critical denials explicitly above the catch-all for legibility, logging, and resilience against future edits.
• A single over-broad rule re-flattens the network — every ruleset needs an adversarial second reader who hunts for the allowed flow an attacker would want.
• Segmentation makes a foothold survivable and visible: it both blocks east-west lateral movement and generates the evidence of it, turning the network into a sensor — the network-layer implementation of "assume breach."