Threat Intelligence & Detection / Decision Guide

Design-Time Architecture Threat Modeling

Design-time threat modeling evaluates software architecture, component trust boundaries, data flows, and security invariants during system design and continuous development iterations. Rather than reacting to post-deployment intrusions, engineering teams apply design-time frameworks—most heavily during design reviews and sprint planning—to identify misuse cases, threat vectors, and architectural refactoring requirements before code is deployed.

Design-Time Architecture Threat Modeling: STRIDE DFD Mapping ↔ PASTA 7-Stage Risk Alignment ↔ OWASP 4-Question Engine ↔ VAST / OCTAVE Allegro Integration

Framework Overview & Selection Criteria

Engineering teams select design-time threat modeling frameworks based on system architecture complexity, development cadence, risk governance requirements, and organizational maturity.

The five entries below do not all operate at the same altitude. STRIDE, PASTA, the OWASP questions, and VAST evaluate a system — components, data flows, and trust boundaries on a Data Flow Diagram. OCTAVE Allegro evaluates an organization’s information assets and the containers that hold them; it is normally paired with a system-level method rather than used instead of one. Trust Boundaries & Threat Modeling covers DFD construction and boundary identification, which every method in this table assumes as an input.

Deep Dive: Microsoft STRIDE Threat Taxonomy & DFD Matrix

Developed at Microsoft, STRIDE is a threat categorization taxonomy that evaluates six discrete threat categories against Data Flow Diagram (DFD) components. STRIDE itself does not mandate specific mitigations—control selection is a context-dependent engineering choice based on system constraints.

STRIDE-per-Element DFD Applicability Matrix

When evaluating a System Data Flow Diagram (DFD), apply threat categories based on the component element type:

* Repudiation applies to a data store when that store holds the audit or log records that would otherwise establish accountability. A store holding only business data is not itself a repudiation target.

Deep Dive: PASTA 7-Stage Risk-Centric Process

The Process for Attack Simulation and Threat Analysis (PASTA) is a 7-stage risk-centric framework designed to align technical threat modeling with enterprise business impact and threat intelligence:

1. Stage 1: Define Objectives — Document business objectives, compliance mandates (PCI DSS, HIPAA, SOC 2), and security SLAs.
2. Stage 2: Define Technical Scope — Map infrastructure components, network boundaries, software dependencies, and API endpoints.
3. Stage 3: Application Decomposition — Deconstruct application architecture using DFDs, identifying trust boundaries and asset locations.
4. Stage 4: Threat Analysis — Ingest threat intelligence, identify adversary motivations, and construct threat scenarios relevant to the architecture.
5. Stage 5: Vulnerability & Flaw Analysis — Review CVE/CWE databases, static code analysis (SAST) findings, and design flaws.
6. Stage 6: Attack Modeling — Construct attack trees and simulate exploit paths to measure attack feasibility and probability.
7. Stage 7: Risk & Impact Analysis — Score residual risk (Likelihood × Impact) and select countermeasures to mitigate business loss.

Deep Dive: OWASP 4-Question Practical Execution

The OWASP 4-Question Framework acts as a lightweight, continuous meta-process for Agile software development teams:

OWASP 4-Question Framework: What are we working on? → What can go wrong? → What are we going to do about it? → Did we do a good job?

• Question 1: What are we working on? — Deconstruct the feature or service using a visual Data Flow Diagram (DFD) or architecture diagram showing inputs, outputs, processes, stores, and trust boundaries.
• Question 2: What can go wrong? — Brainstorm misuse cases and vulnerabilities using STRIDE or threat modeling workshops.
• Question 3: What are we going to do about it? — Translate identified threats into actionable security controls and track them as sprint user stories in the development backlog.
• Question 4: Did we do a good job? — Validate that controls are implemented through peer reviews, automated unit/integration tests, and retrospective threat model updates.

Deep Dive: VAST & OCTAVE Allegro Frameworks

VAST (Visual, Agile, and Simple Threat Modeling)

VAST is a vendor-originated methodology associated with ThreatModeler Inc. It has no open published specification, so the description below reflects its documented positioning rather than a standard that can be independently verified clause by clause. VAST divides threat modeling into two complementary views:

• Application Threat Models: Focuses on architectural components, data flows, and code vulnerabilities (for developers).
• Operational Threat Models: Focuses on infrastructure, deployment environments, and network trust boundaries (for operations/sysadmins).

It is designed to integrate with CI/CD storyboarding so that threat model updates are triggered when architectural changes occur, rather than only at scheduled review points.

OCTAVE Allegro (CMU SEI)

Developed at Carnegie Mellon University, OCTAVE Allegro (CMU/SEI-2007-TR-012) focuses on information asset risk governance through 8 steps organized into 4 phases:

• Phase 1: Establish Drivers — Step 1 establishes the risk measurement criteria and maps them to organizational impact drivers (financial, reputational, regulatory).
• Phase 2: Profile Assets — Steps 2–3 develop the information asset profile and identify the technical, physical, and people containers where each asset lives.
• Phase 3: Identify Threats — Steps 4–5 identify areas of concern and expand them into threat scenarios against those containers.
• Phase 4: Identify and Mitigate Risks — Steps 6–8 identify and analyze risks, then select a mitigation, acceptance, deferral, or transfer approach.

Where Design-Time Threat Modeling Falls Short

A threat model is a point-in-time artifact about a system that keeps changing. Three failure modes recur:

• Model staleness: The model describes the architecture as designed, not as deployed. After a refactor, a new integration, or an emergency change, the DFD and the running system diverge silently. Nothing in STRIDE or PASTA detects that drift; only a re-trigger discipline does.
• Abstraction blindness: Threats below the DFD’s granularity are invisible to it. A single “Auth Service” box hides the token-signing key handling, the session cache, and the library that parses the JWT — each a real attack surface the diagram cannot express.
• Participant bias: Workshop output reflects who was in the room. A model built without the team that operates the database will under-represent operational and insider paths, and a model built without a security engineer will under-represent chained exploitation.

Design-time modeling also cannot establish that a selected control works. It produces a hypothesis about what should stop an attack; proving it requires the runtime evidence covered in Adversary Emulation & Continuous Security Validation, and the intrusion frameworks in Operational Intrusion Frameworks describe the attacker behavior the model is trying to anticipate.

Essential Design-Time Threat Modeling Diagnostic Checklist

The checklist below is a journal working model, not a published audit standard. It operationalizes the framework criteria above into a repeatable review; calibrate the evidence expectations to the size and regulatory context of the program being assessed.

Primary references

• OWASP Threat Modeling Project: Universal 4-Question Threat Modeling Framework — OWASP Threat Modeling
• Microsoft Threat Modeling: Shostack, A. (2014). Threat Modeling: Designing for Security — Adam Shostack Official — source for the STRIDE-per-element applicability matrix.
• PASTA Framework: UcedaVelez, T., & Morana, M. M. (2015). Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. Wiley. ISBN 978-0-470-50096-5 — source for the 7-stage sequence.
• OCTAVE Allegro (CMU/SEI-2007-TR-012): Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process — CMU SEI
• NIST SP 800-92: Guide to Computer Security Log Management — NIST CSRC