Capstone: Threat-Model a Service Boundary

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

• Produce a small threat-model packet that connects a system boundary to threats, requirements, controls, evidence, ownership, and residual risk.

• Defend the packet by tracing one risk path from an assumption to a testable decision.

• State what change would require the model to be updated.

Idea in one sentence: A defensible threat model is not a perfect attack list; it is a reviewable argument about one system promise and the risks that remain around it.

Core Insight

Suppose a new external-sharing service is ready for launch and its team says, “We have authentication, logs, and expiring links.” The capstone asks you to assemble the whole threat-model argument instead. Begin with one service boundary, not a catalog of security products. Each claim must leave enough evidence for another person to trace why a risk matters, what the system changes, and what remains unresolved.

The Scenario

ContractDrop lets an account manager send a confidential contract to a named customer contact. The manager creates a share by selecting a contact from the customer account. The service sends the contact a notification. The contact signs in through the customer identity provider and then opens the contract. A manager can revoke a share before it expires.

The product promise is modest: a contract should be delivered only to the named customer contact while the share remains current. The service is not a secure viewer. A valid contact can download a contract and can later forward it outside the service.

You have been asked for a threat model before the team enables shares for customer accounts outside the current pilot. The goal is not to find every security issue in a document system. The goal is to produce a packet another reviewer can challenge, implement, test, and update.

Constraints

Use these facts as the fixed scenario. They are teaching assumptions, not claims about a real product.

Do not add penetration-testing steps, cryptographic primitive choices, vendor configuration detail, or a compliance checklist. Those are outside this foundation capstone. Work from the observable boundary and the stated constraints.

Design Goal

Your completed packet must answer the four questions from the track:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?

It must also make one reviewable chain visible:

asset and promise
-> flow and trust boundary
-> actor, precondition, and threat path
-> priority and requirement
-> control and remaining risk
-> test, signal, owner, and change trigger

The packet may be short. It cannot skip a link merely because a familiar control has a reassuring name.

Proposed Model

Start by writing a scope statement. A useful version is:

ContractDrop delivers a contract from an authorized account manager to a named customer contact. It must return content only when the verified customer-contact identity matches the share’s recorded contact, the manager is authorized for that customer, and the share is current.

Next, model the relevant flow. This text diagram is enough for the capstone; a visual diagram would be equally valid if it made the same boundaries visible.

Account manager
  -> ContractDrop share-creation endpoint
  -> Share record: contract id, customer id, named contact id, expiry, status
  -> Notification provider -> named contact

Named contact
  -> Customer identity provider
  -> ContractDrop download endpoint
  -> Share record and authorization decision
  -> Contract content

There are two important trust transitions. ContractDrop relies on a manager identity and customer assignment at share creation. Later, it relies on the customer identity provider’s verified contact identifier at download. The notification provider crosses a data boundary too: it receives an address and notification metadata, but should not receive the contract itself.

Now make assumptions explicit rather than hiding them in arrows:

This is the model’s starting point, not evidence that the assumptions are true.

Walkthrough: Turn One Path Into an Argument

Choose a plausible path with a meaningful consequence. For example:

1. A customer contact forwards a valid notification link to another person.
2. The other person obtains the link before expiry.
3. The other person reaches the ContractDrop download endpoint.
4. If link possession alone authorizes the request, contract content is returned.
5. Confidentiality of the contract has failed.

The initial response might be “require login.” That is useful but incomplete. A different customer contact can be logged in. The control must decide whether this verified identity is the contact recorded on this specific share.

Write the requirement before choosing the controls:

For a current contract share, ContractDrop must return content only when the verified requester identity matches the named contact recorded on that share. A valid link or authenticated identity alone must not authorize delivery.

Now place controls at the steps they change:

| Path point | Control | Job | Boundary | | --- | --- | --- | | Share creation | Manager-to-customer authorization and contact selection confirmation. | Prevents an unauthorized manager or obvious wrong-customer share. | It cannot prevent a legitimate manager from choosing the wrong named contact. | | Download decision | Compare verified contact identity with the share’s recorded contact. | Prevents link possession or another contact’s identity from authorizing content. | It cannot prevent the named contact from forwarding an already downloaded contract. | | Every download | Check revocation and expiry from current share state. | Limits later use of old or revoked shares. | It cannot undo a completed download. | | After a decision | Privacy-aware allow/deny event with reason code. | Supports review and investigation. | It does not prevent the response. |

This is layered design, not a shopping list. Each control has a named effect and a limit.

Failure Review and Prioritization

Compare this path with two others. Labels are illustrative judgments, not measured probabilities.

R1 is a direct, known authorization gap. R2 is a plausible workflow error that needs a proportionate design choice. R3 has lower confidence, not necessarily lower importance. Recording uncertainty as a research action is more honest than assigning a decimal score from guesses.

Trade-offs and Residual Risk

Recipient-bound access improves confidentiality because a forwarded link no longer authorizes a different person. It costs identity integration work and can create support friction when the customer identity provider changes an identifier. A creation confirmation may reduce misdelivery, but it adds a step for account managers. Detailed decision events aid investigation, but they require careful access and retention choices.

The capstone must name what remains. A named contact can download and forward a contract. ContractDrop can record the permitted delivery and revoke future access; it cannot erase the contact’s copy. The product may accept that residual risk for ordinary commercial contracts, but not automatically for a new category such as regulated documents.

Record that decision in a bounded form:

This is not a permission slip for harm. It is a claim with scope, authority, and a reason to revisit it.

Evidence and Readiness

A good packet makes each important control testable. Add a verification matrix:

These signals are investigation triggers, not incident verdicts. A sudden absence of mismatch denials may reflect healthy traffic, missing telemetry, or a bypassed policy. The owner must compare it with release and traffic context before deciding.

Defend the Design in Review

Imagine the reviewer asks three questions after reading the packet.

“Why not authorize with the link alone and make the link harder to guess?”

That choice could reduce accidental discovery, but it leaves possession of a copied link as the authorization condition. The stated promise is about a named customer contact, not merely an unguessed string. Recipient-bound authorization changes the decision at the point where content is released. A link can still be used as a locator or share reference, but it is not sufficient evidence of who is asking.

“Why not build a locked-down viewer so forwarding becomes impossible?”

That may be a reasonable product direction under different constraints. In this scenario, it would introduce a larger product and operational commitment while still not guaranteeing that an authorized person cannot photograph, copy, or retype information. The current decision is narrower: reduce unauthorized endpoint access, make permitted delivery explicit, and accept onward sharing for an ordinary contract scope. If the asset changes to a regulated document, the residual-risk trigger requires a fresh decision rather than stretching the old one.

“How would we know the system stopped applying the contact match?”

The answer is not one dashboard. The team would first have endpoint-level negative tests that exercise a mismatched contact against the protected route. The release check confirms the current authorization module and identity mapping are deployed. Runtime decision events then make unexpected changes observable. For example, a release followed by normal sharing traffic but no mismatch decisions should lead to a safe synthetic negative request and configuration check. An event is evidence that initiates investigation; it is not proof that a disclosure occurred.

This defense separates facts, assumptions, and preferences. The endpoint’s behavior is a claim checked by tests. The identity-provider mapping is an assumption that needs evidence and may change. Choosing ordinary collaboration over a restricted viewer is a product preference under the named scope, cost, and usability constraints. The question of whether a future document class is acceptable remains open until that feature is scoped.

Failure Response Walkthrough

Suppose a deployment accidentally changes the claim used to identify the customer contact. The negative test fails in the release environment: contact-b can receive the response for a contact-a share.

1. Contain the affected decision. The service owner disables new shares or the affected customer domain and rolls back the changed authorization mapping. This is a response to a confirmed control failure, not a substitute for the preventive rule.
2. Assess the scope using evidence. Review safe decision events, deployment version, and share records to identify whether the broken route served content. Avoid claiming that every historical share was exposed merely because the test failed.
3. Repair the argument. Correct the mapping, rerun positive and negative endpoint tests, and confirm that the release check and runtime event schema still represent the actual decision.
4. Update the living model. Record the identity-mapping assumption that failed, the evidence that exposed it, and whether the residual-risk decision or change trigger needs to be tightened.

The capstone is complete only when this kind of response can be reasoned about from the packet. A document that lists controls but cannot explain what to do when one stops working is a snapshot, not a usable threat model.

Final Challenge

Create your own capstone packet for a nearby boundary: a clinic portal sends a patient a test-result notification and the patient views the result after identity verification. Do not reuse the ContractDrop answers mechanically.

Include:

1. A scope statement with asset, intended recipient, and protected decision.
2. A flow with at least one trust boundary and one explicit assumption.
3. Two plausible abuse paths with preconditions and consequences.
4. A qualitative priority decision, including one uncertainty that needs evidence.
5. One testable security requirement and controls mapped to the path.
6. A residual-risk record with responsible and accountable owners.
7. A positive test, a negative test, one privacy-aware signal, and one response expectation.
8. One feature, identity, dependency, or incident trigger that would reopen the model.

Use this rubric to defend the result:

Key Takeaways

• A threat-model packet is complete when another reviewer can trace a claim from system promise to verification and remaining risk.
• Scope, assumptions, and boundaries make threat paths specific enough to prioritize and control.
• Controls earn their place by changing a named path; tests and signals earn confidence by checking the resulting behavior.
• Residual risk needs an accountable decision, evidence, and a change trigger—not a vague “accepted” label.
• A living model changes when its actors, flows, assets, assumptions, controls, or evidence change.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Use the four questions to connect system modeling, threat response, and review.
• [GUIDE] OWASP Authorization Testing Automation Cheat Sheet — Focus: Test who may do what to which protected object across releases.
• [MANIFESTO] Threat Modeling Manifesto Capabilities — Focus: Define actionable outcomes and completion criteria for a living threat model.