This chapter covers threat modeling methodologies STRIDE and PASTA, which are essential for identifying, categorizing, and prioritizing threats in system design and operation. For the SY0-701 exam, this maps to Objective 4.1 (Security Operations) under threat intelligence and threat modeling. Understanding these frameworks helps security professionals proactively assess risks and implement appropriate controls, a key skill for incident response and security architecture roles.
Jump to a section
Imagine a bank wants to secure its vault. STRIDE is like the bank's security architect walking through the blueprints, asking: 'Could someone spoof the manager's voice to open the vault? Could a disgruntled employee tamper with the lock logs? Could a thief repudiate their access? Could a laser cutter disclose the vault's contents? Could a denial-of-service jam the electronic lock? Could an escalation of privilege let a teller access the inner vault?' Each question maps to a threat category. The architect then adds controls: voice biometrics (anti-spoofing), tamper-evident seals, mandatory dual-signature logs, steel walls, redundant power, and role-based access. PASTA, on the other hand, is like a penetration testing team simulating a heist. They start by defining the vault's value (millions in cash) and its business context (bank reputation). They decompose the vault into components: door, lock, alarm, camera system. They analyze threats: a social engineer might trick the guard, a brute-force attack might crack the combination. They identify vulnerabilities: the camera feed is unencrypted. They enumerate attack scenarios: cut power, then drill the lock. Finally, they prioritize mitigations: encrypt camera feeds, add backup generator. STRIDE is proactive, category-driven; PASTA is reactive, attacker-centric. Both aim to secure the vault, but one asks 'what could go wrong?' while the other asks 'how would an actual thief break in?'.
What is Threat Modeling?
Threat modeling is a structured approach to identifying, analyzing, and mitigating potential threats to a system. It is not a one-time activity but an iterative process integrated into the software development lifecycle (SDLC) and operational security. The goal is to understand what an attacker could do, what assets are valuable, and what controls reduce risk to an acceptable level. Two widely used methodologies are STRIDE (Microsoft) and PASTA (Process for Attack Simulation and Threat Analysis).
STRIDE: Categorizing Threats by Type
STRIDE, developed by Microsoft, is a mnemonic for six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category targets a specific security property: - Spoofing: Impersonating a user, process, or device. Violates authenticity. Example: An attacker sends an email pretending to be the CEO to trick an employee into transferring funds. - Tampering: Unauthorized modification of data or code. Violates integrity. Example: An attacker alters a database record to change a user's balance. - Repudiation: Denying an action without proof. Violates non-repudiation. Example: A user performs a malicious action and claims they did not, with no audit trail. - Information Disclosure: Exposure of data to unauthorized parties. Violates confidentiality. Example: An attacker exploits a SQL injection to dump user passwords. - Denial of Service (DoS): Disrupting service availability. Violates availability. Example: A flood of traffic overwhelms a web server, making it inaccessible. - Elevation of Privilege: Gaining unauthorized access to higher-level functions. Violates authorization. Example: A standard user exploits a bug to gain admin rights.
STRIDE is typically applied using a data flow diagram (DFD) of the system. Each element in the DFD (process, data store, data flow, external entity) is analyzed for each STRIDE category. For example, a web server process might be vulnerable to spoofing (if authentication is weak), tampering (if input validation is missing), etc. The output is a list of threats, often documented in a threat model table with columns: Threat ID, Category, Description, Impact, and Mitigation.
PASTA: Attack-Centric Threat Modeling
PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric methodology developed by Tony UcedaVélez. It aligns business objectives with technical requirements and involves seven stages: 1. Define Objectives: Identify business goals, security requirements, and compliance needs. Example: For an e-commerce site, objectives include protecting customer payment data (PCI DSS). 2. Define Technical Scope: Map the system architecture, including components, data flows, trust boundaries, and technologies. Tools like DFDs and network diagrams are used. 3. Decompose Application: Break down the application into assets, services, and trust levels. Identify entry points, exit points, and data classification. 4. Threat Analysis: Enumerate threats using attack trees, threat libraries (e.g., CAPEC), and scenarios. This stage is attacker-driven, asking 'How would an attacker exploit this?' 5. Vulnerability Analysis: Identify weaknesses in the system that could be exploited. This includes code reviews, vulnerability scanning, and manual testing. 6. Attack Modeling: Simulate attacks by chaining vulnerabilities into attack paths. Tools like attack trees or misuse cases are used. 7. Risk and Impact Analysis: Quantify risk (likelihood x impact) and propose mitigations. Output is a prioritized list of countermeasures.
PASTA is more comprehensive than STRIDE because it integrates business context and attack simulation. It is often used for high-risk systems like financial applications or critical infrastructure.
How Attackers Exploit and Defenders Deploy
Attackers exploit weaknesses that threat modeling would have identified. For example, a lack of input validation (a tampering threat in STRIDE) leads to SQL injection (CVE-2023-12345). Defenders use threat modeling to proactively implement controls: STRIDE helps ensure all six security properties are addressed, while PASTA helps prioritize based on real attack vectors. In practice, defenders use tools like Microsoft Threat Modeling Tool (STRIDE) or OWASP Threat Dragon (supports multiple methodologies).
Real Command/Tool Examples
Using Microsoft Threat Modeling Tool (free): 1. Create a new model based on a template (e.g., Azure, Web App). 2. Draw a DFD with processes, data stores, external entities, and data flows. 3. Click 'Analyze' to generate threats based on STRIDE. Example output:
Threat: Spoofing of External Web Service
Category: Spoofing
Description: An attacker may spoof the identity of the external web service to gain access to sensitive data.
Mitigation: Use mutual TLS authentication.Using OWASP Threat Dragon (open source): 1. Create a threat model, define assets and trust boundaries. 2. Add threats manually or using a threat library (e.g., STRIDE). 3. Export as JSON or PDF.
For PASTA, there are no specific tools, but practitioners use attack tree tools like ThreatModeler or SeaSponge, or simply document in a spreadsheet with columns for each stage.
Key Components and Variants
STRIDE variants include STRIDE-per-Element (applying STRIDE to each DFD element) and STRIDE-per-Interaction (analyzing interactions between elements). PASTA can be integrated with Agile development by mapping stages to sprints. Other methodologies include OCTAVE (focuses on organizational risk), VAST (Visual, Agile, Simple Threat modeling), and TRIKE (integrates risk management). However, SY0-701 specifically tests STRIDE and PASTA.
Standards and References
STRIDE: Microsoft Security Development Lifecycle (SDL)
PASTA: Published by ISACA and referenced in NIST SP 800-154 (Guide to Data-Centric System Threat Modeling)
Common Weakness Enumeration (CWE) and Common Attack Pattern Enumeration and Classification (CAPEC) are used in both.
1. Define System Scope
Identify the system or application to be modeled. For STRIDE, this means creating a Data Flow Diagram (DFD) that includes external entities (users, third-party services), processes (web server, database server), data stores (databases, files), and data flows (HTTP requests, SQL queries). Mark trust boundaries (e.g., between internal network and internet). For PASTA, this stage also includes business objectives and compliance requirements. Example: A web application with a user (external entity) sending HTTP requests to a web server (process) that queries a database (data store). Logs would show the DFD elements; tools like Microsoft Threat Modeling Tool automate DFD creation.
2. Enumerate Threats (STRIDE)
Apply each STRIDE category to every DFD element. For each element, ask: Can this element be spoofed? Can data be tampered? Can actions be repudiated? Can information be disclosed? Can service be denied? Can privileges be elevated? Document threats in a table. Example: For the web server process, a spoofing threat might be 'An attacker could spoof a legitimate user's session token.' A tampering threat might be 'An attacker could modify input data to perform SQL injection.' Use automated tools to generate initial list, but manually refine. Output: threat list with IDs, categories, and descriptions.
3. Analyze Attack Paths (PASTA)
For PASTA, after defining scope and decomposing the system, create attack trees that model how an attacker could achieve their goal. Start with the attacker's objective (e.g., steal credit card data) and break it down into sub-goals (e.g., exploit SQL injection, then extract data). Use libraries like CAPEC for common attack patterns. For each node, assign likelihood and impact. Example: Attack tree root: 'Steal payment data'; child nodes: 'Exploit SQL injection in login form' and 'Exploit XSS to steal session cookies'. Tools: use a mind map or dedicated attack tree software. Output: prioritized attack scenarios.
4. Identify Vulnerabilities
Map threats to specific vulnerabilities in the system. For STRIDE, this means looking for weaknesses that realize the threat. For PASTA, this is stage 5. Use vulnerability scanning (e.g., Nessus, OpenVAS), code review (e.g., SonarQube), and manual testing. Example: The spoofing threat 'session token spoofing' maps to vulnerability 'weak session ID generation' (CWE-330). Document each vulnerability with its CVE or CWE identifier. Output: vulnerability list with references and severity.
5. Prioritize and Mitigate
Assess risk for each threat/vulnerability using likelihood and impact. For STRIDE, risk is often qualitative (High/Medium/Low). For PASTA, it's quantitative (e.g., annual loss expectancy). Prioritize high-risk items. Propose mitigations: for spoofing, use multi-factor authentication; for tampering, use input validation and digital signatures; for repudiation, enable audit logs; for information disclosure, encrypt data; for DoS, rate limiting; for elevation of privilege, least privilege principle. Document mitigations in the threat model. Example: Mitigation for SQL injection: parameterized queries. Output: prioritized mitigation plan.
Scenario 1: SOC Analyst Investigating a Data Breach A SOC analyst receives an alert of unusual database queries from a web application server. Using STRIDE, the analyst identifies that the threat is 'Tampering' (SQL injection) and 'Information Disclosure' (data exfiltration). The analyst reviews web server logs (Apache access.log) showing suspicious SQL commands in GET parameters:
192.168.1.100 - - [10/Oct/2023:13:55:36 -0400] "GET /products?id=1 UNION SELECT * FROM users HTTP/1.1" 200 5432The analyst correlates with database audit logs showing SELECT queries on users table. The correct response: block the source IP, isolate the web server, and begin incident response. A common mistake: focusing only on the DoS aspect and ignoring the data loss.
Scenario 2: Engineer Implementing Threat Modeling for a New App A security engineer is tasked with threat modeling a new payment processing application. They use PASTA. Stage 1: Business objective is PCI DSS compliance. Stage 2: Technical scope includes a web server, payment gateway, and database. Stage 3: Decomposition reveals entry points: login form, payment form. Stage 4: Threat analysis identifies attack tree: 'Attacker uses XSS to steal session cookie, then impersonates user to make unauthorized payments.' Stage 5: Vulnerability scanning finds missing CSP headers. Stage 6: Attack modeling shows a realistic attack path. Stage 7: Risk is high (likelihood 4, impact 5). Mitigation: implement CSP, use HttpOnly cookies, and deploy WAF. Common mistake: skipping stage 1 (business objectives) leading to misaligned mitigations.
Scenario 3: Penetration Testing Using STRIDE A penetration tester uses STRIDE to structure testing. For each category, they design tests: Spoofing: test for weak authentication (e.g., default credentials). Tampering: test for parameter tampering. Repudiation: check if logs are sufficient. Information Disclosure: test for directory listing. DoS: test for resource exhaustion. Elevation of Privilege: test for privilege escalation via insecure direct object references (IDOR). The tester finds that the application discloses database error messages (Information Disclosure). Correct response: configure custom error pages. Common mistake: testing only one category (e.g., only spoofing) and missing others.
What SY0-701 Tests on This Objective Objective 4.1 (Security Operations) includes threat intelligence and threat modeling. The exam expects you to:
Define STRIDE and PASTA.
Differentiate between the two methodologies.
Apply STRIDE categories to scenarios.
Identify the stages of PASTA.
Recognize when to use each methodology.
Most Common Wrong Answers 1. Confusing STRIDE categories: Candidates often mix up 'Repudiation' and 'Non-repudiation' or think 'Spoofing' is only about email. Wrong: 'Spoofing is about faking an IP address only.' Reality: Spoofing includes any impersonation (user, device, service). 2. Thinking PASTA is a vulnerability scanning tool: PASTA is a process, not a tool. Wrong: 'PASTA is used to scan for vulnerabilities.' Reality: PASTA includes vulnerability analysis as one stage, but it's a full methodology. 3. Believing STRIDE is only for software development: STRIDE can be applied to any system, including network architecture. Wrong: 'STRIDE is only for application threat modeling.' Reality: STRIDE is used in Microsoft SDL but is generic. 4. Mixing up stages of PASTA: Forgetting that stage 1 is 'Define Objectives' not 'Decompose Application'. Wrong: 'The first stage of PASTA is to decompose the application.' Reality: It's stage 3.
Specific Terms and Acronyms - STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. - PASTA: Process for Attack Simulation and Threat Analysis. - DFD: Data Flow Diagram. - Trust boundary: A line marking where trust levels change. - CAPEC: Common Attack Pattern Enumeration and Classification.
Common Trick Questions - A question describes a threat (e.g., 'An attacker modifies a configuration file') and asks which STRIDE category. Answer: Tampering (not Elevation of Privilege). - A question lists steps of a methodology and asks which one. If steps include 'Define business objectives', it's PASTA. If steps include 'Apply STRIDE categories', it's STRIDE. - A scenario asks which methodology to use for a new startup with limited budget. PASTA is more resource-intensive; STRIDE is simpler. Answer: STRIDE.
Decision Rule for Eliminating Wrong Answers On scenario questions, first identify if the question asks for a 'category' (STRIDE) or a 'process' (PASTA). If the scenario mentions 'attack tree' or 'business objectives', it's PASTA. If it mentions 'spoofing' or 'tampering', it's STRIDE. Eliminate options that mix up categories or stages.
STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
PASTA has 7 stages: Define Objectives, Define Technical Scope, Decompose Application, Threat Analysis, Vulnerability Analysis, Attack Modeling, Risk and Impact Analysis.
STRIDE is property-based (focus on security properties); PASTA is attack-centric (focus on attacker goals).
Both methodologies are part of threat modeling, which is proactive security.
SY0-701 expects you to differentiate between STRIDE and PASTA and apply STRIDE categories to scenarios.
Common exam trick: a question describing a threat (e.g., 'user denies sending a message') maps to 'Repudiation'.
Trust boundaries in DFDs are critical for identifying where threats can occur.
These come up on the exam all the time. Here's how to tell them apart.
STRIDE
Focuses on threat categories (Spoofing, Tampering, etc.)
Top-down, property-based approach
Typically used with Data Flow Diagrams (DFDs)
Less resource-intensive, suitable for smaller systems
Output is a list of threats by category
PASTA
Focuses on attack paths and business impact
Bottom-up, attacker-centric approach
Uses attack trees and misuse cases
More comprehensive, suitable for high-risk systems
Output is a prioritized risk mitigation plan
Mistake
STRIDE is a vulnerability assessment methodology.
Correct
STRIDE is a threat categorization framework, not a vulnerability assessment tool. It identifies types of threats, not specific vulnerabilities. Vulnerability assessment (e.g., scanning) comes after threat modeling.
Mistake
PASTA is only for large enterprises.
Correct
PASTA can be scaled; it's not exclusive to large enterprises. However, it is more resource-intensive than STRIDE, so small teams might find STRIDE simpler.
Mistake
Spoofing only refers to IP spoofing.
Correct
Spoofing includes any impersonation: user identity (via stolen credentials), device MAC address, or service (DNS spoofing). The exam tests broad understanding.
Mistake
Repudiation is the same as non-repudiation.
Correct
Repudiation is the threat (denying an action), while non-repudiation is the control (e.g., digital signatures, audit logs). STRIDE lists repudiation as a threat category, not the control.
Mistake
Threat modeling is a one-time activity done at the start of a project.
Correct
Threat modeling should be iterative, updated as the system evolves. Both STRIDE and PASTA are designed to be integrated into the SDLC and operational changes.
STRIDE is a threat categorization framework that classifies threats into six types (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). It is often used with Data Flow Diagrams. PASTA is a seven-stage risk-centric methodology that includes business objectives, attack simulation, and risk analysis. STRIDE is simpler and property-based; PASTA is more comprehensive and attacker-centric. For the exam, know that STRIDE categorizes threats, while PASTA is a full process.
SQL injection primarily falls under Tampering (because it modifies database queries) and Information Disclosure (if it extracts data). However, the primary category is Tampering, as it violates data integrity. The exam might test that SQL injection is a tampering threat, but also note it can lead to information disclosure.
The first stage of PASTA is 'Define Objectives', where you identify business goals, security requirements, and compliance needs. This is often forgotten by candidates who think it starts with 'Decompose Application' (stage 3). Memorize the order: 1. Objectives, 2. Technical Scope, 3. Decompose Application, 4. Threat Analysis, 5. Vulnerability Analysis, 6. Attack Modeling, 7. Risk and Impact Analysis.
No, threat modeling can be applied to any system, including networks, hardware, and physical security. STRIDE and PASTA are commonly used for software, but the principles apply broadly. For example, a network DFD can be analyzed with STRIDE to identify threats like spoofing (ARP spoofing) or DoS (flooding).
The Microsoft Threat Modeling Tool is a free tool that automates STRIDE threat generation from DFDs. It provides a template-based approach and outputs a list of threats with mitigations. Other tools include OWASP Threat Dragon (supports STRIDE and other methodologies).
PASTA's first stage explicitly defines business objectives and security requirements. This ensures that threat modeling aligns with business goals, such as compliance (e.g., PCI DSS) or protecting brand reputation. Subsequent stages use this context to prioritize threats based on business impact, not just technical severity.
A trust boundary is a line that separates different trust levels, such as between the internet and internal network, or between a user and an application. Data crossing a trust boundary is a potential threat point. In DFDs, trust boundaries are drawn as dashed lines, and each crossing data flow should be analyzed for threats like spoofing or tampering.
You've just covered Threat Modeling — STRIDE and PASTA — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?