Threat Model Review Check

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

• Review a small threat model as one connected security argument instead of a checklist of controls.

• Locate the earliest missing link between scope, path, priority, requirement, control, evidence, and risk decision.

• Propose a focused correction that makes the model more defensible without inventing unrelated work.

Idea in one sentence: A useful review asks whether each important claim leads to the next one—not whether every document has been filled in.

Core Insight

Suppose a ShareBox team presents this one-line conclusion: “Proposals are safe because users authenticate, links expire, and downloads are logged.” It sounds reassuring. Yet it does not say which proposal matters, who is allowed to receive it, what an attacker can actually do, what the controls interrupt, what evidence proves them, or what risk remains.

At the start of this track, it was tempting to treat security as a list of familiar controls. We replaced that with a four-question practice: understand the system, discover what can go wrong, decide what to do, and check whether the result is good enough.

This review uses that practice as an argument chain:

system promise and scope
-> assets, flows, boundaries, and assumptions
-> plausible threat paths
-> priority and testable requirements
-> controls and residual-risk decision
-> tests, signals, owners, and change triggers

If a link is weak, later links cannot repair it by sounding more technical.

The trade-off is focus versus review time. A review that tries to enumerate every imaginable attack becomes hard to use; a review that only checks familiar controls misses the system-specific path. The right scope is the one that makes the important argument inspectable.

The Review Packet

The following is a deliberately flawed ShareBox packet. All names and events are illustrative.

The packet contains useful fragments. The review job is not to reject it because it is incomplete; it is to find the first missing connection and repair the model from there.

Review the Four Questions Together

1. What are we working on?

The scope does not name the security promise or the relevant boundary. Improve it:

A sender shares a commercial proposal with a named external partner. ShareBox must return content only to the recorded recipient’s verified identity while the share is current.

Now the asset, intended recipient, decision point, and basic confidentiality promise are visible. Add the sender, identity provider, download endpoint, and proposal store to the flow. Mark where ShareBox relies on external identity evidence.

2. What can go wrong?

“A bad person” is not a path. A useful path is:

An unintended person obtains a forwarded but valid link
-> requests the download endpoint
-> link possession alone is accepted
-> proposal content is returned

This path names preconditions, the decision point, and the consequence. It lets the team ask a useful next question: which condition must change so that link possession alone cannot return content?

3. What are we going to do about it?

“Use strong authentication” is a control label, not a requirement. Rewrite it as an observable outcome:

The download endpoint must return a proposal only when the verified requester identity matches the share’s recorded recipient and the share is not expired or revoked.

The team can now place controls on the path: recipient-bound authorization at the endpoint, current-share checks, expiry, revocation, and privacy-aware decision evidence. A log is detective; it does not replace the endpoint decision. A seven-day expiry limits opportunity but does not prove who is requesting.

4. Did we do a good enough job?

The unit test for token parsing cannot establish recipient-bound authorization. The dashboard of successful downloads may not reveal rejected attempts or a bypassed policy. Build a compact verification chain instead:

So far, we have seen that the review repaired the packet in dependency order: system promise before path, path before requirement, requirement before control, and control before evidence and acceptance.

Common Confusions

“A complete review means every conceivable threat is listed.”

Better model: review plausible paths that matter for the scoped system, and make uncertainty explicit. Exhaustive-looking lists can still miss the decision point.

“A severity label is a priority.”

Better model: priority needs impact, plausibility, exposure, confidence, and the decision context. “High” without reasoning cannot guide work.

“A documented accepted risk is safe.”

Better model: a record exposes a bounded decision. It still needs authority, evidence, a residual-risk statement, and a trigger for reconsideration.

“A dashboard proves the control works.”

Better model: a signal can prompt investigation. Endpoint tests and deployment evidence establish different parts of the claim.

Retrieval Check

Check: What is the difference between a security requirement and a control in the ShareBox review?

Answer: The requirement states the expected authorization outcome—only the recorded, verified recipient may receive a current share. Controls such as identity comparison, expiry, and revocation are chosen mechanisms that make and support that outcome.

Check: The team has an excellent negative authorization test, but no named accountable person for the remaining chance that a legitimate recipient forwards the proposal. What link is missing?

Answer: The residual-risk decision link. Test evidence supports the endpoint control; it does not decide whether the remaining business consequence is acceptable or who must revisit it.

Transfer Challenge

A clinic portal submits this statement: “Only patients can see results because the app requires login and has audit logs.” Review it using the argument chain. Write the first missing detail you would request in each of the four questions.

A good answer should mention:

• a scoped result asset, patient identity, and viewing boundary;
• a concrete path such as one verified patient attempting to view another patient’s record;
• an endpoint-level patient-to-record authorization requirement rather than generic login;
• positive and negative tests, privacy-aware decision evidence, and a residual-risk or change-review owner.

What Comes Next

The capstone will ask you to make this argument yourself for a small service boundary. It is not a request for a perfect diagram or an encyclopedic threat list. It is a request for a coherent, reviewable packet that lets another person understand the system, challenge its claims, and see what must happen when it changes.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare system modeling, threat identification, response, review, and validation questions.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Treat threat modeling as collaborative, continuous system understanding rather than checkbox compliance.
• [MANIFESTO] Threat Modeling Manifesto Capabilities — Focus: Define done criteria and maintain actionable, versioned outcomes.

Key Takeaways

• Review a threat model as an argument chain, beginning with scope and the system promise.
• A concrete path earns a testable requirement; a control name alone does not.
• Evidence, ownership, residual risk, and change triggers complete the argument around a mitigation.
• Repair the earliest missing connection first, then check the downstream consequences.