Threat modeling is a critical phase of any penetration testing engagement. By identifying key business assets and understanding potential attackers, you can accurately prioritize risks and focus your testing on the most relevant threats to the organization, rather than just running down a generic inventory of IT elements.
Even in a complete black-box assessment where you have no prior knowledge of the organization, you should still create a baseline threat model using Open-Source Intelligence (OSINT) from an attacker's perspective.
The Threat Modeling Process
Building an effective threat model ensures your engagement closely emulates the tools, techniques, and profile of real-world attackers.
- 1
Gather relevant documentation
Collect internal policies, procedures, and technical architecture documents to understand how the business operates.
- 2
Identify and categorize assets
Determine the primary and secondary business assets that hold value to the organization.
- 3
Identify threats and communities
Define the potential attackers (threat communities) and evaluate their technical capabilities.
- 4
Map threats to assets
Connect the identified threat communities to the specific assets they are most likely to target.
Core Elements of a Threat Model
Every penetration test should clearly identify and document four foundational elements:
| Element | Description |
|---|---|
| Business Assets | The critical data, systems, or resources the organization needs to protect (e.g., customer data, trade secrets). |
| Business Processes | The workflows and operations that support or interact with the business assets. |
| Threat Communities | The specific groups or individuals (attackers) motivated to target the organization. |
| Capabilities | The technical skills, tools, funding, and resources available to a given threat community. |
Business Asset Analysis
During the business asset analysis phase, you take an asset-centric view of the organization. By interviewing personnel and reviewing documentation, you can determine what an attacker wants, what it is worth, and the impact if it is compromised.
Organizational & Financial Data
This includes internal policies that define critical business processes, product information (trade secrets, R&D data, source code), marketing roadmaps, and highly guarded financial accounts (bank, credit, and equity accounts).
Technical Information
Technical data facilitates the testing process. Look for infrastructure designs (building blueprints, network diagrams), system configurations (baselines, OS images, hardening checklists), and both standard and privileged user account credentials.
Employee Data
Employee data includes Personally Identifiable Information (PII), Protected Health Information (PHI), and National Identification Numbers (like SSNs). Loss of this data often leads to direct regulatory fines or affects critical personnel.
Customer Data
Similar to employee data, customer PII, PHI, and financial information are prime targets. Compromise of customer data can lead to severe indirect losses, such as fraud liability and reputational damage.
Mapping Threats to Assets
When mapping threat communities to assets, it is crucial to look beyond the immediate scope of the application. Secondary assets can drastically change the threat landscape.
Example Scenario:
Imagine an internally hosted CRM application is in scope for your assessment. The customer information in the backend is the primary asset. However, during your review, you discover that an HR database shares the same backend server. This HR database is a secondary asset.
An attacker might not care about the CRM data, but they can use the CRM application as a stepping stone to access highly sensitive employee information.
flowchart TD
A["Attacker"] -->|Exploits| B["CRM Application (In Scope)"]
B -->|Direct Access| C["Customer DB (Primary Asset)"]
B -->|Pivots to| D["HR Database (Secondary Asset)"]
D -.->|Exposes| E["Employee Data"]Threat communities that initially seem irrelevant to the primary application might become highly relevant once you identify the secondary assets connected to it.
Motivation and Impact Modeling
To provide a truly accurate risk score for the organization, your threat model should go beyond technical mappings and include business context:
Motivation Modeling: Evaluate the "net value" of the assets against the cost and effort required for an attacker to acquire them. This helps determine how motivated a specific threat community will be.
Impact Modeling: Create "what-if" scenarios surrounding the loss of identified assets. Consider the asset's intrinsic value, regulatory fines, and indirectly incurred costs (like lawsuits or loss of customer trust).