Threat Modeling

STRIDE is a foundational threat categorization model developed by Microsoft. It provides a mnemonic for six classic threat types to guide identification:

• Spoofing: Impersonating a user or system.
• Tampering: Unauthorized modification of data.
• Repudiation: Denying an action occurred.
• Information Disclosure: Exposing data to unauthorized parties.
• Denial of Service: Degrading or disrupting service availability.
• Elevation of Privilege: Gaining unauthorized access rights. It is often paired with data flow diagrams (DFDs) to map threats to system components.

DREAD is a qualitative risk rating system used to prioritize identified threats. It assigns scores (e.g., 1-10) across five dimensions:

• Damage Potential: How severe is the impact if exploited?
• Reproducibility: How easy is it to reproduce the attack?
• Exploitability: How much effort is required to launch the attack?
• Affected Users: How many users or systems are impacted?
• Discoverability: How easy is it to find the vulnerability? While subjective, it provides a structured way to compare and rank threats for remediation.

PASTA is a risk-centric, seven-stage methodology that aligns business objectives with technical security requirements.

1. Define Objectives & Scope
2. Define Technical Scope
3. Application Decomposition
4. Threat Analysis
5. Vulnerability & Weakness Analysis
6. Attack Modeling & Simulation
7. Risk & Impact Analysis Its stages integrate asset-centric, attacker-centric, and impact analysis views to produce actionable, risk-mitigated outputs.

All threat modeling processes aim to answer four fundamental questions about a system:

• What are we building? (Create an architecture diagram or data flow).
• What can go wrong? (Identify threats using frameworks like STRIDE).
• What are we going to do about it? (Define countermeasures and mitigations).
• Did we do a good job? (Validate the model and iterate). This simple, iterative questioning forms the backbone of any effective threat modeling exercise.

A Data Flow Diagram is the primary visual tool for threat modeling. It maps:

• External Entities (users, systems)
• Processes (functions, services)
• Data Stores (databases, caches)
• Data Flows (communication paths) Critical to this map is the Trust Boundary, a line that separates components with different levels of trust (e.g., internet from internal network). Threats are analyzed where data crosses these boundaries, as these are prime attack surfaces.

For autonomous AI agents, threat modeling must address unique risks beyond traditional software:

• Prompt Injection: Manipulating agent instructions via crafted inputs.
• Training Data Poisoning: Corrupting the agent's foundational knowledge.
• Unintended Cascading Actions: A single compromised agent triggering harmful chain reactions in a multi-agent system.
• Model Inversion/Extraction: Stealing proprietary model logic or data.
• Context Window Manipulation: Exploiting memory or state management to induce biased or erroneous reasoning. Mitigations include strict input/output validation, sandboxed tool execution, and robust observability telemetry.

A security paradigm that eliminates implicit trust and requires continuous verification of every access request, regardless of origin. It is a foundational principle for implementing threat model countermeasures.

• Core Tenet: "Never trust, always verify."
• Implementation: Enforces strict identity verification, microsegmentation, and least-privilege access.
• Relation to Threat Modeling: Threat modeling identifies trust boundaries and data flows that a Zero Trust architecture must then rigorously enforce and monitor.

A core security concept mandating that users, processes, and systems should be granted the minimum levels of access necessary to perform their authorized functions.

• Goal: Limit the potential damage from accidents, errors, or attacks.
• Application: Critical for defining access control policies in a threat model, especially for agentic systems where an agent's tool-calling permissions must be strictly scoped.
• Example: A customer service agent should not have write access to the financial database.

The cyclical practice of identifying, classifying, prioritizing, remediating, and mitigating software vulnerabilities. It is the operational follow-through to a threat model's findings.

• Process: Scans, patch management, and penetration testing.
• Input from Threat Modeling: Threat models prioritize which vulnerabilities are most critical based on exploit likelihood and potential business impact (e.g., a flaw in an agent's memory retrieval API is higher risk than a low-traffic admin page).
• Lifecycle: A continuous process that feeds new threats back into the threat modeling cycle.

A systems engineering approach that embeds privacy and data protection into the design and architecture of IT systems from the outset, rather than as an afterthought.

• Framework: Aligns with regulations like GDPR.
• Synergy with Threat Modeling: Threat modeling for systems handling personal data must explicitly identify privacy threats (e.g., data leakage, unauthorized identification). Mitigations like data minimization, encryption, and access controls are then designed in.
• Agentic Context: Crucial for agents that process sensitive user context or proprietary enterprise data.

The process of using mathematical reasoning and logic to prove or disprove the correctness of a system's algorithms or protocols against a formal specification.

• Goal: Ensure the absence of certain classes of design-level bugs and security flaws.
• Relation to Threat Modeling: While threat modeling is a structured, qualitative analysis of potential attacks, formal verification provides a quantitative, mathematical proof of correctness for specific critical components identified in the model (e.g., a cryptographic protocol or a consensus algorithm).
• Use Case: Verifying the security properties of a Trusted Execution Environment (TEE) or a custom access control module.

A suite of technologies that collect security data, automate and standardize incident response workflows, and execute defensive actions.

• Function: The "response" pillar of a security program.
• Connection to Threat Modeling: Threat models define attack scenarios and their indicators of compromise (IoCs). SOAR platforms use these IoCs to create automated playbooks for detection and response. For example, a model predicting prompt injection could trigger a SOAR playbook that isolates an agent and rolls back its context window.