Case Study 1: Rebuilding Meridian's Branch Wireless

"The guest WiFi and the teller workstations were on the same network. I want to be able to say, truthfully, that a customer in the lobby cannot reach a single thing that matters. Right now I can't." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

When Meridian's first risk assessment (Chapter 1) ran, one finding scored a 9 and embarrassed everyone who read it: at most branches, the guest WiFi shared a network segment with the teller workstations. A customer paying a bill in the lobby — or anyone impersonating the guest network from the parking lot — sat on the same broadcast domain as the machines that touch customer accounts. This case study follows security engineer Sam Whitfield and junior analyst Theo Brandt as they redesign branch wireless across Meridian's 120 branches: replacing a flat, shared-passphrase network with a segmented, enterprise- authenticated design, and proving the isolation holds. It is a design-and-build case — you will make architecture decisions, write firewall rules, and audit a configuration — and it is the concrete payoff of §8.3 and §8.6. All systems, addresses, and figures are constructed for teaching (Tier 3).

Skills applied: wireless protocol selection (WEP→WPA3); enterprise authentication design (802.1X/EAP, EAP-TLS vs. PEAP); SSID-to-VLAN mapping; guest isolation and default-deny firewall design; rogue-AP/evil- twin detection planning (WIDS); auditing a wireless configuration; tying wireless controls to the segmentation of Chapter 6 and the risk model of Chapter 1.

Background

Meridian's branch wireless had grown the way most things grow without a policy: one access point at a time, configured by whoever set up the branch, with settings copied from the last branch. The result, as Sam discovered when he pulled configurations from forty branches, was an archaeological record of a decade of decisions nobody made on purpose:

The passphrase for most branches, Sam noted grimly, was written on a laminated card at the front desk so staff could read it to customers — which meant the staff network passphrase, the one that reached internal systems on the shared VLAN, was effectively public. "We don't have a wireless network," Sam told Dana. "We have a wireless network and a guest network, and they're the same network, and the password is on a card anyone can photograph."

Dana's charge was specific and became the success criterion for the project: a customer or attacker on the wireless network — guest or staff SSID — must be unable to reach the teller workstations, the banking applications, or customer data, and we must be able to prove it.

The Design

Phase 1 — Choosing the protocol and authentication

The team started with the two decisions that everything else depends on: what protocol, and how users authenticate. The protocol decision was the easy one, straight from §8.2's rule: WPA3 on all new and upgradeable hardware; WPA2-AES only where a device genuinely cannot do WPA3, with a documented expiry date; WEP and WPA(TKIP) prohibited. The single WEP segment was scheduled for immediate replacement, not "sometime" — Theo flagged it as the one critical-severity finding in the inventory.

The authentication decision was where the real engineering happened, and the team reasoned it out exactly as §8.3 lays out. The shared passphrase had to go, because it created three problems Dana's charge could not tolerate: it could not be revoked for a departing teller without re-keying every device, it gave no record of who connected, and — as the laminated card proved — it leaked. The answer was WPA-Enterprise with 802.1X, putting each user's credential behind Meridian's existing Active Directory / Entra ID via a pair of RADIUS servers.

That left the EAP-method choice, which Sam and Theo debated honestly:

Option A — EAP-TLS (mutual certificates):
   + No password to phish, capture, or crack — credential is a private key on the device.
   + Strongest protection against evil-twin credential harvesting.
   - Requires issuing/managing a certificate on every staff device (needs PKI + device management).
   Verdict: the target state for staff devices, which are bank-issued and managed.

Option B — PEAP (AD password in a TLS tunnel):
   + Easy: staff use their normal AD password; no per-device certificate.
   - DANGER: if a client skips server-certificate validation, an evil twin harvests the AD password.
   Verdict: acceptable ONLY with rigorously enforced server-certificate validation, as a fallback
            for any device that cannot do EAP-TLS.

They chose EAP-TLS as the standard for staff wireless, because Meridian's staff devices are bank-issued and centrally managed, so pushing a client certificate to each one was achievable through the same management tooling that already configured them. PEAP — with mandatory, audited server-certificate validation pinned to Meridian's RADIUS certificate — was kept only as a documented fallback for a handful of legacy devices, with a migration deadline. Theo captured the reasoning in the project log: "PEAP isn't insecure; PEAP-with-validation-off is insecure, and the only way to guarantee validation is on across 120 branches is to not depend on it — so EAP-TLS by default."

🛡️ Defender's Lens: Notice the team did not pick the most secure option reflexively; they picked the most secure option they could actually operate correctly at scale. EAP-TLS was right for Meridian specifically because the device fleet was managed enough to support certificates. For an organization with unmanaged or BYOD devices, the honest answer might be PEAP-with-enforced-validation, accepting a different risk tradeoff. The skill is not memorizing "EAP-TLS is best" — it is matching the control to what the environment can sustain, because a control you cannot operate reliably is worse than a simpler one you can.

Phase 2 — Three SSIDs, three segments

With protocol and authentication settled, the team built the segmented design from §8.6. Three SSIDs, each mapped to its own VLAN and firewalled segment, for the three populations:

   SSID "Meridian-Staff"  → WPA3-Enterprise (802.1X / EAP-TLS) → VLAN 10  STAFF SEGMENT
   SSID "Meridian-Guest"  → WPA3 Enhanced Open + captive portal → VLAN 90  GUEST SEGMENT
   SSID "Meridian-Ops"    → WPA3-Personal, strong unique PSK     → VLAN 50  OPS/IoT SEGMENT

The staff SSID authenticates each user via RADIUS, which returns not just "accept" but the VLAN assignment — every authenticated teller lands on VLAN 10, the staff segment, automatically. The guest SSID uses Enhanced Open so even password-free guest traffic is encrypted against passive sniffing, sits behind a captive portal for terms-of-use, and has client isolation enabled so guests cannot attack each other. The ops SSID quarantines the branch's printers, signage, and cameras — the weak, unpatchable devices of Chapter 14 — on a segment of their own.

Phase 3 — The firewall rules that are the actual security

Sam was blunt with the team about where the security really lived: "The SSIDs and VLANs are just labels. The security is the firewall rules between the segments. If those are wrong, everything else is theater." The team wrote the cross-segment policy as explicit default-deny rules (the Chapter 7 discipline), and these rules — not the encryption, not the authentication — are what satisfy Dana's charge:

# Branch wireless segment policy (default-deny; only explicit allows listed)

STAFF (VLAN 10):
   ALLOW  staff -> internal banking applications   (specific hosts/ports, least privilege)
   ALLOW  staff -> internet (proxied)
   DENY   everything else

GUEST (VLAN 90):
   ALLOW  guest -> internet (direct, filtered)
   DENY   guest -> VLAN 10 (staff)         <-- the rule that protects the tellers
   DENY   guest -> VLAN 50 (ops)
   DENY   guest -> any internal subnet
   (client isolation: guest -> guest also denied)

OPS (VLAN 50):
   ALLOW  ops devices -> their specific management server only
   DENY   ops -> internet          <-- a compromised camera can't phone home
   DENY   ops -> VLAN 10 (staff)
   DENY   ops -> VLAN 90 (guest)

# DEFAULT: deny any path not explicitly allowed above.

🔄 Check Your Understanding: The single most important line in the entire design is DENY guest -> VLAN 10 (staff). Explain, using Chapter 1's offense/defense asymmetry, why the team treats this one firewall rule as more important than the choice of WPA3 or the WIDS deployment. (Hint: which controls are "be right every time" bets, and which control changes what happens when one of those bets is lost?)

Phase 4 — Detection and the deauth/evil-twin defenses

Prevention is not enough on a medium an attacker can transmit into freely, so the team added the detective layer. They enabled 802.11w (Protected Management Frames) everywhere — automatic with WPA3 — which neutralizes the deauthentication attacks that enable handshake capture and evil-twin luring (§8.4). And they deployed a WIDS using the listening capability already built into the new enterprise access points, with two headline detections:

ROGUE AP:    an AP seen on the air whose BSSID is not in the authorized inventory
             AND which is determined to bridge to an internal VLAN  -> CRITICAL alert
EVIL TWIN:   a beacon advertising a Meridian SSID (e.g. "Meridian-Staff")
             from a BSSID not on the authorized allowlist for that SSID -> HIGH alert
DEAUTH FLOOD: an abnormal burst of deauthentication frames              -> investigate (leading indicator)

Theo wrote the branch runbook for a rogue-AP alert: confirm the alert, locate the radio with a signal-strength walk-down, physically remove it, identify the wall jack and disable the switch port, and — if it was an employee's well-meaning consumer AP — handle it as an awareness issue, not a disciplinary one (the awareness program is Chapter 30).

Phase 5 — Auditing the result with wifiaudit.py

Before declaring victory, the team ran every branch's new configuration through the wifiaudit.py tool from this chapter's checkpoint, so that "we fixed it" was a machine-checkable claim and not a hopeful one. A corrected branch produced clean output:

Branch-042-Staff:  PASS
Branch-042-Guest:  PASS
Branch-042-Ops:    PASS

And the audit immediately earned its keep: three branches came back with a CRITICAL: guest network not isolated from internal segments finding, because the VLAN change had been applied to the access point but the corresponding firewall rule had not yet been pushed. The tool caught the gap between "looks done" and "is done" — exactly the failure mode of large rollouts. Theo's note: "The audit isn't bureaucracy. It's the difference between believing the guest network is isolated and knowing it is."

⚠️ Common Pitfall: The three branches that failed the audit illustrate the most dangerous moment in any segmentation project: the window where the labels (SSID, VLAN) are changed but the enforcement (firewall rules) is not. During that window, the network looks correctly segmented in the AP configuration but is actually still flat. A design is only as good as the rule that enforces it, and a rollout is only safe if you verify enforcement, not configuration. Always audit the firewall, not just the wireless settings.

Discussion Questions

1. The team chose EAP-TLS over PEAP for staff wireless, but explicitly said PEAP-with-enforced-validation would be the right choice for a different organization. What characteristics of Meridian's environment made EAP-TLS the correct default here? When would you not recommend it?
2. Sam argued that "the security is the firewall rules between segments, not the SSIDs and VLANs." Do you agree that the strong authentication (EAP-TLS) is secondary to the segmentation? Argue both sides — what does each control protect that the other does not?
3. The single WEP segment (a barcode-scanner network) was the only critical-severity protocol finding. Why might such a forgotten, "low-importance" network actually be a serious risk, and how does it connect to the rogue-AP problem (an unauthenticated bridge onto the internal network)?
4. The wifiaudit.py tool caught three branches where the VLAN was changed but the firewall rule was not. Beyond running the audit, what process change would prevent that gap from occurring in the first place? (Consider the order of operations in the rollout.)
5. Meridian offers guest WiFi as a customer amenity. A branch manager asks to "temporarily" allow a guest-segment tablet to reach an internal printer for a customer event. How should Sam respond, and what does saying yes do to the entire security model of guest WiFi?

Your Turn

Take a multi-population environment you know — a university building (students, faculty, lab equipment), a hotel (guests, staff, building systems), or a clinic (clinicians, patients, biomedical devices) — and reproduce this design. Specify: (1) the wireless populations and their trust levels; (2) the SSID → protocol → authentication → VLAN mapping for each; (3) the complete default-deny firewall policy between segments, identifying the single most important deny rule; and (4) the two WIDS detections you would prioritize. Then write the one sentence you would give your CISO completing: "An attacker who fully compromises our [guest/most-exposed] wireless can reach ______ and nothing else." Keep it to one page.

Key Takeaways

• A flat wireless network with a shared passphrase is the common starting state and the core problem: no separation of trust, un-revocable credentials, and a passphrase that leaks.
• Protocol first, then authentication: WPA3 (WPA2-AES only as a dated exception, WEP/WPA prohibited), then WPA-Enterprise (802.1X) to replace the shared passphrase with per-user identity.
• Match the EAP method to what you can operate: EAP-TLS (mutual certificates) where devices are managed; PEAP only with rigorously enforced, audited server-certificate validation.
• The SSIDs and VLANs are labels; the firewall rules between segments are the security. DENY guest -> staff is the rule that satisfies "a customer cannot reach the tellers."
• Add the detective layer for a medium you cannot fence: 802.11w/PMF to stop deauth, and a WIDS for rogue APs and evil twins — with a runbook for response.
• Audit enforcement, not configuration. The dangerous window in any segmentation rollout is when the labels are changed but the firewall rules are not; a config-audit tool (wifiaudit.py) catches it.
• Segmentation is the keystone: every other wireless control may fail, and the default-deny isolation is the layer that makes wireless compromise survivable — defense in depth, applied to the air.