Threat Modeling

General

This section defines the required models needed for a correct penetration testing execution. The standard does not use a specific model, but required that the model used would be consistent in terms of its representation of threats, their capabilities, their qualifications as per the organization being tested, and the ability to repeatedly be applied to future tests with the same results. The standard focuses on two key elements of traditional threat modeling - business assets, and attacker. Each one is further broken down to the business assets themselves, and the business processes, and from the attacker perspective the threat community, and the attacker capabilities. As a minimum, all four elements should be clearly identified and documented at every penetration testing.

When modeling the attacker side, on top of the threat community (which is mostly semantic and can be tied back to the organization’s business SWOT one), and the capabilities (which is mostly technical), an additional aspect of motivation modeling should also be provided – which essentially takes into account the value of the different assets available at the target and combined with the cost of acquiring it. As a complementary model, impact modeling should also be performed for the organization in order to provide a more accurate of the “what-if?” scenario surrounding the loss event of each of the identified assets which takes into account the asset “net” value, it’s intrinsic value, and other costs associated with a loss event that are incurred indirectly.

High level threat modeling process

1. Gather relevant documentation
2. Identify and categorize primary and secondary assets
3. Identify and categorize threats and threat communities
4. Map threat communities against primary and secondary assets

Gather relevant documentation

You will need extensive documentation of the assessment scope, the organization and it’s most critical business processes in order to complete a relevant threat modeling exercise. The documents you may want to obtain include : - Policies, plans and procedures - Technical information - Infrastructure design information - System configuration information - Business processes information

Example

In the light of a PTES assessment the internally hosted CRM application may be in scope. The customer information stored in the back-end database is an easily identifiable primary asset as it is directly linked to the application in scope. However, by reviewing the technical design of the database server, one can also identify the HR database stored on the same back-end database server as a secondary asset. An attacker can use the CRM application as a stepping stone to obtain employee information. In a basic threat modeling exercise, certain threat communities may be identified as not relevant when mapped to the CRM application, but by identifying the secondary assets the threat landscape suddenly changes.

Business Asset Analysis

The business asset analysis part of the threat model basically takes an asset centric view of all the related information assets, the business processes that surround/support them, the personnel involved with manipulating/processing/maintaining them, and their IT environment that hosts/protects/processes them.

In the business asset analysis phase, the pentester is tasked with finding out what are the business asset that are most likely to be sought after by an attacker, what is their direct worth, and what are the intrinsic costs of such a loss. This part is concluded with an impact analysis for each of the assets initially identified in order to provide the organization later on a model on top of which it can build a more cohesive risk management strategy that would be based on (along with the results from the rest of the penetration test which should provide a fairly accurate estimate of the probability of such loss, and the different ways in which loss events would most likely occur).

Organizational Data

Policies, Plans, and Procedures

Internal policies, plans, and procedures define how the organization does business. These documents are of particular interest as they can help identify key roles within an organization and critical business processes that keep a company running.

Product Information (e.g. trade secrets, R&D data)

Product related information includes any patents, trade secrets, future plans, source code, supporting systems that directly affect the product market value, algorithms, and any other information that the organization regards as a key factor to the business success of such product.

Marketing Information (plans, roadmaps, etc.)

Marketing plans for promotions, launched, product changes, positioning, partnerships, 3rd party providers, business plans related to activities inside or outside the organization. Additionally, PR related data such as details of partners, reporters, consulting firm, and any correspondence with such entities is also considered a highly sought after target.

Financial Information (e.g. bank, credit, equity accts)

Financial information is often some of the most guarded information an organization possesses. This information can include bank account information, credit card account information and/or credit card numbers, and investment accounts, among others.

Technical Information

Technical information about the organization, and the organization’s operations, is of unique interest to the penetration tester. Such information is often not the expected deliverable of a penetration test, however, it facilitates the testing process by feeding valuable information other areas; infrastructure design information may provide valuable data to the Intelligence Gathering process.

• Infrastructure Design Information

Infrastructure design related information pertains to all the core technologies and facilities used to run the organization. Building blueprints, technical wiring and connectivity diagrams, computing equipment/networking designs, and application level data processing are all considered infrastructure design information.

• System Configuration Information

System configuration information includes configuration baseline documentation, group policy information, operating system images, software inventories, etc. This information could aid the discovery of vulnerabilities (such as through the knowledge of configuration errors or outdated software installations).

• User Account Credentials

User account credentials help facilitate access to the information system, at a non-privileged level, as long as a means to authenticate exists (e.g. VPN, web portal, etc.).

• Privileged User Account Credentials

Privileged user account credentials help facilitate access to the information system, at an elevated level of access, as long as a means to authenticate exists (e.g. VPN, web portal, etc.). Obtaining privileged user account credentials often leads to compromise of the information system being tested.

Employee Data

Here employee data is being analyzed as any data that have a DIRECT affect on the organization is obtained or compromised by an attacker. Organizations that have to adhere to some compliance which places fines over the loss of such data are obvious candidates for such a direct loss effect. Also, organizations who’s employees may be considered critical assets may also be subjected to such scrutiny (specific government bodies, specialized trade secret related employees/departments, etc…). The following list provides examples to information realms of personal data that may be considered business assets for the threat modeling.

• National Identification Numbers (SSNs, etc.)
• Personally Identifiable Information (PII)
• Protected Health Information (PHI)
• Financial Information (e.g. bank, credit accts)

Customer Data

Much like employee data, customer data is considered a business asset in the threat modeling when such information will incur a direct/indirect loss to the organization. On top of regulatory/compliance need (based on fines), an additional factor comes into play here when such data can be used to conduct fraud, where the organization may be held liable or sued for the losses related to the fraud (based on losing the customer information that enabled it). The following list provides examples of such information realms that may hold relevant customer data and should be considered business assets for the sake of the threat modeling</IA>

• National Identification Numbers (SSN’s, etc.)
• Personally Identifiable Information (PII)
• Protected Health Information (PHI)
• Financial Accounts (e.g. bank, credit, equity accts)
• Supplier Data

Information related to suppliers that is considered critical to the organization (such as critical components manufacturers, agreements with suppliers that may be part of a trade secret, cost analysis of supplied components), as well as any data that may be used to affect the business operations of the organization through its suppliers is considered a business asset.

• Partner Data
• “Cloud” Service Account Information

Human Assets

When identifying human assets in an organization, we have to remember that the context is having such assets part of a greater effort to compromise the organization. As such, human assets that are identified as business assets are those that could be put under leveraged to divulge information, manipulate to make decisions or actions that would adversely affect the organization or enable an attacker to further compromise it. Human assets are not necessarily the highest up in the corporate hierarchy, but more often are key personnel that are related to previously identified business assets, or are in positions to enable access to such assets. The following list provides some examples of such assets, and should be adapted to the organization being tested.

• Executive Management
• Executive Assistants
• Middle Management
• Administrative Assistants
• Technical/Team Leads
• Engineers
• Technicians
• Human Resources

Business Process Analysis

In the business process analysis we differentiate between critical business processes, and non-critical processes. For each category the analysis is the same, and takes into account the same elements. The main difference is in the weighting that the threat from a critical business process is assigned with as opposed to a non-critical one. Nevertheless, it's imperative to remember that an aggregation os a few non-critical business processes can be strung into a scenario that essentially forms a critical element/process, and such threat scenarios should also be identified at this phase and mapped out for later use in the penetration test.

Technical infrastructure supporting process

As business processes are usually supported by IT infrastructure (such as computer networks, processing power, PCs for entering information and managing the business process, etc...), all those elements must be identified and mapped. Such mapping should be clear enough to be used later on in the process of translating the threat model to the vulnerability mapping and exploitation.

Information assets supporting process

Contrary to technical infrastructure, information assets are existing knowledge bases in the organization that are used as either a reference, or as support material (decision making, legal, marketing, etc...). Such assets are usually identified in the business process already, and should be mapped alongside the technical infrastructure, as well as any additional technical infrastructure that supports the information assets themselves.

Human assets supporting process

Identification of the HR that are involved in the business process should be made in conjunction with the process analysis itself (whether documented or not), and every person that has any kind of involvement (even if it does not relate to an information asset or a technical infrastructure element) should be documented and mapped in the process. Such HR assets are usually part of an approval sub-process, a verification sub-process, or even a reference (such as legal advice). These kinds of assets (especially ones that have no relation to information assets or technical infrastructure) would be later mapped to attack vectors that are more social in nature than technical.

3rd party integration and/or usage of/by process

Similar to human assets supporting the process, any 3rd party that has any involvement with the business process should be mapped as well. This category can be tricky to map out, as it could contain both human assets, as well as information/technical ones (such as a SaaS provider).

Threat Agents/Community Analysis

When defining the relevant threat communities and agents, a clear identification of the threat should be provided in terms of location (internal / external to the organization), the specific community within the location, and any additional relevant information that would assist in establishing a capabilities/motivation profile for the specific agent/community. Where possible, specific agents should be identified. Otherwise, a more general community would be outlined, along-with any supporting material and intelligence. Some examples of a threat agent/community classifications are:

Internal	External
Users	Business Partners
Management (executive, middle)	Competitors
Administrators (network, system, server)	Contractors
Developers	Suppliers
Engineers	Nation States
Technicians	Organized Crime
Contractors (with their external users)	Hacktivists
General user community	Script Kiddies (recreational/random hacking)
Remote Support

Threat Capability Analysis

Once a threat community has been identified, the capabilities of said community must also be analyzed in order to build an accurate threat model that reflects the actual probability of such a community/agent to successfully act upon the organization and compromise it. This analysis requires both a technical analysis as well as an opportunity analysis (where applicable).

Analysis of tools in use

Any tools that are known to be available to the threat community/agent are to be included here. Additionally, tools that may be freely available should be analyzed for the required skills to be able to utilize them to their potential, and mapped in the threat capability.

Availability to relevant exploits/payloads

The threat community/agent should be analyzed in terms of its capability to either obtain, or develop relevant exploits for the environment relevant to the organization. Additionally, accessibility to such exploits/payloads through 3rd parties, business partners, or underground communities are also be to taken into account in this analysis.

Finding relevant news of comparable Organizations being compromised

In order to provide a complete threat model, a comparison to other organizations within the same industry should be provided. This comparison should include any relevant incidents or news related to such organizations and the challenges they face. Such a comparison is used to validate the threat model and offer a baseline for the organization to compare itself to (taking into account that this publicly available information only represents a portion of the actual threats and incidents the compared organization actually faces)