This chapter covers threat modeling as a critical planning activity for penetration testing, directly aligned with PT0-002 objective 1.1 (Plan and scope an assessment). Threat modeling helps you identify, prioritize, and document potential threats and attack vectors before executing any test. Expect approximately 5-7% of exam questions to touch on threat modeling concepts, methodologies, and their application to scoping decisions.
Jump to a section
Threat modeling for penetration testing is like an architect designing a bank vault before a security audit. The architect doesn't just list possible break-in methods; they systematically analyze every component: the walls, door, alarm system, cameras, and even the lock manufacturer's history. They create a blueprint showing attack paths—like how a thief might bypass the alarm by cutting power or exploit a weak hinge. They prioritize risks: a vulnerable lock is more critical than a scratched paint job. They also consider the vault's context—its location in a high-crime area or near a construction site. For the audit, they decide which attack vectors to test first based on likelihood and impact. Similarly, a penetration tester uses threat modeling to map the system's architecture, identify threats (e.g., SQL injection, misconfigured S3 buckets), and prioritize testing based on risk. The model evolves as new vulnerabilities are discovered, just as the architect updates plans if a new drill-resistant material becomes available. Without this structured approach, the auditor might waste time on low-impact issues or miss critical flaws. The exam tests your ability to select the right threat modeling methodology (STRIDE, PASTA, etc.) and apply it to scope a penetration test effectively.
What is Threat Modeling and Why Does It Matter for PenTest Planning?
Threat modeling is a structured approach to identifying, quantifying, and addressing security risks in a system or application. For penetration testers, it is the foundational step that ensures the test is focused, efficient, and aligned with the client's risk profile. The PT0-002 exam expects you to understand that threat modeling is not a one-time activity but an iterative process that informs the entire penetration testing lifecycle—from scoping and rules of engagement to reporting.
How Threat Modeling Works Internally: The Mechanism
Threat modeling typically follows a four-step process: 1. Decompose the system – Break the target into components (e.g., web server, database, API, network segments, user roles). This includes creating data flow diagrams (DFDs) that show how data moves between components, trust boundaries, and entry points. 2. Identify threats – Use a framework like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to systematically evaluate each component and data flow. 3. Prioritize threats – Assess each threat's likelihood and impact using a risk matrix (e.g., DREAD – Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or other scoring systems. 4. Mitigate or accept risks – Decide which threats to address, which to accept, and which to test. This directly defines the penetration test scope: what will be tested, what techniques will be used, and what is out of scope.
Key Components, Values, Defaults, and Timers
STRIDE – Developed by Microsoft, each letter represents a threat category. The exam expects you to map each category to the applicable security property (e.g., Spoofing threatens authentication). Know that STRIDE is best for software/application threat modeling.
DREAD – A risk scoring system that assigns numeric values (1-10) for each of the five categories. The total score (5-50) helps prioritize threats. Common trap: DREAD is subjective and less used today; the exam may test its components.
PASTA – Process for Attack Simulation and Threat Analysis. It is a risk-centric methodology that aligns with business objectives. It involves seven stages, from defining objectives to analyzing residual risk.
Attack Trees – Graphical representations of attack paths, with the root as the attacker's goal and leaves as sub-goals. Each node can be assigned a cost or difficulty.
Data Flow Diagrams (DFDs) – Must include external entities, processes, data stores, and data flows. Trust boundaries should be clearly marked. The exam may test your ability to identify missing trust boundaries or incorrect data flows.
Default values: There are no default timers in threat modeling; it is a conceptual exercise. However, the exam may ask about the typical order of steps (decompose first, then identify threats, etc.).
Configuration and Verification Commands
Threat modeling is not a command-line tool; it is a process. However, there are tools like Microsoft Threat Modeling Tool (TMT) that help create DFDs and generate threat lists. The exam expects you to know how to use the output of threat modeling to scope a test. For example:
If threat modeling reveals a high-risk API endpoint, the penetration test should include API fuzzing.
If the model shows a trust boundary between the web server and database, the test should include SQL injection attempts.
Verification of threat modeling is done via peer review or by comparing the test plan against the threat model.
How Threat Modeling Interacts with Related Technologies
Threat modeling is used in conjunction with: - Vulnerability scanning – Threat modeling identifies which assets and vulnerabilities are most critical, guiding scanning priorities. - Penetration testing – The threat model defines the attack surface and test cases. - Risk management frameworks (e.g., NIST SP 800-30) – Threat modeling feeds into risk assessment. - Secure SDLC – Threat modeling is a key activity in the design phase (Shift Left).
Deeper Dive into STRIDE and DREAD
STRIDE per Element: - Spoofing – Impersonating someone or something else. Threatens authentication. Example: stealing session tokens. - Tampering – Modifying data or code. Threatens integrity. Example: SQL injection. - Repudiation – Denying an action. Threatens non-repudiation. Example: logging gaps. - Information Disclosure – Exposing data to unauthorized parties. Threatens confidentiality. Example: directory traversal. - Denial of Service – Disrupting service. Threatens availability. Example: resource exhaustion. - Elevation of Privilege – Gaining higher access. Threatens authorization. Example: privilege escalation.
DREAD Scoring: - Damage potential: How severe is the damage? (1-10) - Reproducibility: How easy is it to reproduce? (1-10) - Exploitability: How easy is it to exploit? (1-10) - Affected users: How many users are affected? (1-10) - Discoverability: How easy is it to discover? (1-10) - Total = (D+R+E+A+D)/5 or sum? The exam may use sum (5-50).
Common Pitfalls and Exam Traps
Confusing STRIDE categories: For example, mixing up Tampering (integrity) with Information Disclosure (confidentiality).
Forgetting that threat modeling is NOT vulnerability scanning: It is about identifying threats, not finding specific CVEs.
Assuming one methodology fits all: The exam expects you to choose the right methodology for the scenario (e.g., PASTA for risk-driven, STRIDE for app-focused).
Ignoring business context: Threat modeling must consider the business impact; a low technical risk may have high business impact.
Real-World Application
In a typical engagement, the penetration tester receives a threat model from the client or builds one during scoping. The model includes DFDs, identified threats, and risk scores. The tester uses this to:
Determine which systems are in scope.
Choose testing techniques (e.g., if threat model shows an exposed admin interface, test for default credentials).
Define rules of engagement (e.g., no DoS on critical systems).
Report findings with reference to the threat model (e.g., 'This SQL injection realizes the Tampering threat identified in the threat model').
Summary of Key Values for the Exam
STRIDE has 6 categories.
DREAD has 5 categories.
PASTA has 7 stages.
Attack trees are hierarchical.
DFDs must show trust boundaries.
Threat modeling is performed BEFORE the test.
Decompose the Target System
Begin by breaking down the target system into its core components: hardware, software, network segments, data flows, and user roles. Create a data flow diagram (DFD) that maps all external entities, processes, data stores, and data flows. Identify trust boundaries where data crosses from one security zone to another (e.g., from the internet to the DMZ). This step is critical because it defines the attack surface. The exam expects you to recognize that missing a trust boundary can lead to overlooked threats. Use a tool like Microsoft Threat Modeling Tool or simply whiteboard. Ensure you document each component's function and the type of data it handles (e.g., PII, financial).
Identify Threats Using STRIDE
Apply the STRIDE methodology to each element in the DFD. For each process, data store, data flow, and external entity, ask: Can it be spoofed? Tampered? Repudiated? Can it lead to information disclosure? DoS? Elevation of privilege? List all potential threats. For example, a web server process is susceptible to spoofing if authentication is weak, and to tampering via input validation flaws. The exam tests your ability to map a given vulnerability to the correct STRIDE category. Remember: STRIDE is a mnemonic, not a scoring system. Do not confuse it with DREAD.
Prioritize Threats with DREAD
For each identified threat, assign a numeric score (1-10) for each DREAD category: Damage, Reproducibility, Exploitability, Affected Users, Discoverability. Sum the scores to get a total risk rating (5-50). Prioritize threats with higher scores. The exam may ask you to calculate or interpret a DREAD score. Be careful: DREAD is subjective and can vary by assessor. In practice, many organizations use a simplified High/Medium/Low rating. DREAD is less common now, but the exam still tests it. Know that a score of 40+ is critical, 20-40 is high, below 20 is medium/low.
Define Scope and Rules of Engagement
Based on the prioritized threat list, decide which threats will be tested during the penetration test. This defines the scope. For example, if a threat related to SQL injection on a public-facing web app is rated critical, include SQL injection testing in the scope. If a threat involves physical access to a data center, and the client does not allow physical testing, mark it as out of scope. Document the rules of engagement: what techniques are allowed (e.g., social engineering? DoS?), what systems are off-limits, and what times testing can occur. The exam emphasizes that threat modeling directly informs the scoping document and rules of engagement.
Document and Iterate
Create a threat model report that includes the DFD, threat list, DREAD scores, and scope decisions. This report becomes part of the penetration test plan. Threat modeling is not a one-time activity; as the test progresses, new threats may emerge, or the client may provide additional information. Update the threat model accordingly. The exam expects you to understand that threat modeling is iterative and should be revisited if the target environment changes (e.g., a new application version is deployed). Documentation is key for compliance and for justifying why certain tests were performed or omitted.
Enterprise Scenario 1: E-Commerce Platform Migration
A large retailer is migrating its e-commerce platform from on-premises to AWS. The penetration testing team is brought in early during the design phase. The team conducts threat modeling using PASTA to align with business objectives (protect customer PII and payment data). They create a DFD showing data flows from the user's browser through CloudFront, ALB, EC2 web servers, RDS database, and third-party payment processor. Trust boundaries are identified at the ALB (external to internal) and between EC2 and RDS. STRIDE analysis reveals threats like: spoofing via stolen session tokens (high), tampering of product prices via API (critical), and information disclosure through misconfigured S3 buckets (high). DREAD scoring prioritizes the API tampering threat (score 45). The penetration test scope is defined to include API fuzzing, session management testing, and S3 bucket permission audits. The test is scheduled during low-traffic hours. During testing, the team discovers an S3 bucket with public write access, validating the threat model. The client remediates before go-live.
Enterprise Scenario 2: Financial Services Internal Network
A bank wants to test its internal network for lateral movement risks. The threat model is built using attack trees. The root goal is 'Attacker gains access to core banking database'. Sub-goals include: compromise a workstation, escalate privileges, move laterally to database server, extract data. Each sub-goal is assigned a difficulty and detection likelihood. The model highlights that workstations are highly vulnerable due to legacy OS. The penetration test focuses on phishing to get initial access, then using tools like Mimikatz for privilege escalation and PsExec for lateral movement. The threat model also identifies a trust boundary between the workstation VLAN and the database VLAN. The test scope includes attempts to cross that boundary. During the test, the team successfully moves from a workstation to the database server, confirming the threat model's prediction. The bank uses the findings to implement network segmentation and endpoint hardening.
Common Misconfigurations and Failures
Incomplete DFDs: Missing trust boundaries or external entities leads to overlooked threats. For example, failing to include the payment processor as an external entity might miss threats related to data leakage to third parties.
Over-reliance on automated tools: Tools like Microsoft TMT generate many generic threats; without manual review, critical context-specific threats (e.g., business logic flaws) are missed.
Not updating the model: When the client adds a new feature (e.g., a mobile app endpoint), the threat model must be updated. Otherwise, the penetration test may miss new attack vectors.
Ignoring business impact: A threat with low technical severity (e.g., a slow DoS) might have high business impact (e.g., loss of revenue during Black Friday). The exam expects you to consider business context in prioritization.
PT0-002 Objective 1.1: Plan and Scope an Assessment
The exam tests your ability to select and apply threat modeling methodologies to define the scope of a penetration test. Specifically, you must:
Identify which threat modeling methodology (STRIDE, DREAD, PASTA, Attack Trees) is appropriate for a given scenario.
Understand the steps of each methodology and their outputs.
Interpret a data flow diagram and identify trust boundaries.
Use threat prioritization to justify scope decisions.
Most Common Wrong Answers and Why Candidates Choose Them
Confusing STRIDE with DREAD: A question might describe a scoring system and ask 'Which threat modeling methodology is being used?' The wrong answer is STRIDE because the candidate remembers the acronym but not that DREAD is for scoring. Why: STRIDE is more famous, but DREAD is the scoring system. Tip: If the question mentions numeric scores (1-10), it's DREAD.
Choosing STRIDE for a risk-driven scenario: When the scenario emphasizes business impact and alignment with objectives, the correct answer is PASTA, not STRIDE. Why: Candidates default to STRIDE because it's the most common. Tip: Look for keywords like 'business objectives' or 'risk analysis' to choose PASTA.
Misidentifying trust boundaries: A DFD might show a firewall but the trust boundary is incorrectly placed. Candidates might think the firewall itself is the boundary, but the boundary is the line that data crosses. Tip: Trust boundaries are where security policies change; firewalls enforce boundaries, but the boundary is the conceptual line.
Thinking threat modeling is only for software: The exam may present a network infrastructure scenario. Candidates might think STRIDE is only for apps. Reality: STRIDE can be applied to any system, including networks. However, for network-focused threat modeling, Attack Trees may be more appropriate.
Specific Numbers, Values, and Terms That Appear Verbatim on the Exam
STRIDE: 6 categories – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
DREAD: 5 categories – Damage, Reproducibility, Exploitability, Affected Users, Discoverability.
PASTA: 7 stages – Define objectives, Define technical scope, Decompose application, Analyze threats, Analyze vulnerabilities, Analyze attacks, Analyze risk.
Attack Trees: Root node is the ultimate goal; leaf nodes are sub-goals.
Data Flow Diagram elements: External Entity, Process, Data Store, Data Flow.
Trust Boundary: A line that separates different trust levels.
Edge Cases and Exceptions the Exam Loves to Test
When to use multiple methodologies: In some scenarios, you might use STRIDE to identify threats and DREAD to prioritize them. The exam may ask 'Which combination is best?'
Threat modeling for cloud vs. on-premises: The methodology is the same, but the exam may include cloud-specific threats (e.g., misconfigured IAM roles).
Threat modeling for IoT: Includes physical threats (tampering with devices) that may not be in scope for a standard pen test.
Out-of-scope threats: Even if a threat is identified, the client may exclude it from testing (e.g., social engineering). The exam tests that you respect the rules of engagement.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If the question asks for a methodology that produces a numeric risk score, eliminate STRIDE and Attack Trees (they don't score).
If the question asks for a methodology that focuses on business objectives, eliminate STRIDE (it's threat-centric, not risk-centric).
If the question shows a diagram with nodes and arrows, look for trust boundaries. If the boundary is missing, the answer is likely 'incomplete DFD'.
If the question describes a process of breaking down the system into components and analyzing each, the answer is likely 'decomposition' as part of threat modeling.
Threat modeling is a structured process to identify and prioritize threats before penetration testing.
STRIDE has 6 categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
DREAD has 5 categories: Damage, Reproducibility, Exploitability, Affected Users, Discoverability, each scored 1-10.
PASTA is a 7-stage risk-centric methodology that aligns with business objectives.
Attack trees model attack paths with root as the goal and leaves as sub-goals.
Data flow diagrams must include external entities, processes, data stores, data flows, and trust boundaries.
Threat modeling directly informs the penetration test scope and rules of engagement.
Common wrong answers on the exam confuse STRIDE with DREAD or misidentify trust boundaries.
Threat modeling is iterative and should be updated when the system changes.
The exam expects you to choose the appropriate methodology based on the scenario (e.g., PASTA for risk-driven, STRIDE for app-focused).
These come up on the exam all the time. Here's how to tell them apart.
STRIDE
Classifies threats into 6 categories (Spoofing, Tampering, etc.)
Does not assign numeric scores
Focuses on threat type identification
Best used during decomposition and threat identification phase
Output is a list of threats per component
DREAD
Scores threats using 5 criteria (Damage, Reproducibility, etc.)
Assigns numeric values (1-10) for prioritization
Focuses on risk prioritization
Best used after threat identification to prioritize
Output is a numeric risk score (5-50)
PASTA
Risk-centric, aligns with business objectives
7-stage process from objectives to residual risk
Involves stakeholders from business units
Output includes risk mitigation strategies
More comprehensive but time-consuming
STRIDE
Threat-centric, focuses on technical threats
6 categories applied per element
Typically performed by security team alone
Output is a list of threats
Faster and easier to apply
Mistake
Threat modeling is the same as vulnerability scanning.
Correct
Threat modeling identifies potential threats (e.g., 'an attacker could exploit weak authentication'), while vulnerability scanning identifies specific vulnerabilities (e.g., 'CVE-2023-1234 exists'). Threat modeling is a higher-level, proactive analysis; vulnerability scanning is a reactive detection of known issues.
Mistake
STRIDE is a scoring system used to prioritize threats.
Correct
STRIDE is a classification system for threat types, not a scoring system. DREAD is the scoring system that assigns numeric values to prioritize threats. Mixing these up is a common exam trap.
Mistake
Once created, a threat model does not need to be updated.
Correct
Threat models must be updated when the system changes (e.g., new features, infrastructure changes) or when new threats emerge. The penetration test plan should be revisited accordingly.
Mistake
Attack trees are only useful for physical security.
Correct
Attack trees can model any attack path, including cyber attacks. They are particularly useful for modeling multi-step attacks like lateral movement or advanced persistent threats (APTs).
Mistake
PASTA is only for web applications.
Correct
PASTA is a risk-centric methodology that can be applied to any system, including networks, cloud environments, and IoT. Its seven stages are adaptable to various contexts.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
STRIDE is a threat classification system that categorizes threats into six types (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). DREAD is a risk scoring system that assigns numeric values (1-10) to five criteria (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) to prioritize threats. STRIDE identifies what threats exist; DREAD ranks them. On the exam, if you see a numeric score, it's DREAD; if you see a list of threat types, it's STRIDE.
A DFD includes four main elements: external entities (rectangles), processes (circles or ovals), data stores (two parallel lines), and data flows (arrows). Trust boundaries are drawn as dashed lines. Start by identifying the system boundary and all external entities (users, third-party services). Then map the processes (web server, app server, database) and data stores (databases, files). Connect them with data flows showing the direction of data. Mark trust boundaries where data crosses from one security zone to another (e.g., from the internet to the internal network). The exam may ask you to identify missing elements or incorrect trust boundaries.
PASTA stands for Process for Attack Simulation and Threat Analysis. Its seven stages are: 1) Define security objectives, 2) Define technical scope, 3) Decompose the application, 4) Analyze threats, 5) Analyze vulnerabilities, 6) Analyze attacks, and 7) Analyze risk. Each stage builds on the previous, culminating in a risk analysis that aligns with business objectives. The exam may test the order or ask which stage involves defining objectives (stage 1).
Yes, it is common to combine methodologies. For example, you might use STRIDE to identify threats and DREAD to prioritize them. Or use attack trees to model complex attack paths after a PASTA decomposition. The exam may present a scenario where the best approach is a combination. Look for clues: if the scenario requires both identification and scoring, STRIDE + DREAD is appropriate.
Threat modeling helps define what is in scope and what is out of scope for the penetration test. For example, if a threat involves social engineering but the client does not allow it, that threat is marked out of scope. The rules of engagement specify which techniques are allowed (e.g., no DoS, no physical access) based on the threat model's risk assessment. The exam expects you to know that threat modeling directly informs the scoping document.
Trust boundaries are conceptual lines that separate areas with different trust levels. For example, the boundary between the internet and a corporate network, or between a web server and a database server. Data crossing a trust boundary is a potential attack vector. In threat modeling, identifying trust boundaries is crucial because threats often involve crossing these boundaries. The exam may ask you to identify trust boundaries in a DFD or explain why a missing boundary leads to incomplete threat analysis.
No, threat modeling can be applied to any system, including network infrastructure, cloud environments, IoT devices, and even physical security. The PT0-002 exam covers threat modeling in the context of penetration testing planning, which can involve any type of target. However, the methodologies (STRIDE, PASTA, Attack Trees) were originally developed for software but are adapted for other systems.
You've just covered Threat Modelling for PenTest Planning — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?