• Ingen resultater fundet

1.2 Overview of this report

2.1.3 Threat modeling

This thesis does not aim to model threats to an organization’s environment as such. It is difficult to talk about threat modeling when no specific organization has been selected and the aim of the thesis is not to develop or enhance current threat modeling frameworks.

11http://tools.kali.org/information-gathering/ghost-phisher

12 http://resources.infosecinstitute.com/the-recon-ng-framework-automated-information-gathering/

13See Appendix A.1 for an explanation of Maltego and the terms.

14See Appendix A for my guide to this (Paterva’s documentation is a bit messy).

Figure 2.2: A screenshot of some of the transforms currently available directly in Maltego’s Transform Hub.

In this section an overview of threat modeling in general is given based on the PTES threat modeling-section15. Pointers to other methods are given in as a part of this to provide some differ-ent approaches, as the other pen-testing frameworks are virtually not considering threat modeling.

Threat modeling is essential to penetration testing as it provides the connection between the work the researcher has done and discovered and what an attacker would target. It adds a “real-life value” to the test results and the subject can prioritize mitigations better in accordance with their risk acceptance. For this thesis, the content may aid to establish common attack scenarios to tie the deliveries closer to practical examples.

Even though we say unknown adversary here, it will depend on the rules of engagement. The pen-tester may e.g. get credentials to act in roles of employees [45] to test resilience against misuse cases, which can arise from dissatisfied (e.g. terminated or wrongfully treated) employees [5, 29, 47, 41, 9].

The test can either include extensive communication with the subject about the possible targets

15http://www.pen-test-standard.org/index.php/Threat_Modeling

and their prioritization or the researcher might himself find several different servers during the intelligence gathering phase; the one where e.g the customer database resides is more important than the rest and emphasis during the test should hence be put here by the researcher. This would be theprimary target. If some other programs are running here, they can be collateral, secondary targets of the test.

PTES focuses on identifying (subject) assets/processes and attackers (types and capabilities) and lists four steps of the phase from a high-level perspective16

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

There are several methods available for this, as threat modeling is often an integral part of a risk analysis in order for the organization to take a complete and thorough look of their assets and asset containers (i.e. the units the assets reside on); risk analysis is treated separately in Sec. 2.2.

Two major types of approaches to threat modeling are often seen: Attack trees (system-centric/goal oriented) and misuse cases (attacker-centric)[42]. The same paper finds that attack trees are the most effective of the two for identifying threats; examples of both can be seen in Figure 2.3. The same conclusion is reached in [33] stating that“The attacker-centric approach makes assumptions about attacker capabilities and ressources.”.

(a)An example of a threat tree. (b) An example of misuse cases for threat modeling.

Figure 2.3: Examples of the two major approaches to threat modeling. Both taken from [42].

Several papers discuss approaches for threat modeling. Notable ones17 are [50], which originally proposed the notion and use of attack trees. [57] presents an enhancement of this “[. . . ]for

16http://www.pen-test-standard.org/index.php/Threat_Modeling#High_level_threat_modeling_

process

17I.e. referenced from other papers

expressing aggregate attack behaviors and modalities.”; [62] visits the same idea by enriching attack trees to perform advanced logic calculations to identify weakest links.

Several other papers are concerned with attack trees, as they are widely popular; EMC shows in [18] how they have used them in their software development process. If it is necessary to know more of how to use the findings in practice, [48] gives examples of applications and [36]

describes how security requirements for systems can be derived from the findings. This paper states that it is ultimately always about security trade-off’s (i.e. security shall be seen in context of the risk acceptance), which is also a theme in [21], extending the i framework18 to enhance the analysis of the trade-off. [31] presents similar work, also based oni, to derive security and privacy requirements from the threat modeling.

A more formal approach to attack trees is presented in [1], where an IDS is modeled using attack trees. The approach of [33] does not have a direct practical value as presented in the paper, but may be of academic interest; it contains a great deal of references.

For misuse cases, [52] is one of the papers originally describing the technique; here by extending regular use cases with “negative” uses cases (i.e. uses cases intended to not fulfill); [42] gives ref-erences to the others. Off the same idea, [40] uses the same notion of a negative use case to create attack trees with negative (“soft”-)goals, which can offer a differentiated view of the attacker goals.

To get a view on the practical use with some insight, great examples are the aforementioned [18]

and also [51], which presents Microsoft’s system-centric, practical approach to threat modeling.

It may be valuable to the analyst to look into current attacks methods in the same way it is done in Section 2.5 and 2.4 on current attacks and social engineering techniques respectively.

Focus in those sections are not on overall attack methods, but only within social engineering.

It should be noted, as with risk assessments in general (see also Sec. 2.2), also the threat modeling has to be maintained to continuously return value to the organization for the time invested in the work. By now, supposedly many commercial tools exist to automate this to some extent.

[26] presents an early, theoretic approach for this.