Threat Modeling & Risk Analysis

• Threat Modeling and Risk Analysis is the structured process of identifying potential security threats and quantifying risks using formal frameworks like STRIDE, DREAD, and PASTA.
• It integrates systematic threat identification with quantitative risk scoring to inform mitigation strategies throughout secure system development.
• Its applications span secure software, cyber-physical systems, autonomous vehicles, and industrial IoT by continuously leveraging threat intelligence.

Threat modeling and risk analysis constitute the structured disciplines of identifying, characterizing, and quantifying potential security threats and vulnerabilities in complex systems, with the goal of systematically informing mitigation planning, prioritizing security controls, and enabling secure system development. In advanced engineering and computing contexts such as secure software development, cyber-physical systems, and autonomous platforms, these processes leverage formal methodological frameworks that integrate structured asset modeling, adversarial analysis, probabilistic quantification, and continuous feedback from operational threat intelligence sources.

1. Formal Definitions and Core Concepts

Threat modeling is the structured process of identifying potential security threats and prioritizing mitigation techniques to ensure that valuable assets (such as confidential data) remain protected. Risk assessment is the process used to determine the level of potential threat and risk present in an IT system. Its main phases include risk identification, risk analysis, and risk prioritization. Risk analysis, as a sub-activity, quantifies or qualitatively rates each identified risk in terms of likelihood and impact, commonly resulting in a risk score or risk category for informed mitigation planning (Kamal et al., 2020).

The standard risk quantification formula across domains is: $$\text{Risk} = \text{Likelihood} \times \text{Impact}$$ with both dimensions mapped to appropriate ordinal or ratio scales.

2. Methodological Integration in Secure SDLC

In Secure Software Development Life Cycle (Secure SDLC), the security perspective is embedded within each development phase:

• Requirements & Planning: Establish security requirements, perform risk assessment (asset identification, threat enumeration, risk criteria definition, risk register).
• Design: Produce architecture and data-flow diagrams; apply threat modeling (e.g., STRIDE) covering system elements and trust boundaries.
• Implementation: Enforce secure coding standards, conduct static analysis and code review.
• Testing: Execute dynamic security testing (penetration and fuzz testing), verify implemented mitigations.
• Deployment & Maintenance: Harden configurations, manage patches, perform regression security testing, and iterate on incident response plans.

Threat modeling (e.g., with STRIDE, DREAD, PASTA) is first instantiated at the design phase, guiding downstream security testing and risk re-evaluation. Risk assessment is most acute at planning, informing acceptability thresholds and remediation priorities (Kamal et al., 2020).

3. Taxonomies, Frameworks, and Risk Scoring

Several established frameworks structure both threat enumeration and risk scoring:

STRIDE

• Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
• Explicitly maps to system DFD elements; applied per asset or subsystem (Kamal et al., 2020, Paz et al., 4 May 2025).

DREAD

A five-dimensional scoring model, where threats are rated for:

• Damage, Reproducibility, Exploitability, Affected Users, Discoverability The risk is then: $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$ Thresholds guide prioritization (e.g., $\geq 2.5$ on a 1–3 scale is high risk) (Kamal et al., 2020).

PASTA

A seven-stage methodology advancing from business objectives through attack simulation and residual risk quantification. Explicitly supports alignment of technical and business domains and can be combined with STRIDE/DREAD for granular modeling (Kamal et al., 2020).

ACTISM

Defines an iterative tuple capturing assets, DFD, threat set, impact vector (multidimensional: safety, finance, operational, privacy/legal), attack graph, feasibility, risk vector, and an update loop $U$ for continuous ingestion of threat intelligence (e.g., CVE feeds). Risk is always the product of likelihood (e.g., normalized CVSS base score) and a consequence-driven impact score with critical safety weighting, thresholded per cyber-physical domain (HEAVENS 2.0) (Huang et al., 2024).

4. Stepwise Process: Roles, Activities, and Quantitative Models

Typical risk assessment and threat modeling workflow segments:

A. Risk Assessment (Planning)

• Stakeholders: Project Manager, Security Architect, Business Owner
• Steps: Asset identification $\rightarrow$ threat-actor enumeration $\rightarrow$ risk criteria/acceptance $\rightarrow$ scenario analysis (likelihood, impact) $\rightarrow$ risk prioritization $\rightarrow$ documentation

B. Threat Modeling (Design)

• Stakeholders: Security Analyst, System Architect, Lead Developer
• Steps: Document system/DFD $\rightarrow$ enumerate trust boundaries and controls $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$0 STRIDE analysis per DFD element $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$1 DREAD scoring $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$2 threat matrix and prioritization $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$3 proposed mitigation patterns $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$4 iterate on design change

Quantitative models frequently employ scales for both Likelihood and Impact (e.g., $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$5) and a heatmap or risk matrix for classification: $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$6 with categorical bands such as Low, Medium, High determined by thresholding $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$7 (Paz et al., 4 May 2025).

5. Cross-Domain Case Studies and Framework Extensions

Autonomous Vehicles

Decompose into Sensing, Perception, Planning, Control, Communication and model threat trees per subsystem. Use OWASP Threat Dragon for DFD construction, apply STRIDE/DREAD, and produce per-threat risk metrics. Example: GPS spoofing threat with DREAD score of 3.8 prioritizes the need for cryptographic authentication (e.g., Galileo OSNMA) (Paz et al., 4 May 2025).

Automotive Systems (ACTISM)

Integrates consequence-driven impact analysis (weighted for safety: $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$8) and continuously updates models as new vulnerabilities are disclosed or mitigations deployed, preventing "model-rot". Feedback from practitioners supports automation of CVE integration and use of MITRE ATT&CK mapping, driving continuous security posture management (Huang et al., 2024).

Agentic and AI-Driven Protocols

For emerging AI agent communication protocols (MCP, A2A, Agora, ANP), risks are mapped across Authentication, Operational, and Supply-Chain domains, with qualitative (3x3) likelihood-impact matrices and falsifiable, measurement-driven security claims (e.g., tool execution ambiguity in MCP). Recommendations include cryptographic binding, namespace governance, mandatory integrity checks at runtime, version pinning, and continuous monitoring (Anbiaee et al., 11 Feb 2026).

Industrial IoT (TMAP)

STRIDE-informed attack graph is constructed over IIoT architectures (Purdue model). Probabilistically annotated paths are ranked using: $$\text{RiskScore} = \frac{D + R + E + A + D^{\prime}}{5}$$9 with per-threat, per-path, and per-asset CVSS scoring for clear remediation priorities. Case studies on IoP and IoM validate the method's quantitative and actionable output (Saurabh et al., 2023).

6. Complementarity with Security Testing and Operational Feedback

Threat modeling and risk analysis are rigorously tied to both white-box (static/source analysis) and black-box (dynamic, fuzzing, pentesting) methods. The output of threat and risk models (control requirements, DREAD findings) informs what and how to test, ensuring that documented mitigations are verified in implementation and regressions are flagged rapidly. Automated tools (SAST/DAST) and Software Composition Analysis (SCA) further link risk assessment findings to actionable software engineering feedback loops (Kamal et al., 2020).

Continuous model improvement is required: new threat intelligence, vulnerability disclosures, and architectural changes necessitate repeated risk re-estimation, as exemplified in ACTISM, automotive, and agentic AI system methodologies (Huang et al., 2024, Zambare et al., 12 Aug 2025).

7. Challenges and Best Practices

Key challenges include:

• Third-party/OSS risk: Addressed with automated SCA and CVE tracking.
• Skill gaps in development teams: Managed through embedded security champions and regular training.
• Measurement overload: Handled with a focus on actionable, prioritized security metrics—e.g., high-risk DREAD findings, test coverage percentages.
• Model staleness: Continuous ingestion of threat intelligence and automated model updates mitigate obsolescence (ACTISM, MAESTRO).
• Residual risk identification: As formalized in defense-tree modeling, even aggressive mitigation often leaves some residual risk at the system root, requiring iterative cycles and/or architectural revision (Flores et al., 2023, Saurabh et al., 2023).

By integrating threat modeling and risk analysis systematically throughout the lifecycle—leveraging frameworks such as STRIDE, DREAD, PASTA, ACTISM—and coupling them to automated security testing and continual threat intelligence, organizations can not only proactively minimize late-stage vulnerabilities but also provide quantifiable, defendable justifications for security investments and risk acceptances (Kamal et al., 2020, Paz et al., 4 May 2025, Huang et al., 2024).