EFFECTIVENESS OF THREAT MODELLING TOOLS

Aantal woorden: 17 000

Lorenz Verheyden Stamnummer : 01270743

Promotor: Prof. dr. Len Lemeire

Master of Science in de Handelswetenschappen

Academiejaar: 2017 – 2018

PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. I declare that the content of this Master’s Dissertation may be consulted and/or reproduced, provided that the source is referenced. Naam student/name student : Lorenz Verheyden Handtekening/signature

i

Executive summary

In dit onderzoek wordt de effectiviteit van threat modelling toepassingen onderzocht door te meten welke

extra waarde ze bieden aan het beveiligingsproces. Threat modelling is een techniek om

beveiligingsproblemen van applicaties of systemen te ontdekken aan de hand van een architecturale

analyse. Op deze manier bekomt men een bedreigingsprofiel van de applicatie of het systeem en kan men

beveiligingsmaatregelen gericht implementeren om zich tegen deze geïdentificeerde bedreiging in te dekken.

Het onderzoek werd uitgevoerd in de vorm van een beschrijvende case studie, deze keuze werd gemaakt

omdat er reeds weinig onderzoek bestaat omtrent de effectiviteit van threat modelling programma’s. Het

nadeel van deze methodologie is dat er geen sterke conclusies kunnen worden gevormd, de conclusies van

dit onderzoek zijn daarom enkel van toepassing op de twee onderzochte programma’s en voor de gebruikte

steekproef. Tijdens de case studie werd een experten paneel van zes experten opgericht waarbij twee

experten de architecturale omschrijving van een systeem hebben ontworpen en gevalideerd. De resterende

experten werden gevraagd om een bedreigingsanalyse uit te voeren met twee threat modelling programma’s

die automatisch bedreigingen genereren: (1) de Microsoft Threat Modelling Tool 2016 en (2) de Tutamen

threat modelling tool.

Voor het meten van de effectiviteit van de programma’s werden drie dimensies onderzocht: (1) de

accuraatheid van de automatische bedreigingsgeneratie, (2) de tijd benodigd om een bedreigingsanalyse uit

te voeren, en (3) de gebruiksvriendelijkheid van de programma’s. Beide programma’s slaagde er niet in om

alle bedreigingen van het systeem te identificeren, er was steeds expertise van de beveiligingsanalist nodig

om de lijst van bedreigingen te vervolledigen. Het vermogen om deze lijst te vervolledigen is afhankelijk van

het aantal jaren threat modelling ervaring van de analist. Verder zijn beide programma’s sneller in het

uitvoeren van een bedreigingsanalyse dan niet-gespecialiseerde toepassingen voor alle experten in de

steekproef, zelf zonder voorgaande kennis van het programma. Ten slotte is de gebruiksvriendelijkheid van

de programma’s afhankelijk van de persoonlijke ‘workflow’ van de analist en zijn/haar persoonlijke

voorkeuren.

Uit het onderzoek kan men besluiten dat de twee threat modelling toepassingen: Microsoft Threat Modelling

tool 2016 en Tutamen threat modelling tool extra waarde bieden aan het beveilingsproces. Er dient echter

extra onderzoek te gebeuren met een grotere steekproef en/of extra threat modelling toepassingen om deze

bevinden te verifiëren en generaliseren.

ii

Preface This Master’s dissertation came to life as part of my Master Business Administration: Management and IT

education at the university of Ghent. I would like to take this opportunity to thank every person who helped

and supported during my studies and the writing of this thesis.

First and foremost, I would like to thank my promotor Prof. dr. Len Lemeire for offering me the possibility to

write this thesis on a very interesting subject and for all the guidance and knowledge that he has provided

over the course of writing of this dissertation. He was always able to guide me in the right direction in case I

got stuck.

Secondly, I would provide special thanks to the people of Toreon, who provided me with the security

experts that were needed to develop the threat modelling case and helped me get in contact with the other

security experts on the panel.

Last, but not least, I would like to thank all my family and friends, who have supported me over the years. It

would have been impossible to be where I am today without their support.

Thank you very much,

Lorenz

iii

Table of Content

Contents EXECUTIVE SUMMARY .............................................................................................................................................. I

PREFACE ................................................................................................................................................................... II

TABLE OF CONTENT ................................................................................................................................................. III

LIST OF ABBREVIATIONS ........................................................................................................................................... V

LIST OF FIGURES ...................................................................................................................................................... VI

LIST OF TABLES ....................................................................................................................................................... VII

1. INTRODUCTION .................................................................................................................................................... 1

2. LITERATURE .......................................................................................................................................................... 3

2.1 WHAT IS THREAT MODELLING ....................................................................................................................... 3 2.2 DIFFERENT THREAT MODELLING APPROACHES .................................................................................................. 6

2.2.1 Attack centric threat modelling ....................................................................................................................... 6 2.2.2 Asset centric threat modelling ......................................................................................................................... 8 2.2.3 Software centric threat modelling ................................................................................................................... 8

2.3 COMMONLY USED METHODOLOGIES .............................................................................................................. 9 2.3.1 STRIDE.............................................................................................................................................................. 9 2.3.2 LINDUNN: a STRIDE analysis for privacy ........................................................................................................ 11

2.4 LESS COMMONLY USED METHODOLOGIES ..................................................................................................... 12 2.4.1 Trike ............................................................................................................................................................... 12 2.4.2 VAST............................................................................................................................................................... 12 2.4.3 PASTA ............................................................................................................................................................ 13

2.5 THREAT MODELLING TOOLS AND SCIENTIFIC CONTRIBUTION ............................................................................. 13

3. RESEARCH QUESTIONS ....................................................................................................................................... 15

3.1 Research question ............................................................................................................................................ 15 3.2 Sub questions .................................................................................................................................................... 15

4. METHODLOGY .................................................................................................................................................... 15

4.1 Research design ................................................................................................................................................ 15 4.1.1 Threat modelling case design ........................................................................................................................ 16 4.1.2 Expert panel creation..................................................................................................................................... 17 4.1.3 Threat modelling tools ................................................................................................................................... 18 4.1.4 Survey ............................................................................................................................................................ 20

5. RESULTS ............................................................................................................................................................. 20

5.1 Manual benchmark .......................................................................................................................................... 20 5.2 Expert panel ...................................................................................................................................................... 23 5.3 Microsoft Threat Modelling Tool 2016 ............................................................................................................. 24 5.4 Tutamen ........................................................................................................................................................... 32

iv

6. DISCUSSION ........................................................................................................................................................ 37

6.1 Tool accuracy .................................................................................................................................................... 37 6.2 Time efficiency .................................................................................................................................................. 38 6.3 User friendliness ............................................................................................................................................... 39 6.4 Do threat modelling tools provide extra value to the security process? .......................................................... 40 6.5 Limitations of the research ............................................................................................................................... 40 6.6 Further research ............................................................................................................................................... 41

7. CONCLUSION ...................................................................................................................................................... 41

8. SOURCES ............................................................................................................................................................... I

9. APPENDIX ............................................................................................................................................................ IV

Appendix A: The architectural description provided to the expert panel ................................................................ A Appendix B: An example of the descriptor language used in the Tutamen threat modelling tool ........................... B Appendix C: The survey presented to the expert panel ............................................................................................ C

v

List of abbreviations

CAPEC Common Attack Patterns

CLASP Comprehensive, Lightweight Application Security

Process

CWE Common Weakness Enumeration

DFD Data Flow Diagram

DOS Denial Of Service

DREAD Damage potential, Reproducibility, Exploitability,

Affected Users, and Discoverability

EU European Union

GDPR General Data Protection Regulation

IOT Internet of Things

IT Information technology

NIST The National Institute of Standards and

Technology

NSA National Security Agency

OWASP Open Web Application Security Project

PII Personally Identifiable Information

PASTA Process for Attack Simulation and Threat Analysis

SaaS Software As A Service

SDL Security Development Lifecycle

SDLC Software Development Lifecycle

SSL Secure Socket Layer

SSO Single Sign On

TAM Threat Analysis & Modelling Tool

VAST Visual, Agile, and Simple Threat modelling

vi

List of Figures Figure 1: A graphical representation of the amount of records being stolen in data breaches in 2016 and 2017. (Information is beautiful, 2018) Figure 2: The system security engineering process. (Myagmar, Lee & Yurcik, 2005) Figure 3: A simplified DFD example for a web shop. Figure 4: An example of a network diagram (for a Netflows system). (Myagmar, Lee & Yurcik, 2005) Figure 5: An Attack tree example for opening a physical safe. (Schneier, 1999) Figure 6: A level 1 DFD example for a digital publishing system. (Scandariato, Wuyts & Joosen, 2013) Figure 7: An attack tree example showing how tampering with the data flow may occur. (Scandariato, Wuyts & Joosen, 2013) Figure 8: A DFD example and a generated list of threat in the Microsoft Threat Modelling Tool (MSDN, 2017) Figure 9: The manually made DFD for the threat modelling case. Figure 10: The DFD of the threat modelling case made in Visio. Figure 11: The threat modelling case DFD made by expert 1 (The Microsoft Threat Modelling tool 2016). Figure 12: The threat modelling case DFD made by expert 2 (The Microsoft Threat Modelling tool 2016). Figure 13: The threat modelling case DFD made by expert 3 (The Microsoft Threat Modelling tool 2016). Figure 14: The threat modelling case DFD made by expert 4 (The Microsoft Threat Modelling tool 2016).

vii

List of tables Table 1: Breakdown of the activities in the manual benchmark. Table 2: The analysis of the first trust boundary of the manual benchmark. Table 3: The analysis of the second trust boundary of the manual benchmark. Table 4: The analysis of the third trust boundary of the manual benchmark. Table 5: An overview and rating of the different vulnerabilities of the manual benchmark. Table 6: An overview of the threat modelling experience of the expert panel. Table 7: On overview of the experts’ experience with the provided tools. Table 8: An overview of the automatically generated list of threats produced by the Microsoft Threat Modelling Tool 2016. Table 9: An overview of the automatically generated list of threats for expert 1, 2 and 3 (Microsoft Threat Modelling tool 2016). Table 10: An overview of the list of threats for which expert 1 agrees that they pose a threat to the system (Microsoft Threat Modelling Tool 2016). Table 11: An overview of the vulnerabilities provided by expert 1. Table 12: An overview of the list of threats for which expert 2 agrees that they pose a threat to the system (Microsoft Threat Modelling Tool 2016). Table 13: An overview of the vulnerabilities provided by expert 2. Table 14: An overview of the list of threats for which expert 3 agrees that they pose a threat to the system (Microsoft Threat Modelling Tool 2016). Table 15: An overview of the vulnerabilities provided by expert 3. Table 16: An overview of the automatically generated list of threats for expert 4 (Microsoft Threat Modelling Tool 2016). Table 17: An overview of the vulnerabilities provided by expert 4. Table 18: An overview of the time needed to perform the treat analysis with the Microsoft Threat Modelling Tool 2016. Table 19: User experience and ease of use of the Microsoft Threat Modelling tool 2016. Table 20: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool.

viii

Table 21: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 1 Table 22: An overview of the listed vulnerabilities by expert 1 and the corresponding automatically generated threats from the Tutamen threat modelling tool. Table 23: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 2 Table 24: An overview of the listed vulnerabilities by expert 2 and the corresponding automatically generated threats from the Tutamen threat modelling tool. Table 25: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 3 Table 26: An overview of the listed vulnerabilities by expert 3 and the corresponding automatically generated threats from the Tutamen threat modelling tool. Table 27: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 4 Table 28: An overview of the listed vulnerabilities by expert 4 and the corresponding automatically generated threats from the Tutamen threat modelling tool. Table 29: An overview of the time needed to perform the treat analysis with the Tutamen threat modelling tool. Table 30: User experience and ease of use of theTutamen threat modelling tool. Table 31: An overview of the time it took to finish the threat analysis per expert and per tool. Table 32: An overview of the user friendliness per tool.

1

1. Introduction Over the last decade security trends have been changing, the number of reported incidents has increased

rapidly, and attacks are becoming more and more sophisticated (Stallings, 2006). 2017 faced some very

high-profile data and security breaches. In the USA 145 million Americans had their sensitive personal

information (driving license details, tax IDs, social security number, address, etc) stolen, when hackers

where able to exploit a vulnerability in a web application on the website of Equifax (CNN, 2018). With the

data that was leaked the attackers will be able to open bank accounts and take out loans on the victim’s

name, without them even knowing (CNN, 2018). Another high-profile security breach was the worldwide

WannaCry ransomware attack. The WannaCry malware targeted legacy Windows machines and used a

security exploit, which is rumoured to have been found and used by the National Security Agency (NSA),

to infect every nearby vulnerable machine it could find. This led to the infection of more than 300 000

devices in over 150 countries (CNN, 2017). The total cost of the ransomware attack has been estimated to

range from hundreds of millions of dollars up to $4 billion (CBS News, 2017). Figure 1 illustrates a graphical

representation of the number of records leaked in 2016 and 2017. The size of the different circles represents

the amount of records which were stolen, and the colour represents the way the data was leaked.

Figure 1: A graphical representation of the amount of records being stolen in data breaches in 2016 and 2017. Red

represents companies being hacked, green indicates accidental publishing and kaki represents overall poor security,

other colours represent inside jobs and stolen devices or media. Source: Information is beautiful, 2018.

What can be immediately noticed in Figure 1 is that the number of red circles have increased in 2017 and

that they appear to be bigger than the previous year. This seems to be confirmed by a recent survey

conducted by PwC (2018) where 29% of surveyed businesses reported to have suffered loses or damages

caused by a cyberattack which destroyed or manipulated data in the last year. The same survey also found

that businesses have security concerns about the rising number of digital devices, such as the Internet of

Things (IOT). To counter the possible security threat of IOT devices 66% of the companies that were

2

surveyed already have a security policy in place for IOT devices or are currently implementing one (PwC,

2018). This rise in cyber-attacks is one of the main reasons why Gartner (2017) reports that annual global

spending on information security has increased with 7% in 2017 to reach a total of $86,4 billion and is

estimated to grow up to $93 billion in 2018.

Another big concern to companies and consumers at the moment is privacy. As seen in Figure 1 there are

a lot of massive data breaches happening on an almost continuous basis, explaining why a 2018 PwC

survey found that only 25% of consumers thought that companies handle their sensitive information

responsibly. Companies want to regain the trust of the consumers and prove to them that they can handle

their data in a responsible way, by investing in advanced authentication technology (Pwc, 2018). According

to a PwC (2018) survey this appears to be working, half of the respondents said that advanced

authentication technology has enhanced customer confidence in the business’ competence to handle their

data responsibly. Advanced authentication technology has helped reduce fraud, improve customer

experience and 46% of surveyed companies are planning to increase investments in it (Pwc, 2018).

However, the use of some advanced authentication techniques, such as biometric technologies, has raised

privacy concerns by consumers and governments. Some information about you can always be changed,

but biometric data such as your face or fingerprint will stay with you for life. Therefore, a breach of biometric

data could potentially follow you the rest of your life (IT Governance EU, 2018). The second, and maybe

most important reason, why privacy is so important to companies is the General Data Protection Regulation

(GDPR). This European Union (EU) regulation seeks to implement one single privacy law for the whole EU,

which impacts all companies that operate within the EU, and protects all its citizen’s data privacy (EUGDPR,

2018). This regulation is expected to change the way that organisations approach data privacy and hence

caused worries among a lot of companies (EUGDPR, 2018; Gartner, 2017). The law doesn’t only change

the way that companies can collect and process data from EU citizens, it also requires companies to report

any data breaches that have occurred within 72 hours, at risk of a fine (GDPR EU, 2018). It remains to be

seen if the GDPR will prove to be effective and if this will prevent, or at least keep companies accountable

for data breaches that might occur.

Since the number of attacks on companies are on the rise and GDPR puts an emphasis on data security,

threat modelling will likely have a significant role in the Security Development Lifecycle (SDL). It helps

security analysts understand the system’s vulnerabilities, guides secure design and provides a framework

for penetration testing and code reviews (Swiderski & Snyder, 2004). It provides a structured way for

companies to assess security risks and prepare for the GDPR (Möckel & Abdallah, 2010). Seeing how the

fines for not complying with GDPR range from €20 million up to 4% of annual global turnover of the

company, companies have a strong incentive to comply with the regulations (ITGovernance UK, 2018).

3

2. Literature 2.1 What is threat modelling

To develop secure software, it is important to keep security in mind during the design phase. Failing to do

so might result in additional expenses, as the cost of retrofitting security in after the release of software is

estimated to be up to 30 times higher than it would have costed to correct security mistakes during the early

design phase (Microsoft, 2009). Therefore, it is recommended to detect any possible security threats as

early as possible. This is where threat modelling comes in, it helps security analysts evaluate the system

or software architecture and spot security threats early on. Because of this, it has been recognised as one

of the most important steps to create secure software (McGraw, 2006; Scandariato, Wuyts & Joosen, 2013).

Hence, it is important to integrating threat modelling as early as possible in the Software Development

Lifecycle (SDLC) (Crook et al., 2002; Massacci, Mylopoulos & Zannone, 2005; Hussain et al., 2014).

Threat modelling is, as defined by Oladimeji, Supakkul & Chung (2006): “a formal process of identifying,

documenting and mitigating security threats to a software system” (p.1). A security threat is the possibility

of harm being done to a system or application because there is a vulnerability present in the design. When

an attacker finds this vulnerability and exploits it, it leads to an attack (Hussain et al., 2014). Therefore, it is

important to implement security measures to patch the vulnerabilities and stop attackers from causing harm

to the system. It is important to not implement security measures at random, just because a system has

“256-bit keys“ or an “intrusion detection system“ does not mean it is automatically secure. It all depends on

the context of the system’s functionalities and design. The system security designer must consider the

entire system when examining which security features to implement (Myagmar, Lee & Yurcik, 2005).

Schneier (2000) describes security as: “[Security is ] a chain; it’s only as secure as the weakest link. Security

is a process not a product“ (p.257). This definition of security indicates that creating secure systems is not

a one-time task but a continuous process of improvement. Since security is a process and not a product, it

benefits greatly from a systematic approach. Threat modelling provides this structured approach for the

system security designer to carefully choose the security measures that the system really needs (Myagmar,

Lee & Yurcik, 2005).

Figure 2: The system security engineering process. Reproduced from: Myagmar, Lee & Yurcik, 2005

4

Figure 2 shows how threat modelling plays a leading role in the security engineering process. Threat

modelling helps security designers to understand the complexity of the system and to identify all threats,

whether they can be exploited or not. These identified threats are then evaluated based on the likelihood

of the attack happening and the potential damage such an attack might cause. Then a decision is made on

how to mitigate the threat by implementing security measures or by accepting the risk involved (Myagmar,

Lee & Yurcik, 2005; Crook et al., 2002). Threat modelling provides the foundation for the security

requirements and thus the security of the entire system. It helps to focus the security team’s efforts to

develop meaningful and useful security measures by providing the foundation upon which the system’s

security is build (Myagmar, Lee & Yurcik, 2005). Diverse types of systems can benefit from threat modelling,

from simple to complex systems, already deployed systems or even systems which only exist on paper so

far. No matter what stage of the development process the system is in, it can benefit from threat modelling

(Crook et al., 2002).

The threat modelling process varies depending on the organisation, the tools which are available, the threat

modelling methodologies and approach which are used, etc. However, there are three steps which all threat

modelling processes have in common, though the execution and name of each step might differ: (1)

characterisation of the system, (2) identification of assets, and (3) identification of threats (Swiderski &

Snyder, 2004; Myagmar, Lee & Yurcik, 2005).

The first step of every threat modelling process is to get familiar with the system and its components. The

security designer must know the system’s components, how they work together, their dependencies, the

flow of information, the use cases, etc. (Shostack, 2014; Myagmar, Lee & Yurcik, 2005). It depends on the

type of system how the different components and their dependencies can be modelled. The most common

notation is a Data Flow Diagram (DFD), this diagram shows the flow of information through a system or

application and all its components (Torr, 2005; Möckel & Abdallah, 2010). The DFD diagram makes it easier

to analyse possible threats, since the data flow through the different components and their interactions can

be followed (Shostack, 2014; Swiderski & Snyder, 2004). The interaction of elements with different rights

or privileges are indicated with dotted lines, known as trust boundaries. These trust boundaries should warn

the security analyst to pay attention since threats tend to cluster around the trust boundaries on a DFD

(Shostack, 2014). For example, if the DFD for a simple web shop is created it would look like Figure 3. The

red dotted line between the Web and Web server elements represents a trust boundary. This trust boundary

is placed here because the user must make a connection through the internet to access the web shop.

Since this connection is coming from outside of the system the integrity and quality of the data cannot be

verified. An attacker might have changed incoming data or have send some malicious data to the system.

This dotted red line represents that disparity in the levels of trust of the data, the data from the internal

system that we can monitor and trust and the data for which we have no control and therefore must be wary

of. These trust boundaries do not only show up in DFDs when a connection with an outside network is

made (i.e., the internet) but also when there are interacting components with different privileges or can be

used to indicate different security zones (OWASP, 2017; Shostack, 2014).

5

Figure 3: A simplified DFD example for a web shop.

A DFD is a very powerful tool to decompose the architecture of a system or application but can only be

made when all the different software components are known. This is not always the case for complex or

large-scale networked systems (Myagmar, Lee & Yurcik, 2005). A possible solution to this problem is by

using network models instead of DFDs, this network model shows the different computers on a network

and their role (Figure 4). This allows for analysts to investigate the communication between different

computers in a network and start the threat modelling process based on this network model (Kamvar,

Schlosser & Garcia-Molina, 2003; Myagmar, Lee & Yurcik, 2005).

Figure 4: An example of a network diagram (for a Netflows system). Source: Myagmar, Lee & Yurcik, 2005

The next step in the threat modelling process is to identify the assets: what will an attacker likely attack or

try to compromise, what must be defended, etc. The definition that is given to an asset in this stage depends

on the threat modelling approach that is being utilized, it can be defined from an attacker’s point of view or

as a system’s resource (Shostack, 2014). In other words, according to Myagmar, Lee & Yurcik,

‘’An asset is an abstract or concrete resource that a system must protect from misuse by an

adversary. Assets can be tangible, such as processes and data, or more abstract concepts such

as data consistency. It is impossible to have a threat without a corresponding asset because assets

are essentially threat targets.’’ (2005, p.3)

6

This broad definition shows that an asset can be many things, both tangible and abstract, and that they

pose potential targets for any malicious attackers. Furthermore, it shows that threats and assets are

correlated, without any assets it is impossible to have any threats.

The last step in the threat modelling process is to identify all the possible threats to the system. The

identification of these threats is based on the information that was gathered in the previous two steps. A

threat can be defined as the goal of the attacker or as what can be gained by the attacker by attacking the

system (Swiderski & Snyder, 2004). To find all possible threats and vulnerabilities one must enumerate

through all the assets, which were defined in the previous step, and review a list of possible attack threats

for each asset. The result of this is a threat profile of the system, this describes all potential vulnerabilities

and attacks. For each element in the threat profile a decision must be made to mitigate the threat by

implementing some sort of protection to the system or assets or to accept the risk posed by the threat

(Myagmar, Lee & Yurcik, 2005; Swiderski & Snyder, 2004). These choices that are made by the security

designer to accept or mitigate the risk will afterwards be translated into security requirements and finally

manifest themselves as security measures (Myagmar, Lee & Yurcik, 2005).

The execution of the threat modelling process depends on the methodology and threat modelling approach

that is utilized, this can add extra steps to the process which is described above. Many different threat

modelling approaches and methodologies have been developed to fit the needs of security designers

better. The following paragraphs give an overview of the different common and uncommon threat modelling

approaches and methodologies.

2.2 DIFFERENT THREAT MODELLING APPROACHES Threat modelling is commonly implemented using one of three independent approaches: attack centric,

asset centric or software centric (Shostack, 2014). The decision of which focus to use depends on the tools

and methods used, the limitations of the selected focus and its advantages (Möckel & Abdallah, 2010).

2.2.1 Attack centric threat modelling Attack centric threat modelling focuses on the system’s security from the attackers’ point of view and on

the identifications of the system’s access points (Mirembe & Muyeba, 2008). Most attack centric threat

models identify vulnerabilities by summarising threats as attack lists or visualising them as attack trees

(Shostack, 2014; Schneier, 2000). Attack trees provide a structured approach for describing the security of

a system. The attack that could be used against the system is represented in a tree structure, where the

root node represents the goal of the attack and the leaf nodes are the diverse ways the attack can be

achieved (Schneier, 1999). An example of an attack tree can be seen in Figure 5, illustrating the possible

attack paths to open a safe. Though this is an attack tree that is not Information Technology (IT) related, it

provides a good overview of how an attack tree works. The root node shows what the purpose of the attack

is, in this case opening a safe. The first row of child nodes provides all viable ways on how the attacker can

open the safe. The next row of child nodes (3th row) represent sub-goals and their children represent ways

on how to achieve that sub-goal (Schneier, 1999). In Figure 5 this means that the purpose of the attack is

to open the safe. A viable way to open a safe from the attacker’s point of view is to learn the combination,

7

which is a child node of the purpose (or root/top node). The third row of nodes show how an attacker might

learn the combination of the safe, for example by eavesdropping. The children of the eavesdropping node

show two possibilities to overhear the safe’s combination: listen to the victim’s conversations or get him/her

to state the combination of the safe. Since getting someone to state the combination of the safe is unfeasible

the only remaining option to eavesdrop the combination is to spy on them and listen to all their

conversations. In case this is not feasible to do the attacker can go back up the tree and look for other

attack options which might have a bigger chance of success. By traversing the tree and all the viable options

and adding values to the tree (in Figure 5 this is possible or impossible) the attacker can find a way to fulfil

his/her purpose. If one would add numeric values on the tree, instead of possible or impossible as in Figure

5, calculations can be made to show how secure a system is (Schneider, 1999).

Figure 5: An attack tree example for opening a physical safe. The value between brackets indicates whether the

attack option is possible (P) or impossible (I). Reproduced from: Schneier, 1999

Why use attack centric threat modelling Attack centric threat modelling in combination with the use of attack trees or attack lists are very popular

among security experts, because they are simple to interpret and understand, provide a way to reuse

expertise, and provide a structured approach (Mirembe & Muyeba, 2008; Shostack, 2014). There are

however some problems with this approach—because the security experts are following a threat list or an

attack tree— it does not allow them to think about the threats that they represent. They might become too

fixated with the attack tree and not critically think about any other attack options the attacker might have

(Mirembe & Muyeba, 2008). Shostack (2014) notes that this attack centric threat modelling approach does

not lead to reproducible results and does not provide enough structure to figure out what an attacker might

do. According to Shostack’s (2014) opinion, using the attacker as the centre of the threat modelling is not

recommended, as the attacker has his own motivation and skills, thus making it difficult to predict what

approach he might use to compromise the system.

8

2.2.2 Asset centric threat modelling Asset centric threat modelling focuses on protecting the internal infrastructure of a system or application

and managing business risk (Potteiger, Martins & Koutsoukos, 2016; Möckel & Abdallah, 2010). The asset

centric approach is typically used when an asset of IT or business applications must be protected—such

as data, personal information, etc (Potteiger, Martins & Koutsoukos, 2016). When using an asset centric

threat modelling approach, the business objectives and deployment patterns of the system or application

will most likely be known. This means that the access and asset controls will be understood, thus making

it an ideal approach for clearly distinguished business applications with a specific goal (Möckel & Abdallah,

2010). However, Shostack (2014) raises some concerns about the usefulness of an asset centric threat

modelling approach, saying that only a small number of people will benefit from it. According to Shostack

(2014) there are three interpretations of the definition of an asset: (1) things attackers want, (2) things you

want to protect, and (3) stepping stones to either of those. If all the people involved in the threat modelling

process do not have a consensus on the definition of an asset the entire process will stall and become very

complicated (Shostack, 2014).

Over the past years several lists of security measures and tools have been made available to offer guidance

to help protect a company’s assets. The Open Web Application Security Project (OWASP)—a worldwide

non-profit organisation which focuses on software security—has conducted research on IOT devices to

construct a list of the top 10 IOT attack surfaces and mitigations (OWASP, 2018). This list can be utilized

to protect IOT devices against the most common attacks and provides important technical and business

impact information. The National Institute of Standards and Technology (NIST) has also developed a

cybersecurity framework which allows businesses to personalize security measures and break them up into

distinct categories associated with various kinds of threats, provides protection, intrusion detection,

countering infiltration and recovering after an attack (NIST, 2018).

2.2.3 Software centric threat modelling The software centric approach to threat modelling is more suitable for systems with an unknown deployment

pattern and is designed to safeguard the security of the software’s code (Potteiger, Martins & Koutsoukos,

2016). Software centric threat modelling focuses on the software that is being build or designed and looks

for the various attacks that can occur on the different elements of the application (Shostack, 2014; Palanivel

& Selvadurai, 2014). The most crucial step in software centric threat modelling is understanding the

software model that is being used, whether it is simple or complex, and making sure that everyone that is

involved in the project has a good understanding of it (Shostack, 2014). This mutual understanding of the

software model can provide considerable value and will lead to an overall improvement of the component’s

security (Palanivel & Selvadurai, 2014; Shostack, 2014). One of the main advantages of this software

centric approach is that it makes software developers participate in the threat modelling process and that

the resulting threat and software model can be used by the entire team. This will also lead to the software

developers gaining a better understanding of the business and its assets (Shostack, 2014).

9

2.3 Commonly used methodologies 2.3.1 STRIDE STRIDE is a popular threat modelling technique created by Microsoft that is commonly used in the

security industry and Microsoft consistently uses it on all their products (Hernan et al., 2006; Torr, 2005;

Ingalsbe et al., 2008). STRIDE is backed by some of the most recognised secure software processes, like

OWASP’s Comprehensive, Lightweight, Application, Security Program (CLASP) (Chandra et al., 2007)

and Microsoft’s SDL (Howard & Lipner, 2006). STRIDE is an acronym for the various categories of

threats that might affect the components of a system or application (Torr, 2005) and stands for:

• Spoofing: attackers pretend to be someone (or something) else.

• Tampering: attackers change data in transit or at rest.

• Repudiation: attackers perform actions that can’t be traced back to them.

• Information disclosure: attackers steal data in transit or at rest.

• Denial of service: attackers interrupt a system’s legitimate operation.

• Elevation of privilege: attackers perform actions they aren’t authorized to perform. (p. 69)

STRIDE: How does it work? When applying the STRIDE methodology to a threat analysis, the security analyst must go through

several steps (Scandariato, Wuyts & Joosen, 2013), as listed below.

Step 1: Make the Dataflow Diagram At the heart of a STRIDE threat model lays the DFD. This graphical representation helps the security analyst

view the system from the attacker’s perspective and analyse the levels of trust available in the system or

application (Swiderski & Snyder, 2004). The various levels of trust are modelled in the DFD as a trust

boundary, where a trusted and an untrusted element exchange data (Hernan et al., 2006; Al-Fedaghi &

Alrashed, 2010). The different components that are modelled in the DFD provide the scope for the threat

analysis (Scandariato, Wuyts & Joosen, 2013). The DFD can be modelled on various levels of detail, also

known as granularity. The highest level DFD, known as the level 1 DFD, shows how information flows

through the system or application from external entities to processing nodes and data storages

(Scandariato, Wuyts & Joosen, 2013). Dhillon (2011) states that the level 1 DFD should be ample, unless

dealing with very complex systems. Figure 6 shows and example of a level 1 DFD for a digital publishing

system.

10

Figure 6: A level 1 DFD example for a digital publishing system. Source: Scandariato, Wuyts & Joosen, 2013

Step 2: Map the elements of the dataflow diagram to the threat categories After the dataflow diagram is made, each component must be analysed according to the 6 STRIDE threat

categories (Scandariato, Wuyts & Joosen, 2013). The different threat categories can be found in the

STRIDE acronym described in the previous section. This way of utilizing STRIDE is described by Shostack

(2014) as “STRIDE-per-Element”. This approach can make it easier for the security analyst to find threats

by focusing on the set of threats against each element (Shostack, 2014). This technique can help skilled

security analysts to find new types of weaknesses in components, and less skilled analysts to still find

common problems (Shostack, 2014). This “STRIDE-per-Element” approach does have the downside that

a great deal of problems will show up repeatedly in your threat model. Another way of analysing the threats

is by analysing all the different interactions between the components, also known as “STRIDE-per-

Interaction”. This method yields equivalent results with less analysis points (Shostack, 2014; Dhillon, 2011).

Step 3: Analyse the threats For each threat category that has been mapped to a DFD element STRIDE provides a checklist of threats

that have to be examined (Scandariato, Wuyts & Joosen, 2013). These threat checklists come in the form

of an attack tree and the reference book for STRIDE provides a total of twelve attack trees (Figure 7)

(Scandariato, Wuyts & Joosen, 2013; Howard & Lipner, 2006). The next step is to analyse the risk that the

identified threat poses to the application or system (Scandariato, Wuyts & Joosen, 2013). For example, the

DREAD (Damage potential, Reproducibility, Exploitability, Affected Users, and Discoverability)

methodology can be used to prioritize the different threats. For each threat that is identified in the previous

steps a value for each DREAD category is given. All values for that threat are then added together to get

an indication of the impact of the threat (Oladimeji, Supakkul & Chung, 2006). DREAD was a part of the

STRIDE methodology until 2010, but it is no longer advised to use it, as it is subjective in the ranking of

threats and it can lead to unpredictable and varying results (Shostack, 2014). Microsoft now recommends

11

the use of the Security Update Severity Rating system instead of DREAD. This new system classifies

threats in one of 4 categories based on the likelihood of a threat being exploited: low, moderate, important

and critical (Microsoft Technet, 2017).

Figure 7: An attack tree example showing how tampering with the data flow may occur. (DF = data flow, EE =

external entity, PN = internal service). Source: Scandariato, Wuyts & Joosen, 2013

Step 4: Document the threats In the last step of the STRIDE analysis, all the threats that are discovered must be documented. There is

no mandatory or specific format for this step (Scandariato, Wuyts & Joosen, 2013). In the security sector

misuse case are often used to document threats. This is behaviour that is not wanted, from a security

perspective, in a system (Sindre & Opdahl, 2005).

2.3.2 LINDUNN: a STRIDE analysis for privacy Privacy is regularly overlooked in the software engineering process and is often only a concern at the end

of the SDLC, which makes it more challenging and costly to correct (Wuyts, Scandariato & Joosen, 2014).

However, in recent years there has been the emergence of a new attitude toward privacy, which Cavoukian

et al. (2010) call ‘privacy-by-design’. This ‘privacy-by-design’ approach promotes privacy-focused activities

in the initial stages of the SDL. Threat modelling helps eliminate potential threats to the system, but a

methodology like STRIDE is not made to eliminate possible privacy threats. Therefore, a privacy focused

threat modelling technique was created—LINDUNN (Deng et al., 2011; Wuyts, Scandariato & Joosen,

2014). LINDUNN is a threat modelling technique which is complementary to STRIDE, both techniques are

model driven, base their analysis on the DFD diagram of the application or system and follow the same

steps for completing their analysis (Wuyts, Scandariato & Joosen, 2014). Like STRIDE, LINDUNN is an

acronym where each letter in the name refers to a potential privacy threat to the components of the system

or application. Wuyts, Scandariato & Joosen (2014) define the LINDUNN acronym as:

• Linkability (L): occurs when one can sufficiently distinguish whether two items of interest (IOI,

like requests from a user) are related.

• Identifiability (I): occurs when itis possible to pinpoint the identity of a subject (e.g., a user).

• Non-repudiation (Nr): occurs when itis possible to gather evidence so that a party cannot deny

having performed an action.

12

• Detectability (D): occurs when one can sufficiently distinguish whether an IOI exists, e.g., in a

system.

• Disclosure of information (Di): is the exposure of information to individuals who are not

supposed to have access to it.

• Unawareness (U): occurs when the user is unaware of the information he is supplying to the

system and the consequences of his/her act of sharing.

• Non-compliance (Nc): occurs when the system is not compliant with the (data protection)

legislation, its advertised policies and the existing user consents. (p.123)

Wuyts, Scandariato & Joosen (2014) have found in their research that though the LINDUNN methodology

does need some improvements in certain areas, but it was perceived as easy to use and useful by privacy

experts. This methodology could prove very useful for privacy experts, since the GDPR will come into force

on the 25th of May 2018 (GDPR EU, 2018). This European law regulates the data collection and storage of

Personally Identifiable Information (PII) of European citizens (GDPR EU, 2018). It also governs the way

companies must deal with any data breaches that might occur (IT Governance UK, 2018). Seeing how

GDPR puts an emphasis on privacy and data security, threat modelling could have a significant role in

preparing companies for this upcoming regulation. Since the fines for non-compliance to the GDPR are set

up to €20 million, or 4% annual global turnover (whichever is higher) the companies have an incentive to

comply with the new regulation (IT Governance UK, 2018).

2.4 Less commonly used methodologies 2.4.1 Trike Trike is an open source framework for threat modelling that focuses on a risk-based approach that is similar

to Microsoft’s STRIDE (Potteiger, Martins & Koutsoukos, 2016). Trike models focus on the impact on

system’s stakeholders, while STRIDE focuses more on the representation of threats and attacks. Trike’s

goal is that the security risk to the system’s assets are acceptable for all stakeholders (OWASP, 2017). The

Trike tool, which is also provided with the Trike document clarifying the methodology, integrates an attack

centric and software centric approach (Potteiger, Martins & Koutsoukos, 2016). However, the Trike tools

have not been updated since 2012 and the Trike document was only released as a draft version. Therefore,

it is hard to estimate how widely this methodology and tool are still being used (Saitta, Larcom & Eddington,

2005).

2.4.2 VAST The VAST (Visual, Agile, and Simple Threat modelling) methodology focuses on the scalability of the threat

modelling process and the integration into an Agile software development environment (Agarwal et al.,

2016). It seeks to provide outputs for all the various stakeholders: from developers and system architects,

to security analysts and business executives. The methodology provides a unique and straightforward way

for the visualisation of system/application architectures, and does not require extensive security expertise,

13

thus making it accessible to a wider audience (Agarwal et al., 2016). To the best of our knowledge—at the

time of writing—no official methodology document has been released by the creators.

2.4.3 PASTA Process for Attack Simulation and Threat Analysis (PASTA) is a risk centric threat modelling methodology

(OWASP, 2017; Ucedavelez & Morana, 2015). The PASTA methodology integrates system or application

threat analysis with business objectives, business analysis, and compliance (Ucedavelez & Morana, 2015).

It implements a seven-step process which starts with the definition of the business objectives, continues

with the decomposition of the application/system and threat analysis, and finishes with an analysis of the

possible impact on the business (Ucedavelez & Morana, 2015). This focus on the shareholders and

business impact of security threats is what makes PASTA stand out from other threat modelling

methodologies.

2.5 Threat modelling tools and scientific contribution The choice of threat modelling tools is just as important as the choice of threat modelling methodology

(Schlegel, Obermeier & Schneider, 2015). Threat modelling can be done without the use of any tools, but

most users will benefit from a more structured and guided approach (Möckel & Abdallah, 2010). There is a

wide variety of different tools available, which all differ in functionalities, sophistication, and specialisation

(Schlegel, Obermeier & Schneider, 2015; Nguyen et al., 2009). The wide range of available tools can range

from unstructured text documents or mind mapping software specialised for threat analysis to specialised

tools that automate the whole threat modelling process (Schlegel, Obermeier & Schneider, 2015). The

spectrum of available threat modelling tools knows two extremes: (1) general tools which do not need a

certain data model to create the threat analysis and (2) specific tools which require the data to conform to

a certain pre-set structure (Schlegel, Obermeier & Schneider, 2015). General tools have the advantage of

being flexible, since there is very little constraint on how the data needs to be structured. However, the

disadvantage of general tools is that it is difficult to re-use the threat model data for comparable threat

models. Specialised tools on the other hand can automate the threat modelling process since the data has

to fit a certain format. However, this restriction on the input data makes the applications of these tools

restricted (Schlegel, Obermeier & Schneider, 2015). Today there are multiple threat modelling tools publicly

available, that claim to produce more reliable and consistent results by automatically generating lists of

possible threats (Threat Modeler, 2018; Security Compass, 2018). However, to this day few empirical

studies has been performed to quantify the effectiveness of such automated threat modelling tools.

Möckel & Abdallah (2010) studied the efficiency of two Microsoft threat modelling tools for securing an e-

banking application: The Threat Analysis & Modelling Tool (TAM) and the Security Development Lifecycle

Threat Modelling tool. They concluded that the advantage of having a software assisted threat modelling

process becomes apparent when the tool generates an extensive list of possible threats, even unlikely and

minor. This forces the user to critically think about all the possible threats which are presented, even if they

are improbable. This very useful feature of the tools also has a downside, it means that the user still needs

14

to provide sensible input and interpret the results correctly with their expertise. Möckel & Abdallah (2010)

also concluded that the advantages of a software guided threat modelling process will only be meaningful

in case the output of the process will be used to improve system security. So even though the threat

modelling tools can provide guidance and help to the user, it is still up to individuals with ample knowledge

and expertise to translate the outcome of the process into an actionable plan. The two Microsoft threat

modelling tools that Möckel & Abdallah (2010) studied have since been merged together into one tool: the

Microsoft Threat Modelling Tool. A study on the effectiveness of the Microsoft Threat Modelling Tool has

been conducted by Williams & Yuan (2015). They measured the effectiveness of the Microsoft Threat

Modelling tool by comparing the results of a manual threat modelling exercise (with no specialized threat

modelling tools) to the results of the same exercise performed made with the Microsoft Threat Modelling

tool. In the study, which was conducted on twenty undergraduate computer science students, they found

that by using the Microsoft Threat Modelling Tool overall results were better and more threats have been

correctly identified. Williams & Yuan (2015) do note that the results varied from student to student and were

dependent on the completeness of the DFD produced by the student. Variations in the DFDs and their

elements caused variations in the threats that were listed. This variation could be explained by a student’s

lack of threat modelling experience or knowledge. Finally, Williams & Yuan (2015) concluded that the

Microsoft Threat Modelling Tool did assist the threat modelling results of the students. Other research

involving threat modelling tools has mainly focused on the development and validation of a new threat

modelling tool or framework (Schlegel, Obermeier & Schneider, 2015; Schaad & Borozdin, 2012; Nguyen

et al., 2009). Most studies focus on the tools that researchers developed and few studies focus on

measuring the effectiveness of the publicly available threat modelling tools. The aim of this research is to

try to fill this gap, by testing the effectiveness of publicly available threat modelling tools. The effectiveness

of the tools will be tested by using real-life security professionals, this will hopefully provide some guidance

for threat modelling experts to choose the right threat modelling tools and provide a stepping stone for

further research into the effectiveness of threat modelling tools.

15

3. Research questions

3.1 Research question

Do automatic threat modelling tools provide extra value to the security process?

3.2 Sub questions

RQ1: Are the tools accurate?

RQ2: Is time being saved by using threat modelling tools?

RQ3: Are the tools user friendly?

4. METHODLOGY

4.1 Research design

Taking into consideration that no standardized way of comparing the effectiveness of threat modelling tools

exists, this research is based on two similar studies performed by Williams & Yuan (2015) and Wuyts et. al

(2014). In the research of Williams & Yuan (2015) the effectiveness of the Microsoft Threat Modelling tool

was measured by comparing the results of a manual threat modelling exercise (with no specialized threat

modelling tools used) to the results of the same exercise performed with the Microsoft Threat Modelling

tool by twenty undergraduate computer science students. In this research the results of the tools will also

be compared to the results of a manual exercise. However, in contrast to the research done by Williams &

Yuan (2015) the participants of this research do not make this manual exercise themselves. An independent

expert will solve the research case manually and the results of the other experts, with the use of tools, will

be compared to this manual result to determine the effectiveness of the tools. The second influence on the

research methodology is a study performed by Wuyts et. al (2014). In their research Wuyts et. al (2014)

measured the reliability of the LINDUNN methodology by comparing a threat analysis performed by privacy

experts to an optimal execution of the LINDUNN methodology. In their case study Wuyts et. al (2014) asks

three privacy experts to perform an independent analysis (without the LINDUNN methodology) of a system

for which they received a detailed description. These results are then compared to an optimal execution of

the LINDUNN methodology and reviewed by a senior privacy expert. Though their case study is designed

to measure the effectiveness of a threat modelling methodology and does not focus on the tools, it serves

as a blueprint for the design of the present research. Although similar, the research questions of the two

studies focus on a different aspect of the threat modelling process.

For the layout of this research the choice was made to combine different aspect of the two aforementioned

studies, however three modifications were made. Firstly, it was decided to work with information security

16

experts to minimize the mistakes made by a lack of threat modelling knowledge and/or experience. This

means that the sample size will be limited, and the conclusions cannot be generalised. Therefore, the

decision was made to perform a descriptive case study. A descriptive case study is used to characterize a

phenomenon or technique and attempt to understand it. Contrary to an experiment, no attempt is made to

analyse the effect of variables on the phenomenon (Scandariato, Wuyts & Joosen, 2013). A descriptive

study is useful to understand a phenomenon and formulate research hypotheses for further research

(Wuyts et. Al, 2014; Scandariato, Wuyts & Joosen, 2013). A descriptive study is, in the words of Last (1986):

“concerned with and designed only to describe the existing distribution of variables, without regard to causal

or other hypotheses” (p.50) or in other words: ‘‘the first scientific toe in the water in new areas of inquiry’’

(p. 145, Grimes et al., 2002). A descriptive case study for this research is preferable since no similar

research has been performed on publicly available threat modelling tools by using an expert panel.

Secondly, in contrary to the research done by Williams & Yuan (2015) where the participants are asked to

first perform a manual threat modelling exercise. Only one manual threat modelling exercise is made by a

senior security expert, the time necessary to complete the exercise is used as a baseline for all other

experts who use the threat modelling tools. More details on this process are explained in the following case

study section. Lastly, this research will test two different threat modelling tools: Microsoft Threat Modelling

Tool 2016 1 and Tutamen Threat modelling tool 2. All participating experts will solve a threat modelling

exercise with both tools.

This research consists of four phases: (1) the creation and validation of the threat modelling case, (2) the

creation of an expert panel, (3) the selection and utilization of the threat modelling tools, and (4) a survey

to measure the experts’ experience with the tool.

4.1.1 Threat modelling case design A detailed architectural description of a system was created by a senior security expert (Appendix A), this

system was designed to be deliberately insecure. It was decided to go with a 3-tier web application

architecture, the reason for this being that a 3-tier web application is a very common application

architecture, thus it can be assumed that each security expert on the panel has knowledge on the subject

and possible threats. This will minimize the chance that mistakes are made during the threat analysis

because of inexperience or lack of knowledge, though it cannot be completely avoided. Together with the

architectural description is the scope of the threat analysis, this indicates what kind of threats should be

included in the analysis and which should be ignored. For the threat modelling case experts should only

focus on technical security threats, meaning security threats which are related to architectural flaws of the

system and not to human error. This means that threats such as phishing, social engineering, insider threat,

etc. should not be included in the threat analysis. After the creation of this architectural description the

senior security expert provided a list of all the possible threats to the system and determined the

1 Microsoft Corporation, One Microsoft Way Redmond, Washington USA. Available at: https://www.microsoft.com/en-us/download/details.aspx?id=49168 2 Tutamentic Pvt. Ltd., Deansgate 86, Manchester, United Kingdom. Available at: http://www.tutamantic.com/

17

vulnerabilities. However, threat modelling is not an exact science and the results of a threat analysis are

dependent on the expertise of the analyst (Mirembe & Muyeba, 2008; Möckel & Abdallah, 2010). Therefore,

it is important to independently validate the list of vulnerabilities provided by the creator of the architectural

description.

The validation was carried out by an independent senior security expert who teaches threat modelling

classes and has several years’ experience with threat modelling. This second security expert made sure

that the description of the architecture was clearly defined and unambiguous to avoid mistakes made by

misinterpretation of the description. Afterwards the senior security expert made a threat analysis for the

system and compared his list of vulnerabilities to the ones provided by the creator of the architectural

description. The lists of both senior security experts matched. Therefore, the list of vulnerabilities will be

used as the correct solution of the threat modelling case. In case of a mismatch between the two lists of

vulnerabilities, the two security experts would have been brought together for discussion about the results

until consensus is reached comparable to a Delphi study.

During the validation of the architectural description, the second senior security expert recorded the amount

of time it took him to perform the threat analysis. This amount of time will serve as the ‘’manual benchmark’’

time. The time it takes to perform the same threat analysis but with specialised tools will be compared to

this manual benchmark time to determine if the use specialised tools are more time efficient. The manual

benchmark was created by using three non-specialised tools which are widely available in most office

environments: (1) a whiteboard, (2) Microsoft Visio, and (3) Microsoft Excel. The expert first created the

DFD on the whiteboard, which was subsequently recreated in Microsoft Visio. Afterwards a threat analysis

for the system was performed on the whiteboard and in Microsoft Excel and lastly the expert gave

scores/weights to the different threats to indicate the severity of the threats and determined the system

vulnerabilities. This threat modelling workflow is similar to a real-life threat modelling project. First the

security team comes together and discusses the architecture of the system or application and the possible

threats. This first draft is traditionally done on a whiteboard since they are available in most meeting rooms

and make collaboration between the team’s members and correcting mistakes easier. Afterwards the DFD

and threat analysis on the whiteboard must be digitalised to document the threats and the work that has

been accomplished, this also makes it easier to maintain and change as the project moves along.

4.1.2 Expert panel creation After the creation and validation of the threat modelling case a panel of security experts needs to be created.

An invitation for volunteers was made on the OWASP threat modelling Slack, a collaboration hub where

security and threat modelling experts from all over the world come together to share knowledge on threat

modelling and security. Four senior security experts accepted the invitation and together they form the

expert panel that will be provided with the threat modelling tools to solve the case. All participating experts

are required to work in the information security sector and need a minimum of one year of hands-on working

experience with threat modelling.

18

4.1.3 Threat modelling tools Selection of the threat modelling tools The tools which are provided to the experts are chosen based on three different criteria. Firstly, the threat

modelling tools must provide an automatically generated list of threats. This list of threats will indicate how

much of the work can be automated by using these tools. Furthermore, it allows for the inspection of their

correctness and completeness and for the analysis of how much input is still needed from the security

analyst. Secondly, the tools must be able to use or draw a DFD. This requirement has been set because

in the research of Williams & Yuan (2015) a lot of variations in the results were caused by disparities in the

DFDs. Therefore, it is required for the panel of experts to provide the DFD used or generated by each tool

so that variations in the results can be checked for deviations in the DFDs. Lastly, the threat modelling tools

must be publicly available, either paid or for free. This requirement makes sure that the threat modelling

tools is made for widespread use and not only for specific use cases.

The panel of security experts will be provided with two tools to solve the threat modelling case. Each expert

on the panel will use both tools consecutively to perform a threat analysis on the architectural description

that is provided to them. It is expected that the second tool that the expert uses will be less time-consuming,

since the expert is already familiar with the architectural description and has already performed a threat

analysis for said system. To minimize this bias in the results, the panel of experts will be split in two groups

of similar experience and each group of experts will try the tools in a different order. This will hopefully

minimize the bias and make sure that a difference in completion time between the two groups can be

explained by other elements. All experts are provided with basic information about the tools such as

introductory documentation and ‘’getting started’’ videos for them to learn the basic features of the tools.

Microsoft Threat Modelling Tool 2016 The Microsoft Threat Modelling Tool 2016 was chosen to follow-up on the research of Williams & Yuan

(2015) and Möckel & Abdallah (2010) to see if Microsoft’s threat modelling tool is effective in the hands of

security experts. The Microsoft Threat Modelling Tool 2016 passes all the selection criteria: it automatically

generates a list of threats based on the user’s DFD, a user can create their own DFD based on components

which are available in the tool or add their custom components, and the tool can be downloaded for free

from Microsoft’s website. Since Microsoft build the threat modelling tool it follows their own STRIDE

methodology to automatically generate a list of threats for the system that the user is creating. The tool is

built to allow the user to fully perform the threat modelling process in one tool. The user can follow the four

steps of the STRIDE methodology to complete the threat analysis. First the user draws the DFD for the

system and gives different attributes to all the DFD elements. Afterwards the tool automatically performs a

STRIDE-per-interaction analysis based on the all the elements which are present on the DFD and their

attributes. After the completion of the automatic STRIDE analysis the user must go through the list of

potential threats and choose which of the threats are applicable (indicated with ‘needs investigation’) and

which are not applicable to the system. Finally, the tool provides the user with a list of threats and their

priority in the form of a report, this allows for the documentation of the different threats and can be used for

collaboration between teams or in project meetings. This report shows all automatically generated threats

19

and their applicable or not applicable status which was provided in the previous step. This report will be

used to check the automatically generated threats and the amount of threats that the security expert finds

applicable to the architectural description.

Figure 8: A DFD example and a generated list of threat in the Microsoft Threat Modelling Tool. Source: MSDN, 2017

Tutamen Threat Model Automator

The Tutamen Threat Modelling tool is a Software As A Service (SaaS) tool, which means that it is hosted

in the Cloud and does not require the users to install any kind of software on their own computer. The

Tutamen tool passes the three selection criteria but handles the use of DFDs differently than the Microsoft

Threat Modeller Tool 2016. In the Microsoft Threat Modeller Tool 2016, the user must create their own DFD

(in the tool) to get an automatically generated list of threats. In the Tutamen Threat Modeller Tool the user

can use their own choice of diagram software if the output format is accepted by the tool (Visio drawings or

any other xml-based formats). This means that the Tutamen Threat Modelling Tool integrates with the

existing workflow and tools that the security team is currently using. This feature sets the tool apart from

the other publicly available tools and is the reason it was chosen to be studied. Since the experts on the

panel can keep using their familiar tools and workflow it is interesting to study if this tool is able to make the

threat modelling process more efficient. The workflow of the Tutamen threat modelling tool starts with the

user creating a DFD in the diagram software of their choosing. They can make use of a threat modelling

template which is provided for them, in this template each element of the DFD has an attribute field which

can be filled by the user. This attribute field describes the security property of the DFD element and allows

the tool to automatically generate a list of threats. The experts must fill in the attribute field of the elements

by using a descriptor language based on the Security Frame (Appendix B). Once the DFD is finished the

user must go to the Tutamen website and upload their finished DFD. After a moment of processing the

website shows a report of the potential threats to the system which can then be validated by the security

expert. This automatic threat generation uses different security frameworks such as: the OWASP top 10

vulnerabilties list, Common Attack Patterns (CAPEC), Common Weakness Enumeration (CWE), etc. The

Tutamen tool does not support the full threat modelling process. It allows the user to automatically generate

potential threats, but the user must still use their own diagramming software to create the DFD. However,

it allows for the user to use the diagramming software that they are most familiar with and allows for the

integration of the Tutamen tool in an existing threat modelling process without the need to redesign said

process. Furthermore, it closely resembles the workflow of the manual benchmark. The experts will draw a

20

DFD in a diagramming software, like Microsoft Visio, and perform a threat analysis. The only difference is

that with the Tutamen tool the threat generation is done automatically, therefore it is expected to be faster

than the manual threat analysis. On their website the tool claims to: ’’[The automation] speeds up the initial

analysis by a factor of 50 over traditional manual threat model processes’’ (‘’Tutamen Features‘’, 2018).

The question remains whether this tool speeds up the threat modelling process as much as advertised and

whether its automatic generation of threats is complete and accurate.

4.1.4 Survey For the final stage of the study each expert must fill in a survey (Appendix C). In this survey the experts

are first asked about their threat modelling experience, their day to day use of threat modelling, and their

prior knowledge of the tools they used. Afterwards they are questioned about their experience with the

tools: are they easy to use and did they have all the necessary features to create the threat analysis.

Finally, the users are asked to upload all the automatically generated lists of threats, their discovered

vulnerabilities, and their threat analysis for both tools.

5. Results 5.1 Manual benchmark

A senior security expert was given an architectural description of an SSO system (Appendix A) and was

asked to perform a manual threat analysis by using three non-specialised tools commonly found in an office

space: a whiteboard, Microsoft Excel, and Microsoft Visio. The expert kept track of the time it took to

complete each task, Table 1 shows a breakdown of the different tasks in his threat modelling process and

how much time it took the expert to complete each task. The expert used the STRIDE methodology to

perform the threat analysis. However, it must be noted that any methodology could have been used to

enumerate all the possible threats to the system. The expert was instructed to use any threat modelling

methodology that he was comfortable with to ensure an efficient threat modelling process, this allows for

the creation of a favourable baseline result.

Task Time to complete (in minutes)

Create DFD on whiteboard 4,5

Transfer DFD to Visio 7

Perform STRIDE analysis on whiteboard 11

Perform STRIDE analysis in Excel 5

Enumerate threats on whiteboard 5.5

Transfer list of threats to Excel 2.5

Total 35,5 Table 1: Breakdown of the activities in the manual benchmark.

21

Figure 9 and 10 show the DFD that the expert created for the system. They show that the expert first drew

the entire system and then marked the system management components out of scope for the analysis

since they refer to threats which are out of scope for this analysis.

Figure 9: The manually made DFD for the threat modelling case.

Figure 10: The DFD of the threat modelling case made in Visio.

After creating the DFD of the system the senior security expert performed a STRIDE analysis for each

trust boundary that is present in the DFD. The expert analyses three elements of each trust boundary: the

element where the dataflow begins, the element where the dataflow ends, and the dataflow itself.

TB1 User Data flow Web Vulnerabilities Vulnerabilities Vulnerabilities S - T3: Fake server T T4: No SSL N/A R N/A - I T4: No SSL T1: Session ID in clear text D T2: No DOS protection T2: No DOS protection E -

Table 2: The analysis of the first trust boundary of the manual benchmark.

22

Table 2 shows that the first trust boundary already shows 4 potential threats: a lack of security for the

session ID, no Denial of Service (DOS) protection, the possibility of the user connecting to a fake server

(spoofing), and a lack of Secure Socket Layer (SSL) or any other form of encryption used for the

communication between the user and the server. The second trust boundary (Table 3) shows the same

four threats posed to the first trust boundary plus one extra threat: not having 2-factor authentication for the

staff members.

TB2 Staff Data flow Web Vulnerabilities Vulnerabilities Vulnerabilities S T5: No 2-factor authentication T3: Fake server T T4: No SSL N/A R N/A - I T4: No SSL T1: Session ID in clear text D T2: No DOS protection T2: No DOS protection E -

Table 3: The analysis of the second trust boundary of the manual benchmark.

For the last trust boundary (Table 4) no new threats were identified, the senior expert listed three threats

which were also present in the previous trust boundaries: problems with the security of the session ID, no

encryption used for the communication, and the possibility of requests from fake servers.

TB3 Web Data flow API

Vulnerabilities Vulnerabilities Vulnerabilities S T3: Fake server T N/A T4: No SSL N/A R - - I T1: Session ID in clear text T4: No SSL T1: Session ID in clear text D - - - E - -

Table 4: The analysis of the third trust boundary of the manual benchmark. After performing the threat analysis on all the trust boundaries which are present in the DFD the expert

summarized his findings in a final table where he also calculated the risk that such a threat could pose

(Table 5). The vector value indicates how easy an attacker could utilize the threat to attack the system, the

prevalence indicates how common such a weakness is in a system, the detectability expresses how easy

a potential attacker would be able to find the vulnerability in the system, and impact reveals the harm an

attacker would do to the system if he/she exploited that vulnerability. After the expert has rated every

vulnerability on these four categories, he estimates the security risk posed by these vulnerabilities by

multiplying the impact of each vulnerably and the average of the vector, prevalence and detectability value.

This list of vulnerabilities serves as the solution for the threat modelling case.

23

ID Vulnerability Vector Prevalence Detectability Impact Rating Risk

V1 Session ID in clear text

3 2 3 2 5.3 Medium

V2 No DoS protection 2 2 2 2 4.0 Medium V3 Fake server 1 2 2 2 3.3 Medium V4 No data flow

encryption 3 2 3 2 5.3 Medium

V5 Missing 2-factor authentication

1 1 2 1 1.3 Low

Table 5: An overview and rating of the different vulnerabilities of the manual benchmark.

5.2 Expert panel Threat modelling experience Table 6 gives an overview of the threat modelling experience of the experts on the panel. It shows that the

years of threat modelling experience range from one year up to four years. The experts have been split up

into two group based on their years of threat modelling experience and their day-to-day use of threat

modelling. Group A will use the Microsoft Threat Modelling tool 2016 first to perform a threat analysis on

the threat modelling case and afterwards use the Tutamen Threat Modelling Tool. Group B will use the

threat modelling tools in reverse order.

Group A B Expert number 1 number 2 number 3 number 4 Threat modelling experience 4 years 2 years 4 years 1 year Day-to-day use of threat modelling (1 = never; 5 = every day)

3 3 4 2

Table 6: An overview of the threat modelling experience of the expert panel. Experience with the provided tools Table 7 shows that the Microsoft Threat Modelling tool is used more on a day-to-day basis then then

Tutamen Threat Modelling tool. Three out of four experts have reported to use it frequently by giving it a

score of six or more out of nine. Only expert number 1 states to use the tool less frequent then the other

experts on the panel. The Tutamen Threat Modelling tool is used less than the Microsoft tool, expert number

1 and 4 have reported to have never used tool before. Expert number 2 and 3 states to use the Tutamen

Threat Modelling tool before, but do not use it as frequently in their day-to-day activities as the Microsoft

Threat Modelling tool 2016.

Group A B Expert number 1 number 2 number 3 number 4 Day-to-day use of the Microsoft Threat Modelling tool

3 7 7 6

Day-to-day use of the Tutamen Threat Modelling tool 1 2 2 1 Table 7: On overview of the experts’ experience with the provided tools (1= never; 9= every day).

24

5.3 Microsoft Threat Modelling Tool 2016

5.3.1 Automatically generated threats: accuracy and completeness

Table 8 gives an overview of the amount of threats that the Microsoft Threat Modelling tool has generated

automatically for each expert, it also indicates the amount of threats which the experts have marked as

applicable to the threat modelling case. Experts 1, 2, and 3 all have 21 threats which were automatically

generated by the tool, but the amount of applicable threats range from 7 up to 9. Expert 4 has a higher

number of generated threats (35) then the rest of the panel and indicates more applicable threats then the

other experts (12).

Group A Group B Expert 1 Expert 2 Expert 3 Expert 4

Number of threats automatically generated by tool 21 21 21 35 Number of threats applicable to case 9 8 9 12 Number of threats rejected 12 13 12 23

Table 8: An overview of the automatically generated list of threats produced by the Microsoft Threat Modelling Tool

2016.

Expert 1 Expert 1 has created a DFD for the system which is almost identical to the DFD of the manual benchmark

(Figure 10), the only difference is that he did not include the part of the system which is not within scope

for the threat analysis. This DFD automatically generated a list of 21 threats which could potentially harm

the system. Table 9 gives an overview of the threats that the Microsoft Threat Modelling tool generated for

the provided DFD (Figure 11). When this list of automatically generated threats is compared to the list of

threats which expert 1 deems applicable to the system (Table 10) it can be noted that the length of the list

declines from 21 elements down to 9 elements.

Figure 11: The threat modelling case DFD made by expert 1 (Microsoft Threat Modelling tool 2016).

25

Interaction Threat category (STRIDE)

Name threat

Web to API Spoofing Spoofing API address (fake server) Tampering Potential lack of input validation for API Tampering Cross site scripting (caused by lack of input validation) Repudiation Potential data repudiation by API Information disclosure Data flow sniffing (reading of data in transit) Denial of service Potential process crash or stop for API Denial of service Data flow API request is potentially interrupted Elevation of privilege Elevation using impersonation Elevation of privilege API may be subject to elevation of privilege using remote

code execution Elevation of privilege Elevation by changing the execution flow in API

API to Database Spoofing Spoofing of destination data store (fake database server) Tampering Potential SQL injection vulnerability for database Information disclosure Authorization bypass Information disclosure Weak credential storage Denial of service Potential excessive resource consumption for API or

database Customer to Web

Tampering Authenticated data flow compromised (reading and/or modification of data in transit)

Repudiation External entity web potentially denies receiving data Denial of service Data flow login is potentially interrupted

Staff to Web Tampering Authenticated data flow compromised Repudiation External entity web potentially denies receiving data Denial of service Data flow management is potentially interrupted

Table 9: An overview of the automatically generated list of threats for expert 1, 2 and 3 (the Microsoft Threat

Modelling Tool 2016).

Interaction Type of threat (STRIDE) Name threat Web to API Spoofing Spoofing API address

Information disclosure Data flow sniffing Denial of service Potential process crash or stop for API Denial of service Data flow API request is potentially interrupted

API to Database Tampering Potential excessive resource consumption for API or database

Customer to Web

Tampering Authenticated data flow compromised

Denial of service Data flow login is potentially interrupted Staff to Web Tampering Authenticated data flow compromised

Denial of service Data flow management is potentially interrupted Table 10: An overview of the list of threats for which expert 1 agrees that they pose a threat to the system (the

Microsoft Threat Modelling Tool 2016).

26

The nine threats which expert 1 has identified for the system combined with his personal threat modelling

experience form the list of vulnerabilities which were reported (Table 11). When this list of vulnerabilities of

expert 1 is compared to the vulnerabilities identified in the benchmark (Table 5) it shows that expert 1 has

successfully identified all vulnerabilities. The first four vulnerabilities of expert 1 can be derived from the list

of automatically generated threats which he deemed applicable to the system (Table 10). Only the last

vulnerability, stronger authentication for staff members, was not identified by the Microsoft Threat Modelling

tool but by the experience of the expert.

ID Vulnerability Description 1 Denial of service The web server forms a single point of failure. If an attacker can

compromise this the whole service will be down. 2 Spoofing An attacker can pretend to be the web server and intercept all

incoming traffic. 3 Encryption All dataflows must be encrypted to ensure that an attacker will not

intercept login information or modify any data in transit. 4 Session ID By not using encryption and sending the session ID in plain text an

attacker can highjack the session and obtain elevated privilege. 5 Authentication of staff Since the staff has access to the user management systems after

logging in it is recommended to use a better authentication method then just a username and password.

Table 11: An overview of the vulnerabilities provided by expert 1.

Expert 2 Expert 2 created a DFD (Figure 12) which is very similar to that of expert 1 (Figure 11), the only difference

between the two are the names that are used for the different elements. Since both DFDs are identical

except for the names, the Microsoft Threat Modelling tool generated the same list of potential threats (Table

9). Out of the 21 suggested threats eight were marked by expert 2 as applicable to the system (Table 12).

Figure 12: The threat modelling case DFD made by expert 2 (Microsoft Threat Modelling tool 2016).

27

Interaction Name threat Internet to API Spoofing API address

Data flow sniffing Potential process crash or stop for API Data flow API request is potentially interrupted

Customer to internet Authenticated data flow compromised Data flow login is potentially interrupted

Staff member to internet Authenticated data flow compromised Data flow management is potentially interrupted

Table 12: An overview of the list of threats for which expert 2 agrees that they pose a threat to the system (the

Microsoft Threat Modelling Tool 2016).

When requested to provide the system’s vulnerabilities expert 2 provided a list of four threats which can be

seen in Table 13. The provided vulnerabilities are also present in the manual benchmark vulnerabilities list,

however the need for a stronger staff authentication method is missing from expert 2’s list.

ID Vulnerability Description 1 Encryption To assure a safe login process the communication between the users

and the system must be encrypted. 2 Session ID By protecting the session ID and using encryption the communication

will be more secure. 3 Fake webserver

(spoofing) The webserver can be imitated and used as a method to intercept log in credentials.

4 Denial of service A failure of the web server will cause the entire system to go down. Table 13: An overview of the vulnerabilities provided by expert 2.

Expert 3 Expert 3 created a DFD which is almost identical to the DFD of expert 1 and 2 except for one minor

difference: he used a different element to represent the web in his DFD. Instead of using the browser

element like experts 1 and 2 did, expert 3 used an external web service element to represent the web. This

difference appears to seem minor since the number of automatically generated threats remains the same

as for experts 1 and 2 (Table 9).

Figure 13: The threat modelling case DFD made by expert 3 (Microsoft Threat Modelling tool 2016).

28

Out of the 21 different suggested threats nine were marked by expert 3 to be relevant to the system (Table

14). From these nine automatically generated threats and his own expertise expert 3 concluded that the

system has 5 vulnerabilities in its design: (1) weak staff authentication, (2) no encryption being used, (3)

the session ID is being transmitted in plain text, (4) the system is vulnerable to DoS attacks, and (5) an

attacker can fake being the webserver to intercept data (Table 15).

Interaction Type of threat (STRIDE) Name threat Web to API Spoofing Spoofing API address

Information disclosure Data flow sniffing Denial of service Potential process crash or stop for API Denial of service Data flow API request is potentially interrupted

API to Database Tampering Potential excessive resource consumption for API or database

Customer to Web Tampering Authenticated data flow compromised Denial of service Data flow login is potentially interrupted

Staff to Web Tampering Authenticated data flow compromised Denial of service Data flow management is potentially interrupted

Table 14: An overview of the list of threats for which expert 3 agrees that they pose a threat to the system (the

Microsoft Threat Modelling Tool 2016).

ID Vulnerability Description 1 Staff authentication method 2-factor authentication recommended for staff to ensure that

attackers have a much harder time getting in the system. 2 Encryption By not encrypting the dataflows attackers can easily intercept

and read data which might include sensitive information (like login information).

3 Session ID openly transmitted By transmitting the session ID in plain text, the attacker can pretend to be a user or staff by simply copying the session ID without the need for any login information.

4 Denial of Service If the single webserver goes down the entire system will go down.

5 Webserver spoofing An attacker can pretend to be the webserver to collect sensitive data.

Table 15: An overview of the vulnerabilities provided by expert 3.

Expert 4 Expert 4 created a DFD which differs from the three other experts: it has two trust boundaries, uses the

developer instead of the staff as one of the external interactors, uses the webserver as an element, and

included the backup database (Figure 14). This difference this DFDs results in a longer list of potential

threats (Table 16). The threats which expert 4 considers applicable to the system are marked in green,

these threats form the basis for expert 4’s list of system vulnerabilities: (1) spoofing, (2) tampering, and (3)

denial of service (Table 16). Table 17 shows that expert 4 has correctly identified 4 out of 5 system

vulnerabilities even though he has only listed 3 vulnerabilities. His spoofing vulnerability acknowledges the

threat of the session ID being copied and used by an attacker and the possibility of a fake server being

29

used by an attacker, the tampering vulnerability recognizes the need for encryption, and the denial of

service vulnerability is identified.

Figure 14: The threat modelling case DFD made by expert 4 (Microsoft Threat Modeller).

30

Interaction Threat category (STRIDE) Name threat API request Spoofing Spoofing the API Process

Tampering Potential lack of input validation for API Tampering Replay attacks Tampering Collision attacks Tampering Cross site scripting Repudiation Potential data repudiation by API Information Disclosure Data flow sniffing Information Disclosure Weak authentication scheme Denial of Service Potential process crash or stop for API Denial of Service Data flow API request is potentially interrupted Elevation of Privilege Elevation using impersonation Elevation of Privilege API may be subject to elevation of privilege using remote

code execution Elevation of Privilege Elevation by changing the execution flow in API

Deploy code Spoofing Spoofing the dev external entity Tampering Cross site scripting Elevation of Privilege Elevation using impersonation

LAN Spoofing Spoofing of destination data store database Tampering Potential SQL Injection Vulnerability for database Information Disclosure Potential SQL Injection Vulnerability for database Information Disclosure Weak credential storage Denial of Service Potential excessive resource consumption for API or

database Spoofing Spoofing of source data store database Spoofing Spoofing of destination data store backup database

Login Spoofing Spoofing the web server process Tampering Potential lack of input validation for web server Tampering Authenticated data flow compromised Tampering Cross site scripting Repudiation Potential data repudiation by web server Information Disclosure Data flow sniffing Denial of Service Potential process crash or stop for web server Denial of Service Data flow login is potentially interrupted Elevation of Privilege Elevation using impersonation Elevation of Privilege Web server may be subject to elevation of privilege using

remote code execution Elevation of Privilege Elevation by changing the execution flow in web server Elevation of Privilege Cross site request forgery

Table 16: An overview of the automatically generated list of threats for expert 4 (the Microsoft Threat Modelling Tool

2016).

31

ID Vulnerability Description 1 Spoofing Customers: customers can be spoofed by intercepting the session.

Webserver: attackers can spoof the server to intercept communications to and from the real server. Developer: developer can be spoofed to gain elevated privilege.

2 Tampering Incoming data can be read and tampered with if no encryption is used 3 Denial of Service Denial of service attack on the webserver will break the whole system, it forms

a single point of failure Table 17: An overview of the vulnerabilities provided by expert 4.

5.3.2 Time efficiency: time needed to complete the threat modelling case Table 18 gives an overview of the time that was needed by each expert to perform the threat analysis.

Group A (expert 1 and 2) used the Microsoft Threat Modelling tool first out of both tools which are tested.

Expert 2 is the fastest of the group with a time of 27,8 minutes, expert 1 took roughly a minute longer to

complete the analysis with a time of 28,6 minutes. Group B performed the second threat analysis of the

system with the Microsoft tool. Out of this group expert 3 was the fastest with a time of 26,8 minutes and

expert 4 set a time of 31,2 minutes. All experts of the panel beat the manual benchmark’s time, no matter

if it was the first or second threat analysis that they performed.

Group A Group B Manual benchmark Expert 1 Expert 2 Expert 3 Expert 4

Time needed to complete threat analysis (in minutes)

35,5 28,6 27,8 26,8 31,2

Table 18: An overview of the time needed to perform the treat analysis with the Microsoft Threat Modelling Tool 2016.

5.3.3 Ease of use After the completion of the threat analysis each expert was asked about their experience with the Microsoft

Threat Modelling tool 2016, the results can be seen in Table 19. Expert 1 did not enjoy using the tool and

does not like the way the tool works. These feelings on the tool are not shared by the other experts of the

panel. Expert 3 considers the tool neither bad nor good and gives the tool a 3 out of 5 on both user

experience and ease of use. Experts 2 and 4 find the tool easy to use, but expert 4 feels indifferent about

the user experience that the tool offers.

Group A Group B

Expert 1 Expert 2 Expert 3 Expert 4 User experience of the Microsoft threat modelling tool

2 4 3 3

Ease of use of the Microsoft threat modelling tool 2 4 3 4 Table 19: User experience and ease of use of the Microsoft Threat Modelling tool 2016 (1= very bad; 5= very good).

32

5.4 Tutamen 5.4.1 Automatically generated threats: accuracy and completeness

Table 20 gives an overview of the amount of threats that the Tutamen threat modelling tool automatically

generates for each expert based on their DFD. It also shows how many of these threats each expert

believes to be applicable to the system. For experts 1 and 3 the tool automatically generated 14 threats,

for which they indicate that about half of them are relevant to the case (7 out of 14 for expert 1 and 6 out of

14 for expert 3). Expert 2 generated one more threat then expert 1 and 3, amounting to a total of 15

generated threats. Out of these 15 threats, expert 2 believes that 8 of them apply to the case. The Tutamen

threat modelling tool generated 10 threats for the DFD of expert 4, out of which 7 are indicated by expert 4

to be applicable to the case.

Group A Group B Expert 1 Expert 2 Expert 3 Expert 4 Number of threats automatically generated 14 15 14 10 Number of threats applicable to case 7 8 6 7 Number of threats rejected 7 7 8 3

Table 20: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool.

Expert 1 Table 21 shows the threats that the Tutamen threat modelling tool automatically generated for the DFD of

expert 1 (Figure 11). It also shows which threats the expert finds applicable to the case and which threats

are dismissed. Seven threats are indicated by the expert to be applicable to the case, which lead to the

system vulnerabilities (Table 22).

ID Description T1 Unauthenticated access, attacker performs a malicious action without providing any proof

of their identity. T2 Unauthorized access, attacker uses a service without being properly authorized to. T3 Cryptographic breach, attacker breaches cryptographic controls. T4 Insecure configuration, attacker takes advantage of a misconfiguration to perform an

unauthorized action. T5 Non-repudiation(poor logging), Attacker performs a malicious action which cannot be

detected or accounted. T6 Poor exception handling, attacker takes advantage of an insecure exception in system T7 Malicious data (poor validation), attacker injects malicious data into a service. T8 poor protection of (sensitive) data, attacker breaches sensitive data. T9 Session compromise, attacker compromises a session to perform an unauthorized action.

T10 Message deletion T11 Message insertion T12 Message modification T13 Message replay T14 Unauthorized disclosure

Table 21: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 1 (A green threat ID indicates which threats expert 1 believes to be applicable to the case).

33

Six out of seven automatically generated threats correspond to one or more of the system vulnerabilities

which were listed by expert 1. The only threat which is not linked to a system vulnerability is T4, the insecure

configuration. Two out of five listed vulnerabilities have no corresponding threats: denial of service and

stronger authentication for staff members.

ID Vulnerability Applicable threats V1 Denial of service None V2 Spoofing T9, T10, T11, T13 V3 Encryption T8, T12 V4 Session ID T9 V5 Authentication of staff None

Table 22: An overview of the listed vulnerabilities by expert 1 and the corresponding automatically generated threats from the Tutamen threat modelling tool. Expert 2 For the DFD of expert 2 (Figure 12) the Tutamen threat modelling tool generated 15 threats in total (Table

23). The private key compromise threat (T10) is the only difference between the threats that are generated

for expert 1 and 2. Since their DFDs are almost identical except for the names of DFD elements this disparity

in generated threats is caused by the different attributes which can be used for DFD elements. Out of the

fifteen automatically generated threats eight are marked by expert 2 to be applicable to the system.

ID Description T1 Unauthenticated access, attacker performs a malicious action without providing any proof

of their identity. T2 Unauthorized access, Attacker uses a service without being properly authorized to. T3 Cryptographic breach, Attacker breaches cryptographic controls. T4 Insecure configuration, Attacker takes advantage of a misconfiguration to perform an

unauthorized action. T5 Non-repudiation(poor logging), Attacker performs a malicious action which cannot be

detected or accounted. T6 Poor exception handling, Attacker takes advantage of an insecure exception in system T7 Malicious data (poor validation), Attacker injects malicious data into a service. T8 poor protection of (sensitive) data, Attacker breaches sensitive data. T9 Session compromise, Attacker compromises a session to perform an unauthorized action. T10 private key compromise, attacker accesses private key of certificate, enabling access to all

uses of public/private key pair T11 Message deletion T12 Message insertion T13 Message modification T14 Message replay T15 Unauthorized disclosure

Table 23: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 2 (A green threat ID indicates which threats expert 2 believes to be applicable to the case). Seven out of eight applicable threats correspond to the listed system vulnerabilities (Table 24), only threat

number 4 (insecure configuration) does not correspond to one of the four indicated vulnerabilities.

34

Furthermore, there were no automatically generated threats which coincide with the denial of service

vulnerability (v4).

ID Vulnerability Applicable threats V1 Encryption T8, T10, T13 V2 Session ID T9 V3 Fake webserver

(spoofing) T11, T12, T14

V4 Denial of service None Table 24: An overview of the listed vulnerabilities by expert 2 and the corresponding automatically generated threats from the Tutamen threat modelling tool. Expert 3 The Tutamen threat modelling tool generated the same 15 threats for expert 3 as it did for expert 1 (Table

25). However, expert 3 believes that only six out of fifteen generated threats apply to the case. Unlike

expert 1, expert 3 does not believe that the insecure configuration is applicable to the system.

ID Description

T1 Unauthenticated access, attacker performs a malicious action without providing any proof of their identity.

T2 Unauthorized access, Attacker uses a service without being properly authorized to. T3 Cryptographic breach, Attacker breaches cryptographic controls. T4 Insecure configuration, Attacker takes advantage of a misconfiguration to perform an

unauthorized action. T5 Non-repudiation(poor logging), Attacker performs a malicious action which cannot be

detected or accounted. T6 Poor exception handling, Attacker takes advantage of an insecure exception in system T7 Malicious data (poor validation), Attacker injects malicious data into a service. T8 poor protection of (sensitive) data, attacker breaches sensitive data. T9 Session compromise, Attacker compromises a session to perform an unauthorized action.

T10 Message deletion T11 Message insertion T12 Message modification T13 Message replay T14 Unauthorized disclosure

Table 25: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 3 (A green threat ID indicates which threats expert 3 believes to be applicable to the case). The six threats which were indicated to be applicable to the system all correlate with one of the

vulnerabilities which were listed by expert 3 (Table 26). However, the staff authentication and denial of

service vulnerability do not have any corresponding threats.

35

ID Vulnerability Applicable threats V1 Staff authentication method None V2 Encryption T8, T12 V3 Session ID openly transmitted T9 V4 Denial of Service None V5 Webserver spoofing T10, T11, T12, T13

Table 26: An overview of the list of threats for which expert 3 agrees that they pose a threat to the system (the

Tutamen Threat Modelling Tool).

Expert 4 The Tutamen threat modelling tool generated the lowest number of threats for expert 4, a total of 10

threats. As indicated in the previous section on the Microsoft Threat Modelling tool 2016, expert 4 has a

DFD which diverges from the other experts (Figure 14). This different DFD and the attributes that the

experts chose for the DFD elements result in a much shorter list of threats compared to those of other

experts. Seven out of ten threats are marked by expert 4 as applicable to the case, all seven correspond

to one vulnerability which were listed by expert 4 (Table 28). The only vulnerability which does not have a

corresponding threat is the denial of service vulnerability.

ID Description T1 Unauthenticated access, attacker performs a malicious action without providing any proof

of their identity. T2 Unauthorized access, Attacker uses a service without being properly authorized to. T3 Cryptographic breach, Attacker breaches cryptographic controls. T4 Insecure configuration, Attacker takes advantage of a misconfiguration to perform an

unauthorized action. T5 Non-repudiation(poor logging), Attacker performs a malicious action which cannot be

detected or accounted. T6 Poor exception handling, Attacker takes advantage of an insecure exception in system T7 Malicious data (poor validation), Attacker injects malicious data into a service. T8 poor protection of (sensitive) data, attacker breaches sensitive data. T9 Session compromise, Attacker compromises a session to perform an unauthorized action. T10 private key compromise, attacker accesses private key of certificate, enabling access to all

uses of public/private key pair Table 27: An overview of the automatically generated list of threats produced by the Tutamen threat modelling tool for expert 4 (A green threat ID indicates which threats expert 4 believes to be applicable to the case).

ID Vulnerability Applicable threats V1 Spoofing T2, T4, T9 V2 Tampering T3, T7, T8, T10 V3 Denial of Service None

Table 28: An overview of the list of threats for which expert 4 agrees that they pose a threat to the system (the

Tutamen threat modelling tool).

36

5.4.2 Time efficiency: time needed to complete the threat modelling case

Table 29 gives an overview of how long each expert needs to complete the threat analysis for the case

with the Tutamen tool. Group B (which used the Tutamen tool for their first analysis) was the slowest,

expert 3 needs 26,8 minutes to complete the threat analysis and expert 4 needs 31,2 minutes. Though

they are the slowest times, they still completed the threat analysis faster then the manual benchmark.

Expert 3 beats the manual benchmark time with 8,7 minutes and expert 4 was 4,3 minutes faster than the

manual benchmark. Both experts from group A (which used the Tutamen tool for their second threat

analysis) were also faster than the manual benchmark. Expert 1 was 9,8 minutes faster and expert 2

managed to beat the manual benchmark time by 9 minutes.

Group A Group B Manual benchmark Expert 1 Expert 2 Expert 3 Expert 4

Time needed to complete threat analysis (in minutes)

35,5 25,7 26,5 26,8 31,2

Table 29: An overview of the time needed to perform the treat analysis with the Tutamen threat modelling tool.

5.4.3 Ease of use Table 30 indicates the user-friendliness and ease of use of the Tutamen threat modelling tool. Expert 1

and 2 demonstrate that they like using the tool by awarding it a score of four out of five for the user

experience. Expert 3 feels indifferent about the user experience and expert 4 indicates to not like it. Four

out of five points are awarded for the tool’s ease of use by expert 1 and 3. Expert 2 feels indifferent about

the usability of the tool and expert 4 shows not liking how the tool works. Expert 4 wrote in a comment

field of the survey: ‘’The tool [Tutamen threat modelling tool] can be confusing when choosing the right

attributes for the DFD. I always had to go look up the different attributes and lost quite some time

because of this’’.

Group A Group B Expert 1 Expert 2 Expert 3 Expert 4

User experience of theTutamen threat modelling tool 4 4 3 2 Ease of use of the Tutamen threat modelling tool 4 3 4 2

Table 30: User experience and ease of use of theTutamen threat modelling tool (1= very bad; 5= very good).

37

6. Discussion

6.1 Tool accuracy Microsoft Threat Modelling tool 2016 The Microsoft Threat Modelling tool 2016 generated a list of 21 and 35 threats automatically for the provided

SSO system, dependant on the DFD which was utilised. Expert 4 has a different structure for his DFD which

caused an increase in the number of threats that the Microsoft Threat Modelling tool 2016 generates. This

difference in automatically generated threats has been observed in the work of Williams & Yuan (2015).

Williams & Yuan (2015) noted that that the results of a threat analysis with the Microsoft Threat Modelling

Tool are dependent on the completeness of the DFD and the elements used in the DFD. It is possible that

expert 4 lacked the threat modelling knowledge, since he is the least experienced on the expert panel, to

design the DFD correctly or he possibly misinterpreted the provided architectural description of the system.

Since expert 4 indicated to have experience with the Microsoft Threat Modelling tool a lack of threat

modelling experience or misinterpretation of the system description appears more likely.

From the total number of threats that the Microsoft Threat Modelling Tool generated less then half were

marked by each expert as applicable to the system. This high number of generated threats, compared to

the applicable threats, indicates an extensive threat generation by the Microsoft Threat Modelling Tool or a

lack of DFD customization options which lead to a broader threat generation. The Microsoft Threat

Modelling Tool does allow for the use of custom DFD elements and attributes, however the experts were

asked to not include any custom elements to ensure that no expert had an advantage due to prior

experience with the tool. Both options indicate that there is a certain requirement of threat modelling or

security experience to identify the applicable threats and vulnerabilities to implement useful security

features.

Both automatically generated lists of threats (21 and 35 threats long) correctly identified four out of five

vulnerabilities which were verified during the benchmark: (1) the session ID, (2) denial of service, (3)

spoofing of the web server, and (4) missing encryption. The only vulnerability which was not identified

automatically by the tool is the need for stronger staff authentication with for example 2-factor

authentication. The two most experienced members of the expert panel, expert 1 and 3 with four years of

threat modelling experience each, were able to successfully identify this system vulnerability. This suggests

that personal threat modelling experience influences the results and accuracy of a threat analysis. This has

also been observed in the work of Mirembe & Muyeba (2008) and Möckel & Abdallah (2010). Mirembe &

Muyeba (2008) concluded in their work: ‘’ In general there is no well defined[sic] technique of measuring

the quality of threat models. Therefore, quality depends on rigorous analysis and experience of the analyst’’

(p. 98).

38

Tutamen threat modelling tool The Tutamen threat Modelling tool generated a smaller list of threats for the provided system, ranging from

10 to 14 threats. Unlike the Microsoft Threat Modelling tool, the Tutamen threat modelling tool generated

less threats for expert 4 with his deviating DFD. This indicates that the findings of Williams & Yuan (2015),

that different DFDs and elements lead to different threat analysis results, are applicable not only to the

Microsoft Threat Modelling Tool but also extend to other threat modelling tools. This illustrates the findings

of Mirembe & Muyeba (2008) and Möckel & Abdallah (2010) that threat modelling experience—for example

making DFDs—is decisive for the overall quality of the threat analysis.

The smaller number of automatically generated threats leads to a higher threat applicability rate, ranging

from 6 out of 14 up to 7 out of 10. These lists of automatically generated threats could identify three out of

five system vulnerabilities: (1) spoofing of the web server, (2) the need for encryption, and (3) the vulnerable

session ID. The Tutamen threat modelling tool, like the Microsoft tool, fails to identify the need for stronger

authentication mechanisms for staff members. Furthermore, it does not mention anything about a possible

denial of service attack. Both experts from group B (expert 3 and 4), who used the Tutamen tool first, were

able to identify the denial of service vulnerability despite it not being displayed by the Tutamen tool.

However, expert 4 (1-year threat modelling experience) was not able to identify the need for stronger staff

authentication while expert 3 (4 years’ experience) was able to identify this vulnerability. This further

indicates the relationship between the completeness of the threat analysis and the threat modelling

experience of the analyst. Another possible explanation is that the experts are too focused on the threats

generated by the tool and don’t think critically anymore. For example, an expert might only consider threats

which are presented to him/her by the tool and don’t consider threats which are missing from that list. This

has been observed by Mirembe & Muyeba (2008) while using attack trees and it is possible that this

phenomenon also applies to the use of threat modelling tools.

6.2 Time efficiency To measure whether the threat modelling tools are more time efficient then non-specialised tools each

expert was asked to keep track of the time it took to perform the threat analysis. To reduce the bias in the

results the panel of experts was split into two group (A and B) which use the two tools in a different order.

Table 31 gives an overview of time it took to complete the threat analysis for each expert and in what order

they used the tools. Each expert completed the threat analysis faster then the manual benchmark time of

35,5 minutes. This indicates that the threat modelling tools provide some sort of extra value to the analyst

which allows them to work more time efficiently. This could be the result of the inbuild automatic threat

generation or not having to copy and paste data between different programs. Each expert performed better

on their second threat analysis, for this reason the two groups were formed.

Personal experience with the tool and an analyst’s threat modelling experience appears to influence the

time needed to perform a threat analysis with the tools. For group A’s first round of analysis (with the

Microsoft Threat Modelling tool) expert 2 performed faster then expert 1. Expert 2 was able to do this

because of his better knowledge of the tool, despite his 2 years deficit in threat modelling experience

39

(compared to expert 1). However, in the second round of analysis expert 1 beat the time of expert 2, even

though expert 1 had never used the Tutamen tool before. This indicates that threat modelling experience

proves very valuable when one has very little to no experience with that threat modelling tool. Table 31 also

shows that expert 3 consistently beats the time of expert 4. This can be explained by the 3 years of

experience that expert 3 has over expert 4.

Group A

Group B Expert 1 Expert 2

Expert 3 Expert 4

Tools Time Tools Time Microsoft 28,6 27,8 Tutamen 26,8 31,2 Tutamen 25,7 26,5 Microsoft 24,6 29,3

Table 31: An overview of the time it took to finish the threat analysis per expert and per tool.

6.3 User friendliness Table 32 gives an overview of the user experience and ease of use for each tool and shows the diverging

opinions of the expert panel. Expert 1 appears to not like the experience of using the Microsoft Threat

Modelling tool but does like to use the Tutamen threat modelling tool. This is the opposite of expert 4 who

does not like the Tutamen tool but prefers to use the Microsoft Threat Modelling tool. This opinion (expert

4) could be influenced by the fact that he uses the Microsoft Threat Modelling tool frequently, this

combined with the different workflow of the Tutamen tool could have attributed to expert 4’s low scores.

Expert 2 appears to be fond of both tools, except for the ease of use of the Tutamen threat modelling tool,

this could also be influenced by the fact that expert 2 also frequently uses the Microsoft tool. Expert 3,

who also indicated to be a frequent user of the Microsoft tool, feels indifferent for the user experience of

the Microsoft tool but appears to like the ease of use of the Tutamen tool.

In their study on the effectiveness of the Micosoft Threat Modelling tool, Williams & Yuan (2015) found

that students like the automatic threat generation and feedback that the tool provide but didn’t like the

generic DFD elements and wished for more specific elements. The expert panel has a divided opinion on

the Microsoft tool, this is most likely influenced by the threat modelling workflow and the tools that they

normally use to perform a threat analysis.

Tools

Expert 1 Expert 2 Expert 3 Expert 4 Microsoft Threat Modelling

user experience 2 4 3 3

ease of use 2 4 3 4

Tutamen user experience 4 4 3 2 ease of use 4 3 4 2

Table 32: An overview of the user friendliness per tool.

40

6.4 Do threat modelling tools provide extra value to the security process? Based upon the three measures that this study has analysed for two different threat modelling tools, they

appear to add extra value to the security process. Both tools are confirmed to be faster than the use of

non-specialised tools, even in the hands of less experienced analysts. However, the analyst’s threat

modelling experience and experience with the tool influences the time needed to complete a threat

analysis. One reason that the threat modelling tools are faster than non-specialised tools is the automatic

threat generation they provide. This automatic threat generation is a good guideline for the analyst to

identify threats and system vulnerabilities. However, the list of generated threats should be looked at

critically by the analyst and should not be the end result of the threat analysis. An analyst should keep an

open mind about all possible threats and look further then the automatically generated threat list to

successfully identify all system threats and vulnerabilities. This competence, to look further then the

automatically generated list and identify all vulnerabilities, is related to the analyst’s years of threat

modelling experience. Lastly, if either of the tested tools fit an analyst’s workflow or work environment and

they feel easy to use it they will be an added value to that analyst’s security process.

6.5 Limitations of the research The conclusions of this research are only valid for the tools that have been tested, the results cannot be

generalised to all threat modelling tools. To generalise the results of this research a bigger sample, of both

threat modelling tools and experts, is needed. This research does not have the goal to produce generalised

results, instead its purpose is to provide a stepping stone for further future research into the effectiveness

and added value of threat modelling tools. Since little research has been done on this topic an exploratory

case study is preferable since it is used to understand and characterize a phenomenon without analysing

variables’ effect on the phenomenon. Furthermore, a descriptive study is a useful research tool to devise

research questions for future research.

Since little research has been performed on the use of threat modelling tools, the decision was made to

combine the research methodologies of two other studies: (1) a study performed by Wuyts et. al (2014)

with almost identical research questions, and (2) a study by Williams & Yuan (2015) where they tested the

effectiveness of the Microsoft Threat Modelling tool on students. Combining two different research

methodologies might result in less accurate and less reliable results, but this is not the goal of a descriptive

case study. One element that will skew the results is the fact that all experts had to perform a threat analysis

twice for the same system. This means that the second attempt will be faster than the first one, unless the

expert has a lot of problems with the workings of the tool. An attempt was made to minimize this bias in the

results by dividing the panel of experts into two group, of similar experience, and making them use different

threat modelling tools for their first attempts. Nonetheless, the bias cannot be completely avoided.

Furthermore, by creating two separate groups another bias was created. The list of system vulnerabilities

which the experts created during their first threat analysis was copied to their second analysis—since it was

for the same system. This might have had an impact on the accuracy and time efficiency results of this

research.

41

6.6 Further research The limitations which are mentioned in the previous section are all possible directions for future research.

Future research could further investigate the effectiveness of threat modelling tools with a bigger sample

of experts and/or tools. Furthermore, it could prove interesting for future research to create a ‘’threat

modelling benchmark’’, a methodology to measure the performance of various aspects of threat modelling

tools. This would allow for the comparison between different tools and allows for security analysts to choose

the right tool which fits their needs.

7. Conclusion In this research a descriptive case study was performed to measure the effectiveness of threat modelling

tools. An expert panel, consisting of four threat modelling experts, was asked to perform a threat analysis

on a system with two provided threat modelling tools: the Microsoft Threat Modelling tool 2016 and the

Tutamen threat modelling tool. To measure the effectiveness of the tools three aspects were assessed: (1)

the accuracy of the automatic threat generation, (2) the time it took to complete the analysis, and (3) the

ease of use of the tool. Firstly, it was found that both tools have a differing accuracy of automatic threat

generation and require the analyst’s threat modelling experience to uncover all system vulnerabilities. The

accuracy of both tools is dependent on the utilized DFD and its elements, the ability of the analyst to mark

generated threats applicable and discover missing threats from the generated list. Secondly, both tools

were faster to complete a full threat analysis compared to a manual benchmark where no specialised tools

were used, even when the experts had no prior knowledge of the tools. Lastly, the two tools were both

received differently by the expert panel in terms of ease of use and user experience, this is dependent on

the personal threat modelling workflow of the expert and his/her threat modelling experience. In summary,

both threat modelling tools appear to provide extra value to the security process and its users. However,

more research needs to be performed on the matter with different tools and bigger samples to generalise

the findings of this research.

i

8. Sources Agarwal, A. (2016). VAST Methodology: Visual, Agile, and Simple Threat Modeling. Various Interviews. Prescott Valley: Transformational Opportunities. Al-Fedaghi, S., & Alrashed, A. A. (2010). Threat risk modeling. In 2nd International Conference on Communication Software and Networks, ICCSN 2010 (pp. 405–411). http://doi.org/10.1109/ICCSN.2010.29 Cavoukian, A. (2010). Privacy by Design: Achieving the Gold Standard in Data Protection for the Smart Grid. Tech. Rep. Information and Privacy Commissioner of Ontario: Ontario. CBS News. Berr, J. (2017, May 16). "WannaCry" ransomware attack losses could reach $4 billion. Retrieved March 08, 2018, from https://www.cbsnews.com/news/wannacry-ransomware-attacks-wannacry-virus-losses/ Chandra, P., Wohleber, T., Feragamo, J., Williams, J. (2007).CLASP v1.2: comprehensive, lightweight application security process. Tech. rep., OWASP CNN. Borak, D. & Vasel, K. (2018, February 28). The Equifax hack could be worse than we thought. Retrieved March 08, 2018, from http://money.cnn.com/2018/02/09/pf/equifax-hack-senate-disclosure/index.html Continuum Security. Vries, S. D. (2018, March 06). Threat Modeling and SDLC Security tools. Retrieved March 25, 2018, from https://www.continuumsecurity.net/ Crook, R., Ince, D., Lin, L., & Nuseibeh, B. (2002). Security requirements engineering: When anti-requirements hit the fan. In Proceedings of the IEEE International Conference on Requirements Engineering (Vol. 2002–January, pp. 203–205). http://doi.org/10.1109/ICRE.2002.1048527 Deng, M., Wuyts, K., Scandariato, R., Preneel, B., & Joosen, W. (2011). A privacy threat analysis framework: Supporting the elicitation and fulfillment of privacy requirements. Requirements Engineering, 16(1), 3–32. http://doi.org/10.1007/s00766-010-0115-7 Gartner (2017, August 16). Gartner Says Worldwide Information Security Spending Will Grow 7 Percent to Reach $86.4 Billion in 2017. Retrieved March 08, 2018, from https://www.gartner.com/newsroom/id/3784965 GDPR EU (2018). WAT IS GDPR. Retrieved February 28, 2018, from https://gdpr-eu.be/wat-is-gdpr/ Grimes, D. A., & Schulz, K. F. (2002). Descriptive studies: What they can and cannot do. London: Lancet. http://doi.org/10.1016/S0140-6736(02)07373-7 Hernan, S., Lambert, S., & Ostwald, T. (2006). Uncover Security Design Flaws using The STRIDE Approach. Retrieved March 25, 2018 from: https://msdn.microsoft.com/en-gb/msdnmag/issues/06/11/ThreatModeling/default.aspx Howard, M., & Lipner, S. (2006). The Security Development Lifecycle. Change, 34(May), 352. http://doi.org/10.1007/s11623-010-0021-7 Hussain, S., Kamal, A., Ahmad, S., Rasool, G., & Iqbal, S. (2014). Threat Modelling Methodologies: a Survey. Sci.Int.(Lahore), 26(4), 1607–1609.

ii

Ingalsbe, J. A., Kunimatsu, L., Baeten, T., & Mead, N. R. (2008). Threat modeling: Diving into the deep end. IEEE Software, 25(1), 28–34. http://doi.org/10.1109/MS.2008.25 IT Governance EU. Irwin, L. (2017, September 14). GDPR: Things to consider when processing biometric data. Retrieved March 08, 2018, from https://www.itgovernance.eu/blog/en/gdpr-things-to-consider-when-processing-biometric-data/ IT Governance UK (2018). GDPR enforcement and penalties. Retrieved February 28, 2018, from https://www.itgovernance.co.uk/dpa-and-gdpr-penalties Kamvar, S. D., Schlosser, M. T., & Garcia-Molina, H. (2003). The Eigentrust algorithm for reputation management in P2P networks. In Proceedings of the twelfth international conference on World Wide Web - WWW ’03 (p. 640). https://doi.org/10.1145/775240.775242 KuLeuven (2017). LINDDUN in a nutshell. Retrieved February 28, 2018, from https://distrinet.cs.kuleuven.be/software/linddun/linddun.php Last, J. M. (1986). A dictionary of epidemiology. International Journal of Epidemiology. https://doi.org/10.1093/ije/15.2.277 McGraw, G. (2006). Software Security: Building Security in. In Proceedings - International Symposium on Software Reliability Engineering, ISSRE. https://doi.org/10.1109/ISSRE.2006.43 Microsoft Technet (2017). Security Update Severity Rating System. Retrieved March 08, 2018, from https://technet.microsoft.com/en-us/security/gg309177.aspx Mirembe, D. P., & Muyeba, M. (2008). Threat modeling revisited: Improving expressiveness of attack. In Proceedings - EMS 2008, European Modelling Symposium, 2nd UKSim European Symposium on Computer Modelling and Simulation (pp. 93–98). https://doi.org/10.1109/EMS.2008.83 Möckel, C., & Abdallah, A. E. (2010). Threat modeling approaches and tools for securing architectural designs of an e-banking application. In 2010 6th International Conference on Information Assurance and Security, IAS 2010 (pp. 149–154). https://doi.org/10.1109/ISIAS.2010.5604049 MSDN. Santos, R. (2017, August 17). Getting Started - Microsoft Threat Modeling Tool - Azure. Retrieved March 25, 2018, from https://docs.microsoft.com/en-gb/azure/security/azure-security-threat-modeling-tool-getting-started Myagmar, S., Lee, A. J., & Yurcik, W. (2005). Threat Modeling as a Basis for Security Requirements. Symposium on Requirements Engineering for Information Security (SREIS), 1–8. Nguyen, H. Q., Köster, F., Klaas, M., Walter, B., Obermeier, S., & Brändle, M. (2009). Tool support for achieving qualitative security assessments of critical infrastructures. In International Conference on Security and Cryptography. NIST. Keller, N. (2017, January 10). Draft Version 1.1. Retrieved February 27, 2018, from https://www.nist.gov/cyberframework/draft-version-11 Oladimeji, E. A., Supakkul, S., & Chung, L. (2006). Security threat modeling and analysis: A goal-oriented approach. Proc of the 10th IASTED International Conference on Software Engineering and Applications SEA 2006, 13–15. Retrieved from: https://pipeline.utdallas.edu/~eao015100/documents/SecurityThreatModeling.pdf OWASP (2017). Application Threat Modeling. Retrieved March 06, 2018, from https://www.owasp.org/index.php/Application_Threat_Modeling

iii

OWASP (2017). OWASP Internet of Things Project. Retrieved February 27, 2018, from https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Vulnerabilities OWASP (2017). Threat Risk Modeling. Retrieved February 28, 2018, from https://www.owasp.org/index.php/Threat_Risk_Modeling#Trike Palanivel, M., & Selvadurai, K. (2014). Risk-driven security testing using risk analysis with threat modeling approach. SpringerPlus, 3(1), 1–14. https://doi.org/10.1186/2193-1801-3-754 Potteiger, B., Martins, G., & Koutsoukos, X. (2016). Software and attack centric integrated threat modeling for quantitative risk assessment. In Proceedings of the Symposium and Bootcamp on the Science of Security - HotSos ’16 (pp. 99–108). https://doi.org/10.1145/2898375.2898390 PwC. Castelli, C. (2018). Revitalizing privacy and trust in a data-driven world. Retrieved March 08, 2018, from https://www.pwc.com/us/en/cybersecurity/assets/revitalizing-privacy-trust-in-data-driven-world.pdf PwC (2018). The Global State of Information Security Survey 2018. Retrieved March 08, 2018, from https://www.pwc.com/us/en/cybersecurity/information-security-survey.html Saitta, P., Larcom, B., & Eddington, M. (2005). Trike v. 1 methodology document. URL: Http://dymaxion. Org/trike/ …, 1–17. Retrieved March 08, 2018 from http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf Visited 28/02/2018 Scandariato, R., Wuyts, K., & Joosen, W. (2015). A descriptive study of Microsoft’s threat modeling technique. Requirements Engineering, 20(2), 163–180. http://doi.org/10.1007/s00766-013-0195-2. Schaad, A., & Borozdin, M. (2012). TAM2: automated threat analysis. In Proceedings of the 27th Annual ACM Symposium on Applied Computing - SAC ’12 (pp. 1103–1108). https://doi.org/10.1145/2245276.2231950 Schlegel, R., Obermeier, S., & Schneider, J. (2015). Structured system threat modeling and mitigation analysis for industrial automation systems. Industrial Informatics (INDIN), 2015 IEEE 13th International Conference on. https://doi.org/10.1109/INDIN.2015.7281734 Schneier, B. (1999). Attack Trees. Dr. Dobb’s Journal of Software Tools, 24(12), 60. Retrieved from http://www.schneier.com/paper-attacktrees-ddj-ft.html Schneier B. (2000). Secrets&Lies. New York, USA:John Wiley &Sons,Inc. Security Compass (2018). Secure Your Software with Automated Threat Modeling via SD Elements: Quick, Scalable, and Secure. Retrieved March 10, 2018, from https://www.securitycompass.com/threatmodeling/ Shostack A. (2014).Threat Modeling - Designing for Security. Indianapolis, Indiana: John Wiley & Sons, Inc. Sindre, G. and Opdahl, A.L. (2005). Eliciting Security Requirements with Misuse Cases. Requirements Engineering. 10: 34–44. Stallings, W. (2006). Cryptography and Network Security – Principles and Practices (pp. 9-11). Upper Saddle River, NJ: Pearson Education International.

iv

Swiderski, F., & Snyder, W. (2004). Threat modeling (Microsoft Professional). Redmond, WA: Microsoft Press. Threat modeller (2018). How do you drive security end-to-end throughout your enterprise? . Retrieved March 28, 2018, from http://threatmodeler.com/ Torr, P. (2005). Demystifying the threat modeling process. IEEE Security & Privacy Magazine, 3, 66–70. https://doi.org/10.1109/MSP.2005.119 Tutamen Features (2018). Retrieved from: http://www.tutamantic.com/page/features Ucedavelez, T., & Morana, M. M. (2015). Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. Indianapolis, Indiana: John Wiley & Sons, Inc. Retrieved from http://techbus.safaribooksonline.com/book/networking/security/9780470500965 Wuyts, K., Scandariato, R., & Joosen, W. (2014). Empirical evaluation of a privacy-focused threat modeling methodology. Journal of Systems and Software, 96, 122–138. https://doi.org/10.1016/j.jss.2014.05.075

9. Appendix Appendix A: The architectural description provided to the expert panel. Appendix B: An example of the descriptor language used in the Tutamen threat modelling tool. Appendix C: The survey presented to the expert panel.

A

Appendix A: The architectural description provided to the expert panel You are hired by ABC Hotels, a big hotels chain, to perform a security analysis of their current system. They are afraid that their Single Sign On (SSO) system may be vulnerable to attackers. Their SSO system has a 3-tier architecture and has the following specifications:

• There is a webserver in the DMZ that handles all incoming traffic and authorization. The application runs on PHP and allows both HTTP and HTTPS connections. The server does not keep logs of the traffic that it receives, but it checks all incoming traffic for any malicious requests. The application keeps a record of all changes made by users. Users must log in using their username and password. The server keeps sessions open for 5 minutes and send the sessionID back to the user in clear text.

• The business logic API sits between the application and the database. This piece of software is responsible for the enforcement of business logic as well as the authentication/authorization logic. The API will validate all incoming requests, any malicious or irregular requests will be rejected.

• The database that stores all the login credentials of their customers is stored on a single dedicated MySQL server on premises (i.e. local LAN). All credentials are encrypted before being stored. ABC Hotels does create a backup of this information on a daily basis, but these have never been needed so far. The developers could not get the PHP to MySQL ‘secure connection’ library to work.

• The system administrators keep all the software that is running on the system up to date and patched, something they claim keeps the system well protected.

• The website that uses the SSO system is used by staff and customers to perform online reservations and check-in to the hotel. The staff uses computers in the lobby as well as the staff rooms to connect to the website on the Internet. One of the staff members performs the administration of users and puts every user in the correct group (staff or customer).

• The application is written by an external software company that claims they have implemented controls against the OWASP top 10. The developers provide the code for a release to the system administrator , who then deploys it on the server. The developers do not have access to the servers. The system administrator provides the developers with the log files of the servers upon their request.

ABC Hotel would like a list off all possible threats to their system. Scope: You should only list all the threats to the system components and the interactions between them, insider threats and physical attacks do not fall in the scope of the threat analysis. The purpose of the analysis is to analyze the threats to the SSO, so you should only focus on this, anything else falls out of scope. You may make the following assumptions about the system: 1) The password policy is strong 2) The system uses role-based access control 3) A technical user account is used between the API and webserver

B

Appendix B: An example of the descriptor language used in the Tutamen threat modelling tool

frame name frame description ELEMENT Basic building block of all types in model. Everything is an element.

PROCESS Describes a logical set of executions. Threat model elements are either Processes or Dataflows.

DATAFLOW Describes data or control change within the modelled system.

AUTHN Use this to describe generic identity/authentication security patterns.

AUTHN.METHOD If you know you are going to define a method, but you don’t know which authentication method, use this.

AUTHN.METHOD.OTP This is for One-Time-Passwords.

AUTHN.METHOD.CERTIFICATE This describes the use of certificates for authentication.

AUTHN.METHOD.CHALLENGERESPONSE … Challenge/Response.

AUTHN.METHOD.HMACCHALLENGERESPONSE … HMAC Challenge/Response.

AUTHN.METHOD.BIOMETRIC This is for general biometric identification and may become more granular in the future

AUTHN.METHOD.COOKIE … cookies for authentication.

AUTHN.TOKEN Use this descriptor if you plan to use tokens but have not decided anything specific.

AUTHN.TOKEN.SAML … SAML authentication.

AUTHN.TOKEN.OAUTH2 … Oauth2 authentication use.

AUTHN.TOKEN.OPENIDCONNECT … OpenIDConnect authentication.

AUTHN.PROTOCOL Use this descriptor to define a generic protocol use.

AUTHN.PROTOCOL.EAP .., EAP protocol use for authentication.

AUTHN.PROTOCOL.KERBEROS … this is for using Kerberos authentication.

AUTHZ Use this to describe generic access control/authorization security patterns.

AUTHZ.METHOD This is to define a generic authorization method approach.

AUTHZ.METHOD.ABAC … Asset-based access control definition.

AUTHZ.METHOD.RBAC … Role-based access control definition.

AUTHZ.TOKEN This is for defining token-based authorization.

AUTHZ.TOKEN.SAML … SAML authorization.

AUTHZ.TOKEN.XACML … XACML authorization.

AUTHZ.TOKEN.OAUTH2 … Oauth2 authorization.

AUTHZ.PROTOCOL This is a placeholder for defining authorization protocols.

CONFIG Use this to describe generic application, host, network and system configuration security patterns.

CRYPTO Use this to describe generic cryptographic security patterns.

CRYPTO.INTERFACE Use this to define a generic cryptographic interface model.

CRYPTO.INTERFACE.PKCS11 … for PKCS11.

CRYPTO.INTERFACE.KMIP …. For KMIP.

CRYPTO.PROTOCOL This is for defining a generic cryptographic protocol set.

CRYPTO.PROTOCOL.SSL … for SSL.

CRYPTO.PROTOCOL.TLS … for TLS.

C

Appendix C: The survey presented to the expert panel

C

C

C