Case Study 1: Meridian Closes the Branch-Jack Gap

"The firewall worked perfectly. That was the problem — everyone thought it was the whole defense." — Sam Whitfield, Security Engineer, Meridian Regional Bank (constructed)

Executive Summary

A routine penetration test embarrassed Meridian Regional Bank in a way no audit finding ever had: the tester ignored the bank's expensive internet-edge firewall entirely, walked into a branch lobby, plugged a small computer into a network jack behind a customer-service desk, and was handed a working internal IP address. From there she reached teller workstations, a file server full of loan documents, and a path toward the cardholder data environment (CDE). The edge firewall had done exactly what it was built to do — and had been completely irrelevant, because the attacker never crossed the edge.

This case study follows security engineer Sam Whitfield and SOC manager Marcus Reyes as they turn that single finding into Meridian's perimeter-and-segmentation control set: a documented default-deny firewall posture, an IDS/IPS deployment that watches both north-south and east-west traffic, 802.1X network access control on branch switch ports, and a microsegmentation plan with a bastion host as the only administrative path into the CDE. It is a design-and-build study: you will watch a flat, edge-only network become a layered one that assumes the attacker is already inside. All systems, addresses, and figures are constructed for teaching (Tier 3).

Skills applied: firewall type selection; writing and auditing a default-deny ruleset; IDS-vs-IPS placement; 802.1X NAC design; microsegmentation and bastion-host design; defense-in-depth reasoning on the network; translating a single pentest finding into a documented control standard.

Background

Meridian's network had grown the way most do: by accretion. Years ago someone bought a strong next-generation firewall for the internet edge, ruled it carefully, and — understandably — treated it as the network security control. Inside that edge, the network was largely flat. Branches connected back to the core over the bank's WAN, and once traffic was "inside," it moved freely. There were a few large VLANs — corporate, a loosely-defined CDE, guest WiFi — but within each zone, and often between them, east-west traffic was unrestricted. No switch port asked a connecting device to prove anything. The assumption baked into the whole design was the classic one: the inside is trusted.

CISO Dana Okafor had commissioned the penetration test deliberately, as part of the program-maturation initiative that began after the Chapter 1 phishing near-miss. The brief was simple: "Find the way in we haven't thought about." The tester found it in under a day, and her report contained one sentence that Dana read aloud to the board's Audit Committee: "The bank's network security is a strong front door on a building with no interior walls and unlocked side entrances."

Sam and Marcus were handed the remediation. Dana's instruction echoed her instruction after the phishing incident: "Don't just buy a box. Design the control, document it, and make it something we can defend to an examiner."

The Design

Phase 1 — Reframing the problem: assume the attacker is inside

Sam started not with a product but with a principle. The pentest had proven that the perimeter could be stepped around — physically, through a lobby jack; logically, through a phishing click; and remotely, through any compromised vendor connection. The design premise therefore could not be "make the perimeter stronger." It had to be assume the attacker is already inside, and build so that being inside is not enough.

That reframing produced four workstreams, each a layer that assumes the one before it has failed:

   LAYER 1  Admission control   -> NAC / 802.1X: should this device even connect?
   LAYER 2  Boundary control    -> default-deny firewalls between every zone
   LAYER 3  Detection           -> IPS in-line at the edge; IDS watching east-west
   LAYER 4  Containment          -> microsegmentation + bastion for the CDE

   The branch-jack attack defeated a network that had only a weak version of Layer 2.
   Each layer below is designed assuming the layer above it was bypassed.

Figure CS1.1 — Meridian's four perimeter-and-segmentation layers. The pentest succeeded because only Layer 2 existed, and weakly. Defense in depth means every layer assumes the others can fail.

🚪 Threshold Concept: The most important deliverable of this project was not any device — it was the decision to stop treating network position as authorization. Every control that follows is a consequence of that one shift. Once "inside the network" no longer means "trusted," the branch jack stops being a catastrophe and becomes just another untrusted port.

Phase 2 — Layer 2 first: a documented default-deny firewall posture

Sam began with the firewalls because they were the control Meridian already had — just configured loosely. He audited the existing inter-zone rules and found exactly what the pentester's metaphor predicted: a corporate→CDE firewall whose effective policy was close to default-allow, with a handful of broad permits accumulated over years, including one permit ip 10.20.0.0/16 -> 10.30.0.0/24 that a forgotten project had added and never removed. That single rule let any corporate host reach the entire CDE.

He rewrote the boundary as a strict default-deny standard. The reference implementation — the one that would go into the program document as the template for every inter-zone firewall — was the corporate↔CDE ruleset:

# Meridian standard: corporate <-> CDE inter-zone firewall
# corp = 10.20.0.0/16   cde = 10.30.0.0/24   payment app = 10.30.0.40
# CDE db = 10.30.0.50   jump host = 10.20.9.10
# Policy: DEFAULT-DENY, least privilege, every permit justified, denies logged.

iptables -P FORWARD DROP                              # (1) fail-safe default

iptables -A FORWARD -m conntrack \
    --ctstate ESTABLISHED,RELATED -j ACCEPT           # (2) stateful return traffic

iptables -A FORWARD -s 10.30.0.40 -d 10.30.0.50 \
    -p tcp --dport 5432 -j ACCEPT                     # (3) app -> CDE db (5432) ONLY

iptables -A FORWARD -s 10.20.9.10 -d 10.30.0.0/24 \
    -p tcp --dport 22 -j ACCEPT                       # (4) jump host -> CDE SSH ONLY

iptables -A FORWARD -s 10.20.0.0/16 -d 10.30.0.0/24 \
    -j LOG --log-prefix "CDE-DENY: "                  # (5a) log every other attempt
iptables -A FORWARD -s 10.20.0.0/16 -d 10.30.0.0/24 \
    -j DROP                                            # (5b) and drop it

The discipline Sam imposed was not the syntax but the justification record. Every permit rule got a one-line entry in a rule register: who requested it, what business flow it enables, and when it was last reviewed. Rule 3's entry read: "Payment application (10.30.0.40) to CDE database (10.30.0.50/tcp 5432). Owner: Payments team. Sole legitimate inbound to the CDE database. Reviewed 2025-Q2." A rule whose justification no one could write was a rule scheduled for deletion.

The audit of the old ruleset taught a second lesson worth recording, because it shows how default-allow rots over time. Sam catalogued the corporate→CDE rules he inherited and traced each to its origin:

Three of the four inherited rules were either dangerous or far too broad, and only one described a real business need. This is the normal state of a default-allow ruleset that no one reviews: legitimate flows hide among accumulated exceptions, and an attacker needs only one of the broad ones. The rewrite did not add capability — it subtracted unjustified paths until only the necessary ones remained. That subtraction is the essence of least privilege on the wire.

🔄 Check Your Understanding: Of the four inherited rules above, the second (permit tcp any -> 10.30.0.0/24 dport 5432) might look almost harmless — it only allows one port. Why is it still a serious finding, and what could an attacker on the corporate network do with it that the scoped replacement (10.30.0.40 only) prevents?

⚠️ Common Pitfall: The broad permit ip any rule Sam found is the single most common firewall misconfiguration in real environments, and it almost always originates the same way: a 2 a.m. outage, a fast fix, and no cleanup. The defense is not heroics; it is process — a periodic rule review that forces every permit to be re-justified, so orphaned broad rules surface and die. The technology was never the weak point. The absence of a review process was.

Phase 3 — Layer 3: detection that watches both directions

A default-deny firewall decides what is allowed; it does not tell Marcus's SOC whether the allowed traffic is malicious. The pentester's traffic, once she was inside, used entirely permitted east-west paths. So Sam and Marcus designed detection to watch both directions, with deliberately different postures for each.

At the internet edge, they placed a signature-based IPS in-line. The edge is where known exploits arrive constantly and where blocking in real time is worth the risk; the IPS drops traffic matching high-confidence signatures for known attacks (the kind of signature that lit up across the industry during Log4Shell). They accepted the in-line risk knowingly: only high-confidence signatures were set to drop; noisier ones were set to alert only, so a false positive could not black-hole legitimate customer traffic to the online-banking portal.

For internal east-west traffic — the blind spot the pentest exploited — they deployed an out-of-band IDS sensor fed by a SPAN/mirror port on the core switch. It could not block (it sees only a copy), but blocking internal traffic was not the goal; seeing it was. The IDS ran both signature rules (for known internal-attack patterns like lateral SMB exploitation) and anomaly detection (for the novel, low-and-slow movement signatures alone would miss). Critically, they wrote a local policy signature aimed squarely at the kind of reconnaissance the pentester had performed:

alert tcp $CORP_NET any -> $CDE_NET ![22,5432] ( \
    msg:"MERIDIAN POLICY Corp host probing CDE on non-permitted port"; \
    flow:to_server; \
    flags:S; \
    threshold:type both, track by_src, count 10, seconds 30; \
    classtype:attempted-recon; \
    sid:9000023; rev:1; )

Read it: alert on TCP SYN packets (flags:S — connection attempts) from the corporate network to the CDE network on any port except 22 and 5432 (the only two the firewall permits), firing when one source makes 10+ such attempts in 30 seconds (threshold — a single stray packet is noise; a burst is a port scan). This is detection aligned with the firewall policy: the firewall drops these probes, and the IDS tells the SOC someone is making them. The combination — drop and alert — is exactly the defense-in-depth pairing the chapter argues for.

   Meridian detection placement:

   Internet ─►[ NGFW + in-line IPS ]─► core switch ─► zones (corp/CDE/guest)
                  (drops known exploits)   │
                                           │ SPAN/mirror (copy of east-west)
                                           ▼
                                        [ IDS sensor ] ── alerts ─► SOC ─► SIEM
                                        signatures + anomaly         (Ch.21 correlation)

Figure CS1.2 — Edge IPS blocks known north-south exploits in-line; an out-of-band IDS watches internal east-west traffic and alerts. Both feed the SOC, where Chapter 21's SIEM will correlate them.

🛡️ Defender's Lens: Notice the deliberate asymmetry in blocking authority. In-line blocking at the edge is acceptable because the traffic is untrusted and a stray drop is survivable. In-line blocking deep inside the network is far riskier — a false positive could sever a core banking flow — so internal detection is observe-only, and containment is handled structurally by segmentation (Layer 4) rather than by an IPS guessing in real time. Match the control's authority to the cost of its mistakes.

Marcus added one more analytical layer that paid off immediately: he insisted the edge IPS be tuned before go-live rather than after, because an IPS that black-holes legitimate traffic on day one destroys organizational trust in the whole project. His pre-deployment tuning ran the IPS in alert-only mode for two weeks against live edge traffic, captured every signature that fired, and sorted them by how often they hit benign traffic. The results were instructive:

   Edge IPS pre-deployment tuning (2 weeks, alert-only):

   Signature class            Fired   Benign?   Decision
   ───────────────────────────────────────────────────────────
   Known RCE exploit attempts  312    0%        -> set to DROP (high confidence)
   Outbound to known-bad C2    58     0%        -> set to DROP
   "Suspicious user-agent"     9,400  ~99%      -> ALERT only (mobile-banking app)
   Generic protocol anomaly    21,000 ~100%     -> DISABLE (pure noise on this link)

The "suspicious user-agent" signature was firing almost entirely on Meridian's own mobile-banking app, whose client string the vendor rule didn't recognize. Had Marcus enabled blocking on it, the IPS would have broken the bank's mobile app for every customer on go-live. This is the base-rate problem (§7.6) made operational: a signature that fires 9,400 times and is benign 99% of the time is not a control, it is an outage waiting to happen. Tuning first, blocking second.

Phase 4 — Layer 1: 802.1X NAC closes the branch jack

Now the literal hole. The pentester's rogue laptop got an IP because no switch port asked it to prove anything. Sam deployed 802.1X port-based network access control on branch and corporate switch ports. The design used the three roles directly: employee laptops became supplicants presenting a machine certificate (not a password, and never a bare MAC); each access switch became the authenticator, keeping ports closed to all but the authentication exchange; and Meridian's existing RADIUS service, checking against Active Directory / Entra ID, became the authentication server.

The policy assigned VLANs on success:

The last row is the one that defeats the pentester. A rogue laptop that cannot present a valid certificate now fails authentication and lands in the quarantine VLAN — a dead-end segment that reaches nothing but a remediation page. The branch jack still hands out an address, but the address is useless. For devices that genuinely cannot run a supplicant (printers, badge readers), Sam used MAC Authentication Bypass only inside tightly restricted segments, so that even if an attacker cloned a printer's MAC, the impersonated "printer" could reach only the print server — a deliberately small prize.

🔗 Connection: This is the network's first concrete step toward the zero-trust architecture of 🔗 Chapter 32. NAC verifies the device before granting access; certificate-based 802.1X verifies identity rather than mere presence on the wire. The principle — verify before trust, regardless of location — is exactly what zero trust generalizes from the switch port to every request in the environment.

Phase 5 — Layer 4: microsegmentation and the bastion

The final layer assumed all three above had failed: suppose an attacker does get a foothold on a valid corporate workstation (a phishing click, as in Chapter 1, needs no rogue hardware). On the old flat network, that foothold reached everything. Sam's microsegmentation plan applied default-deny between workloads, starting with the CDE and its most sensitive neighbors. Each workload was permitted to talk only to its genuine partners:

   Meridian CDE microsegmentation (default-deny between all; only these permitted):

   payment-app (10.30.0.40) ──tcp/5432──► CDE-db (10.30.0.50)
   CDE-db                    ── (no inbound except from payment-app) ──► X
   teller-ws                 ──tcp/443──► banking-app   (and print-srv)   ──► X to CDE
   admins                    ──► BASTION (10.20.9.10) ──tcp/22──► CDE hosts

   A foothold on teller-ws cannot reach CDE-db: no policy permits it.

Figure CS1.3 — CDE microsegmentation. Default-deny between every pair of workloads; only the few genuinely required flows are permitted. A compromised teller workstation is a dead end with respect to the CDE.

Crucially, Sam did not flip default-deny on overnight. Following the chapter's "observe first" discipline, he ran the bank's flow monitoring (the capability built in 🔗 Chapter 10) in observe-only mode for several weeks to map which workloads actually communicated, discovered two legitimate flows nobody had documented (a reporting job and a backup agent), wrote least-privilege policy from that evidence, and only then enforced. Enabling default-deny without that map would have broken production and forced the very broad exceptions that defeat the purpose.

The administrative path got special treatment. Rather than letting admins SSH into the CDE from their everyday workstations — any of which could be the phished foothold — all CDE administration was forced through a single bastion host (10.20.9.10, the only source permitted by firewall rule 4 and by the microsegmentation policy). The bastion was hardened, required phishing-resistant MFA, and recorded every session. It concentrated administrative risk onto one heavily defended, fully instrumented box instead of scattering it across the fleet.

⚠️ Common Pitfall: Microsegmentation is a project, not a checkbox. The enforcement tooling is the easy part; the hard part is knowing which flows are legitimate. Sam's discipline — observe, derive policy from evidence, then enforce — is what separates a microsegmentation rollout that holds from one that gets rolled back after it breaks the quarter-end reporting job nobody knew existed.

Phase 6 — Operationalizing: from a project to a standing capability

A control that is built once and never tended decays — the same lesson the rotting default-allow ruleset taught in reverse. Sam and Marcus knew the four layers would only stay effective if the program treated them as living things, so the final deliverable was the operating discipline around them, not just the configuration. Three commitments went into the program document:

1. Quarterly firewall rule review. Every permit rule must be re-justified from the rule register, or it is removed. This is the process that would have caught the permit ip any rule years earlier — the technology never failed, the review was missing. Elena Vasquez (GRC) tied this to the bank's PCI-DSS obligation, which explicitly requires periodic firewall ruleset review, turning a security good-practice into a compliance artifact an examiner can check.
2. Detection-as-policy alignment. Whenever a firewall rule changes, the corresponding IDS signature is reviewed too, so that the SOC always alerts on the probes the firewall drops. A rule and its detection are maintained as a pair.
3. A small set of health metrics the SOC reports monthly, so the controls' effectiveness is visible rather than assumed:

The last metric is the proof that the design is holding: if any administrative connection reaches a CDE host from a source other than the bastion, either a rule is wrong or someone has found a bypass — and the metric surfaces it immediately. Metrics turn "we built it" into "we know it works," which is the language the board and the examiner both speak — and the foundation of the full metrics-and-reporting work the program builds toward in Part VIII.

🔗 Connection: Every artifact in this phase feeds forward. The flow map and detection design become inputs to the network monitoring of 🔗 Chapter 10; the "verify before access" stance of NAC and the microsegmentation policy become the foundation of the zero-trust roadmap in 🔗 Chapter 32. Meridian did not just close one hole — it laid the groundwork for the architecture the whole industry is moving toward.

The Outcome

A follow-up penetration test, six months later, told the story. The tester repeated the branch-jack attack: she plugged into a lobby port and this time landed in the quarantine VLAN, able to reach nothing but a remediation page. She tried a phished foothold on a teller workstation (Meridian's red team granted her one to test the inner layers) and found she could reach the banking application and the print server — and nothing in the CDE, because no microsegmentation policy permitted it. Her probes toward the CDE database were dropped by the firewall and generated SID 9000023 alerts in the SOC within seconds. The bastion host's session recording captured her one attempt to reach it. She wrote in her report: "The interior walls are now real. Every path I tried either dead-ended or announced itself."

The program document gained its perimeter-and-segmentation standard: default-deny on every inter-zone firewall with a justification register, edge IPS plus internal IDS feeding the SOC, 802.1X NAC with quarantine, and CDE microsegmentation behind a bastion. None of it was a single purchase. All of it was design — the kind an examiner could read and a board could fund.

🔄 Check Your Understanding: The follow-up tester, given a foothold on a teller workstation, still reached the banking application and print server (just not the CDE). Is that a failure of the design? What would it take to shrink even that access further, and what is the cost? (Hint: consider per-workload policy on the corporate segment too, and the "observe first" effort that requires.)

Discussion Questions

1. Sam set only high-confidence signatures to drop at the edge IPS and left noisier ones as alert-only. Argue for and against a more aggressive posture that blocks on more signatures. What is the worst-case failure of each choice for a bank's online-banking traffic?
2. The internal detection was deliberately observe-only (IDS), with containment handled structurally by microsegmentation rather than by an in-line IPS. When, if ever, would you place an IPS inside the network, and what would have to be true to make that safe?
3. The quarantine VLAN reaches "only a remediation server." A skeptic asks: why give a failed device any access at all — why not drop it completely? Make the case for the remediation VLAN, and name a risk it introduces.
4. Sam refused to enable microsegmentation without weeks of flow observation first. A manager under audit pressure wants it done this week. How do you explain the risk of skipping the observation phase in business terms the manager will accept?
5. Every layer in this design assumes the one above it failed. Identify, for each of the four layers, the specific failure of the layer above that it is designed to catch.

Your Turn

Take a network you know (your employer's, your school's, or a small business you invent with 4–6 workloads) and reproduce Sam's four-layer design at a high level. (1) Write a default-deny ruleset for one inter-zone boundary, with every permit justified in a phrase. (2) Decide where you would place an IPS in-line versus an IDS out-of-band, and why. (3) Sketch an 802.1X NAC policy with at least three device classes and the VLAN each lands in. (4) Draw a microsegmentation map for your most sensitive workload, listing only the flows you would permit. State, in one sentence per layer, what failure of the layer above each one catches. Keep it to two pages.

Key Takeaways

• A strong edge firewall is not a security program; the branch-jack attack proved that a perimeter you can step around — physically, by phishing, or via a vendor — protects nothing on the trusted side.
• Default-deny with a justification register is the firewall standard; the most dangerous real-world misconfiguration is the broad permit ip any added in an outage and never reviewed away.
• Match blocking authority to the cost of mistakes: in-line IPS at the untrusted edge, observe-only IDS for internal east-west traffic, with containment handled structurally by segmentation.
• Align detection with policy: a signature that alerts on probes the firewall drops turns a blocked attack into a visible one.
• 802.1X with certificates and a quarantine VLAN closes the admission gap: an unverified device gets an address that reaches nothing.
• Microsegmentation + a bastion make "inside the network" stop meaning "trusted"; observe real flows first, derive least-privilege policy from evidence, then enforce — it is a project, not a checkbox.
• Defense in depth on the network means many small barriers, each assuming the last has failed — and the proof is a follow-up test where every attacker path either dead-ends or announces itself.