Case Study 1: Knowing the Enemy — Meridian's First Threat Model

"Tell me who would attack us and how, before you tell me what to buy." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

Chapter 1 left Meridian with a five-row risk register and a CISO who had won, with a near-miss, the argument for maturing the program. The next question Dana asked her team was deceptively simple and quietly profound: who, specifically, is trying to attack a bank like ours, and how would they do it? Until that question is answered, every control purchase is a guess. This case study follows junior analyst Theo Brandt, security engineer Sam Whitfield, and GRC analyst Elena Vasquez as they build Meridian's first threat-actor profile and a STRIDE-lite threat model for the bank's crown-jewel assets — applying, in order, every tool from this chapter: the actor taxonomy, the motivation lens, the cyber kill chain, the ATT&CK vocabulary, and STRIDE. You will watch abstract models become a prioritized, defensible plan that re-orders the Chapter 1 risk register around the adversaries who actually matter to a regional bank. The scenario, the team, and all figures are constructed for teaching (Tier 3); the threat-actor categories, kill chain, and ATT&CK are real and canonical (Tier 1).

Skills applied: threat-actor categorization by motivation and capability; building a weighted threat-actor profile; mapping attacks to the cyber kill chain; using ATT&CK tactics and techniques as a shared language; STRIDE-lite threat modeling of a crown-jewel asset; turning a threat model into a prioritized defensive roadmap; distinguishing likely-and-cheap-to-defeat threats from unlikely-but- high-impact ones.

Background

Two weeks after delivering the risk register, Theo, Sam, and Elena gathered in a windowless conference room that the SOC had unofficially claimed. Dana's brief was on the whiteboard: "Threat-actor profile + threat model for our crown jewels. One week. I want to walk into the next risk-committee meeting able to say exactly who we defend against and where we'd catch them — not 'cyber threats are increasing.'"

The team's instinct, born of a hundred vendor emails, was to start from a list of scary attacks and work backward to products. Elena stopped that immediately. "We did this with assets last time and it worked. We start with who, then how, then where we break it — and only then does anyone say the word 'buy.'" She wrote three column headers: Who. How. Where we win. That structure — the chapter's actor → kill-chain → defense pipeline — organized the entire week.

Meridian's relevant facts were already on file from Chapter 1: ~1,800 employees, ~120 branches, ~2.5 million customers, a hybrid environment (legacy on-prem core, Windows Active Directory, VMware; plus AWS and Microsoft 365 with Entra ID), and a thick compliance surface (GLBA, PCI-DSS, SOX, FFIEC). What they did not yet have was a clear-eyed picture of the adversary.

The Analysis

Phase 1 — Building the threat-actor profile

Theo opened with the five-actor taxonomy and a hard question for each: does this actor realistically target a regional bank, and how heavily should we weight them? The team reasoned through each, refusing to copy a generic industry list and instead grounding every weight in Meridian's actual situation.

Cybercriminals — weighted HIGH (primary threat). "Money is here," Sam said, "so this is most of our real risk." The team enumerated the criminal sub-threats that genuinely apply to a bank: ransomware crews (fast, money-driven, availability-targeting); credential-theft operators (the very kind that ran the Chapter 1 phishing attempt); fraud groups (after wire-transfer and payment capability); and the initial access broker market that sells footholds to the others. Theo noted the defining trait from §2.1: these actors are economically rational. "We don't have to be impregnable to them. We have to be more expensive than the next bank, so the rational move is to go bother someone else." That single sentence, Elena observed, would resonate with a board far more than a threat-feed screenshot.

Insiders — weighted MEDIUM, but ALWAYS PRESENT. Elena insisted this row never be zero. "Most of ours won't be malicious. They'll be the loan officer who clicks, the admin who fat-fingers a permission, the contractor whose account we forget to disable." (She flagged the contractor-offboarding gap she'd half- noticed during the asset inventory — a thread that becomes Chapter 18's identity-governance work.) The team marked insiders as a constant background threat addressed as much by culture and process as by technology — explicitly deferring the defense program to Chapter 30, while keeping the actor on the profile here.

Hacktivists — weighted LOW, situational. "We're a mid-size Midwestern bank. We're not a symbol of anything — today," Theo said. The team agreed the baseline was low but wrote a trigger condition: a controversial lending decision, a high-profile customer, or proximity to a contested cause could spike this overnight, and the relevant impact would be availability (a DDoS to embarrass) more than data theft. They noted the model must be revisited, not set once.

Nation-state / APT — weighted LOWER-LIKELIHOOD, but HIGH-IMPACT. This was the contentious row. Sam's first instinct: "We're not a defense contractor; skip it." Elena pushed back with two reasons straight from §2.1's check-your-understanding: first, banks are strategically interesting — disrupting financial infrastructure or pre-positioning for a conflict has value beyond stealing any single secret; second, and decisively, the SolarWinds pattern means even an unremarkable mid-size firm can be swept up as a stepping stone through a compromised supplier. "We install dozens of third-party tools. We don't have to be the target to be the victim." The team settled on lower-likelihood, high-impact — not a daily worry, but not a zero, and important precisely because the controls that blunt an APT (segmentation, least privilege, behavioral detection) also serve against criminals.

Script kiddies — folded into the criminal/automated baseline. Rather than a separate heavy row, the team treated script kiddies as the human face of the automated, indiscriminate probing from Chapter 1 (§1.3): high volume, low sophistication, defeated by the same hygiene (patching, default-deny, strong auth) that stops opportunistic criminals. "They can't improvise past a closed door," Theo wrote. "So our job against them is just: close the doors."

The profile, condensed to the one page Dana asked for:

🛡️ Defender's Lens: The profile's real output is not the table; it is a spending principle. Because Meridian's threat is dominated by financially motivated criminals, the program should fund — first and hardest — the controls that defeat them: phishing-resistant authentication, segmentation, monitoring, and tested backups. The lower-likelihood APT row does not get ignored, but it gets served by controls that also counter criminals, so a single dollar buys defense against two adversaries. This is what it means to right-size defense to the threat instead of buying against a generic "cyber" boogeyman.

Phase 2 — From profile to STRIDE-lite threat models

With who settled, the team turned to how — running a STRIDE-lite pass on each crown-jewel asset from the Chapter 1 inventory. In §2.6 we walked the online-banking platform; here Theo and Sam worked the asset that, Sam argued, "controls access to everything else": Active Directory / Entra ID, Meridian's identity backbone. The logic: if an attacker owns identity, they own the bank, so the identity system is worth modeling with care.

ASSET: Active Directory / Entra ID (identity)   (CIA emphasis: Integrity, Confidentiality)

S  Spoofing        Actor: criminal (phish/stuff creds); insider reusing a teammate's session
                   Vector: stolen/sprayed credentials; forged authentication
                   Kill-chain: Delivery -> Exploitation
                   Defense:  phishing-resistant MFA everywhere (Ch.16); conditional access
T  Tampering       Actor: attacker who reaches a domain controller alters group membership
                   Kill-chain: Privilege Escalation
                   Defense:  tiered admin, change auditing, protected groups, monitoring (Ch.19)
R  Repudiation     Threat: an admin action with no reliable, tamper-evident trail
                   Defense:  centralized, immutable logging of all privileged actions (Ch.21)
I  Info disclosure Actor: criminal/APT enumerates the directory (users, groups, trusts)
                   Kill-chain: Discovery
                   Defense:  least-privilege read; detect mass enumeration; honeytoken accounts
D  Denial of svc   Threat: ransomware encrypts DCs; identity outage halts the whole bank
                   Kill-chain: Actions on Objectives (Impact)
                   Defense:  resilient/redundant DCs; tested offline backups (Ch.24)
E  Elevation       Actor: ANY foothold -> domain admin (the crown-jewel objective)
                   Kill-chain: Privilege Escalation -> Lateral Movement
                   Defense:  least privilege, PAM, tiering, PAWs (Ch.19); segmentation (Ch.6-7)

Figure 2.4 — STRIDE-lite threat model for Meridian's identity backbone. Every threat ties to a likely actor, a kill-chain stage, and the chapter that builds its defense — so the model doubles as a roadmap.

The exercise surfaced something neither the asset inventory nor the risk register had made explicit: identity is the highest-leverage target in the bank, because nearly every STRIDE category, for nearly every other asset, eventually routes through compromising identity. Spoofing a login, escalating to domain admin, moving laterally — all of it is identity. "If we get identity right," Sam said, "we make five other asset models harder for the attacker at once." That insight pre-stages the entire Identity and Access Management arc of Part IV (Chapters 16–20).

🔗 Connection: Notice how the kill chain and ATT&CK ride along inside STRIDE. The "E — Elevation" row is the ATT&CK Privilege Escalation tactic; the "I — Information disclosure" row, applied to a directory, is the Discovery tactic (enumerating users and groups); and the whole model is annotated with kill-chain stages. STRIDE gives you the checklist of what to consider; the kill chain and ATT&CK give you the shared language and stage-awareness to act on it. Using them together is how professionals turn a brainstorm into a defensible artifact.

Phase 3 — A worked intrusion against the model

To pressure-test the threat model, Priya Nair — the incident-response lead — proposed a thought experiment: take a realistic criminal intrusion and walk it against our defenses, stage by stage, to see where we'd actually break the chain. The team constructed a plausible scenario based on the very actor profile they'd just written (financially motivated, ransomware-bent) and traced it through the kill chain. For each stage they asked two questions: what would the attacker do? and with our planned controls, where does the chain break?

CONSTRUCTED INTRUSION (Tier 3) — financially motivated ransomware crew vs. Meridian

 STAGE                ATTACKER MOVE                       MERIDIAN'S BREAK POINT
 ──────────────       ─────────────────────────────       ──────────────────────────────
 Reconnaissance       harvest staff emails from           (low-cost to attacker; we reduce
                      public sources + breach dumps       footprint, monitor active scans)
 Weaponization        craft "invoice overdue" phish       (off our network; threat intel may
                      with a credential-harvest link      recognize the kit)
 Delivery             email reaches 40 staff              **BREAK 1**: email/URL filtering +
                                                          user reporting -> SOC alert
 Exploitation         a user submits credentials          **BREAK 2 (decisive)**: phishing-
                                                          resistant MFA -> stolen pw is useless
                                                          (exactly the Ch.1 near-miss)
 Installation         IF a foothold lands, drop a         **BREAK 3**: EDR + baseline detects
                      scheduled-task backdoor             new persistence; least privilege limits it
 Command & Control    beacon to external C2 every 60s     **BREAK 4**: network/DNS monitoring +
                                                          beacon detection isolates the host
 Lateral Movement     dump creds, pivot toward            **BREAK 5**: segmentation + PAM +
                      domain admin and file servers       tiering blunt the pivot
 Actions/Impact       deploy ransomware across shares     **BREAK 6 (leverage-killer)**: tested
                                                          OFFLINE backups neutralize extortion

Figure 2.5 — The same intrusion meets six independent break points. No single control is assumed perfect; defense in depth bets that across the chain, at least one layer catches what the others miss.

The whiteboard told the story Dana wanted. Against the bank's primary threat, Meridian's planned program offered not one defense but six, distributed across the chain — and the two most decisive (phishing- resistant MFA at Exploitation, tested offline backups at Impact) were exactly the controls the actor profile said to prioritize. "This is the asymmetry, flipped," Theo said, recalling Chapter 1. "They have to win at every stage. We have to win once, and we've got six chances."

🚪 Threshold Concept: A threat model is not a document you file; it is a map of where you choose to fight. Phase 3 reveals that Meridian's defense does not depend on perfect prevention at the perimeter — it depends on having an independent control at several links so that the failure of any one is survivable. New defenders look for the single wall that stops everything; experienced defenders build a chain of break points and accept that some attacks will get past the first few. The threat model is how you decide, in advance and on purpose, which links you will hold.

⚠️ Common Pitfall: Modeling only the likely threat and forgetting the high-impact one. The team nearly skipped the APT row, and nearly skipped the "what if the supply chain is poisoned?" question, because criminals dominate the day-to-day. Elena's insistence on keeping the SolarWinds-shaped risk in the model is what later (Chapter 29) gives Meridian a third-party-risk program instead of a blind spot. A threat model that only contains what is probable will miss the rare event that is catastrophic — and the multiplication from Chapter 1 ($\text{Risk} = \text{Likelihood} \times \text{Impact}$) is the reminder that a small likelihood times a huge impact is still a number you cannot ignore.

Phase 4 — Re-prioritizing the risk register

The final move closed the loop with Chapter 1. Armed with the actor profile and threat models, the team revisited the five-row risk register and re-weighted it around the actors who actually matter. Two changes stood out. First, the "credential attack" risk (R1) — already CRITICAL — was now explained: it is the entry point for the bank's primary actor (criminals) and is broken decisively at one cheap, high-value control (phishing-resistant MFA). That sharpened the business case. Second, a new risk was added that the asset-only view had missed entirely: supply-chain compromise of a trusted vendor's software — low likelihood, high impact, invisible to a register built only from internal assets. It entered the register as the seed of Chapter 29's third-party-risk work.

🔄 Check Your Understanding: The team folded "script kiddie" into the automated-baseline rather than giving it its own heavy row, but gave "nation-state/APT" a dedicated row despite lower likelihood. Explain the reasoning using both axes (motivation and capability) and the Chapter 1 risk formula. Why does a low-likelihood actor sometimes deserve more modeling attention than a higher-likelihood one? (Hint: consider impact, and consider which controls serve multiple actors at once.)

Discussion Questions

1. The team weighted cybercriminals HIGH and nation-states LOW-likelihood/HIGH-impact. If you were on Meridian's risk committee and the budget funded controls against only one of these as a first priority, which would you choose — and could a single control set serve both? Defend your answer using the actor profile.
2. Elena insisted the insider row "never be zero," noting most insider incidents are accidental. How does an accidental insider differ, defensively, from a malicious one, and why might the same controls (least privilege, monitoring) help against both?
3. Phase 3 found six independent break points against a ransomware intrusion, but Phase 2's identity model showed nearly everything routes through compromising identity. Is "defense in depth across the chain" in tension with "identity is the single highest-leverage target," or do they reinforce each other?
4. The team treated the threat model as a living document to revisit (especially the hacktivist trigger conditions and the supply-chain risk). What real-world events should prompt Meridian to re-run its threat-actor profile, and how often should it be reviewed even absent a triggering event?
5. Phase 4 added a supply-chain risk that an asset-only view had completely missed. What does this reveal about the limits of building a security program purely bottom-up from an asset inventory, and what does an attacker-aware (threat-modeling) view add?

Your Turn

Take the organization you profiled in Chapter 1's exercises (or invent a small business in a different sector — a clinic, a school district, an e-commerce shop). Produce two artifacts, one page total:

1. A weighted threat-actor profile. For each of the five actor types, assign a weight (high / medium / low / not-applicable) and justify it in one phrase grounded in this organization's reality. Note at least one trigger condition that would change a weight.
2. A STRIDE-lite threat model for one crown-jewel asset. For each of the six STRIDE categories, write one concrete threat, the likely actor, the kill-chain stage, and one defense.

Then write three sentences: which actor dominates your profile, which single control set would defend against the most of your threats at once, and which low-likelihood/high-impact risk you almost left out. If you cannot justify a weight in a phrase, that is a signal to learn more about the organization — note what you would go find out.

Key Takeaways

• A threat-actor profile answers who realistically attacks us, and how heavily to weight each — grounded in the organization's real situation, not a generic industry list. For a bank, criminals dominate; insiders are ever-present; hacktivists are situational; APTs are low-likelihood but high-impact (and reachable via the supply chain).
• The profile's true output is a spending principle: fund the controls that defeat your primary actor first, and prefer controls (segmentation, least privilege, behavioral detection) that serve multiple actors at once.
• STRIDE-lite turns each crown-jewel asset into a structured set of threats, each tied to an actor, a kill-chain stage, and the chapter that builds its defense — so the threat model doubles as a roadmap.
• Walking a realistic intrusion against the model reveals multiple independent break points along the kill chain; defense in depth bets that at least one layer holds when others fail. The attacker must win every stage; the defender must win once.
• A low-likelihood, high-impact actor (the APT, the supply-chain compromise) can deserve more modeling attention than a higher-likelihood one, because $\text{Risk} = \text{Likelihood} \times \text{Impact}$ and because the controls that blunt it often serve the common threats too.
• An attacker-aware threat model catches risks (like supply-chain compromise) that a purely asset-driven view misses — which is why a mature program builds both bottom-up (assets) and top-down (adversaries).