Chapter 2: The Threat Landscape: Who Attacks, Why They Attack, and How Attacks Actually Work

"Know your enemy and know yourself; in a hundred battles you will never be in peril." — Sun Tzu, The Art of War

Overview

In Chapter 1, an attacker tried to phish a loan officer at Meridian Regional Bank and failed at the authentication wall. We never asked the obvious question: who was that? A bored teenager running a kit they bought on a forum? A professional credential-theft crew that phishes two hundred banks a week and sells whatever they harvest? A nation-state team using the bank as a stepping stone to something larger? The answer matters enormously, because each of those adversaries has a different budget, a different goal, a different level of patience, and — most usefully to you — a different set of moves they tend to make. A defender who cannot distinguish them defends against a cartoon. A defender who can allocates a finite budget against the threats that are actually likely to show up, and recognizes those threats in the logs when they do.

This chapter is about knowing your enemy with enough precision to defend against them. We will sort the world's attackers into a taxonomy you can reason with, examine what drives each kind, and then — the heart of the chapter — learn two models that turn the chaos of "a breach happened" into an orderly sequence of steps, each of which is a place to detect and stop the attacker. The first model, the cyber kill chain, tells the story of an intrusion as a chain of stages. The second, MITRE ATT&CK, is the shared dictionary the entire defensive industry now uses to describe attacker behavior precisely. We will trace a real, industry-changing intrusion — the SolarWinds supply-chain attack — through both models, and we will look hard at ransomware, the threat most likely to ruin a Tuesday at a bank. Then you will build Meridian's first threat model: a structured answer to the questions who would attack us, how, and where would we catch them?

The asymmetry from Chapter 1 — attackers need to be right once, defenders every time — is the backdrop for everything here. But this chapter adds a hopeful corollary that the kill chain makes concrete: an attacker does not win in a single instant; they win across a sequence of steps, and you only have to break the chain at one of them. That reframing is the engine of practical defense.

In this chapter, you will learn to:

• Categorize threat actors by motivation and capability, and recognize which ones realistically target an organization like yours.
• Name the four big motivations — money, espionage, ideology, ego — and read an attacker's likely behavior from their goal.
• Walk an intrusion through the cyber kill chain and identify, at each stage, what a defender could detect or prevent.
• Use MITRE ATT&CK and the vocabulary of tactics, techniques, and procedures (TTPs) to describe attacks the way professionals do.
• Trace a real intrusion from initial access to impact, and build a basic threat model for Meridian that turns "who might attack us" into a ranked defensive plan.

Learning Paths

This chapter is foundational for everyone, but it lands differently depending on where you are headed:

🛡️ SOC Analyst: This is one of your core chapters. Live in §2.3 (kill chain), §2.4 (ATT&CK — you will map every alert to it for the rest of your career), and §2.5 (anatomy of an intrusion). The kill chain and ATT&CK are the coordinate system of your job. 🏗️ Security Engineer: Focus on §2.3 and §2.6 (threat modeling) — they tell you where to place controls and which controls actually matter against the threats you face. Design follows threat. 📋 GRC: §2.1–§2.2 (actors and motivations) and §2.6 (threat modeling) feed directly into risk assessment (Chapter 27) and the threat-informed parts of a security program. Know which adversaries your regulators and your board worry about. 📜 Certification Prep: Threat-actor types, motivations, the kill chain, ATT&CK, IoCs, and TTPs are heavily tested on CompTIA Security+ and appear throughout CISSP. The key-takeaways.md file maps every term to its exam domain.

2.1 The cast of attackers

Begin with a correction. In Chapter 1, Elena Vasquez scolded Theo for writing "hackers" as the threat for every asset, and the scolding was right: hackers is a word that names everyone and therefore describes no one. The people who attack Meridian are not a monolith. They differ in who they are, what they want, what they can do, and how much they care — and those differences are precisely what let you defend efficiently. A threat actor is an individual or group with the intent and capability to cause harm to your assets; the discipline of this section is sorting them into categories that predict behavior.

We sort threat actors along two axes that you will use constantly. The first is motivation — why they attack: what outcome are they pursuing? The second is capability — how good they are: their resources, skill, patience, and the sophistication of the techniques they can bring to bear. A useful shorthand pairs these: a low-capability actor with intense motivation is a different problem from a high-capability actor with passing interest. Capability without motivation rarely touches you; motivation without capability is noisy but often stoppable; the dangerous quadrant is high motivation and high capability — and the whole point of a threat model is to figure out whether anyone in that quadrant actually cares about you.

Let us walk the standard taxonomy. These categories overlap at the edges — a nation-state may hire criminals; an insider may be recruited by a foreign government — but they are the vocabulary the entire field uses, and they map cleanly to the certifications.

A nation-state actor is a government-sponsored group that attacks in the service of a state's interests: espionage, military or economic advantage, sabotage, or pre-positioning for a future conflict. These are the best-resourced and most patient adversaries on earth. They have salaries, intelligence agencies behind them, the time to spend months inside a network, and access to custom tooling and sometimes to zero-day vulnerabilities — flaws unknown to the vendor, for which no patch yet exists. When a nation-state group conducts a long, stealthy, targeted campaign, it earns a particular label: an APT, or Advanced Persistent Threat — advanced in technique, persistent in that it maintains long-term access and returns again and again, and a threat in the literal sense. (The term originated in U.S. defense circles as a way to discuss state adversaries without naming them in unclassified settings, and it stuck.) Not every APT is a nation-state and not every nation-state operation is "advanced," but in practice the label marks the patient, well-funded, goal-driven adversary you cannot simply out-spend. The SolarWinds intrusion we dissect later in this chapter is the textbook modern example.

A cybercriminal is motivated by money, full stop. This is the largest category by volume and the one most likely to hit a bank, because a bank is where the money is. Cybercriminals range from lone operators to organized, businesslike enterprises with help desks, affiliates, and profit-and-loss statements. They run ransomware, steal and sell credentials and payment-card data, commit fraud, and operate the initial access broker market — selling footholds in already-compromised networks to whoever will pay. Their defining trait, from a defender's seat, is that they are economically rational: they prefer easy targets, they abandon hard ones, and they scale through automation. That rationality is your lever. You do not have to be impregnable against a cybercriminal; you frequently only have to be more expensive to attack than the next organization, so that the rational move is for them to go elsewhere. (Against a nation-state with a specific reason to want you, that logic fails — which is exactly why distinguishing the two matters.)

A hacktivist attacks to advance a political or social cause: to protest, to embarrass, to leak documents they believe the public should see, or to disrupt an organization they oppose. Their capability varies enormously — from loosely coordinated crowds running simple denial-of-service tools to skilled operators conducting targeted leaks. Their motivation is ideological, which changes the calculus: they are not deterred by "we have nothing worth stealing," because their goal may be attention, disruption, or symbolic harm rather than profit. For a bank, hacktivist risk is usually lower than criminal risk, but a controversial business decision, a high-profile customer, or simple proximity to a cause can change that overnight.

An insider is someone with legitimate access — an employee, contractor, or partner — who causes harm, whether maliciously or by accident. The insider is a category apart because they start inside the perimeter, with credentials and knowledge that an external attacker has to fight to obtain. A malicious insider may steal data on the way out the door, sabotage systems, or sell access. But the more common insider incident is not malicious at all: a well-meaning employee who clicks a phishing link, misconfigures a storage bucket, emails a spreadsheet to the wrong address, or carries data home on a thumb drive. (We list "insider" in the taxonomy here; the dedicated defense against insider threat, including the cultural and programmatic side, is built in Chapter 30.) The insider is the living proof of Theme 3 from Chapter 1 — the human is simultaneously the weakest link and, when trained and alert, the strongest asset.

A script kiddie is an unskilled attacker who runs tools and exploits written by others without deeply understanding them. The name is dismissive, and the skill level often is low — but do not mistake low skill for low risk. A script kiddie pointing an automated scanner and a public exploit at your weakest, least-patched system can absolutely cause a breach; they simply cannot adapt when a defense holds. They are the human face of the automated, indiscriminate background radiation we described in Chapter 1 (§1.3): high volume, low sophistication, opportunistic. The good news is that the same boring controls that defeat automated scanning — patching, default-deny, strong authentication — defeat the script kiddie, because they cannot improvise past a closed door.

🔗 Connection: Chapter 1 introduced the offense/defense asymmetry. The taxonomy refines it. Against opportunistic actors (script kiddies, most cybercriminals), the asymmetry is survivable by being a harder target than your neighbor — they need to be right once, but they will not work hard to make it you. Against a determined APT with a specific reason to want you, "harder than the neighbor" is not enough, and you must lean on defense in depth, detection, and response (Theme 4). One taxonomy, two completely different defensive postures — which is why naming the actor is a defensive act.

Here is the taxonomy as a reference table you will return to:

🔄 Check Your Understanding: 1. Why does the capability axis matter as much as the motivation axis when deciding how to defend? Give an example of a high-motivation, low-capability actor and how you would treat it differently from a high-motivation, high-capability one. 2. A defender says, "We have no secrets a foreign government would want, so we don't need to worry about APTs." Name two reasons this reasoning can fail.

Answers

1. Motivation tells you who wants to attack; capability tells you how hard they can push and how stealthy they can be. A motivated hacktivist crowd (high motivation, low capability) is often stopped by basic DDoS protection and patching, because they cannot adapt; a motivated APT (high motivation, high capability) can develop custom tooling and wait months, so you must invest in detection and response, not just prevention. 2. (a) You may be a stepping stone — a supplier, customer, or trusted partner of the real target (the SolarWinds pattern). (b) Strategic value is broader than "secrets": disrupting a financial institution, holding access for a future conflict, or harvesting credentials that unlock other organizations can all make an unremarkable company worth an APT's time.

2.2 Motivations: money, espionage, ideology, ego

The taxonomy answers who; motivation answers why — and why is the single most predictive thing you can know about an attacker, because the goal shapes the behavior. An attacker who wants money behaves differently inside your network than one who wants secrets, and a defender who knows the goal can anticipate the moves. Motivation is the underlying objective that drives a threat actor to act; let us take the four big ones in turn and, for each, draw the line from motive to method to defense.

Money is the dominant motivation on the internet, by a wide margin. Financial attackers want to convert access into cash as efficiently as possible, which dictates a recognizable repertoire: ransomware (encrypt the victim's data and sell back the key), data theft for resale (payment cards, credentials, personal data sold in bulk), fraud (initiating fraudulent transactions or wire transfers), and extortion (threatening to leak stolen data unless paid). Because the goal is profit, financially motivated attackers optimize for return on effort: they automate, they reuse infrastructure, they pick soft targets, and they move fast once inside, because dwell time is risk and risk is cost. For a bank, this is the bread-and-butter threat. The defensive implication is direct: raise the cost of the attack (strong authentication, segmentation, monitoring) and raise the difficulty of monetization (so that even a foothold yields little), and the economically rational attacker reprices you and leaves.

Espionage is the motivation of the nation-state and, occasionally, of corporate competitors. The goal is information — state secrets, intellectual property, negotiating positions, the personal data of officials, or simply visibility into what a target is doing. Espionage rewards patience and stealth above all. An attacker who wants to steal money wants to act and leave; an attacker who wants to watch wants to stay quiet for as long as possible, blending into normal activity, avoiding the noisy moves that trigger alarms. This is the APT signature, and it is why espionage actors invest so heavily in living off the land — using the legitimate tools already present on a system (administrative utilities, scripting, built-in remote access) so their activity looks like ordinary administration rather than malware. The defensive implication flips: against espionage you cannot rely on catching "bad files," because there may not be any; you must detect anomalous behavior by otherwise-legitimate tools and accounts. That is the entire premise of the threat hunting we build in Chapter 22.

Ideology drives hacktivists and, in a darker form, terrorists and some nation-state operations. The goal is to advance a cause — through disruption (denial of service to silence or embarrass), exposure (leaking documents), defacement (replacing a website with a message), or destruction. Ideological attackers are unpredictable in target selection because their triggers are events and beliefs, not asset value. A bank that finances a controversial project, or that simply becomes a symbol, can attract ideological attention it never courted. The defensive implication is that you cannot threat-model ideology purely from your own asset inventory; you must also watch the world — your public posture, your customers, the causes that might name you — and be ready for availability attacks (Chapter 1's third leg of the triad) that aim to embarrass rather than enrich.

Ego — the desire for status, the thrill of the challenge, the bragging rights — drives script kiddies and some lone-wolf attackers, and it shades into the others (criminals seek reputation in their markets; hacktivists seek glory in their movements). Ego-driven attacks are often opportunistic and showy: a defacement to prove it could be done, a breach announced for clout. The capability is frequently low, but the unpredictability and the willingness to act just because the door was open make ego-driven actors a real, if usually manageable, part of the landscape. The defensive implication is the most familiar one: deny the easy win. Most ego-driven attacks die against basic hygiene, because the ego is in finding an easy hole, and a closed door is not a story worth telling.

🛡️ Defender's Lens: Read the goal, predict the behavior. A financially motivated intruder will move fast toward something monetizable — payment systems, ransomware deployment, wire-transfer capability — so a sudden burst of reconnaissance, privilege escalation, and lateral movement toward financial systems is the signature. An espionage actor will move slowly toward sensitive data, using legitimate tools, minimizing noise — so the signature is the quiet anomaly: a service account logging in at an odd hour, an administrative tool run on a host that never runs it, small steady data transfers. When you investigate, asking "what would an attacker with this goal do next?" turns a pile of alerts into a hypothesis. Goal-driven thinking is what separates an analyst who chases indicators from one who anticipates the adversary.

📟 War Story: A constructed but representative composite. A mid-size manufacturer suffered two intrusions in one year. The first was loud and fast: within hours of a phishing foothold, the attacker had dumped credentials, spread to a dozen hosts, and detonated ransomware across file servers — money, on a stopwatch. The second was the opposite: a single service account began authenticating to a sensitive engineering server during off-hours, transferring modest amounts of design data over weeks, using only built-in Windows tools. No malware fired; no alarm tripped for two months. Same company, two utterly different adversaries, betrayed by their motivations. The ransomware crew wanted cash and could not afford to be slow; the espionage actor wanted blueprints and could not afford to be loud. The lesson: tune your detection to the goals of the actors who realistically target you, not to a generic notion of "an attack."

🔄 Check Your Understanding: 1. An attacker has been inside a network for three months, using only built-in administrative tools, moving slowly toward a research database. What is the most likely motivation, and what does that imply about how you should try to detect them? 2. Why is "we have nothing worth stealing" a weak defense against an ideologically motivated attacker?

Answers

1. Espionage (likely an APT): the patience, stealth, living-off-the-land tooling, and targeting of sensitive information all point to a goal of watching/stealing information rather than fast monetization. You should detect anomalous behavior — unusual account activity, admin tools on hosts that never use them, off-hours access, slow data egress — rather than relying on malware signatures, because there may be no "bad files" to find. 2. Ideological attackers select targets by belief and events, not asset value; their goal may be disruption, embarrassment, or a symbolic statement, so a target with no stealable data can still be attacked (e.g., a denial-of-service to silence or shame it).

2.3 The cyber kill chain

We now turn from who and why to how — and here is the chapter's first power tool. The cyber kill chain is a model that breaks an intrusion into an ordered sequence of stages an attacker must generally complete to achieve their objective, from first reconnaissance to final impact. The model was introduced by analysts at Lockheed Martin (adapting a military concept), and its enduring value to a defender is a single, liberating idea: because an attack is a chain of steps, you do not have to stop it at the first step or the last — you can break the chain at any link. Every stage the attacker must pass through is a stage at which you might detect or prevent them. The asymmetry of Chapter 1 said the attacker needs to succeed only once; the kill chain adds the rejoinder that the attacker must succeed at every stage, while you only need to win at one.

The classic kill chain has seven stages. Let us walk them, and for each, state what the attacker is doing, what it looks like from the defender's seat, and what control or detection applies. This pairing — every attacker move next to its defensive counter — is the habit the whole book is built on.

1. Reconnaissance. The attacker gathers information about the target: employee names and emails (from the company website, social media, breach dumps), technologies in use, exposed services, business relationships. Defender's view: much reconnaissance is passive and invisible, but some is active — port scans, vulnerability probes, suspicious web crawling — and shows up in your edge telemetry. Counter: reduce your public footprint (limit what is exposed and disclosed), and monitor for scanning patterns. You cannot stop someone reading your website, but you can make the reconnaissance yield less and notice when it turns active.

2. Weaponization. The attacker prepares the attack: crafts the phishing email, builds or packages the malware, sets up the fake portal, pairs an exploit with a payload — the part of an attack that actually executes the attacker's intent once delivered (run code, install a backdoor, encrypt files). Defender's view: this happens on the attacker's infrastructure, so you usually cannot see it directly. Counter: this stage is where threat intelligence earns its keep — if the wider community has observed the attacker's tooling, infrastructure, or patterns, you may recognize the weapon when it arrives, even though you never saw it being built.

3. Delivery. The attacker transmits the weapon to the target: the phishing email arrives, the malicious link is clicked, the infected USB is plugged in, the compromised software update is downloaded. Defender's view: this is the first stage that touches you, and it is rich with detection and prevention opportunity. Counter: email security gateways, web/URL filtering, attachment sandboxing, and — crucially — trained humans who report the suspicious message (the loan officer's colleague in Chapter 1). Delivery is the stage where the attack vector — the path or means by which an attacker reaches and breaches a target (email, web, removable media, a vulnerable exposed service, a trusted supplier) — becomes concrete.

4. Exploitation. The weapon triggers: the malicious code runs, the vulnerability is exploited, the harvested credentials are used. Defender's view: on an endpoint this is where endpoint detection and response (EDR) tools watch for malicious behavior; on a network service it is where intrusion prevention may block a known exploit. Counter: patching (so the vulnerability is not there to exploit), hardening and attack-surface reduction (Chapter 11), application control, and EDR. The Meridian phishing attack from Chapter 1 was stopped at exploitation — the credentials were harvested (delivery succeeded) but the attempt to use them against the real portal failed, because phishing-resistant MFA broke the exploit.

5. Installation. The attacker establishes persistence — a foothold that survives a reboot or a closed session: a backdoor, a new service, a scheduled task, a created account, a registry run-key. Defender's view: persistence mechanisms are detectable, because they create artifacts (new services, autoruns, unexpected accounts) that differ from a known-good baseline. Counter: EDR and host monitoring tuned to detect persistence techniques, baseline integrity checks, and least privilege (so the foothold cannot install itself system-wide).

6. Command and Control (C2). The installed malware "phones home" to the attacker's infrastructure to receive instructions and exfiltrate data — establishing a channel the attacker steers the intrusion through. Defender's view: C2 traffic is one of the most reliable detection points in the whole chain, because the malware must communicate, and that communication has patterns — regular beaconing to an external server, connections to known-bad domains or IPs, DNS used as a covert channel. Counter: network monitoring (Chapter 10), DNS inspection, blocking known C2 infrastructure from threat intel, and detecting the regularity of beacons. This is the stage where the SolarWinds backdoor revealed itself to the analysts who finally caught it.

7. Actions on Objectives. The attacker accomplishes their goal: exfiltrates data, deploys ransomware, commits fraud, destroys systems, or simply continues to watch. Defender's view: by this stage harm is occurring, so detection here is "better late than never" — but data-loss prevention, anomaly detection on large transfers, and integrity monitoring can still catch the objective and trigger response. Counter: segmentation and least privilege limit how far the objective can reach; backups defeat ransomware's leverage; monitoring catches the exfiltration. And every earlier link you broke means the attacker never reached this one.

🚪 Threshold Concept: The attacker must traverse the entire chain to succeed; you only have to break one link to stop this particular attack. This inverts the discouraging asymmetry of Chapter 1. Yes, the attacker needs to be right once to get in — but "in" is only the third or fourth link, not the finish line. A foothold that cannot persist, persistence that cannot reach the internet to receive commands, a command channel that cannot reach the crown jewels because of segmentation — any one of these breaks the chain. This is why defense in depth (Theme 4) works: each independent layer is another link the attacker must defeat, and you are betting that across a deep enough chain, at least one of your controls catches what the others missed. Internalize this and "we got a foothold, are we breached?" stops being a yes-or-no panic and becomes "which link do we break, right now?"

Here is the kill chain as a labeled diagram, annotated with the defensive opportunity at each stage. Tape this to the inside of your skull.

   ATTACKER PROGRESS  ───────────────────────────────────────────────►  GOAL

   1 RECON      2 WEAPONIZE   3 DELIVERY    4 EXPLOIT     5 INSTALL
   gather info  build the     send it       trigger it    persist
   on target    weapon/payload (email/web/   (run code,    (backdoor,
                               USB/supply)   use creds)    service, task)
      │            │              │             │             │
      ▼            ▼              ▼             ▼             ▼
  reduce        threat        email/URL     patch, EDR,   EDR, baseline,
  footprint;    intel; recog- filtering;    hardening,    autoruns watch,
  watch for     nize known    sandboxing;   app control   least privilege
  scanning      tooling       train+report
                                   │             │
        (Meridian Ch.1 attack stopped HERE ──────┘  delivery succeeded,
                                                     exploitation failed: MFA)

   6 COMMAND & CONTROL (C2)          7 ACTIONS ON OBJECTIVES
   malware phones home,             exfiltrate / ransomware /
   receives orders, beacons         fraud / destroy / keep watching
      │                                  │
      ▼                                  ▼
  network + DNS monitoring,         DLP, anomaly on large transfers,
  block known C2, beacon            segmentation limits reach,
  detection  ◄── SolarWinds         backups defeat ransomware leverage
              caught at THIS stage

   RULE:  the attacker must pass EVERY stage; the defender only has to
          BREAK ONE LINK.  Each control above is a different link.

Figure 2.1 — The cyber kill chain with paired defensive opportunities. An attack is a chain; defense in depth puts an independent control at multiple links so that one failure is survivable.

A caution before we move on: the kill chain is a model, and like all models it is a simplification. Real intrusions skip stages, loop back, run several chains in parallel, or begin already inside (an insider, or stolen credentials, may start at Installation). Critics rightly note the original model is somewhat perimeter- and malware-centric, written for an era that assumed the attacker was outside trying to get in. It remains invaluable as a thinking tool — a way to decompose an attack into stoppable steps — but for describing the full richness of modern attacker behavior, the field reached for something more granular, which is where ATT&CK comes in.

🔄 Check Your Understanding: 1. An attacker successfully phishes an employee and runs malware on their laptop, but your network monitoring blocks the malware's attempt to reach its command-and-control server. At which kill-chain stage was the attack stopped, and why is that still a defensive success even though the attacker got code running? 2. Why is the Command-and-Control stage often described as one of the best places to detect an intrusion?

Answers

1. The attack was stopped at Command and Control (C2) — exploitation and installation succeeded (code ran, perhaps persisted), but the malware could not reach the attacker to receive instructions or exfiltrate data, so the chain broke before Actions on Objectives. It is a success because breaking any link prevents this attack from reaching its goal; the foothold is contained and now becomes an incident to investigate and evict, not a breach. 2. Because the malware must communicate with the attacker to be useful, and that communication has detectable patterns (regular beaconing, known-bad destinations, DNS abuse). It is hard for an attacker to avoid generating some network signal, so C2 is a reliable, high-value detection point.

2.4 MITRE ATT&CK as a shared language

The kill chain tells you the phases of an attack. MITRE ATT&CK tells you, in fine and standardized detail, the specific behaviors attackers use within those phases — and it does so in a vocabulary that the entire defensive industry has agreed to share. ATT&CK (the name is a styling of Adversarial Tactics, Techniques, and Common Knowledge) is a free, continuously updated knowledge base, curated by the non-profit MITRE Corporation, that catalogs real-world attacker behavior observed in actual intrusions. If the kill chain is a sentence — "the attacker got in, persisted, and stole data" — ATT&CK is the dictionary and grammar that let two defenders on opposite sides of the world mean exactly the same thing by every word.

ATT&CK is organized into a hierarchy you must know cold, because it formalizes three terms — tactic, technique, procedure — that you will use in every detection, every threat report, and every incident write-up for the rest of your career. Together these three are abbreviated TTPs (tactics, techniques, and procedures), the standard shorthand for "the characteristic ways a given adversary operates."

A tactic is the attacker's tactical goal — the why of a step: what are they trying to accomplish at this moment? ATT&CK enumerates a set of tactics that read like a more detailed kill chain: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact. A tactic answers "what is the adversary's objective in this phase?" — for example, Persistence (stay on the system) or Credential Access (steal passwords or keys).

A technique is how the attacker achieves a tactic — the method. Each tactic contains many techniques (and sub-techniques), each with a stable identifier like T1566 (Phishing) under Initial Access, or T1059 (Command and Scripting Interpreter) under Execution. The identifier is the magic: when an analyst writes "we observed T1566.001," every other analyst knows precisely that spear-phishing via a malicious attachment occurred, with no ambiguity and no translation. A technique answers "by what method did they pursue the tactic?"

A procedure is the specific implementation — the exact way a particular adversary or piece of malware carries out a technique on a particular occasion. Two groups may both use the Phishing technique, but their procedures differ: one sends a fake invoice with a macro-laden document; another sends a link to a credential-harvesting page that mimics a vendor portal. The procedure is the fingerprint-level detail. A procedure answers "what did this adversary actually do, step by step?"

The relationship, made concrete with Meridian's Chapter 1 incident:

TACTIC      : Initial Access          (the goal: get a foothold)
   └ TECHNIQUE : Phishing  (T1566)     (the method: trick a human)
        └ SUB-TECHNIQUE : Spearphishing Link (T1566.002)
             └ PROCEDURE : a DocuSign-styled email with a link to a
                           pixel-perfect fake SSO portal that harvested
                           the loan officer's password   ← what actually happened

Why does this hierarchy matter so much to a defender? Three reasons, each practical.

First, ATT&CK is a common language, which means threat intelligence becomes actionable across organizations. When a security vendor or government agency publishes that a given APT "uses T1566.002 for initial access, T1059.001 for execution, and T1071.001 for command and control," your team can immediately ask, "do we detect those techniques?" — and act, without first having to decode prose into specifics. The SolarWinds reporting, the ransomware advisories, the CISA alerts you will read in your career are all written in ATT&CK.

Second, ATT&CK is a coverage map. You can lay your detections over the ATT&CK matrix and see your gaps — which techniques you would catch and which would sail through unnoticed. This turns "are we secure?" (unanswerable) into "which techniques used by the actors who target us can we currently detect?" (answerable, and improvable). We build exactly this detection coverage practice in Chapter 22.

Third, ATT&CK is threat-informed defense made operational. Because the framework documents which groups use which techniques, you can prioritize detections for the techniques used by the adversaries who realistically target your sector. A bank can pull the techniques associated with financially motivated groups and ransomware operators and focus its limited engineering there, rather than trying to detect all of attacker-kind at once.

🛡️ Defender's Lens: The single most important habit ATT&CK instills is detecting behavior, not just indicators. An IP address or a file hash (which we define next, in §2.5) is easy for an attacker to change — a new server, a recompiled binary, and your block list is stale. But a technique — say, dumping credentials from memory, or using a built-in scripting interpreter to run code — reflects how the attacker fundamentally operates, and is far costlier for them to abandon. Detections written against techniques age slowly and catch variants; detections written against specific indicators age in days. ATT&CK pushes you up this "pyramid of pain" toward the durable detections. We climb that pyramid deliberately in Chapter 22.

⚠️ Common Pitfall: Treating ATT&CK as a checklist to "complete." Teams sometimes try to build a detection for every one of the hundreds of techniques and burn out, or they paint their coverage map green by writing brittle, low-quality detections just to claim the cell. ATT&CK is a prioritization and communication tool, not a compliance bingo card. Cover the techniques used by the threats that realistically target you, write detections good enough to actually fire on real behavior, and be honest about the gaps. A truthful map with real coverage of the relevant techniques beats a green wall of detections that never catch anything.

🔗 Connection: ATT&CK is a Tier-1 canonical resource (see §7 of the style conventions and this chapter's further reading), maintained at attack.mitre.org and used by virtually every serious security team, vendor, and government agency. It is not a vendor product or a passing trend; it is closer to a shared standard. You will meet it again in detection engineering (Chapter 22), and the landmark breaches of Chapter 40 are routinely dissected technique-by-technique using it. Learning to "speak ATT&CK" is one of the highest-leverage things a new defender can do.

🔄 Check Your Understanding: 1. Define tactic, technique, and procedure, and give a one-line example of each for a phishing-based intrusion. 2. Why does a detection written against a technique (e.g., "credentials dumped from memory") tend to be more durable than one written against a specific indicator (e.g., a particular malicious IP address)?

Answers

1. Tactic = the adversary's goal in a phase (e.g., Initial Access — get a foothold). Technique = the method (e.g., Phishing, T1566). Procedure = the specific implementation (e.g., a fake DocuSign email linking to a cloned SSO login page that harvests the password). 2. An indicator like an IP address is cheap for the attacker to change — a new server defeats the block instantly. A technique reflects how the attacker fundamentally operates; changing it requires re-engineering their tradecraft, which is far more costly, so behavior-based detections catch variants and age more slowly.

2.5 Anatomy of an intrusion: from initial access to impact

Models become real when you run an actual attack through them. Let us trace the SolarWinds (Sunburst) intrusion — one of the most consequential cyberattacks ever publicly documented, and an anchor case we return to throughout this book (detection in Chapter 22, supply-chain risk in Chapter 29, build-pipeline security in Chapter 31, and a full study in Chapter 40). Our goal here is not exhaustive forensic detail; it is to see how a sophisticated APT intrusion maps onto the kill chain and ATT&CK, and to find the defensive opportunity at each step. The high-level facts below are drawn from public reporting by the affected vendor, the U.S. government (CISA), and incident-response firms; treat the specifics as the widely reported public account (a Tier-1/Tier-2 mix as noted in the further reading), not a classified one.

First, two more terms you need, because they are the currency of intrusion analysis. An indicator of compromise (IoC) is an observable artifact that suggests a system may be compromised: a malicious file hash, a known-bad IP address or domain, a suspicious registry key, an unusual filename, a specific string in a log. IoCs are the evidence of an intrusion — the things you search your environment for to find an attacker's traces. And threat intelligence is curated, analyzed information about adversaries — their identities, motivations, infrastructure, and TTPs — that helps defenders anticipate, detect, and respond to attacks. IoCs are raw evidence; threat intelligence is the analyzed understanding that gives those indicators meaning and tells you which adversary to expect. A list of bad IP addresses is data; "these IPs are the C2 infrastructure of a financially motivated group currently targeting regional banks, and here are the techniques they use" is intelligence.

Now the intrusion, stage by stage.

Reconnaissance and Resource Development. The attackers — a sophisticated, state-linked group — chose not to attack their ultimate targets directly. Instead they targeted SolarWinds, a software company whose network-management product, Orion, was installed deep inside thousands of organizations, including government agencies and major enterprises. This is the strategic insight of a supply-chain attack: why break into ten thousand well-defended networks when you can compromise one trusted supplier they all install? The attackers developed the capability to tamper with Orion's build process.

Initial Access and the weaponized supply chain (ATT&CK: Supply Chain Compromise, T1195). The attackers gained access to SolarWinds' software build pipeline — the automated system that compiles and packages the product — and inserted malicious code into Orion such that it was signed and distributed as a legitimate, trusted update. This is the part that made the attack so devastating: the malware arrived through the front door, cryptographically signed by the vendor, indistinguishable from a normal patch. Customers who did exactly the right thing — keep your software updated — installed the backdoor. Defensive opportunity: this is precisely why Chapter 31 (securing the build pipeline) and Chapter 29 (third-party and supply-chain risk, software bills of materials) exist. The lesson is that "trusted" is not a permanent property; trust in a supplier is a risk that must be managed, not assumed.

Delivery and Installation (Persistence, T1542-class behavior). When customers installed the trojanized update, the malicious code — later named SUNBURST — embedded itself as a backdoor inside a legitimate, signed Orion component. It then did something that betrays its authors' patience and sophistication: it did nothing for about two weeks. It lay dormant, a deliberate delay to evade sandboxes and analysis, before activating. Defensive opportunity: dormancy defeats naive "detonate it in a sandbox and watch" analysis, which is why behavioral detection over time, and assuming that even signed software can misbehave, matters.

Defense Evasion and Discovery. Once active, the backdoor was meticulous about staying hidden. It checked its environment, avoided systems running security-analysis tools, disguised its network traffic to blend with legitimate Orion telemetry, and moved with the patience of an espionage actor rather than the haste of a criminal. Defensive opportunity: the attacker's stealth is real, but stealth is not invisibility. The backdoor still had to act — and action, eventually, leaves traces.

Command and Control (Application Layer Protocol, T1071; and a notable use of DNS). The backdoor reached out to attacker infrastructure for instructions, using a custom protocol and domain-generation techniques designed to look like normal Orion network behavior. Defensive opportunity: this is where the chain finally broke. The intrusion was ultimately uncovered not by antivirus catching a bad file, but in part because defenders noticed anomalous behavior — and one widely reported thread of the discovery involved a security firm detecting that an employee had enrolled a second device for multi-factor authentication, an authentication anomaly that did not fit normal behavior. The attacker's beaconing and lateral movement, however careful, were behaviors that disciplined detection could surface. The most sophisticated intrusion of its era was caught by paying attention to what was anomalous, not to a signature of what was known-bad.

Actions on Objectives (Collection and Exfiltration). For the relatively small number of high-value targets the attackers chose to pursue beyond the initial backdoor, the objective was espionage: access to email, documents, and sensitive systems at government agencies and enterprises. They moved laterally, escalated privileges, and quietly collected information — the patient, watch-don't-grab signature of a nation-state actor. Defensive opportunity: segmentation, least privilege, and monitoring of sensitive systems limit how far an objective can reach even after a foothold; and detection of lateral movement and anomalous access can catch the objective in progress.

Now map this whole intrusion to its lessons in one view:

 STAGE (kill chain)     WHAT SUNBURST DID                 DEFENSIVE OPPORTUNITY
 ──────────────────     ──────────────────────────────    ─────────────────────────
 Recon / Resource Dev   targeted a trusted SUPPLIER,       supplier risk is YOUR risk
                        not the victims directly           (Ch.29 TPRM/SBOM)
 Initial Access         poisoned the build pipeline;       secure the pipeline
   (Supply Chain, T1195) shipped SIGNED malware            (Ch.31); don't assume trust
 Install / Persistence  backdoor in signed component,      behavioral detection over
                        dormant ~2 weeks                   time; "signed" ≠ "safe"
 Defense Evasion        blended with Orion traffic,        stealth ≠ invisibility;
                        avoided analysis tools             instrument everything
 Command & Control      beaconed to attacker infra         anomaly detection caught it
   (App-Layer, T1071)   via custom/DNS techniques          (Ch.22) — NOT a signature
 Actions on Objectives  espionage: email, docs at          segmentation + least priv
   (Collection/Exfil)   selected high-value targets        limit reach; monitor crown jewels

Figure 2.2 — SolarWinds mapped to the kill chain. The intrusion was caught at Command and Control by behavioral anomaly detection, not by a signature — the central lesson of threat-informed defense.

🛡️ Defender's Lens: Notice what did not save the victims and what eventually did. Antivirus did not save them — the malware was signed and trusted. "Keep your software patched" did not save them — patching is what delivered the backdoor. Compliance checklists did not save them. What surfaced the intrusion was behavioral anomaly detection and a culture of investigating things that did not fit — an extra MFA enrollment, traffic that was subtly wrong, accounts doing things they had never done. This is the empirical case for Theme 4 (assume breach) and for the entire Part V investment in monitoring, detection, and hunting. When prevention is bypassed by a signed supply-chain attack, detection is what is left, and detection is a capability you build, fund, and practice.

⚠️ Common Pitfall: Concluding "we could never stop a nation-state, so why bother?" This is the wrong lesson and a dangerous one. First, the vast majority of attacks you will face are not nation-states; they are opportunistic criminals and script kiddies whom solid hygiene reliably defeats. Second, even against SolarWinds-class adversaries, the controls that matter — segmentation, least privilege, behavioral detection, supply-chain risk management — limit the blast radius and shorten the dwell time even when they do not prevent initial access. Defense is not binary. "We cannot guarantee prevention" is true and is precisely why detection, containment, and recovery exist. The defender's job is not to make breaches impossible; it is to make them rare, expensive, shallow, and survivable.

🔄 Check Your Understanding: 1. Why is a supply-chain attack like SolarWinds so dangerous, and which two later chapters address the defenses it motivates? 2. The SolarWinds backdoor was ultimately surfaced by behavioral anomaly detection rather than by antivirus signatures. What does that tell you about where to invest when facing sophisticated, stealthy adversaries?

Answers

1. A supply-chain attack compromises a trusted supplier whose software is installed across many organizations, so the malware arrives signed and trusted through the normal update process — defeating "keep your software patched" and bypassing perimeter defenses. The defenses are built in Chapter 29 (third-party/supply-chain risk, SBOMs) and Chapter 31 (securing the build pipeline). 2. Against stealthy adversaries who use signed software and living-off-the-land techniques, there may be no "bad file" for a signature to catch; you must invest in behavioral detection — monitoring for anomalous account, host, and network behavior — and in a culture that investigates things that do not fit. This is the rationale for the detection-and-hunting program in Chapter 22.

Before we leave the anatomy of intrusions, contrast SolarWinds with the threat most likely to actually hit a bank: ransomware. Where SolarWinds was patient espionage, a ransomware intrusion is usually fast and loud, and its objective is money via the availability leg of the CIA triad (Chapter 1, §1.5) — encrypt the victim's data and extort payment for the key. The 2021 Colonial Pipeline incident, which we revisit as an incident-response tabletop in Chapter 24 and in operational-technology context in Chapter 33, is the canonical example: a single compromised credential to a legacy remote-access account let a financially motivated group into a critical fuel pipeline's IT network, and the operational decision to shut down the pipeline — to be safe while the IT compromise was understood — caused fuel shortages across the U.S. East Coast. The technical attack hit IT; the impact rippled into the physical world. Modern ransomware has also evolved into double extortion — stealing the data before encrypting it, so that even a victim with good backups faces the threat of public leakage (we trace this evolution in Chapter 35). For a defender, the ransomware kill chain offers many links to break: phishing-resistant authentication and patched remote access (Initial Access), least privilege and segmentation (Lateral Movement), behavioral detection (the noisy, fast escalation is detectable), and — the decisive one — tested, offline backups that neutralize the encryption leverage entirely. We will run exactly this scenario as a full Meridian tabletop in Chapter 24.

2.6 Threat modeling Meridian (STRIDE-lite)

We have the cast (§2.1), the motives (§2.2), the kill chain (§2.3), the shared language (§2.4), and a worked intrusion (§2.5). Now we synthesize all of it into the deliverable that makes this chapter actionable: a threat model. A threat model is a structured analysis of what could go wrong with a system — the assets worth protecting, the adversaries who might target them, the ways they could attack (the attack vectors and techniques), and the defenses that address each. Threat modeling answers, in an organized way, the questions a defender must answer before spending a dollar: what are we protecting, who would attack it, how, and where do we stop them? (We are building the basic, organization-level threat model here. The application-specific flavor of threat modeling — modeling a single software feature's data flows — is built in Chapter 12; this chapter owns the foundational concept.)

There are several methodologies; we will use a lightweight version of STRIDE, a model originally from Microsoft that prompts you to consider six categories of threat. The value of STRIDE is that it is a checklist against forgetting — for any asset, it nudges you to ask about each threat category rather than only the one that springs to mind. The six categories, each paired with the CIA property it threatens and an example at Meridian:

Let us run a STRIDE-lite pass on one of Meridian's crown-jewel assets — the online/mobile banking platform — and connect each identified threat to an actor, a kill-chain stage, and a defense. This is the analysis Theo and Sam perform for the Project Checkpoint.

ASSET: Online/mobile banking platform   (CIA emphasis: Availability, Integrity, Confidentiality)

S  Spoofing       Threat actor: cybercriminal (phishing/credential-stuffing)
                  Vector: fake login portal; reused/breached passwords
                  Kill-chain: Delivery -> Exploitation
                  Defense:  phishing-resistant MFA (Ch.16); account lockout;
                            DMARC to curb spoofed mail (Ch.9)
T  Tampering      Threat actor: criminal or insider altering transactions
                  Kill-chain: Actions on Objectives
                  Defense:  integrity checks, transaction signing, change control,
                            segregation of duties on transfers (Ch.17)
R  Repudiation    Threat: disputed transactions with weak audit trail
                  Defense:  comprehensive, tamper-evident logging (Ch.21)
I  Info disclosure Threat actor: criminal exfiltrating customer/account data
                  Kill-chain: Actions on Objectives (Exfiltration)
                  Defense:  encryption (Ch.4-5), least privilege, DLP, segmentation
D  Denial of svc  Threat actor: hacktivist or extortionist (DDoS/ransomware)
                  Kill-chain: Actions on Objectives (Impact)
                  Defense:  DDoS mitigation (Ch.6), tested offline backups (Ch.24)
E  Elevation      Threat actor: any foothold -> domain admin
                  Kill-chain: Privilege Escalation -> Lateral Movement
                  Defense:  least privilege, PAM, tiering (Ch.19), segmentation

Figure 2.3 — STRIDE-lite threat model for Meridian's banking platform. Each threat category maps to a likely actor, a kill-chain stage where it lives, and the chapter that builds its defense — turning the threat model into the table of contents of Meridian's security program.

Two things to notice. First, the threat model is a bridge between this chapter and the rest of the book: nearly every defense named above is built in a later chapter, which means a good threat model literally generates your roadmap of what to build and in what order. (Recall from Chapter 1's case study that Meridian's first risk register did the same thing; the threat model is the more structured, attacker-aware version of that idea.) Second, the threat model is where the actor taxonomy pays off. Because Meridian is a bank, the STRIDE pass is dominated by financially motivated criminals and the occasional hacktivist; an APT is possible but lower-likelihood, and an insider is always present. That actor profile tells Meridian to invest first in the controls that defeat the likely threats — strong authentication, segmentation, monitoring, backups — rather than spreading thin against every conceivable adversary. Threat modeling is how you spend a finite budget against an infinite landscape.

🧩 Try It in the Lab: Pick a system you actually use — your email account, a personal website, a small app you maintain. Run a STRIDE-lite pass on it: for each of the six categories, write one concrete threat, the kind of actor who would attempt it, and one defense you do (or should) have. This takes fifteen minutes and is, in miniature, exactly what a security team does for a crown-jewel asset. Notice which categories you struggle to populate — those are often your blind spots, which is the entire point of using a checklist model rather than free association.

⚖️ Authorization & Ethics: Threat modeling is a purely defensive, analytical activity — you are reasoning about your own systems and how to protect them, which requires no special authorization. But this chapter has taught you how attacks work, and that knowledge carries the responsibility we set out in Chapter 1: study offense to defend, and apply any active technique (scanning, testing) only to systems you own or are explicitly authorized to assess. Understanding the kill chain makes you a better defender; it is not a license to walk one against someone else's network.

🔄 Check Your Understanding: 1. What does the "E" in STRIDE stand for, which CIA property does it threaten, and at which kill-chain stage(s) does it typically occur? 2. Why does building a threat model help an organization prioritize its security spending rather than just listing dangers?

Answers

1. Elevation of privilege — gaining capabilities you should not have; it threatens authorization and typically occurs at the Privilege Escalation (and subsequent Lateral Movement) stages, after an attacker has an initial foothold. 2. A threat model ties each threat to a likely actor and a kill-chain stage, which reveals which threats are realistic for this organization and where the highest-value defenses sit; you can then fund the controls that address the most likely, highest-impact threats first, instead of spreading a finite budget evenly across every conceivable danger.

Project Checkpoint

This chapter advances both Meridian deliverables: the security program gains a threat model and threat-actor profile, and bluekit gains its second module, threatmodel.py.

Program increment — Meridian's threat model + actor profile. Building on the asset inventory and risk register from Chapter 1, Theo and Sam produce two artifacts. The first is a threat-actor profile: a one-page statement of who realistically targets a regional bank and how much to weight each. For Meridian, the honest profile is: cybercriminals (primary) — ransomware crews, credential-theft operators, fraud groups, and the initial-access-broker market that feeds them; insiders (always present) — mostly accidental, occasionally malicious; hacktivists (situational) — low baseline, spiking with controversy; nation-state/APT (lower-likelihood but high-impact) — possible because banks are strategically interesting and because supply-chain attacks (SolarWinds) make even mid-size firms reachable. The second artifact is a STRIDE-lite threat model for each crown-jewel asset (we did the banking platform in §2.6; the team repeats it for the core-banking database, Active Directory/Entra ID, and the cardholder data environment). Each threat is tagged with its likely actor, its kill-chain stage, and the chapter that builds its defense. Together, these become §2 of Meridian's security-program document, and — crucially — they re-prioritize the Chapter 1 risk register around the actors who actually matter. Templates live in Appendix I.

bluekit increment — threatmodel.py. We turn the kill chain into a small classifier that maps a raw security event to the kill-chain stage it represents — the first step toward the detection logic we expand in Chapter 22. As always, the code is illustrative and never executed during authoring; the expected output is hand-traced in a comment.

# bluekit/threatmodel.py  — Chapter 2 increment
"""Map security events to kill-chain stages, and size an attack surface.

kill_chain_stage() is a teaching classifier (keyword-based), not a detection
engine — Chapter 22 builds the real thing. Illustrative; not executed here.
"""

# minimal keyword -> kill-chain stage map (lowercased substring match)
_SIGNS = {
    "port scan": "Reconnaissance", "vuln scan": "Reconnaissance",
    "phishing": "Delivery", "malicious link": "Delivery",
    "exploit": "Exploitation", "credential use": "Exploitation",
    "new service": "Installation", "scheduled task": "Installation",
    "beacon": "Command and Control", "c2": "Command and Control",
    "exfil": "Actions on Objectives", "ransomware": "Actions on Objectives",
}


def kill_chain_stage(event: str) -> str:
    """Return the kill-chain stage for an event description, or 'Unknown'."""
    e = event.lower()
    for sign, stage in _SIGNS.items():
        if sign in e:
            return stage
    return "Unknown"


def attack_surface(assets: dict) -> int:
    """Sum exposure points across assets: {asset: {'ports': n, 'apis': n, 'users': n}}."""
    return sum(a.get("ports", 0) + a.get("apis", 0) + a.get("users", 0)
               for a in assets.values())


if __name__ == "__main__":
    for ev in ["Port scan from 203.0.113.9", "Phishing email reported",
               "Beacon to unknown domain every 60s", "Ransomware note found"]:
        print(f"{kill_chain_stage(ev):22s} <- {ev}")
    meridian = {"portal": {"ports": 2, "apis": 5, "users": 0},
                "ad": {"ports": 3, "apis": 0, "users": 1800}}
    print("attack surface points:", attack_surface(meridian))

# Expected output:
# Reconnaissance         <- Port scan from 203.0.113.9
# Delivery               <- Phishing email reported
# Command and Control    <- Beacon to unknown domain every 60s
# Actions on Objectives  <- Ransomware note found
# attack surface points: 1810

Notice what these thirty lines do for Meridian. kill_chain_stage() lets an analyst tag each alert with where in an attack it would sit — the first move toward thinking in chains rather than isolated events, and the seed of the detection-mapping work in Chapter 22. attack_surface() turns Chapter 1's qualitative "attack surface" idea into a countable number that can be tracked over time: as Meridian reduces exposed ports and tightens accounts, the number should fall, giving the program a metric (a theme we develop fully in Chapter 36). You have written the second module of the toolkit — and connected the abstract kill chain to a concrete line of analysis code.

Summary

This chapter turned the vocabulary of Chapter 1 toward the adversary: who attacks, why, and how — and how a defender decomposes an attack into stoppable steps.

• Threat actors sort by motivation (why) and capability (how good): nation-state/APT (espionage, very high capability, patient), cybercriminal (money, scales via automation, the bank's primary threat), hacktivist (ideology, situational), insider (legitimate access, often accidental), and script kiddie (ego, runs others' tools, cannot improvise). Naming the actor is a defensive act.
• The four big motivations — money, espionage, ideology, ego — predict behavior: money moves fast toward monetization; espionage moves slowly and quietly toward information; ideology targets by belief, not value; ego seeks the easy win. Read the goal, anticipate the moves.
• The cyber kill chain decomposes an intrusion into stages (Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command and Control → Actions on Objectives). Its liberating lesson: the attacker must pass every stage, but you only have to break one link — the engine of defense in depth.
• MITRE ATT&CK is the field's shared language for attacker behavior, organized as tactics (the goal), techniques (the method, with stable IDs like T1566), and procedures (the specific implementation) — together, TTPs. It serves as a common language, a coverage map, and the operational basis of threat-informed defense. Detect behavior, not just indicators.
• An IoC (indicator of compromise) is an observable artifact of an intrusion; threat intelligence is the analyzed understanding that gives indicators meaning. An attack vector is the path an attacker uses to reach a target; a payload is the part that executes the attacker's intent.
• SolarWinds showed that trust is a risk to manage: a signed, supply-chain-delivered backdoor defeated antivirus and patching and was ultimately caught by behavioral anomaly detection — the empirical case for assume-breach and for investing in monitoring, detection, and hunting (Part V). Ransomware (e.g., Colonial Pipeline) is the fast, money-driven, availability-targeting threat most likely to hit a bank, with many links to break and tested offline backups as the decisive control.
• A threat model (here, STRIDE-lite: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a structured answer to what are we protecting, who would attack it, how, and where do we stop them? It ties each threat to an actor, a kill-chain stage, and a defense — turning the threat landscape into a prioritized roadmap.

Spaced Review

Before moving on, retrieve from Chapter 1 — concepts resurface here at a wider interval so they stick. Try these without scrolling back.

1. Define, in one sentence each, threat, vulnerability, exploit, and risk, and state the relationship among them. (Then notice: in this chapter, a threat actor is the who, a kill-chain stage is the how, and a control breaks the chain — the same four words, now in motion.)
2. From Chapter 1: why does connecting a system to the internet immediately raise its risk, even if no specific human is interested in it? Which actor type from this chapter is the human face of that automated probing?
3. Chapter 1 modeled $\text{Risk} = \text{Likelihood} \times \text{Impact}$. Meridian's threat-actor profile rates cybercriminals as high-likelihood and nation-states as lower-likelihood. If a nation-state attack would be far higher impact, how should that shape Meridian's spending — and what does the multiplication tell you about not ignoring a low-likelihood, high-impact risk entirely?

What's Next

You now know your enemy — the actors, their motives, the stages of their attacks, and the language defenders use to describe them — and you have built Meridian's first threat model. What you do not yet have is the organizing principles that turn this threat-awareness into sound defensive design. Chapter 3 supplies them: the CIA triad in full (previewed in Chapter 1), the AAA model and non-repudiation, the taxonomy of control types and functions, and the bedrock design principles — least privilege, separation of duties, fail-safe defaults, defense in depth, and the zero-trust mindset. Where this chapter asked "who attacks and how?", Chapter 3 asks "how do we organize a defense that holds?" — and it will classify the very controls that stopped the Meridian phishing attempt, so the principles arrive already attached to a story you know.