PTES: Threat Modeling

Contents
1
General
1.1
High level threat modeling process
1.2
Example
1.3
High level modeling tools
2
Business Asset Analysis
2.1
Organizational Data
2.1.1
Policies, Plans, and Procedures
2.1.2
Product Information (e.g. trade secrets, R&D data)
2.1.3
Marketing Information (plans, roadmaps, etc.)
2.1.4
Financial Information (e.g. bank, credit, equity accounts)
2.1.5
Technical Information
2.1.6
Employee Data
2.1.7
Customer Data
2.2
Human Assets
3
Business Process Analysis
3.1
Technical infrastructure supporting process
3.2
Information assets supporting process
3.3
Human assets supporting process
3.4
3rd party integration and/or usage of/by process
4
Threat Agents/Community Analysis
4.1
Employees
4.2
Management (Executive, middle)
5
Threat Capability Analysis
5.1
Analysis of tools in use
5.2
Availability to relevant exploits/payloads
5.3
Communication mechanisms
5.4
Accessibility
6
Motivation Modeling
7
Finding relevant news of comparable Organizations being compromised
General
This section defines a threat modeling approach as required for a correct execution of a penetration testing. The standard does not use a specific model, but instead requires that the model used 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 - assets and attacker (threat community/agent). Each one is respectively broken down into business assets and business processes and the threat communities and their capabilities.
As a minimum, all four elements should be clearly identified and documented in every penetration test.
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 analysis), and the capabilities (which is mostly technical), additional aspects of motivation modeling should also be provided. These additional points essentially take into account the value of the different assets available at the target and are 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 view of the “what-if?” scenario surrounding the loss event of each of the identified assets. This should take into account the assets “net” value, its intrinsic value, and other indirectly incurred costs associated with a loss event.
The threat modeling phase of any penetration testing engagement is critical for both the testers, as well as the organization. It provides clarity as far as the organization’s risk appetite and prioritization (which assets are more important than others? what threat communities are more relevant than others?). Additionally, it enables the tester to focus on delivering an engagement that closely emulates the tools, techniques, capabilities, accessibility and general profile of the attacker, while keeping in mind what are the actual targets inside the organization such that the more relevant controls, processes, and infrastructure are put to the test rather than an inventory list of IT elements.
The threat model should be constructed in coordination with the organization being tested whenever possible, and even in a complete black-box situation where the tester does not have any prior information on the organization, the tester should create a threat model based on the attacker’s view in combination with OSINT related to the target organization.
The model should be clearly documented, and be delivered as part of the final report as the findings in the report will reference the threat model in order to create a more accurate relevance and risk score that is specific to the organization (rather than a generic technical one).
High level threat modeling process
Gather relevant documentation
Identify and categorize primary and secondary assets
Identify and categorize threats and threat communities
Map threat communities against primary and secondary assets
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, it can also be identified that the HR database stored on the same back-end database server is 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.
High level modeling tools
There are a variety of tools available to identify targets and map attack vectors.  These normally focus on the business assets (what systems to target) and business processes (how to attack them.)  Depending on the engagement, the penetration testing team may perform these exercises with no input from the customer; or they may spend a lot of time with customer stakeholders identifying targets of interest.  Tools with a business asset focus usually require a quantitative input to describe how important each potential target is to test.  The inputs may also be qualitative, such as a description by the customer’s CIO that a system is mission-critical.
Tools focused on business processes, information flows and technical architecture are used to identify potential attack vectors and choose which are mostly likely to succed or most likely to be used by a certain class of adversary.
Business Asset Analysis
During the business asset analysis part of the threat modeling exercise an asset-centric view is taken on all assets, and business processes they support them, included in the scope. By analyzing the gathered documentation and interviewing relevant personnel within the organization, the pentester is able to identify the assets that are most likely to be targeted by an attacker, what their value is and what the impact of their (partial) loss would be.
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, launches, product changes, positioni