Threat Modeling

Process for Attack Simulation and Threat Analysis is a risk-centric, seven-stage framework that aligns business objectives with technical requirements. It emphasizes:

• Defining business and security objectives.
• Defining the technical scope.
• Application decomposition.
• Threat analysis based on attack trees.
• Vulnerability and weakness analysis.
• Attack modeling and simulation.
• Risk and impact analysis to prioritize mitigation.

A qualitative risk assessment model, often used with STRIDE, to score and prioritize threats. It evaluates five factors:

• Damage Potential: How great is the damage?
• Reproducibility: How easy is it to reproduce the attack?
• Exploitability: How much effort is required to launch the attack?
• Affected Users: How many users are impacted?
• Discoverability: How easy is it to discover the threat? Each factor is scored (e.g., 1-3 or 1-10) to calculate a risk rating.

A hierarchical, diagrammatic representation of threats against a system. The root node represents the attacker's ultimate goal (e.g., "Steal Funds"). Child nodes represent different methods to achieve that goal, branching into increasingly specific sub-goals and attack vectors. This method is excellent for:

• Visualizing all potential attack paths.
• Identifying single points of failure.
• Calculating the cost or probability of different attack methods. It is often integrated into other frameworks like PASTA.

Analyzing permissioned functions and privilege escalation risks. This involves mapping all roles (e.g., owner, admin, user) and ensuring role-based access control (RBAC) is correctly enforced. Common threats include missing or insufficient access checks, allowing any user to call critical functions like mint, withdraw, or upgrade.

• Example: An unprotected selfdestruct function.
• Mitigation: Use modifiers like onlyOwner and implement checks-effects-interactions patterns.

Validating the contract's core economic mechanisms and state transitions. The focus is on ensuring asset accounting is correct and that the protocol's intended financial logic cannot be manipulated.

• Key Risks: Reentrancy attacks, incorrect balance updates, flash loan exploits, and oracle manipulation.
• Analysis: Model all possible paths for value transfer (e.g., deposits, swaps, rewards) and identify states where assets can be duplicated or stolen.

Assessing risks from integrations with external systems, including price oracles, cross-chain bridges, and other smart contracts. These are trust boundaries where assumptions about external data or code can be violated.

• Oracle Threats: Data staleness, manipulation (e.g., flash loans to skew prices), and single points of failure.
• Dependency Risks: Insecure external calls, untrusted delegatecall targets, and upgradable proxy dependencies.

Examining how the contract handles all possible inputs and boundary conditions. This prevents integer overflows/underflows, denial-of-service (DoS) via gas exhaustion, and logic errors from unexpected data.

• Common Issues: Lack of checks for zero addresses, unchecked math, unbounded loops, and front-running vulnerabilities.
• Method: Use fuzzing to test extreme values and state machine testing to explore all edge cases.

Evaluating the risks introduced by proxy patterns and admin keys. While upgradeability allows for bug fixes, it centralizes trust and creates a powerful attack vector if the admin key is compromised.

• Threats: Malicious implementation upgrades, proxy storage collisions, and indefinite admin control over user funds.
• Considerations: Timelocks, multi-signature schemes, and the principle of least privilege for upgrade functions.

Identifying patterns that could make the contract unusable or excessively costly for users. This includes gas griefing attacks and logic that can be exploited to block contract operations.

• DoS Vectors: Block gas limit with unbounded operations, locking funds in an unreachable state, or exploiting gas price auctions.
• Prevention: Implement pull-over-push patterns for withdrawals, set reasonable limits on loop iterations, and avoid state changes in loops.

The total sum of all potential entry points, vulnerabilities, and assets an attacker could exploit within a system. In blockchain, this includes smart contract functions, RPC endpoints, validator nodes, and user wallets. Key activities involve:

• Mapping all external interfaces and data flows.
• Identifying trust boundaries between components.
• Prioritizing reduction of the surface through design and access controls.

A mnemonic classification model for categorizing threats, developed by Microsoft. Each letter represents a threat category:

• Spoofing: Impersonating a user or system.
• Tampering: Unauthorized data modification.
• Repudiation: Denying an action occurred.
• Information Disclosure: Data leakage.
• Denial of Service: Disrupting system availability.
• Elevation of Privilege: Gaining unauthorized access rights. It provides a systematic checklist for threat identification.

A graphical representation of how data moves through a system, used as the primary visual aid in threat modeling. It depicts:

• External Entities (users, oracles).
• Processes (smart contracts, off-chain services).
• Data Stores (blockchain state, databases).
• Data Flows (transactions, API calls). Analysts use DFDs to identify trust boundaries where data crosses between components, which are prime locations for threat analysis.

The quantitative or qualitative evaluation of identified threats, following their discovery in threat modeling. It involves analyzing the likelihood of a threat being exploited and the potential impact (financial loss, reputational damage, data breach). The output is a prioritized list of risks, often visualized on a risk matrix, which informs the mitigation strategy and resource allocation for security controls.

The specific technical or procedural countermeasures designed to address threats identified during modeling. For smart contracts, these include:

• Access Controls: Using modifiers like onlyOwner.
• Input Validation: Checking parameters with require() statements.
• Circuit Breakers: Pausing contracts during an incident.
• Audits & Formal Verification: External code review and mathematical proof of correctness. Mitigations are mapped directly to threats to ensure coverage.

The practice of collecting and analyzing information about existing and emerging threats to inform the threat modeling process. In Web3, this involves monitoring:

• Real-world exploits and post-mortems from other protocols.
• Common vulnerability patterns (e.g., reentrancy, oracle manipulation).
• Attacker Tactics, Techniques, and Procedures (TTPs). This external data makes threat models more realistic and proactive, moving beyond theoretical risks to known adversary behaviors.