Capstone: Run a Small Abuse-Case Review

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

• Produce a small, bounded abuse-case review that another team can inspect and prioritize.

• Connect an adversary profile, abuse cases, chain gates, human workflow, capability boundaries, and defensive actions.

• Reject or downgrade an unsupported path and communicate the remaining finding responsibly.

Idea in one sentence: A good abuse-case review turns a plausible path into a proportionate decision, not a collection of scary possibilities.

Core Insight

A capstone is not a longer threat list. It is a proof that the learner can keep several useful boundaries intact at the same time: a bounded adversary, a visible chain, a human workflow, a capability limit, an owned defense, and a responsible finding. If one of those is missing, the dossier may still sound security-minded while failing to produce a decision someone can safely make.

The central pressure is that each earlier lesson can be used badly in isolation. A profile can become an all-powerful attacker. An abuse case can become a vague label. A chain can become a dramatic story with missing gates. A control can become an unowned checklist. A disclosure can become a public accusation. The capstone corrects that fragmentation by making every artifact answer to one product promise.

For this review, the promise is that intended readers—not merely any person with a company account—can view a confidential roadmap, while support retains only the case-specific capability it needs. The strongest submission is not the one with the greatest number of threats. It is the one whose next owner can challenge a fact, change an assumption, select a control, and still understand what remains true.

The Scenario

Northstar is a fictional company document service. A product team wants a “rapid review” feature: an owner can create a company link to a confidential roadmap; the link may be added to a support ticket when a display problem occurs; support may use a short-lived metadata token for the named case. The promise is simple:

Only intended readers should view the roadmap, and support should diagnose a case without acquiring standing access to unrelated confidential documents.

Your capstone is an abuse-case review dossier for this feature. You are not testing Northstar, contacting people, collecting document contents, using tools against a target, or writing an exploit. You are using the fictional facts in this lesson to make an inspectable defensive argument.

The initial model is that a review succeeds when it names many threats. That model fails because an unlimited attacker makes every feature look hopeless, while a long list gives no owner a next decision. The stronger model is a bounded dossier: each claim has a starting state, evidence or uncertainty, a path consequence, a proportionate defense, and a remaining risk.

Constraints

Use only these teaching facts:

Do not add stolen credentials, administrator power, hidden vulnerabilities, real people, or “and then they somehow get access.” Those would be new branches requiring their own evidence. The capstone rewards a well-supported small model, not imagination without boundaries.

Design Goal

Produce one dossier with six parts:

1. system promise and scope;
2. bounded adversary profile and assumption ledger;
3. two candidate abuse cases, including one discarded or downgraded case;
4. one chain graph with gates, evidence, and uncertainty;
5. a behavior-to-defense matrix with owners and residual risk;
6. a concise responsible finding for the owning team.

The artifact should let a product, support, identity, or security owner ask, “What should we validate or change next?” It should not claim an incident that the facts do not establish.

Proposed Model

Start with a compact adversary profile.

Then write two abuse cases.

Case A — ticket audience. Ari reads a ticket with a company link. If the legacy policy accepts any company account with that link, Ari may receive the roadmap outside the owner’s intended audience. This challenges the assumption that internal ticket access is equivalent to intended readership.

Case B — unsupported outsider. A person without a company account somehow gets the link and reads the roadmap. The current facts provide neither an account nor a bypass of the company-account check. Downgrade this case. It is an open question, not a prioritized chain.

The discarded case is essential. It proves the review can reduce noise rather than merely accumulate risk.

Walkthrough

Draw Case A as a gate sequence:

[Ari can read ticket]
       | ticket contains a usable legacy link
       v
[Ari can present link with company account]
       | legacy authorization accepts company membership
       v
[Northstar returns roadmap]
       | conflicts with intended-reader promise
       v
[Unintended view may occur]

For each arrow, record what supports it. Ticket access and legacy authorization are given fictional facts. Ari’s intent is not. A document-view event could later help the owner inspect an actual access, but it would not prove intent by itself.

Now choose a defense. The primary control is explicit-recipient authorization for confidential documents; it changes the critical gate wherever the link appears. A complementary support workflow should avoid placing sensitive links in broad tickets. A proportionate signal records account, document, sharing mode, and time. A named owner decides whether a credible signal merits a temporary restriction. Recovery narrows sharing and reviews the audience if an inappropriate rule was active.

Support access has a separate capability boundary. Prefer a case-bound, read-only metadata token for one document and a short window over a broad, long-lived service capability. The former may still expose metadata for the named document during its valid window, but it does not automatically reach unrelated roadmaps. State the support cost: issuing case-bound authority and handling legitimate exceptions can slow diagnosis.

Failure Review

Review the dossier for four failure modes.

Unbounded adversary. If a story grants Ari an administrator session, stop. That is not a continuation of the given profile. Write a separate hypothesis only if new evidence supports it.

Control without a job. “Add logging” is incomplete. Name the event, the question it supports, the owner, and the safe first decision. A record is evidence, not an incident verdict.

Human blame. “Train support” is incomplete if the workflow asks an agent to approve a high-impact recovery change from urgency and apparent authority. Separate intake, independent verification, action-specific approval, notice, and escalation.

Unsupported impact. Do not write “roadmap stolen” without an observed event. Write “an unintended company account may view the roadmap if the stated conditions hold.”

Trade-offs

The review improves decisions, but it costs time and creates friction. Recipient-specific sharing can slow collaboration. Case-bound support access can slow diagnosis. Event retention creates privacy responsibilities. Temporary restrictions can interrupt legitimate work.

The trade-off is not solved by removing every safeguard or adding every control. Select the smallest set of layers that changes the important gate, supplies decision-relevant evidence, has an owner, and states what remains. A weak preventive control plus an unowned alert is not defense in depth.

The capstone also has a boundary. It does not replace secure-code review, detection engineering, incident response, legal advice, or a real disclosure policy. It is a defensible handoff into those practices.

Evidence and Readiness

Use this rubric before handing off the dossier.

Final Challenge

Create the dossier for Northstar using the supplied facts. Keep it to two pages or less. End with this six-line finding:

Scope:
Observed facts:
Supported impact:
Not claimed:
Minimum evidence handling:
Requested owner decision and next check-in:

A strong submission contains the Case A chain, downgrades Case B, selects explicit-recipient authorization as the primary control, gives support access a narrow capability boundary, and states one residual risk. It should be possible for the owner to disagree with an assumption without discarding the whole review.

Before handing it over, perform one revision pass. Read the dossier as the product owner. Can you identify the one request that needs a decision? Read it as support. Can you see which workflow step changes and what evidence is sufficient? Read it as the person who will receive the finding. Can you reproduce the relevant configuration without being given confidential content or a portable link? Read it as a skeptical reviewer. Can you point to the exact place where the analysis stops claiming more than its evidence supports?

If the answer is no, revise the smallest part that is unclear. Do not add a second attacker story to hide the uncertainty. For example, if the primary control sounds vague, name the authorization gate it changes. If a signal sounds vague, say which account, document, sharing mode, and time need to be connected. If a recovery step sounds vague, name the owner who may narrow the sharing state and the condition for reversing that restriction. If the support token sounds vague, state its resource, action, lifetime, delegation, and stopping boundary.

The dossier should also be readable by someone who does not share the reviewer's intuition. That is why each table has an evidence column and why an unsupported case is retained only as a downgrade. A reader may decide that Ari's assumed intent is unlikely. That changes prioritization, not the fact that the legacy authorization rule can conflict with the intended-reader promise. Conversely, a reader may find that the ticket audience is actually narrower than assumed. That breaks the illustrated path and should lower the finding without requiring a debate about attacker cleverness.

This is the practical value of the capstone: it turns disagreement into a change to a specific field rather than an argument over whether security matters. The model is inspectable, proportionate, and reversible. It creates a compact record of what the team knows, what it assumes, what it will validate, and what it chooses to do next.

One final prioritization pass keeps the dossier useful. Rank Case A by asking three questions in order. First, does it conflict with an important promise? Yes: confidential access is broader than intended readership. Second, are its starting state and gates supported? Yes, within the fictional facts, though intent remains an assumption. Third, does a proportionate owner have a feasible change? Yes: explicit-recipient authorization changes the main gate, while safer ticket handling and case-bound support access reduce complementary opportunities. This is enough to recommend validation and design work; it is not enough to claim a confirmed incident.

Now rank Case B. It has a potentially serious outcome, but no supported starting account, no path through the company-account check, and no evidence of a bypass. The correct action is not to erase it forever. Record it as an open question, identify what evidence would make it relevant, and keep it out of the immediate recommendation. This comparison shows why impact alone is not priority. Plausibility, evidence, control leverage, and cost must travel together.

Finally, hand off the dossier with a clear owner boundary. Product owns the authorization promise. Support owns the ticket and case workflow. Identity or platform owners may own group membership and capability issuance. A security reviewer helps keep the reasoning coherent, but should not silently become the owner of every control. When responsibilities cross teams, the dossier is successful if it makes those dependencies visible before a real issue forces a hurried decision.

Resources

• [ARTICLE] OWASP Threat Modeling Cheat Sheet — Focus: compare the dossier with a structured system-model, threat, response, and review loop.
• [FRAMEWORK] NIST Cybersecurity Framework 2.0 — Focus: use outcomes and ownership to organize protection, detection, response, recovery, and governance.
• [ARTICLE] CISA Vulnerability Disclosure Policy Platform — Focus: use an owner’s published channel and scope when a real finding requires coordination.

Key Takeaways

• A capstone review is complete when another owner can inspect its assumptions, gates, defenses, evidence, and residual risk.
• A discarded unsupported path is evidence of disciplined adversarial judgment.
• The best primary defense changes the relevant authorization or capability gate; other layers reduce opportunity and improve handling.
• Honest communication states a possible impact without manufacturing an incident.
• The final artifact is a bounded, actionable handoff—not an exploit plan or a fear report.