Writing

A threat-model worksheet for a design review

By Brandon Eckert

A useful threat model should help a team make a decision. Which boundary could fail? What would happen? Who will address it, and what evidence will show that the response works?

This worksheet gives those questions a place to live. The completed example follows a fictional invoicing service with two customer organizations. It is educational material, not an assessment of a real application or a description of an employer’s practices.

Get the worksheet

The UTF-8 text files work in a text editor or can be copied into a review ticket. Keep completed assessments and their evidence in your team’s appropriate private workspace.

Start with the system and its rules

Write down the feature, its business purpose, the people reviewing it, and what the review excludes. Then identify the assets, actors, entry points, dependencies, and boundaries. OWASP’s threat-modeling guidance provides a useful foundation for modeling a system, identifying threats, choosing responses, and validating those responses.

For this example, Tenant Alpha and Tenant Beta each have administrators and members. Members can list and read all invoices in their own tenant. Administrators can also create, update, delete, and export those invoices. Creating an invoice does not give its creator a special ownership privilege. Being an Alpha administrator grants no access to Beta.

The example also requires membership revocation to take effect on the next request, even if a caller still has a previously issued credential. That is an explicit policy decision for this exercise; a real review must establish its own revocation requirement and verify the implementation against it.

Draw enough to expose the boundaries

Untrusted client
    | identity + requested tenant + operation
    v
API: verify identity, membership, permission
    |                         |
    v                         v
Tenant-scoped data       Tenant-bound export job
                              |
                              v
                        Worker -> file store
                              |
                              v
                    Authorized export retrieval

The client/API boundary is only the beginning. An export crosses into a worker and then storage. The retrieval path must still connect the caller, current permission, tenant, and file. Add caches, integrations, and alternate paths when they are in scope.

Mark assumptions explicitly. “The membership source is current” is an assumption until the team has evidence about caching and invalidation. A proposed tenant filter is a planned control, not an established result.

Write threats as concrete scenarios

The completed worksheet includes five linked scenarios:

  • TM-001 — Cross-tenant invoice access. A Beta caller supplies an Alpha invoice ID, or a list/search reveals Alpha data. Review reads, writes, counts, and aggregates.
  • TM-002 — Unverified tenant selection. An Alpha administrator changes the tenant selector to Beta. The selected tenant must be checked against verified membership.
  • TM-003 — Export access and propagation. Creation, background processing, storage, and retrieval can each lose the tenant boundary. Review the whole path.
  • TM-004 — Stale membership. A removed member reuses an earlier credential. Check the policy’s next-request requirement, including caches.
  • TM-005 — Role enforcement. A member attempts an administrative operation on an invoice they are allowed to read. Tenant membership alone is insufficient.

STRIDE can provide additional prompts: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It does not prove that the model is complete. Ask about the business workflow and the paths the diagram leaves out, too.

Turn the discussion into owned work

For each scenario, record the affected asset or boundary, prerequisites, impact, existing controls and evidence, chosen response, action owner, target date, and verification method. Keep residual risk, acceptance authority, and unanswered questions visible.

For TM-001, “add authorization” is too vague. A more useful action is to apply verified tenant scope at every invoice access path, then check both allowed access and foreign-tenant denial. The API authorization test matrix supplies cases with the same threat IDs.

An export model should also leave a question about already downloaded files: revoking membership cannot recall a copy a user already possesses. That may require a separate retention or handling decision.

Review the evidence and revisit the model

The completed example leaves controls open and unverified. No security tests have been executed. Replace assumptions with evidence as work progresses, and record the result without losing the original decision.

Revisit the model when roles, queries, integrations, worker behavior, storage, or session rules change. If testing produces a finding, use the vulnerability triage checklist to record its applicability, impact, priority, and closure criteria.

← All writing