Threat Modeling: Find Security Risk Before Writing Controls

Threat modeling is a structured way to ask what can go wrong in a design, why it matters, and what evidence would show that a response is adequate. It belongs before control selection because a catalog of controls cannot reveal whether the team misunderstood the system. The output is not a perfect forecast. It is a reviewable model of assets, boundaries, assumptions, attacker actions, and risk decisions.

Workshop brief

text

Asset -> Trust boundary -> Attacker action -> Weakness
      -> Business impact -> Mitigation -> Verification

This workshop chain is a completeness test: every mitigation must connect a plausible action to verification evidence.

Scenario: a team is redesigning account recovery for a multi-tenant business application.

Participants: a product owner who understands abuse and support impact; engineers who know data and control flow; operations staff who know identity, deployment, and failure behavior; privacy and security partners who can challenge assumptions.

Time box: ninety minutes for the first model, followed by owned investigation. A workshop should generate decisions and questions, not force false certainty before the room closes.

Scope: request recovery, issue a one-time capability, deliver it, change the authenticator, and invalidate prior sessions. Customer support override is a separate but connected flow. This decision-sized scope is large enough to reveal boundaries and small enough to reason about.

Exercise 1: name assets and impact

List what the flow must protect: account control, recovery destination, active sessions, tenant data, audit history, service availability, and user privacy. For each, describe the effect of lost confidentiality, integrity, availability, authenticity, or accountability. “Sensitive” is not an impact statement. “An attacker changes the recovery destination and obtains control of a finance administrator account” is.

Asset	Security property	Concrete harm
Recovery token	Confidentiality and single use	Account takeover
Destination record	Integrity	Recovery redirected to attacker
Active sessions	Revocability	Attacker remains after reset
Audit trail	Integrity	Response cannot reconstruct event
Recovery endpoint	Availability	Users locked out or support overloaded

The table prevents an early jump to “encrypt the token.” Encryption may help one exposure path, but it does not ensure single use, bind the token to an account, limit attempts, or revoke sessions.

Exercise 2: draw the actual flow

Mark trust boundaries wherever identity, privilege, administrative control, or data ownership changes. The message provider is external even if it has a trusted contract. The worker and API may share a cloud account yet run under different identities. The session service is a boundary because changing a password without revoking sessions may leave the attacker active.

Annotate protocols, identity, data classification, and persistence. Ask what happens when delivery is delayed, the queue duplicates a message, the identity store is partially unavailable, or the support tool uses an override. A clean diagram of only the successful path hides the conditions attackers exploit.

Diagram-as-code example

This is Mermaid-compatible text. Keep the source versioned with the design. Labels should expose authority and sensitive data without including production values. Review diffs when a new store, provider, protocol, or privileged path appears.

Exercise 3: write attacker stories

Use STRIDE or another prompt set for coverage, but phrase findings as actions and consequences. Examples:

An attacker enumerates registered accounts from response content or timing and targets known administrators.
A person with access to a forwarded mailbox replays an unexpired recovery link after the legitimate user has used it.
A compromised worker requests capabilities for arbitrary accounts because its identity has broad database authority.
An attacker exhausts message delivery or support capacity with automated requests.
A support operator changes a destination and suppresses the corresponding audit event.

Include preconditions. “Database compromise” is too broad to guide design. “A read-only analytics credential can read reusable recovery tokens stored in plaintext” identifies an authority and an attack step.

Structured threat record

threat: id: REC-04 action: "Replay a previously delivered recovery capability" preconditions:

"Attacker obtained the link"
"Capability remains valid after first use"

assets: ["account control", "active sessions"] impact: "high" uncertainty: "Delivery-provider link scanning behavior needs testing" owner: "identity-platform"

The uncertainty field is important. Automated mail scanners may follow links, while implementation behavior varies. The team should test the selected provider and design a confirmation step rather than assert unsupported behavior.

Exercise 4: identify vulnerabilities and controls

Separate threat, vulnerability, and impact. A threat is a potential adverse event. A vulnerability is the condition that permits it. Impact is the business harm. Public reachability creates exposure but is not automatically a vulnerability; a reusable bearer capability is. An unguessable identifier can reduce guessing but does not replace authorization or expiry.

Map a mitigation to the attack step it changes:

for each material_threat: validate preconditions with evidence choose response = avoid | reduce | transfer | accept map control to specific precondition assign implementation owner define verification test record residual risk and review trigger

For replay, store only a protected representation of a random capability, bind it to one account and purpose, set a short expiry, consume it atomically, invalidate competing recovery attempts, and revoke relevant sessions after successful reset. Do not claim that one measure eliminates takeover.

Atomic consumption pseudocode

begin transaction record = recovery_requests.lookup(hash(presented_token)) require record.purpose == "password-reset" require record.expires_at > now() require record.used_at is null update record set used_at = now() update account authenticator increment account security_epoch commit

The transaction prevents two simultaneous requests from both accepting the capability. The security epoch is one possible session-revocation mechanism: sessions carrying an older epoch are rejected. Actual data-store semantics and failure recovery require testing.

Exercise 5: prioritize without pretending precision

Use agreed likelihood and impact definitions, document uncertainty, and identify non-negotiable requirements regardless of score. A high-impact path with uncertain likelihood can justify discovery work or containment. A low-risk issue may be accepted with an owner and review trigger. Arithmetic does not make subjective inputs objective.

Decision	Required evidence	Verification
Prevent enumeration	Equivalent public response behavior	Timing and content tests
Limit automated abuse	Rate controls at account and network dimensions	Distributed abuse test
Make capability single-use	Atomic state transition	Concurrent replay test
Revoke attacker access	Session invalidation on reset	Old-session integration test
Protect audit history	Separate write authority and retention	Privileged misuse exercise

Controls become engineering work only when they have delivery points and tests. Put authorization and abuse tests in the feature backlog. For operational controls, name the signal, threshold rationale, responder, and runbook.

Exercise 6: challenge assumptions

Record assumptions such as “the identity provider validates redirect destinations exactly,” “the queue authenticates publishers,” or “support cannot edit audit events.” Verify important assumptions in official documentation, configuration, or tests. An inherited model with unverified assumptions can create more confidence than evidence warrants.

Threat modeling has limits. It can miss runtime misconfiguration, implementation defects, supplier changes, and novel abuse. It can become theater through elaborate diagrams, hundreds of unowned findings, and no tests. Pair it with secure coding, dependency governance, configuration review, testing, telemetry, and incident learning.

Workshop closeout checklist

Can every participant explain the protected business outcome?
Are assets and harms concrete rather than labeled only “sensitive”?
Does the flow include identity, administration, recovery, and failure paths?
Are trust boundaries based on authority and ownership, not cloud icons?
Is each threat an attacker action with preconditions and consequence?
Does every material mitigation break a named attack step?
Are uncertainty, owner, test, residual risk, and review trigger recorded?
Will architecture changes create a visible model-review task?

Close by reading the chain aloud: asset, boundary, attacker action, enabling condition, impact, response, owner, verification. If a link is missing, the item is not ready. That chain turns a threat workshop from speculative paperwork into a design feedback loop.

Workshop implementation backlog

Treat repeatable threat modeling as a product capability with an owner, an interface, and measurable failure behavior. Begin with one bounded production flow rather than a platform-wide rewrite. The accountable group should include product, engineering, security, privacy, and operations representatives. Write the user or business outcome first, then map the identities, data, policy decisions, dependencies, and recovery paths that influence it. Record assumptions that can become false as the environment changes.

Capture a baseline before changing controls. For this topic, useful baseline evidence includes modeled high-value flows, unresolved threats by impact, mitigation ownership, assumption age, and changes awaiting review. Baselines need dimensions, not only totals: environment, tenant, caller type, resource, model or policy version, and outcome often explain why an average moved. Protect telemetry from sensitive content, restrict access, and give high-cardinality data a deliberate retention period.

Implement the smallest vertical slice that can be evaluated end to end. Put configuration and policy under review, assign stable version identifiers, and make a rollback path available before broad exposure. Exercise both expected behavior and a missed boundary, incorrect assumption, control that does not break the attack path, or design change that bypasses the model. A release is not complete when the happy path succeeds; it is complete when operators can detect, contain, and recover from the credible failures.

For facilitated attacker-path analysis, each claim must connect to a workshop artifact and owned test. Start with offline tests and an isolated environment, move to internal or shadow traffic where appropriate, then expose a small production cohort with explicit stop conditions. Compare the new path with the baseline. Promote only when the evidence supports the intended benefit and no unacceptable regression is hidden in a subgroup. Use staged delivery.

Facilitator risk review

For facilitated attacker-path analysis, each claim must connect to a workshop artifact and owned test. Central services also concentrate availability and administrative risk. Define what happens when they are slow, unavailable, inconsistent, or compromised. Safe degradation is domain-specific: sometimes denying an action is correct; sometimes a bounded, auditable fallback prevents greater harm. No control described here establishes safety by itself. A technically correct mechanism can be undermined by stale ownership, excessive privilege, incomplete data, weak recovery, or an adjacent path that bypasses enforcement.

For facilitated attacker-path analysis, each claim must connect to a workshop artifact and owned test. High-impact exceptions should be discoverable in operations, not buried in a design document. Do not reduce the review to a single score. Track uncertainty and residual risk in plain language. Accepted risk needs an accountable owner, a reason, an expiration or review trigger, and evidence that the assumed conditions still hold.

For facilitated attacker-path analysis, each claim must connect to a workshop artifact and owned test. Privacy and security should shape observability. Record identifiers, versions, reason codes, timing, and outcome rather than raw credentials, private prompts, regulated records, or complete retrieved documents. Test redaction before telemetry leaves the process. Restrict debug modes and make temporary diagnostic access expire automatically.

Threat workshop closeout

Confirm ownership for the user outcome, production service, policy or model, data, and incident response.
Verify least privilege for human and workload identities, including administrative and emergency paths.
Test input limits, timeouts, retries, concurrency, idempotency, and cancellation under realistic load.
Exercise a missed boundary, incorrect assumption, control that does not break the attack path, or design change that bypasses the model and confirm that alerts identify the affected path and version.
Sample successful and denied or degraded outcomes; investigate by cohort rather than relying on averages.
Verify that logs, traces, evaluation sets, caches, and support bundles exclude unnecessary sensitive data.
Test rollback, revocation, restore, and dependency outage procedures on a schedule.
Revisit the design after material architecture, supplier, data, threat, or policy changes.

Workshop conclusion

The durable outcome is not a diagram or a purchased feature. It is a reviewable production loop: define the decision, constrain authority, preserve useful evidence, test failure, and adjust from observed results. For repeatable threat modeling, success should be demonstrated through reviewed flow diagrams, traceable decisions, abuse-case tests, closed mitigation records, and model-change history. That evidence lets engineering, security, product, and operations discuss the same system without pretending uncertainty has disappeared.

Continue with Secrets Management: Keeping Credentials Out of Code and Logs and browse the Prime Axiom resource library for related implementation material.

Threat modeling references

For facilitated attacker-path analysis, each claim must connect to a workshop artifact and owned test. The architecture, examples, and recommendations in this article are original synthesis for practical engineering use. These sources are included for standards, risk frameworks, and vendor-supported behavior.

Cybersecurity Threat Modeling Secure Design Prime Axiom Insights

Threat Modeling: Find Security Risk Before Writing Controls

Workshop brief

Exercise 1: name assets and impact