Threat Modeling That Produces Testable Controls

Executive summary

A threat model is valuable when it changes a design and leaves behind evidence that the change works. A diagram plus a list of threats is an intermediate artifact, not the outcome. The durable outcome is a set of claims that a team can implement, observe, test, own, and revisit as the system changes.

This paper presents a practical chain:

define the decision and system scope;
model assets, actors, data flows, dependencies, and trust boundaries;
write abuse paths as concrete sequences;
decide which paths to prevent, constrain, detect, respond to, transfer, or accept;
express each treatment as a testable control claim;
connect the claim to implementation, telemetry, a test, an owner, and a review trigger;
verify the complete chain during delivery and operation.

The approach is methodology-neutral. STRIDE can help a team ask systematic questions, attack trees can deepen one objective, and misuse cases can connect threats to user workflows. None of those methods automatically produces assurance. The quality test is whether another person can determine what should be true, how to check it, which evidence is authoritative, and who acts when it fails.

What threat modeling is for

The OWASP Threat Modeling project organizes the practice around four durable questions: what are we working on, what can go wrong, what will we do about it, and whether we did a good enough job. That framing is useful because it prevents a method or diagramming tool from becoming the goal.

Threat modeling supports a decision. Examples include whether a new upload feature is safe to release, how an agent may call external tools, where tenant authorization must be enforced, whether a recovery design meets business requirements, or which controls are required before a supplier receives production data. The model should be bounded tightly enough to inform that decision.

A useful model does five things:

makes assumptions and boundaries reviewable;
exposes plausible attacker paths before they become incidents;
identifies design changes while they are still affordable;
converts important security expectations into delivery and operational work;
records residual risk and ownership so silence is not mistaken for acceptance.

It does not predict every attacker action. It does not prove that a system is secure. It does not replace secure design, code review, testing, monitoring, incident response, or governance. It connects those practices around explicit claims.

Begin with a decision, not a blank diagram

A generic prompt such as “threat model the platform” usually creates an unbounded inventory. Start with the decision and the change instead:

Decide whether the document-conversion feature may process untrusted tenant files in the existing worker pool before the September release.

That sentence reveals the subject, the untrusted input, the isolation question, the environment, and the deadline. It also tells reviewers which nearby systems matter. The exercise can now include the upload API, object storage, queue, conversion workers, output store, tenant-facing status API, telemetry, administrative access, and deployment pipeline while excluding unrelated product areas.

Record the following at the top of the model:

Decision: what approval, design choice, or prioritization this model informs.
In scope: components, identities, data flows, environments, deployment paths, and operating procedures included.
Out of scope: adjacent systems explicitly excluded and the reason.
Change: what is new or materially different.
Assumptions: facts treated as true for this review.
Constraints: legal, business, availability, cost, compatibility, and time boundaries.
Reviewers: people who can challenge architecture, abuse paths, operations, privacy, and business assumptions.
Freshness trigger: the date or change that requires another review.

Out-of-scope entries are not a disposal bin. If an excluded dependency can invalidate the decision, capture it as an external assumption with an owner. “Identity provider is secure” is too broad. “The identity provider validates phishing-resistant authentication for workforce administrators, and the platform consumes the signed assurance context” is reviewable.

Model the system at the level where controls live

A system model needs enough detail to reveal where authority, data, and execution change. It rarely needs every class or subnet. Include:

human and machine actors;
processes and independently deployable services;
data stores, queues, caches, and logs;
external services and organizational dependencies;
identities and credential types;
protocols and important data flows;
administrative and recovery paths;
build, release, configuration, and secret-delivery paths;
trust boundaries.

A trust boundary exists where the assumptions used on one side are not automatically valid on the other. Internet-to-edge is one boundary, but it is not the only one. Tenant A to a shared service, application to cloud control plane, workload to metadata service, CI job to deployment role, support operator to production tooling, and primary region to recovery environment are also boundaries.

Label each flow with more than a protocol name. “HTTPS” says little about who authenticates whom, what authorization is expected, what can be replayed, how data is validated, or which telemetry exists. A stronger flow label might read:

Browser sends a tenant-scoped upload request over TLS; gateway validates a signed session; API authorizes tenant and object size; object storage issues a one-use destination; audit log records tenant, actor, object ID, policy result, and request ID.

That label already contains candidate control claims.

Assets are not only databases

List what an attacker or failure could harm:

customer data and derived data;
credentials, tokens, keys, and consent grants;
authorization decisions and policy configuration;
model prompts, retrieval corpora, build inputs, and release artifacts;
service availability and recovery capacity;
financial destinations and approval records;
logs, evidence, and time synchronization;
reputation, legal obligations, and safety;
the integrity of decisions made from system output.

For each asset, state the security property that matters. “Invoice” is an object; “authorized vendor destination and approver evidence remain correct and attributable” is a security objective.

Attacker capabilities should constrain the story

Describe capabilities, not a cinematic persona. Relevant capabilities may include owning a normal tenant account, controlling a vendor mailbox, causing a victim to authorize an OAuth client, submitting arbitrary files, replaying captured requests, operating from many IP addresses, compromising a dependency, or obtaining read access to one log store. Also record meaningful limits: the attacker does not control the cloud organization, cannot break modern cryptography, or has no physical access.

Capability statements stop contradictory threats. If the exercise assumes a fully compromised cloud administrator, many application controls are irrelevant; the model should instead focus on limiting administrative blast radius, detecting misuse, and recovering trust.

Write abuse paths as sequences

A threat label such as “spoofing” or “data leak” is too compressed to design against. Write a sequence with a precondition, attacker actions, crossed boundaries, affected assets, and a consequence.

Use this form:

Given precondition, an actor can action, then action, crossing boundary, which causes security consequence to asset. Existing controls do or do not interrupt the path at point.

For the conversion service:

Given a normal tenant account, an attacker uploads a crafted document that exploits the conversion runtime, obtains code execution in a shared worker, reads another tenant's queued input through the shared filesystem, and exfiltrates it in generated output. The upload API authenticates the tenant but no current control isolates jobs within the worker.

This path is useful because reviewers can challenge each link. Does the runtime parse that format? Is the filesystem shared? Can output carry arbitrary data? Are egress destinations constrained? A false assumption can be corrected without discarding the entire model.

Write separate paths when controls or consequences differ. “Malicious file” might mean parser exploitation, decompression exhaustion, antivirus evasion, stored cross-site scripting in a preview, or content-policy violation. Combining them produces vague mitigations.

Use taxonomies as prompts, not conclusions

STRIDE asks about spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Microsoft documents STRIDE as a way to identify categories of threat against elements and interactions. It is effective for breadth, particularly when applied at each trust boundary. A category is not an abuse path and does not establish risk.

Ask category-specific questions:

Spoofing: Which identity could be falsely asserted? What evidence binds the request to it?
Tampering: Which data or control input can change between validation and use?
Repudiation: Which consequential action lacks attributable, protected evidence?
Information disclosure: Which flow, log, cache, error, or derived output crosses an authorization boundary?
Denial of service: Which bounded resource can one actor exhaust, and how does degradation spread?
Elevation of privilege: Which execution or policy boundary lets a lower-authority actor obtain a higher-authority action?

Then turn the answer into a sequence. Use attack trees when one objective has many alternative prerequisites. Use misuse cases when user workflow and social context determine the risk. Use a privacy method when identifiability, linkability, consent, or purpose limitation is central. Method choice should follow the decision.

Prioritize without fake precision

Prioritization decides where design and verification effort goes. A numeric score can help sort a backlog, but unsupported arithmetic can conceal uncertainty. Record the reasoning components:

consequence to the named asset and business outcome;
attacker capability and access required;
exposure and reachable population;
preconditions and their stability;
existing prevention and detection;
blast radius and recoverability;
evidence quality and uncertainty;
regulatory, contractual, or safety thresholds.

Use a small ordinal scale if it improves consistency. State why a path is high, medium, or low in the current scope. A high path might combine cross-tenant disclosure, normal-user reachability, shared-worker execution, and weak detection. A low path might require a separately controlled administrator plus a disabled legacy feature. Neither rating is permanent.

Keep two fields that scores often erase:

Confidence: how strongly evidence supports the path and rating.
Unknowns: facts that could change the decision and how they will be resolved.

An unknown with severe plausible consequence may justify a time-boxed spike, isolation default, or release condition rather than passive acceptance.

Choose a treatment and expose residual risk

For each prioritized path, choose one or more treatments:

Avoid: remove the feature, data, privilege, or dependency that creates the path.
Prevent: make a required attacker step fail.
Constrain: limit capability, duration, scope, or blast radius.
Detect: produce a reliable signal with enough context for action.
Respond and recover: stop harm, restore service or trust, and preserve evidence.
Transfer: allocate a defined portion through contract or insurance without pretending responsibility disappears.
Accept: record the residual risk, rationale, authority, expiration, and monitoring condition.

“Use a WAF,” “sanitize input,” and “enable logging” are not complete treatments. They name mechanisms without specifying the security outcome or failure behavior.

Convert treatment into a testable control claim

A testable control states who or what enforces a security property, under which conditions, with observable results. A compact format is:

Subject must enforce or produce property for scope under condition. On failure it must fail safely and emit evidence. Owner verifies it through test at frequency or trigger.

For the worker path:

Each document conversion job must execute in an ephemeral sandbox dedicated to one tenant and one object. The sandbox must receive no cloud control-plane credentials, must mount only the selected input read-only and a unique output location write-only, and must deny network egress by default. A setup or policy failure must prevent job execution. The platform must record tenant ID, object ID, sandbox policy version, image digest, start/result state, resource-limit outcome, and request ID. The conversion-service owner verifies isolation in CI for each policy change and in a quarterly production-like escape exercise.

This claim contains multiple assertions that may need separate tests, but they share one defensive purpose. It is stronger than “containerize conversion.”

The control record

For each claim, maintain:

Control ID and title — stable references for code, dashboards, findings, and incidents.
Abuse paths addressed — links, not copied prose.
Security outcome — what attacker step fails or what harm is bounded.
Enforcement point — the component and trust boundary where the decision occurs.
Implementation reference — policy, configuration, service, library, or operational procedure.
Failure mode — fail closed, safe degradation, quarantine, alert-and-continue, or another explicit behavior.
Evidence — logs, configuration state, signed attestations, test output, metrics, or review records.
Verification — test method, environment, expected result, and negative case.
Owner and responder — who maintains it and who acts on failure.
Cadence and triggers — continuous, release, periodic, or change-driven checks.
Exceptions — scope, authority, expiration, compensation, and removal plan.

Do not force every control into one tool. Some controls are architectural, some preventive policy, some human approval, and some detection or recovery. All can still produce evidence.

Design verification with the control

Verification should answer both “is the mechanism present?” and “does the security outcome hold?” Those are different.

For sandbox isolation:

Static policy test: reject deployment if the worker definition includes cloud credentials or broad mounts.
Unit or component test: attempt to access an unmounted path and confirm denial.
Integration test: run two tenant jobs concurrently and attempt cross-job path access.
Egress test: attempt DNS and network connections to disallowed destinations and verify denial plus evidence.
Resource test: submit decompression and CPU/memory stress fixtures and verify quotas, termination, and queue health.
Failure test: make policy creation fail and confirm the document is not processed in a weaker mode.
Telemetry test: generate each denial and confirm the event arrives with the correlation fields an investigator needs.
Recovery exercise: compromise a disposable worker and demonstrate termination, credential nonavailability, affected-object identification, and clean replacement.

The NIST Secure Software Development Framework treats secure development practices as outcomes to integrate into the software lifecycle. That principle matters here: a control test belongs in normal delivery, not only in a yearly review.

Negative tests reveal boundaries

Happy-path tests show that an authorized action succeeds. Security claims also require attempts that must fail:

wrong tenant with a valid object ID;
expired or replayed authorization;
missing identity context;
stale policy cache;
service dependency timeout;
malformed, oversized, nested, or ambiguous input;
administrative action without the required approval;
log destination unavailable;
recovery environment using an outdated policy.

Specify the expected failure. An HTTP status alone may be insufficient. Confirm that no object changed, no downstream job ran, no sensitive detail leaked, the audit event exists, and retry behavior cannot turn the failure into duplication or bypass.

Telemetry is part of the control, not a receipt

Logs are useful when they allow a person or system to decide. “Log all access” can create cost, privacy risk, and noise while omitting the fields needed to distinguish abuse.

For each control, define:

event producer and schema version;
actor and workload identity;
tenant, resource, action, policy, and result;
correlation identifiers across boundaries;
timestamp source and expected skew;
reason codes that are safe to expose;
integrity, transport, retention, and access rules;
volume expectations and drop detection;
alert or investigation consumer;
response owner and service objective.

A detection control needs a tested decision rule. For example:

Alert when one tenant produces more than five sandbox policy denials across distinct documents in ten minutes, or any attempt targets a cloud metadata address. Include tenant, actor, object IDs, worker image digest, policy version, destination, and request chain. Page the security on-call for metadata attempts; queue other clusters for review within one business day.

Then test the rule with synthetic events, including below-threshold behavior and telemetry interruption. A dashboard nobody owns is not a detection control.

The NIST Cybersecurity Framework 2.0 helps connect these outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. The categories are useful for checking that a model has not reduced security to prevention alone.

Ownership and workflow

Threat modeling succeeds when the people who can change the system participate. A productive review usually needs:

a product or business owner who can explain value and harm;
engineers who know real data and execution paths;
a security facilitator who can probe attacker behavior and control quality;
an operator or responder who knows telemetry and failure behavior;
privacy, legal, fraud, safety, or supplier specialists when the scope demands them.

The security facilitator should not become owner of every resulting control. Ownership belongs where the implementation and operational authority live. Security may own a reusable platform control or an independent verification, but a service team normally owns its authorization, failure behavior, and telemetry.

Create delivery work directly from the model. A control ticket should carry the control ID, abuse path, acceptance criteria, negative test, evidence fields, owner, and release condition. Preserve links between model, architecture decision, code or policy, test, and operational evidence. That traceability makes future review much faster.

Definition of done

A threat-model action is done when:

the agreed design or implementation exists;
its configuration is reviewable;
positive, negative, and failure-path tests pass in the appropriate environment;
evidence reaches its intended destination;
an owner can demonstrate how to investigate or respond;
documentation and recovery paths reflect the change;
residual risk and exceptions have explicit authority and expiry.

Closing a ticket because a product was purchased or a setting was enabled is not enough.

Keep the model alive without making it ceremonial

Review on meaningful triggers:

a new external or cross-tenant data flow;
a new identity, privilege, tool, model, or integration;
a change to authentication, authorization, encryption, or key ownership;
a new parser, upload type, execution capability, or agent action;
a supplier, build, deployment, or recovery-path change;
a major incident, near miss, or repeated control failure;
a material legal, threat, or business change;
expiration of an assumption or accepted risk.

Use version control for the model and control records. Review diffs rather than recreating a workshop. At release time, ask which data flows, boundaries, assumptions, abuse paths, and controls changed. If none changed, record that determination. If they did, update the affected slice.

Track a few workflow measures that indicate health rather than vanity:

time from design change to model review;
percentage of high paths with an owned treatment and verification;
age of unresolved unknowns and exceptions;
control-test pass rate and time to repair;
percentage of detection controls with exercised response;
incidents or findings that invalidate model assumptions;
repeated abuse-path patterns that justify a reusable platform control.

Counting threats found can reward inflated lists. Measure whether important paths are treated and verified.

A worked example: tenant document conversion

Consider a SaaS application adding document conversion. Customers upload office documents, an API places work on a queue, workers convert files, and users download output.

Scope and objectives

The decision is whether the shared worker design is safe for untrusted tenant files. Assets include tenant input and output, worker execution integrity, cloud credentials, service availability, audit evidence, and customer trust. The attacker has a normal tenant account and can submit arbitrary supported files but does not control the cloud organization.

Trust boundaries include browser to API, API to object storage, queue to worker, worker to parser, tenant job to shared host, worker to network, and deployment pipeline to worker image.

Selected abuse paths

A crafted file exploits a parser and reads another tenant's data from shared storage.
A compression bomb exhausts worker resources and delays all tenants.
A compromised converter reaches the cloud metadata service and obtains workload credentials.
Generated output contains active content that executes in the application origin when previewed.
A vulnerable converter image is deployed without attributable build inputs.

Treatments and control claims

The team chooses per-job isolation, read-only unique input, write-only unique output, no default credentials, deny-by-default egress, resource limits, output content handling, immutable image digests, and build provenance verification.

For resource exhaustion:

The admission service must reject files outside supported compressed and expanded size limits before queueing. The worker must enforce per-job CPU, memory, wall-clock, output-size, and recursion limits. Limit termination must not retry without a bounded policy. Events must distinguish admission rejection from runtime termination and include tenant, object, limit, observed value, policy version, and request ID.

Tests cover deceptive headers, nested archives, concurrent near-limit jobs, retry behavior, queue recovery, and telemetry delivery. The service owner maintains the limits; platform engineering owns runtime enforcement; security engineering owns the quarterly adversarial fixture review; operations owns the saturation alert.

For artifact integrity:

Production may run only a converter image by immutable digest when its signed build provenance identifies the approved source revision and builder workflow, the image passes policy checks, and the deployment identity is authorized for that environment. Verification failure must block deployment and emit a policy decision with digest, provenance identity, source revision, builder, and rule version.

This does not prove the source is safe. It makes the artifact's origin and build path verifiable and allows policy to reject an unexpected path.

Residual risk

Isolation can have implementation flaws, parsers can cause kernel-level vulnerabilities, and approved source can contain malicious or mistaken code. The model records residual risk, defense layers, patch ownership, worker replacement design, blast-radius assumptions, and the triggers that require re-review.

Common failure modes

Starting too late

A pre-release meeting discovers that tenant isolation requires a redesign, so the team relabels the risk as “accepted.” Model at the first reviewable architecture and update as implementation becomes concrete.

Treating the data-flow diagram as completion

The diagram documents what exists. It does not state what can go wrong, what changes, or how controls will be verified.

Listing taxonomies without paths

“Spoofing: high” cannot be tested. Name the identity, attacker capability, flow, consequence, and control gap.

Copying generic mitigations

“Validate input” omits format, canonicalization, location, limits, failure behavior, and evidence. Write the property required at the enforcement point.

Ignoring operators and recovery

A prevention-heavy model may fail during its first incident because alerts have no owner, logs lack correlation, credentials cannot be revoked, or recovery bypasses the control.

Confusing compliance evidence with effectiveness

A screenshot can show configuration at one time. It may not demonstrate negative behavior, failure handling, runtime drift, or response readiness.

Accepting risk by backlog neglect

Unscheduled work is not risk acceptance. Acceptance needs scope, rationale, accountable authority, compensation, monitoring, and expiry.

Modeling every system identically

A public content site, payment workflow, industrial controller, cloud control plane, and AI agent have different assets, consequences, attacker capabilities, and verification options. Reuse structure, not conclusions.

A compact review template

Use this checklist for a focused review:

Context

Decision and deadline
In scope / out of scope
Change and business outcome
Assumptions, constraints, and unknowns
Reviewers and freshness trigger

System

Actors and identities
Assets and security properties
Components, stores, dependencies, and flows
Trust boundaries
Administrative, build, deployment, and recovery paths

Abuse paths

Attacker capability and precondition
Ordered actions and crossed boundaries
Consequence and blast radius
Existing interrupting controls
Priority, confidence, and unknowns

Control records

Security outcome and enforcement point
Implementation and safe failure mode
Evidence and telemetry consumer
Positive, negative, failure, and recovery tests
Owner, responder, cadence, and triggers
Residual risk, exception authority, and expiry

Closure

Architecture decisions updated
Delivery work linked
Tests running at the right cadence
Telemetry exercised
Response and recovery demonstrated
Model change stored and future trigger assigned

Final principle

The most useful threat model is not the one with the largest diagram or threat count. It is the one that makes an important security claim explicit and keeps the evidence for that claim connected to the system as it changes.

Ask one final question for every high-priority abuse path:

If this control silently stopped working tomorrow, how would we know, who would act, and what test would prove the repair?

If the team cannot answer, the threat model has found its next task.