Case Study 1: The Lobby Camera and Meridian's Device-Fleet Reckoning

"We didn't get breached. We got lucky. The difference is a sentence I never want to say to a regulator again." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

A routine internal review at Meridian Regional Bank turned up a $40 internet-connected camera on a branch's flat network — bought with a corporate card, configured with the factory password admin/admin, unknown to the security team, and one short pivot away from the teller workstations. Nothing bad had happened. That was the problem: nothing bad had happened yet, and only because no attacker had found the camera first. This case study follows security engineer Sam Whitfield and GRC analyst Elena Vasquez as they convert a near-miss into a program: a fleet-wide device discovery, a default-credential and inventory triage using the iotinv.py tool from this chapter, a segmentation redesign for both the messy branch-IoT population and the high-stakes ATM fleet, and a procurement-and-ownership policy so the next forty-dollar camera cannot repeat the story. It is a design-and-build case: the deliverables are an inventory, a segmentation architecture, a monitoring rule set, and a policy. All names, figures, logs, and addresses are constructed for teaching (Tier 3); IPs use documentation ranges only.

Skills applied: device discovery and inventory; default-credential triage; shadow-IoT detection; device segmentation design (default-deny, minimal allow-lists); monitoring-rule design for predictable devices; hardening ATMs where the platform permits and compensating with containment where it does not; translating a technical gap into a governance/procurement control.

Background

Meridian runs ~120 branches across three Midwestern states and ~200 ATMs in the field. Branch technology had grown the way it grows everywhere: organically, locally, and without a gatekeeper. A branch manager who wanted a lobby camera bought one. A facilities contractor who replaced an HVAC unit connected its controller to "the network" because the manual said to. Printers, badge readers, electronic door locks, conference-room displays, and a long tail of devices accumulated over years — many on the same flat network as the teller workstations and the branch file server, because nobody had ever said they shouldn't be.

The camera that started this was found almost by accident. During an unrelated review of one Illinois branch's switch configuration, Sam noticed a device with an unfamiliar MAC address pulling a small, steady stream of traffic to a local server and, occasionally, reaching out to the internet. He traced the port, walked to the wall, and found a consumer security camera mounted above the back-office door. He logged into it from his laptop on the first try: admin/admin. The web interface was reachable from anywhere on the branch network. The firmware build date predated the bank's purchase of the device by three years, and the manufacturer's support page listed no updates at all.

Sam took the finding to Dana with a blunt framing: "This isn't a camera problem. It's an inventory problem. If we don't know this camera exists, how many others don't we know about — and what are they sitting next to?" Dana authorized a fleet-wide device reckoning and gave the work the same rule she had given the first risk assessment: be honest about what we don't know.

🔗 Connection: This is Chapter 1's foundational truth surfacing again — you cannot protect what you do not know you have — but applied to a device population that actively resists being counted, because so much of it arrived through a corporate card rather than a procurement process. The first risk assessment built an asset inventory of systems; this builds one of devices, and it is the precondition for every control that follows.

The Engagement

Phase 1 — Discovery: finding what nobody catalogued

You cannot segment, monitor, or harden a device you have not found, so the work began with discovery, not defense. Sam ran a passive network-discovery sweep across a representative set of branch segments — watching traffic and fingerprinting devices rather than aggressively scanning, to avoid disrupting anything fragile. The results, even on a sample of branches, were sobering. A single mid-size branch turned up:

DISCOVERED DEVICES — Branch BR-041 (sample)
  managed (known to UEM/CMDB):
    6 x teller workstation      6 x managed laptop      1 x branch file server
  UNMANAGED / not in any inventory:
    3 x IP camera (1 = the original; 2 more found)
    2 x badge reader            1 x HVAC controller
    2 x network printer         1 x smart conference display
    1 x smart speaker (employee-brought, personal)
    2 x personal Wi-Fi printer (employee-brought)
    1 x thermostat (documented firmware CVE, no patch available)

The smart speaker and the personal printers were textbook shadow IoT — devices employees had attached with no approval, no inventory entry, and no thought to security. The thermostat was the nightmare case: a real, publicly documented firmware vulnerability with no available patch, sitting on the same flat segment as everything else. None of these devices had been segmented, because nobody had known to segment them. None were monitored, because nobody knew they existed.

Sam fed the discovered device list into iotinv.py — the inventory-and-flag tool built in this chapter's checkpoint — to produce a triage view. A representative slice of the input and the tool's output:

# input (illustrative): id, user, password, managed
cam-br041-01  admin  admin       no
cam-br041-02  admin  admin       no
cam-br041-03  admin  ''          no
hvac-br041    admin  password    no
printer-br041 root   root        no
disp-br041    --     --          yes   (managed display, vendor-locked)
thermo-br041  admin  admin       no

# iotinv.inventory(...) output (hand-traced):
total=7
default_cred=['cam-br041-01', 'cam-br041-02', 'hvac-br041',
              'printer-br041', 'thermo-br041']
unmanaged=['cam-br041-01','cam-br041-02','cam-br041-03',
           'hvac-br041','printer-br041','thermo-br041']

(Note that cam-br041-03 had its password set to empty '', which is not in the known-default set the tool ships with — the pair would need to be admin/'' to flag — so it appears as unmanaged but not as a default-cred offender. That gap is itself a lesson: the default-credential database must be maintained, and "no password at all" deserves its own check. Sam noted it as a tool improvement.)

🛡️ Defender's Lens: In one pass, the tool did the single most valuable thing in device security: it turned an invisible population into a ranked work list. Five devices on default credentials are "anyone-who-reaches-them-is-admin" emergencies — a guess-and-you're-in problem fixable in minutes for the ones whose passwords can be changed. Six unmanaged devices are candidates for the contained IoT segment. The thermostat is flagged both ways and carries an unpatchable vulnerability, which makes it the clearest "cannot fix — must contain" case in the building.

Phase 1.5 — Scoping the near-miss: what the camera could have become

Before designing controls, Sam did what a good responder always does after a near-miss: he scoped the actual exposure, soberly and concretely, so the remediation would be sized to the real risk rather than to anxiety. The question was not "is a camera scary?" but "given where this camera sat and what it could reach, what was the realistic worst case, and how close did we come to it?" He reconstructed the exposure path defensively — mapping what an attacker could have done, in order to know which controls to build, never to build an attack:

EXPOSURE PATH (reconstructed for defense, BR-041, pre-remediation)
  1. Initial access:  camera reachable from the branch LAN; default creds admin/admin.
                      (Anyone on that flat network — including a guest who bridged on —
                       could log in as administrator in seconds.)
  2. Foothold:        camera's embedded OS exposes a shell / scripting interface.
                      (Many such devices do; it becomes a small Linux box on your LAN.)
  3. Reconnaissance:  from the camera, the local /24 is fully reachable — flat network.
                      (Teller workstations, branch file server, printers all in scope.)
  4. Lateral movement: pivot toward a teller workstation or the file server.
  5. Objective:       reach branch data / stage toward the wider network.
  Elapsed, if attempted: minutes. No exploit code required at step 1 — just a password
  that was printed in a manual.

What made the near-miss a near-miss rather than an incident was simply that no attacker had found the camera first — not any control the bank had in place. That is an uncomfortable thing to write in a finding, and Sam wrote it anyway, because the value of the scoping exercise is precisely its honesty: the only thing standing between this camera and a branch compromise was luck, and luck is not a control. The scoping also clarified the remediation priorities. Step 3 — "the local /24 is fully reachable" — was the load-bearing weakness; remove the flat network and steps 4 and 5 become impossible regardless of steps 1 and 2. That insight pointed straight at segmentation as the highest-value fix, with credential rotation as the fast first-aid and monitoring as the safety net. The architecture in Phase 3 follows directly from this scoping.

🔄 Check Your Understanding: Sam's scoping concluded that segmentation (removing the flat network) was a higher-value fix than the credential change, even though the credential change was faster and easier. Why? (Hint: which weakness, if removed, makes the most of the exposure path collapse — and which weakness will still be there when the camera's next, unpatchable vulnerability is discovered?)

Answer

Changing the password fixes step 1 (initial access via default creds), but the camera's firmware is ancient and unpatchable, so a future vulnerability could re-open initial access at any time — the credential fix is not durable. Segmentation removes step 3 (lateral reachability): even if an attacker regains a foothold on the camera through some future flaw, a contained device on a tiny allow-list can reach almost nothing, so steps 4–5 collapse. Segmentation neutralizes the largest and most durable part of the exposure, which is why it is the higher-value control even though it is more work than rotating a password.

Phase 2 — Triage: fix-in-minutes vs. cannot-fix-must-contain

Sam and Elena sorted every discovered device into one of four buckets, because the right control depends entirely on which bucket a device falls into:

The discipline here is the chapter's core lesson made operational. The cameras and printer were "fix-in-minutes": change the password, and a near-certain compromise becomes merely a risk to manage. The thermostat was the opposite — there was no password change or patch that would make it safe, so the only move was to change the consequences of its compromise. The shadow devices were removed outright and became the motivating examples for the policy in Phase 4. Sam resisted the temptation to treat every device the same; matching the control to the bucket is what separates a real remediation from a checkbox.

⚠️ Common Pitfall: Changing default passwords and declaring victory. Sam was explicit with the team: rotating credentials on the cameras was necessary but not sufficient. The camera's firmware was still ancient and unpatchable; a future vulnerability could bypass the password entirely. Credentials are the fix-in-minutes layer; segmentation and monitoring are the layers that hold when the credential layer is eventually defeated. Treating the password change as the whole job would have rebuilt the same false sense of security that let the camera sit unnoticed for nine months.

Phase 3 — Segmentation: designing the fence

With devices discovered and triaged, Sam designed the segmentation that would contain the population he could not harden. He started from the rule of thumb that governs the whole chapter: every cross-segment path is denied unless a specific business need justifies allowing it, and the IoT segment's allow-list should be the shortest in the building. The branch architecture he standardized:

            MERIDIAN BRANCH — STANDARDIZED SEGMENTATION (per branch)
                    default-deny between every segment

  ┌──────────────────────────────┐      ┌──────────────────────────────┐
  │ CORPORATE (managed)          │      │ IoT / FACILITIES (contained) │
  │  tellers, file server,       │  ✗   │  cameras, badge readers,     │
  │  managed laptops (UEM)       │◄────►│  HVAC/UPS, printers, display │
  │  10.41.10.0/24               │denied│  10.41.30.0/24               │
  └───────────────┬──────────────┘      └───────────────┬──────────────┘
                  │ allow: business apps                 │ allow-list (the shortest in the branch):
                  │ to core only (north)                 │   cameras   → 10.41.30.10 (NVR) :554
                  ▼                                       │   badge rdr → 10.41.30.11 (ACS) :443
  ┌──────────────────────────────┐      │   HVAC      → 10.41.30.12 (BMS) :443
  │ CARDHOLDER DATA ENV (CDE)    │      │   printers  → 10.41.30.13 (print) :9100
  │  POS terminals               │  ✗   │   INTERNET  → DENY (all of the above)
  │  10.41.20.0/24  (PCI scope)  │denied│
  │  no path from IoT or guest   │◄────►│  ┌────────────────────────────┐
  └──────────────────────────────┘      │  │ GUEST / BYOD-PERSONAL Wi-Fi│
                                         │  │ customers + personal side  │
                                         │  │ 10.41.99.0/24 internet-only│
                                         │  │ NO path to any internal net│
                                         │  └────────────────────────────┘

Figure CS14.1 — Meridian's standardized per-branch device segmentation. The contained IoT/facilities segment (10.41.30.0/24) permits each device class exactly one destination on the local services subnet and denies the internet entirely; the cardholder data environment is unreachable from IoT or guest; guest and BYOD-personal traffic is internet-only with no internal path.

Three design decisions are worth drawing out, because each is a deliberate application of the chapter:

• The IoT segment denies the internet by default. This single rule is the highest-value line in the ruleset. The original camera had been reaching the internet; with outbound internet denied, a compromised camera cannot phone home to an attacker's command-and-control server, cannot be enrolled into a botnet, and cannot exfiltrate. The vulnerability survives; its usefulness to an attacker collapses.
• Each device reaches exactly one server. A camera reaches the network video recorder and nothing else — not another camera, not the badge controller, not a teller workstation. If a camera is compromised, the attacker inherits the camera's reachability: one server, on one port. Lateral movement is designed out.
• The cardholder data environment is walled off entirely from both IoT and guest, which is not only good architecture but a PCI-DSS requirement. The flat network that let Sam's hypothetical attacker pivot from the camera to the tellers is gone; there is no path from the least-trusted devices to the most sensitive.

Phase 4 — Monitoring and the procurement gate

Segmentation limits where a compromised device can go; monitoring ensures the team notices when one tries. Sam tuned a small, high-value rule set that exploited exactly the property that makes IoT painful to own but easy to watch — its predictability:

DETECTION RULES — branch IoT segment (plain-language)
  R1: ALERT if any host in 10.41.30.0/24 connects to a destination
      NOT on its device-class allow-list.            (compromise / misconfig)
  R2: ALERT if a new device (unknown MAC/fingerprint) appears
      on any branch segment.                          (shadow IoT arriving)
  R3: ALERT if any 10.41.30.0/24 host attempts an OUTBOUND
      internet connection.                            (C2 / exfil attempt)
  R4: ALERT on a sustained increase in outbound bytes from a
      normally low-volume device (e.g., a camera).    (exfil / botnet)

These rules are cheap and quiet precisely because the devices are boring. A camera that has spoken only to the recorder for months will never legitimately trip R1, R3, or R4, so when it does, the signal is real. Contrast this with trying to baseline a human's laptop, where "normal" is a thousand changing destinations. Sam made the point to the SOC explicitly: the more constrained a device's legitimate behavior, the more reliable its monitoring — and IoT's rigidity, the source of so much of its pain, is here a gift.

Finally, Elena addressed the root cause, which was never technical. The lobby camera existed because no policy required a connected device to be approved, inventoried, and owned before it went on a network. She drafted the device-onboarding gate that became part of Meridian's mobile/IoT policy — this chapter's program increment:

MERIDIAN CONNECTED-DEVICE ONBOARDING GATE (required before a device goes live)
  1. Approval: a named owner requests the device; security reviews the class.
  2. Inventory: device recorded (model, firmware, owner, branch, segment) in the CMDB.
  3. Credentials: default credentials changed (or device rejected if unchangeable
     AND it exposes a reachable management interface that matters).
  4. Placement: device assigned to the correct segment; allow-list entry added.
  5. Monitoring: device's expected behavior registered so deviations alert.
  No approval + inventory + segment = the device does not go on the network.

⚖️ Authorization & Ethics: Note that the guest/BYOD-personal segment treats the personal side of employees' phones as fully untrusted and internet-only — which protects the bank and respects the employee. The bank gains no visibility into personal traffic and no path from it into internal systems; the employee's personal life stays personal. The same boundary that contains an untrusted device also honors a privacy line, which is exactly the dual purpose containerization and segmentation are meant to serve.

Outcome

Across the rollout to all 120 branches, the discovery sweeps found cameras, printers, badge readers, and a recurring scatter of shadow devices — including several more unpatchable controllers like the BR-041 thermostat. Each was triaged into its bucket: credentials fixed where possible, unmanageable devices contained on the IoT segment with the internet denied, shadow devices removed, and a handful of managed-capable devices enrolled. The ATM fleet (treated in detail below) was confirmed on its own isolated, monitored segment. The procurement gate stopped the inflow of new shadow IoT at the source.

The honest framing Dana used with the board was not "we fixed it." It was: "We found the devices we didn't know we had, we contained the ones we can't fix, we're watching all of them, and we put a gate in front of the next one. The lobby camera is now the least dangerous device in the building, because it can reach exactly one server and we'd see it the instant it tried to reach anything else." That is what a mature answer to an unfixable problem sounds like.

A note on the ATMs

Meridian's ~200 ATMs got the disciplined, high-stakes version of the same four moves, because an ATM combines the stakes of a core financial system (it dispenses cash, reads cards, is PCI-scoped) with the rigidity of an embedded device (an older special-purpose OS, vendor-maintained, not freely patchable). The team: (1) inventoried every ATM — location, model, OS, firmware, responsible vendor, segment — and reconciled continuously, because a cash-dispensing device missing from inventory is an unacceptable blind spot; (2) segmented the ATMs onto a dedicated isolated segment reaching only the transaction-processing and management hosts they require, never the corporate network or the internet; (3) hardened where the platform allowed — application allowlisting so only the ATM software runs, unnecessary services disabled, default accounts removed — and where patching on demand was impossible, tracked vendor patch cycles as a managed third-party risk while segmentation and monitoring carried the load; and (4) monitored for any deviation from the ATM's narrow, predictable behavior, integrating physical-tamper signals (skimmer/enclosure sensors) into the same alerting. The ATMs and the branch IoT look different on the surface, but they are governed by one playbook: inventory everything, manage what you can, contain and watch what you cannot, and gate procurement so the problem stops growing.

To make the ATM monitoring concrete, consider an illustrative day of one ATM's egress, where the device's entire legitimate behavior is a short, repeating list of destinations:

ATM-0042 expected behavior (baseline):
  -> 10.20.5.10  :443   transaction switch        (every txn)
  -> 10.20.5.11  :443   management / health server (hourly check-in)
  -> 10.20.5.12  :443   software-distribution host (maintenance window only)
  Everything else: DENY (no corporate net, no internet, no peer ATMs).

ALERT example (hand-traced):
  14:02:17  ATM-0042 -> 198.51.100.40 :443   <-- NOT on baseline. ESCALATE.
            (an ATM reaching an unknown external host is, on this device,
             among the highest-signal events in the entire environment)

The contrast with a human endpoint is the whole point. If a laptop reached 198.51.100.40, an analyst would shrug — laptops reach unfamiliar hosts constantly. When ATM-0042 does it, it is an emergency, because the ATM has reached exactly three internal hosts and nothing else for its entire service life. The narrowness that makes an ATM rigid and hard to patch is the same narrowness that makes its monitoring nearly false-positive-free. This is why the team could afford a strict, paranoid rule set on the ATM and ATM-area camera segments that would have been unworkable anywhere people typed.

🛡️ Defender's Lens: Notice the recurring lesson across both the cameras and the ATMs: the more constrained a device's legitimate behavior, the cheaper and more reliable its monitoring. A defender who internalizes this stops seeing IoT/embedded rigidity as purely a liability and starts using it — the very predictability that makes these devices impossible to update makes them trivial to baseline and alert on. The same property that is your enemy at patch time is your ally at detection time.

Discussion Questions

1. Sam insisted that changing the cameras' default passwords was "necessary but not sufficient." Build the argument for why, using the idea of layered defense. What specifically still threatened the cameras after the password change, and which controls addressed that?
2. The thermostat had a real, unpatchable firmware vulnerability. Walk through the reasoning that led the team to keep it in service rather than rip it out. Under what circumstances would removal be the right call instead?
3. Detection rule R3 ("alert on any outbound internet connection from the IoT segment") would be unworkable on a corporate user segment but is ideal on the IoT segment. Explain the property of IoT devices that makes the difference, and give one other place in an enterprise where the same property would make a similarly strict rule practical.
4. Elena treated the root cause as a governance failure (no procurement gate) rather than a technical one. Do you agree? Argue both sides: when is "add a policy/process" the right fix, and when is it an excuse to avoid a needed technical control?
5. The ATM fleet and the branch IoT received "the same four moves" but with very different rigor. What justifies spending more effort per ATM than per camera? Frame your answer in the risk vocabulary of Chapter 1.

Your Turn

Pick a real or invented organization with a physical footprint (a clinic, a school, a retail store, a small factory). Reproduce this engagement at small scale: (1) list the connected devices you would expect to find, separating managed from likely shadow; (2) for each, note whether its credentials and firmware are likely changeable/patchable, and assign it to one of the four triage buckets; (3) design a two-or-three-segment device architecture with a default-deny rule and write the IoT segment's allow-list; (4) write three monitoring rules tuned to your devices' predictability; and (5) draft a three-step procurement gate. Keep it to two pages. Where you cannot decide a device's bucket, say what you would go find out — uncertainty named is better than a confident guess.

Key Takeaways

• Discovery precedes defense. The most dangerous device is the one missing from inventory; a passive discovery sweep is the first move, and it routinely finds shadow IoT nobody knew existed.
• Match the control to the bucket. Default creds that can change are fix-in-minutes; unchangeable or unpatchable devices are "cannot fix — must contain"; shadow devices are removed; managed-capable devices are enrolled. Treating them all the same is the failure.
• Segmentation's highest-value rule is "deny the internet" for IoT. It collapses the worth of a compromise — no command-and-control, no botnet enrollment, no exfiltration — even though the vulnerability remains.
• Each device reaches exactly one server. Minimal allow-lists design lateral movement out of the network; a compromised camera inherits only the camera's (tiny) reachability.
• IoT's predictability makes monitoring cheap and reliable. Strict rules ("talks off its allow-list," "any outbound internet," "new device appears") that would drown a user segment in false positives are near-silent and high-signal on an IoT segment.
• The root cause is often governance. A procurement-and-ownership gate (approve, inventory, credential, place, monitor — before go-live) stops the inflow of new shadow IoT at the source.
• One playbook, two intensities. ATMs (high stakes, rigid) and branch IoT (messy, real) are both governed by inventory → manage what you can → contain and watch what you cannot → gate procurement.