Threat Modeling as Structured Imagination

By the end of this lesson, you will be able to...

• Turn a system promise and a bounded adversary profile into a concrete misuse or abuse case.

• Record the preconditions, challenged assumption, evidence, and next decision that make a case useful to a team.

• Compare candidate cases and reject one that is only a label, a duplicate, or an unsupported attacker story.

Idea in one sentence: Structured imagination changes a threat model by asking how a real person could use a real feature in an unwanted way, then writing down what would have to be true.

Core Insight

Northstar, the fictional document-sharing service from the previous lesson, has a clear product promise:

Only the intended readers should view the confidential roadmap.

The team already has a system model. A document owner creates a link. Northstar lets any person with a company account open that link. A support ticket can contain the link when someone reports a display problem. The team also has a bounded adversary profile: Ari is a contractor with an ordinary company account and legitimate access to the support ticket, but no administrator role or database access.

It is tempting to write information disclosure beside the diagram and call the work done. That label is not wrong. It names a concern. But it does not say which feature is used, what Ari can actually see, which condition makes the outcome possible, or what the team should inspect next.

Structured imagination supplies the missing middle. It does not mean inventing clever attacks. It means changing one part of a normal use story—the actor's intent, the context, the sequence, or the incentive—and following the system's stated behavior. The result is an abuse case: a concise, inspectable story about an unexpected use of a feature and its consequence.

The goal is not to prove that Northstar is vulnerable or to test a real service. It is to make the assumptions inside a design visible enough that the team can validate, prioritize, or revise them.

The Promise We Need to Keep

A threat model from the prerequisite track answers, “What are we building?” It identifies assets, data flows, trust boundaries, and ordinary actors. That model is still necessary. Now we ask a sharper question:

If a legitimate feature is used by a person whose goal conflicts with the promise, which assumption has to carry more security weight than the team noticed?

For Northstar, the important feature is not “a document system” in general. It is the company-link sharing rule. The relevant boundary is also specific: the design team treats a person with a company account as close enough to an intended reader.

The model works only while company accounts and intended readers coincide; a support ticket visible to a broader group breaks that condition.

This is an observed fact in the fictional scenario, not a claim about every sharing product. The lesson holds the system facts fixed so that the reasoning is inspectable. In a real review, the team would confirm the effective authorization rule, ticket audience, and logging behavior before treating the case as a finding.

The Naive Design: A List of Threat Names

Frameworks such as STRIDE can prompt useful questions. MITRE ATT&CK can also give a shared vocabulary for adversary behavior. Neither is a replacement for the local system story.

Compare these two notes:

Each part earns a different question:

• Ari and the ticket ask whether the starting access exists.
• The company link asks what normal feature is being used.
• The authorization rule names the precondition.
• The unexpected read states the consequence against the product promise.
• “If” keeps an unverified rule from becoming a certainty.

An abuse case is therefore not a vulnerability report, an exploit recipe, or a control. It is a design hypothesis that connects a feature to a plausible unwanted outcome. OWASP describes abuse cases as ways a feature can be used unexpectedly to let an attacker influence its use or outcome.

Why the Label Breaks Under Pressure

Suppose the product lead replies, “The ticket is internal, so the link is safe.” That response may be reasonable under one model: internal access is treated as equivalent to intended access.

The fictional evidence challenges that equivalence:

System promise:          only intended readers view the roadmap
Normal workflow:         a support ticket contains the company link
Observed audience:       the ticket is readable by product support
Authorization rule:      any company account with the link may view
Missing distinction:     company member is not the same as intended reader

The old response focuses on where the ticket lives. The stronger model follows the authorization decision that occurs after the ticket is read. If Ari opens the link with an ordinary company account, Northstar evaluates company membership, not the owner's intended-recipient list. The system could return the roadmap without any broken authentication or exotic capability.

The useful correction is not “internal users are attackers.” It is narrower:

A workflow can extend the audience of a capability. The access rule must be compared with the promise, not with the workflow's friendly intent.

That correction also protects the team from a common failure: treating a diagram as proof. A data-flow diagram can show that a link crosses into a ticket. It cannot by itself establish who can read the ticket today, what policy Northstar applies, or whether a particular person would misuse the access. Those are evidence questions.

A Better Boundary: The Challenge Sheet

Use a small threat-model challenge sheet for each candidate abuse case. It deliberately begins with the existing feature and promise rather than with a technique catalogue.

Plain meaning: the sheet turns “what could go wrong?” into a question another person can check.

In Northstar: it asks whether a broader ticket audience plus company-wide link authorization can defeat an owner-specific promise.

Technical name: this is an abuse-case record. It is one useful representation of a threat-model concern, not the only representation a team needs.

The last field matters. A case without an owner or next decision is an alarming story that nobody can act on. A short record helps a team turn analysis into a conversation and a decision.

Worked Challenge Sheet: Three Candidate Cases

Here are three candidate cases for the same Northstar feature. The system facts are illustrative and deliberately limited. No testing or real target is involved.

Candidate A is the strongest place to begin. It has an actor, a normal workflow, a stated authorization rule, and a direct conflict with the promise. It still contains an uncertainty: Ari's intent is not a fact. That uncertainty does not erase the case; it tells the team not to write “Ari accessed the roadmap” as if it had happened.

Candidate B is also useful, but it challenges a different design choice: whether a bearer-style company link represents a controllable audience. It may deserve a separate product decision rather than being merged into A.

Candidate C demonstrates a valuable outcome: discarding a case. “An outsider gets in somehow” looks severe only because it hides every required condition. It neither changes the modeled actor nor provides evidence that the existing company-account control is bypassed. Keeping it beside A would inflate the list without improving a decision.

So far, the point is not to create three scary stories. It is to turn one feature into several testable questions, preserve their differences, and stop when a story has no supported starting state.

The Trade-off: Coverage Versus Decision Quality

Structured imagination improves coverage. It can reveal that a feature is safe under its normal story but unsafe when a link, approval, recovery step, or incentive moves into another workflow.

It costs time and coordination. Each credible case needs someone to supply system facts and someone who can act on the answer. A team that produces fifty one-line threats may look thorough while creating no clear validation work. A team that writes only one polished case can miss an important alternate use.

This is the trade-off: use enough cases to challenge meaningful assumptions, but make each case precise enough to affect a decision. The method does not establish likelihood, prove impact, choose a mitigation, or replace an authorized test. Those are later risk and design decisions.

You can see the boundary when records begin to reuse the same actor, condition, and consequence with different labels, or when nobody can say what evidence would change their mind. At that point, pause the brainstorming and refine the system facts or merge duplicates.

Design Review: From Case to a Bounded Question

Before passing a case to the next lesson, run this quick review.

1. Name the promise. “Only intended readers view the roadmap” is testable. “Keep data secure” is too broad.
2. Keep the starting position honest. State what the actor already has; do not smuggle a stolen credential, hidden privilege, or unlimited knowledge into the story.
3. Change one normal condition. In A, the link appears in a broader ticket audience. In B, it is forwarded. The change should be visible.
4. Write the precondition as a question when unverified. “Does Northstar authorize any company account with the link?” is better than asserting a flaw.
5. State the decision owner. A security reviewer can describe the concern, but a product or identity owner may need to choose the boundary.

This review makes the next lesson possible. Once the team has several bounded cases, it can ask whether their conditions compose into a path—or whether they are unrelated possibilities that should remain separate.

Check Your Understanding

Check: A note says, “Elevation of privilege might happen because an employee could be malicious.” Is it an abuse case ready for review?

Think first, then reveal.

Answer: No. It is a category plus a vague actor. It needs a feature, a starting access level, a changed use or sequence, a precondition, an outcome that violates a promise, and evidence or uncertainty. The employee's intent alone does not show what the system would permit.

Check: In candidate A, which statement should be verified before the team calls it an actual finding?

Think first, then reveal.

Answer: The effective authorization rule and ticket audience. The scenario treats them as given teaching facts, but a real review must establish them. Ari's intent may remain an assumption; it is enough to justify a bounded misuse case, not a claim that misuse occurred.

Practice: Challenge a Nearby Workflow

A fictional expense tool lets an approver view a reimbursement attachment through a company link. An employee pastes that link into a broad finance-help ticket. The product promise is: only the employee and assigned approver may view the attachment.

Write one abuse-case record using the challenge-sheet fields. Do not propose a technical fix. End with the one question that the product, support, or identity owner should answer.

A good answer should mention:

• the normal feature and the precise promise;
• a bounded actor with legitimate starting access to the finance-help ticket, not unlimited access;
• the changed workflow context: the link appears before a broader audience;
• an explicit precondition about the link's authorization rule;
• the unwanted view of the attachment, plus what is fact, assumed, or still unknown;
• a named owner and a validation or design decision rather than a generic warning.

Resources

• [ARTICLE] OWASP Threat Modeling Cheat Sheet — Focus: follow the structured path from a system model to threats, responses, and review.
• [ARTICLE] OWASP Abuse Case Cheat Sheet — Focus: see abuse cases as records of unexpected feature use that can inform concrete security work.
• [ARTICLE] Threat Modeling Manifesto — Focus: compare a useful, collaborative modeling practice with checkbox work and “hero” analysis.
• [FRAMEWORK] MITRE ATT&CK: Get Started — Focus: use tactics and techniques as vocabulary only after the local actor, goal, and system context are clear.

Key Takeaways

• A threat name is a prompt; an abuse case is a bounded story that connects a feature, actor, precondition, and consequence.
• Start from the system promise and a real workflow, then change intent, context, sequence, or incentive without granting the actor unexplained powers.
• Keep facts, assumptions, and open questions separate so a plausible case does not become an unsupported finding.
• Coverage is useful only when each case informs a validation or design decision; discard or merge stories that cannot do that.
• The next step is to trace whether separate, evidence-backed conditions compose into a meaningful path.