Threat Modeling for a Feature and System Boundary

A security review becomes useful only after the thing being reviewed is bounded. A list of controls is not yet a threat model. In this lesson you will work on one fully synthetic document-sharing feature, name its assets, actors, entry points, data flows and trust boundaries, then connect material threat scenarios to controls and inspectable evidence.

The goal is not to prove that a system is secure. The goal is to produce a bounded, reviewable decision record that explains what was modeled, what evidence was observed, what changed when a boundary moved, and what remains uncertain.

1. The bounded outcome

By the end, you can build Bounded Threat Model Record v1 for one synthetic feature. Each material row connects: asset → security objective → actor/entry point → trust boundary → threat scenario → control → evidence check → residual risk → owner decision needed.

You will preserve both positive and negative evidence. A successful path alone is never treated as complete security proof.

2. The synthetic feature

The local fixture models a document-sharing service. An authenticated owner uploads a document and metadata. A named collaborator may retrieve that document through the application service. Metadata and document bytes are stored behind the application service. No production account, real credential, external target, or irreversible network action is used.

The bounded question is: Can this feature preserve its declared access and trust assumptions when we deliberately change one boundary or remove one evidence check?

3. What this record proves—and what it does not

The record can show that, in the declared synthetic fixture, a threat scenario is linked to a control and to an observable check. It can also show that a changed trust boundary invalidates an earlier assumption.

It does not prove production security, universal completeness, formal risk acceptance, or correct deployment of a similarly named control elsewhere.

4. Asset and security objective

Start with what must be protected, not with a control name. The primary assets are document content and document metadata. A bounded objective may be: only the owner and an explicitly named collaborator can retrieve the document; unauthenticated callers cannot read document metadata.

A useful objective is testable. “Use authentication” is a mechanism. “An unauthenticated caller cannot read metadata” is an observable objective.

5. Actors and entry points

The fixture has three relevant actor classes: owner, named collaborator, and unauthenticated caller. Entry points are upload, document retrieval, and metadata retrieval. The model stays intentionally small so that every row can be traced to evidence.

Do not silently add administrators, billing systems, CDN behavior, malware scanning, key management, or incident response. Those can matter in a real review, but they are outside this lesson unless the boundary is explicitly changed.

6. Data flow before threat labels

Describe the flow before assigning threat names:

1. owner/collaborator → application entry point;
2. application service → metadata store;
3. application service → storage adapter;
4. application service → response to the authorized actor.

The flow tells you where trust assumptions are crossed. A threat row without a concrete path tends to become checklist prose.

7. Trust boundaries

TB-INTERNET-APP separates untrusted client input from the application service. In the baseline fixture, the storage adapter is treated as part of the application-controlled trust zone. That assumption is deliberately mutated later.

A trust boundary is not a decorative line. Moving a component across it changes which assumptions are valid and therefore which threat/control rows must be reconsidered.

8. Threat scenarios, not generic threats

A material scenario names a precondition, target asset, path and consequence. Example: an authenticated user requests a document for which they are neither owner nor collaborator; if object authorization is absent, document content could be disclosed across the feature boundary.

The scenario is bounded. It does not claim that every application has the same threat or that one taxonomy is complete.

9. Controls must trace to a scenario

For the cross-user read scenario, the preventive control is an ownership/collaboration authorization check at the application service. The evidence check is a positive retrieval by an allowed collaborator plus a negative retrieval by a different authenticated actor.

A control name with no evidence check is CONTROL_UNVERIFIABLE in this lab. Naming “authorization” does not establish enforcement.

10. Evidence before inference

Separate three layers:

• Fact/design boundary: what the frozen lesson contract says must be modeled.
• Observation: what the local fixture actually returned.
• Inference: what the observation supports inside this bounded model.

Never turn a local observation into a universal security claim.

11. Baseline evidence

Run the baseline probe. The owner and named collaborator can retrieve the document; an unrelated authenticated actor is denied; unauthenticated metadata retrieval is denied. Record the observations, not just the intended policy.

The baseline is positive evidence plus denied-path evidence. Both are required because a threat model that records only success hides the enforcement boundary.

12. Safe negative probe: unauthorized document read

The probe unauthorized_document_read uses only synthetic identities already in the fixture. Expected classification: AUTHORIZATION_DENIED.

The evidence supports only this bounded conclusion: the fixture rejected this undeclared reader under the current configuration. It does not establish production authorization correctness.

13. Boundary mutation: external storage

The probe external_storage_boundary_mutation moves the storage adapter outside the application-controlled trust zone. Expected classification: TRUST_BOUNDARY_CHANGED_REVIEW_REQUIRED.

This does not mean external storage is inherently unsafe. It means the old threat model is stale because a data flow now crosses a different trust boundary. Revisit confidentiality, integrity, service identity, transport assumptions, and the evidence that supports them.

14. Entry-point mutation: unauthenticated metadata

The probe unauthenticated_metadata_endpoint changes the synthetic metadata endpoint so authentication is no longer required. Expected classification: UNAUTHENTICATED_METADATA_EXPOSURE.

The important lesson is not an exploit technique. It is the modeling rule: a new or changed entry point invalidates the old actor/boundary assumptions and requires updated threat/control evidence.

15. Mutation: control name without evidence

The probe control_name_without_evidence_check keeps a control label but removes its verification step. Expected classification: CONTROL_UNVERIFIABLE.

This is a common review failure. A mitigation can be plausible and still be unreviewable if the team cannot say what observation would distinguish enforced behavior from a diagram-only promise.

16. Mutation: incomplete evidence record

The probe evidence_field_removed removes one required field from the record. Expected classification: EVIDENCE_INCOMPLETE.

The required fields force traceability. Omitting residual risk or owner decision needed can make a technically correct control look like complete risk closure when it is not.

17. Repair without erasing failure evidence

Repair means restoring the bounded invariant and rerunning the decisive probe. Keep the original negative observation. The before/after pair is stronger evidence than a final green result alone.

For example, after an external-storage boundary change, update the affected threat rows and define the new evidence checks. Do not pretend the previous model remained valid.

18. Residual risk and owner decision

After controls are proposed, write what remains uncertain. Example residual risk: this local fixture does not validate production identity configuration, storage-service policy, network controls, key handling, operational monitoring, or human approval.

Residual risk is not the same as formal acceptance. The artifact has an owner_decision_needed field precisely so the learner does not fabricate accountable approval.

19. Changed-context transfer

The independent transfer uses a synthetic appointment-sharing feature. Its actors and data sensitivity differ from document sharing. Rebuild only the rows implied by that feature’s own assets, entry points, data flows and boundaries.

Copying the document-sharing table without re-deriving the rows fails the transfer requirement.

20. Common shortcuts to reject

• A generic security checklist is a complete threat model.
• Every possible threat must be enumerated before development can continue.
• A threat model proves a system is secure.
• Threat modeling is a one-time document that never changes with system boundaries.

Each shortcut fails because it replaces bounded evidence with an unsupported conclusion.

21. Source and freshness boundary

The frozen source boundary contains one official OWASP Threat Modeling Cheat Sheet snapshot retrieved on 2026-09-02. It supports the current process framing: system modeling, threat identification, mitigations, and review/validation. The lesson does not treat one taxonomy as universally complete.

The frozen review date is 2026-10-02. Query 1 is executed on 2026-09-16, so no source recheck is due and the source scope is not expanded.

22. Completion checklist

A complete submission contains the bounded objective, assets, actors, entry points, data flows, trust boundaries, material threat scenarios, controls, evidence checks, at least one safe negative mutation, residual risk, and a changed-context decision. Observations remain distinct from inference, and the final learner decision is not prefilled.