Threat modeling: turn architecture into security decisions

Threat modeling asks what could go wrong in a particular system and what the team should do about it. Its useful output is not a catalogue of frightening possibilities. It is a set of design and implementation decisions tied to the architecture, with owners and evidence that the chosen defenses work.

For a CTO, the central question is whether engineering can explain how important security properties survive real system behavior: retries, background jobs, privileged support actions, supplier outages, and malicious input. A diagram makes those conversations concrete. A maintained threat model turns the conclusions into delivery work.

OWASP’s threat-modeling guidance provides a useful foundation: understand the system, identify threats, decide how to respond, and assess whether the work is sufficient. The workflow below applies that thinking to engineering decisions.

Describe the system before discussing attacks

Start with a bounded capability, such as customer exports, payment initiation, or device updates. Modeling an entire platform at once often produces shallow observations because nobody can explain every dependency in enough detail.

State the assets and security goals in operational terms. “Protect customer data” is too broad. “An authenticated user can export only records belonging to their authorized tenant” gives the team a property to test. Other goals might concern transaction integrity, service availability, recovery, or attribution of administrative actions.

Identify users, services, data stores, external dependencies, entry points, and trust boundaries. Draw the important data flows, including asynchronous processing and administrative paths. Label flows with the data carried, authentication mechanism, and authorization context where these affect the analysis.

A trust boundary marks a change in assumptions or authority, not necessarily a network perimeter. A browser calling an API crosses one boundary. A shared worker acting on behalf of a customer crosses another, even if both services run in the same cluster.

For a multi-tenant application, show where tenant identity is established and how it reaches authorization checks, background jobs, and exports. Include service identities, object storage access, support tools, and external callbacks. Otherwise, the diagram may describe the happy path while omitting the paths most likely to bypass isolation.

Record assumptions separately from facts. “The queue cannot be written by customers” needs supporting configuration evidence. Unknowns should become investigation tasks, not silently accepted defenses.

Choose a method that helps the team reason

A method supplies prompts and structure. It does not determine which threats matter most, prove that a design is secure, or replace knowledge of the system.

STRIDE for systematic prompts

STRIDE examines six categories. Apply them to relevant components, flows, and boundaries rather than forcing every category onto every diagram element.

One scenario may span several categories. Keep a single actionable record where appropriate rather than creating duplicate tickets to satisfy the taxonomy.

Other methods for different questions

PASTA, the Process for Attack Simulation and Threat Analysis, offers a seven-stage, risk-oriented approach connecting business objectives, technical scope, decomposition, threat and vulnerability analysis, attack modeling, and risk treatment. It suits deeper analysis where attacker behavior and business consequences need explicit attention.

Attack trees start with an attacker goal and break it into alternative or combined routes. For “obtain another tenant’s export,” alternatives might include bypassing API authorization, confusing the worker’s tenant context, or stealing a download credential. AND relationships represent conditions that must occur together; OR relationships represent alternatives.

VAST, Visual, Agile, and Simple Threat modeling, emphasizes scalable modeling across application and operational perspectives. Teams considering it should examine whether their tooling and development process can maintain those views consistently.

A practical starting recommendation is a data-flow diagram plus STRIDE, followed by an attack tree for the most consequential scenario. More methodology is useful only when it improves decisions.

Run the review around concrete scenarios

Bring the people who understand implementation and operation: a developer, an architect or technical lead, a security reviewer, and someone familiar with production behavior. Include product, privacy, or supplier specialists when their knowledge affects the scope.

Before the session, circulate the diagram, security goals, relevant configuration, and unresolved assumptions. During the review, walk one request or event from entry to completion. Ask where identity changes, where data persists, what gets retried, and which component has authority to approve an action.

Write threats as scenarios, not labels. “Authorization issue” is not useful enough. A stronger statement is: “An authenticated user substitutes another tenant’s export identifier; the download endpoint checks login but not object ownership, exposing customer records.”

Separate three concepts:

• A threat describes an adverse action or event, such as unauthorized export retrieval.
• A vulnerability is a weakness that could enable it, such as a missing ownership check.
• Risk considers the scenario’s likelihood and consequence in the actual environment.

A threat can be worth investigating before a vulnerability is confirmed. Equally, finding a weakness does not establish that every imaginable attack is feasible.

Include misuse by legitimate users, privileged insiders, configuration errors, and supplier failures alongside external attacks. Ask what happens when a dependency times out or returns an unexpected response. Fail-open behavior and inconsistent retries often emerge from these discussions.

Worked example: a multi-tenant export pipeline

The following example is illustrative. Assume a SaaS application has a browser client, an API, a shared database, a job queue, an export worker, and object storage. Tenant users request CSV exports; the worker generates files, and the API issues temporary download links. Support administrators have a separate troubleshooting interface.

The security goals are tenant isolation, authorized export initiation, bounded resource consumption, and attributable support actions. Assume the worker has database access broad enough to serve multiple tenants. That makes its handling of tenant context a central decision rather than a minor implementation detail.

Trace authority through the flow

At the API, the authenticated principal is associated with permitted tenant membership. A tenant identifier supplied by the browser is a selection request, not proof of authorization. The API checks membership and export permission before creating an immutable job record containing the authorized tenant, requester, and permitted export scope.

The queue message references that record. The worker validates the job and enforces tenant-scoped data access when producing the export. Storage metadata associates the resulting object with the job and tenant. Before issuing a download link, the API checks the current requester’s authorization against that association.

This design still needs explicit decisions about access revocation: should a user who loses membership after requesting an export retain access to the completed file? The team must define that policy and implement it consistently.

Convert scenarios into controls and tests

Temporary links introduce a residual exposure window: possession may permit access until expiry, depending on the mechanism. The team should decide whether that is acceptable for the data involved or whether downloads need an authenticated intermediary with current authorization checks.

Do not close the model after testing the synchronous API alone. Verify delayed jobs, retries, cancelled requests, expired membership, deleted tenants, and partial failures. For example, a retried job must not reuse an object associated with a different tenant or publish an incomplete export as successful.

The resulting deliverable is a reviewed architecture, a threat register, implementation tasks, and linked verification results. It is not merely the diagram.

Prioritize using exposure and consequences

Prioritize plausible scenarios using exposure, impact, preconditions, and existing defenses. Distinguish a directly reachable authorization failure from a scenario requiring several unproven compromises. Consider affected data, service disruption, financial consequences, safety implications, and recovery difficulty where relevant.

Use a simple consistent scale if it helps the team, but record the rationale behind the rating. A numerical score with unexplained inputs creates false precision. CVSS can inform assessment of a concrete vulnerability; it is not a substitute for understanding business impact or an architectural abuse case.

Treatment choices include changing the design, reducing exposure, adding preventive or detective controls, avoiding the capability, or accepting the remaining risk. Supplier contracts may allocate responsibilities, but they do not remove technical failure modes.

Residual risk should have a named decision-maker, a reason, an expiry or review trigger, and any operating conditions. Engineering completion and risk acceptance are different decisions. A ticket can be finished while meaningful risk remains.

Carry the model into delivery and evidence

For each material scenario, record its identifier, affected components, preconditions, consequence, existing defenses, treatment, owner, and verification method. Link the record to the architecture version and relevant implementation work so reviewers can tell which design was assessed.

Translate treatments into testable acceptance criteria. “Improve access control” is vague. “Tenant A cannot request, poll, cancel, or download Tenant B’s export through any supported endpoint” identifies behavior that engineering can verify.

Use evidence appropriate to the claim:

• Code review can establish where authorization is enforced.
• Configuration inspection can establish service permissions and storage exposure.
• Negative integration tests can exercise cross-tenant and privilege boundaries.
• Load and fault-injection tests can examine availability and failure behavior.
• Targeted penetration testing can investigate attack paths that need independent exploration.

No single artifact proves the whole model. A screenshot of a setting does not prove every worker uses it, and a passing test does not demonstrate an untested path. Record test environment, scope, results, and limitations.

Threat modeling complements secure coding, dependency assessment, vulnerability scanning, and penetration testing. Its distinctive contribution is architectural reasoning: it can reveal a dangerous allocation of authority even when individual components have no known vulnerability.

Keep tooling and automation subordinate to the model

A shared diagram and a structured register can support a focused first review. Dedicated tools become useful when teams need reusable component libraries, consistent identifiers, collaboration, and reliable links between threats and delivery records.

Evaluate whether a tool supports trust boundaries, custom scenarios, version history, exportable records, ownership, and evidence references. Automatically generated threats are prompts to examine, not confirmed findings. Long lists without context can hide the few decisions that matter.

AI assistance can draft scenario descriptions, suggest missing paths, or compare changes against an earlier model. Human reviewers still need to validate architecture, feasibility, mitigation coverage, and residual risk. Keep confidential diagrams and credentials out of unapproved services. Threat-model generation is also distinct from runtime detection; producing a model does not establish continuous monitoring or automated remediation.

Review when the architecture or assumptions change

Update the model for new integrations, authentication changes, privileged actions, data categories, network exposure, and major dependency changes. An incident or unexpected test result can also invalidate an earlier assumption.

Different systems need different emphasis. Cloud applications require attention to identity permissions and management-plane access. Mobile clients should be treated as attacker-controlled environments rather than trusted enforcement points. Connected devices introduce physical access, update integrity, recovery, and potentially safety consequences. AI-enabled features add untrusted content and tool-use boundaries; authorization must constrain actions regardless of model output.

Measure whether important flows have current models, high-priority treatments have verification evidence, assumptions remain unresolved, and accepted risks have overdue reviews. Counting threats alone rewards volume rather than useful analysis. Periodically ask an independent reviewer to challenge one critical scenario and its evidence.

Make the first review small enough to finish

Secani can preserve the workflow around these decisions by modeling relevant systems and dependencies, assigning owners and reviewers, and connecting evidence to requirements, controls, and decisions. Unresolved assumptions become tasks; source material and human approvals remain attached to the review. Any AI-assisted suggestions should be checked before approval.

Start with one critical data flow. Trace its authority end to end, identify a handful of plausible scenarios, and finish with owned treatments and explicit verification criteria. Schedule the next review around the architecture changes that could invalidate those decisions.