• Aucun résultat trouvé

Automated attack tree generation and evaluation : systemization of knowledge

N/A
N/A
Protected

Academic year: 2021

Partager "Automated attack tree generation and evaluation : systemization of knowledge"

Copied!
38
0
0

Texte intégral

(1)

Automated Attack Tree Generation and Evaluation:

Systemization of Knowledge

by

Sam Nguyen

B.S. Electrical Engineering and Computer Science, M.I.T., 2020 Submitted to the Department of Electrical Engineering and Computer Science

in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science

at the

MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 2020

© Massachusetts Institute of Technology, MMXX. All rights reserved.

The author hereby grants to M.I.T. permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created.

Author . . . Department of Electrical Engineering and Computer Science

August 21, 2020

Certified by . . . Dr. Howard Shrobe Principal Research Scientist MIT Computer Science and Artificial Intelligence Laboratory

Thesis Supervisor

Accepted by. . .

Dr. Katrina LaCurts Chair, Masters of Engineering Thesis Committee

(2)
(3)

3

Automated Attack Tree Generation and Evaluation:

Systemization of Knowledge

by

Sam Nguyen

Submitted to the Department of Electrical Engineering and Computer Science on August 21,2020, in partial fulfillment of the requirements for the degree of

Masters of Engineering in Electrical Engineering and Computer Science

Abstract

The large scale infrastructure that modern society is dependent on has become more and more dependent on the computer systems that control it. Examples like electrical grids, water systems, or power plants all contribute heavily towards everyday function. Even though these systems have such importance, they have been repeatedly shown to be vulnerable to attacks. Cybersecurity research has shown that each month one in every five industrial control systems is attacked. A long-term concerted attack campaign to control or shutdown these systems could lead to disastrous results such as shutting down a power grid. Thus, it is crucial to be able to evaluate these systems and determine their vulnerabilities, especially by utilizing the bank of documented past attacks available as a resource.

To address this, this thesis presents an extension to Dr. Howard Shrobe’s Attack Planner, a computational vulnerability analysis system that is capable of outputting multistage attack model trees that achieve a desired goal on a desired system resource. It generates the attack models based on already known tactics and techniques that achieve different goals. In this thesis, I describe the systemization of knowledge of MITRE and NIST’s available categorization and bank of exploits and vulnerabilities into the Attack Planner, an additional tactic based on an attacker-controlled ad server, and a critique of the internal organization and semantics.

In order to incorporate MITRE and NIST’s data, I used Dr. Erik Hemberg’s BRON framework and created an interface between BRON’s network representation of this data and the Attack Planner. MITRE and NIST categorize and organize all stages of an attack campaign at varying levels of depth starting from an overarching goal to down to specific exploits on a specific version of an operating system. By using BRON’s network to link the specific exploits with their parent goals, the Attack Planner is able to generate plans with higher levels of detail.

Thesis Supervisor: Dr. Howard Shrobe Title: Principal Research Scientist

(4)

4

Acknowledgements

I would first like to thank my advisor, Dr. Howard Shrobe, for his patience and guidance throughout this project. I am very grateful for this opportunity to work with you on this project. Your insight and experiences in the field made working with you very enjoyable.

I would like to thank DARPA for their sponsorship under the CHASE program.

I would also like to thank Dr. Erik Hemberg for showing us BRON and his work with the National Vulnerability Database.

(5)

5

Table of Contents

Abstract ... 3 Acknowledgements ... 4 Table of Contents ... 5 List of Figures ... 7

List of Code Listings ... 8

Chapter 1 Motivation and Thesis Scope ... 10

1.1 Attacks on Large-Scale Infrastructure ... 10

1.2 Self-Adaptive Survivable Systems ... 11

1.3 Computational Vulnerability Analysis ... 12

1.4 Thesis Scope ... 12

Chapter 2 National Vulnerability Database ... 14

2.1 MITRE and NIST ... 14

2.2 Kill Chain ... 16

2.3 BRON ... 17

Chapter 3 The Attack Planner ... 20

3.1 Attack Tree Generation ... 20

3.2 Attack Planner’s Capabilities ... 22

3.3 Systemization of Knowledge ... 23

(6)

6

3.4 Attack Planner Extension: Adding CVEs ... 26

3.4.1 Motivation for using NVD ... 26

3.4.2 Implementation ... 27

Chapter 4 A Review of the Attack Planner ... 30

4.1 Attack Planner’s Predicates ... 30

4.1.1 Documentation ... 31 4.1.2 Consistency ... 32 4.1.3 Redundancy ... 33 4.2 Critique Summary ... 34 Chapter 5 Summary ... 35 5.1 Thesis Contributions ... 35

5.1.1 Systemization of Knowledge: Ad Server and CVEs ... 35

5.1.2 Review of Attack Planner ... 35

5.2 Future Work ... 36

(7)

7

List of Figures

2-1 Table of BRON classifications ...15

2-2 Example CAPEC ...16

2-3 MITRE Attack Matrix ...17

2-4 Attack Matrix Techniques ...18

2-5 BRON Network ...19

3-1 Attack Tree Generation ...21

(8)

8

List of Code Listings

3-3 Attack Method: compromise-site-through-adware ...25

3-4 Attack Method: remote-execution-compromised-browser ...25

3-5 Action: serve-ads ...26

3-6 Attack Method: how-to-read-a-file ...26

3-7 intersection.py main ...27

3-8 intersection.py run_path_finder ...28

3-9 intersection.py run_intersection...28

3-10 BRON make_graph_edges ...29

4-1 Example of Attack Planner Predicates ...30

4-2 Underlying Predicate Structure ...31

4-3 Example of Predicate Inconsistency ...33

(9)
(10)

10

Chapter 1

Motivation and Thesis Scope

1.1 Attacks on Large-Scale Infrastructure

Computer systems that control large scale infrastructure are commonplace in modern society. Electrical power grids and nuclear power plant are imperative for daily function but they, just like other computer systems, are susceptible to attack and exploitation. These systems are so large that attacks against them are not isolated events. A sequence of targeted attacks on this system is known as a campaign. Examples of such campaigns are Stuxnet and Triton. These attacks targeted Iran’s power plants and Saudi Arabia’s petrochemical plants respectively. Both took many steps in order to achieve initial penetration and lateral movement within the systems. Ultimately, they managed to tamper with key control systems within the facilities resulting in large scale failure [1], [2]. Cybersecurity research and antivirus company Kaspersky Labs found in 2016 that each month, one in every five industrial control systems is attacked [3]. The severity of shutting down a nation’s power grid is important enough to dedicate resources to exploring potential dangerous campaigns against these systems.

On the other hand, since there is so much more work that is required to attack such infrastructure, there is a lot more to examine and learn from. Studying specific attacks or bugs in software leads to patching, but campaigns allow researchers to study patterns of attacks that could lead to detecting other future incoming attack campaigns.

(11)

11

1.2 Self-Adaptive Survivable Systems

In order to protect against and combat these attacks, it is necessary to restructure the defensive systems to be self-adaptive survivable systems [4]. These systems must be able to protect and repair themselves. However, before determining how to address any issues or breakdowns, the system must be able to understand and diagnose the problems. The issue is that failure of a single resource has very high potential to lead to or indicate other or future failures in the underlying infrastructure. Thus, when identifying compromises in the system, it is not

enough to determine what failed and how anymore. Especially when dealing with long attack campaigns, understanding where other parts of the infrastructure could be affected and what role a singular compromise plays in an overall attack campaign is of increasing importance.

In order to accomplish these things, an inputted trust model is used to determine what actions, resources and observed behaviors should be trusted [4]. Decisions made by the system are guided by what the trust model deems safe while observed compromises or failures update the trust model and inform future decisions. In addition, attack campaigns have temporal constraints, multiple stages, and constraints on values that cause repeated observable events in the system over a period of time. These events can be modelled as trend templates and are useful for analyzing and detecting ongoing campaigns.

Using trust models and trend templates, long-term self-adaptive survivable systems are capable of identifying, detecting, defending against, and recovering from multi-stage attack campaigns.

(12)

12

1.3 Computational Vulnerability Analysis

Connecting a series of observed events or compromised resources to a possible attack campaign is required to be able to self-diagnose [4]. Generating strong trust models and trend templates requires a deep understanding of the attack campaigns that they are meant to defend against. This thesis focuses on computational vulnerability analysis, a systematic method for developing attack models. While current systems use specific exploit signatures or anomaly profiling, they are incapable alone of handling long drawn-out attacks that happen across

multiple stages, try to avoid detection by working slowly, and use earlier footholds and accesses to perform an attack in the future. By systematically generating all possible attack plans,

computational vulnerability analysis can account for such tactics.

Systematically generating plans requires understanding attacks to the level of encoding them as a template. There are many prevalent attack patterns that are commonly used (e.g. phishing attacks) that can be observed and described in natural language. The process of converting these attack patterns from natural language to formalized executable goal-directive reasoning to be used as a template is known as the systemization of knowledge.

1.4 Thesis Scope

In this thesis, we discuss and explore the Attack Planner, a computational vulnerability analysis program developed by Dr. Howard Shrobe. Specifically, I propose and implement an integration of the National Vulnerability Database (NVD) with the Attack Planner using NVD-specific database software.

(13)

13

In Chapter 2, I go into detail about what the National Vulnerability Database is, their hierarchy within the context of an attack campaign, and the database software to work with them.

In Chapter 3, I introduce attack tree generation, give a general overview of the Attack Planner, explain the systemization of knowledge (SoK) in the Attack Planner, step through a tactic I added based on ad-server based attacks, and show how I implemented the interface between the NVD and the Attack Planner.

In Chapter 4, I give a review and critique of the Attack Planner’s internal organization, focusing on its predicate usage, issues with consistency and understanding, and propose some solutions that could help improve the Attack Planner.

Finally, in Chapter 5 I summarize my contributions to the Attack Planner and the future work for this project.

(14)

14

Chapter 2

National Vulnerability Database

2.1 MITRE and NIST

The National Vulnerability Database (NVD) is a U.S. government repository that manages vulnerability data using the Security Content Automation Protocol (SCAP) [5]. The NVD includes databases of various security related events and information such as software flaws, misconfigurations, the product name that has referenced flaws, and impact metrics. Automated security measures such as vulnerability management and compliance are possible with this database. By aggregating the data, NVD analysists have created various metrics such as “association impact metrics (Common Vulnerability Scoring System – CVSS), vulnerability types (Common Weakness Enumeration – CWE), and applicability statements (Common Platform Enumeration – CPE).” Various levels of classification have resulted from this work. These levels of classification range from a high-level tactic to achieve a goal all the way down to a specific bug in a particular piece of software.

(15)

15

Figure 2-1: Table of BRON’s vulnerability classifications [6]

Figure 2-1 shows BRON’s categorization and labelling of the different vulnerability databases that will be referenced throughout the rest of this thesis. Organizations MITRE and National Institute of Standards Technology (NIST) both manage the various databases. MITRE manages the adversarial tactics (TACTIC), adversarial techniques (TECHNIQ), common attack pattern enumeration and classification (CAPEC), and CWE databases [7], [8], [9]. NIST

manages the common vulnerabilities and exposures (CVE) and CPE databases [10], [11]. Within the databases, there are parent-child relations that connect the different levels of classification as seen in Figure 2-2.

(16)

16

Figure 2-2: Example CAPEC with connections to children CWE [12]

While these inter-database connections exist, they are not present everywhere. It is very difficult to start from a high-level goal and find all the available exploits using just the databases provided by MITRE and NIST. Additionally, the details available in the higher level databases are not enough to formalize and use in computational vulnerability analysis.

2.2 Kill Chain

MITRE maintains the TACTIC and TECHNIQ information on its platform known as the Attack Matrix [7]. They have catalogued and grouped TECHNIQs under a parent TACTIC. The

(17)

17

point of note is that they have also organized the TACTICS into what is known as the kill chain.

Figure 2-3: MITRE’s attack matrix. Top rows are strategic goals (TACTIC). Others are TECHNIQs [7]

The kill chain describes each of the major steps needed to be taken to accomplish a successful attack. It is very thorough and describes a variety of different aspects of an attack such as initial access, discovery of information, privilege escalation, and exfiltration. Almost all steps of an actual attack could fit somewhere in the kill chain. However, in the real world, attacks do not happen neatly in the order MITRE’s kill chain describes. Many of the steps can happen at a variety of stages (e.g. defense evasion) and the kill chain does not necessarily describe an attack across a long period of time. The main contribution we take from the Attack Matrix is a

comprehensive initial set of categorizations and documentations of different attack techniques to perform systemization of knowledge on.

2.3 BRON

As previously stated, one of the weaknesses of the NVD is the connectivity. Using solely the database interfaces provided on their websites, it is very difficult to understand the

(18)

18

connections between each repository. Some entries have connections to lower or upper level database entries, while others do not.

Figure 2-4: Two techniques from MITRE’s attack matrix. The top has no connection to any CAPECs while the

bottom does [13], [14]

In order to more easily navigate through the various databases, we use BRON, a framework developed by Dr. Erik Hemberg, which provides a relational schema that connects the different databases together into a single easily workable network [6]. BRON provides additional analyses and useful tools such as a path search tool.

(19)

19

Figure 2-5: Depiction of BRON’s network [6]

BRON enables easier navigation and search through the various databases that make up the NVD. By using BRON’s path search tool, low level information (CVEs, CPEs) can be quickly obtained and linked to higher level goals (TECHNIQ, CAPEC).

(20)

20

Chapter 3

Attack Planner

3.1 Attack Tree Generation

Analysis of attack campaigns has many more steps and complexities compared to isolated attacks. For handling such multi-step processes, attack tree generation techniques have been traditionally used. Bruce Schneier released the first publication on attack trees in 1999 in Dr. Dobb’s Journal of Software Tools [15]. His work was built on top of Fault Tree Analysis, a frequently used reliability analysis technique developed at Bell Telephone Laboratories in 1962 [16].

The fault trees generated were meant to evaluate system failure and its potential causes. Thus, the root of the fault tree is the fail case and the leaves are potential reasons for that failure. The relationship between a parent and its children can also be categorized as “and” or “or”. In the “and” case for example, a subset of the children together must be satisfied for the parent to be satisfied. In contrast, in the “or” case, the children are independent and only one needs to be satisfied to satisfy the parent [15]. An attack tree works very similarly to the fault tree. Instead of trying to determine possible causes of a failure, the root of an attack tree specifies a particular goal trying to be met.

(21)

21

Figure 3-1: Example of attack tree generation [15]

Schneier describes in Figure 3-1 what an attack tree would look for an attack to open a safe [17]. In order to achieve the main goal of opening a safe, an attacker simply needs to satisfy one of picking the lock, learning the combo, cutting the safe open, or ensuring the safe is

installed improperly so that it can be opened later. For each of those sub-goals, there are similar sub-goals that need to be satisfied.

After generation, each node in the tree can be determined to be possible or impossible. An example would be that causing improper installation is impossible (labelled I) while cutting open the safe is possible (labelled P). Once the nodes have been labelled, impossible paths can be pruned. The process of identifying which nodes are possible or impossible depends greatly on the circumstance and requires both an understanding of the environment of the attack as well as what the attack requires.

(22)

22

3.2 Attack Planner’s Capabilities

The main contributions of this thesis focus on an extension to the Attack Planner, a program with the capabilities to generate both potential single and multi-stage attacks on a given network topology for a desired goal [4]. The Attack Planner was developed by Dr. Howard Shrobe’s group in order to generate detailed attack plans to be used as attack models. It derives its base knowledge for attack plan generation not from keeping track of past specific attacks like Stuxnet, but from reasoning about the techniques they used, in what situations they can be used, and what goal they achieved. Thus, the systemization of knowledge of the techniques used is necessary to increase the Attack Planner’s breadth of knowledge and ability to generate plans.

Since attack plan generation requires an understanding of the victim’s environment, the Attack Planner also models the network structure and topology, the types of hardware and OS on each node, the software running on each node, access rights to the data, and locations of data storage. Finally, the Attack Planner models the dependencies required of the computational resources in the network. Typical properties include data integrity and privacy, performance, and communication integrity and privacy.

The Attack Planner generates plans using the same methodology described in attack tree generation. It starts with a goal to violate a targeted property on the network model (e.g. violate the data integrity on a target database) and generate all the necessary sub-goals needed to achieve the parent goal. This repeats until the Attack Planner has reached a low enough level sub-goal that it only needs to accomplish certain actions in the network. Once it reaches that state, those leaf sub-goals will generate children that are actions instead of sub-goals.

(23)

23

Figure 3-2:Example of Attack Planner’s generated plans

The Attack Planner uses a DFS algorithm to generate every possible plan and returns them as a set of trees or a single combined tree. As seen in Figure 3-2, the Attack Planner represents the “and/or” characteristic in green. Goals are colored blue while actions are colored red. The Attack Planner is primarily implemented in Allegro Common Lisp.

3.3 Systemization of Knowledge

The Attack Planner contains a library of various attack methods and actions that it uses to build its attack plans. The NVD is a massive library of cyberattack documentation that can be

(24)

24

added into the Attack Planner, but it is not so simple. The information laid out in the NVD is written in natural language while the Attack Planner requires a more thorough understanding of the prerequisites, restrictions, post conditions, and resources at play to use a technique. In order to extend the Attack Planner’s knowledge, the techniques described in the NVD must be

formalized first. The next section will walk through an example of this formalization.

3.3.1 Ad-Server Attack

The ad-server attack is a technique meant to achieve remote execution through a browser by serving malicious ads to a target website. There are two attack methods written here that work in conjunction to formally describe this technique. Each attack method has a goal it achieves described in the to-achieve. In this case, compromise-site through-adware’s goal is to

compromise a site while remote-execution-compromised-browser is trying to achieve remote execution. The to-achieve field is also how parameters are passed down in the Attack Planner.

There is additional information in each attack method to ensure the Attack Planner has proper understanding of the environment and the used resources. The bindings and typing fields are used to ensure that the variable names have the correct typing or assignment. The

prerequisite field acts as a check to ensure that the necessary conditions are satisfied to continue

using this attack method. If not, this tactic is abandoned and the Attack Planner moves on to the next attack method to try.

Each attack method also has a plan. This section describes the sub-goals needed to satisfy the to-achieve goal. In Figure 3-4, when remote-execution-compromised-browser is used as a node in an attack plan, it will generate its sub-goals. The Attack Planner does this by

(25)

25

looking for all attack methods that try to achieve the desired goal. In this case, it is an attack method that tries to compromise a site.

The plan for compromise-site-through-adware in Figure 3-3 shows that there are no more goals needed. Instead, the action serve-ads is needed to satisfy this goal. Actions require a prerequisite and a post condition to describe an action occuring in the environment model. In Figure 3-5, the prerequisite to serve ads is that there is an available attacker ad-server that can serve ads to a target victim site. To describe a success, the post condition describes that the victim site has been modified.

Figure 3-3: Attack Planner’s attack method ‘compromise-site-through-adware’

Figure 3-4: Attack Planner’s attack method ‘remote-execution-compromised-browser’

The code describing specifically how the Javascript in the ad accomplishes remote execution is outside the scope of the Attack Planner. The Attack Planner’s purpose is to capture the possibility of an attack happening and under what conditions it is possible. In this case, the Attack Planner captures the circumstances where remote execution can be achieved if an internal machine on the network visits a website that is vulnerable to malicious ads.

(26)

26

Figure 3-5: Attack Planner’s action ‘serve-ads’

While this particular attack method is specific to web browser based attacks, it is meant to be used as a child to a more general attack method such as an attack method that requires achieving remote code execution as shown in Figure 3-6. In this way, the nodes closer to the leaves are more specific because they describe specific tactics for a more general goal.

Figure 3-6: Attack Planner’s attack method ‘how-to-read-a-file’

3.4 Attack Planner Extension: Adding CVEs

3.4.1 Motivation for using NVD

The Attack Planner’s attack methods and actions correspond to NVD’s TECHNIQs and CAPECs respectively. This allows the Attack Planner to generate high level plans for a given network. However, there is still a vast source of vulnerability data available among the lower level classifications, specifically the CVEs. CVEs are specific to certain platforms and patches. By modelling the CVEs as children to the Attack Planner’s actions, the Attack Planner is able to further identify the likelihood and possibility of an attack of a particular type occurring. For each

(27)

27

action in an attack plan, if there are no CVEs that are children of the current action that are applicable on any of the available platforms on the network, then that attack is more unlikely to happen. On the other hand, the presence of CVEs that fit the situation concretize the possibility of an attack of that type happening.

3.4.2 Implementation

In order to incorporate the information in the NVD, BRON is used as an interface to easily obtain the desired nodes and map out the NVD. BRON’s path search function outputs the set of all reachable nodes given a set of starting nodes. For example, given a set of CAPECs, it will output all TACTICs, TECHNIQs, CVEs, etc. that are connected to that CAPEC. The goal is to find CVEs that are children of the CAPEC but also parents of any CPEs in the network. To have BRON work with the Attack Planner, I created additional interfacing in intersection.py.

Figure 3-7: intersection.py main method. Calls functions from BRON to get necessary data

The path search function can only handle one type of starting nodes at a time, thus I run BRON’s run_path_finder twice. The typical pipeline for BRON’s path search is to input the file path to the list of starting points and then output a CSV representing the set of reachable nodes. To avoid making excess intermediary CSVs, the output from BRON is kept in Pandas’

(28)

28

dataframe form as shown in Figure 3-8. Additionally, some input processing needs to be done to replace how BRON parses the input file paths.

Figure 3-8: intersection.py run_path_finder method. Preprocesses the data such that BRON’s path finder can run

correctly

Once both dataframes are obtained, the intersection is found to find the set of all common CVEs. This returns the set of all CVEs that are children of the desired action and are applicable on a desired platform

Figure 3-9: intersection.py run_intersection method. Parses the dataframes and returns the common CVEs

Some additional changes needed to be made to make sure this ran correctly. There was an issue with BRON’s make_graph_edges function. When not called from the command line,

make_graph_edges would throw a name error for network_specific. This was fixed by adding network_specific as a parameter as shown in Figure 3-10. In all the use cases of BRON with the

(29)

29

Figure 3-10: BRON’s make_graph_edges method after adding network_specific parameter[17]

The end result is that when the Attack Planner is generating plans and gets to an action, it can call this function to compute and find any available CVEs. Intersection.py can be directly invoked in LISP in the Attack Planner and will return a list of all applicable CVEs.

(30)

30

Chapter 4

A Review of the Attack Planner

4.1 Attack Planner’s Predicates

As described in the Attack Planner section, the Attack Planner models the network it is generating attacks for as well as keeping a library of attack methods and actions. At this level of abstraction, the Attack Planner primarily uses predicates. These predicates are maintained in predicate-defs.lisp and provide a wide variety of useful statements as shown in Figure 4-1.

Figure 4-1: Example of Attack Planner’s predicates

These predicates are simply macros. The define-predicate function handles the

underlying work of interacting with the network model. In particular, the functions ask-in-state and insert-in-state serve as the interface to the Attack Planner’s notion of the environment as shown in Figure 4-2.

(31)

31

Figure 4-2: Attack Planner’s predicate’s underlying structure

This allows the predicates to obtain information from or interact with the environment. This allows for very easy extensions to the Attack Planner because of the ease of adding any necessary predicates. However, a couple issues regarding these predicates have formed.

4.1.1 Documentation

The first is the lack of documentation for the predicates. As seen in Figure 4-1, the many predicates have no description. I believe they were originally written at a point where the scope of the Attack Planner’s knowledge was simple enough that the predicates were self-explanatory. But as the knowledge of the Attack Planner increases, more and more predicates will be added. Additionally, for many of these predicates, it is not clear exactly what it is describing or what the parameters are being used for. As an example in predicate value-of, it is unclear what path is. Another example would be predicate ran-as-system. This predicate takes in a process and OS parameter. The natural interpretation would be the process is run at system privilege on a specific type of operating system. But the OS parameter is meant to represent an instance of that OS

(32)

32

running, and the process is actually running on that virtual machine. There are many predicates currently, but the Attack Planner would greatly benefit from documenting the intentions behind each predicate. This may require finding in which attack methods each predicate is being used.

4.1.2 Consistency

The other issue with the predicates is the lack of consistency. While all these predicates serve as a description of the world, they can be categorized further. There are some predicates that simply describe the world currently, such as the predicate is-superuser which checks if a user is a superuser. There are also predicates that describe an event or change occurring such as

modified-by, visits-site, and runs-with-permissions-of. I believe organizing the predicates into

categories will help make their intentions more clear.

This will also allow for formatting rules to be enforced for each category. This way the predicate will be able to be read in a consistent manner to avoid confusions about their intentions. For example, predicates that describe an event could be reformatted such that intention of the predicate can be read as “something does/has something.” The two predicates in Figure 4-3,

visits-site and modified-by, demonstrate this lack of consistency. Visits-site can be read as

“victim-machine visits site”. Something is doing an action in this case. On the other hand,

modified-by, it is meant to be understood as “object is modified by attacker” which is not

consistent with interpretations of these types of predicates. Instead, modified-by could be written as just modified and it would be consistent and therefore easier to understand.

(33)

33

Figure 4-3: Additional Attack Planner’s predicates to show consistency issue

4.1.3 Redundancy

The final issue with the predicates is redundancy. When a predicate is created, it is

usually created to enable some attack method. However, the generalness of each predicate varies. As seen in the ad server example, there is a very specific can-serve-ads predicate. But there also exists very general predicates like has-remote-execution that are more widely used. Since it is so easy to create a predicate, in the process of creating a new predicate it can be easy to overlook an already existing predicate that could be used instead. As more attack methods and actions are added, these general predicates start to have more and more specific variants appear as shown in Figure 4-4.

(34)

34

Figure 4-4: Attack Planner’s predicates to show redundancy

4.2 Critique Summary

Overall, the Attack Planner’s major issues reside mainly in its predicates. While the ease of creating predicates makes formalizing attack methods and actions very convenient, over time it has also led to disorganization. There is a lack of documentation for the predicate’s intentions, a lack of consistency in how the predicates are written, and there is redundancy in predicates. All three of these issues serve to confuse the developer and clutter the predicate space. The goal of the Attack Planner is to be able to formalize common attack patterns into attack methods and actions in a simple and easy-to-read manner.

(35)

35

Chapter 5

Summary

5.1 Thesis Contributions

5.1.1 Systemization of Knowledge: Ad Server and CVEs

Adding onto the Attack Planner’s knowledge base, I formalized a possible attack through malicious ads. In addition, I extended the Attack Planner’s knowledge base using BRON to interface with the NVD and add in CVEs. This extends the Attack Planner’s high level knowledge and attack plan generation to include low level concrete possibilities for the plans occurring.

5.1.2 Review of Attack Planner

After working with the Attack Planner, I give my review of the Attack Planner’s inner logic, primarily focusing on its use of predicates. I list out the three main issues: the lack of documentation, lack of consistency, and redundancy. These all serve to make the intentions of the predicates and the attack methods using them unclear. The goal of the formalization of these techniques is to make them clear enough that they can be encoded and easily understood. I suggest a couple solutions to address these problems.

(36)

36

5.2 Future Work

With the addition of CVEs into the Attack Planner, the Attack Planner’s generated plans are both more detailed with regards to the network and can be more easily evaluated for

likelihood of attack. Plans with many possible CVEs are much more likely to be vulnerable than plans with little CVEs present. Patching CVEs is an easily fixable task thus being able to

systematically generate all the CVEs the network is vulnerable to further enhances the network’s security. As the Attack Planner grows in knowledge, it becomes a more and more useful tool for maintaining and confirming the safety of a network.

(37)

37

Bibliography

[1] M. Giles, “Triton is the world's most murderous malware, and it's spreading,” 02-Apr-2020. [Online]. Available:

https://www.technologyreview.com/2019/03/05/103328/cybersecurity-critical-infrastructure-triton-malware/. [Accessed: 21-Aug-2020].

[2] N. Falliere, L. O. Murchu, and E. Chien, “W32.stuxnet dossier,” Symantec Security Response, Tech. Rep., Feb 2011, revision 1.4

[3] “Threat Landscape for Industrial Automation Systems in the second half of 2016,” Kaspersky

ICS CERT. [Online]. Available:

https://ics-cert.kaspersky.com/reports/2017/03/28/threat-landscape-for-industrial-automation-systems-in-the-second-half-of-2016/. [Accessed: 21-Aug-2020].

[4] H. Shrobe, “Computational Vulnerability Analysis for Information Survivability”, AIMag, vol. 23, no. 4, p. 81, Mar. 2002.

[5] H. Booth, D. Rike, and G. A. Witte, “The National Vulnerability Database (NVD):

Overview,” 20-Feb-2017. [Online]. Available: https://www.nist.gov/publications/national-vulnerability-database-nvd-overview. [Accessed: 21-Aug-2020].

[6] Personal Communication, in preparation

[7] MITRE ATT&CK®. [Online]. Available: https://attack.mitre.org/. [Accessed: 21-Aug-2020]. [8] “Common Attack Pattern Enumeration and Classification,” CAPEC. [Online]. Available:

https://capec.mitre.org/. [Accessed: 21-Aug-2020].

[9] “Common Weakness Enumeration,” CWE. [Online]. Available: https://cwe.mitre.org/. [Accessed: 21-Aug-2020].

[10] “Common Vulnerabilities and Exposures (CVE),” CVE. [Online]. Available: https://cve.mitre.org/. [Accessed: 21-Aug-2020].

[11] B. Cheikes, D. A. Waltermire, and K. Scarfone, “Common Platform Enumeration: Naming Specification Version 2.3,” NIST, 09-Jun-2020. [Online]. Available:

https://www.nist.gov/publications/common-platform-enumeration-naming-specification-version-23. [Accessed: 21-Aug-2020].

[12] “Common Attack Pattern Enumeration and Classification,” CAPEC. [Online]. Available: https://capec.mitre.org/data/definitions/7.html. [Accessed: 21-Aug-2020].

(38)

38

[13] “Credentials from Password Stores,” Credentials from Password Stores, Technique T1555 -

Enterprise | MITRE ATT&CK®. [Online]. Available:

https://attack.mitre.org/techniques/T1555/. [Accessed: 21-Aug-2020].

[14] “Input Capture,” Input Capture, Technique T1056 - Enterprise | MITRE ATT&CK®.

[Online]. Available: https://attack.mitre.org/techniques/T1056/. [Accessed: 21-Aug-2020]. [15] B. Schneier, “Schneier on Security,” Blog. [Online]. Available:

https://www.schneier.com/academic/archives/1999/12/attack_trees.html. [Accessed: 21-Aug-2020].

[16] T. W. DeLong and Army Materiel Command Texarkana Tx Intern Training Center, “A Fault Tree Manual,” DTIC. [Online]. Available:

https://apps.dtic.mil/sti/citations/AD0739001. [Accessed: 21-Aug-2020]. [17] Personal Communication, in preparation

Figure

Figure 2-1: Table of BRON’s vulnerability classifications [6]
Figure 2-2: Example CAPEC with connections to children CWE [12]
Figure 2-3: MITRE’s attack matrix. Top rows are strategic goals (TACTIC). Others are TECHNIQs [7]
Figure 2-4: Two techniques from MITRE’s attack matrix. The top has no connection to any CAPECs while the  bottom does [13], [14]
+7

Références

Documents relatifs

The method used, a significant national survey in France (1000 people questioned in 260 families where a stroke took place in the previous year), carried out in 2004/2005 taking

Furthermore, we have developed a solution for this problem that utilizes an abstraction-based refinement speci- fication derived from a system model and a set of traces

In case of anonymization, Blb proved to be generally the most robust attack, as it always achieved successful attacks with the high recall rates compared to others with high

For block ciphers, Dinur and Shamir proposed the idea of side channel cube attack model in which only one bit of information is available to the attacker after each round [26].. Due

In the example from Figure 1, the global action-based policy could specified to be not({X, isEmployee (X ), card [(owner, Y )], isCustomer(Y )}, {in}), stating that an actor X is

As proved in [16], the HS-attack requires the least number of observations to uniquely identify Alice’s set of friends with respect to the Threshold-Mix.. Attack Scheme In our Mix

Proof: Summing up implications of all m1 messages sent by Initiator parties to Responder parties, at time t, Victim has installed σ × t connections in its memory.. However, all

The algorithm presented in section 3 builds on some of the concepts of the similarity approach and addresses the issues raised in the discussion above. In particular, it allows: i)