FreeExam
A closed notebook, a blank card, and a pencil on a wooden desk.

Threat modeling

50 cards

Model assets and trust boundaries, reason through abuse cases, and turn risks into verifiable design changes.

Card 1 of 50

Front. Scope. What defines a useful threat-model scope?

These cards are original study material. They are not questions from a named employer or a live hiring loop.

All 50 cards in this deck

  1. 1.Scope

    What defines a useful threat-model scope?

    A specific system or change, its users, deployment context, sensitive assets, and interfaces. State exclusions and dependencies so omitted components are visible assumptions rather than accidental blind spots.

  2. 2.Security Objective

    How do you make a security objective testable?

    Express an invariant, such as 'a tenant cannot read another tenant's exports' or 'a transfer requires authorized approval.' Broad goals like 'secure the API' do not identify what must be protected or verified.

  3. 3.Asset

    Why include capabilities as assets, not only stored data?

    The ability to deploy code, approve payments, issue identities, or consume compute can be abused without stealing a database. Identify integrity and availability consequences alongside confidentiality.

  4. 4.Actor

    What makes an attacker description useful?

    Capabilities, starting access, incentives, and constraints relevant to the system. Distinguish an unauthenticated visitor, malicious tenant, compromised employee session, and compromised dependency instead of assuming one all-powerful attacker.

  5. 5.Entry Point

    Which entry points are often missed when reviewing only public APIs?

    Webhooks, imports, message consumers, admin tools, scheduled jobs, build pipelines, support workflows, and restore procedures. Trace how each accepts data or authority, including inputs that arrive asynchronously.

  6. 6.Data Flow

    What should a data-flow diagram show for security review?

    External entities, processes, data stores, flows, and trust boundaries, annotated with identities and sensitive data. It should make crossings and enforcement points visible rather than merely list service names.

  7. 7.Trust Boundary

    Why can a boundary exist between two services owned by the same company?

    They may run with different privileges, owners, tenants, or compromise assumptions. Organizational ownership does not imply equal trust; verify identity and authorization when authority crosses between components.

  8. 8.Assumption

    How should an assumption such as 'only employees can access this tool' be recorded?

    Name the enforcement mechanism, evidence, owner, and consequence if it fails. A network diagram or undocumented convention is not proof that external access is impossible.

  9. 9.Stride

    What does STRIDE provide in a threat-model discussion?

    Prompts for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It helps generate questions, but does not by itself rank risks or establish that all threats were found.

  10. 10.Spoofing

    A webhook carries a customer ID in JSON. What spoofing question should be asked?

    How the receiver verifies the sender and binds the payload to an authorized customer. A plausible ID or source-IP check alone may not prove origin or payload integrity.

  11. 11.Tampering

    Where should integrity be checked for a file processed later by a worker?

    At the point where the worker consumes the intended version, with trusted metadata or protected storage binding. Checking an upload once is insufficient if the object can be replaced before processing.

  12. 12.Repudiation

    What evidence supports accountability for a sensitive admin action?

    Authenticated actor and delegation context, target, action, decision, time, and outcome in protected audit records. Shared accounts and editable logs weaken attribution even if an application log says the operation succeeded.

  13. 13.Disclosure

    Why review errors, logs, and metrics as data-exposure paths?

    They can copy secrets or sensitive records outside the primary access controls. Trace who can read each destination and its retention, including support tools and third-party telemetry.

  14. 14.Dos

    What distinguishes an expensive-request threat from ordinary traffic volume?

    One valid-looking request may trigger disproportionate CPU, memory, fan-out, or paid API work. Bound work by query complexity, input size, concurrency, deadlines, and tenant budgets, not only requests per second.

  15. 15.Escalation

    How can a low-privilege configuration edit become code execution with higher privileges?

    A privileged worker may later interpret the configuration as a command, plugin, template, or credential reference. Follow the data to its eventual consumer and assess the consumer's authority.

  16. 16.Attack Tree

    What is an attack tree useful for?

    Breaking an attacker goal into alternative or combined prerequisite steps. It exposes where controls interrupt a path, but its completeness depends on the modeled branches and assumptions.

  17. 17.Abuse Case

    How does an abuse case differ from a functional user story?

    It describes an adversarial goal and how intended features could be misused, such as repeatedly claiming a promotion or exporting another tenant's records. Include prerequisites, observable effects, and expected prevention or detection.

  18. 18.Business Logic

    Why can a business-logic flaw survive input validation?

    Every individual value and request may be valid while the sequence violates a business invariant. Test allowed transitions, ownership, cumulative limits, and concurrent operations rather than only malformed strings.

  19. 19.State Machine

    How does a state-machine model help review a refund flow?

    It makes allowed transitions explicit, including cancellation, retry, and partial completion. Check that refund amounts and counts remain valid across every path, not just the normal paid-to-refunded transition.

  20. 20.Replay

    What question should be asked about a signed request that can be submitted twice?

    Whether replay causes an additional effect. A signature proves integrity and origin under its key assumptions, not freshness or uniqueness; use bounded timestamps/nonces and idempotent operation records where appropriate.

  21. 21.Race

    Two valid withdrawals arrive simultaneously. What threat must be modeled?

    Both may pass a balance check before either commits. Enforce the balance invariant atomically through a suitable transaction, lock, or conditional update, and test concurrent execution rather than only serial requests.

  22. 22.Canonicalization

    Why should validation and execution agree on representation?

    Different decoding, path normalization, Unicode handling, or parser rules can make a checked string mean something else downstream. Normalize deliberately and avoid security decisions based on a different parser than the final consumer.

  23. 23.Parser Boundary

    A gateway and backend parse HTTP differently. What risk follows?

    Ambiguous framing or interpretation can make them disagree about request boundaries or routing. Use consistent, strict protocol handling and test the actual proxy/backend combination rather than relying on either component alone.

  24. 24.Multi Tenant

    What should a tenant-isolation threat model trace beyond database queries?

    Cache keys, object paths, search indexes, queues, logs, exports, background jobs, and administrator workflows. A tenant filter in one API handler does not protect every derived copy or asynchronous path.

  25. 25.Cache Poison

    What makes a shared cache a security-sensitive component?

    An attacker may influence a response stored under a key later served to another user. Match cache keys and variation to authentication and representation context, and avoid caching private output in shared entries.

  26. 26.Signed Link

    How should a threat model treat a shareable download link?

    As a capability whose possession may grant access. Model forwarding, referrer leakage, logs, expiration, revocation, and whether the capability is scoped to a single object or broader collection.

  27. 27.Third Party

    What changes when a vendor processes customer documents?

    Data and control cross an organizational boundary. Evaluate access, retention, subprocessors, deletion, incident visibility, and service failure behavior; outsourcing processing does not remove responsibility for the product's data flow.

  28. 28.Supply Chain

    Which trust transitions belong in a software supply-chain model?

    Source contribution, dependency resolution, build execution, artifact storage, signing, promotion, and deployment. Ask who can change each input and whether the deployed digest is bound to the reviewed source and trusted build.

  29. 29.Admin Plane

    Why model the administrative plane separately from the user data plane?

    Admin paths often bypass ordinary limits and can change policies, identities, or all tenants' data. Their authentication, authorization, audit, and recovery requirements may be much stronger than normal user operations.

  30. 30.Backup Path

    Why include backup and restore in a threat model?

    Backups duplicate sensitive data and restore can reintroduce deleted accounts, vulnerable code, or revoked credentials. Model backup access, destruction, key availability, and post-restore reconciliation.

  31. 31.Prompt Injection

    What trust-boundary failure does indirect prompt injection exploit?

    Untrusted retrieved or tool-provided content is interpreted as authority to change an agent's instructions or actions. Separate data from authorization, constrain tools, and enforce sensitive decisions outside model-generated text.

  32. 32.Agent Tools

    Why is an agent's tool permission more important than whether its prompt says 'be safe'?

    The model may misinterpret or follow hostile input. Limit accessible resources and actions in the runtime, validate arguments and authority, and bind any approval to the exact proposed effect.

  33. 33.Output Consumer

    Why inspect how generated output is consumed downstream?

    Text may later become HTML, SQL, a shell command, or a workflow decision. Treat output according to the destination's trust and encoding rules; generation does not sanitize it for execution.

  34. 34.Privacy

    How does a privacy threat differ from unauthorized access alone?

    An authorized system can collect, link, infer, or retain more personal information than the purpose requires. Model data minimization, user expectations, access purpose, and retention in addition to attacker intrusion.

  35. 35.Likelihood

    What evidence informs likelihood without pretending to know an exact probability?

    Reachability, prerequisites, attacker capability, exposed population, existing exploitation, and control strength. Use calibrated categories or scenarios and record uncertainty instead of multiplying arbitrary numbers into false precision.

  36. 36.Impact

    How should impact be estimated for a data-export threat?

    Consider data sensitivity, number of affected users, exposure duration, downstream misuse, recovery, and operational consequences. A record count alone can understate a small but highly sensitive leak.

  37. 37.Attack Path

    Why prioritize a connected attack path over isolated findings?

    Several moderate weaknesses may combine into a severe outcome, while a high-scoring flaw may be unreachable in the deployed architecture. Trace prerequisites and effects to select controls that break the meaningful path.

  38. 38.Mitigation Choice

    How do you compare prevention, detection, and recovery controls?

    Assess whether they block the path, reveal it in time, or limit consequences after it occurs. A logging control does not prevent a transfer, and a preventive control still needs monitoring for bypass or failure.

  39. 39.Defense Depth

    When do two controls fail to provide independent defense in depth?

    When they share the same identity, configuration, parser, or administrative failure mode. Analyze correlated bypasses; two checks calling the same misconfigured policy service may be one effective boundary.

  40. 40.Residual Risk

    What must be explicit when accepting residual risk?

    The remaining scenario, impact, rationale, compensating controls, accountable decision-maker, and review or expiry condition. A closed ticket without ownership or conditions is not a durable risk decision.

  41. 41.Control Owner

    Why give each mitigation a named owner and verification criterion?

    Otherwise a threat model can describe intended protection that never reaches production. Link the control to a test or evidence source and define who maintains it when the design changes.

  42. 42.Security Test

    How do you turn 'cross-tenant exports are forbidden' into a test?

    Create two tenants with distinct records, attempt export using the other tenant's IDs through every relevant path, and assert both denial and no generated artifact or queued side effect.

  43. 43.Negative Evidence

    What does failure to reproduce a threat establish?

    Only that the attempted path did not succeed under the tested conditions. Record coverage and remaining assumptions; a failed proof of concept is not evidence that all variants or deployments are safe.

  44. 44.Prototype Review

    When should threat modeling happen during design?

    Early enough to change boundaries and architecture, then again when implementation or deployment reveals new details. A lightweight initial model can be refined; waiting until launch makes structural mitigations expensive.

  45. 45.Change Trigger

    Which changes should trigger a threat-model update?

    New trust boundaries, identities, data types, external integrations, privileged actions, or deployment exposure. A routine refactor may need only a focused check, while a small-looking permission change can require substantial review.

  46. 46.Facilitation

    Who should contribute to a useful threat-model session?

    People who understand product intent, architecture, operations, identity, and relevant abuse. Include security expertise without making one security reviewer responsible for inventing every system assumption.

  47. 47.Artifact

    What should remain after the threat-model meeting?

    A scoped diagram, assets and invariants, assumptions, prioritized scenarios, control decisions, owners, and verification links. Preserve unresolved questions; meeting attendance alone is not an actionable artifact.

  48. 48.Attack Framework

    How should MITRE ATT&CK inform a review?

    Use its behavior taxonomy to consider plausible adversary actions and detection coverage. It is not a complete application-specific threat model or proof that checking every technique secures the system.

  49. 49.Control Failure

    Why model what happens when a control is unavailable?

    Policy engines, identity providers, key services, and scanners can fail. Define fail-open or fail-closed behavior per operation, bounded fallback, and recovery so availability fixes do not silently bypass critical authorization.

  50. 50.Review Complete

    When is a threat-model review ready to support a release decision?

    Material threats have a documented disposition, required controls have evidence, and remaining risks and assumptions have accountable owners. Completion means a reviewable decision, not a claim that no threats remain.