Detecting Cyber Security Anti-Patterns in System Architecture Models

(1)

IN

DEGREE PROJECT INFORMATION AND COMMUNICATION TECHNOLOGY,

SECOND CYCLE, 30 CREDITS STOCKHOLM SWEDEN 2021,

Detecting Cyber Security Anti- Patterns in System Architecture Models

VENKATA RAMAKRISHNA CHIVUKULA

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

(2)

Detecting Cyber Security Anti-Patterns in System Architecture Models

VENKATA RAMAKRISHNA CHIVUKULA

Master of Science in Information and Network Engineering Date: January 22, 2021

Supervisors: Wojciech Wideł, Per Eliasson Examiner: Mathias Ekstedt

School of Electrical Engineering and Computer Science Host company: Foreseeti AB

Swedish title: Identifiering av strukturella svagheter i systemarkitekturmodeller

(3)

(4)

iii

Abstract

Organizations across the world have been on the receiving end of large-scale cyber-attacks. Over time, the number and the success of these attacks have grown to a high level. To prepare for these attacks, organizations have to test the resilience of their infrastructures. One way to manage the risk of these attacks and to ensure security is the use of threat modeling. Through threat modeling, organizations can analyze their infrastructure and identify vulnerabilities. The vulnerabilities then have to be patched to improve the overall security posture of the organization. When modeled, these vulnerabilities can occur in different forms. Certain vulnerabilities are specific to certain components in the system. On the other hand, some deficiencies occur in conjunction with multiple assets in the infrastructure. These are called structural deficiencies. Identifying and mitigating these structural deficiencies is very important.

In this thesis, structural deficiencies are described and a catalog of some deficiencies is built through a survey. The deficiencies and the catalog are developed to work with Foreseeti AB’s securiCAD modeling software. Further, a deficiency model is defined that can enable description and search of these deficiencies in securiCAD models. Using the description model, all occurrences of the deficiency can be found. These occurrences then can be replaced with structural improvements. The improved securiCAD models are then tested with simulations. The results from the simulations show that the structural improvements are useful in significantly reducing the Time-To-Compromise (TTC) of important assets. Using the catalog and the deficiency model, system administrators can identify deficiencies and test the effect of different improvements in the securiCAD model which can then be applied to the actual infrastructure.

(5)

iv

Sammanfattning

Organisationer över hela världen har blivit måltavlor för storskaliga cyberat- tacker. Över tid har antalet framgångsrika attacker vuxit till en hög nivå. Som en förberedelse för dessa attacker måste organisationer testa sin infrastrukturs motståndskraft. Ett sätt att hantera risken för dessa attacker och säkerställa säkerhet är användningen av hotmodellering och attacksimuleringar. Genom hotmodellering och attacksimuleringar kan organisationer analysera egenska- perna för informationssäkerhet i sin infrastruktur och identifiera svaga punk- ter. Svagheterna måste sedan hanteras för att förbättra organisationens övergri- pande säkerhetsposition. När de modelleras kan dessa svagheter förekomma i olika former. Vissa är komponentspecifika och lokala till ett objekt i infrastrukturen. Dessa kan hanteras med hjälp av försvar som definieras i securi- CAD. Andra svagheter kan uppstå genom relationerna mellan flera objekt i infrastrukturen. Dessa kallas strukturella svagheter. Att identifiera och mildra dessa strukturella svagheter är mycket viktigt.

I denna avhandling beskrivs strukturella svagheter och en katalog med svagheter har byggts upp. Vidare definieras en modell som möjliggör beskriv- ning av dessa svagheter och möjliggör identifiering av svagheter i securiCAD- modeller. Med hjälp av beskrivningsmodellen kan alla förekomster av bristen hittas. Dessa händelser kan sedan ersättas med strukturella förbättringar. De förbättrade securiCAD-modellerna analyseras sedan. Resultaten visar att de strukturella förbättringarna är användbara för att avsevärt minska Time-To- Compromise (TTC) för viktiga tillgångar. Med hjälp av katalogen och modellen kan systemadministratörer identifiera svagheter och testa effekten av olika förbättringar i securiCAD-modellen som sedan kan tillämpas på den faktiska infrastrukturen.

(6)

Chapter 1 Introduction

1.1 Context

It can be assumed that any network system given enough time will be compromised. This system could be a simple web server or it could be a whole industrial site with thousands of different devices. The validity of this as- sumption is further strengthened by the numerous large scale attacks on infrastructures of both government and private organizations over the past many years (e.g. WannaCry ransomware attack of 2017). The cost of attacks such as WannaCry on the organizations can be huge and it is not always an economic loss – many attacks were recorded on hospitals during the COVID-19 pan- demic affecting the services these hospitals have been performing [1]. When many cyber-attacks are studied, it is revealed that some of them have been performed with the backing of nation-states, sometimes carried out over the duration of many years. From the perspective of the organization, this is a significant problem as developing a perfectly impenetrable defense against an adversary with seemingly unlimited resources and time would require unlimited resources and time. Since this is not feasible, the organization has to study its security posture and bulk up its defense to a reasonable level. “Reasonable level” is an abstract term, and it depends upon various factors. For example, the organizations will have to have redundant servers for essential services since they would have to switch off the servers to update them with the latest security patches. Depending upon the size of the organization and the service this might not be reasonable. Choosing how much resources and time to allocate to cyber security is where risk management comes in.

Risk management broadly includes the study of risk, i.e. events that have a negative impact, the cost of these events, identification of the contributing

1

(9)

2 CHAPTER 1. INTRODUCTION

factors, the process of avoiding or minimizing the effect of these events, and the cost of mitigation. When a service such as a website is considered, a risk from a cyber security standpoint is that it can be a victim of a Denial of Service (DoS) attack. This would lead to the loss of availability of the website and other web services. The direct cost of this loss event would be loss of sales and penalties. There exist services that provide DoS mitigation at a certain cost. The use of such mitigation is then decided while considering the cost of the mitigation itself, the value of the web service to the organization, and the acceptable risk.

Many guidelines can be followed for cyber risk management. One such document is published by The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL), called Risk management framework for information systems and organizations [2]. Such guidelines provide a methodology to integrate security and risk management into the activities of a system development life-cycle. A significant part of these guidelines is the use of threat modeling.

1.2 Threat Modeling

As defined by Uzunov and Fernández [3], “threat modeling is a process that can be used to analyze potential attacks or threats, and can also be supported by threat libraries or attack taxonomies”. Threat modeling typically involves identifying the valuable assets that an organization wants to protect, then identifying as well as prioritizing the vulnerability and attack vectors associated with those assets to address the most likely threats. Threat modeling is effective in finding architectural security flaws and reduce architectural risks [4].

It is then possible to reduce the risk of security incidents through modifying the architecture. However, it is not as useful in cases of specific issues such as bugs in software. Threat modeling can be performed at any time in a systems life-cycle but it is most effective when it is done during the design phase. If performed after the system is already implemented, it is still useful in reducing the risk over time.

There are different approaches to threat modeling but the most popular one is the STRIDE model developed by Microsoft [5]. It is derived from an acronym for the six threat categories: spoofing identity, tampering with data, repudiation, information disclosure, denial of service, and elevation of privilege. Xiong and Lagerström [6] classified the existing threat modeling works into non-mutually exclusive categories of “manual/automatic modeling” and

“formal/graphical modeling”. “Formal modeling” is a method based on math-

(10)

CHAPTER 1. INTRODUCTION 3

ematical models, and “graphical modeling” can be attack trees, attack graphs, or tables.

1.2.1 Attack Trees

Attack trees were popularized by Schneier [7, 8] as an efficient means to describe and analyze system security. Attack trees were then formalized by Mauw and Oostdijk [9] and further extended to also include defenses by Ko- rdy, Mauw, Radomirovic, and Schweitzer [10]. Kordy, Piètre-Cambacédès, and Schweitzer [11] summarize the various attack graph approaches proposed since then. Many tools have also been developed to collect the information about the existing infrastructure and then automatically generate the attack graphs such as “MulVAL: A Logic-based Network Security Analyzer” and

“NetSecuritas: An Integrated Attack Graph-based Security Assessment Tool for Enterprise Networks”.

Essentially, attack trees encode possible paths that an attacker could take when moving through the system to reach their destination. The example using the concept of a thief and a house will be useful to understand this better as shown in Figure1.1. In this example, we can see that the different attack steps are presented in a tree which is an advantage of attack trees since it makes it much easier to understand. Here, the objective for the adversary is to gain access to the house and this can be done in several ways. A simple method would be to break in through the door. The lock on the door can be broken through the use of force. A smarter adversary with the expertise could proba- bly pick the lock. When the house and the neighborhood are considered, then the adversary could either jump down the chimney or maybe steal the spare key from a neighbor with lax security. Further, certain steps have sub-steps that need to be completed. Some of these steps are AND steps where all the sub-steps have to be completed, while some steps are OR steps where any of the sub-steps need to be completed. In this example, to pick the door, the adversary has to identify the lock mechanism and use the tool, but to bypass the door, they have to either pick the lock or use a key that they have obtained (through any other manner).

This is a brief introduction to the concept of threat modeling and it represents a major problem that any system designer has to deal with. The malicious entity has multiple paths to reach the objective and many times the paths are not readily apparent. Many times these paths involve a lot of steps taken in the right manner that the system designer would not be able to predict without a lot of effort. Through the use of threat models such as attack trees, the de-

(11)

Figure 1.1: An attack tree with a graph representing the probability of the attacker breaking in with respect to time

fender can build a list of steps that can be taken by the malicious entity, each of which can be stopped differently by using mitigation measures. The defender has to keep in mind that the attacker will always try to find the easiest way to reach the objective and hence the defenses need to be a response to this. In the example, there would be no sense to upgrade to an unbreakable window when the lock on the door can be easily picked. This is a example of the chain being only as strong as the weakest link.

1.2.2 Time to compromise

Since systems, software and protocols keep changing, these mitigation measures are not perfectly secure forever but the exact time required to compromise a certain defense depends on various factors including the talent and the resources that the attacker has. This introduces time and probability as important factors in the evaluation of the attack steps. Arnold, Hermanns, Pulungan, and Stoelinga [14] highlights the importance of probabilistic timed evaluation of attack scenarios through the use of case studies. In “pwnPr3d: An Attack- Graph-Driven Probabilistic Threat-Modeling Approach”, Johnson, Vernotte, Ekstedt, and Lagerström [15] introduce the pwnPr3d model which presents the attack tree as an edge-weighted directed graph, G = (V, I, E, ω) where:

(12)

• V is a set of nodes that represent the different attack steps,

• I is a subset of V that identifies the starting point of the attacker,

• E is the set of weighted directed-edges that define the possible steps that the attacker can take through the system to reach the objective,

• ω is the weight function used to define the probability distribution over time that a certain attack step is successful.

Here, ω or the weight function provides the important concept of time-to- compromise (TTC). The TTC is drawn from a probability distribution such as exponential distribution, bernoulli distribution, or log-normal distribution, over the time of an attack. A TTC distribution graph provides a way to predict how fast a certain attacker can succeed with a certain attack step through re- peated random sampling from the probability distribution. Once the weights of the edges are assigned using the weight function, a shortest path algorithm can be used to predict the path an attacker might take to reach their objective.

When the TTC of all the steps in an attack path are combined, a global TTC is obtained. The purpose of different mitigations would then be to help increase this global TTC value by reducing the probability success of the attack step with the lowest TTC.

The mitigations used to increase the TTC can be quite varied, from adding simple rules to a firewall to restrict the movement of certain kinds of data traf- fic to using complex software to study the data and stop anomalous data from passing through. Some mitigations target specific vulnerabilities or deficiencies, which affects just a single component. These mitigations will be referred to as defenses for the rest of this work. For example, when Address Space Layout Randomization [16](a technique used to harden a system against mem- ory corruption vulnerabilities) is used on a host to help fortify against buffer overflow attacks, it only affects the particular host. On the other hand, some deficiencies occur in conjunction with multiple components of the infrastructure and will be called structural deficiencies for the rest of this work. These structural deficiencies are more complex and might require the restructuring of the infrastructure to mitigate. For example, implementing Multi-Factor Au- thentication(MFA) requires the addition of components to store and verify the additional security factors. Such mitigations will be called structural improvements and this study will concentrate on identifying and implementing these.

Since these structural improvements are more complex, they are tougher to identify and implement, but they can be said to occur in form of patterns and

(13)

anti-patterns. Understanding patterns and anti-patterns will help in further understanding structural improvements.

1.3 Patterns

The concept of patterns in software engineering has existed since 1995. They are used in various areas such as software architecture, parallel programming, and security. A pattern in software development is a description of a recurring problem and its corresponding successful solution [17]. Once a pattern is identified, it can be described in different languages, such as UML. Secu- rity patterns are well-understood solutions to recurring security problems [18].

Security patterns provide a way to capture the expertise and experience of security experts and make it easier to develop more secure systems. Over the years, a number of security patterns have been identified, visualized and classified [17,18].

Security patterns are used as a guide in the security design as a response to attack patterns [19] and misuse patterns [20]. Attack patterns are a way to describe the steps to perform a specific security attack in a generic manner while misuse patterns describe a generic attack performed using platform or software-specific vulnerabilities. Security patterns as a whole are not very generic and many times they do not have a direct impact on the architecture. A more general type of security pattern was proposed by Uzunov and Fernández called threat patterns along with a threat taxonomy to describe them. Accord- ing to Uzunov and Fernández [3], “The relationship between threat patterns and attack/misuse patterns mirrors the relationships between threats and attacks more generally, i.e. attacks realize threats by exploiting vulnerabilities on assets”.

1.4 Anti-pattern

On the other hand, anti-patterns in software development, as first introduced by Koenig [21], are said to occur when certain solutions to commonly occurring problems tend to be ineffective and sometimes counter-productive. Anti- patterns were further extended to refer informally to any commonly reinvented but bad solution to a problem by Brown, Malveau, McCormick III, and Mow- bray [22]. In the field of IT infrastructure, the National Cyber Security Center, which is part of the Government Communications Headquarters (GCHQ) of the UK, published a white paper, Security architecture anti-patterns [23]. It

(14)

suggests various commonly occurring system designs that should be avoided.

Solutions to these anti-patterns are developed after considering factors such as the real-world performance of the components that are part of a secure system.

One such anti-pattern is the use of back-to-back firewalls. A common myth among system designers is that implementing back-to-back firewalls, sometimes from different vendors, with the same set of controls, helps prevent intrusion. This is based on the notion that the existence of the same vulnerability in two different products will be low and as such having two firewalls will prevent vulnerabilities from being exploited. According to Crowther [23], it is observed that two firewalls contribute more to the increase of overhead and maintenance rather than to overall security. Gartner [24] published a report on statistics of attacks on firewalls. It was found that 95% of these attacks oc- curred due to misconfiguration and not due to a vulnerability in the firewall itself. Also, expertise for both systems has to be maintained and both systems have to be patched regularly. Only in cases of a contractual interface between two independent parties is it ever useful.

The previous example demonstrates how structural deficiencies occur. The individual components in the example might be free of any vulnerabilities, but when used in conjunction they introduce deficiencies into the system. In the example here, having two firewalls might increase the time required to patch them and might expose the infrastructure to vulnerabilities for longer. These structural deficiencies are therefore tougher to find since any method to find these structural deficiencies has to consider the connected components, the privilege (i.e. security access level) of the components, and the use of the components as well. Organizations have to be able to detect these structural deficiencies to keep their assets and operations secure.

When security failures of organizations as a whole are considered, they can be summarized into four issues [25]:

• Over-reliance on intuition to make security decisions: Due to the absence of reliable statistics of cyber-attacks, security decisions have to be made using experience and intuition. This leads to biased and sub- optimal decisions.

• Leaving cracks in the security foundation: Basic security controls are absent in many organizations and allow for attackers to easily penetrate the defenses. For example, collecting logs but not analysing them or protecting them from tampering.

• Over-reliance on knowledge versus intelligence: Security operations are developed around static and generic knowledge within products and not

(15)

updated frequently such as not studying the tools that attackers are using currently. This allows for advanced attacks to remain undetected for longer.

• Weak security governance: Access control for different users is unde- fined or unclear and allows for systemic gaps and vulnerabilities. Espe- cially when provisioning administrative rights to users who do not need them for their regular work.

1.5 Research Questions and our Contribu- tions

In this work the following research questions have been tackled.

• RQ-1: What are some common structural deficiencies in IT infrastructures and what are the best practices for security improvements?

• RQ-2: How should structural deficiencies and their improvements be represented such that the former could be automatically identified in models, and the latter automatically incorporated in models?

The contributions of this work are as follows.

To answer the first question, a literature study of existing works was done and several deficiencies were identified. These deficiencies were then categorized into local and structural. A list of best practices was built corresponding to each of these deficiencies using different studies. The ease of implementation of each of the improvements is also considered.

The second involved describing the infrastructure model and the deficiencies in the form of graphical models. Once described as graphical models, a search and replacement algorithm was written to replace the deficiencies from the infrastructure model. The main purpose of this thesis was to devise a methodology to programmatically identify and implement mitigations in a securiCAD model.

1.6 Ethics and Sustainability Aspect

The simulations performed in this work do not require large amounts of com- puting power. So this work does not significantly affect the energy consump-

(16)

tion of an organization, especially when compared to other hardware used in the IT infrastructure. It can be argued that ensuring better security helps in achieving the UN Sustainable Development Goals [26] faster. Goals such as Goal 7: Affordable and Clean Energy; and Goal 11: Sustainable Cities and Communities are involved with the use of information and communication technologies that need to be resilient to cyber attacks. Affordable and Clean Energy could be achieved with the use of technology to monitor and control the energy generation to make it efficient and these become a target for cyber attacks. Similarly, Sustainable Cities could require the use to technology to monitor the consumption of energy. This generates a lot of sensitive data regarding the energy use of different people. This data has to be kept secure.

The biggest impact of this work is in regards to ethics and privacy. Using tools like this, organizations can ensure that their users data remains confiden- tial and that their work is not affected. As mentioned previously, there have been cyber attacks that target hospitals [1]. Such attacks could directly lead to death of patients due to downtime of critical systems. The focus of this work will reduce the effectiveness of cyber-crime in the long run. If there is less cyber-crime, it will keep everyone safe in the increasingly internet connected society.

1.7 Thesis Outline

Chapter 2 introduces the model used to describe and search for deficiencies.

Chapter 3 overviews the process of building the catalog. Further, a brief catalog will be presented.

Chapter 4 describes the deficiencies using the model. Further, the result of the replacement is discussed.

Chapter 5 summarizes this study.

(17)

Chapter 2 Preliminaries

2.1 securiCAD

This work was performed using foreseeti’s securiCAD¹. securiCAD is an enterprise cybersecurity management tool. It is a CAD tool in which the IT infrastructure can be modeled in a drag-and-drop manner and/or through im- porting data from other tools such as network scanners. The tool can then generate a “heat map” of the location where the infrastructure is more or less vulnerable, based upon the vulnerability data built up by foreseeti [27].

The models built in securiCAD will consist of assets such as Hosts, Data- stores, and Routers among many others. The assets will further be connected using associations that occur in various forms according to the assets that are being connected, such as Authentication, Authorization, and Communication.

Each of these assets has certain properties such as attack steps, defenses, tags, and object details. The attack steps represent all the possible attacks on that asset, their cost, and the consequences associated with it. Each type of attack has local TTC which is configured by default by forseeti, but it can be changed to other forms as required. Each asset also has defenses assigned to it and the defenses can be assigned a probability value between 0 and 1. For example, a host in securiCAD has attacks like ARPCachePoisoning, BypassAntiMalware and it has defenses like AntiMalware, HostFirewall, StaticARPTables.

Figure2.1represents securiCAD loaded with a model and its simulation.

The model will also consist of assets that will be used to mitigate vulnerabilities, such as firewalls, protocols (used to encrypt a dataflow), and intrusion

1https://www.foreseeti.com/securicad-professional/

10

(18)

CHAPTER 2. PRELIMINARIES 11

Figure 2.1: securiCAD

(19)

12 CHAPTER 2. PRELIMINARIES

prevention systems (IPS)².

The attacker is also an asset that is connected to other assets to simulate the access that the attacker might begin with. It could be an attacker approaching from the internet or an attacker having physical access to a host in the infrastructure. The attacker can also be assigned properties and the level of threat the attacker poses through profiles such as Script Kiddie or Advanced Persistent Threat. The attacker is then simulated to move through the network making use of various vulnerabilities to reach the key assets, i.e. assets that need to be secured the most. The key assets are represented as having a consequence value set to something higher than 0. The consequence value is used to represent the impact if an attack step on that asset is reached. The consequence value can be set in the range of 0 to 10 where 0 represents no impact while 10 represents maximum impact.

2.2 Simulation Results

The simulation run with securiCAD is based on probabilistic simulation in attack graphs. This involves the calculation of the average TTC for each attack step for each asset based on what defenses has been implemented in the asset.

The simulation requires two values as inputs. One is the number of samples.

Since the success of an attacker at each attack step in a sequence is determined by a given probability. Simulating the attacker multiple times generates different results. Averaging the results for different samples, helps in getting a stabilized result that is representative of an average attacker. The other is the TTC infinity threshold value. The TTC infinity threshold value sets the limit where securiCAD will stop following an attack path. If an attack path takes more than the set value, it is assumed that the attack path is not feasible.

The simulation then proceeds to calculate the result and generates a report.

One figure that is generated is the TTC for different attack steps for all the assets. This figure is a graph between the success rate of the attack to time. The shape of the graph represents if the success of the attack scales linearly with time or if its exponential. For example, in Figure2.2, it can be seen that the max success rate within the period of the simulation is under 70% for both assets, but for one asset the success rate rises exponentially at the beginning while for the other asset the success rate rises linearly in the beginning. The different shape of the graphs have different implications that need to be con-

2The list of all assets, their defenses, and their associations can be found at https://docs.foreseeti.com/docs/securilang-reference

(20)

(a) Asset 1 (b) Asset 2

Figure 2.2: An example of the TTC graph for assets in an example model

sidered when threat modeling.

Other results include the critical path graph and the choke point graph.

The critical paths show the different attack steps an attacker is most expected to use to reach the key asset. The graph of the choke points shows the assets in the architecture that the attacker exploited or traversed most frequently in the simulation to reach the key assets. The width of the choke point indicates the frequency of the asset in the attack paths. The wider the choke point the more frequently it is present in successful attacks.

Once a securiCAD result is generated, it has to be studied for rectifying the identified vulnerabilities. securiCAD suggests some mitigations based on the available defenses. These mitigations are limited by the defenses that a certain asset has been designed with. There is a requirement for being able to identify structural deficiencies and suggest structural improvements. This requires being able to define the deficiencies and this can be done through formalization of the infrastructure model and deficiency model.

2.3 Formalization

Searching for security patterns in the infrastructure allows for detecting deficiencies but in pattern-oriented modeling, most patterns are specified using informal and semi-formal approaches, such as natural languages and other graphical notations [28]. Through the use of a formal model, the infrastructure and its deficiencies can be described in an unambiguous manner. Once the infrastructure has been modeled, deficiencies can be searched for easily.

Many formal specification languages are already available in literature such as [29,30]. Konrad, Cheng, Campbell, and Wassermann [29] proposed the use of security pattern templates for defining security patterns as an extension of

(21)

the design patterns proposed by Gamma, Helm, Johnson, and Vlissides [17].

The security pattern template included additional information such as behav- ior, constraints, and related security principles. The addition of this information addressed the difficulties inherent to the development of secure systems.

Bayley and Zhu [30] proposed a meta-modeling approach to the formalization of design patterns. Through their approach they are able to capture both structural and behavioral features and support the use of automatic tools for applying patterns. In both these formal models, the patterns are described in a high level that makes it difficult to implement in a tool that is more low level like securiCAD. So there is a need for a securiCAD specific model that allows for description of both the infrastructure and the deficiencies and also to enable for search of deficiencies in the infrastructure in an automated manner.

2.4 Infrastructure model

In this study, a modeling framework is presented for the search of structural deficiencies in securiCAD models. In the framework, the infrastructure of the organization is presented as an undirected graph with the different assets being represented as nodes and the connections between them represented as edges.

The properties and rules for the different nodes and edges are inherited from the securiCAD models.

Denoting the sets of all of the securiCAD’s assets, associations and defenses by SecLangAssets, SecLangAssocs and SecLangDef enses, respectively, we formalize securiCAD’s infrastructure models as follows.

Definition 1. An infrastructure model is a tuple (V, E, asset, association, de- fense, name), where

• (V, E) is a simple graph with nodes representing objects and edges rep- resenting links between the objects,

• asset : V → SecLangAssets is a function, returning for a node in V the asset that the node is an instance of,

• association : E → SecLangAssocs is a function returning for an edge in E, the association that the edge is an instance of,

• def ense : V × SecLangDef enses → [0, 1] is a function returning for a node in V and the defense, the probability of the defense being functional,

(22)

• name is a function that returns the assigned name of the object.

Figure 2.3: An example model of IT infrastructure with different assets and associations between them

Example 1. This is an example of a model for an IT infrastructure network as shown is Figure2.3. Some of the assets have been hidden to make it easier to understand. For example,

• V = {1, 2, 3, 8, 18, 29, 36, 39, 43, 53, 60, ...},

• E = {(1, 2), (2, 3), (3, 43), (3, 36), (3, 60), (2, 29), (1, 18), ...},

• asset(1) = N etwork,

• asset(2) = Router,

(23)

• association(1, 2) = Connection,

• name(1) = Of f ice,

• def ense(1, DN SSec) = 0,

• def ense(1, P ortSecurity) = 0.5.

2.5 Description of deficiencies

securiCAD implements mitigations in the form of defenses on a single component. These defenses affect that single component alone and are aimed to decrease the probability of a specific attack step from occurring. On the other hand, a structural deficiency is any deficiency that cannot be fixed by increas- ing the probability of a defense being functional on a single component. The foremost example to use for identifying a deficiency is the absence of Multi- factor Authentication (MFA). Any service that is accessed through any form of authentication is limited in security by the security of the authentication mechanism itself. A physical card used to gain access is only as secure as the person it is assigned to. If the person misplaces the physical card or keeps it in a location from where it can be easily stolen, then this authentication can be easily compromised. Similarly, passwords can be stolen if they are written down somewhere or if the person reveals it to someone else. Authentication can be broadly categorized into three types: Knowledge, ownership, and in- herence factors, i.e. the user knows something, has something, or is something (fingerprints, retina, etc.) respectively. Multi-factor Authentication (MFA) is the use of a combination of these categories since compromising more than one of these mechanisms is exponentially tougher.

So the MFA deficiency can be found by searching through the architecture and finding any access control mechanisms that do not have more than one form of authentication used. Then a second form of authentication has to be added and also the data relevant to this authentication has to be stored somewhere. This involves adding components and changing the connections of different parts of the infrastructure. Hence, this will be classified as a structural deficiency and not a local deficiency.

In a securiCAD model, this deficiency will be in the form of an AccessCon- trol Asset connected to one or more UserAccounts through Root Authorization or Non-root Authorization. These UserAccounts are then further connected to only one Keystore through an Authentication connection. Here, when the attacker is simulated, to gain access the attacker has to compromise just a single

(24)

Keystore. If the UserAccount is connected to two or more Keystores and the Multi-Factor Authentication defense is enabled, the attacker has to compromise all the Keystores that the UserAccount is connected to to successfully compromise the AccessControl.

This is a description in a human-understandable language. This will be defined in a form such that it fits into the infrastructure model and can be used in an algorithm to search through the model using the deficiency model.

Definition 2. A deficiency in a model (V, E, asset, association, def ense, name) is its submodel, i.e.,

a model (V⁰, E⁰, asset, association, def ense, name) satisfying V⁰ ⊆ V and E⁰ ⊆ E.

Example 2. The MFA deficiency in a model (V, E, asset, association, defenses, name) could be defined as a deficiency (V,’ E’, asset, association, defenses, name) satisfying the following conditions:

• V⁰ = {v₀, v₁, . . . , v_n, v_n+1} for some n ∈ N, n ≥ 1,

• asset(v0) = AccessControl,

• asset(vⁱ) = U serAccount for i ∈ {1, . . . , n},

• asset(vn+1) = Keystore,

• (v0, v_i) ∈ E and association(v₀, v_i) = N on − RootAuthorization for i ∈ {1, . . . , n},

• (vⁱ, v_n+1) ∈ E and association(v_i, v_n+1) = Authentication for i ∈ {1, . . . , n},

• and for every vn+2 ∈ V satisfying (v_i, v_n+2) ∈ E for i ∈ {1, . . . , n} it holds that either,

– asset(vn+2) 6= Keystore or,

– there is i ∈ {1, . . . , n} such that association (vi, vn+2) 6= Authentication, or else

– there is i ∈ 1, . . . , n such that def ence(vi, M F A) = 0.

(25)

2.6 Structural deficiencies vs defenses

Security mitigations are quite varied across different platforms. Certain security mitigations can be implemented on a single device while some are implemented across the whole network, such as IPS. Some security implementations are softwares that are installed on systems while some are standalone hardware devices.

This variance makes it difficult to categorize these security mitigations into local defenses and structural improvements. Defenses such as ASLR can definitely be cataloged as local defenses, similarly, network segmentation can be cataloged as structural improvements quite easily. While mitigations such as IPS are difficult to be categorized. On the whole, the classification of the mitigations is dependent upon how the assets and mitigations are modeled in the threat modeling language. The threat modeling language provides a way to model the relevant parameters and the attack logic of a system. It is built after collecting a lot of data regarding the system architecture and analyzing it.

For the purpose of this project, the distinction is dependent on how a mitigation or the assets involved are implemented in securiCAD. In securiCAD, Access Control, Firewall, IDS, IPS, Physical Zones, Protocol, Web Applica- tion Firewalls, and Zone Management are implemented as independent components. Based upon this, any security mitigation that requires the addition of these components to the existing infrastructure model will be considered a structural change. Further, any change that involves two or more components will also be considered structural, if it involves adding, removing, or moving the links between the components. Keeping this in mind, a catalog was formed which will be presented in Chapter3.

(26)

Chapter 3 Catalog of Structural Deficien- cies

3.1 The catalog

Comprehensive threat modeling requires proper knowledge of a system’s architecture and its technical domain. Further, expertise in security of the system is required to be able to recognize both generic and specific attacks. Accord- ing to Dhillon [4], a threat taxonomy that contains the common deficiencies in an architecture can greatly increase the effectiveness of the threat modeling process. However, most taxonomies such as STRIDE or ENISA Reference In- cident Classification Taxonomy¹are at a very high level of abstraction and are not appropriate for threat modeling or are only relevant in specific contexts.

Catalogs such as MITRE ATT&CK²intend to classify adversarial behaviors.

These are useful to study the attacks that might occur, but they do not provide a methodology for defensive measures that can be taken.

In Chapter 2, a formal definition of a model for the identification of deficiencies was proposed. This chapter presents a basic catalog of deficiencies that can be expressed in the model form such that they can be searched for. Multiple organizations across the world suggest various best-practices and publish different reports of the state of security each year, some reports are published every quarter [31,32]. Using some of these suggested best practices, most notably the ones described in Crowther [23], along with some of the suggested mitigations from securiCAD, a rudimentary catalog is built.

The focus of this catalog is upon deficiencies that can be implemented in

1https://www.enisa.europa.eu/publications/reference-incident-classification-taxonomy/

2https://attack.mitre.org/matrices/enterprise/

19

(27)

20 CHAPTER 3. CATALOG OF STRUCTURAL DEFICIENCIES

securiCAD. According to the ease of implementation, the structural improvements in the catalog are divided into three types. Type 1 improvements require minimum addition of assets, Type 2 require addition of a few assets and adding a few defenses and the Type 3 improvements require addition of a few assets along with changes to the original assets to make sure existing infrastructure is not affects. These are explained in detail in the following sections.

(28)

CHAPTER 3. CATALOG OF STRUCTURAL DEFICIENCIES 21

STRUCTURALDEFICIENCIESSTRUCTURALIMPROVEMENTS Type1 AbsenceofintrusionpreventionAddIPS AbsenceofintrusiondetectionAddIDS PlaintextcommunicationEncryptDataflows AbsenceofWebApplicationFirewallAddWebApplicationFirewall Useofweakpasswords Unknownassets/users/servicesonthenetworkAddZoneManagement IrregularpatchingofvulnerabilitiesAddFirewalltoRouter EasyaccesstocriticalassetsType2 AbsenceofMFAUsemulti-factorauthentication ManagementBypassRestrictManagementandDataPlanecommunication Separatecredentialsandmanagementsystemsfordifferentzones Type3 Redundancyforcriticalinfrastructure NetworkSegmentation BrowseupforadministrationBastionhost Usehostwithlesspriviledgeforriskyactivity SocialEngineeringScoringbasedadministrativeaccess BacktobackfirewallMergethefirewallsintoone InsecureThirdpartyaccessforsupportIsolatedsystemsforthirdparties Just-in-timeapproachforthirdpartyadminaccess

Figure 3.1: Structural Deficiencies and Improvements

(29)

3.1.1 Type 1 Improvements

This type covers the most basic of the structural improvements that can be implemented. These deficiencies require the addition of a security asset to be mitigated (see Figure3.1).

The absence of intrusion prevention and detection systems requires the addition of these systems in the infrastructure, which are represented by the individual assets; IDS and IPS in securiCAD. The IDS asset is added to Host, Dataflow, and Router assets; and the IPS asset is added to Dataflow and Router assets (see Figure3.2a,3.2b).

A common deficiency is the presence of known vulnerabilities in assets present in the network or the presence of foreign assets, services, or users in the network. Similarly, the use of weak passwords is another deficiency. Ac- cording to Tripwire [33], 27% of survey participants said their employer had suffered a data breach as the result of an unpatched vulnerability and 47% said they take at least days to detect new hardware or software on the network. To mitigate these deficiencies, it is required that a zone represented by a network, be managed. A zone is said to be managed when standard procedures or rou- tines exist to ensure that available patches are applied to assets in the network, passwords are sufficiently strong, and to check that there are no foreign assets, services, or users on the network. In securiCAD, this is represented in an asset known as ZoneManagement. Adding ZoneManagement asset to the Network asset is a way to represent that these deficiencies have been mitigated (see Figure3.2c).

Similarly, plaintext communication on a network is also a deficiency, according to CyberX [31], 69% of networks have plain-text passwords traversing the network which makes cyber-reconnaissance and subsequent compromise relatively easy. The mitigation to this vulnerability would be to encrypt all communication. This is modeled as adding the Protocol asset to Dataflows and setting the defenses on the Protocol (see Figure3.2d). The Dataflow asset represents the different data communication that occurs and Protocol represents the protocol of the data communication, with further defenses representing the level of protection through the use of encryption and authentication.

Another deficiency is allowing unmonitored access to critical web services through the absence of web application firewalls, i.e. web services are open to attacks from malicious users. This can be mitigated by having a web application firewall. This mitigation is represented as associating a WebApplication- Firewall asset to a WebApplication (see Figure3.2e). A similar well-known deficiency is allowing unmonitored access to critical assets, which is mitigated

(30)

(a) IDS asset associated to Host, Dataflow, and Router assets

(b) IPS asset associated to Dataflow and Router assets

(c) ZoneManagement asset associated to Network asset

(d) Protocol asset associated to Dataflow asset

(e) WebApplicationFirewall asset associated to We- bApplication asset

(f) Firewall asset associated to Router asset

Figure 3.2: Type 1 Improvements for Deficiencies

(31)

(a) AccessControl without MFA

(b) AccessControl with MFA

Figure 3.3: Type 2: Occurrence of the MFA Deficiency and its improvement

by adding a firewall to the network (see Figure3.2f). This is represented in securiCAD as associating a Firewall asset to a Router. Another mitigation to this deficiency is to have network segmentation which is addressed in Type 3.

3.1.2 Type 2 Improvements

The more complex structural deficiencies and their improvements require larger changes to the infrastructure when modeled in securiCAD such as adding more than one asset and changing the associations between multiple assets.

A fundamental deficiency that can be categorized as Type 2 is the absence of MFA. This deficiency occurs when the authentication mechanism is not ro- bust enough as explained in Chapter2. This deficiency is represented as Ac- cessControl assets that are connected to UserAccounts which have only one Keystore associated with them. This deficiency is mitigated by adding multiple factors of authentication to the authentication mechanism. This is represented as adding an association from the UserAccounts to another Keystore asset. This ensures that the AccessControl is providing authorization to User- Accounts that have Authentication association to at least two Keystores (see Figure3.3a, 3.3b). Further, the MFA defense on the UserAccount has to be turned on. This ensures that the Attacker has to compromise all the Keystores that the UserAccount is associated with to pass through the AccessControl.

Management bypass [23] is a deficiency arising when a user with administrative access has access to different devices from different security zones.

This creates a bypass for the attacker to move from a fringe device in a lower security zone to the management interface to a device in a higher security zone.

(32)

If the attacker is able to do this, then they are bypassing other security mechanisms to gain access to the key assets. There are two mitigations for this. One is to restrict data plane and control plane communication. This is achieved by isolating Networks with an Administration association to a Router. When such a Network is identified, it should be made sure that it does not have a Con- nection association to any other Router. Similarly, any Host connected to this Network, should not be associated with any other Network that has a Connec- tion association to a Router. If such a Host is found, then the association has to be removed. To maintain access for the User, a new set of UserAccount, Ac- cessControl, and their respective associations have to be created. Figure 3.4 represents how the deficiency occurs and its mitigation. In the Figure 3.4a, the Host 1 provides a link between the administration network Network 1 and the communication network Network 2. This provides an opportunity for the Attacker to compromise Router 1 through its administration network. This is avoided in Figure 3.4b, since there is no direct link between Network 1 and Network 2. To maintain the access of the User, new UserAccounts and Hosts have been created such that the user can still access both the networks. It has to be noted that this kind of change will affect other services associated with the user of the host.

Another mitigation is to use different credentials for different security zones such that compromise of keys from one zone does not affect the other zones.

This can be represented in securiCAD as the same AccessControl being used for hosts, routers, or services in the same security zone, particularly when it has a Root-Authorization association to an UserAccount. If the AccessControl or the UserAccount is associated with assets in a different security zone, then a new UserAccount and AccessControl asset have to be created such that the User is now using different UserAccounts for different security zones.

(33)

(a) Data Plane and Control Plane communication from same host

(b) Data Plane and Control Plane divided into different hosts

Figure 3.4: Type 2: Management Bypass deficiency

(34)

(a) Same credentials in different security zones

(b) Different credentials in different security zones

Figure 3.5: Type 2: Management Bypass through common credentials

(35)

3.1.3 Type 3 Improvements

The final type of deficiencies are those that involve assets that serve more than one purpose. The improvements to these deficiencies can technically be implemented but there is no guarantee that all components of the system will remain functional. It would require adding additional input to the model regarding each asset or each improvement. This means that the improvement has to be studied manually such that no dependent systems are broken.

An example of this deficiency is the unpatchable system [23]. In this deficiency, a system exists that is so critical that it cannot suffer any downtime.

In this situation, the system is not allowed any downtime for patching vulnerabilities. To mitigate this situation, a redundant or backup system has to be implemented. This can be modeled as having redundant assets which are connected in parallel, but it would not be possible without manually identifying critical assets that have to be online at all times. Further, if redundancy has to be implemented, then a lot of Dataflows, Services, and other assets might have to be duplicated.

Similarly, network segmentation is another structural improvement that is heavily dependent upon the infrastructure already implemented. Further, the structure of the assets might have to comply with any regulations that the organization has to follow such as Payment Card Industry Data Security Standards (“PCI DSS”).

Another deficiency is the use of a less trusted/secure device to access and administer a more trusted network, also known as browsing up, through the use of a remote desktop or remote shell [23]. A mitigation in this situation is to use an intermediary such as a bastion host or a jump box (a host specifically configured to withstand attacks) as a way to reduce vulnerability. This helps to reduce the number of exposed protocols and monitor the actions being performed. However, it does not increase the confidence that only the authorized person is using the bastion host. The less trusted device could have been compromised along with its credentials. One of the mitigations for this deficiency is to change this into a browse down, i.e. include the administration device as in the trust zone and if the same device is to be used for risky activities such as web browsing or email, it should be done through a remote host or a vir- tual environment. The improvement would be modeled similar to the division of data plane and control plane communication, but the identification of this deficiency in the infrastructure model would require more information than present in the model.

Certain deficiencies can be mitigated through the use of both defenses and

(36)

structural improvements, e.g. Social Engineering. Social Engineering can be mitigated through the improvement of the Security Aware defense on the User.

In the real world, it refers to the users being aware of the need for security practices and following these rules. Beyond a certain point, it is impossible to make sure that all employees have perfect security awareness. According to MediaPRO [32], “Employees in management roles or above showed riskier behaviors than entry- or mid-level employees”. This requires a more complex approach that measures the closeness of users to key assets and using a scoring mechanism to measure users’ security awareness and then assigning minimum required scores for different assets.

Another deficiency is the use of back-to-back/multi-vendor firewalls (explained in Chapter1). Mitigating it requires the removal of redundant firewalls and merging them into one. This is difficult to identify since it cannot be modeled directly in securiCAD. It could be modeled as two Firewalls with different names connected to an empty Network with no other connections, but it again depends upon more context being present to reliably be identified.

The last deficiency included in the catalog is granting unmonitored access to third parties to assets for support or administrative purposes. According to Sangster [34], 44% of firms in the survey by eSentire had a significant data breach caused by a vendor, even though most organizations had some formalized third-party policies. A relevant mitigation [23] would be to have isolated third party access systems and to have a just-in-time administrative approach such that remote administrative access is only granted when external support is required, for example, granting access only when a support ticket is being worked upon.

3.2 Conclusion

The catalog provides a starting point for searching for deficiencies and replac- ing them with improvements. The deficiencies can be searched for using the model as described in Chapter2. The search for the deficiencies will be further expanded in the next chapter.

(37)

Chapter 4 Structural deficiencies as graphs

In this Chapter, the different structural deficiencies identified in Chapter3will be described using the deficiency model described in Chapter2. Then the result of using these descriptions to find the deficiencies and apply the improvements in an example model are studied.

4.1 Deficiencies expressed as models

A deficiency (V’, E’, asset, association, defense, name) in a model (V, E, asset, association, defense, name) is the

IDS absent deficiency if

• V⁰ = {v₀},

• asset(v⁰) = {Dataf low, Host, Router},

• and for every v1 ∈ V satisfying (v0, v₁) ∈ E it holds that asset(v1) 6=

IDS.

IPS absent deficiency if

• V⁰ = {v0},

• asset(v⁰) = {Dataf low, Router},

• and for every v1 ∈ V satisfying (v0, v₁) ∈ E it holds that asset(v1) 6=

IP S.

30

(38)

CHAPTER 4. STRUCTURAL DEFICIENCIES AS GRAPHS 31

Plain text communication deficiency if

• V⁰ = {v₀},

• asset(v0) = Dataf low,

• asset(v¹) = P rotocol,

• (v0, v₁) ∈ E,

• and for every v1 ∈ V satisfying (v0, v₁) ∈ E, it holds that def ense(v1, Authenticated) = 0, and def ense(v¹, Encrypted) = 0, and def ense(v¹, N once) = 0.

ZoneManagement absent deficiency if

• V⁰ = {v₀},

• asset(v0) = N etwork,

• and for every v¹ ∈ V satisfying (v⁰, v1) ∈ E, it holds that asset(v¹) 6=

Zone M anagement.

Firewall absent deficiency if

• V⁰ = {v₀, v₁},

• asset(v0) = Router,

• and for every v¹ ∈ V satisfying (v0, v₁) ∈ E it holds that asset(v1) 6=

F irewall.

MFA absent deficiency if

• V⁰ = {v₀, v₁, . . . , v_n, v_n+1} for some n ∈ N, n ≥ 1,

• asset(v⁰) = AccessControl,

• asset(vi) = U serAccount for i ∈ {1, . . . , n},

• asset(vn+1) = Keystore,

• (v⁰, vi) ∈ E and association(v⁰, vi) = N on − RootAuthorization for i ∈ {1, . . . , n},

(39)

32 CHAPTER 4. STRUCTURAL DEFICIENCIES AS GRAPHS

• (vi, v_n+1) ∈ E and association(vi, v_n+1) = Authentication for i ∈ {1, . . . , n},

• and for every vn+2 ∈ V satisfying (vi, v_n+2) ∈ E for i ∈ {1, . . . , n} it holds that either,

– asset(v_n+2) 6= Keystore or,

– there is i ∈ {1, . . . , n} such that association (vi, v_n+2) 6= Authentication, or else

– there is i ∈ 1, . . . , n such that def ence(vi, M F A) = 0.

Management Bypass deficiency 1 if

• V⁰ = {v0, v1} ,

• asset(v0) = N etwork,

• asset(v1) = asset(v₂) = Router,

• (v0, v₁) ∈ E and association(v0, v₁) = Administration,

• for every v² ∈ V satisfying (v0, v₂) ∈ E and asset(v2) = Router, it holds that association(v0, v₂) = Connection.

Data plane and control plane communication combined - II

• V⁰ = {v₀, v₁, v₂},

• asset(v0) = Host,

• asset(v¹) = N etwork,

• asset(v2) = Router,

• (v0, v₁) ∈ E and association(v0, v₁) = Connection,

• (v¹, v2) ∈ E and association(v¹, v2) = Administration,

• for every v3, v₄ ∈ V ,

• satisfying (v0, v₃), (v₃, v₄) ∈ E, and asset(v3) = N etwork ,asset(v4) = Router, it holds that association(v³, v4) = Connection.

(40)

4.2 Implementation

In securiCAD, the models are stored in the XML format. Using Python and the ElementTree API, the model can be described in form of a graph. Simi- larly, the deficiencies and the improvements can also be described in form of graphs. This reduces the problem of searching for deficiencies into a problem of searching for sub-graphs in a graph. This problem has already been solved and in this project, the networkx package is used for this purpose.

There are a few assumptions made during the improvements step. One is that it is assumed that if any improvements are done, they will be performed completely and as such any assets added during this step will have all the defenses turned on. The second is that since the cost of implementation is not considered at this point, all the required improvements are applied across the network, for example, in the addition of IPS, it is assumed that the IPS is added to all the assets that can be associated to an IPS. All the simulations are run with 5000 samples and a TTC infinity threshold value of 200.

The implementations are performed mainly on the example model available in securiCAD. The example model represents the infrastructure of a standard office. The example model has two key assets (assets with a star in Fig- ure 2.3), the Host Stage srv 2, and the Datastore Customer records. The At- tacker has access to the Host Workstation 1 through the attack step Compro- mise. The Host Stage srv 2 has an attack step Compromise with a consequence set to 5. The Datastore Customer records has an attack step Write with a consequence set to 8. Further, the defenses are already set to certain values that would be most commonly found in the infrastructure of this kind.

(a) Stage srv 2 Compromise (b) Customer records Write

Figure 4.1: The TTC for the key assets in the example model

(41)

4.3 Results

The example model already has firewalls associated with the routers and the dataflows have already been encrypted so no Protocol asset was added. Fur- ther, it does not have any web applications so web application firewalls cannot be added to this model. The simulation with the model in this state and the results for the two key assets are generated. In Figure4.1, the empirical distribution functions of the global TTC for the compromise steps on the assets are plotted. For example, for the Host Stage srv 2 asset, the probability that the asset will be compromised within 40 days is 67%.

(a) The default model

(b) 11 IDS added to various assets

Figure 4.2: The choke points diagram in the default model and the model with IDS added

(42)

4.3.1 Type 1 improvements

The different Type 1 improvements were applied individually and the results obtained were studied. In the example model, the absence of IDS was found at 11 assets, the absence of IPS was found at 2 assets and the absence of Zone- Management was found at 4 assets. In most of the cases, the improvements did not affect the TTC of the key assets significantly. This can be explained since every improvement tackled only one deficiency at a time, it still left other paths for the attacker to reach the key assets. This can be observed when the chokepoints graph generated in the securiCAD report is analyzed. Figure4.2 represents the choke points graph (introduced in Section 2.2), before and after the improvements have been implemented. In the figure, it can be seen that after adding a total of 11 IDSs to the Dataflows, Hosts, and Routers, the choke points are changed. For example, the LSASS Keystore and the Local Accounts AccessControl are not as wide and red anymore as they are now less frequently traversed in the most common attack paths. This can be explained as both of them are connected to the Host Workstation 1, which now has a IPS associated with it and has reduced the probability of certain attack paths being successful. This does not however remove all the attack paths, so the attacker is still able to reach the key assets.

In all the improvements the impact of the improvements on average is more apparent for the Datastore Customer Records since it is further inside the network. Any attacker starting from the host Workstation 1 has to have more successful attack steps to reach the Customer Records. Further, since only a few deficiencies are resolved at a time, it still leaves other paths that the attacker can traverse to reach the Stage srv. 2.

(43)

Figure 4.3: A view of the model with all the Type 1 improvements added

When more than one improvement is implemented at the same time, it can be observed that the simulation gives a better outlook. When all the Type 1 improvements are implemented (see Figure4.3), it is observed that the success rate of the attacks at 40 days has dropped for both the assets and their attack step. As shown in Figure 4.4, when all the Type 1 improvements are implemented, for Stage srv 2 with attack step of Compromise, the probability of compromise in 40 days has reduced from 67% in the example model (see Figure4.1) to 55%, and for the Datastore Customer records the probability of compromise in 40 days has reduced from 47% in the example model (see Figure4.1) to 27%.

(44)

(a) Stage srv 2 Compromise (b) Customer records Write

Figure 4.4: The TTC for the key assets in the example model with Type 1 improvements

(a) Oracle Login RootLogin before (b) Oracle Login RootLogin after

(c) Oracle Database ApplicationLogin before

(d) Oracle Database ApplicationLogin after

Figure 4.5: The TTC for the associated assets with MFA improvement

4.3.2 Type 2 improvements

For the Type 2 improvement, the MFA improvement was added to the example model. In the search step, Upon simulation, the effect of the improvement is much more conclusive. As seen in Figure4.5, the addition of the MFA reduces the probability of compromise of the access control directly. Along with the access control, the probability of the success of the attack ApplicationLogin in

(45)

the service Oracle Database has also decreased. It can be seen in Figure4.5, that the probability of success of the attack steps RootLogin at the Oracle Login has fallen from 42% in 40 days to 6%. Similarly, for the ApplicationLogin attack step for the Oracle Database, the probability of success of the attack has fallen from 42% in 40 days to 6%. However, it has to be noted that since the access control on the assets occurs deeper in the network, the addition of MFA does not affect the Stage srv 2 directly but it does have some effect on the Customer Records.

4.4 Conclusion

The results from the simulations show that the deficiency model can be effec- tively used to identify the occurrence of the deficiencies, particularly structural deficiencies. Once these deficiencies have been identified, replacement of these deficiencies with the improvements can help reduce the the success of attacks. This improves security posture of the infrastructure as a whole.

Detecting Cyber Security Anti-Patterns in System Architecture Models

Detecting Cyber Security Anti- Patterns in System Architecture Models

VENKATA RAMAKRISHNA CHIVUKULA

Detecting Cyber Security Anti-Patterns in System Architecture Models

VENKATA RAMAKRISHNA CHIVUKULA

Abstract

Sammanfattning

Contents

Chapter 1 Introduction

1.1 Context

1.2 Threat Modeling

1.2.1 Attack Trees

1.2.2 Time to compromise

1.3 Patterns

1.4 Anti-pattern

1.5 Research Questions and our Contribu- tions

1.6 Ethics and Sustainability Aspect

1.7 Thesis Outline

Chapter 2

Preliminaries

2.1 securiCAD

2.2 Simulation Results

2.3 Formalization

2.4 Infrastructure model

2.5 Description of deficiencies

2.6 Structural deficiencies vs defenses

Chapter 3

Catalog of Structural Deficien- cies

3.1 The catalog

3.1.1 Type 1 Improvements

3.1.2 Type 2 Improvements

3.1.3 Type 3 Improvements

3.2 Conclusion

Chapter 4

Structural deficiencies as graphs

4.1 Deficiencies expressed as models

IDS absent deficiency if

IPS absent deficiency if

Plain text communication deficiency if

ZoneManagement absent deficiency if

Firewall absent deficiency if

MFA absent deficiency if

Management Bypass deficiency 1 if

Data plane and control plane communication combined - II

4.2 Implementation

4.3 Results

4.3.1 Type 1 improvements

4.3.2 Type 2 improvements

4.4 Conclusion