Threat Scenario Template

The Customer Export Service authenticates every caller and keeps its archive bucket private. Neither fact answers the question that matters: can an administrator from one tenant cause a worker to build another tenant’s archive and then obtain it through the application’s authorized download path?

“Broken access control” does not answer it either. It names a family of failures without locating this one. An engineer cannot derive a denial test from the label, a defender cannot decide which event should page, and an incident responder cannot tell whether stopping downloads would contain the attack.

A threat scenario makes the path specific enough to resist. It follows an attacker from a real foothold, through interfaces and trust boundaries, to an asset and consequence. It then follows the defense through prevention, proof, observation, response, ownership, and the risk left behind.

Start with the path

Write a scenario when an architecture or feature creates a consequential attacker path, when an incident exposes a path the model missed, or when detection, red-team, release, or risk-acceptance work needs a common statement of the threat. Do not create one merely to give every item in a risk taxonomy a document.

Begin with access and action. Name an attacker by the capability or position that makes the path plausible: an authenticated user in another tenant, a compromised workload identity, a malicious integration, or an administrator with production access. “Hacker” supplies no useful constraint.

Then write the path as an ordered attempt through real interfaces. Name where policy must hold. For the export service, the important boundary is not simply “the network.” Tenant context crosses from an authenticated API request into a queued job, and archive identity later crosses into the download authorization decision. Those transitions expose where untrusted identifiers can acquire authority.

Finish the attacker half by naming the asset and a credible consequence. “Customer records from another tenant are disclosed” can drive controls and escalation. “Confidentiality is affected” cannot. Record any access, configuration, timing, or failure that the attack requires; preconditions keep a conceivable path from masquerading as an equally likely one.

Carry the same path into engineering work

Existing controls are implemented claims with evidence, not security features that happen to be nearby. Authentication proves who submitted an export request; it does not prove that the caller may name the requested tenant. A private bucket blocks anonymous access; it does not protect an archive delivered through a confused application.

Required controls should interrupt a named step or reduce its consequence. Attach requirement-catalog or architecture-decision IDs when they exist, and identify the enforcement point. “Harden authorization” hides the decision. “Derive tenant context from the authenticated subject before enqueue and reject a worker envelope whose tenant signature fails” tells an implementer where denial belongs.

Verification must be capable of contradicting the control claim. Change the subject, tenant, archive, action, and queued context independently and expect denial at the intended boundary. Attribute the result to the reviewed build or deployed version. An approval, an undated test folder, or a successful happy path is not evidence that the attacker path is closed.

Detection and response cover the path that prevention misses. Name an event with enough context to distinguish an attempt, the route by which it reaches an owner, and the first containment decision. “Logs exist” is weaker than “subject/job tenant mismatch pages Product Security with actor, tenant, job, policy result, and release version.” “Investigate” is weaker than deciding whether to pause new exports while preserving API, queue, worker, and object-access evidence.

Finally, name the accountable owner, due condition, and residual risk. Controls reduce the scenario; they do not erase it. If a legitimate tenant administrator may still misuse authorized exports, state that bounded risk and the measures that limit it. Reopen the scenario when one of its assumptions, interfaces, identities, controls, or consequences changes.

The working template

The headings preserve the trace from attacker intent to operational ownership. Omit a field only when it truly does not apply, not because the answer is inconvenient.

# Threat Scenario: <short path and consequence>

## Identity and scope
- Scenario ID and status:
- System or workflow:
- Accountable owner:
- Review trigger or due condition:
- Related profile, decision, requirement, exception, and incident IDs:

## Attacker path
- Asset at risk:
- Attacker capability and starting access:
- Entry point:
- Trust boundaries and policy-enforcement points crossed:
- Ordered attack path:
- Preconditions and assumptions:
- Consequence if successful:

## Prevention and proof
- Existing controls, with evidence:
- Required controls, with owner and due condition:
- Verification that can show failure:

## Observation and response
- Signals of attempt or success:
- Monitoring and routing owner:
- First containment decision:
- Evidence to preserve and recovery path:

## Residual risk
- Risk remaining after controls:
- Risk owner and active acceptance or exception:

Status is useful when it has a defined meaning such as proposed, active, mitigated, accepted, or retired. Retirement requires evidence that the path or asset no longer exists; a closed implementation task is not enough.

Follow one scenario from request to response

The completed record below continues the Customer Export Service profile from the previous appendix. Its path is narrow enough to test but broad enough to expose a second enforcement point after the API.

# Threat Scenario: Cross-tenant archive disclosure

## Identity and scope
- Scenario ID and status: TS-AUTHZ-EXPORT-002; active
- System or workflow: Customer Export Service, from request through download
- Accountable owner: Customer Data Platform service owner
- Review trigger or due condition: review before public release and whenever
  tenant hierarchy, job-envelope format, archive delivery, or delegated export
  access changes
- Related records: SSP-EXPORT-007; SADR-AUTHZ-EXPORT-003;
  AUTHZ-EXPORT-004; DATA-EXPORT-002; LOG-AUTHZ-003

## Attacker path
- Asset at risk: tenant-scoped customer records in export archives
- Attacker capability and starting access: authenticated account administrator
  in tenant A who can create and download exports for tenant A
- Entry point: export request API accepting a request-supplied tenant ID
- Trust boundaries and enforcement points crossed: authenticated subject to
  Export API authorization; API to signed queue envelope; worker to archive
  bucket; administrator and archive ID to download authorization
- Ordered attack path: replace tenant A's ID with tenant B's ID; cause the API
  to enqueue that value; let the worker build tenant B's archive under an ID
  visible to tenant A; request a download URL for the archive; retrieve it
  before expiry
- Preconditions and assumptions: the API trusts a body tenant ID, the worker
  trusts the queued context, or the download path checks role without checking
  archive ownership; the attacker can observe or predict the resulting archive
  ID
- Consequence if successful: disclosure of tenant B's regulated customer data

## Prevention and proof
- Existing controls, with evidence: company identity provider authenticates the
  caller; the object bucket denies public access; export actions produce audit
  events. These controls constrain access but do not establish tenant ownership.
- Required controls, with owner and due condition: the API owner must derive
  tenant context from the authenticated subject and enforce AUTHZ-EXPORT-004
  before enqueue; the worker owner must verify the signed tenant envelope; the
  download owner must authorize subject, action, archive, and tenant before
  issuing a five-minute single-object URL. All are release conditions.
- Verification that can show failure: suite `export-tenant-boundary` changes
  subject, tenant, action, archive ID, and queued tenant context independently;
  expects denial at the named enforcement point; verifies that denied attempts
  create tenant-safe audit events; and is attributed to the release under review

## Observation and response
- Signals of attempt or success: repeated cross-tenant denials, subject/job
  tenant mismatch, authorization success followed by object-owner mismatch,
  unusual export volume, or archive access by an unexpected actor
- Monitoring and routing owner: the audit platform routes correlated events to
  Product Security on-call and the Customer Data Platform service owner
- First containment decision: decide whether to disable new export creation and
  downloads globally or for affected tenants while preserving evidence
- Evidence to preserve and recovery path: preserve request, policy-decision,
  queue-envelope, worker, object-access, and deployed-version records; expire
  exposed URLs; identify and delete unauthorized archives; restore export only
  after the fixed path and detection have been exercised

## Residual risk
- Risk remaining after controls: a compromised legitimate administrator can
  export records that the role is authorized to access
- Risk owner and active acceptance or exception: Customer Data Platform risk
  owner; bounded by MFA, attributable audit events, volume detection, a
  four-hour archive lifetime, and customer incident procedures; no exception
  permits cross-tenant access

The record does not pretend that the private bucket is irrelevant. It assigns that control its actual job and refuses to let it stand in for application authorization. It also makes a successful test insufficient on its own: the denial event must be observable, routed, and usable during containment.

Review the trace, not the form

Read the scenario in both directions. From the attacker side, each step should name a real interface, required condition, and boundary. From the engineering side, each required control should interrupt a step, each verification should be able to fail that control, and each signal should lead to an owned decision.

Challenge vague fields with concrete questions. Which account does the attacker already control? Who supplies the tenant identifier? At which call is object ownership enforced? What event distinguishes probing from ordinary denial? What can responders stop without destroying the evidence they need? The answers may reveal a missing control, but they may also reveal that the scenario combines several paths and should be split.

A high-priority scenario should result in linked work: a requirement, architecture condition, implementation task, negative test, detection specification, response step, or explicit risk decision. If it changes nothing, either existing evidence already covers the path and should be linked, or the scenario is still too vague to govern engineering.

The scenario is ready when an engineer can write a failing test from it, a reviewer can locate the enforcement points and evidence, a defender can route its signals, an incident lead can make the first containment decision, and a risk owner can understand what remains.