Link to the Pentest Methodologies and Reporting path in TryHackMe: Threat Modeling for Pentesters
Introduction
It is your first week at a security consultancy, and the team lead drops a 50-page scope document on your desk. The client is Stratford Systems, a mid-sized financial services company. They want a penetration test of their customer-facing payment portal and supporting infrastructure. The engagement window is ten business days. The team lead looks at you and asks: "Where do you start?"
The instinct is to fire up nmap and start scanning. Resist it.
Stratford's network has hundreds of hosts, dozens of services, and multiple application layers. Ten business days is not enough to test everything. If you start scanning blindly, you will spend three days mapping low-priority internal file shares while the payment database with 200,000 customer credit card records sits untouched. The client's CISO does not care that you found a missing patch on a print server. They care about whether an attacker can reach the data that keeps their business alive.
This is the problem that threat modeling solves. Before you run a single scan, you build a structured understanding of what the client needs to protect, what could go wrong, and where to focus your limited testing time. A threat model is not a compliance checkbox or an architect's exercise; for a penetration tester, it is a targeting document. It transforms a vague scope into a prioritized attack plan.
Where Threat Modeling Fits in the Pentest Lifecycle
The Penetration Testing Execution Standard(opens in new tab) (PTES) defines seven phases that structure a professional engagement from start to finish:
Pre-Engagement Interactions
Intelligence Gathering
Threat Modeling
Vulnerability Analysis
Exploitation
Post-Exploitation
Reporting
Threat modeling sits at Phase 3, after you have gathered intelligence about the target but before you begin active vulnerability analysis or exploitation. This placement is deliberate. Intelligence gathering tells you what exists on the network; threat modeling tells you what matters and what to target first. Without it, vulnerability analysis becomes a scattershot exercise, and exploitation lacks strategic direction.
Consider the Stratford engagement. After intelligence gathering, you know the company runs a public-facing web application called StratPay Portal, an internal API gateway, an Active Directory domain (stratford.local), a SQL Server database cluster, and a VPN-accessible admin dashboard. That is a lot of surface area. Threat modeling is where you decide which components represent the highest risk to the business and deserve the most testing time.
Learning Objectives
By the end of this room, you will be able to:
Explain why threat modeling is a critical pre-engagement activity for penetration testers
Identify where threat modeling sits in the Penetration Testing Execution Standard (PTES) lifecycle
Describe the four-question framework that underpins all threat modeling methodologies
Recognize the three frameworks covered in this room and their complementary roles
Prerequisites
This room targets users with basic knowledge of cyber security along with familiarity with network architecture concepts. In particular, we recommend:
Four Questions and Three Frameworks
You've seen why the Stratford engagement demands a threat model; now let's look at the questions and frameworks that will structure it.
The Four Questions
At its core, every threat modeling methodology answers the same four questions. These were formalized by Adam Shostack, who led threat modeling at Microsoft's Security Development Lifecycle (SDL), and they serve as the universal backbone regardless of which specific framework you use:
What are we working on? Decompose the system into its components, data flows, and boundaries. Understand the architecture before you attack it.
What can go wrong? Systematically identify threats against each component. This is where frameworks like STRIDE, PASTA, and MITRE ATT&CK provide structure.
What are we going to do about it? Determine the response for each identified threat: mitigate, eliminate, transfer, or accept the risk.
Did we do a good enough job? Validate your analysis, review completeness, and update the model as the system evolves.
For penetration testers, questions 1 and 2 directly drive your test plan. Question 3 informs the recommendations section of your report. Question 4 connects to the re-testing phase, where validated findings trigger remediation and verification.
These four questions also anchor the Threat Modeling Manifesto, published in 2020(opens in new tab) by a group of 15 industry practitioners. The Manifesto established shared values for the discipline, including prioritizing finding and fixing design issues over checkbox compliance, and emphasizing that doing threat modeling matters more than debating which methodology is best.
Three Frameworks, Three Perspectives
This room covers three frameworks that answer question 2 ("What can go wrong?") from different angles. Each one adds a layer of depth that the others lack:
STRIDE answers the question with systematic categories. It gives you a structured checklist of six threat types (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and a method for applying them to every component in your target architecture. You will also learn DREAD, a companion scoring model that helps prioritize the threats STRIDE identifies.
PASTA (Process for Attack Simulation and Threat Analysis) answers the question with business risk context. Its seven-stage process starts from the client's business objectives and works toward technical threats, ensuring your pentest priorities align with what the organization actually cares about.
MITRE ATT&CK answers the question with real adversary intelligence. Instead of theoretical categories, ATT&CK catalogs the specific tactics and techniques that observed threat groups use in the wild. If Stratford Systems operates in financial services, ATT&CK tells you exactly which attack techniques groups like FIN7 have used against similar organizations.
None of these frameworks is a silver bullet on its own. STRIDE is systematic but does not prioritize. PASTA is thorough but time-intensive. ATT&CK is evidence-based but requires threat intelligence maturity. Used together, they give you a layered, actionable threat model that translates directly into a penetration test plan.
Let's build that model. In the next task, we start with the shared vocabulary that all three frameworks depend on: assets, data flows, and trust boundaries.
Answer the questions below
What is the name of the framework that uses six threat categories including Spoofing and Tampering? STRIDE
The Building Blocks: Assets, Data Flows, and Trust Boundaries
Every framework in this room, whether it is STRIDE, PASTA, or MITRE ATT&CK, depends on the same foundational vocabulary. Before you can identify threats, score them, or map them to real adversary behavior, you need to understand what you are analyzing and how its pieces connect. This task introduces the building blocks that make structured threat modeling possible.
Assets: What Are We Protecting?
Consider a bank's physical security. The building has a lobby, teller windows, a back office, a vault, and a loading dock. Each area holds different things of value, and the security controls in each area reflect that. You do not protect the lobby the same way you protect the vault. The same principle applies to digital systems.
In threat modeling, an asset is anything of value that an attacker might target or that the organization needs to protect. For penetration testers, assets fall into three categories:
Data assets are the information the system stores, processes, or transmits. For Stratford Systems, these include customer Personally Identifiable Information (PII), payment card numbers, authentication credentials, and transaction logs. Data assets are often the primary target; they are what attackers monetize.
System assets are the infrastructure components that host and move data. Servers, databases, APIs, network devices, and cloud services all qualify. Compromising a system asset is often a means to reach a data asset, not an end in itself.
Business process assets are the workflows and operations that generate revenue or maintain compliance. For Stratford, the payment processing workflow is a business process asset. If an attacker disrupts it, the company loses revenue regardless of whether any data is stolen.
As a pentester, your threat model should identify assets in all three categories. The client's scope document and pre-engagement conversations will tell you which ones matter most, but a structured asset inventory ensures nothing critical gets overlooked.
Data Flow Diagrams: Mapping the System
Once you know what assets exist, you need to understand how they connect. A Data Flow Diagram (DFD) is a visual representation of how data moves through a system. DFDs were originally developed in the 1970s for software engineering, but the security community adopted and extended them by adding one critical element: trust boundaries.
A DFD uses five element types, each with a standard visual notation:
| Element |
Symbol |
What It Represents |
Example |
| External Entity |
Rectangle |
A user, system, or service outside your control |
Customer's web browser, third-party payment processor |
| Process |
Circle |
Application logic that transforms or acts on data |
StratPay web application, API gateway |
| Data Store |
Parallel lines |
A repository where data persists at rest |
SQL Server database, Active Directory, log files |
| Data Flow |
Arrow |
A connection over which data moves between components |
HTTPS request, API call, database query |
| Trust Boundary |
Dashed line |
A border where the level of trust changes |
Internet ↔ DMZ, DMZ ↔ internal network |
These five elements are all you need to model any system at any level of abstraction. Simple systems may have a single DFD; complex environments like Stratford's require multiple diagrams at different levels of detail.
Building a DFD: The StratPay Portal
Let's build a DFD for the Stratford Systems architecture we will use throughout this room. We will start with the StratPay Portal, the customer-facing payment processing application, and map it step by step.
Step 1 — Identify the External Entity
The customer interacting with StratPay through their web browser is an external entity. We draw a rectangle labeled "Customer (Browser)" on the left side of our diagram. The customer is outside Stratford's control; we cannot dictate what browser they use, whether their machine is compromised, or whether their connection is secure.
Step 2 — Draw the First Trust Boundary
Between the customer's browser and Stratford's infrastructure lies the public Internet. When data crosses from the Internet into Stratford's DMZ (Demilitarized Zone), it transitions from an untrusted context to a semi-trusted one. We draw a dashed line labeled "Internet ↔ DMZ" between the customer and the first internal component.
Step 3 — Add the First Process
Inside the DMZ sits the StratPay Web Application, which receives customer requests, validates input, and handles the user interface. This is a process (circle) because it transforms data: it takes raw HTTP requests and converts them into structured operations.
Step 4 — Draw the Second Trust Boundary
The StratPay Web Application communicates with backend services on the internal network. This transition from the DMZ to the internal network is another trust boundary, drawn as a dashed line labeled "DMZ ↔ Internal Network."
Step 5 — Add the Second Process
On the internal network side, the Internal API Gateway receives requests from the web application and routes them to the appropriate backend service. This is another process; it validates, authenticates, and forwards API calls.
Step 6 — Add Data Flows
Arrows connect each component, showing how data moves:
Customer → StratPay Web App (HTTPS request containing payment details)
StratPay Web App → Internal API Gateway (API call with transaction data)
Internal API Gateway → SQL Server Database (database query)
Step 7 — Add the Data Store
The SQL Server Database cluster stores customer PII, payment card data, and transaction history. We represent it with parallel lines on the right side of the diagram.
The resulting DFD looks like this image drawn using Threat Dragon(opens in new tab).
[Customer] ──HTTPS──> | (StratPay Web App) ──API──> | (API Gateway) ──SQL──> ║ SQL Server DB ║
Internet↔DMZ DMZ↔Internal
This is a simplified Level 1 DFD. In a real engagement, you would expand each process into its own sub-diagram showing internal logic, authentication mechanisms, and error handling paths. For this room, the Level 1 view gives us enough structure to apply all three frameworks.
Trust Boundaries: Where Vulnerabilities Concentrate
Trust boundaries deserve special attention because they are where most vulnerabilities live. Every time data crosses a trust boundary, it moves between zones with different levels of trust, and that transition creates opportunity for exploitation.
Consider the boundary between the customer's browser and the StratPay Web Application. On the customer's side, all data is untrusted; a malicious user can craft any HTTP request they want. On the StratPay side, the application must decide what to trust. If the application fails to validate input at this boundary, the result is injection attacks, cross-site scripting, parameter manipulation, and a long list of vulnerabilities you have already studied in the Web Application Security modules of this path.
The same logic applies at every boundary in the diagram. The DMZ-to-internal boundary is where an attacker who has compromised the web application attempts to pivot deeper. The internal network boundary around the database is where access control either holds or fails.
As a pentester, trust boundaries on a DFD are your initial target list. Every data flow crossing a trust boundary is a point where security controls must exist and where you should test whether they actually work. This is why building an accurate DFD is not just an academic exercise; it is the foundation of your engagement's test plan.
Attack Surface
The attack surface of a system is the total set of points where an unauthorized user can attempt to enter data, extract data, or interact with the system. If trust boundaries tell you where controls should exist, the attack surface tells you how many entry points an attacker has to work with.
In a DFD, the attack surface includes:
Every external entity's connection to an internal process (the customer's HTTPS connection to StratPay)
Every data flow that crosses a trust boundary (the API calls between the DMZ and internal network)
Every exposed service or endpoint that accepts input (login forms, API endpoints, file upload handlers)
A smaller attack surface is easier to defend and easier to test. Part of your threat modeling work is identifying whether the attack surface is larger than it needs to be. Does the admin dashboard need to be accessible over VPN, or could it be restricted to a hardened jump box? Does the API gateway expose endpoints that are only used internally? These are questions that arise naturally from mapping the attack surface on a DFD.
You do not need specialized software to build a DFD. In practice, pentesters use a range of tools depending on formality and audience:
OWASP Threat Dragon is a free, open-source tool specifically designed for security-focused DFDs. It supports STRIDE-based threat annotation directly on the diagram and runs as both a web application and a desktop app.
Microsoft Threat Modeling Tool is a free Windows application that auto-generates STRIDE threats from DFD elements. It is useful for structured workshops but limited to Windows.
Draw.io or Excalidraw works well for quick sketches during scoping calls or informal threat modeling sessions. These general-purpose diagramming tools lack security-specific features but are fast and collaborative.
For the static site exercises in this room, we provide pre-built DFDs. In the field, building your own DFDs from architecture documentation and stakeholder interviews is a core skill that improves with practice.
Answer the questions below
What DFD element is represented by a dashed line? Trust boundary
Which DFD element type is used to represent application logic that transforms or acts on data? Process
STRIDE: Systematic Threat Identification
You have a DFD. You have trust boundaries. Now you need a systematic way to ask the right questions about every component on that diagram. Without a framework, threat identification becomes a brainstorming session that depends entirely on whoever happens to be in the room. An experienced pentester might spot a dozen threats; a junior tester might spot three, and they might not overlap at all. This inconsistency is a problem when clients are paying for thorough coverage.
STRIDE solves this by giving you a structured checklist of six threat categories to evaluate against every element in your DFD. It works whether you have been pentesting for ten years or ten days.
Origins
STRIDE was created in 1999 by Loren Kohnfelder and Praerit Garg at Microsoft. Adam Shostack later popularized it through Microsoft's Security Development Lifecycle (SDL), embedding it as the default threat identification method in the Microsoft Threat Modeling Tool. The framework has remained unchanged since its creation; the six categories are as relevant today as they were 25 years ago because they map directly to the fundamental properties of secure systems.
The Six Categories
Each STRIDE category represents a specific way that a security property can be violated. For penetration testers, each category also translates into a concrete question you should ask about every component in scope.
Spoofing - Violates Authentication
Can an attacker impersonate a legitimate user or system?
Spoofing occurs when an attacker pretends to be someone or something they are not, bypassing authentication controls to gain unauthorized access. This includes credential theft, session hijacking, IP spoofing, and forged authentication tokens.
Real-world anchor: In February 2024, attackers compromised Change Healthcare(opens in new tab) by using stolen credentials to access a Citrix remote access portal that lacked Multi-Factor Authentication (MFA). The attackers impersonated a legitimate user, moved laterally for nine days, and ultimately deployed ransomware that compromised 190 million healthcare records. A threat model of the Citrix portal would have flagged the absence of MFA as a spoofing risk at the external trust boundary.
Tampering - Violates Integrity
Can an attacker modify data in transit or at rest?
Tampering covers any unauthorized modification of data, whether it is intercepting and altering network traffic, manipulating database records, injecting malicious code, or modifying configuration files.
Real-world anchor: The SolarWinds attack(opens in new tab), disclosed in December 2020, involved a Russian APT group injecting the Sunburst backdoor into the Orion software build pipeline. The compromised updates were distributed to over 30,000 organizations, including multiple US government agencies. The attackers tampered with the software supply chain itself, and the malicious code persisted undetected for over a year. Threat modeling the build and distribution pipeline would have identified code integrity verification as a critical control at each stage.
Repudiation - Violates Non-Repudiation
Can an attacker perform actions without being traced?
Repudiation threats arise when a system cannot prove that a specific action was performed by a specific actor. If logging is insufficient, disabled, or easily tampered with, an attacker can act without leaving a reliable audit trail. This makes incident response slower and forensic reconstruction difficult.
Real-world anchor: The National Public Data breach in 2024(opens in new tab) involved attackers exfiltrating 2.9 billion records through low-volume API queries designed to avoid triggering alerts. Without adequate logging and anomaly detection, the organization could not reconstruct the timeline of exfiltration for months. IBM's 2025 research found that organizations without centralized logging take significantly longer to identify and contain breaches.
Information Disclosure - Violates Confidentiality
Can an attacker access data they should not see?
Information disclosure covers any scenario where sensitive data is exposed to unauthorized parties. This includes SQL injection that dumps database contents, directory traversal that exposes configuration files, verbose error messages that reveal internal architecture, and insecure API responses that return more data than intended.
Real-world anchor: In May 2023, the CL0P ransomware group(opens in new tab) exploited a SQL injection zero-day (CVE-2023-34362) in MOVEit Transfer, a managed file transfer application. The vulnerability allowed attackers to extract data from over 1,062 organizations, affecting more than 65 million individuals, including employees of the BBC, British Airways, and the US Department of Energy. A DFD of the file transfer workflow would have identified SQL injection risk at the web interface trust boundary.
Denial of Service - Violates Availability
Can an attacker disrupt service for legitimate users?
Denial of Service (DoS) threats target the availability of a system, making it unresponsive or entirely unavailable. This includes network-level volumetric attacks, application-layer resource exhaustion, logic bombs, and targeted crashes triggered by malformed input.
Real-world anchor: The Mirai botnet(opens in new tab), originally responsible for a 620 Gbps attack in 2016, continues to evolve. In 2024, Cloudflare(opens in new tab) blocked a record-setting Distributed Denial of Service (DDoS) attack peaking at 5.6 Terabits per second, launched from over 13,000 compromised IoT devices. Cloudflare reported blocking 21.3 million DDoS attacks in 2024, a 53% increase over the prior year.
Elevation of Privilege - Violates Authorization
Can an attacker gain permissions beyond their intended role?
Elevation of Privilege (EoP) occurs when an attacker escalates from a lower privilege level to a higher one, gaining access to functionality or data they were never meant to reach. This includes exploiting broken access controls, kernel vulnerabilities, misconfigured permissions, and application logic flaws.
Real-world anchor: Log4Shell (CVE-2021-44228)(opens in new tab), disclosed in December 2021, allowed remote code execution through a JNDI lookup injection in the widely used Apache Log4j library. An attacker who could control a single log message could execute arbitrary code with the full privileges of the application. Over 830,000 attack attempts were detected within 72 hours of public disclosure. A DFD showing user input flowing through the application to Log4j and then to an external JNDI/LDAP server would have exposed the trust boundary violation where user-controlled data triggered an unrestricted external lookup.
The DFD-to-STRIDE Mapping Table
Not every STRIDE category applies to every DFD element. The following mapping table, derived from the original Microsoft SDL guidance, defines which categories are relevant for each element type:
| DFD Element |
Spoofing |
Tampering |
Repudiation |
Info Disclosure |
DoS |
EoP |
| External Entity |
✓ |
|
✓ |
|
|
|
| Process |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
| Data Flow |
|
✓ |
|
✓ |
✓ |
|
| Data Store |
|
✓ |
✓* |
✓ |
✓ |
|
Two observations stand out. First, processes are susceptible to all six STRIDE categories, making them the highest-priority elements in any analysis. Every process on your DFD should receive full STRIDE treatment. Second, the asterisk on Data Store / Repudiation reflects a specific case: data stores are generally not subject to repudiation threats unless the data store serves as an audit log. If an attacker can tamper with log files, they can erase evidence of their actions, which is a repudiation threat enabled by tampering.
Two Analysis Approaches
STRIDE can be applied in two ways, and the choice matters when you are working under time constraints.
STRIDE-per-Element visits every component on the DFD and checks each applicable STRIDE category. This is comprehensive but time-intensive. For a DFD with 15 elements, you are evaluating up to 90 threat combinations (15 elements × 6 categories, minus the non-applicable cells from the mapping table). This approach works well for smaller systems or high-assurance environments where thoroughness is more important than speed.
STRIDE-per-Interaction focuses specifically on data flows that cross trust boundaries. Instead of analyzing every element, you analyze every interaction between elements in different trust zones. For penetration testers, this is often the more efficient choice because trust-boundary-crossing data flows are exactly where vulnerabilities concentrate, as we discussed in Task 2.
For the Stratford engagement, STRIDE-per-Interaction would focus your analysis on three critical data flows: the customer-to-web-application connection (Internet ↔ DMZ), the web-application-to-API-gateway connection (DMZ ↔ Internal), and the API-gateway-to-database connection (Internal ↔ Database). These three interactions cover the highest-risk attack paths without requiring you to individually analyze every internal component.
Applied Walkthrough: STRIDE Against the StratPay Web Application
Let's apply STRIDE to the StratPay Web Application process from the Task 2 DFD. As a process, it is susceptible to all six categories:
Spoofing: Can an attacker impersonate a legitimate customer? The web application authenticates users through a login form. If session tokens are predictable, cookies lack secure flags, or the application is vulnerable to credential stuffing, an attacker could assume another customer's identity.
Tampering: Can payment data be modified in transit? If TLS is misconfigured or the application accepts unsigned parameters, an attacker could intercept and alter transaction amounts, recipient account numbers, or other payment details through parameter manipulation or man-in-the-middle positioning.
Repudiation: Can a transaction be performed without an audit trail? If the application does not log transaction events with sufficient detail (timestamps, source IPs, user identifiers, action performed), a disputed transaction cannot be reliably attributed. For a payment system subject to PCI DSS, this is a compliance failure as well as a security gap.
Information Disclosure: Can an attacker extract other customers' payment data? Insecure Direct Object Reference (IDOR) vulnerabilities, SQL injection, or overly verbose API responses could allow an attacker to access records belonging to other customers. Error messages that reveal database structure or internal paths also fall under this category.
Denial of Service: Can the payment portal be overwhelmed? Application-layer attacks targeting expensive operations (complex search queries, large file uploads, or computationally intensive payment validation routines) could exhaust server resources without requiring massive bandwidth.
Elevation of Privilege: Can a regular customer access admin functions? Broken access control, missing authorization checks on admin API endpoints, or client-side-only role enforcement could allow a standard user to access the admin dashboard or perform privileged operations like issuing refunds.
Each of these identified threats becomes a potential test case in your penetration test plan. STRIDE does not tell you which of these to test first; that is what DREAD, the subject of the next task, provides.
Limitations of STRIDE
STRIDE is powerful, but it is not perfect. Honest assessment of a framework's limitations is part of professional practice:
No built-in prioritization. STRIDE identifies threats but does not rank them by severity or likelihood. A list of 30 threats with no priority guidance is not actionable without a companion scoring model.
Resource-intensive for complex systems. A microservices architecture with 50 services, each with its own DFD, generates hundreds of threat combinations. Without scoping discipline, the analysis can become unwieldy.
Static and design-time focused. STRIDE analyzes the system as designed, not as it behaves at runtime. It does not account for zero-day vulnerabilities, configuration drift, or dynamic attack patterns that emerge from unexpected interactions.
Quality depends on DFD accuracy. An incomplete or inaccurate DFD produces an incomplete threat model. If you miss a data flow or misplace a trust boundary, the corresponding threats go unidentified.
These limitations are not reasons to avoid STRIDE; they are reasons to complement it with other approaches. The next three tasks introduce tools that address each gap: DREAD for prioritization, PASTA for business context, and MITRE ATT&CK for evidence-based adversary intelligence.
Answer the questions below
Which STRIDE category directly violates the security property of integrity? Tampering
During your STRIDE analysis of the StratPay Portal, you discover that the application does not log failed authentication attempts. Which STRIDE category does this logging gap fall under? Repudiation
According to the DFD-to-STRIDE mapping table, which DFD element type is susceptible to all six STRIDE categories? Process
Scoring Threats with DREAD
After running STRIDE against the StratPay Portal in the previous task, your team identified 23 potential threats across six categories. The project manager looks at the list and asks the question that every pentester hears on a time-boxed engagement: "Which ones do we test first?"
STRIDE is excellent at identifying what can go wrong, but it does not tell you how bad each threat is. A spoofing threat against the customer login and a denial of service threat against an internal monitoring dashboard are both valid STRIDE findings, but they are not equally urgent. You need a way to score and rank threats so your limited testing time goes where it matters most.
DREAD is a lightweight risk scoring model designed to do exactly that. It gives you a fast, repeatable method for prioritizing threats during a threat modeling session.
Origins and Deprecation
DREAD was published in 2002 in Writing Secure Code (2nd edition) by Michael Howard and David LeBlanc at Microsoft. It was originally used alongside STRIDE as part of Microsoft's internal security review process.
Here is the part where we are transparent about history. Microsoft internally discontinued DREAD around 2008. Adam Shostack, who owned SDL threat modeling at Microsoft, explained the reasoning: different teams assigned wildly different scores to the same threat, making cross-team comparisons unreliable. One team's "7" was another team's "4," and the arguments about scoring consumed time that should have been spent analyzing threats. Microsoft replaced DREAD with a simpler approach, predefined severity classifications of Critical, Important, Moderate, and Low, based on specific vulnerability characteristics rather than subjective numerical ratings.
Despite this deprecation, DREAD remains widely used. Fortune 500 companies, military organizations, and penetration testing firms continue to use it for quick triage. More importantly for your career, DREAD is explicitly tested on the CISSP (Domain 1, Objective 1.11) and appears in other certificates' training materials. You will encounter it on certification exams and in professional practice.
The lesson here is not that DREAD is bad. The lesson is that every scoring model has limitations, and understanding those limitations is part of using the model effectively.
The Five Categories
Each DREAD category is scored on a scale of 1 to 10, where 1 represents minimal risk and 10 represents maximum risk.
Damage Potential
How severe is the impact if this threat is successfully exploited?
This category measures the worst-case outcome. A threat that leads to complete database compromise and exfiltration of all customer records scores near 10. A threat that leaks a non-sensitive application version number scores near 1. Consider both data impact (confidentiality, integrity) and operational impact (availability, business disruption).
Scoring guidance:
10: Complete system compromise, full data exfiltration, or total business disruption
5: Partial data exposure, limited system access, or degraded functionality
1: Trivial information leakage with no meaningful impact
Reproducibility
How reliably can the attack be repeated?
A threat that can be triggered every time with the same steps scores high. A threat that depends on a specific race condition, a narrow time window, or unpredictable environmental factors scores low. Reproducibility matters for pentesters because a highly reproducible vulnerability is easier to demonstrate and harder for the client to dismiss.
Scoring guidance:
10: Attack succeeds every time, can be scripted or automated
5: Attack works intermittently or requires specific conditions
1: Attack depends on rare circumstances and is difficult to reproduce on demand
Exploitability
What skill level, access, and tools are required to exploit this threat?
A vulnerability that can be exploited with freely available automated tools and no authentication scores high. A vulnerability that requires deep reverse engineering expertise, custom exploit development, and physical access to the server room scores low.
Scoring guidance:
10: Automated tools exist, no authentication required, scriptable by a beginner
5: Requires authenticated access or moderate technical skill
1: Requires advanced exploit development, zero-day research, or physical access
Affected Users
What proportion of users or systems are impacted if this threat is exploited?
A threat that impacts every customer who has ever used the payment portal scores high. A threat that only affects a single administrator account on a rarely used internal tool scores low. Consider both breadth (how many users) and significance (are the affected users high-value targets like administrators?).
Scoring guidance:
10: All users, including administrators, are affected
5: A significant subset of users or a critical user group is affected
1: A single user in an uncommon configuration is affected
Discoverability
How easy is this vulnerability to find?
A vulnerability that appears in automated scanner output, is visible in the URL, or is documented in a public CVE scores high. A vulnerability that requires deep manual analysis, source code review, or insider knowledge scores low.
Scoring guidance:
10: Visible to automated scanners, documented publicly, or trivially discoverable
5: Requires targeted manual testing or familiarity with the application
1: Requires extensive reverse engineering or access to source code
The Discoverability Controversy
Discoverability is the most debated category in the model, and this debate is worth understanding because it sharpens your thinking about risk assessment in general.
Many security practitioners automatically assign a maximum score of 10 to Discoverability, regardless of the actual difficulty of finding the vulnerability. Their reasoning: assuming a vulnerability is hard to discover is a form of security through obscurity, which is not a reliable defense. A vulnerability might be obscure today and publicized tomorrow when a researcher posts a write-up, a scanner adds a detection rule, or an attacker shares the technique on a forum.
This perspective is compelling enough that OpenStack adopted "DREAD-D", a modified version that drops Discoverability entirely and calculates risk from the remaining four categories. Some OWASP guidance has echoed this recommendation.
The counterargument is that Discoverability captures something real. A vulnerability buried deep in a complex multi-step workflow genuinely is less likely to be found and exploited than one visible in the login URL. Removing the category loses information.
There is no universally correct answer. What matters is that you make a deliberate, documented decision about how your team handles Discoverability and apply that decision consistently across all scored threats. Inconsistency, not the category itself, was the core problem Microsoft identified.
Calculating the Risk Score
The DREAD risk score is the average of all five category scores:
Risk Score = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5
The resulting score maps to a four-tier severity scale:
| Score Range |
Severity Rating |
| 9.0 – 10.0 |
Critical |
| 7.0 – 8.9 |
High |
| 4.0 – 6.9 |
Medium |
| 1.0 – 3.9 |
Low |
Worked Example 1: SQL Injection in the Payment Search Feature
Let's score a SQL injection vulnerability discovered during STRIDE analysis of the StratPay Web Application. The vulnerability exists in the payment search feature, which allows customers to look up past transactions by date and amount.
| Category |
Score |
Reasoning |
| Damage |
9 |
Successful exploitation grants access to the SQL Server database containing customer PII and payment card data. Full data exfiltration is possible. |
| Reproducibility |
8 |
The injection point is consistent and can be scripted with sqlmap. Minor variations in input formatting do not affect reliability. |
| Exploitability |
7 |
SQL injection is a well-documented technique with mature automated tools. The attacker needs no authentication to reach the search feature, though some WAF evasion may be required. |
| Affected Users |
9 |
All customers with stored payment data are impacted. The database does not segment records by customer tier or region. |
| Discoverability |
8 |
The search feature is publicly accessible. Automated scanners detect the injection point, and verbose error messages reveal the database type and query structure. |
Risk Score: (9 + 8 + 7 + 9 + 8) / 5 = 8.2 => High
This threat goes to the top of the test plan. The combination of high damage, broad user impact, and low exploitation barrier makes it a priority.
Worked Example 2: Verbose Error Messages on the Admin Dashboard
Now consider a lower-severity finding: the admin dashboard, accessible only through the VPN, displays detailed stack traces and database connection strings when errors occur.
| Category |
Score |
Reasoning |
| Damage |
3 |
The exposed information (stack traces, connection strings) is useful for further attacks but does not directly compromise data. It is an information disclosure that enables, rather than constitutes, a breach. |
| Reproducibility |
10 |
Triggering an error message is trivial and succeeds every time. Submitting malformed input to any form field produces the verbose output. |
| Exploitability |
9 |
No special tools or skills required. Any authenticated admin user can trigger the error by entering unexpected input. |
| Affected Users |
2 |
Only administrators with VPN access can reach the dashboard. The exposed information affects the organization's security posture rather than individual users. |
| Discoverability |
6 |
The vulnerability requires VPN access and an admin account to reach. It would not appear in an external scan. However, once on the dashboard, the errors are immediately visible. |
Risk Score: (3 + 10 + 9 + 2 + 6) / 5 = 6.0 => Medium
This threat is worth documenting but does not warrant priority testing time. The low Damage and Affected Users scores pull the overall rating down despite high Reproducibility and Exploitability. In your pentest report, you would flag this as a finding that supports further attacks rather than a standalone critical risk.
Comparing the Two Scores
The two examples illustrate why scoring matters. Without DREAD, both threats sit on the same undifferentiated STRIDE list. With DREAD, you can clearly articulate why the SQL injection (8.2, High) demands immediate attention while the verbose error messages (6.0, Medium) can be addressed after higher-priority threats are tested. This is the conversation you will have with project managers and clients throughout your career: not just what is wrong, but how bad it is relative to everything else.
DREAD vs. CVSS: A Brief Comparison
You will encounter the Common Vulnerability Scoring System (CVSS) far more often than DREAD in professional practice. CVSS, currently at version 4.0 (released November 2023(opens in new tab)), is the industry standard used by the National Vulnerability Database(opens in new tab) (NVD), bug bounty platforms, and most commercial security tools.
CVSS is significantly more complex than DREAD. It uses multiple metric groups (Base, Threat, Environmental) with over a dozen individual factors, producing a more consistent and defensible score. Its complexity is also its barrier: a full CVSS assessment requires detailed technical knowledge and takes considerably longer per vulnerability.
DREAD's value is speed and accessibility. During a threat modeling workshop where you need to triage 20 threats in an hour, DREAD's five intuitive categories and simple average calculation get you to a prioritized list fast. CVSS is the right tool for formal vulnerability reporting; DREAD is the right tool for real-time threat modeling triage. They serve different purposes, and professional pentesters use both.
Answer the questions below
What does the "A" in DREAD stand for? Affected Users
You are scoring a Denial of Service vulnerability in the StratPay Portal. The vulnerability can be triggered by anyone on the Internet, requires no authentication, and crashes the entire payment portal affecting all customers. However, it causes no data loss, and the system recovers automatically on restart. Which DREAD category would receive the lowest score? Damage
PASTA: Risk-Centric Threat Modeling
STRIDE told us what could go wrong with each component in our DFD. DREAD told us how bad each threat is. But neither framework asked a critical question: what does the business actually care about?
Consider two identical SQL injection vulnerabilities. One exists in a staging environment used by three developers for testing. The other exists in the StratPay Portal processing live payment transactions for 200,000 customers. Technically, they are the same vulnerability. From a business perspective, they are different by orders of magnitude. A framework that treats them equally is missing context that matters.
PASTA forces you to start from business objectives and work toward technical threats, not the other way around. It is the framework that teaches penetration testers to think like both an attacker and a business advisor.
Origins
PASTA stands for Process for Attack Simulation and Threat Analysis. It was developed by Tony UcedaVélez, CEO of the security firm VerSprite, and first presented at OWASP AppSecEU in 2012. The comprehensive reference is Risk Centric Threat Modeling (Wiley, 2015), co-authored by UcedaVélez and Marco M. Morana.
Where STRIDE is a threat classification tool and DREAD is a scoring tool, PASTA is a complete methodology. It defines a seven-stage process that progresses from business context through technical analysis to risk-quantified output. VerSprite uses PASTA as the foundation for every penetration testing engagement they conduct; the threat model directly informs what gets tested and how findings are communicated.
The Seven Stages
Each PASTA stage builds on the one before it, creating a progressive narrowing from broad business context to specific, prioritized attack paths. Let's walk through all seven stages using the Stratford Systems engagement as our example.
Stage 1 — Define Objectives
What does the business need to protect, and why?
This stage aligns the threat model with the organization's business goals, compliance requirements, and risk appetite. For Stratford Systems, the key business objectives are:
PCI DSS compliance: Stratford processes payment card data and is subject to Payment Card Industry Data Security Standard requirements. A breach involving cardholder data triggers mandatory reporting, potential fines, and possible loss of the ability to process payments.
Customer trust: Stratford's revenue depends on customers trusting the platform with their financial data. A publicized breach erodes that trust and drives customer attrition.
Transaction uptime: Every minute the payment portal is unavailable represents lost revenue. Availability is a direct business concern, not just a technical one.
Pentest connection: Stage 1 answers the question "Why are we doing this pentest?" If the engagement is driven by PCI DSS requirements, your testing priorities and reporting structure will differ from an engagement driven by a recent incident or an upcoming acquisition. This context shapes everything that follows.
Stage 2 — Define Technical Scope
What systems, components, and technologies are in play?
This stage maps the architecture, identifies the attack surface, and inventories the components that support the business objectives defined in Stage 1. For Stratford:
StratPay Portal: Public-facing web application (HTTPS), hosted in the DMZ
Internal API Gateway: Middleware connecting the portal to backend services
SQL Server Database Cluster: Stores customer PII and payment card data
Active Directory (stratford.local): Employee authentication and SSO integration
Admin Dashboard: Internal management interface, accessible via VPN only
Pentest connection: Stage 2 directly informs your scope document and Rules of Engagement. The component inventory becomes the boundary of what you are authorized to test. If the API gateway was not discussed in this stage, it should not appear in your scan targets without explicit client approval.
Stage 3 — Application Decomposition
How does data move through the system, and where are the trust boundaries?
This stage creates the Data Flow Diagrams we built in Task 2. You identify processes, data stores, external entities, data flows, and trust boundaries. If you have already completed your DFDs during a STRIDE analysis, you can reuse them here; PASTA and STRIDE share this foundational artifact.
Pentest connection: The entry points identified during decomposition become your initial target list. Every data flow crossing a trust boundary is a point where you will probe for vulnerabilities.
Stage 4 — Threat Analysis
What threats are realistic for this specific organization and industry?
This is where PASTA diverges significantly from STRIDE. Instead of walking a generic checklist of threat categories, Stage 4 incorporates threat intelligence specific to the client's industry, geography, and technology stack.
For Stratford Systems (financial services), relevant intelligence sources include:
Verizon Data Breach Investigations Report (DBIR): The 2025 report found that 88% of system intrusion breaches in the financial sector involved stolen credentials, and 36% of all breaches originated from third-party compromises.
Industry incident history: The Change Healthcare breach (2024) demonstrated that financial and healthcare organizations are prime targets for ransomware groups using credential theft as an initial vector.
Sector-specific threat patterns: Financial services organizations face elevated risk from credential theft, ransomware, payment fraud, API abuse, and insider threats.
STRIDE can be used within Stage 4 as one input for systematic threat identification. The difference is that PASTA filters STRIDE's output through an intelligence lens: a theoretical denial of service threat against an internal print server gets deprioritized because threat intelligence shows that real attackers targeting financial services focus on credential theft and data exfiltration, not print server disruption.
Pentest connection: Intelligence-driven testing focuses your engagement on realistic threats rather than theoretical ones. If threat intelligence shows that 88% of breaches in your client's sector involve stolen credentials, credential-based attack testing should consume a significant portion of your ten-day engagement window.
Stage 5 — Vulnerability Analysis
What known vulnerabilities exist in the target systems, and how do they relate to the identified threats?
This stage maps known vulnerabilities to the threats identified in Stage 4. Sources include CVE databases, prior vulnerability scan results, configuration reviews, and publicly disclosed issues affecting the client's technology stack.
For Stratford, this might include:
Known SQL injection patterns in the StratPay Portal's web framework
Default or weak configurations on the API gateway management interface
Missing patches on the SQL Server cluster
Weak Kerberos delegation settings in stratford.local
Pentest connection: Stage 5 prioritizes which vulnerabilities to confirm through active testing. Instead of running every check in your scanner's database, you focus on vulnerabilities that map to the threats identified in Stage 4. A known SQL injection in the payment processing workflow (maps to the credential theft and data exfiltration threats) gets tested before a theoretical XML external entity vulnerability in an internal logging service.
Stage 6 — Attack Modeling
How do threats and vulnerabilities chain together into realistic attack paths?
Stage 6 is where PASTA earns its name. You build attack trees that model complete attack scenarios from initial access to final objective. Each tree starts with an attacker's goal at the root and branches into the different paths an adversary could take to achieve it.
Consider the Stratford CISO's stated concern: "I want to know if an attacker who compromises an employee credential can reach our payment database." This translates into the following attack tree:
Goal: Exfiltrate customer payment data
├── Path A: External exploitation
│ ├── Exploit SQL injection in StratPay Portal
│ └── Extract database contents directly
├── Path B: Credential-based access
│ ├── Phish Stratford employee
│ ├── Harvest credentials
│ ├── Authenticate to VPN with stolen credentials
│ ├── Access admin dashboard
│ ├── Pivot to internal network
│ └── Query SQL Server database
└── Path C: Supply chain compromise
├── Compromise third-party payment processor integration
└── Intercept or redirect transaction data
Each path represents a distinct attack scenario that can be tested independently. Path A is a direct technical exploitation. Path B is the credential-based chain the CISO specifically asked about. Path C represents a supply chain risk that may be outside the engagement scope but should be flagged.
Pentest connection: Attack trees become your test plan. Each path defines a sequence of attack steps you will attempt during the engagement. If Path B fails at the VPN authentication step (because MFA is properly enforced), you document that control as validated and move to the next path. Attack trees also help you communicate your methodology to the client: you are not randomly poking at systems, you are systematically testing specific attack scenarios grounded in real threats.
Stage 7 — Risk and Impact Analysis
What is the business impact if each attack path succeeds?
The final stage quantifies the business consequences of each validated attack path. This is where the thread from Stage 1 (business objectives) connects to Stage 6 (attack paths) to produce a risk statement the client can act on.
For Stratford, if Path B succeeds (phishing → VPN → admin dashboard → database):
PCI DSS impact: Mandatory breach notification, potential fines of $5,000–$100,000 per month of non-compliance, forensic investigation costs, possible suspension of card processing privileges
Customer impact: 200,000 customers require notification; credit monitoring costs estimated at $30–$35 per affected individual
Reputational impact: Customer attrition, negative media coverage, reduced new customer acquisition
Operational impact: Incident response mobilization, system remediation, regulatory engagement
Pentest connection: Stage 7 is how you write the Executive Summary of your penetration test report. When a CISO reads that "an attacker with a single compromised employee credential can traverse from VPN access to the payment database, exposing 200,000 customer records and triggering PCI DSS breach notification requirements," that statement carries weight because it is grounded in a structured analysis, not a guess. This is the language that gets remediation budgets approved.
The two frameworks are complementary, not competing. The following comparison highlights when each one is the better fit:
| Dimension |
STRIDE |
PASTA |
| Primary question |
"What can go wrong with this component?" |
"What would an attacker do to this business?" |
| Starting point |
System architecture (DFD) |
Business objectives |
| Perspective |
Defender (design review) |
Attacker (simulation) |
| Output |
Categorized threat list |
Prioritized risk inventory with business impact |
| Best used when |
Quick threat identification during design |
Pentest scoping, risk-driven assessments |
| Time investment |
Moderate (hours) |
High (days to weeks for full execution) |
In practice, the two frameworks nest together. You can use STRIDE within PASTA's Stage 4 for systematic threat identification, then let PASTA's remaining stages add business context, vulnerability correlation, attack path modeling, and risk quantification. For the Stratford engagement, a combined approach would use STRIDE to generate the initial threat list and PASTA to filter, chain, and prioritize those threats against business objectives.
Answer the questions below
After completing your threat model, the client asks your pentest team to justify why you are prioritizing the payment portal over the internal company wiki. Which PASTA stage provides the business-risk evidence to support this prioritization? Stage 7
During a PASTA analysis for Stratford Systems, your team discovers that financial sector threat intelligence reports show a 300% increase in API-targeted attacks over the past year. In which PASTA stage would you incorporate this finding? Stage 4
MITRE ATT&CK for Threat Modeling
STRIDE gives you categories of threats. PASTA gives you business context. But when a client asks, "What specific attack techniques should we be worried about?", you need answers grounded in observed adversary behavior, not theoretical models.
Consider the Stratford Systems engagement. STRIDE told us that the StratPay Web Application faces spoofing, tampering, and information disclosure threats. PASTA told us that credential theft is the top concern for financial services. But how do real attackers steal credentials from organizations like Stratford? Do they use phishing with malicious attachments? Do they exploit public-facing applications? Do they harvest credentials from memory after gaining initial access? The answer to "What can go wrong?" changes dramatically when you replace hypothetical categories with evidence from real-world intrusions.
This is where MITRE ATT&CK(opens in new tab) transforms threat modeling from an abstract exercise into an intelligence-driven process.
What Is MITRE ATT&CK?
ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge. It is a globally accessible, curated knowledge base of adversary behaviors based on real-world observations, maintained by the MITRE Corporation and funded by the US government. ATT&CK catalogs what attackers actually do after gaining access to systems, organized into a structured matrix that security professionals use for threat modeling, detection engineering, red teaming, and gap analysis.
The current version is ATT&CK v18, released in October 2025. The Enterprise matrix, which is the most relevant for penetration testers, contains 14 tactics, 216 techniques, and 475 sub-techniques covering Windows, macOS, Linux, cloud platforms (IaaS), network devices, containers, and identity providers.
The distinction between tactics and techniques is fundamental:
A tactic is the adversary's goal at a particular phase of an operation. "I need to get initial access." "I need to escalate my privileges." "I need to move laterally." Tactics answer why the attacker is performing an action.
A technique is the method the adversary uses to achieve that goal. "I will send a phishing email with a malicious attachment (T1566.001)." "I will exploit a public-facing application (T1190)." Techniques answer how the attacker accomplishes the tactic.
A sub-technique is a more specific variant of a technique. Phishing (T1566) breaks down into Spearphishing Attachment (T1566.001), Spearphishing Link (T1566.002), and Spearphishing via Service (T1566.003).
This hierarchy, tactic → technique → sub-technique, gives you adjustable zoom. You can discuss threats at the strategic level (tactics), the operational level (techniques), or the granular implementation level (sub-techniques).
The 14 Enterprise Tactics
The Enterprise matrix organizes adversary behavior into 14 tactics, ordered roughly by the progression of an intrusion from initial reconnaissance through final impact. Each tactic represents a distinct operational objective:
| # |
Tactic |
Adversary's Goal |
Pentest Relevance |
| 1 |
Reconnaissance |
Gather information to plan the attack |
OSINT, target profiling, attack surface mapping |
| 2 |
Resource Development |
Establish infrastructure and capabilities |
Domain registration, tool acquisition, account creation |
| 3 |
Initial Access |
Get into the target network |
Phishing, exploiting public-facing apps, valid accounts |
| 4 |
Execution |
Run malicious code on the target |
Command-line tools, scripting interpreters, scheduled tasks |
| 5 |
Persistence |
Maintain access across reboots and credential changes |
Registry run keys, scheduled tasks, account manipulation |
| 6 |
Privilege Escalation |
Gain higher-level permissions |
Exploitation, token manipulation, misconfigurations |
| 7 |
Defense Evasion |
Avoid detection by security controls |
Obfuscation, disabling defenses, indicator removal |
| 8 |
Credential Access |
Steal credentials for further access |
Dumping password hashes, keylogging, Kerberoasting |
| 9 |
Discovery |
Learn about the target environment |
Network scanning, account enumeration, permission discovery |
| 10 |
Lateral Movement |
Move through the network to reach objectives |
Pass-the-Hash, remote services, internal spearphishing |
| 11 |
Collection |
Gather data of interest before exfiltration |
Screen capture, email collection, data staging |
| 12 |
Command and Control |
Communicate with compromised systems |
Encrypted channels, web protocols, domain fronting |
| 13 |
Exfiltration |
Steal data from the target network |
Exfiltration over C2, alternative protocols, physical media |
| 14 |
Impact |
Disrupt, destroy, or manipulate systems and data |
Data encryption (ransomware), defacement, resource hijacking |
For penetration testers, tactics 3 through 14 map directly to the phases of an active engagement. Tactics 1 and 2 correspond to pre-engagement reconnaissance and preparation.
Connecting ATT&CK to the Cyber Kill Chain
If you completed the Cyber Kill Chain room, you already have a high-level model of how attacks progress through seven phases: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control (C2), and Actions on Objectives.
ATT&CK expands this model significantly. The Kill Chain provides the strategic roadmap; ATT&CK provides turn-by-turn navigation. Here is how the two frameworks map to each other:
| Cyber Kill Chain Phase |
ATT&CK Tactics |
| Reconnaissance |
Reconnaissance |
| Weaponization |
Resource Development |
| Delivery |
Initial Access |
| Exploitation |
Execution |
| Installation |
Persistence |
| Command and Control |
Command and Control |
| Actions on Objectives |
Collection, Exfiltration, Impact |
The mapping reveals a critical insight: five ATT&CK tactics have no direct equivalent in the Cyber Kill Chain. Privilege Escalation, Defense Evasion, Credential Access, Discovery, and Lateral Movement all describe adversary behaviors that the Kill Chain's seven-phase model does not explicitly address. These five tactics represent the operational reality of what happens inside a compromised network after initial access, which is precisely the territory where penetration testers spend most of their engagement time.
The takeaway is not that one framework is better. Use the Kill Chain for high-level strategic planning and executive communication. Use ATT&CK for deep technical analysis, technique-level test planning, and detection gap assessment.
Threat Modeling with ATT&CK: The CTID Methodology
In July 2024, MITRE's Center for Threat-Informed Defense (CTID) published "Threat Modeling with ATT&CK(opens in new tab)" v1.0.1, a formal methodology developed in collaboration with AttackIQ, Citigroup, JPMorgan Chase, HCA Healthcare, and Verizon Business. The methodology structures ATT&CK-based threat modeling around the same four questions from the Threat Modeling Manifesto that we introduced in Task 2.
The methodology's key innovation is theory-evidence scoring. When you identify a threat using STRIDE, it is theoretical: "Spoofing could occur at this trust boundary." When you identify a threat using ATT&CK, you can distinguish between theoretical threats and threats backed by observed evidence: "FIN7, a threat group known to target financial services, has been observed using T1566 (Phishing) and T1078 (Valid Accounts) against organizations in this sector." The theory-evidence distinction places threats on a prioritization matrix where evidence-backed threats receive higher priority than purely theoretical ones.
The practical workflow for ATT&CK-based threat modeling follows five steps:
Step 1 — Search by Industry
Identify threat groups known to target organizations in your client's sector. For Stratford Systems (financial services), relevant groups include FIN7 and FIN8, both of which have extensively targeted financial institutions.
Step 2 — Search by Platform
Identify techniques that target your client's specific technology stack. Stratford runs Windows Server and SQL Server, making techniques like T1190 (Exploit Public-Facing Application) and T1133 (External Remote Services) directly relevant.
Step 3 — Compile Navigator Layers
Create separate ATT&CK Navigator layers for each threat group and platform search. Each layer highlights the techniques relevant to that particular lens.
Step 4 —Overlay and Analyze
Combine the layers mathematically using the Navigator's layer overlay feature. Techniques that appear in multiple layers, meaning they are used by relevant threat groups and target relevant platforms, represent the highest-priority threats. These are the techniques most likely to be used against your specific client.
Step 5 — Map Defenses to Gaps
Compare the prioritized technique list against the client's existing security controls. Techniques where the client has no detection or prevention capability represent the gaps your penetration test should target.
Applied Walkthrough: ATT&CK Against Stratford Systems
Let's apply this workflow to the Stratford engagement.
Industry search (financial services): FIN7 is one of the most prolific threat groups targeting financial institutions. Searching ATT&CK for FIN7's known techniques reveals a consistent pattern:
T1566 — Phishing (Initial Access): FIN7 routinely uses spearphishing emails with malicious attachments to gain initial footholds
T1059 — Command and Scripting Interpreter (Execution): After initial access, FIN7 uses PowerShell and JavaScript for execution
T1078 — Valid Accounts (Persistence, Privilege Escalation, Defense Evasion): FIN7 harvests and reuses legitimate credentials to maintain access and evade detection
Platform search (Windows Server, SQL Server):
T1190 — Exploit Public-Facing Application (Initial Access): Directly relevant to the StratPay Portal
T1133 — External Remote Services (Initial Access, Persistence): Relevant to the VPN-accessible admin dashboard
T1505.001 — SQL Stored Procedures (Persistence): Relevant to the SQL Server database cluster
Combined analysis: The overlay reveals that T1078 (Valid Accounts) appears in both the industry layer and the platform layer. FIN7 uses stolen credentials as a primary technique, and Stratford's architecture (VPN access, AD-integrated SSO, SQL Server authentication) provides multiple surfaces where valid credentials unlock access. This convergence confirms what PASTA's Stage 4 suggested through industry statistics: credential-based attacks should be the primary focus of the Stratford engagement.
The ATT&CK analysis also identifies specific test cases that STRIDE and PASTA could not provide on their own. Instead of "test for spoofing at the VPN trust boundary" (STRIDE), you now have "test whether stolen Active Directory credentials grant VPN access, and if so, whether the admin dashboard enforces additional authentication beyond SSO" (ATT&CK-informed). The specificity translates directly into actionable test steps.
Three tools support ATT&CK-based threat modeling in practice:
ATT&CK Navigator(opens in new tab) is a free, web-based tool. It allows you to create custom layers with color coding, scores, and comments, then combine layers mathematically to identify technique overlap. The Navigator is the primary visualization tool for ATT&CK-based threat modeling output.
CISA Decider(opens in new tab) is a free tool from the Cybersecurity and Infrastructure Security Agency that helps translate conceptual attack steps into ATT&CK Tactics, Techniques, and Procedures (TTPs) through guided decision-tree questions. It is particularly useful when you know what an attacker did but need to identify the correct ATT&CK classification.
Atomic Red Team(opens in new tab) is an open-source library maintained by Red Canary that provides small, portable test cases mapped to individual ATT&CK techniques. Each "atomic test" validates whether a specific technique would succeed or be detected in the target environment. While Atomic Red Team is more relevant to the exploitation and post-exploitation phases of a pentest, its technique-level structure connects directly to the threat model you build here.
Answer the questions below
How many tactics are in the MITRE ATT&CK Enterprise matrix (v18)? 14
What is the first ATT&CK tactic (alphabetically) that has no direct equivalent in the Cyber Kill Chain? Credential Access
Putting It All Together: Threat Modeling Stratford Systems
You have the tools. You have the vocabulary. Over the previous tasks, you learned to decompose systems into Data Flow Diagrams with trust boundaries (Task 3), identify threats systematically with STRIDE (Task 4), score and prioritize those threats with DREAD (Task 5), align your analysis with business objectives through PASTA (Task 6), and ground your threat model in real adversary intelligence using MITRE ATT&CK (Task 7).
Now it is time to use all of them together.
Your team lead at the security consultancy has handed you the engagement briefing document for the Stratford Systems penetration test. Your job is to build a threat model that will drive the test plan. The static site attached to this task walks you through the process step by step.
The Engagement Briefing
The following document is displayed on the static site. Read it carefully before beginning the exercise.
ENGAGEMENT BRIEFING - CONFIDENTIAL
Client: Stratford Systems, Inc.
Industry: Financial services
Compliance scope: PCI DSS (cardholder data environment)
Engagement type: External penetration test with limited internal pivot authorization
Target systems:
StratPay Portal (customer-facing payment application, HTTPS, public-facing)
Internal API Gateway (middleware connecting portal to backend services)
SQL Server Database Cluster (customer PII and payment card records)
Active Directory domain (stratford.local) with SSO integration
Admin Dashboard (internal management interface, VPN-only access)
Employee Directory Service (staff lookup and profile management, LDAP-integrated)
Engagement timeline: 10 business days
Authorization boundaries: External testing of all public-facing assets is authorized without restriction. Internal pivot is authorized only through the VPN entry point using credentials provided by the client or obtained during testing. The SQL Server database may be queried to confirm data access but bulk extraction is prohibited. Social engineering (phishing simulation) against up to five pre-approved employee email addresses is authorized.
Client CISO's primary concern:
"We had a close call with a phishing attack last quarter. One of our finance team members clicked a malicious link, and our SOC caught it before any damage was done, but it was a near miss. I want to know: if an attacker compromises an employee’s credentials, can they reach our payment database? That is the scenario that keeps me up at night."
Guided Exercise: Five Steps to a Threat Model
The static site presents the following five steps as an interactive, guided exercise. Each step applies a specific framework or skill from the room and builds on the previous step's output. Complete each step before moving to the next.
Step 1 - Review the DFD (Task 2: Building Blocks)
The static site displays the complete Stratford Systems DFD, expanded from the StratPay Portal diagram in Task 2 to include all six target systems, their interconnections, and all trust boundaries.
The expanded DFD includes the following trust boundaries:
TB1: Internet ↔ DMZ — separates external users from the StratPay Portal
TB2: DMZ ↔ Internal Network — separates the web application from backend services
TB3: Internal Network ↔ Database Zone — separates application logic from data storage
TB4: Internet ↔ VPN Tunnel — separates remote employees from the internal network
TB5: VPN Tunnel ↔ Internal Network — separates authenticated VPN traffic from unrestricted internal access
Your task: Click on each trust boundary in the DFD to confirm its location and the data flows that cross it. The static site highlights the crossing data flows when you select a trust boundary. After reviewing all five, answer the verification question to proceed.
Step 2 - Apply STRIDE (Task 3: Threat Identification)
The static site highlights four DFD components, one at a time. For each component, you are presented with a scenario and must select the STRIDE category that represents the greatest risk.
Component A - VPN Authentication Service (Process):
Employees connect to the internal network through a VPN that authenticates against Active Directory. The CISO reported a recent phishing near-miss targeting employee credentials. Which STRIDE category represents the greatest risk for this component?
Component B - Data flow between API Gateway and SQL Server Database:
The API Gateway sends parameterized SQL queries containing customer payment data to the database cluster. Responses include cardholder names, masked card numbers, and transaction histories. Which STRIDE category represents the greatest risk for this data flow?
Component C - Admin Dashboard (Process):
The admin dashboard allows authorized staff to manage customer accounts, issue refunds, and view transaction logs. It is accessible only through the VPN. Which STRIDE category represents the greatest risk for this component?
Component D - Audit Log Data Store:
Transaction events, authentication attempts, and administrative actions are written to a centralized log store. The logs are used for PCI DSS compliance reporting and incident investigation. Which STRIDE category represents the greatest risk for this data store?
The static site provides feedback after each selection, explaining why the chosen category is correct or incorrect and describing the specific threat in the context of the Stratford architecture.
Step 3 - Score with DREAD (Task 4: Prioritization)
The four threats are presented with full context. Each card shows the DREAD category scores for each threat. Based on the scores, determine the testing priority order.
Threat 1: Internal API Gateway management interface still uses default credentials (admin/admin) that were never changed after deployment.
Threat 2: Customer-facing payment search feature is vulnerable to SQL injection, granting database access to all customer payment records.
Threat 3: Admin dashboard (VPN-only) leaks stack traces and database connection strings on malformed input.
Threat 4: Customer-facing feedback form accepts unsanitized HTML; injected JavaScript executes in other customers' browsers when they view the feedback page.
After ranking all four threats, the static site reveals the recommended ranking with reasoning for each category.
Step 4 - Layer ATT&CK Intelligence (Task 6: Adversary Techniques)
The CISO's attack scenario (phishing → credential compromise → VPN access → admin dashboard → database exfiltration) describes a chain of adversary actions. Each step in the chain maps to an ATT&CK tactic and technique.
The static site presents the attack chain as a sequence of five steps. Two steps have their ATT&CK mappings pre-filled; three are blank. Select the correct tactic for each blank step from the dropdown menu.
| Attack Step |
ATT&CK Tactic |
Technique |
| Phishing email with malicious attachment |
Initial Access (pre-filled) |
T1566.001 Spearphishing Attachment |
| Harvest employee credentials |
Credential Access (pre-filled) |
T1078 Valid Accounts |
| Authenticate to VPN with stolen credentials |
[You select] |
T1133 External Remote Services |
| Access admin dashboard and pivot internally |
[You select] |
T1021 Remote Services |
| Query SQL Server to extract payment data |
[You select] |
T1041 Exfiltration Over C2 Channel |
The static site provides guidance feedback if you select an incorrect tactic.
Step 5 - Prioritize the Test Plan
Based on all four previous steps, the static site presents four test objectives for the Stratford engagement. Rank them from highest to lowest priority by putting them in order.
Test Objective A: Test whether the StratPay Portal is vulnerable to SQL injection in the transaction search feature.
Test Objective B: Test whether phished employee credentials grant VPN access and whether the VPN enforces Multi-Factor Authentication.
Test Objective C: Test whether an authenticated VPN user can reach the admin dashboard and pivot from there to the SQL Server database.
Test Objective D: Test whether the admin dashboard enforces role-based access control, preventing standard employees from performing privileged actions like issuing refunds.
Answer the questions below
In the DREAD scoring exercise (Step 3), which of the two threats received the higher risk rating: the phished VPN credentials or the SQL injection in the transaction search feature? SQL injection
In the ATT&CK mapping exercise (Step 4), which tactic did you assign to the step where the attacker uses stolen VPN credentials to access the internal network? Initial Access
What flag did you get after going through all the steps?
Conclusion
Over the course of this room, you built a threat model for the Stratford Systems engagement using four complementary tools. Each one answered a different question that a penetration tester faces before active testing begins:
STRIDE answered "What can go wrong?" by giving you six systematic threat categories to evaluate against every component in a Data Flow Diagram. It turned an unstructured brainstorm into a repeatable checklist.
DREAD answered "How bad is it?" by scoring each identified threat across five dimensions, producing a ranked priority list from an undifferentiated threat inventory.
PASTA answered "What does the business care about?" by grounding your analysis in business objectives, compliance requirements, and real-world threat intelligence. It connected technical findings to the language that gets remediation budgets approved.
MITRE ATT&CK answered "What are real attackers actually doing?" by replacing theoretical threat categories with specific techniques observed in attacks against organizations like your client. It transformed your threat model from a hypothesis into an evidence-based assessment.
No single framework covers everything. STRIDE identifies threats but does not prioritize them. DREAD prioritizes but lacks business context. PASTA provides business context but takes time. ATT&CK provides adversary evidence but requires intelligence maturity. Used together, as you did in the Task 7 capstone, they produce a threat model that is systematic, prioritized, business-relevant, and grounded in reality.
The Threat Model Is a Living Document
A completed threat model is not a deliverable you file away after the engagement kickoff. It is a working document that evolves:
Before the engagement, the threat model defines your test priorities, informs the Rules of Engagement, and shapes the attack paths you will attempt. If you completed the Planning and Scoping room in Module 1, you already know that scope documents and Rules of Engagement require a clear understanding of what matters to the client. The threat model provides exactly that understanding.
During the engagement, your findings validate or refute the threat model's predictions. If the threat model predicted that credential-based VPN access was the highest-priority attack path and you confirm it works, the model was accurate. If you discover an unanticipated path, perhaps an exposed management interface that was not in the DFD, the model has a gap that should be documented.
After the engagement, the threat model should be updated with the new findings. Three critical vulnerabilities that were not predicted by the original model are not a failure of threat modeling; they are an input for the next iteration. Each engagement makes the model more accurate and more complete.
This iterative cycle connects directly to the next room in this module. Re-testing covers how validated findings drive remediation verification: the client fixes the vulnerabilities you discovered, and you re-test to confirm the fixes work. The threat model informs what gets re-tested and in what order, closing the loop between modeling, testing, and remediation.
