Abuse Cases and Attack Paths

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

• Turn a security objective into a concrete abuse case with a visible undesired outcome.

• Trace a plausible attack path by naming its starting state, preconditions, steps, and result.

• Find the assumption or step that a control, test, or design change could interrupt.

Idea in one sentence: An abuse case states the bad outcome we must prevent; an attack path makes the sequence required to reach that outcome inspectable.

Core Insight

ShareBox lets an employee send a time-limited link to a commercial proposal. The team has already named a confidentiality objective: only the intended partner should be able to read the proposal. It has also drawn the path: a browser presents a link to the download endpoint, which checks current link state and returns the document.

The first reaction to a forwarded link is often, “Someone could steal the document.” That sentence is not wrong, but it is too compressed to guide a decision. Does the person need to sign in? Does the endpoint still accept the link after it is revoked? Can the person discover the link, or must somebody forward it? Which of those claims is known, and which is an assumption?

An abuse case describes the system being used to produce an outcome its owners do not want. An attack path is the smaller causal story: the starting position, the conditions that must hold, the actions taken, and the objective failure at the end. The path is not a list of frightening possibilities. It is a claim that the team can inspect and challenge.

The Small Situation

Keep the scenario deliberately small.

The last row is an assumption, not an observed fact about every product. In a real review, the team would confirm it by reading the endpoint contract and exercising the feature with a browser that has no partner account. We will use it so that the causal structure stays visible.

The Initial Model: Name the Threat and Move On

It is reasonable to begin with a short threat statement:

A forwarded sharing link may disclose a proposal to an unintended reader.

This works as a reminder. It does not yet tell us whether the threat is plausible in this design, where to put a control, or what a successful test would look like. A team that jumps straight from that sentence to “add authentication” may protect the wrong step. It may also miss a simpler break in the sequence, such as expiry, revocation, or a rule that binds the link to a partner identity.

The missing part is the route between the actor and the broken promise. We need to turn the threat statement into an abuse case, then show the path that makes it possible.

From an Undesired Outcome to an Abuse Case

Write an abuse case in terms of an actor using a real system behavior to violate a named objective. A compact shape is:

[Actor] uses [entry point or system behavior] to cause [undesired outcome],
violating [security objective].

For ShareBox:

An unintended link holder uses the download endpoint to read a proposal intended for a partner, violating the proposal’s confidentiality objective.

This is more useful than “document theft” for three reasons.

1. It keeps the actor bounded. The person holds a link; we have not granted them every capability.
2. It names the behavior to examine: the download endpoint’s handling of a link.
3. It names the consequence that matters: an unauthorized read, not merely a suspicious request.

An abuse case does not claim that the event has already happened. It is a teaching model of an unwanted outcome that could follow if its preconditions hold. Evidence can weaken or defeat it. For example, if the endpoint requires a verified account matching the intended partner before it returns bytes, “has a forwarded link” no longer supplies all the necessary access.

The Moving Parts in an Attack Path

Now expand the abuse case into an attack path. A useful path has four kinds of information:

The important distinction is between an action and a precondition. “The person opens the link” is an action. “The endpoint accepts the link without verifying partner identity” is a condition that the team must verify. Combining them hides where the design actually makes the path possible.

A Worked Attack Path

Here is the complete small path. The timestamps are illustrative; they are not an observed incident record.

Notice what this table does not say. It does not say that email is always unsafe, that a partner acted maliciously, or that a person bypassed encryption. The path uses only the stated actor capability and the system behavior under review. That restraint is useful: a path earns attention by being plausible, not by being dramatic.

Why include step 3 separately from step 4? Because the boundary is between them. If the endpoint rejects the request, the actor can still present the link but cannot complete the path. If it returns the file, the objective failure is concrete. Separating acceptance from delivery makes the future requirement and test much sharper.

So far, we have moved from a vague concern to a testable claim: a forwarded link, while valid and accepted as sufficient proof, leads through the download endpoint to an unauthorized read.

Find the Path’s Breakpoints

An attack path is useful because it exposes more than one breakpoint. A breakpoint is a precondition or action whose failure prevents the undesired outcome. It is not automatically a control choice; it is first a place where the team can reason.

These are situated options, not universal commands. The trade-off is stronger assurance against an unauthorized read versus the identity and workflow friction imposed on legitimate recipients. If a proposal is public by design, identity binding may be needless friction. If the proposal contains acquisition terms, the stronger requirement may be justified. Later lessons will turn the selected breakpoint into a testable security requirement and discuss layered controls. For now, the path prevents a familiar mistake: treating “authentication” or “logging” as a complete answer without stating which step it changes.

Where This Model Breaks

An attack path is a hypothesis about a system state, not a proof that the system has a vulnerability.

It breaks or needs revision when its evidence changes:

• The endpoint now requires a verified partner account, so step 3 no longer follows from link possession alone.
• The link token is sent through a channel the unintended person cannot access, so step 1 is unsupported for this actor.
• The objective is availability rather than confidentiality, which calls for a different undesired outcome and likely a different path.
• The team learns that a CDN or proxy serves the file under different authorization rules; that component belongs in the path rather than being silently ignored.

The model also has a scope boundary. We are not evaluating exploit techniques, cryptographic internals, or every social route by which a link could be copied. Those may matter in a different scope, but adding them here would hide the one mechanism this lesson is teaching: every claimed path needs visible preconditions and transitions.

Common Confusions

Confusion: “An abuse case is just a bug report.”

Why it is tempting: both describe unwanted behavior.

Better model: a bug report usually says that observed behavior violates an expected result. An abuse case explores how valid or invalid system behavior could violate a security objective before an incident exists.

Confusion: “An attack path must contain a clever exploit.”

Why it is tempting: the word “attack” suggests a technical break-in.

Better model: a path can use ordinary product behavior. The security question is whether those steps let a plausible actor violate a promise.

Confusion: “Every row in the path is a control.”

Why it is tempting: teams want to move quickly to mitigations.

Better model: some rows are starting conditions or actions. A control changes, blocks, detects, or recovers from a specific transition; it needs a stated location and effect.

Confusion: “One path proves the whole threat model is complete.”

Why it is tempting: a detailed table feels comprehensive.

Better model: it gives one inspectable explanation. Lesson 007 adds structured prompts to look for other paths while keeping context and judgment in charge.

Trace It Yourself

Check: A ShareBox link is valid, but the download endpoint now requires a signed-in partner account whose identifier matches the recipient recorded on the share. An unintended person has only the forwarded link. At which step does the worked path stop?

Think first, then reveal.

Answer: It stops at step 3. The person can still open the link and send a request, but link possession no longer satisfies the endpoint’s acceptance condition. Update the path’s preconditions rather than claiming that forwarding is impossible.

Check: The team adds an audit record after each successful download. Does that break the path?

Think first, then reveal.

Answer: No. The record may create evidence for investigation or later review, but the endpoint can still return the file. It is a detection or evidence measure, not a prevention at the acceptance step.

Practice: Trace a Nearby Path

A clinic portal emails a patient that a test result is ready. The email contains a link to a page that displays the result. In the current design, the page accepts the link alone; it does not ask the visitor to sign in. An unintended household member reads the email on a shared device and opens the link.

Write one abuse case, then trace the path with a starting state, two or more preconditions, actions, and the violated objective. Finally, mark one breakpoint and say whether your proposed response prevents, detects, or limits the outcome.

A good answer should mention:

• confidentiality of the patient’s result, not a generic statement that “data is at risk”;
• the shared-device or email access as the actor’s starting position, without granting access to the entire clinic system;
• a precondition about the link being accepted without patient identity verification;
• the page returning the result as the objective failure; and
• the boundary that an audit record helps explain the event but does not stop the read.

Connections

• Lesson 005 supplies the bounded actor and assumption ledger that make a path plausible instead of imaginary.
• Lesson 007 uses STRIDE as a way to ask for additional threats without treating categories as an answer.
• Lesson 009 turns a selected breakpoint into a testable security requirement.

Resources

• [PROJECT] OWASP Threat Modeling Project — Focus: Use its outcome-oriented framing to connect a system representation to meaningful security questions.
• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare the abuse-case and threat-identification work with a practical decomposition workflow.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Use its principles to keep analysis collaborative, context-specific, and continuously revised.

Key Takeaways

• An abuse case names an unwanted outcome, the actor, the relevant system behavior, and the security objective at stake.
• An attack path separates starting access, preconditions, actions, and outcome so each claim can be checked.
• The most useful control discussion starts at a path breakpoint, not at a generic list of security products.
• A path is a bounded hypothesis: new evidence, a changed identity rule, or a changed system boundary can invalidate it.