Threat Modeling

Integrity means data has not been altered outside authorised change. Authenticity means the claimed origin of a message or request is genuine. Non-repudiation means the originator cannot later credibly deny it, with evidence that convinces a third party.

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.

A level-0 context diagram draws the whole system as one process, every external entity that talks to it, and the flows between them. It fixes scope and shows what crosses the outer trust boundary, with no internal structure.

A process is running code that transforms data, a data store is passive data at rest, an external entity is a person or system you do not control, and a flow is data in motion between them.

An entry point is anywhere data or a request crosses into the system from outside its trust boundary. Not just HTTP endpoints: queue consumers, file drops, inbound email, webhooks, scheduled jobs that fetch remote data, and admin or support consoles all count.

A trust boundary marks a data flow where the two sides do not trust each other equally. Draw it wherever the principal, privilege, tenant, code owner or execution context changes - not wherever the network or a firewall changes.

A data-flow diagram shows what data moves where, not when or in what order. It omits control flow, sequencing, retries and error paths, so replay, race, double-processing and failure-path leak threats stay invisible on it.

Denial of Service violates availability - legitimate users stop being served. On a process it exhausts CPU, memory or threads; on a store it fills or locks storage; on a flow it saturates or cuts the channel.

Elevation of Privilege is STRIDE's category for an actor gaining rights it was never granted - doing something it is not permitted to do. It violates authorization, and the answering controls are authorization decisions plus least privilege.

Both hand an unauthenticated stranger internal detail for free: stack traces expose paths, versions and sometimes a connection string; a debug route dumps environment variables including keys. Return generic errors, keep the route out of production builds, and rotate anything exposed.

Repudiation is an actor plausibly denying an action they took, or falsely claiming one they did not, because the system kept no trustworthy evidence. It violates non-repudiation, and the answering control family is identity plus auditing.

Tampering violates integrity: someone modifies data or code they are not authorized to change. On a data-flow diagram it applies to processes, data flows and data stores, but not to external entities, which get spoofed instead.

In an attack tree, an AND node costs the sum of its children, because the attacker must complete all of them. An OR node costs the minimum, because the attacker picks one. The root holds the cheapest complete attack.

Annotate each leaf with independent attributes: money, skill level, elapsed time, required access, equipment and detectability. Collapsing them into one number hides that a step can be cheap in cash yet demand rare skill or insider access nobody can buy.

Keep the three story clauses and make each hostile: the role becomes a named attacker persona, the capability becomes what they want the system to allow, and the benefit becomes their payoff. The asset stays in the final clause.

A concrete-action leaf names one specific thing an attacker does on this system, specific enough to cost and to defend. A category leaf such as 'obtain a credential' only restates the sub-goal above it, hides the real work, and maps to no control.

Restate the attacker's goal as a must-not statement with an observable outcome, then write a test that runs from the adversary's position and asserts the refusal, the unchanged state, and the recorded evidence.

LINDDUN covers Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance. Each names the failure of a privacy property: unlinkability, anonymity, plausible deniability, undetectability, confidentiality, user awareness, and policy compliance.

A security model protects the system from unauthorised parties. A privacy model protects the person the data describes, including from the operator's own authorised staff and vendors. So the fix is collecting and keeping less, not stronger access control.

Fix the scope to the change itself, sketch its flows and trust boundaries, walk one fixed question set over every boundary crossing, and leave with ranked threats that each have an owner. You buy the obvious high-impact threats and spend completeness.

Fit decides it, not fashion: team maturity, the system's type and risk profile, any regulatory or contractual driver, the time budget per model, and who consumes the output. A lighter method run every release beats a heavier one nobody finishes.

Points arbitrage is a chain of legitimate operations permitted by that system's own rules, and no catalog holds rules it never saw. A library sets a floor of known patterns; novel abuse comes from an asset-driven pass.

DREAD rates a threat on five dimensions - Damage, Reproducibility, Exploitability, Affected users and Discoverability - each given a small ordinal rating in the room, then collapses them into one number, classically their arithmetic mean.

A CVSS score describes technical severity, not what the business loses. Lead each threat with a scenario: who does what, to whose money or data, and what it costs. Use the score only to rank items against each other.

A bug bar is a written table, agreed before any finding exists, that defines each severity band by the concrete kinds of flaw that belong in it, the deadline to fix each band, and which bands block shipping.

A CVSS v3.1 base vector: network-reachable with low complexity, needing no privileges and no user interaction, escaping its own security scope to fully compromise confidentiality and integrity in the component it reaches, with no availability impact.

Rate likelihood from what the abuse requires, not from how clever it is: who already holds the access, how much effort and skill it takes, and whether anyone would notice. Every picker already has the scanner, so likelihood is high.

A threat modeling session needs whoever knows the design and whoever knows reality: the architect or tech lead, the developers building it, an ops or SRE voice, and a product owner who knows which flows carry value.

Generated output is a floor, not a finished model. A tool reliably applies the same per-element rules everywhere and catches structural gaps, such as a data store drawn with no trust boundary. It cannot judge business impact or whether the diagram is true.

Because the model becomes a version-controlled source file that diffs in a pull request. pytm's Python and threagile's YAML sit beside the code and regenerate the data-flow diagram and threat report on every run, so the picture never goes stale.

Reconcile the model against independent evidence of the running system - deployment descriptors, service and datastore inventories, routing and access config, traffic telemetry - and record every element, flow or trust boundary that reality has and the model does not.

Trigger on architectural change, not code volume: a new component or service, a new trust boundary such as a new caller or tenant, a new class of data, and any incident that disproves a design assumption.

The browser runs on the user's machine, so every field, header and request sequence it sends is attacker-authorable. Draw it outside your trust boundary: it is an input source, never a place where a rule is enforced.

In a multi-tenant API the deciding boundary is not the network edge but every endpoint, where an authenticated caller's tenant claim meets shared tenant-owned data. Information disclosure and elevation of privilege dominate the result.

Anything shipped inside an app package is readable by whoever holds a copy, so treat that key as public. Two assets are exposed: a fleet-wide credential an attacker can replay against your API, and the customer data cached on a device you do not own.

At your side of the tunnel. Everything arriving through it is untrusted input from a system you do not run, so the vendor stays outside your boundary even though the connection is private and encrypted.

Use the same four DFD elements: functions and managed-service calls are processes; buckets, tables and queues are data stores; event sources are external entities. Draw trust boundaries where the calling identity changes, not where a machine or network ends.