Case Study 1: Meridian Prepares for What's Next

"You don't rise to the level of your fears; you fall to the level of your preparation. The whole job is to prepare before you're afraid." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

A quarter after the SOC matured and the awareness program took root, Meridian Regional Bank's CISO, Dana Okafor, calls a half-day working session with a deliberately forward-looking agenda: not "what is hitting us now," but "what is coming, and what do we start today." Two emerging threats dominate the discussion because both have the property that waiting is the most expensive option — modern double-extortion ransomware (a present threat the bank must become resilient to) and the quantum threat to cryptography (a future threat whose defensive work, because of harvest-now-decrypt-later, must begin now). This case study follows the team as they produce two concrete artifacts for Meridian's security program: a ransomware resilience plan that assumes the encryption will succeed, and a post-quantum migration plan that starts — as it must — with a crypto-inventory. You will watch the chapter's most abstract ideas become a prioritized work list a bank can actually fund. The scenario and all figures are constructed for teaching (Tier 3).

Skills applied: threat-evolution reasoning; ransomware-resilience design (immutable/offline/tested backups, egress monitoring, quiet-phase detection, segmentation); building a crypto-inventory; assessing PQC readiness and prioritizing by quantum exposure; crypto-agility; horizon-scanning triage; translating emerging threats into a governable program increment.

Background

Meridian, as you know by now, is a mid-size regional bank: roughly 1,800 employees, 120 branches, 2.5 million customers, a hybrid environment (an on-prem data center with a legacy core-banking system and a Windows Active Directory domain, plus AWS and a Microsoft 365/Entra tenant), and a compliance surface that includes GLBA, PCI-DSS, SOX, and FFIEC oversight. Over the preceding chapters the security program has matured considerably: there is a risk register, a control framework, network segmentation, hardened baselines, an identity program, a SIEM with detection use cases, an incident-response plan, and — fresh from Chapter 24 — a ransomware tabletop the team ran together. The bank is no longer the reactive organization it was after the Chapter 1 phishing near-miss.

But Dana has been reading. The ransomware tabletop the team ran assumed a fairly classic attack; the threat intelligence crossing her desk describes something meaner — double extortion, data-leak sites, attackers who hunt the backup servers first. And buried in a NIST announcement is a development most of her peers are ignoring: the post-quantum cryptography standards are finalized, and the regulators who examine banks have started asking, gently for now, what institutions' plans are. Dana's instinct, honed over a career, is that both of these reward early movers and punish procrastinators — and that both are easy to not do, because neither is on fire today.

She opens the session with the framing that organizes everything: "We are good at fighting fires. Today we are not fighting a fire. We are doing the thing that is hard precisely because nothing is burning — preparing. Two threats. Ransomware, which will hit us eventually and which we must survive. And quantum, which will not break our crypto for years but which is already stealing our long-lived data if we do nothing. By the end of today I want two plans, both starting with actions we take this quarter."

The Analysis

Phase 1 — Ransomware resilience: assuming the encryption succeeds

Marcus Reyes (SOC Manager) and Priya Nair (IR & threat hunting) lead the ransomware half. Priya opens by reframing the goal, because she has seen teams waste a planning session chasing the wrong target: "I want to ban the phrase 'ransomware-proof' from this room. We cannot prevent ransomware — not with an affiliate economy renting industrial-grade tooling to anyone with a foothold to buy. Our job is resilience: assume the day comes when our files get encrypted, and engineer so that day is survivable and not existential."

The team works through the chapter's resilience checklist against Meridian's real environment, and the discomfort is instructive — every item exposes a gap.

Backups that ransomware cannot reach. This is where the conversation gets uncomfortable fast. Meridian backs up the core-banking database and key systems nightly. But Sam Whitfield (Security Engineer) walks through how the backups actually work, and the room goes quiet: the backup server is domain-joined, reachable from the production network, and the backup service account has broad rights. "If an affiliate reaches domain admin," Priya says, "they reach the backups, and the modern playbook is to destroy the backups first, then encrypt. Our backups defend us against a disk failure. They may not defend us against a determined human." The team specifies a fix: at least one backup copy must be immutable (write-once, undeletable for a retention window) and offline or logically isolated — not reachable with production credentials. And the item everyone wants to skip gets made mandatory: quarterly restoration tests of the core database, because, as Dana puts it, "an untested backup is a prayer with a budget line."

Detection in the quiet phase. Marcus maps the modern intrusion sequence — access, dwell, detonation — onto Meridian's telemetry. The encouraging news: because detonation usually comes days or weeks after the initial foothold, the affiliate's quiet activity is detectable. The team commits to specific hunts and detections: anomalous PowerShell and WMI use (living-off-the-land), creation of new privileged accounts, unusual internal scanning, and access to the backup infrastructure from unexpected hosts. "We are not waiting for the ransom note," Marcus says. "We are hunting the eleven quiet days before it."

Egress monitoring against double extortion. Priya makes the point that reframes their whole posture: "Double extortion means they steal the data before they encrypt it. That is actually good news for detection — exfiltration of tens of gigabytes to an unusual destination is loud if you are listening." The team adds egress-volume monitoring and alerting on large or anomalous outbound transfers, especially from file servers and especially to new external destinations. Even when it cannot stop the theft, it answers the question that will dominate the incident: what exactly did they take? — the difference between a precise regulatory notification and a worst-case-assumption catastrophe.

Segmentation and least privilege to limit spread. The reason ransomware so often encrypts everything is that the affiliate reached broad access. Meridian's existing segmentation (Chapters 6–7) and least-privilege work (Chapters 3, 17) are revisited specifically through the ransomware lens: can a foothold in the branch network reach the core? Can a compromised general-corporate account reach the cardholder data environment or the backup server? Each "yes" becomes a remediation item. The principle: a foothold in one zone must not become detonation in all of them.

A rehearsed, ransomware-specific IR plan — updated for double extortion. The Chapter 24 tabletop is revisited and found to be missing the modern wrinkles. The updated plan adds explicit decision points the old one lacked: Assume data was stolen — what is our breach-notification and regulatory clock under GLBA and state laws? What is our position on paying, given a leak-site threat against customer PII? Who engages law enforcement, the cyber-insurer, and outside counsel, and in what order? How do we communicate to customers if their data appears on a leak site? Elena Vasquez (GRC) owns turning these into written decision criteria, because, as she notes, "you do not want to be inventing your data-breach legal strategy at 3 a.m. with a countdown timer on a leak site."

The team captures the resilience plan as a one-page table tied to owners and the risk register:

🛡️ Defender's Lens: Notice that not one of these controls is "buy a better antivirus." Every item assumes prevention has failed and engineers for survival — immutable backups so recovery is possible, quiet-phase detection so the attack is caught before detonation, egress monitoring so the breach is scoped, segmentation so the blast radius is bounded, and a rehearsed plan so the human decisions are made in advance. This is defense in depth (Theme 4) applied to a threat you cannot stop: each layer is designed on the assumption that the one before it failed.

Phase 2 — The quantum clock: building the crypto-inventory

Sam Whitfield leads the post-quantum half, and he begins by managing expectations in the opposite direction from the ransomware discussion. "Ransomware is urgent and concrete. Quantum is the reverse — it feels abstract and far away, and that is exactly the trap. The work is long, so it has to start now, and the first step is boring: we have to find out where we even use cryptography."

He explains harvest-now-decrypt-later to the non-engineers in the room, because the whole justification rests on it: "An adversary does not need a quantum computer today to hurt us with one tomorrow. They can record our encrypted traffic and copy our encrypted archives now, while RSA and ECC are 'safe,' and just wait. The day a big enough quantum computer exists, they decrypt the whole stash retroactively. So the question is not 'when will quantum break RSA?' It is: 'how long does our data need to stay secret, and could a quantum computer plausibly exist within that window?' For our twenty-year customer records, the clock is already running. Data we wrote last year may already be in someone's archive."

Dana presses the obvious question: "So do we rip out RSA everywhere this year?" Sam's answer is the heart of the discipline. "No — and that is why the inventory matters. Not everything is equally exposed. Quantum exposure depends on two things: whether the algorithm is asymmetric public-key — RSA, ECC, the stuff Shor's algorithm breaks — and how long the data it protects must stay confidential. A system using ECC to protect a banking session that is worthless in two minutes is barely quantum-exposed, even though it is one of our most-attacked systems. A system using RSA to wrap a twenty-year archive is our top priority. We migrate by exposure, not by 'where is RSA.' And to do that, we need the map."

The team conducts a first-pass crypto-inventory across a representative sample of systems — a deliberately small, honest start, exactly as Meridian started its risk register in Chapter 1. For each system they record the algorithm, the purpose, and the confidentiality lifetime of the protected data, then classify the quantum exposure:

Reading the table aloud, Sam draws out the prioritization the bank will fund. "The archive, the wire-transfer keys, and code-signing are HIGH — for two different reasons. The archive because of its long confidentiality lifetime; that is pure harvest-now-decrypt-later. The wire-transfer and code-signing keys because if a future adversary can forge those signatures, they can authorize fraudulent transfers or ship malicious updates that look genuine — an integrity catastrophe, not a confidentiality one. The TLS and VPN are MEDIUM: asymmetric key exchange, yes, but each session secret is worthless in minutes, so harvest-now-decrypt-later barely applies — we will migrate them, but they are not the front of the line, and frankly the broader industry will migrate TLS for us as browsers and libraries adopt PQC. The password hashes and the symmetric at-rest encryption are LOW; Argon2 and AES-256 are minimally affected, and we do not want to waste scarce migration effort there."

🔗 Connection: This entire prioritization rests on Chapter 4's distinction between symmetric and asymmetric cryptography. The reason RSA/ECC are the crisis and AES/Argon2 are not is precisely the different hard problems they rely on — and the quantum threat is a threat to the specific hard problems (factoring, discrete logs) that public-key cryptography depends on. The crypto-inventory is, in a sense, Chapter 4's symmetric/asymmetric distinction turned into a work plan.

Phase 3 — From inventory to a migration plan, and the crypto-agility problem

With the inventory in hand, Sam confronts the harder discovery — the one that makes PQC a multi-year program rather than a project. "When I went to estimate the effort to migrate the customer-data archive, I hit a wall. The algorithm is not a setting we flip. It is baked into the storage application, into a vendor product we cannot even inspect, into key-management assumptions that thread through a dozen systems. We are not crypto-agile. Migrating one HIGH system is a small engineering project; migrating all of them, across products we did not build, is years."

This reframes the whole initiative, and Dana seizes on it as the real prize. "Then the quantum migration is not really about quantum. It is the forcing function that finally makes us build the thing we should have had all along — the ability to change a cryptographic algorithm without rebuilding the system. We do this once, properly, and the next migration, and the one after that, become routine instead of a crisis." The team adopts a phased plan with crypto-agility as the spine:

1. Inventory and prioritize (this quarter). Complete the crypto-inventory beyond the sample; rank all systems by quantum exposure. Sam owns this; the bluekit tool automates the classification.
2. Demand crypto-agility in everything new. Effective immediately, new systems and new procurement must support algorithm changes by configuration, and vendors must state their PQC roadmap. This stops the bank from digging the hole deeper while it plans to climb out.
3. Migrate the HIGH systems first, starting with the longest-lived data. The customer-data archive and signing keys move to NIST PQC algorithms (FIPS 203 for key establishment; FIPS 204 or 205 for signatures) as crypto-agility allows, prioritized by harvest-now-decrypt-later exposure.
4. Track the standards and the vendors. GRC adds NIST PQC and the bank's regulators' guidance to the horizon-scanning inputs; engineering tracks when its critical vendors ship PQC support.
5. Prefer hybrid where available. Where libraries support it, adopt hybrid schemes that combine a classical and a post-quantum algorithm, so the bank is no worse off if either is later weakened — a pragmatic, conservative migration stance.

⚠️ Common Pitfall: Treating PQC as a single future "rip and replace" event. The teams that will struggle most are not the ones that adopt PQC late; they are the ones that never built crypto-agility, so that every algorithm change — this one and all future ones — is an archaeological dig through hard-wired code and opaque vendor products. The deliverable that matters most from Meridian's PQC initiative is not a specific algorithm; it is the agility to change algorithms cheaply, forever.

Phase 3.5 — The deepfake the bank had not planned for

Before the team closes, Elena Vasquez raises the threat that does not fit neatly into either the ransomware or the quantum bucket but that she has decided cannot wait: deepfake-enabled fraud. "We are a bank," she says. "Our entire business is authorizing the movement of money on someone's say-so. And the thing that has always made an urgent call from a senior executive believable — that it sounds like them — just stopped being reliable. Our wire-transfer desk and our high-value customer-service lines verify identity, in part, by recognizing a voice or seeing a face. That control is now defeatable, and it is cheap to defeat."

She walks the team through the attack she is worried about, which is not hypothetical for a bank: a fraudster clones the voice of a high-net-worth customer, or of a Meridian executive, and calls to authorize a large transfer or a change of account details, weaponizing urgency and a familiar voice to rush past verification. Dana pushes on the obvious instinct: "Do we buy deepfake-detection software?" Elena's answer mirrors the chapter's principle. "We can layer some on, but it is a losing arms race — as the fakes get better, the detectors fall behind, and I am not betting the wire desk on a detector keeping up. The durable fix is process: we stop treating a voice or a face as proof of identity, and we require a channel the attacker does not control and a secret the fake does not have."

The team drafts a deepfake-verification checklist for any request to move money or change payment or account details, regardless of how it arrives or how senior the apparent requester:

• Out-of-band callback to a known number. No transfer or detail change proceeds on the inbound contact alone; the desk independently calls the customer or executive back on the number already on file in the bank's records — never a number supplied in the request.
• Pre-shared verification (a secret, not a voice). High-value customers and internal approvers are enrolled with a verification phrase or a knowledge factor the desk confirms — something a cloned voice cannot produce on demand.
• Phishing-resistant step-up for the highest tiers. For the largest transfers, authorization requires a possession factor — a hardware security key (Chapter 16) — so that no synthetic face or voice, however perfect, can satisfy the control.
• Urgency is a red flag, not a fast lane. Policy is explicit that no urgent or confidential request skips verification; the pressure to hurry is reframed, for the desk staff, as the signal to slow down.
• Name the threat in training. Elena coordinates with the awareness program (Chapter 30) to add deepfake fraud to the curriculum for finance and customer-service staff — because a teller who has never heard that a voice can be faked is the one who skips the callback.

🔗 Connection: Notice that almost none of this is new — the out-of-band callback, the knowledge factor, the hardware key, the friction against urgency are controls Meridian already understands from the authentication and awareness work of Chapters 16 and 30. The deepfake threat did not require Meridian to invent new defenses so much as to extend existing ones to a new attack surface — human verification — and to name the new threat explicitly so staff apply them. That is often how a mature program absorbs an emerging threat: not a frantic new purchase, but the disciplined extension of controls it already has.

This is the third act now item, and Elena owns it. Like the ransomware and PQC work, it costs little and buys disproportionate resilience — and, like them, it is far cheaper to build before a synthetic-voice call reaches the wire desk than to explain to regulators afterward why a cloned voice moved a customer's money.

Phase 4 — Folding both into the emerging-threat watch

To close the session, Elena assembles both initiatives into the program's new emerging-threat watch, so they become tracked risks with owners rather than good intentions. She applies the §35.6 triage to the chapter's four threats:

She runs the customer-data archive's risk through riskcalc.py (Chapter 1) to confirm its place on the risk register, and the team adds the crypto-inventory output as a living appendix to the program document. Dana closes the session: "None of this was on fire today. That is exactly why it was worth a half-day. The institutions that get hurt by these threats are almost never hurt by a secret — the information is public. They are hurt by the absence of a process to notice and act. Today we built the process."

🔄 Check Your Understanding: The team rated the online-banking TLS as only MEDIUM quantum exposure even though it is one of Meridian's most-attacked systems, while rating the rarely-touched customer-data archive HIGH. Explain why this ordering is correct under harvest-now-decrypt-later — and name the one reason Meridian should still migrate the TLS eventually despite its lower priority. (Hint: think about session secret lifetime versus archive confidentiality lifetime, and about who migrates TLS on the bank's behalf.)

Discussion Questions

1. Priya banned the phrase "ransomware-proof." What does insisting on resilience over prevention change about how a team spends its budget and designs its controls? Where might "prevention" still matter?
2. The backups discussion was the most uncomfortable moment of the session. Why are backups so frequently the weakest link against modern ransomware, and why does "we have backups" so often create false confidence?
3. Sam argued for migrating by quantum exposure (algorithm type × data lifetime) rather than "wherever we use RSA." Construct an example where the naive "replace all RSA first" approach would waste effort on a low-priority system while leaving a high-priority one exposed.
4. Dana reframed PQC migration as "really about crypto-agility." Is she right that the agility is more valuable than the specific algorithm change? Argue both sides.
5. The emerging-threat watch marked hardware/firmware supply chain as watch rather than act now or dismiss. Defend that triage decision for a bank like Meridian. When would it escalate?

Your Turn

Pick an organization you know (or invent a small one) and produce both artifacts in miniature, one page each. (a) A ransomware resilience plan: walk the five-item checklist against the organization's real environment, naming a specific gap and target state for each. (b) A crypto-inventory and PQC priority list: list five to seven systems with their crypto, purpose, and data-confidentiality lifetime, classify each as HIGH/MEDIUM/LOW quantum exposure, and justify your top migration priority using harvest-now-decrypt-later. For at least one system, identify what makes it not crypto-agile and what you would change. If you cannot determine a system's actual crypto, note that — "we don't know what this uses" is itself a finding, and the most common one.

Key Takeaways

• "Ransomware-proof" is the wrong goal; resilience is the right one. Assume the encryption succeeds and engineer for survival: immutable + offline + tested backups, quiet-phase detection, egress monitoring, segmentation, and a rehearsed double-extortion IR plan. None of it is "buy better antivirus."
• Backups are the most common weak link against modern ransomware because attackers hunt and destroy reachable backups first; "we have backups" is false confidence unless they are immutable, isolated, and restoration-tested.
• The quantum migration starts with a crypto-inventory, because you cannot migrate cryptography you cannot find — and most organizations cannot find theirs.
• Prioritize by quantum exposure, not by "where is RSA." Exposure = asymmetric algorithm × data confidentiality lifetime. Harvest-now-decrypt-later makes long-lived data (archives, signing keys) the top priority; short-lived session crypto (TLS) is lower even when heavily attacked.
• PQC migration is really a forcing function for crypto-agility — the ability to change algorithms by configuration. The agility outlasts this migration and makes every future one routine.
• Both threats reward early movers and punish procrastinators, and neither is "on fire" today — which is exactly why a horizon-scanning process, not a fire alarm, is what turns them into funded, owned work.