Fundamentals and Scoping

What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? They run in that order and repeat as a loop, not a one-off checklist.

An actor assumption is a written statement of the adversary you defend against: their capability, resources and access. It bounds the model, because a threat stays in scope only if that assumed actor could reach and carry it out.

The assets are the ability to complete a purchase during the on-sale window, fair allocation of the inventory, the revenue, and fan trust. Seat-map confidentiality carries almost no loss — here availability and functionality are the assets, not stored data.

A usable assumption states the claim in a form that could be proved false, names the team that owns it, says which threats come back if it is wrong, and gives an event or date that forces a recheck.

Most threats follow from the functionality existing, so they can be priced but not removed. A control succeeds when an attempt costs the attacker more than a success is worth, so a rational attacker stops or goes elsewhere.

Findings that each name a person who owns them, security requirements written into the work being built, abuse test cases for the threats worth exercising, and a diagram corrected to match how the system actually works.

The system boundary is the explicit line naming which components, dependencies and people a threat model reasons about. Draw it around what your team can act on, and record everything else on a written out-of-scope list.

That sentence names a missing control, not something that could go wrong. A threat statement has to name an actor, the entry point they reach, the action they take, the asset affected, and the concrete impact.

The Hero Threat Modeler anti-pattern. The Manifesto holds that threat modeling needs no innate gift, so the fix is moving the specialist from authoring models to reviewing what teams author, not hiring a second hero.

The Threat Modeling Manifesto values finding and fixing design issues over checkbox compliance, people over process and tools, understanding as a journey over a snapshot, doing over talking, and continuous refinement over one delivery. Right-hand items are lesser goods, not worthless.

The design is unchanged, so only threats whose reachability rested on supervision change status. Tampering and repudiation now dominate because the asset is the truth of the count, and every control whose strength came from supervision is unsupported.

The crown jewels are the molecule-screening model weights and the accumulated wet-lab result set: losing either hands a competitor the company's entire scientific lead. The sales CRM holds more records but the company survives losing it. Rank by which loss is unrecoverable.

Write each goal so a single concrete scenario could prove it false: 'a filing cannot be attributed to a bar member who did not submit it.' Name the asset, the property and the condition. 'Filings shall be secure' is untestable.

Treat it as an assumption rather than a mitigation: name the owning team, confirm exactly which fields and which paths are covered, and keep the threat open with residual risk until that confirmation lands.

Cost-versus-gain reasoning only describes an attacker spending their own budget for profit. It fails when the payoff is personal, when a third party funds the attack to impose loss on you, and when per-target cost is near zero.

Check three things about the modeling work: that the model matched the system actually built, that enumeration reached every part of that model, and that each decision from question three has evidence it exists in the running system.

Admiration for the Problem, analysis that never reaches a practical solution, plus Tendency to Overfocus, where one threat eats the attention the rest of the model needed. Force every threat to a decision, and sweep the whole system before deepening any part.

No. A pentest tests one build, from the positions a tester could reach, in a limited window, so failing to exploit something is not evidence the design constrains an attacker.

Model the change, not the monolith. Scope covers the new behaviour, the data the change newly exposes, and every existing control the change leans on or alters. Pre-existing weaknesses in untouched code go to a backlog, not into this session.

Split wherever two clauses could get different answers — a different owner, a different mitigation, or a different accept-versus-fix decision. Each resulting sentence keeps its own actor, entry point, action, asset and impact.

An attacker develops a technique once and replays it across every site, so their cost scales with techniques and the defender's with sites times techniques. Winning means buying that shape: shrink the estate, share the controls.

Push back on both. A threat model asserts intent about one design at a point in time; an audit needs evidence a control operated over a period, and a register is a maintained, organisation-wide list.

Perfect Representation. The Manifesto's answer is that no single ideal view of a system exists, so several partial representations that each illuminate different problems beat one supposedly complete model — and the analysis should have started weeks ago.

Defend it as a bound, not a shrug: justify it from the assets rather than from team size, state which threats it leaves untreated, get agreement from whoever owns the consequence, and record the triggers that would force a revisit.

Make the assumptions list, not the diagram, the thing under review: give each assumption an owner, an event trigger or expiry, and a hook in design review so change authors are asked whether their change invalidates one.

Treat the old answers as claims, not as current state. Re-answer question one against the system as it runs today, keep the recorded decisions and the reasons behind them, and verify which of those mitigations actually exist.

Bound by the decision the model must support, not by inventory completeness. Slice by asset, time-box each slice, and ship the explicit list of what you did not examine as a first-class deliverable alongside what you found.

Require a bounded actor described by the access they already hold and an impact stated as an operational loss. A statement nobody can dispute, test or close is not a finding — it is a mood.