Loading module…
Loading module…
Module 1 of 13
Rung one · the lens — what to protect, from whom, and what to do first
Most security is bought the way people buy fire extinguishers after a fire next door. A ransomware story leads the news, and a backup product appears in next year's budget. Someone forwards a list of the ten most critical web-application risks, and the list is pasted into a project as its security requirements, whether or not the project looks anything like the systems the list was written about. A vendor shows a dashboard full of red, and the red becomes the board's picture of risk. A senior executive reads about a fraud involving a faked voice and orders "awareness training for everyone", with no idea who in the organisation could actually move money on a phone call. Each purchase answers a real fear. None answers the question that should have come first: what exactly are we protecting, from whom, and what should we do first? The result is familiar to anyone who has worked in security. Controls pile up wherever the last headline pointed; every risk is rated "high", so nothing can be ranked; tools are installed but nobody checks that they work; and the most dangerous path through the system — the one a real adversary would take — was never drawn, because nobody drew the system at all. This course's subtitle names the pattern: security without threat modeling is just expensive guessing. It teaches threat modeling: the structured, repeatable way to decide what to protect, from whom, and what to do first — for a system you own or are designing, for an organisation you work for, or for your own life — and to write the answer down so that it can be checked, shared, argued with and changed. A threat model is not a scan, a penetration test or an audit. Those examine a system that already exists for specific weaknesses; threat modeling reasons about what could go wrong, ideally before anything is built, and produces an explicit model that the people who build, fund and run the system can read. The method rests on six elements that every threat model has, whether its subject is a web portal or a person. The subject is what we are working on, drawn as parts, the flows between them and the trust boundaries where control or trust changes hands — for a system, a data-flow diagram; for a person, a model of their life as a system of accounts, devices, people, places, money and public footprint. Assets are what is worth protecting, and to whom: data, functions, money, reputation, safety and people's wellbeing. Adversaries are who would act, why, with what capability and what opportunity — plus the accidents and honest mistakes that can do as much damage as an attacker. Threats are what can go wrong, found systematically rather than remembered: with STRIDE, a checklist of six threat types applied to each element of the diagram, with privacy-threat checklists, and with attack trees that break an adversary's goal into the routes that reach it. Risk is likelihood and impact taken together and ranked honestly, with ranges rather than false precision. And responses are what we decide to do about each risk — mitigate it, eliminate it, transfer it or accept it — each with an owner and a way to verify that it works. Four questions bind the six together. They come from the Threat Modeling Manifesto, published in 2020 by a group of practitioners in the field, and they are the spine of this course: What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? One fictional organisation carries the whole course. Kestrel Motion, the servo-motor and drive maker you may know from earlier courses in this catalogue — above all Course 014, which assessed its security posture, and Course 016, which rebuilt its network — has plants at Aldren and Brask in the Meridian Union, about 1,100 employees, an IT team of 9 that includes a security lead and one analyst, reporting to the CFO, a managed-service provider, Corvane IT Services, and a managed detection and response (MDR) service that runs its security monitoring. This course follows Kestrel through two threat models at once. Strand A is a system: the Kestrel Distributor Portal, sponsored by the head of sales and built by an external developer, Varnhold Digital, so that about 60 distributors with about 180 user accounts can see their own prices, place orders, track deliveries and download invoices — a new door onto the ERP, the system that holds Kestrel's orders, prices and invoices. Strand B is a person: Kestrel's CFO, who approves large payments, is named in press coverage of an acquisition and in public company filings, and asks for a personal threat model after a fraud attempt is stopped in the portal project's third week. This module lays out the threat model board, the transformation the course produces and the thirteen-rung method — and it draws the boundary first. This is a defender's and designer's course. Adversary thinking stays at the depth a defender needs: goals, sub-goals, tactic names from MITRE ATT&CK, and vulnerabilities only by their public class names, such as "broken access control" — never exploitation steps, payloads, tool usage, evasion, or instructions for breaking into, tracking, impersonating or surveilling anyone. Attack trees are drawn to the depth where a control can be attached, and no deeper. Social engineering appears only as signs to recognise and processes that stop it. Testing happens only with written authorisation. A person is modeled only with their consent and participation, and when the risk to someone comes from a person they know, the course's answer is safety first: the signs, and where to get help — never confrontation or counter-surveillance. Every judgement carries a probability from the course's seven-band yardstick and a separate confidence of high, moderate or low (or not known); every claim is labelled fact, assessment or speculation with its source; and every money and time figure is a range or marked illustrative.
The six elements are the periodic table of this course, and the board lays them out in the one arrangement that shows how they act on one another — so read it as a mechanism, not as a poster. Start on the left with the subject. A data-flow diagram (DFD) uses four symbols and no more: external entities (squares) are people or systems outside your control that send or receive data — the distributors, the email service, Varnhold's build pipeline, Kestrel's sales staff; processes (circles) are the code or services that do something with data — the portal web application, the customer identity service, the integration service, the admin console; data stores (open-ended bars) are where data rests — the portal database, the ERP, the audit log; and flows (arrows) are data moving between them. The DFD is deliberately plain: it shows what talks to what and where data goes, not how the servers are built, because those are the facts threats attach to. The red dashed lines are the most important thing on it. A trust boundary is any place where the level of trust or control changes: between the internet and the portal (TB1), between the portal in the DMZ — the network zone for services the internet must reach — and the integration service in the internal servers zone (TB2), between the integration service and the ERP (TB3), between Kestrel's staff and the admin console (TB4), and between Varnhold's pipeline and the production portal (TB5). Threats cluster at boundaries, because a boundary is where one side must decide whether to believe what the other side sends; a flow that crosses a boundary unchecked is a design decision nobody made on purpose. For a person the subject panel becomes a life model — the person at the centre, ringed by accounts, devices, people, places, money and public footprint — and the same idea holds: where the CFO's personal email can reset a work account, or where a family member's public post reveals that the CFO is abroad, trust crosses a line. Move to the centre. The STRIDE badges are pinned on the element each threat attacks, because STRIDE is used per element: S for spoofing (pretending to be someone or something else), T for tampering (altering data or code), R for repudiation (denying an action when there is no trustworthy record), for information disclosure (exposing data to someone not entitled to it), for denial of service (making the system unavailable) and for elevation of privilege (gaining rights one should not have). STRIDE was developed at Microsoft in 1999 and its strength is not cleverness but coverage: walking six questions across every element finds threats that no one in the room would have remembered unprompted. Beneath the badges hangs an , the structure Bruce Schneier popularised in 1999: an adversary's goal at the top, the ways to reach it below, joined by (any one branch is enough) and (every branch is needed). The board's tree is drawn from the defender's side — — and it stops at the depth where a control attaches, which is both the ethical line of this course (Module 2's ) and the practical one: the defender needs to know where to cut a path, not how to walk it. The AND branch shows why trees matter: taking over a distributor's account needs a reused, leaked password no second factor or rate limit, so one control that removes either condition cuts the whole branch. On the right is the : each threat that matters, ranked by likelihood and impact on a shared yardstick, carrying an owner chip (drawn here on the accepted risk, PT7, signed by the head of sales), the control chips (PC1–PC9) that answer it, and a that says whether anyone has shown the control works. A ladder without ticks is a list of intentions; the ticks are what separate a threat model from a wish list. And underneath runs , the four questions as a cycle, because a threat model is never finished: every change to the system and every incident sends you back to with new facts. The four questions are exactly the parts of the board: is the subject panel; is the badges and the tree; is the ladder and its chips; and is the ticks, the version stamps and the timeline. The central idea follows from the drawing. A system's security is a property of how its parts, flows and boundaries are arranged — not of the products bought for it. A portal can have a firewall in front of it, an expensive scanner run against it and a strong password policy, and still let any logged-in distributor read any other distributor's invoices, because no product knows that is a rule the server must check on every request. Only someone who has drawn the system and asked what can go wrong at each element will find that. Every later module lights one part of the board: Module 3 the subject panel, Module 4 the assets on it, Module 5 the adversary cards beside it, Module 6 the STRIDE badges, Module 7 the attack tree, Module 8 the ladder, Module 9 the control chips, Module 10 the life model, Module 11 the loop placed in a delivery timeline, Module 12 the ticks and the version stamps, and Module 13 the whole board, before and after.
Traced instance: the portal from Week 0 to Week 30, and the CFO alongside it. At Week 0 — Month 7 of the security programme that Courses 014 and 016 followed — the head of sales sponsors the portal and Varnhold is engaged to build it. The security lead asks for a design threat model before any code is written, and runs it as four 2-hour sessions in Weeks 2–5, with the network engineer (from Course 016), the ERP application owner, the head of sales' portal product owner and Varnhold's technical lead around the table. The first question, what are we working on?, produces the DFD on the board: four external entities, four processes, three data stores and five trust boundaries, with the portal web application behind the reverse proxy in the DMZ (course 016's R5) and the integration service as the only component allowed to talk to the ERP. The same sessions value the assets — distributor-specific prices and discounts, order integrity and invoices and payment details all high; distributor accounts medium alone but high as a stepping stone; the ERP critical, as one of Course 014's crown jewels; portal availability medium, because a fallback ordering channel exists — and ground the adversaries in Kestrel's own picture rather than in films: financially motivated fraudsters and credential-stuffing operators (who try passwords leaked from other sites against new ones) as primary; a curious or dishonest distributor looking at another's prices; ransomware groups seeking a path to the ERP across TB2 and TB3; a supply-chain compromise of the developer or a third-party library, low likelihood but high impact; and competitors wanting price lists, assessed but not evidenced. The second question, what can go wrong?, is answered by walking STRIDE across every element and adding abuse cases — misuses of legitimate functions — which yields ten threats, PT1–PT10, from account takeover through reused passwords (PT1) to payment-detail fraud through the portal's messages or refund process (PT10). The third question produces the Week 5 ranking. PT5 — one distributor seeing another's prices or invoices because the server does not check who owns each record, the class of flaw known as broken access control — goes first: it is likely to be present unless it is designed out, and its impact is high. PT1 follows (an attempt within a year , 80–95%; impact medium–high), then (, 55–80%; impact high) and , supply-chain compromise (, 20–45% over three years; impact critical). PT3 and PT8 have high impact but are made unlikely by design; , denial of service near order deadlines, is with a fallback channel — orders by email and phone, and a rule for extending deadlines — and its risk owner, the head of sales, signs for it. Nine controls answer the threats, : among them MFA, rate limiting and a breached-password check for every distributor account (), a server-side ownership check on every record request backed by automated tests (), an admin console not reachable from the internet (), an integration service that re-checks every price and quantity against the ERP (), and no payment-detail changes through the portal at all (). The model is issued as at . In the middle of those sessions, in , accounts payable receives an email from a lookalike of a real supplier's domain asking to change bank details, and the call-back rule from course 014's stops it (fact). The CFO, whose signature moves money, asks the security lead for a , built together in with the CFO's consent and only the information the CFO chose to share. The build runs , and the fourth question, , gets its first hard answer in : an authorised pre-launch penetration test by an independent firm, under a written scope signed by the CFO and the head of sales, using test accounts only. It finds — two invoice-download functions lacked the PC2 ownership check, so a test distributor account could open another test account's invoice — and findings, verbose error messages on one page and sessions that stayed valid too long; it confirms that the admin console is not reachable from the internet and that prices are re-checked by the integration service (fact). The high finding is fixed before launch and added to the automated tests; the model becomes in , and the portal launches in . Then reality tests it twice. In (), about arrive from many addresses; rate limiting and MFA hold, , and distributors whose passwords turn up in breach lists are reset — detected through the identity service's alerts to the MDR (fact). In (), emails from a announce "new bank details" to distributors; exact-domain spoofing is blocked because Kestrel's domain publishes a policy of (the email-authentication setting from course 016's that tells receivers to refuse mail failing Kestrel's checks), but the lookalike reaches distributors; to check, as the launch notice had advised, and (fact). Lookalike-domain monitoring is added and PT2's residual risk re-rated. On the personal side, in a call and voice message apparently from the asks the CFO for an urgent, confidential transfer "to secure an acquisition"; the CFO applies the payment rule (), calls the CEO back on the known number, finds no such request, and reports it — (fact; whether the voice was synthetic is ). In a sign-in to the CFO's personal email from an unfamiliar country is (), and the password is changed (fact). At the review both models are revisited together; the portal model becomes , PT1 and PT2 are re-scored, lookalike domains become a standing branch of PT2, and PC2–PC5 need no change. Notice what the board does claim: PC7 and PC9, like the CFO's CC3–CC6, are marked pending rather than verified, because nothing yet has shown them working — and an honest board does not draw a verified tick it has no evidence for.
The gap between the two is the whole value of the course — and it is worth being fair to the guesser first. The expensive guesser is not careless. Security budgets really are set in the weeks after a frightening story, boards really do ask "could that happen to us?", and buying a recognised product is a defensible answer to a question nobody has framed more precisely. The trouble is structural, and it has three parts. Guessing is incomplete: people defend against the threats they happen to think of, which are the vivid and the recent, and intuition has no way of finding its own blind spots. Guessing misallocates: without a way to compare risks, effort flows to what feels frightening rather than to what is both likely and damaging, and because resources are finite, defending the wrong thing leaves the right thing undefended. And guessing has no shared basis: the reasoning lives in one person's head, where it cannot be reviewed, handed over or improved. Each of the guesser's habits is one of those defects in practice. The first is buying a tool after every headline, which answers somebody else's incident rather than your own system. The second is copying a generic list. The OWASP Top 10, a widely used list of web-application risk categories, ranks broken access control first in its 2021 edition — and the list is right; Kestrel's top risk, PT5, is exactly that class. But the list cannot tell you where in your system the check is missing, and pasting it in as requirements produces a document that mentions access control and a portal in which two invoice-download functions still lacked the check until the Week 20 test found them. The threat modeler uses such lists as a prompt while walking the diagram, not as a substitute for drawing it. The third habit is having no picture of the system, and the public record shows what that costs. The Target breach of 2013 is widely reported to have begun with credentials belonging to a heating and ventilation contractor — a third party whose access crossed a trust boundary, exactly the kind of crossing a drawn model puts in front of someone. The SolarWinds compromise disclosed in 2020 reached its victims through compromised software updates: a supplier's build-and-release path, the same kind of boundary as Kestrel's TB5, which is why PT9 sits on the ladder despite being unlikely. The fourth habit is rating every risk "high", which feels prudent and is useless, because a list in which everything is urgent cannot tell anyone what to do on Monday. The fifth is fearing movie villains — the brilliant state hacker — while the base rates point at the ordinary: reused passwords, payment fraud by email. The FBI's annual reports have consistently listed — fraud by email that impersonates an executive or supplier to redirect a payment — among the costliest reported cybercrime types, and Kestrel's own experience fits: the Week 3 supplier lookalike, E2's "new bank details" and the CFO's Week 9 call are all the same mundane family. The sixth habit is . In the breach of , the entry point was traced to a known web-application vulnerability that had not been patched — a gap between what was assumed and what was true. A control that is assumed to be in place is a claim, not a fact, and Kestrel's Week 20 test turned one such claim — "every record request is owner-checked" — into a finding before an adversary could. The seventh is , so that the system changes and the model does not. And the eighth is . The guesser's plan covers servers; the threat modeler notices that the person who can approve a transfer is part of the attack surface. In , an employee of the engineering firm in was reported to have transferred about after a video call in which the "colleagues" were deepfakes. The defence that worked for Kestrel's CFO in Week 9 was not detection software but a rule decided in advance: two people, a call-back to a number already on file, and no exceptions for anyone, including the CEO. The replaces each habit with a discipline. It keeps a with trust boundaries, redrawn when the system changes. It and asks , because a distributor account that is worth little on its own is worth a great deal as a stepping stone. It in motive, capability, opportunity and base rates. It , element by element, so coverage does not depend on memory. It on a shared yardstick, with ranges, a confidence and a named owner. It puts , where one control cuts many paths, each with a criterion that says how we will know it works. It on every change and incident — the attack of , in which initial access was reported to have come through a legacy VPN account without MFA, is often cited as the kind of forgotten door that a model updated on every change exists to catch. And it as well as systems, with their consent. None of these disciplines is exotic; what the course adds is how to do each one on a real system and a real person, in the right order. At Kestrel, the modeler's portal went live with five trust boundaries drawn, ten threats found, the top four ranked with bands and nine controls with verification criteria; the Week 20 test found and closed the one gap that mattered most; and the two events after launch, E1 and E2, ended with no account taken over and no money lost — while the guessed version, by construction, would have shipped with a web firewall, a scan report and no one asking whether one distributor could read another's invoice.
The course is thirteen modules, and their order follows the four questions: you cannot find what can go wrong with a system you have not drawn, and you cannot decide what to do about risks you have not ranked. After this orientation, Module 2, The Threat Modeler's Discipline & Boundary, installs six commitments that govern everything else, tagged B1–B6 and cited by those tags throughout. B1, defend and never attack: adversary thinking only to the depth a control needs. B2, authorisation and consent: model what you own or are asked to model, test only with written authorisation, and model a person only with their consent and participation. B3, evidence and honesty: every claim sourced and graded fact, assessment or speculation, with probabilities taken from the seven-band yardstick — almost no chance (1–5%), very unlikely (5–20%), unlikely (20–45%), roughly even chance (45–55%), likely (55–80%), very likely (80–95%), almost certain (95–99%) — and a separate confidence of high, moderate or low, or not known where the gap is real. B4, privacy and proportion: a threat model is itself sensitive, so collect only what the decision needs, restrict who can read it and set how long it is kept. B5, security people can live with: proportionate, usable controls, the highest-value steps first, and no selling by fear. B6, a living model and blameless learning. Module 2 is a gate: the rest of the course assumes it. Modules 3 to 5 answer the first question and prepare the second. What Are We Working On? — Modeling the Subject covers scope and the question the model must answer (W1), data-flow diagrams (W2), trust boundaries (W3), a life modeled as a system (W4), assumptions and dependencies written down (W5) and the right level of detail (W6). Assets & Valuation covers what counts as an asset (A1), valuing by impact on confidentiality, integrity and availability, plus safety and privacy (A2), value to whom — the defender's view against the adversary's, and stepping-stone assets (A3), dependencies and aggregation (A4), personal assets such as identity, phone number, location, family and approval authority (A5), and an asset register that drives decisions (A6). Adversary Profiling covers motive, capability and opportunity (P1), the classes of adversary — criminal, insider both malicious and mistaken, state, hacktivist, competitor, and people in someone's personal sphere (P2), threat intelligence at the right level (P3), personas for individuals (P4), base rates rather than movie villains (P5) and the adversary register (P6). answer the second question. covers STRIDE per element of the diagram (S1), spoofing and tampering (S2), repudiation and information disclosure (S3), denial of service and elevation of privilege (S4), privacy threats with , the privacy threat modeling approach from KU Leuven, at a general level (S5), and abuse cases and business-logic threats, payment fraud among them (S6). covers trees: a goal, its sub-goals, AND/OR branches (T1), drawing them from the defender's side to the depth a control attaches (T2), paths across trust boundaries, third parties and the supply chain (T3), annotating branches with cost, likelihood and detectability (T4), mapping paths to ATT&CK tactic names (T5) and choke points where one control cuts many paths (T6). answer the third question. covers likelihood × impact on the yardstick (R1), the scoring schemes compared — why , also from Microsoft, is widely criticised as subjective and was later dropped from Microsoft's own process, why measures the severity of a vulnerability rather than the risk to you, and what (Factor Analysis of Information Risk) gains by working in ranges (R2) — ranges and uncertainty stated honestly (R3), the pitfalls of risk matrices (R4), prioritising by choke point, cost and time to fix (R5), and risk owners and explicit acceptance (R6). covers the four responses (D1), design principles such as least privilege, defence in depth, secure defaults, failing safe and separation of duties (D2), mapping controls to threats and checking coverage (D3), usability and human factors (D4), verification criteria (D5) and residual risk, stated (D6). apply the four questions beyond one system. covers the personal security plan built on the questions of the guide — what do I want to protect, from whom, how bad would it be, how likely is it, and how much trouble am I willing to go through to prevent it (H1) — executives and public-facing people facing impersonation, payment fraud, deepfaked voice and video and exposure of personal details (H2), family and household as part of the surface (H3), travel and devices (H4), safety-first handling when the risk is someone the person knows (H5), and a plan light enough to live with (H6). covers when to model (L1), light and deep models (L2), security requirements and acceptance criteria in delivery (L3), the roles of facilitator, system owner and risk owner (L4), methods and tools at a general level — STRIDE, (the Process for Attack Simulation and Threat Analysis, published by UcedaVélez and Morana in 2015), LINDDUN and diagram templates (L5) — and scaling through patterns, reusable threat libraries and champions (L6). answer the fourth question and keep it answered. covers the review checklist (V1), validation by authorised testing (V2), incidents and near misses as feedback (V3), measures of a useful model (V4), the threat model document and its audiences (V5) and the triggers for an update (V6). runs the whole method on the portal and the CFO, from the first diagram to the Week 30 review, and compresses it into a master equation and a self-assessment. Every module from 2 to 12 is built the same way: six , the sub-techniques of its rung, each with a tag (Module 3's W1–W6, Module 7's T1–T6, and so on) and each dissected through six fixed fields — it is, its (drawn on the threat model board), the as a numbered procedure, its and failure modes, to use it and when not, and it connects to the rest. Kestrel is traced through every atom with labels that never collide with the atom tags: the portal's trust boundaries , threats and controls ; the CFO's threats and controls ; and the post-launch events and . Earlier courses' work is cited by course: course 014's controls such as (MFA), (the MDR service), (supplier access) and (payment-change verification), and course 016's network changes such as (the management zone), (the supplier access broker) and (egress filtering). The CFO's model also draws on Course 015's map of a personal and household security surface. The world is fictional so that a whole system and a whole life can be shown — weaknesses included — without exposing anyone's real systems or real person, and its people are named by role only. Where the course uses real-world material — the Manifesto, Adam Shostack's (2014), STRIDE, attack trees, ATT&CK, the OWASP Top 10, CVSS (whose version 4.0 was released by FIRST in 2023), FAIR, as a general guide to risk assessment, and a handful of well-documented incidents — it stays at the level the public record supports.
This is a dissection course, not a product tour: every technique is broken down to its mechanism and its procedure, so you finish not with a shopping list but with a repeatable way to decide what to protect, from whom and what to do first — and to explain that decision to the people who must fund it, build it or live with it. Three things to hold onto as you go. First, draw before you defend: answer what are we working on? on paper before anyone names a product. Kestrel's top risk, PT5, was found by asking a STRIDE question of one element on a drawn diagram; a generic scan was poorly placed to raise it, because the missing rule — this invoice belongs to that distributor — existed only in the business, not in any product's signature list. Second, rank honestly and grade every claim: "the portal is high risk" helps nobody; "an attempt to take over distributor accounts with reused passwords within a year is very likely (80–95%), impact medium–high" — with its basis and its confidence stated, and labelled as assessment — is something a sponsor can act on, and when E1 arrived in Week 27 it was a judgement the board had already made, with PC1 already in place to meet it. Say not known when it is — whether the CFO's Week 9 caller used a synthetic voice is not known, and the response did not depend on knowing. Third, stay on the defender's side and inside consent: this course reads adversaries only as goals, classes and tactic names, at the depth a control needs (B1); you test only what you are authorised in writing to test, as Kestrel's Week 20 test was, under a scope signed by the CFO and the head of sales and on test accounts only (B2); you model a person only with their consent and only with what they choose to share, as the CFO's model was (B2, B4); and if the threat to someone comes from a person they know, the right move is their safety and the right help, not investigation. One note on scope: the course teaches method, not any jurisdiction's law; wherever a question turns on legal duties around testing, monitoring or personal data, the course's answer is to take it to counsel. Hold those three and the rest is detailed machinery. Module 2 makes the discipline explicit first, because the same method that lets a defender see a system clearly must be held to a strict standard of authorisation, restraint and honesty.
Before the first diagram is drawn, the course installs the discipline that governs the whole method. Module 2 is the threat modeler's boundary, in six commitments tagged B1–B6: defend, never attack — adversary thinking only to the depth a control needs (B1); authorisation and consent — model what you own or are asked to model, test only with written authorisation, and model a person only with their consent (B2); evidence and honesty — sourced, graded claims, fact separated from assessment and speculation, and "not known" said aloud (B3); privacy and proportion — a threat model is itself sensitive, so collect only what the decision needs and protect it (B4); security people can live with — proportionate, usable controls and no fear-selling (B5); and a living model and blameless learning (B6). The threat model board is a powerful instrument; Module 2 is what keeps it lawful, honest and safe to use.
The signature image of the course: one threat model laid out as a pinboard, here the Kestrel Distributor Portal and Kestrel's CFO at the Week 30 review (portal Week 0 is Month 7 of Kestrel's security programme). On the left, the subject: the portal's data-flow diagram — square external entities, round processes, open-ended data stores, arrows for flows — crossed by five dashed trust boundaries, TB1–TB5, with STRIDE badges pinned on the elements they threaten (PT1–PT9). In the centre, an attack tree hanging from one adversary goal, its OR/AND branches ending where a control (PC1, PC2, PC3) attaches. On the right, the risk ladder: threats ranked at Week 5 with their yardstick bands, control chips and verification ticks — verified, pending or failed — and the one accepted risk with its named owner. Below, the CFO's life model with threats CT1–CT6 and controls CC1–CC6, the four-question loop with the model's three versions, and one timeline from Week 0 to Week 30.
The transformation the course produces. The expensive guesser buys a tool after every frightening headline, copies a generic list instead of drawing the system, rates every risk "high", aims at movie villains rather than base rates, deploys controls nobody verifies, writes the model once and files it, and leaves the people at risk out of the plan. The threat modeler keeps a current picture with trust boundaries, values assets and asks valuable to whom?, grounds adversaries in motive and base rates, finds threats systematically, ranks risks with ranges, confidence and owners, puts verified controls at the choke points, updates the model on every change and incident, and models a person too — with their consent. On Kestrel's portal (the guessed version is a counterfactual): five trust boundaries, ten threats and nine controls, a pre-launch test that found the two functions lacking the PC2 check, and two real events that ended with no account taken over and no money lost.
How the course is built. Phase 1 sets the lens and the line (Modules 1–2). Phase 2 answers what are we working on? — the subject, what is at stake in it and who would act against it (Modules 3–5). Phase 3 answers what can go wrong? — STRIDE, privacy threats and attack trees (Modules 6–7). Phase 4 answers what are we going to do about it? — ranking honestly, then responding (Modules 8–9). Phase 5 applies all four questions to a person and embeds them in how an organisation works (Modules 10–11). Phase 6 answers did we do a good job? and runs the whole method end to end (Modules 12–13). Under every rung run the six commitments of Module 2, B1–B6.