Review: Scope a Threat Model

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

• Review a small threat-model scope for missing promises, assets, flows, assumptions, and trust boundaries.

• Explain why a diagram or a control list alone is not a usable answer to “what are we working on?”

• Repair an incomplete scope statement before the team begins threat discovery.

Idea in one sentence: A good threat-model scope is a compact, challengeable argument about the system, what has value, how it moves, and which assumptions must remain true—not a picture with a security label.

Core Insight

The ShareBox team starts a threat-model session for external document sharing. A product manager brings this submission:

ShareBox lets employees send documents to partners.
We use expiring links and encryption.

Employee → ShareBox → Partner

It names a feature and two possible controls. But a reviewer cannot tell what “send” means, what expires, where revocation is decided, or whether the email provider is inside the analysis.

The team’s first instinct is understandable:

We have a diagram and a few security measures, so we are ready to list threats.

That works only when everyone shares the same hidden model. One person may assume a logged-in partner; another may assume anyone holding the link can download. The review checks whether another informed person can recognize the system, its value, paths, and assumptions.

The Concepts Together

The pieces form one chain:

system promise and boundary
        ↓
assets, objectives, and consequences
        ↓
flows, entry points, decisions, and trust boundaries

Without a promise, access discussion is vague. Without value, a diagram is decorative. Without a path and decision, impact is speculative. This is still only the first question: what are we working on?

A Review Is Not a Vocabulary Test

A document can contain every vocabulary word and still fail to describe a coherent system:

The asset crosses a trust boundary through an entry point and requires confidentiality.

It does not name the asset, sender, receiving process, or failure. Review connections, not labels.

Use this compact test:

The test asks for evidence to make the next question specific, not a perfect diagram.

Synthesis Example: Review the Incomplete ShareBox Model

Return to the one-page submission. The review group uses the test above instead of starting with a list of attack names.

Each repair turns a broad concern into a reviewable claim. The group has not selected a control or named an attacker; it has made the system legible enough for a later threat to have a location and effect.

The Repaired Scope Packet

After the review, the ShareBox team writes this small packet. It is a teaching model, not a production specification.

Promise and boundary

An authenticated employee creates a time-limited share for one external partner. The partner can request the proposal using the link before expiry unless the employee revokes it. This scope covers creation, email delivery, download, expiry, and revocation. It excludes file-malware scanning and the employee’s corporate identity system.

Values and objectives

Actors, paths, and boundaries

Employee browser -- create share --> Sharing API --> metadata database
                                      |                object store
                                      v
                               external email provider
                                      v
Partner browser -- present link --> Download endpoint -- read state --> metadata database
                                                       -- if allowed --> object store

• The employee browser, email provider, and partner browser are external to the server-side ShareBox processes in this simplified model.
• The download endpoint makes the current allow-or-deny decision after reading expiry and revocation state.
• The email provider delivers a link; it does not decide that a later download is allowed.

Assumptions to challenge later

• The employee has already authenticated before creating a share.
• The download endpoint is the only route that returns proposal bytes for this feature.
• The endpoint reads current expiry and revocation state rather than relying on a stale copy.
• The email provider is used only to deliver the message described in this scope.

Now a reviewer can challenge a boundary, add a path, or test an assumption.

The Review Trade-off

The trade-off is completeness versus attention. A scope with every infrastructure detail becomes unreadable; a three-box diagram hides decisions. Include the smallest detail that answers the next question, and revise it when a new route, dependency, or state changes that answer.

Retrieval Check

Check: A team writes, “Our asset is the customer report. We use encryption.” What two links are still missing before this is a useful model?

Think first, then reveal.

Answer: Add the security objective and failure consequence, then the system context and flow through which the report is released. Encryption may be relevant later, but is neither the value argument nor the system representation.

Check: A diagram marks the partner browser, email provider, and object store. Does that automatically identify all trust boundaries?

Think first, then reveal.

Answer: No. State why control or assumptions change. A separately administered object store may warrant a boundary, while an internal service may also need one if its identity assumptions differ.

Check: Why record an assumption that the download endpoint is the only release path?

Think first, then reveal.

Answer: It makes the claim challengeable. A preview or export path would require an updated scope and analysis.

Common Confusions

• “The scope must include the whole company.” A smaller feature boundary is usually stronger when it contains the relevant promises, values, and paths. Broader is not automatically more complete.
• “A trust boundary means the other side is hostile.” It means the control or assumptions change. A trusted vendor can still be outside the team’s direct administration.
• “An assumption is an excuse to omit detail.” It is the opposite: a visible claim the team agrees to check, refine, or invalidate when the system changes.
• “Reviewing the model means we have already found the threats.” This review prepares threat discovery. It does not replace the adversary and abuse-path work in the next cluster.

Transfer Challenge

A clinic offers a portal where a patient can download a test result before a follow-up appointment. A draft says:

Patient → Portal → Result
The portal has login and encryption.

Review and repair it in no more than ten lines plus a small diagram or table.

A good answer names the promise and feature boundary; the result, access capability, and patient metadata with their objectives; the browser, decision point, state, store, and notification dependency; one changed-trust crossing; and one challengeable assumption about release paths.

Do not start by naming a threat category. If the system model cannot answer where the portal decides to release the result, it is not ready for that next question.

What Comes Next

You now have a way to review the first half of the threat-model argument: what system promise, value, path, and assumption are we going to examine?

The next lesson changes the question. It introduces threat actors, capabilities, and assumptions so the team can ask what could plausibly go wrong without inventing an all-powerful attacker. Keep this scope packet nearby; it is the map that makes that adversarial reasoning concrete.

Resources

• [PROJECT] OWASP Threat Modeling Project — Focus: Revisit the methodology-neutral four-question frame and its emphasis on scope, systems, assumptions, and trust boundaries.
• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare the scope packet with its system-modeling guidance for entities, processes, stores, flows, and boundaries.
• [LEARNING PATH] Microsoft Threat Modeling Security Fundamentals — Focus: Use it for further practice decomposing a system before eliciting threats.

Key Takeaways

• A reviewable scope connects a promise, boundary, values, objectives, flows, decisions, and assumptions.
• A diagram and a control list do not substitute for explaining what each path does and why it matters.
• Assumptions make the model easier to challenge and maintain; they are not hidden omissions.
• Finish this first question before moving to actors and threats, so later reasoning has a real system to inspect.