Threat Modeling Starts With the System

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

• Explain why a list of security controls is not yet a threat model.

• Describe a small system well enough that another person can recognize what is inside the analysis and what is outside it.

• Improve a vague threat-model scope by adding a system promise, actors, components, dependencies, flows, and assumptions.

Idea in one sentence: Before asking what can go wrong, build a recognizable model of the particular system whose security and privacy you want to reason about.

Core Insight

A team is adding external sharing to a fictional product called ShareBox. An employee uploads a document, enters a partner's email address, and creates a link that expires after 24 hours.

The first security discussion sounds productive:

• require multi-factor authentication for employees;
• encrypt stored documents;
• scan uploaded files;
• write an audit log;
• rate-limit downloads.

Every item might be useful. Yet the team cannot answer a smaller question:

Does the invited partner need an account, or can anyone holding the link download the document?

That missing answer changes the system. It changes who can act, where authorization happens, what the email provider can expose, what “revocation” means, and which controls can protect the document.

The team has started with solutions before agreeing on the thing being secured.

Threat modeling begins one step earlier. It begins with a representation of a real system: its purpose, actors, components, interactions, dependencies, assumptions, and boundaries. Only then can a threat or mitigation refer to something concrete.

The Tempting Shortcut: Start With Controls

The initial model is reasonable:

Security means choosing strong controls from a reliable checklist.

This model helps with baseline hygiene. Password hashing, access checks, encryption, logging, and safe defaults should not be rediscovered from nothing for every feature.

The model becomes insufficient when the same control means different things in different systems.

Consider the instruction “require authentication.”

• Authentication for the employee who creates the link?
• Authentication for the external recipient?
• Authentication between the download API and object storage?
• Authentication for a support engineer using an administrative tool?

The control name does not identify the actor, boundary, action, or security promise. A checklist can remind the team to ask about authentication. It cannot decide where authentication belongs until the system is visible.

The same problem appears with “encrypt everything.” Encryption at rest does not stop an authorized download endpoint from sending a document to the wrong person. Encryption in transit does not repair a link that acts as a reusable bearer credential. The control may work exactly as designed while the product promise still fails.

This is the pressure that creates the need for threat modeling.

What Are We Working On?

OWASP presents four methodology-neutral questions for threat modeling:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

This lesson concentrates on the first question.

In plain English, system modeling means creating a representation that the people involved can recognize as the system under analysis.

For an early conversation, that representation can be small. It does not need every class, port, database column, or network rule. It needs enough truth to support the next security question.

A useful first scope records:

Notice what this table does not contain yet: a complete threat list or a final design. Its job is orientation.

A Small System We Can Recognize

For this lesson, ShareBox is a simplified teaching model, not an observed production architecture.

Employee browser
      |
      | upload document + partner email
      v
Sharing API -----> Metadata database
      |
      +----------> Object storage
      |
      +----------> Email provider -----> Partner inbox

Partner browser ---- share link ----> Download endpoint ----> Object storage

The diagram is deliberately incomplete, but it earns several useful questions:

• Does the link identify a document, grant access, or both?
• Does the download endpoint check the recipient's identity?
• Which component decides that 24 hours have passed?
• How does revocation reach the download path?
• Is the email provider merely transporting the link, or is it inside the trusted delivery story?

We are not answering those questions yet. We are showing where the questions attach to the system.

That distinction matters. “Links can leak” is a vague concern. “A forwarded link can be replayed at the download endpoint because possession of the link is the only authorization evidence” is a claim about specific actors, data, and decisions. The second statement can be challenged, tested, or changed by the design.

How the First Scope Breaks

Suppose the team writes:

Scope: the ShareBox upload service.

This sounds precise. It is also too narrow for the promised feature.

The user promise is not only “store a document.” It includes delivering access to an external partner and later denying access after expiry or revocation. The important path leaves the upload service:

1. The employee creates a share.
2. The API generates or records access data.
3. The email provider carries the link.
4. The partner opens the link in another browser.
5. The download endpoint decides whether to return the document.

If the model stops after step 2, it excludes the decisions most likely to determine whether the sharing promise holds.

Now try the opposite scope:

Scope: every system that might affect ShareBox security.

This includes the partner's device, the employee's organization, internet routing, the cloud provider, the email provider, support processes, and perhaps the physical security of every data center. The model becomes too broad to guide one feature decision.

The stronger model is purpose-bounded:

Include the actors, components, interactions, dependencies, and assumptions needed to reason about the external-sharing promise. Record important exclusions instead of pretending they do not exist.

For example, the team can include email delivery as a dependency and state that compromise of the partner's already-unlocked device is outside this feature review. That exclusion is not proof that the device is safe. It is an explicit limit on the current analysis.

Worked Classification

Classify each statement before reading the explanation.

1. “All stored documents use provider-managed encryption.”

This is a current control or implementation fact. It belongs in the model as context, but it does not define the whole system or prove the sharing promise.

2. “An employee can revoke a share, after which the old link must not download the document.”

This is a system promise with an observable security consequence. It tells us that the revocation decision and the download endpoint belong in scope.

3. “The email provider will not rewrite or inspect the link.”

This is an assumption about an external dependency. The team should be able to challenge or verify it. Hiding it inside prose would make the model look more certain than it is.

4. “The partner's personal device is outside the current review.”

This is a scope decision. It can be reasonable for a feature-level exercise, but the residual limitation should remain visible: the feature cannot protect a document after a legitimate recipient saves or copies it.

5. “Use short, random link tokens.”

This is a proposed response. It may reduce guessing, but it comes after the system and threat are understood. It does not answer whether a forwarded valid link should work.

So far, we have separated five things that teams often mix together: system facts, promises, assumptions, scope decisions, and proposed controls. Threat modeling becomes easier when each statement has an honest role.

What This Changes

Before modeling the system, a security discussion tends to collect nouns: MFA, encryption, scanning, audit, zero trust.

After modeling the system, the discussion can form checkable sentences:

• This actor performs this action.
• This data crosses this boundary.
• This component makes this decision.
• This external service is trusted for this limited behavior.
• This promise fails if this assumption is false.

Those sentences do not guarantee security. They give the team a shared object to challenge.

The system model also makes disagreement useful. If an engineer says the email provider is outside the system while a product manager says private delivery is part of the promise, the disagreement is no longer hidden. The team can revise the promise, the design, or the stated boundary.

Consequences, Trade-offs, and Limits

More detail is not automatically better.

A model that is too shallow hides important paths. A model that is too detailed consumes time, becomes hard to update, and can distract the team with implementation facts that do not change a decision.

The practical preference is to use the smallest model that supports the current security decision.

This improves shared understanding and keeps the exercise manageable. It costs time to create and maintain. It can still fail when participants omit a dependency, hold different assumptions, or draw the boundary around the component they own rather than the promise the user depends on.

Watch for these signals:

• threats have no component, actor, or interaction to attach to;
• controls are proposed without naming the failure they prevent;
• participants disagree about how a request or piece of data moves;
• a feature promise crosses a dependency that the diagram omits;
• “out of scope” is used to erase risk instead of delimit the current exercise.

A threat model is a working representation, not a certificate. It should change when the system or its important assumptions change.

Common Confusions

Confusion: A threat model is a list of threats.

Why it is tempting: the threats look like the main output.

Better model: threat discovery depends on a representation of a particular system. Without that representation, the list is generic and difficult to verify.

Confusion: The architecture diagram is the threat model.

Why it is tempting: the diagram is the most visible artifact.

Better model: the diagram is one representation. The model also needs promises, assumptions, security concerns, decisions, and follow-up actions.

Confusion: Out of scope means safe.

Why it is tempting: removing an item makes the exercise smaller.

Better model: an exclusion limits what the current exercise claims. It does not remove the excluded dependency or risk from reality.

Confusion: We need a perfect diagram before discussing threats.

Why it is tempting: missing detail feels unsafe.

Better model: begin at a resolution that supports the current decision, record uncertainty, and refine the representation when a question requires more detail.

Check Your Understanding

Check: A team says, “Our threat model covers the API.” The product promise is that a password-reset email lets only the requesting user regain access. What is missing from the scope?

Think first, then reveal.

Answer: At minimum, the reset-token creation and storage, email delivery dependency, recipient interaction, reset endpoint, expiry or one-time-use decision, and resulting credential change. “The API” does not reveal the end-to-end promise or its trust assumptions.

Check: Is “enable audit logging” part of the answer to “what are we working on?”

Think first, then reveal.

Answer: It can be recorded as an existing or proposed control, but it does not answer the first question by itself. The model must first show which actions matter, which component records them, and what evidence the log is expected to provide.

Practice

A library lets a member request a password-reset link. A third-party email service delivers the link. The reset endpoint accepts the token and a new password.

Write a compact first scope for a threat-modeling session.

A good answer should mention:

• the promise: the correct member can regain access without giving another person control of the account;
• the actors: member, possible link holder, support staff, and external email provider;
• the components: reset-request endpoint, token state, email integration, reset endpoint, and account store;
• the interactions: request, token creation, email delivery, token submission, password change, expiry, and invalidation;
• at least one assumption, such as how the member's email address was established;
• an explicit boundary or exclusion, such as the handling of an already-compromised unlocked device;
• no claim that a proposed control, by itself, proves the promise.

Connections

• The next lesson, Assets, Security Objectives, and Impact, sharpens the word “promise” by asking what has value and what harm a failure creates.
• Data Flows, Entry Points, and Trust Boundaries turns the compact system sketch into a more precise flow model.

Resources

• [GUIDE] OWASP Threat Modeling Project — Focus: The four-question framework, methodology-neutral scope, system representation, and lifecycle use.
• [ARTICLE] OWASP Threat Modeling Cheat Sheet — Focus: Why system modeling precedes threat identification and which elements make a system representation useful.
• [TUTORIAL] Microsoft Threat Modeling Security Fundamentals — Focus: Data-flow elements, trust boundaries, model depth, and the design-break-fix-verify sequence.

Key Takeaways

• A control checklist can support threat modeling, but it cannot replace a model of the particular system.
• Start with the user or system promise, then include the actors, components, interactions, dependencies, assumptions, and boundaries needed to reason about that promise.
• Scope should be narrow enough to guide a decision and broad enough to include the end-to-end path on which the promise depends.
• An explicit exclusion limits the current analysis; it does not make the excluded risk disappear.
• The model is ready for the next step when threats and controls can attach to recognizable parts of the system.