Threat Actors, Capabilities, and Assumptions

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

• Describe a relevant threat actor by goal, access, capability, constraint, and knowledge.

• Turn a vague security assumption into a statement that a team can challenge.

• Reject both “nobody would do that” and “the attacker can do anything” as unhelpful models.

Idea in one sentence: A useful adversary profile is a bounded explanation of who might try to break a specific promise, what they can actually do, and which assumptions make that attempt easier or harder.

Core Insight

ShareBox’s team has a good scope packet for its external document-sharing feature. It knows that a partner presents a link to the download endpoint, which reads current expiry and revocation state before returning a proposal.

Then someone asks, “What if an attacker gets the link?” Another person replies, “An attacker can do anything, so we need every possible control.” A third says, “Our partners are trusted, so that is not worth discussing.”

All three reactions skip the useful work. A threat model does not need a movie villain or an all-powerful attacker. It needs a plausible actor connected to the system’s values, entry points, and assumptions.

The Two Bad Extremes

The first tempting model is:

Treat every outsider as able to bypass every protection.

It can be useful as a reminder that systems fail. It becomes useless when it makes every threat equally urgent. If an actor can rewrite databases, intercept all traffic, impersonate every employee, and operate every dependency at once, the model cannot guide a design decision.

The opposite model is:

Only malicious experts matter, and trusted people never cause a security failure.

This also breaks. A partner can forward a link by mistake. A former contractor may retain access. An employee may use a feature in a way the product did not intend. Security concerns can be malicious or accidental; the model should distinguish intent without hiding the effect.

The stronger model is an adversary profile: a small, testable description of an actor’s goal, starting access, capabilities, constraints, knowledge, and assumptions. It is not a prediction of a specific person. It is a reasoning tool.

Build a Profile From the System, Not From Fear

Start with the scope packet from lesson 004. Choose a value and a path where its objective could fail. Then ask who has a credible reason and starting position to interact with that path.

For ShareBox, consider a person who receives the partner’s forwarded email but was not the intended recipient. This teaching model assumes the product currently uses a bearer-style link: possession of the link is enough to request the proposal. It does not assume the person can break encryption, access ShareBox infrastructure, or impersonate the employee.

This profile is more useful than “external attacker.” It points to the partner-browser entry point, the link capability, and the confidentiality objective. It also shows what evidence would change the discussion: if the product requires a verified partner account, the starting access and capability claims must be revised.

Assumptions Are Part of the Model

An assumption is a condition treated as true while the team reasons about the system. It is not a blank space where difficult questions disappear.

Use this shape:

We currently assume [condition].
This matters because [it enables or limits an actor or path].
We can challenge it by [evidence, design review, test, or system change].

For the forwarding profile:

We currently assume the link itself is sufficient to request a download.
This matters because an unintended holder can reach the same entry point as the intended partner.
We can challenge it by reviewing the endpoint’s required inputs and testing a request from a browser with no partner account.

This does not decide whether the feature is acceptable. It earns the next question: if the assumption holds, what sequence of actions could violate confidentiality? Lesson 006 will answer that with an abuse case and an attack path.

A Worked Comparison

The team initially writes one row:

It cannot be inspected. Rewrite it step by step:

So far, the team has not said that a disclosure will occur. It has a credible, bounded starting state from which it can later trace a path. That distinction keeps threat modeling from becoming either panic or reassurance.

What This Changes

Before this lesson, the team might ask, “What attacks exist for file sharing?” After it, the better question is, “Which actor can reach which entry point under which assumptions, and what objective could that interaction violate?”

That change makes review more precise. A profile that requires a former employee’s account belongs on a different path from a profile that starts with a forwarded link. The team can also state what it deliberately leaves out: cryptographic attacks, infrastructure compromise, and social-engineering detail are outside this foundation lesson unless the system evidence makes them necessary.

Trade-offs and Limits

The trade-off is coverage versus focus. Adding many actor profiles can reveal more possibilities, but it can also turn a session into an unranked list. Begin with actors that can plausibly interact with the values and paths already in scope, then expand when evidence or a system change warrants it.

Profiles can still be wrong. A useful signal is a new identity requirement, integration, download route, or customer workflow that changes an actor’s access or knowledge. When that happens, update the profile and its assumptions rather than treating the old one as permanent truth.

There is also a boundary on what this profile proves. It explains a credible starting point; it does not yet prove a complete sequence from the forwarded email to an objective failure. The next lesson must still ask what steps the actor takes, which preconditions must hold, where the path could be interrupted, and what direct evidence supports each later step. Keeping the profile separate from that later path helps the team revise one without quietly changing the other, losing evidence, or inventing steps the system does not permit.

Common Confusions

• “A threat actor must be malicious.” Mistakes and misuse can threaten the same objective; name intent when it changes the reasoning.
• “Capabilities are personality traits.” They are concrete actions the actor can take in this system, such as presenting a link or using a known endpoint.
• “An assumption means we have accepted the risk.” It is a claim to test or revisit, not a decision to ignore its consequences.
• “More powerful is always more useful.” A profile that can do everything cannot show where an actual boundary or control matters.

Check Your Understanding

Check: Is “a competitor” a sufficient profile for the ShareBox model?

Think first, then reveal.

Answer: No. Add a goal, a way the competitor reaches a specific entry point, capabilities, constraints, knowledge, and assumptions. Otherwise the label does not explain a plausible interaction.

Check: A partner is authenticated before a download. What should change?

Think first, then reveal.

Answer: Revisit the forwarded-link profile. Link possession may no longer be sufficient, so the starting access, capability, and key assumption have changed.

Practice: Profile a Nearby Actor

A clinic portal sends a patient a notification that a test result is ready. Create a profile for an unintended person who can see the notification but is not the patient. State the goal, starting access, capabilities, constraints, knowledge, and one assumption to challenge.

A good answer should connect the profile to a named value and entry point, avoid assuming access to every system, and say what evidence would invalidate its key assumption.

Connections

• Lesson 004 supplies the scoped system, values, paths, and assumptions that make a profile concrete.
• Lesson 006 turns this bounded profile into an abuse case and a step-by-step attack path.

Resources

• [PROJECT] OWASP Threat Modeling Project — Focus: Use its four-question framework to keep actor reasoning tied to a represented system and its assumptions.
• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare profiles with the system-modeling and threat-identification stages.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Use its principles to support collaborative, context-specific analysis rather than checklist theater.

Key Takeaways

• A useful actor profile states goal, access, capabilities, constraints, knowledge, and assumptions.
• Build the profile from a scoped value and path; do not begin with a generic attacker label.
• Assumptions are visible claims that future evidence can challenge.
• Bounded profiles prepare abuse-case reasoning without turning every actor into an all-powerful adversary.