ThreatExploit Documentation logoThreatExploit Documentation logo ThreatExploit Documentation
Threat Modeling Fundamentals Mapping Business Processes

Threat modeling isn't just about finding technical flaws; it's about understanding what matters most to an organization. By mapping technical assets to the business processes they support, you can accurately assess risk and focus your security efforts on the areas that truly impact the business.

The Threat Modeling Process

To build a threat model that accurately reflects business risk, you need to understand both the assets you are protecting and the attackers who might target them.

  1. 1

    Gather documentation

    Collect internal policies, technical architecture diagrams, business plans, and any other documentation that defines how the organization operates.

  2. 2

    Identify primary and secondary assets

    Catalog the assets that drive the business. Primary assets are the direct targets (like a customer database), while secondary assets are stepping stones (like an adjacent HR database on the same server).

  3. 3

    Identify threat communities

    Determine who would want to attack the organization. Consider both internal and external actors, their capabilities, and their motivations.

  4. 4

    Map threats to assets

    Connect the dots. Evaluate which threat communities are most likely to target specific primary or secondary assets, and how they might reach them.

Primary vs. Secondary Assets
Imagine you are testing an internally hosted CRM application. The customer data inside it is an easily identifiable primary asset. However, if an HR database sits on the same back-end server, that HR database becomes a secondary asset. An attacker might use the CRM application purely as a stepping stone to steal employee information. Identifying secondary assets often completely changes the threat landscape.

Analyzing Business Processes

Business processes are the value chains that allow an organization to operate and generate revenue. When mapping these processes, you should differentiate between critical and non-critical workflows.

Keep in mind that combining several non-critical processes can sometimes reveal a critical flaw. Every business process is supported by four key pillars:

flowchart TD
    BP["Business Process"]
    
    BP --> TI["Technical Infrastructure"]
    BP --> IA["Information Assets"]
    BP --> HA["Human Assets"]
    BP --> TP["3rd Party Integrations"]
    
    TI -.->|Servers, Networks| TI
    IA -.->|Databases, IP| IA
    HA -.->|Employees, Execs| HA
    TP -.->|SaaS, Vendors| TP

  1. Technical Infrastructure: The IT elements that support the process, such as computer networks, processing power, and user workstations.

  2. Information Assets: The knowledge bases used for reference or decision-making (e.g., legal documents, marketing plans).

  3. Human Assets: The people involved in the process, including those in approval or verification roles.

  4. 3rd Party Integrations: External vendors or SaaS providers that interact with the workflow.

Identifying Business Assets

During your asset analysis, take an asset-centric view to determine what is most likely to be targeted, its value, and the impact if it were lost or compromised.

Organizational and Technical Data

These assets define how the organization runs and are highly sought after by attackers:

  • Product Information: Trade secrets, source code, R&D data, and algorithms.

  • Financial Information: Bank accounts, credit card data, and equity accounts.

  • Technical Information: Infrastructure blueprints, system configuration baselines, and user/privileged account credentials.

Customer and Employee Data

Data that can incur a direct or indirect loss (through fines, lawsuits, or fraud) if exposed:

  • Personally Identifiable Information (PII)

  • Protected Health Information (PHI)

  • National Identification Numbers (e.g., SSNs)

Human Assets

Human assets aren't always executives. They are anyone who can be leveraged to divulge information or grant access. This includes executive assistants, engineers, HR personnel, and even technicians who might have physical access to restricted areas.

When mapping human assets, look for personnel who are adjacent to critical business processes. An administrative assistant often has the same access rights (or physical keys) as the executive they support, making them a prime target for social engineering.

Understanding Threat Communities

To map processes effectively, you must understand who is attacking them. Threat communities should be categorized by location (internal vs. external) and analyzed for their capabilities and motivations.

Common Threat Communities

Internal ThreatsExternal Threats
Employees & ContractorsBusiness Partners & Suppliers
Management (Executive, Middle)Competitors
IT Administrators & DevelopersNation States
Engineers & TechniciansOrganized Crime & Hacktivists
Remote SupportScript Kiddies

Threat Capabilities and Motivation

Once you identify a threat community, analyze their capabilities:

  • Tools: What tools do they have access to, and what skill level is required to use them?

  • Exploits: Can they develop custom payloads, or do they rely on publicly available exploits?

  • Communication: Do they use simple encryption, or advanced command-and-control (C2) mechanisms like bulletproof hosting and drop-sites?

  • Accessibility: How easily can they physically or digitally access the target organization?

Finally, consider their motivation. Attackers are constantly evolving, but common motivations include direct/indirect profit, hacktivism, personal grudges, reputation building, or using the organization as a pivot point to attack a connected partner system.

Validate your model with OSINT
To ensure your threat model is realistic, look for news of comparable organizations in the same industry being compromised. This baseline helps validate your assumptions about which threat communities are actively targeting the sector.