6.4 Risk Scenario Development & Threat Modeling
Key Takeaways
- An actionable risk scenario must contain five core components: Threat Actor, Threat Type/Event, Asset/Resource, Predisposing Vulnerability/Condition, and Business Consequence/Impact.
- Risk scenarios bridge technical vulnerabilities and business impact, enabling executives and asset owners to evaluate exposure within risk appetite.
- The STRIDE threat modeling framework systematically analyzes flaws across six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
- PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric, 7-stage threat modeling methodology that aligns application security risks directly with business objectives and regulatory compliance.
- Top-down scenario development starts with mission-critical business objectives, while bottom-up scenario development starts with technical component telemetry and configurations.
6.4 Risk Scenario Development & Threat Modeling
A major challenge in enterprise IT risk governance is communicating complex technical exposures in language that business asset owners, executive leadership, and board members can understand. Telling a Board of Directors that "We have 42 unpatched CVEs on our Linux clusters" produces confusion and apathy.
Risk Scenario Development solves this communication failure by translating abstract technical weaknesses into structured, realistic, and tangible narrative events that describe who might do what, to which asset, how, and what the business consequences would be.
1. Anatomy of an Actionable Risk Scenario
According to ISACA's Risk IT Framework, an actionable risk scenario must be clearly defined, realistic, and contain five essential structural elements:
+-----------------------------------------------------------------------------+
| THE 5 CORE ELEMENTS OF AN ACTIONABLE RISK SCENARIO |
| |
| 1. THREAT ACTOR (AGENT) |
| Who initiates the event? (e.g., Nation-state, insider, cybercriminal) |
| | |
| v |
| 2. THREAT TYPE / ACTION |
| What is the malicious/accidental event? (e.g., Ransomware, theft) |
| | |
| v |
| 3. VULNERABILITY / CONDITION |
| What weakness enables the event? (e.g., Missing MFA, unpatched bug) |
| | |
| v |
| 4. ASSET / RESOURCE AT RISK |
| What business asset is impacted? (e.g., ERP database, wire system) |
| | |
| v |
| 5. BUSINESS CONSEQUENCE & IMPACT |
| What is the financial, operational, or legal damage? ($2M fine, outage)|
+-----------------------------------------------------------------------------+
Deconstructing the 5 Elements:
- Threat Actor / Agent: The internal or external entity driving the event (e.g., external ransomware syndicate, disgruntled financial accountant, automated worm).
- Threat Type / Event: The nature of the threat occurrence (e.g., unauthorized data exfiltration, system destruction, physical sabotage, unauthorized modification).
- Predisposing Vulnerability / Condition: The operational flaw, architectural weakness, or lack of control that permits the threat to succeed (e.g., lack of multi-factor authentication on legacy VPN, unsegmented flat network, missing peer review).
- Asset / Resource at Risk: The critical informational, technical, or physical asset targeted (e.g., cloud customer repository, active directory domain controller, real-time settlement engine).
- Consequence / Business Impact: The quantifiable operational downtime, financial loss, regulatory fines, safety hazards, or reputational damage suffered by the enterprise.
EXAMPLE OF A WELL-STRUCTURED RISK SCENARIO:
"An external cybercriminal syndicate [ACTOR] leverages an unpatched remote code execution vulnerability on an exposed edge VPN gateway [VULNERABILITY] to execute unauthorized network intrusion and deploy ransomware [THREAT TYPE], encrypting the primary Enterprise Resource Planning (ERP) database [ASSET], resulting in 72 hours of manufacturing downtime and an estimated financial loss of $4.5 million [CONSEQUENCE]."
2. Top-Down vs. Bottom-Up Scenario Development
When developing an enterprise risk scenario catalog, organizations combine two complementary approaches:
+-----------------------------------------------------------------------------+
| SCENARIO DEVELOPMENT APPROACH COMPARISON |
| |
| TOP-DOWN SCENARIO DEVELOPMENT BOTTOM-UP SCENARIO DEVELOPMENT |
| ----------------------------- ------------------------------ |
| - Starts with Business Objectives - Starts with Individual Components |
| - "What could shut down retail?" - "What happens if Server X fails?" |
| - Driven by Business Asset Owners - Driven by IT Engineers / SysAdmins |
| - High executive relevance - High technical granularity |
+-----------------------------------------------------------------------------+
- Top-Down Scenario Development: Begins with the organization's critical business processes and strategic goals (e.g., customer checkout processing, payroll execution). The team asks: "What events would cause this business process to fail completely?" This ensures scenarios are business-relevant and prioritized by strategic impact.
- Bottom-Up Scenario Development: Begins with specific IT assets, component configurations, software versions, and network topologies. The team asks: "What happens if this database cluster fails or this firewall is bypassed?" This ensures no technical failure modes or architectural dependencies are overlooked.
3. Threat Modeling Methodologies: STRIDE
Originally developed by Loren Kohnfelder and Praerit Garg at Microsoft, STRIDE is the most widely adopted developer- and architecture-focused threat modeling methodology. It categorizes threat events according to the specific security property being violated.
+-----------------------------------------------------------------------------+
| THE STRIDE THREAT MODEL |
| |
| STRIDE THREAT CATEGORY VIOLATED SECURITY PROPERTY |
| +--------------------------+ +-------------------------------------+ |
| | S - SPOOFING |-->| Authenticity (Impersonation) | |
| | T - TAMPERING |-->| Integrity (Unauthorized Modification| |
| | R - REPUDIATION |-->| Non-Repudiation (Denying Actions) | |
| | I - INFORMATION DISCLOS. |-->| Confidentiality (Data Leakage) | |
| | D - DENIAL OF SERVICE |-->| Availability (System Outage) | |
| | E - ELEVATION OF PRIV. |-->| Authorization (Gaining Root/Admin) | |
| +--------------------------+ +-------------------------------------+ |
+-----------------------------------------------------------------------------+
Detailed STRIDE Mapping & Countermeasures:
| Threat Category | Attacker Action & Definition | Violated Property | Primary Mitigating Controls |
|---|---|---|---|
| Spoofing | Pretending to be an authorized user, system, or IP address to gain access. | Authenticity | Multi-Factor Authentication (MFA), mutual TLS (mTLS), digital certificates, IPsec. |
| Tampering | Modifying data in transit or storage without authorization. | Integrity | Cryptographic hashing (SHA-256), digital signatures, database access controls, WORM storage. |
| Repudiation | Denying having performed an action or transaction without the system being able to prove otherwise. | Non-Repudiation | Immutable audit logs, write-once centralized logging (SIEM), digital signatures, PKI timestamps. |
| Information Disclosure | Exposing sensitive data to unauthorized individuals or processes. | Confidentiality | Encryption at rest (AES-256), encryption in transit (TLS 1.3), Data Loss Prevention (DLP), data masking. |
| Denial of Service | Degrading or halting system availability for legitimate users. | Availability | Load balancing, rate limiting, DDoS scrubbing (Cloudflare/Akamai), auto-scaling clusters. |
| Elevation of Privilege | Gaining unauthorized higher-level permissions (e.g., standard user to domain administrator). | Authorization | Principle of least privilege, Role-Based Access Control (RBAC), sandboxing, kernel hardening. |
4. The PASTA Framework (Process for Attack Simulation and Threat Analysis)
While STRIDE is an excellent software-engineering threat model, PASTA is a risk-centric, business-oriented threat modeling methodology designed specifically for enterprise risk practitioners. PASTA aligns application-level security threats directly with business objectives, regulatory compliance, and financial impact across seven sequential stages.
+-----------------------------------------------------------------------------+
| THE 7-STAGE PASTA THREAT MODEL |
| |
| [STAGE 1: DEFINE OBJECTIVES] ---> Identify business goals & compliance|
| | |
| v |
| [STAGE 2: DEFINE TECH SCOPE] ---> Map software boundaries, APIs, data |
| | |
| v |
| [STAGE 3: APP DECOMPOSITION] ---> Build Data Flow Diagrams (DFDs) |
| | |
| v |
| [STAGE 4: THREAT ANALYSIS] ---> Extract threat intelligence & actors|
| | |
| v |
| [STAGE 5: VULNERABILITY ANALYSIS]---> Identify technical CVEs & flaws |
| | |
| v |
| [STAGE 6: ATTACK SIMULATION] ---> Model exploit paths & attack trees |
| | |
| v |
| [STAGE 7: RISK & IMPACT ANALYSIS]---> Calculate business & financial loss |
+-----------------------------------------------------------------------------+
The Seven Stages of PASTA:
- Define Objectives: Establish the business goals, regulatory obligations, and financial criticality of the target application.
- Define Technical Scope: Document architectural components, software dependencies, network interfaces, and third-party integrations.
- Application Decomposition: Create Data Flow Diagrams (DFDs) to map trust boundaries, data stores, process nodes, and communication protocols.
- Threat Analysis: Ingest cyber threat intelligence to model threat actors, attacker motivations, and targeted threat scenarios.
- Vulnerability & Flaw Analysis: Identify software vulnerabilities, security design flaws, and configuration weaknesses.
- Attack Modeling & Simulation: Build Attack Trees and simulate attack paths to test whether vulnerabilities can be successfully exploited.
- Risk & Impact Analysis: Quantify the residual risk and business impact to prioritize countermeasures and inform executive decision-making.
[!IMPORTANT] Why PASTA is Tested on the CRISC Exam: ISACA favors PASTA because it is risk-centric and business-driven. Rather than treating threat modeling as a purely technical code review, PASTA starts with Stage 1: Business Objectives and ends with Stage 7: Business Impact Analysis, ensuring that every security mitigation directly supports enterprise goals.
An IT risk practitioner is drafting formal risk scenarios for the enterprise risk register. According to ISACA Risk IT guidance, which set of components MUST be documented to make each scenario complete, realistic, and actionable?
During a software threat modeling review of a core online banking application, a security engineer uses the STRIDE framework and identifies that transaction data transmitted between web clients and backend databases is not cryptographically protected, allowing an attacker to alter payment amounts in transit. Which STRIDE category and corresponding security property are directly violated?
Why is the PASTA (Process for Attack Simulation and Threat Analysis) framework considered especially advantageous for enterprise IT risk practitioners compared to purely developer-centric threat modeling models like STRIDE?
An enterprise risk committee is debating whether to develop risk scenarios using a top-down or a bottom-up approach. What is the PRIMARY benefit of adopting a top-down scenario development approach?