Integrated Threat Modelling

(1)

Integrated Threat Modelling

Dag Eng

Thesis submitted for the degree of Master in Information Security

60 credits

Department of Informatics

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

(2)

(3)

Integrated Threat Modelling

Dag Eng

(4)

Integrated Threat Modelling http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

Abstract

Threat modelling is a component in security risk analysis, and it is commonly conducted by applying a specific approach for discovering and modelling threats. The three main approaches for threat modelling are asset-centric, attacker-centric or software-centric.

In this thesis we ask the question why one should only use just one of the three approaches, and not combine them. We then propose a method called integrated threat modelling which combines the three common threat modelling approaches. Our method presents respondents with three sets of questionnaires, where each questionnaire focuses on either the asset- centric, attacker-centric or software-centric approach. The results we gather from these questionnaires are threat scenarios represented as attack trees.

Our method finally combines the results from the three approaches into a combined threat model.

Following the specification of the method, we present a hypothetical cloud solution that we use in a case study to test how the integrated threat modelling approach could be applied in cloud solutions. We investigate if the integrated threat modelling approach can produce better and richer models than any other approach in isolation. With the limited amount of data collected it is challenging to judge how much the threat modelling can be improved with the use of our method. In conclusion the results show that an integrated threat modelling method can improve the threat modelling, and the study we conduct documents a proof of concept.

(6)

(7)

Acknowledgements

I would like to thank my two supervisors Professor Audun Jøsang at the Department of Informatics and Rune Dyrlie at Telenor Norge AS for valuable advice, suggestions, guidance and interesting conversations over the period I have worked on this Master’s project.

I am also deeply grateful for the support that I have received from my friends and family. Special thanks go to Ole Kristian Rosvold, Guy Oscar Heyden, Joakim Johanson Lindquister, Simen Fjellstad Holm and Lisa Kvalbein for helping out with the case study and for taking the time to read the thesis and suggest improvements.

(8)

(9)

Introduction

(14)

(15)

Chapter 1

Background

People in organisations have a multitude of computing devices available that they use from everywhere: at home, at work, while they are travelling between home and work, and when they are out of the office on business trips or on vacation. These devices range from small, portable smart phones to laptops and desktop computers that run on different hardware and software platforms. What they all have in common, however, is that they are interlinked with large servers and server farms that are commonly referred to as the cloud [39]. The cloud, among other things, provides services that synchronize information between the devices, back up information, and improve collaboration between staff within the same or partner organisations. There are several cloud models, and the services can be provided by both in-house staff, outsourced staff and a combination of both. The notion of Internet of Things (IoT) [41] and the introduction of smart devices [35] means that more and more devices, e.g. common home appliances such as fridges and toasters, are also connected to the cloud and indirectly interlinked with all the other devices people use online. As more and more businesses and individuals adopt these cloud services their organisations are exposed to security threats.

1.1 Problem definition

To address these threats, many organisations bring in internal and external security professionals to assess the security of their organisation and systems [8]. Security professionals know their field and they should be the ones leading security assessment work. However, modern organisations are often complex both in terms of the IT systems used and in how business units are organised, and as such it is hard to get a clear picture of how they operate. As a consequence of this complexity the organisations likely encompass a wide range of competences that the security professionals themselves cannot substitute. The security professionals should therefore include other staff in their work and take advantage of the thoughts, opinions and contributions of those who are not security professionals.

This thesis focuses on threat modeling techniques and in particular on how they can be used to find threat scenarios in the context of cloud-based

(16)

solutions. In the thesis we present a case about a hypothetical Software as a Service (SaaS) [39] cloud solution based on the public cloud model.

Furthermore, the thesis presents a methodology which aims to combine multiple threat modelling approaches and the opinions of people with different backgrounds in order to build better threat models.

More specifically, the thesis seeks to answer the following research questions:

1. How can different threat modelling techniques be combined?

2. What are the the advantages and disadvantages of using integrated threat modelling?

3. How can this be applied to the cloud?

1.2 Research method

The research is based on material on threat modelling found in text books and the academic litterature. We thoroughly investigated three common approaches to threat modelling [32, pp. 34]. These approaches focused on either assets, attacker(s) or software. We proposed a new method to threat modelling where those three approaches were combined. We then conducted a case study, to validate the new method and gather qualitative data for research. Finally, we studied and analysed the data to assess the advantage of integrating the three different approaches to threat modelling.

1.3 Scope limitations

The scope of this thesis is to investigate ways to discover and model threat scenarios. It does not use these threat scenarios further. It does e.g. not cover risk analysis and how risks can be mitigated to improve the security of an IT system. Threat assessment is always a component of risk analysis, which e.g. also includes asset and impact assessment.

1.4 Related research

The method used in this thesis has some similarities with research done by american researchers Potteiger, Martins and Koutsoukos. In 2016 they released a paper titled "Software and Attack Centric Integrated Threat Modeling for Quantitative Risk Assessment" [25]. The similarity between our study’s objective and their project’s objective is that both try to combine multiple threat modelling approaches. Overall though, their approach differs significantly from the approach used in this thesis. They present a quantitative model and use the Common Vulnerability Scoring System (CVSS) [6] to add score values that they use for risk assessment, whereas this thesis aims to build a qualitative threat model with a scope limited to threat scenarios and where risk assessment is not covered.

(17)

Part II

Theory

(18)

(19)

Chapter 2

Concepts and Definitions

Throughout this thesis we use and refer to several concepts and definitions.

To clarify our interpretation of these and to avoid any confusion in our use of them, we use this chapter to define them.

2.1 Security services

In the field of information security it is common to refer to the the following three security services as the main properties for security [13, p 3]: Confidentiality; Availability; Integrity

2.1.1 Confidentiality

Confidentiality is to protect information assets in such a way that information is not disclosed to unauthorised individuals [13, p 5].

An example of confidentiality breach is a situation where an unauthorised user gets knowledge of or access to information belonging to another user or business through a malicious attack against the media where the information is stored, transferred or used. Another example is when con- fidential information is leaked by accident e.g. when an email is sent to the wrong person by accident. The breach could hence be both intentional and provoked by an attacker, but it could also be the result of a bug that causes the system to leak data not intended for the user, under normal or incorrect non-malicious use of the system.

2.1.2 Availability

Availability protection is to ensure the availability of data and resources to authorised individuals [13, p 3].

Availability is crucial for all systems, and for cloud services in particular it is essential that the service is available to its users on demand. An attacker that in any way prevents an authorised user from connecting to their cloud service would render the service useless. Any malicious attacks or non-malicous incidents that prevent the cloud system to serve its users would be considered a breach of availability. For a cloud service the entire

(20)

infrastructure, both hardware and software, connecting the cloud user to the cloud service servers in a data centre, must be operational in order for the cloud service to be usable. Sabotage or failure on either the servers in the cloud provider’s data centre or outage on the connection between the cloud user and the cloud service provider could therefore render the cloud service useless and lead to a breach of availability.

2.1.3 Integrity

Integrity is to protect information assets in such a way that they cannot be modified by unauthorised individuals [13, p 4].

For a cloud service provider this means that no unauthorised user or attacker should be able to alter information owned by another user or business.

2.2 Authorisation

Authorisation is to specify access and usage policies for entities, roles or processes [18, p 48]. The access control system enforces the access policies.

Given a file system, an authorised process can, for example, be approved access to read from, but not write to, a specific file. Whenever the process attempts to read this file, the access control of the system checks a directory where access policies are stored and finds that the entity is authorised to read. It then grants the entity access to read the file.

Should however the entity attempt to write to or delete the file, the access control mechanism should quickly determine that the entity has not been authorised to perform any of those operations and deny the request.

2.3 Asset

An asset is essentially anything of value. It could be a physical entity or information, but it can also be anything that is considered an advantage or resource in a given context [38]. According to the definition used by Adam Shostack, the term asset is commonly used in one of the following three ways [32, p 37]:

1. Things attackers want 2. Things you want to protect 3. Stepping stones to either of these

Examples of assets are buildings and real estate, precious metals or minerals, money, business sensitive information, user data collected in a system, and more abstract, less intangible things such as reputation and brand-name. For the top management of a company meeting typical business goals such as higher average revenue per user (ARPU) [3] and improved earnings before interest, taxes, depreciation and amortisation (EBITDA) [11] margin are also often considered assets.

(21)

Threat agent strength

Vulnerability to threat scenario

Likelihood/frequency of (threat scenario to

cause) incident

Impact of incident on asset

Specific Risk Threat agent

motivation

Threat agent capacity

Threat scenario Threat

agent

Legend:

has attribute contributes to

Figure 2.1: Specific risk model [17]

2.4 Vulnerability

A vulnerability is a lack of a countermeasure or a weakness in an implemented countermeasure. Vulnerabilities can be exploited, and they can be found in software, hardware, procedures and as human weaknesses [13, p 6].

A vulnerability can be a fence with a big (enough for some intruder to climb through), unguarded opening in it, security-unaware staff who are easily manipulated or are in a situation where they are prone to accept bribe. However, a software bug that makes a system interface accept calls that were not intended and that give the caller elevated privilege on the system is also a security vulnerability.

2.5 Threat agent

A threat agent is an entity that has the motivation and capacity to take advantage of and exploit a vulnerability [13, p 6].

Examples of threat agents are burglars, spies, terrorists, hackers, evil system developers or administrators.

2.5.1 Threat agent motivation

The threat agent motivation is typically driven by the entity’s interest in controlling, procuring or damaging an asset. In the case of non-sentient threat agents such as a natural or public health disaster it is clearly somewhat difficult to explain the idea of motivation, but they are non the less considered threat agents.

(22)

2.5.2 Threat agent capacity

The threat agent capacity is given by the skills and efficacy with which the entity can execute some threat scenario. It is therefore dependent on funding and the resources possessed by the entity, i.e. manpower, technology and tools, needed to perform some action.

2.6 Threat scenario

A threat scenario describes series of steps where a potential threat agent with the sufficient capacity exploits a vulnerability to impact an asset.

2.7 Attack

An attack is the manifestation of a threat scenario by a threat agent with motivation.

2.8 Risk

Risk is an abstract term, which according to ISO31000 [16] "... is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated likelihood of occurrence." According to Harris’ CISSP 7th ed. it can be thought of as the likelihood of a threat agent exploiting a vulnerability and the corresponding business impact [13, p 7]. Hence, as shown in Figure 2.1, the specific risk is given as the likelihood of a threat scenario to cause an incident and the impact that incident has on an asset.

2.9 Threat modelling

Threat modelling is a systematic approach used to understand how different threats could be realised and how a successful compromise could take place [13, p 1188]. According to some definitions threat modelling also includes the documentation of threat mitigations [22, p 1].

(23)

Chapter 3

Threat modelling

Threat modelling is simply put the description of techniques where a person or team uses abstractions and information about actors, a system and an organisation in a systematic manner to find and present potential compromises in a structured way [32, p xxii].

The threat modelling in itself is not necessarily the goal or the last action to be performed by a security team. Finding and categorising threats is often just a step in a larger process where a security team performs a complete risk analysis of some system. Threat modelling can therefore be thought of as a component of a process where the overall goal is a complete risk analysis of a system or organisation.

This chapter will present and give a brief introduction to common threat modelling techniques and practices used today and mention some pros and cons associated with each technique.

3.1 The jungle of threat modelling

In order to improve the security of an IT system, the first step one must take is to get an overview of the vulnerabilities in the system or organisation and potential attacks where these vulnerabilities are exploited. To go about finding these threat scenarios, there are several techniques commonly used, and the individual or team looking for threat scenarios in any given situation typically focuses on specific actors in and properties of the IT system they are modelling. In text books and the academic litterature the following concepts are often used [32, pp. 34] to describe various approaches that can be used to analyse some system and find potential attacks against it:

• Asset-centric threat modelling

• Attacker-centric threat modelling

• Software-centric threat modelling

(24)

3.2 Asset-centric threat modelling

In an asset-centric approach the analyst begins by describing the assets of the IT system or organisation that the defender wants to protect. In general, the term asset can be categorised in either of the following three ways [32, p 37]:

1. Things attackers want 2. Things you want to protect 3. Stepping stones to either of these

As the list of assets can become quite large, it is important that the analyst decides which assets are actually relevant in the context of information security, as a smaller list of assets is easier to cope with than one that is large and complex.

Once the assets are defined, the analyst picks assets from the list, one at a time, and focuses on that specific asset to think out ways that it can be impacted. The analyst then describes threat scenarios that could have impact on that particular asset. When all relevant assets have been assessed, the result is a description of threat scenarios that could impact the system or organisation’s assets [32, p 39]. An example of an asset-centric threat modelling approach is CORAS [7, p 3] [37].

3.3 Attaker-centric threat modelling

As the name suggests, the attacker-centric threat modelling approach focuses on the attacker, or rather potential attackers. The analyst uses a list of potential threat agents as a basis for finding threat scenarios. The list the analyst uses can be created either by the analyst or be part of some attacker list collection such as Intel TARA, Verizon’s List, Bernard’s List or a list by OWASP [32, p 478-479].

The analyst would then look at the attacker list and get to know the various threat agents to build an understanding of how they think, behave and act. As the analyst learns more about the threat agents, the idea is that they will think like and portray the attackers in such a way that they will see and understand what their goals might be and as such see relevant threat scenarios [32, p 480].

3.4 Software-centric threat modelling

Another way to threat model is the software-centric approach. The software-centric modelling approach is often referred to as system-centric.

As the name suggests, the software-centric approach is centered around software, namely models of software. These models are commonly expressed as data flow diagrams [32, p 44], but they can just as well be UML, swim lane diagrams or state diagrams. Adam Shostack, the author

(25)

of the book Threat modeling: Designing for Security, argues that data flow diagrams are a good choice for threat modelling [32, p 44] because the diagrams can be made relatively simple and therefore are understandable to people with limited knowledge of UML and other modelling languages with rich notation. Less complex models that do not require much training to understand are likely to encourage these people to contribute valuable input during the threat modelling sessions as opposed to confusing and intimidating them into silence. The choice of diagram therefore really comes down to what backgrounds the members of the threat modelling team have and what they are most confident with.

Once all members of the threat modelling team have agreed upon one or multiple software diagrams that they think describe the system well, they can start looking for system vulnerabilities and threat scenarios. If the system is big and complex, it is perfectly acceptable and normal to add more diagrams that show certain details that do not fit in an overview diagram of the system. Next, to make it easier to find where things can go wrong, it is helpful to add trust boundaries to the diagram. These are boundaries that separate different parts of a system according to the trust that each module or part has in each other. The boundaries are typically drawn as dotted lines crossing the data flow elements in the diagram [32, p 50-51]. The reason for doing this is because vulnerabilities are often found around such boundaries, and thus specifying the system boundaries can help the analyst in getting a clearer picture of the system and where to focus the attention to find as many vulnerabilities and threat scenarios as possible [32, p 51]. With that said, vulnerabilities can be found other places as well; they are not only clustered around trust boundaries.

3.5 STRIDE

There are several ways to create a software-centric threat model, and the approach that will be used as the basis for the software-centric questionnaire in this thesis is known as STRIDE. The STRIDE method was invented by Loren Kohnfelder and Praerit Garg at Microsoft in 1999 [32, p 61]. The name itself, STRIDE, is a mnemonic and stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege [32, p 9]. The threat types described by the mnemonic is defined in Adam Shostack’s book as follows [32, p 9–10], and are properties that are unwanted of any system:

1. Spoofingis pretending to be something or someone you are not.

2. Tamperingis modifying something you are not supposed to modify.

It can include packets on the wire (or wireless), bits on disk, or the bits in memory.

3. Repudiationmeans claiming you did not do something (regardless of whether you did it or not).

(26)

4. Information Disclosureis about exposing information to people who are not authorised to see it.

5. Denial of Service are attacks designed to prevent a system from providing a service. It is often achieved by crashing it, making it unusably slow, or filling up all its storage capacity.

6. Elevation of Privilegeis when a program or user is technically able to do things that they are not supposed to do.

A prerequisite for STRIDE, like any software-centric threat modelling approach, is a good model of the system. The model diagrams should be drawn such that it is easy to spot and put lines around trust boundaries.

Adam Shostack strongly advocates the use of Data Flow Diagrams (DFDs) for threat modelling [32, p 44]. DFD is a type of diagram commonly used to describe how network architected systems work. Figure 3.1 shows the four basic elements [32, p 45] that represent various parts of a classic DFD in addition to the dotted lines that can be used to describe trust boundaries in the DFD.

1. Processdescribes any code execution.

2. Data store describes things that store data. These are typically databases, files or allocated memory segments.

3. External entityas the name suggests, is any entity that is external to the system being modelled. It typically describes a user, user input or external systems that either provide or retrieve information from the system.

4. Data flow (arrow) describes communication between processes, processes and datastore or processes and external systems. Simply put it models the flow of information in the system.

5. Trust boundarysurrounds a set of DFD elements that share the same trust level with dotted lines.

Process Data flow Data store External entity Trust boundary

Figure 3.1: DFD key elements

There are several STRIDE approaches. Hence, there is not just one way to model threats with STRIDE [32, p 61-62]. Examples of approaches to to threat modelling with STRIDE are: STRIDE-per-element, STRIDE-per- interaction, DESIST and the Elevation of Privilege game.

3.5.1 STRIDE-per-element

STRIDE-per-element is an approach where one assumes that certain threat types are more prevalent with certain elements of a DFD diagram. Figure

(27)

3.2 shows a table that is used as a core part of Microsoft’s Security Development Lifecycle (SDL) threat modelling training [32, p 78]. The table simplifies the threat modelling by making it easier to focus on the threat types that are most likely to show up in relation to some DFD element and avoiding the ones that do not. The STRIDE-per-element session is finished when at least one threat has been found for each type of threat element.

3.5.2 STRIDE-per-interaction

S T R I D E

External entity x x

Process x x x x x x

Data flow x x x

Data store x ? x x

Figure 3.2: STRIDE-per-element If one uses the STRIDE-per-

interaction approach, one looks at every (origin, destination, interaction) tuple and lists relevant threat types, i.e. every flow of data between elements in a diagram. The threat types that could affect the interac- tions are then enumerated in a

table grouped by the interaction type. Figure 3.3 shows a simple DFD of the order module of a dropshipping online business. The order and payment processes are handled by the business itself, but the warehouse is handled by an external partner. It is common to make a table such as 3.1 to show STRIDE threat categories that are applicable to the model one is looking for threats against, such as Figure 3.3 in this case.

Browser (U) Order Module (OM)

Bank (B)

Validate credit card

and pay order Payment confirmation

Order product

Order confirmation

Order database (OD) Register order

Warehouse (W)

Send information about customer and order to the warehouse partner and ask them to dispatch order Confirm dispatch

Figure 3.3: DFD of order module for dropshipping online store The table is then extended to include the actual threat scenarios that apply to each of the checked STRIDE boxes (threat types) in the table. The repudiation of interaction two in table 3.1 could for instance be that the warehouse, which is an external partner, claims the order module never

(28)

Element Interaction S T R I D E

1 (OM) sends output to (OD) x x

2 sends output to (external) (W) x x x

3 has inbound data flow from (external) (W) x x x

4 sends output to (external) (B) x x x

5 has inbound data flow from (external) (B) x x x

6 sends output to (external) (U) x

7 has inbound data flow from (external) (U) x x x x 8 (OD) has inbound data flow from (OM) x x x x

9 has outbound data flow to (OM) x x x

10 Flow Data flows to external systems x x x

Table 3.1: STRIDE-per-interaction

sent an order, given some event where a package is not dispatched and received by the customer who ordered it. This is not specific to the STRIDE- per-element method, but it would then be prudent to look for ways to mitigate the repudiation threat. To prevent any repudiation scenario such as the one described, the business could for example implement logging of all dispatch messages sent by the warehouse partner, and the warehouse partner should sign its messages using a digital signature to give the business the ability to verify that the receipt was actually created by the warehouse partner.

3.5.3 Elevation of Privilege game

Another STRIDE approach is the Elevation of Privilege (EoP) game [31, p 5–7]. The EoP game is a threat modelling card game, where the players – three to five – play with cards that contain STRIDE type threats. During the game, when cards are played and read, the players consider whether a threat is relevant for the project or not and if it is, the threat is recorded to be used later. The game is meant to make threat modelling more entertaining and help think of threats that may or may not apply to the model. Obviously, if one of the players come up with relevant threats that are not written on the cards they play, they should still write them down.

It does, however, not affect the game score.

3.6 Attack trees

In December 1999 Bruce Schneier introduced a method he called attack trees in a release of Dr. Dobb’s Journal [28]. The attack tree structure he described is a type of and-or-tree, a tree that has nodes which are connected to their children with either an AND or a OR relation [2]. The root node of such a tree commonly represents a goal and the children represent subgoals to the parent goal. If a parent node has a relation to its children of type AND, then all its children must have reached their (sub)goal for the parent to reach its. If on the other hand the parent node has an OR relation to its

(29)

children, then the parent will reach its goal if at least one of the child nodes reach their.

The "attack trees provide a methodical way of describing threats against, and countermesaures protecting, a system" [29, p 318]. In an attack tree, the root node represents an attack, or attacker goal, the children represent steps required to reach that goal and the leaf nodes different ways an attacker can achieve that goal.

A research group lead by Professor Sjouke Mauw at the University of Luxembourg have extended the attack tree method described by Schneier and introduced a method known as attack–defense trees (ADTrees) [19].

They have extended the attack trees and introduced new elements, among them defense nodes, to be able to present interaction between attacks and defenses in the trees. Along with this research they have developed a package to draw L^ATEX ADTrees. In addition to extend upon Schneier’s attack trees, they have changed the semantics [30] somewhat with regards to the usage of dotted lines between nodes. Bruce Schneier used dotted lines between the leaf nodes and the root node to describe a series of steps that constitute a possible attack [29, p 320]. In the ADTree definition, dotted lines describe a countermeasure [30, p 7]. This difference between Schneier’s attack trees and the ADTrees is however not relevant for the use of attack trees in this thesis. The usage of them in this thesis is simple enough that only parts of the languages where the elements have the same meaning are going to be used.

Attacker goal

Subgoal 1

Subgoal 1.1

Subgoal 1.2

Subgoal 2

Subgoal 2.1

Subgoal 2.2

Subgoal 2.3 Figure 3.4: Attack Tree

attack node

disjunctive refinement conjunctive refinement

Figure 3.4 shows an example of an attack tree with an attacker goal and several subgoals. Subgoal 1 has two subgoals, 1.1 and 1.2, that are bound together by an AND relation, as indicated by the arc in the figure across the paths connecting subgoal 1.1 and 1.2 to subgoal 1. This means that for subgoal 1 to be reached, the attacker has to complete both subgoal

(30)

1.1 and subgoal 1.2. No arc is the default and means that the relation is of type OR. Subgoal 2 has three subgoals, but since it has an OR relation with its children, only one of the subgoals 2.1, 2.2 and 2.3 needs to be completed for subgoal 2 to be reached. The attacker goal can be reached if either subgoal 1 og subgoal 2 is reached. According the figure, the attacker goal can therefore be reached if the attacker completes either or more of the subgoals 2.1, 2.2, 2.3 or both subgoals 1.1 and 1.2.

An attack tree can be much more appealing and easier to work with if it has the actual presentation of a tree. In many cases however, either because of limitations with the tools used to draw it or simply because a graphically drawn tree takes up too much space on a sheet of paper, especially if the attack tree is complex and has many nodes in width and depth, a more compact tree representation is useful.

(Attacker goal)

| - (Subgoal 1)

| | = (Subgoal 1.1)

| | = (Subgoal 1.2)

| - (Subgoal 2)

| | - (Subgoal 2.1)

| | - (Subgoal 2.2)

| | - (Subgoal 2.3)

() node

| node depth level + 1 - disjunctive refinement

= conjunctive refinement

Figure 3.5: ASCII Attack Tree

Attack trees can therefore also be written in outline form, as structured text. Bruce Schneier presented an example of how that could be done in the book Secrets and Lies: Digital Security in a Networked World [29, p 324]. The research group working on the ADTree method have developed Schneier’s structured text approach further and come up with an ASCII friendly way that is easy to read and requires no tool other than a text editor, where ASCII punctuation marks and symbols are used to indicate node depth, disjunctive and conjuctive relations and countermeasure [30, p 8].

Figure 3.5 shows an ASCII attack tree with the same semantic meaning as the one shown in Figure 3.4. Each line in the ASCII attack tree layout contains one node, and the node element is prefixed by its depth indicator and the type of relation it has to its parent. This applies to all nodes except the root node, which does not have any prefixes, since it is at the top with no parent and with a depth of zero.

(31)

Chapter 4

Methodology

Threat modelling is typically conducted by a team of professionals [32, p 31], who in brainstorming sessions find and enumerate threats against a system or organisation they are analysing. During the threat modelling, they often focus on either the assets, attacker(s) or the software [32, p 34].

It is worth asking the question why one should only use just one of the approaches and not combine them?

In his book on threat modelling Adam Shostack claims that a combination of approaches rather than centering the modelling on either the assets, the attackers or the software tends to be confusing [32, p 34]. A goal of this Master’s project is therefore to find and present a method that combines these approaches in a systematic, non-confusing way, such that each approach complements the others in providing a rich, structured threat model, rather than confuse.

In this thesis we present a method that integrates the three common approaches to threat discovery into a combined threat modelling technique.

The technique includes three questionnaires, where one questionnaire is asset-centric, another attacker-centric and the third software-centric. Re- spondents will then be presented with either of the three questionnaires, which they answer during the threat modelling session. Each respondent is only supposed to answer one of the three questionnaires. Once the respondents are done answering the questionnaires, the answers from all three questionnaires are combined. The answers are extracted and compared against each other to determine whether the threat found in one questionnaire is unique across questionnaire one, two and three or if the same threat is found in more than one questionnaire. As a result the method presents an aggregated extract from the three questionnaires.

It is also important to point out that although the focus of this thesis is to combine the asset-, attacker- and software-centric approaches to threat modelling, overall, the method presented is generic and could be modified to combine other threat modelling approaches in addition to or instead of the three ones used in the thesis. The method is a framework to structure a process where multiple threat modelling approaches are applied simultaneously to make results that are then combined to give one set of output.

(32)

S1

S2

S3

Case to be analysed

Attacker- centric approach Asset-

centric approach

Software- centric approach

A1

A1.1 A1.2

A2

A2.1 A2.2

A3

A3.1 A3.2

A1

A1.1 A3

A3.1 A3.2

A2

A2.1 A2.2

Figure 4.1: Integrated Threat Modelling

4.1 The steps

Figure 4.1 shows an example overview of the integrated threat modelling approach with its three main steps separated by dashed lines.

(33)

4.1.1 Step 1 (S1)

The cloud in step one represents the case that is due to be analysed for threat scenarios. The case should be described with text and diagrams.

4.1.2 Step 2 (S2)

The second step shows how the case described in step one is analysed in parallel using three different approaches. Even though the approaches are different and are handled by different teams, they output attack trees.

As mentioned above, the approaches do not have to be asset-, attacker- and software-centric. It is possible to use more than the three or other approaches as well.

4.1.3 Step 3 (S3)

The third step is the integration step, and this is where the output from all three approaches are combined into a complete model of threat scenarios.

As shown in Figure 4.1, the threat scenario described in the output of the third approach (A3) was found to represent the same as the first approach’s node 1.2 (A1.2). Hence the two trees were merged together by replacing the node A1.2 in tree A1 with the tree from A3. The output from the second approach (A2) was found to represent a separate threat scenario that was completely unrelated to any of the other trees. That tree was therefore pulled down and repeated alongside the merged tree.

Note that the merge step shown is specific to Figure 4.1 and not general to the method. Which tree or if any trees should be merged at all depends on the actual trees and the content the different approaches output.

4.2 Why a qualitative rather than a quantitative model

Most models used for threat modelling and security risk analysis described in the literature are qualitative [27, p 1] [15]. Some have, however, come up with models that intend to provide a quantitative evaluation of risk [25, p 1]. For this thesis we have chosen a qualitative model, because at some point one must decide what values to assign the input data, and doing so correctly using a quantitative approach can be very time-consuming without necessarily giving anything back in terms of increased certainty in the end model. In many cases the impacted assets, which can be very abstract if they are intangible, are are not valued using a quantitative approach in the first place and as such the value assigned may not be definite [10, p 20]. With abstract assets it is therefore hard to back up claims that one particular asset has a value of 100 000 NOKs whereas another is valued at 250 000 NOKs.

In his book Empirical Model-Building and Response Surfaces [4, p 424], George Box claims that "...all models are wrong, but some are useful".

Models are for the most part supposed to describe the reality as simple as possible, and describing reality in models is hard. Consequently all

(34)

models are in one way or another indefinite, and the ouput from a given model is not entirely correct even if the input supposedly is. Essentially at some point then, one must abstract, and rather than spend much time on assessing the so-called true value of e.g. an asset, we think the time is better spent evaluating and analysing the results from the model and use the model for what it is, rather than think of it as a perfect, true description of reality.

4.3 Thoughts on combining multiple approaches to threat modelling

It is easy to see that it would require quite a bit of overhead to make and pass out multiple questionnaires. We do, however, believe that in many contexts it can be worthwhile in terms of the gains in number of threat scenarios discovered compared to what one would get by using just one approach. When a threat modelling team is heterogeneous and the members have different backgrounds and interests, it is better to take advantage of this, rather than to force people to adjust to one specific approach, which all team members may or may not be experienced with.

CEOs and upper management in businesses tend to be very focused on assets, and could therefore probably benefit from an asset-centric approach. They care a lot about the business’ economic resources, such as investments, physical things, i.e. buildings, machinery, tools and IT equipment, and last but not least they tend to place great emphasis on the business reputation as well as the notion of a good brand to attract as many customers and investors as possible. Additionally the top management also often consider meeting business goals as assets. Threat scenarios that involve negative impacts on any of these assets either directly or indirectly via stepping stones are hopefully found and pointed out in the asset-centric threat modelling session. What the upper management may not possess though, is the technical knowhow to describe these threats in great detail and with a sufficient clarity that proper mitigations can be found. As seen from the technical department these threats could be very abstract and imprecisely defined. This could also be partly related to the way an asset-centric approach reduces everything to assets, rather than something specific, such as a mail server or workstation [32, p 39]. That the findings are less well defined does not necessarily make them any less relevant for the threat modell however, and hence it could be a good idea to combine findings from the asset-centric approach with the results from the other approaches.

Software engineers and developers, on the other hand, have technical knowhow and typically know, or could easily get to know, the inner workings of a particular IT system. Because of their background they are more likely to be familiar with different software or system diagrams such as flow diagrams and UML. A software-centric approach could therefore give them an edge in discovering threat scenarios.

Others are perhaps well informed about the world’s threat agents, and

(35)

are so more in favour of and could bring more to the table with an attacker- centric approach.

4.4 Questionnaires as tools for data collection

The threat modelling technique presented in this thesis is centered around three types of questionnaires. The questions that are asked in the three questionnaires must guide the respondents through the questionnaires and help them to think of as many threat scenarios against the system or organisation being modelled as possible. While questions tailored specifically to some context may make the questionnaires better suited to guide the respondents to give good answers for a given situation, and consequently help them produce better threat modelling results, the questionnaires developed for our method is generic. The idea is that the questions described in the last three sections of this chapter can be used either directly and unchanged or as a basis to create more specific questions for any given situation. Questions can certainly be removed and added as the analyst sees fit.

The questionnaire-based method is very flexible in terms of the support tools that can be used, and since it combines several common approaches, tools developed specifically for each of those approaches can be used by the respondents of the questionnaires to find threat scenarios and mitigations.

4.5 Why multiple, short questionnaires is best

At first glance it may seem more efficient to limit the number of teams and questionnaires to one to avoid the overhead of running three parallel questionnaires in three different teams and later go through quite a bit of trouble to combine the findings of these teams. However, research conducted by Dr. Susan A. Wheelan suggests that smaller groups, i.e.

groups containing three to six members, are more productive than larger groups [42, p 13]. The same research has shown that smaller groups are more likely to reach higher stages of group development [42, p 6–7], and thus a group where there is more teamwork and less dependence on the leader.

The use of multiple questionnaires encourages the use of multiple, smaller groups rather than one big group. A threat analysis conducted by a group where one individual has too big influence can be highly biased towards an area that is of particular interest to that person and could therefore increase the likelihood that important aspects are not considered or simply are forgotten. Since the goal of this method is to find and analyse as many threat scenarios as possible, multiple, smaller groups with strong teamwork and many opinions is better than a large group which suffers from groupthink [12] and has passive members who go along with whatever a single leader suggests. In larger groups it is easy to become the silent participant, the one who nods and smiles, but does not contribute.

People are silent for a variety of reasons. Some might fear that their

(36)

opinions will be dismissed, and others are not comfortable speaking if they do not know who every other team member is [33]. Some might even be free riders [9] and therefore choose not to contribute. Either way, in smaller groups it is easier to spot a silent participant and it is easier for a reticent person to feel comfortable. Additionally, members of smaller groups will probably also feel more pressure to come up with ideas since everyone knows who that person is and remembers each team member’s contributions.

For someone who is experienced in fields other than ICT and information security, an information security analyst can come across as superior, and it is easy to think that the specialist’s opinion and word is worth more than theirs. The limited scope of each questionnaire makes it possible to assign the members to groups based on their experience and whether they are more likely to take advantage of an asset-centric, attacker-centric or software-centric approach, as mentioned in section 4.3. This, in turn, em- boldens the formation of groups of people with similar backgrounds and lowers the threshold within the group that otherwise would keep those who are not information security specialists from speaking.

4.6 Merging the collected data

A crucial part of this method is to find a way to present the data from the three questionnaires and merge them. In order to compare the threat scenarios from the three different approaches it is important that they are presented in a way that allows the analyst to easily compare them.

The results coming from each questionnaire should therefore be uniformly structured and presented. The attack trees described by Bruce Schneier [28] and the enhanced attack trees, ADTrees [19], are exactly that. The uniform way to present the output from the different approaches should therefore be based on attack trees. Once all questionnaires are answered and presented on attack tree form, the threat modelling supervisor, i.e. the main organiser and the team or person who organises the completion of the threat modelling sessions, can compare all trees and merge the ones that are essentially the same.

With the threat scenarios structured and presented in the same way, namely as trees, they can fairly easily be merged. Obviously whether it is easy to combine two or multiple trees depends on how well structured they are in the first place and whether they are defined using precise language. It is likely that many of the trees will be similar even if they are not described using the same terms. The supervisor(s) should exercise discretion and focus on the actual content and semantics of the trees and less on how the threat scenarios are formulated. If they find that the same threat scenario is described by multiple trees, the trees should be merged. There are no specific rules that dictate how attack trees should be merged. The trees will merely be used as tools to structure the presentation of threat scenarios and the steps that could lead to such threat scenarios.

If trees that describe similar threat scenarios are found, the supervisor(s)

(37)

should look carefully on the children of those threat scenario root nodes and see if they too are similar. If they are not, the two root nodes may really describe different threat scenarios. It is also possible that the respondents have thought of different steps that lead to the same threat scenario. If that is the case, the trees should be merged and the supervisor(s) should specifically make sure that the content of all child nodes from all threat scenario root nodes are included in the new merged tree. What is really important then, is that the merge supervisor(s) exercise discretion and carefully look after similarities and differences between the attack trees produced by all the approaches. Furthermore, they should also expect to come across threat scenarios that are unique across the results from the approaches used. Unique threat scenarios must be kept and included in the final threat model.

4.7 Questionnaires

The following three sections present and elaborate on the specificities of each of the questionnaires that are based around the asset-, attacker- and software-centric approaches. Questionnaires based on other approaches could also be created even though they are not covered in this thesis.

4.8 Asset-centric questionnaire

The asset centric questionnaire should guide the respondent to find as many threat scenarios as possible against a set of assets that they deem most valuable to the system or organisation they are modelling. The method to achieve this is heavily influenced by the way threats are identified and modelled in threat diagrams in the CORAS security risk analysis method, which has a strong focus on assets [7, p 3].

The questionnaire should include the following questions in the order given.

1. What are the five most important assets to the system or organisation being modelled?

2. How can these assets be impacted? Describe scenarios where the assets from the previous question are attacked.

3. Create attack trees to present the threat scenarios from the last question. Create one attack tree per threat scenario.

4.8.1 Question 1

What are the five most important assets to the system or organisation being modelled?

The reason the respondent is only asked to mention five assets is to limit the number of assets that will be used in the modelling and make the respondent focus on what their most valuable assets are.

(38)

The respondent is asked to mention only five assets in order to limit the number of assets to consider for the sake of reduced complexity. It also stresses the respondent to focus on what the most valuable assets really are.

Obviously the organisation or system can have more than these five assets, but including dousens of assets in the model would make the model considerably more complex. An asset is not necessarily something tangible, it could just as well be an abstract notion comprised of multiple rather than a single entity. Hence what one person describes as five assets, another person sees and describes as just one asset. It all depends on how they look at it, and people often view things differently.

4.8.2 Question 2

How can these assets be impacted? Describe scenarios where the assets from the previous question are attacked.

The respondent hopefully spent a bit of time to reflect on the previous question to end up with a short list of assets that are very important to them. For this question the respondent should go through the list of assets, one at a time, and think thoroughly about how the assets can be impacted.

They should write down any threat scenarios they can think of where an incident has impact on the particular asset they are looking at. Who or what the threat agent is, is not relevant at this stage – the focus for this approach is the assets and how they can be affected. Any threat scenario that involves one of the assets from the previous step is therefore highly relevant and should be mentioned.

4.8.3 Question 3

Create attack trees to present the threat scenarios from the last question. Create one attack tree per threat scenario.

The respondent is instructed to perform this step to present their findings in a structured manner. This task could just as well have been a part of the previous question rather than be represented as an extra instruction. However, that would have required the respondent to think about presentation of data rather than what was really important for the previous step – to find as many threat scenarios as possible. If the respondents are familiar with attack trees already, it would make more sense to merge this task with the previous question than to keep it as a separate step.

4.9 Attacker-centric questionnaire

Since the attacker-centric approach is based on a list of potential attackers against a system and aims to find threats against a system or organisation based on what threats these attackers likely pose, the questionnaire should include questions that guide and help the respondents to choose a set of attackers and subsequently find as many threats as possible where these

(39)

Capability Typical threat agent Typical budget Very high Government or large organisation > 1000 million NOK High Organisation or terrorist group > 100 million NOK Medium Smaller organisation < 100 million NOK Low Small group of people or individual < 1 million NOK

Table 4.1: Attacker capability versus budget

attackers are the threat agents. The slides from a presentation held by Tony Martin-Vegue on the ISACA 2014 Fall Conference [20] has been of great inspiration in developing the questions for this questionnaire.

The questionnaire should include the following questions in the order given.

1. Which top five threat agents do you consider likely candidates to attack to your organisation? These can be e.g. humans (whether intentional threat agents, hence hostile, or non-intentional threat agents, i.e. non-hostile), malicious software as well as force majeure.

2. Estimate and qualitatively specify the capabilities and resources the attackers have at their disposal as either "very high", "high",

"medium" or "low". Use table 4.1 as inspiration if you are unsure about the threat agent capability.

3. For each of the five threat agents you mentioned, specify whether they are external or internal (insider) and whether they have a strong agenda or motivation to harm your system or organisation.

4. What are the attackers’ intentions with one attack or multiple attacks?

Give the answer as a selection of one or multiple categories from the following list: Power Projection, Political Pressure, Obstruction, Deception, Intelligence Gathering, Counterintelligence, Financial Gain, Amusement, Gratuitous Defacement or Damage, Advocacy 5. Think about the answers you gave for the previous question and

further specify the goal(s) of each attacker.

6. Use the goals from the last question and create an attack tree for each goal that describes ways the attacker can reach their goal.

4.9.1 Question 1

Which top five threat agents do you consider likely candidates to attack to your system or organisation?

The reason the respondent is only asked to provide five potential attackers is to make the respondent really focus on listing their absolute worst adversaries. In addition to this, a smaller list makes the model less complex. Since this means the user could potentially omit dangerous attackers from the list, the requirement to only mention five should not

(40)

be strictly enforced. If the respondent has good reason to mention more, they should do so. The point of the limit is to make sure the respondent thinks well through which attackers are likely to attack their system or organisation and to make sure the model does not get too complex.

Because creating a list of attackers is both demanding and time consuming, it is common to use pre-developed attacker lists or lists of attacker archetypes to more easily identify relevant potential attackers [32, p 477] against a system or organisation. Providing the respondent with an attacker list, such as Intel’s Threat Agent Library [5] or OWASP’s enumeration of threat agents [32, p 479] can therefore help them think of attackers that they otherwise would not think of.

4.9.2 Question 2

Estimate and qualitatively specify the capabilities and resources the attackers have at their disposal as either "very high", "high", "medium" or "low". Use table 4.1 as inspiration if you are unsure about the threat agent capability.

The table should only be used to guide the respondents in making a pick. There is no definitive answer and there could be organisations with larger budgets than 1000 million NOK that could still be considered to have medium capability, and vice versa. The respondents should therefore be advised to exercise discretion and only use the table as a guide if there is little information about the attacker available.

The reason to ascertain the capability of the threat agent is to get a clearer picture of who or what we are facing and if they have the capability to harm the organisation. Clearly the data used to determine this capability rating is often based on public knowledge about the opponent in addition to intelligence we or trusted parties have gathered, neither of which is always true, and it is therefore not clear cut whether a threat agent has the capability to harm our IT system or not. In general it is therefore best to assume the worst about attackers’ capability if the rating we give them is based on little evidence.

4.9.3 Question 3

For each of the five threat agents mentioned, specify whether they are external or internal (insider) and whether they have a strong agenda or motivation to harm your system or organisation.

This question serves several purposes. Knowledge about a company, i.e. its people, its processes, or its IT systems can be considered a resource and as such a capability. The establishment of a threat agent’s relation to an organisation also helps to get an impression of what kind of attacker we are facing and hence the kind of motivation they are likely to have. Internal and external attackers are likely to have different motivational drives and this can be relevant information. Whether an attacker is internal or external is just one property of the attacker, but as the respondent learns more about the attackers it is easier to get an idea of what really drives them.

(41)

4.9.4 Question 4

What are the attackers’ intentions with one attack or multiple attacks? Give the answer as a selection of one or multiple categories from the following list: Power Projection, Political Pressure, Obstruction, Deception, Intelligence Gathering, Counterintelligence, Financial Gain, Amusement, Gratuitous Defacement or Damage, Advocacy

This question prepares the respondent for the next question by introducing them to a set of categories [20, s 38] that represent objectives.

Once the respondent has chosen one or at top a few objectives that it assumes the attacker has, they have limited the scope of available goals somewhat and have an easier task ahead of them when they go to the next question, where the detailed attacker goals should be specified.

4.9.5 Question 5

Think about the answers you gave for the previous question and further specify the goal(s) of each attacker.

The previous question should already have given the respondent some time to reflect on the objective(s) that each attacker has. And with the objective defined, it is easier to think about goals that align with that objective.

4.9.6 Question 6

Use the goals from the last question and create an attack tree for each goal that describes ways the attacker can reach that goal. If an attacker has multiple goals, one tree should be created for each goal.

This is not really a question, but it is a task the respondent is asked to perform to present their findings in a structured manner. This task could just as well have been a part of the previous question rather than be represented as an extra step. However, that would have required the respondent to think about presentation of data rather than what was really important for the previous step – to think of as many attacker goals as possible. If the respondents are familiar with attack trees already, which is not unlikely if they are chosen as candidates for the attacker-centric approach, it would make more sense to merge this task with the previous question than to keep it as a separate step.

4.10 Software-centric questionnaire

The software-centric approach differs from the previous two in that it focuses on the internals of a system and a model of these rather than on concepts such as assets and attackers. Hence the technique is not very well suited to model an organisation, but can be particularly useful for system developers since they generally have a good understanding of software models and interfaces.

(42)

1. Build an overall diagram of the system you wish to find threats against. Do not include too many details as that will increase the complexity.

2. If more details about the system are required than what was shown in the previous diagram, create one or multiple sub diagrams that show the details of particular areas in that diagram.

3. Inspect the diagram and sub diagrams and find threats against the system. Depending on the size of the threat modelling team this step can be completed in two ways, by following either alternative a) or alternative b). If the respondent is a team of two or more members, they should follow alternative a), otherwise, if there is only a single respondent, they should follow alternative b).

(a) Play the Elevation of Privilege (EoP) [32, p 8] game and write down threats your team finds during the session. The game is meant to stimulate your thinking, and any threat scenarios you come up with should be written down, even if it is not related to an EoP card you looked at.

(b) Use the STRIDE mnemonic and STRIDE-per-element or STRIDE- per-interaction to find threat scenarios.

4. Create one attack tree for each unique threat scenario you found in the previous step. Note that the STRIDE findings are very specific and one threat scenario can often be be described by the result of multiple STRIDE incidents.

4.10.1 Question 1

Build an overall diagram of the system you wish to find threats against. Do not include too many details as that will increase the complexity.

The respondents are free to use whatever modelling language they feel most comfortable using, whether that is UML, swim lane diagrams or data flow diagrams. They should bear in mind however, that if they are working in a larger group or team, languages such as UML are a lot more complex than more simple data flow diagram and hence could be outside the comfort zone of one or multiple team members. It is therefore important that all team members agree on which language is used for presentation as this affects all members’ ability to contribute to the threat modelling task.

4.10.2 Question 2

If more details about the system are required than what was shown in the previous diagram, create one or multiple sub diagrams that show the details of particular areas from the first diagram.

(43)

If the respondents find that the general diagram they made is insuffi- cient, they can describe more details about the system by creating sub diagrams of particular areas in the diagram described as an answer to the previous question. This is a useful feature in that it allows the respondens to describe e.g. complex processes that would clutter the overview diagram and therefore should not be in it [32, p 25]. At the same time, omitting the details completely means potential vulnerabilities and threats could be kept from surfacing and would increase the likelihood that they are left out of the end model.

4.10.3 Question 3

Inspect the diagram and sub diagrams and find threats against the system.

Depending on the size of the threat modelling team this step can be completed in two ways by following either alternative a) or alternative b). If the respondent is a team of two or more members, they should follow alternative a), otherwise, if there is only a single respondent, they should follow alternative b).

(a) Play the Elevation of Privilege (EoP) [32, p 8] game and write down threat scenarios your team finds turing the session. The game is meant to stimulate your thinking, and any threats you come up with should be written down, even if it is not related to an EoP card you looked at.

(b) Use the STRIDE mnemonic and STRIDE-per-element or STRIDE-per- interaction to find threats.

If there are multiple team members, they can use the STRIDE mnemonic in addition to the EoP game to find threat scenarios.

4.10.4 Question 4

Create one attack tree for each unique threat you found in the previous step. Note that the STRIDE findings are very specific and one threat scenario can often be be described as the result of multiple STRIDE incidents.

(44)

(45)

Part III

Case study

(46)

Integrated Threat Modelling

Integrated Threat Modelling

Dag Eng

Thesis submitted for the degree of Master in Information Security

60 credits

Department of Informatics

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

Integrated Threat Modelling

Dag Eng

Abstract

Acknowledgements

Contents

Part I

Introduction

Chapter 1

Background

1.1 Problem definition

1.2 Research method

1.3 Scope limitations

1.4 Related research

Part II

Theory

Chapter 2

Concepts and Definitions

2.1 Security services

2.2 Authorisation

2.3 Asset

2.4 Vulnerability

2.5 Threat agent

2.6 Threat scenario

2.7 Attack

2.8 Risk

2.9 Threat modelling

Chapter 3

Threat modelling

3.1 The jungle of threat modelling

3.2 Asset-centric threat modelling

3.3 Attaker-centric threat modelling

3.4 Software-centric threat modelling

3.5 STRIDE

3.6 Attack trees

Chapter 4

Methodology

4.1 The steps

4.2 Why a qualitative rather than a quantitative model

4.3 Thoughts on combining multiple approaches to threat modelling

4.4 Questionnaires as tools for data collection

4.5 Why multiple, short questionnaires is best

4.6 Merging the collected data

4.7 Questionnaires

4.8 Asset-centric questionnaire

4.9 Attacker-centric questionnaire

4.10 Software-centric questionnaire

Part III

Case study