Threat modeling is a foundational methodology used to identify, categorize, and analyze potential threats to your organization's assets. By understanding what you need to protect and who might attack it, you can accurately assess risk and prioritize your security efforts.
Even in a complete "black-box" scenario where you have no prior information about the target organization, you should still create a threat model. You can build an effective attacker's view by combining Open-Source Intelligence (OSINT) with your initial reconnaissance.
The Threat Modeling Process
A successful threat model connects the dots between what your business values and how an attacker might compromise it. Follow these core steps to build your model:
- 1
Gather documentation
Collect all relevant information about the target environment. This includes network diagrams, business processes, and system architectures.
- 2
Identify and categorize assets
Determine what systems, data, and processes are in scope. Separate these into primary assets (the direct targets) and secondary assets (systems that might be exposed as a byproduct).
- 3
Identify threats and threat communities
Define who would want to attack the organization and what their capabilities are (e.g., script kiddies, organized crime, insider threats).
- 4
Map threats to assets
Connect the threat communities to the specific assets they are most likely to target, creating a clear picture of your actual risk landscape.
Always document your threat model clearly. When delivering a final security report, referencing this model ensures your risk scores are tailored specifically to the organization, rather than relying on generic technical metrics.
Understanding Primary vs. Secondary Assets
When mapping out targets, it is easy to focus only on the obvious applications in scope. However, attackers often use primary assets as stepping stones to reach highly sensitive secondary assets.
Consider an internally hosted Customer Relationship Management (CRM) application. The CRM and its customer data are your primary assets. However, if the CRM shares a backend database server with the company's Human Resources (HR) database, the HR data becomes a critical secondary asset.
flowchart LR
A[Attacker] -->|Compromises| B["CRM Application (Primary Asset)"]
B -->|Stepping Stone| C["Shared Database Server"]
C -->|Accesses| D["HR Database (Secondary Asset)"]By identifying secondary assets, your threat landscape changes dramatically. A threat community that ignores CRM data might be highly motivated to steal HR records.
Business Asset Analysis
During the business asset analysis phase, you take an asset-centric view of the organization. By interviewing stakeholders and reviewing documentation, you can identify what attackers want, the value of those assets, and the impact if they are lost or compromised.
Here are the common categories of organizational data you should look for:
| Asset Category | Description | Examples |
|---|---|---|
| Policies & Procedures | Documents defining how the business operates and identifying key roles. | Internal policies, business continuity plans, operational procedures. |
| Product Information | Data that directly affects the market value of the organization's offerings. | Trade secrets, source code, R&D data, proprietary algorithms. |
| Marketing Information | Strategies and communications regarding market positioning and partnerships. | Roadmaps, PR data, partner details, upcoming launch plans. |
| Financial Information | Highly guarded monetary and account data. | Bank accounts, credit card info, equity accounts, investment data. |
| Technical Information | Infrastructure design and system configuration details. | Blueprints, network diagrams, group policies, system images. |
Deep Dive: Types of Technical Information
Technical information is uniquely valuable to penetration testers and attackers alike. It generally falls into two buckets:
Infrastructure Design Information: The core technologies and facilities used to run the organization (e.g., building blueprints, wiring diagrams, network designs, application data flows).
System Configuration Information: How those systems are set up (e.g., configuration baselines, hardening procedures, software inventories). This data is often used to discover misconfigurations and vulnerabilities.
Next Steps
Once you have established your threat model, you can begin actively mapping attack vectors and identifying vulnerabilities based on the business processes you've uncovered.