Review: Challenge the Threat Model

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

• Review a small threat model for gaps in scope, assumptions, paths, and discovery coverage.

• Separate a concrete threat, a duplicate, a rejected candidate, and an open question.

• Give focused review feedback before controls and priorities narrow the discussion.

Idea in one sentence: A good threat-model review does not ask whether the document has many entries; it asks whether its claims connect a real system boundary, a plausible actor, evidence, and a security objective.

Core Insight

ShareBox lets an employee send a proposal to a partner through a time-limited sharing link. The team has a diagram, an actor profile, an abuse path, and a STRIDE pass. It is tempting to call the threat model complete because it has several pages and six category headings.

The review asks whether those pages make one defensible argument. Do the stated flows match the system? Does an actor have the access the path requires? Does an entry describe a new path or repeat an old one?

This is a review lesson, so it will not add a new framework. Instead, it combines the tools already learned:

scope and objective
-> flows and trust boundaries
-> actors and assumptions
-> abuse paths
-> STRIDE prompts
-> a challenged, evidence-aware discovery record

The output is a clearer answer to “what can go wrong?” before lesson 009 turns retained threats into requirements.

The Review Packet

Here is the deliberately incomplete packet a cross-functional group receives. The facts in the table are a teaching model, not a report about a real service.

Do not jump from this packet to “add authentication and logging.” Check the claimed path and its evidence first.

The Concepts Together

The review starts by giving each artifact a distinct job.

| Artifact | The question it must answer | A weak version | A usable version | | --- | --- | --- | | Scope | What promise and boundary are we examining? | “Secure file sharing.” | “Only the intended partner reads this proposal through this download flow.” | | Flow | What moves, and where does trust change? | “The link downloads a file.” | Browser → public endpoint → link record → proposal response. | | Actor profile | Who can start the path, with which limits? | “A hacker.” | An unintended link holder with browser access but no ShareBox account. | | Assumption | Which condition makes or limits a claim? | “Links work.” | Possession of a valid token is sufficient for acceptance. | | Abuse path | How does the objective fail? | “Documents are stolen.” | Forwarded token → accepted request → response delivers proposal to the wrong person. | | STRIDE entry | What question did we use to search? | “Information disclosure.” | Could this endpoint return the proposal to someone other than the intended partner? |

Each row supports the next. A generic actor cannot justify a path. A category label cannot replace a flow. An assumption without a way to verify it is a note to investigate, not a conclusion.

Challenge the Packet From Four Viewpoints

A review improves when different participants ask different questions. The trade-off is coverage versus review time: more prompts can expose gaps, but unsupported entries delay attention to evidence-backed paths.

The viewpoints are prompts, not a meeting ritual. One person can ask all of them in a small team. The benefit is that a single familiar perspective—such as only looking for code bugs—does not silently decide what counts as a threat.

A Worked Review: Which Notes Survive?

The group makes four comments. Trace each one from observation to decision.

The second row is an abuse path. The third and fourth rows are not weaker because they remain open; they are more honest. The first row is also valuable: a documented rejection prevents the same unsupported concern from reappearing as a separate high-priority item next week.

So far, the group has not tried to solve every issue. It has improved the model’s quality by connecting each result to its evidence and by preserving uncertainty where evidence is missing.

Common Confusions

“A review means finding more threats.”

Why it is tempting: a longer list feels like stronger security work.

Better model: the review may add a path, merge duplicates, reject a path that the flow cannot support, or turn a missing fact into an investigation. All four improve the model.

“An assumption is a flaw.”

Why it is tempting: security discussions often treat uncertainty as failure.

Better model: an assumption is a visible condition that lets the team reason. It becomes dangerous when it is hidden, unsupported, or never revisited.

“A STRIDE category is enough evidence.”

Why it is tempting: category names sound technical and complete.

Better model: the category is a discovery prompt. Keep a candidate only when the modeled boundary, actor, path, and objective support it.

“Logging would close every concern.”

Why it is tempting: an audit record feels like control.

Better model: an audit record may create evidence for a repudiation investigation. It does not stop the endpoint from delivering a proposal to an unintended holder.

Retrieval Check

Check: The download endpoint begins accepting a documentId supplied by the browser in addition to shareToken. Which earlier review decision must change?

Think first, then reveal.

Answer: Reopen the rejected tampering or authorization candidate. The old rejection relied on the client not choosing a document. The new input changes the flow and could create a path to a proposal outside the token’s intended scope.

Check: A reviewer says, “We cannot see a rate limit in the packet, so denial of service is high risk.” What is missing from that conclusion?

Think first, then reveal.

Answer: The request cost, configured limits, traffic exposure, dependency behavior, and resulting user impact are still unknown. Record the evidence request; do not replace uncertainty with a severity label.

Transfer Challenge: Review a New Packet

An appointment portal sends a customer a link to view an appointment summary. The packet says the browser presents the link to a public endpoint, the endpoint retrieves the summary, and the link expires after seven days. It does not say whether the link is bound to a signed-in customer, whether an unintended person can obtain the email, or whether access attempts are logged.

Write four review notes: one scope or objective question, one actor or assumption question, one candidate abuse path, and one open investigation. Then state whether any two notes describe the same path.

A good answer should mention:

• a concrete objective such as confidentiality of the appointment summary;
• the link holder’s actual starting access rather than general access to the portal database;
• the condition under which the endpoint accepts the link;
• a clear distinction between a plausible unauthorized-read path and unknown audit evidence; and
• the possibility that an identity question and a disclosure path refer to one outcome rather than two independent risks.

What Comes Next

The reviewed ShareBox model has one retained confidentiality path and several questions that need evidence. That is enough to begin the next question: which behavior must the system guarantee, under which condition, and who owns it? The next lesson converts a specific threat into a testable security requirement. It should not turn every open question into a vague requirement.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare its review-and-validation questions with the evidence checks in this lesson.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Use its collaboration principles when inviting different viewpoints into a model review.
• [PROJECT] OWASP Threat Modeling Project — Focus: Keep review tied to a specific system and actionable outcomes rather than a generic checklist.

Key Takeaways

• Review the connections among scope, flow, actor, assumption, path, and objective—not the number of rows in a document.
• A useful review can keep, merge, reject, or investigate a candidate; each result should state its evidence.
• Different viewpoints challenge different weak links, but they should converge on the same system model.
• Finish discovery with explicit retained paths and open questions before designing controls or requirements.