Carlos, Kirsley Pierre W Yannis

Audrey

Gopal

Fabio

François Anna Renaud

Nicolas S Thomas

Timothée, Raaj, Isaac, Hélène Camille Paul

Julio Navarro

Modélisation et identification de cyberattaques multi-étapes dans des ensembles d'événements

Keywords: Cybersecurity, multi-step attack, event correlation, attack detection

We helped each other, fixed the world at every lunch time, had beers and mutually complained about the tasks to fulfill. Finally, I

One of the most important inflection points in my life happened when I quitted Telefónica and moved from Madrid to Strasbourg to begin the Ph.D. that culminates in this thesis. More than three years later, I can say that this decision was one of the best ones I have ever made. As Faulkner said, "you cannot swim for new horizons until you have courage to lose sight of the shore". And there are many people I would like to thank for the arrival to this new horizon.

First and foremost, I would like to thank my supervisor, Pierre Parrend, and my thesis director, Aline Deruyver. They made my arrival to France possible when accepting me to do this Ph.D. Thanks to the close supervision of Pierre I have been able to correctly build this manuscript and the related publications.

I would also like to express my gratitude to Joaquín García Alfaro, Matthieu Latapy and Véronique Legrand, for accepting to be part of the jury and for their valuable comments. I would like to thank Véronique also for leading the HuMa project and for putting me in contact with Pierre for the first time, when I contacted her after reading her research work. The conversations with them were the starting point of this adventure.

I am very grateful to the two directors of the CSTB team, Olivier Poch and Pierre Collet. I appreciate being so well received in their team and their recommendations about my work, but also some other non-academic contributions. Olivier has taught me to play chess (even if I am still a noob) and I got from him the best advices about life and the most ironic expressions of the belle langue française. Thanks to Pierre I had my first flight in a light aircraft, an amazing experience, and I have learnt many interesting things such as how to use vacuum to brew coffee.

Olivier and Pierre could be called the "parents" of the big CSTB family. I am very thankful to all its members for making me feel like at home. I did not only find excellent colleagues but also really good friends. I thank the permanent researchers, who has always been willing to help or just to talk about any topic: Laetitia, Luc, Odile, Julie, Raymond, Claudine, Anne J., Jean-Sébastien, Catherine, Christian. I am particularly grateful to Julie, who kindly reviewed many of my manuscripts in English, and to Raymond, who solved my numerous problems with bikes, my main means of transport to the lab. I highly appreciate the invaluable help of Anne N. Without her I would be still fighting against French administrative paperwork. Now it is the turn of the youngest. I would like to thank my comrade Arnaud for his help with the computer infrastructure of the lab and for many great discussions about philosophy. I am really grateful to my brothers in arms, the fellows who were The secret to getting ahead is getting started.

-Mark Twain

Computer networks have become an indispensable tool in our everyday life. Thanks to them we can communicate with other people, share files, do shopping, complete paperwork or even make a reservation in a restaurant. It would be difficult to imagine nowadays life without them and their world-scale interconnection, the Internet. But despite its advantages, the interconnectivity of computers involves serious threats.

Think of WannaCry, a massive cyberattack against computer networks which caused havoc during Spring 2017. More than 230,000 computers in 150 countries, such as Russia and Spain, were infected [Ehrenfeld 2017]. The most affected organization was the Britain's National Health System (NHS), where almost 20,000 appointments were cancelled [Check Point 2018]. The attackers took advantage of a vulnerability in the Server Message Block (SMB) protocol, used for providing shared access to resources, to introduce a malicious software which propagated itself and encrypted the hard disks of infected computers. The objective was to ask for a ransom in exchange of the decryption key. WannaCry is an example of a multi-step attack, term used to denote a cyberattack composed of different phases or steps.

Motivation

As in any other cyberattack1 , the perpetrators of WannaCry take advantage of the vulnerabilities present in computer networks. Apart from unknown vulnerabilities [START_REF] Bilge | [END_REF]], that cannot be patched until they are detected, there exist publicly disclosed ones that may not be able to be corrected for the sake of flexibility [START_REF] Wang | [END_REF]]. Therefore, an early identification of ongoing cyberattacks is important to minimize their impact.

Organizations rely on tools, processes and analysts [Sundaramurthy 2015] to identify attacks. The analyst, a cybersecurity expert, is a key piece [Caulkins 2018] who incorporates human creativity and a background built by experience that is rarely fully captured by automatic machines [START_REF] Vert | [END_REF]]. But when facing multi-step attacks such as WannaCry, the analyst can be overwhelmed trying to determine which were the exact actions taken by the attackers and in which order.

Moreover, once a multi-step attack is detected, it is important to determine how it could happen next time, so the organization can be better prepared against it. But the mere presence of several steps instead of just one makes things harder [Ussath 2016a]. This is evident from the perspective of basic combinatorics. Imagine that we detect the sequence of actions A-B-C, which represents a multi-step attack with three steps. It may be that any future occurrence of the same attack follows exactly the same sequence, because action C requires action B to be performed before, which at the same time requires action A. In this case there is a strong causality and a detector can be developed to exactly match the sequence A-B-C.

But the actions within a multi-step attack are not necessarily linked by a strong causal relationship. We can consider, for example, a sequence of actions where a malware is installed in a computer within the network (action A), and then a message to the attacker's server is sent to request additional software for future lateral movement (action B) before a privilege escalation is performed (action C). If the downloaded software is not necessary for doing the privilege escalation, both sequences A-B-C and A-C-B are possible. This example considers only three actions, but the number of them can be higher, which would normally increment the number of possible sequences.

Furthermore, there exist actions executed by an attacker that seem to belong to the attack itself but that are not part of it. These actions can be attempts of parallel attacks, exploratory probes or even purposeful noise to distract the defender. In some cases, it can be very difficult to distinguish the fundamental actions of the attack, the Table 1.1: List of events containing an instance of WannaCry ones which are repeated each time the attack takes place.

We see an example of this in Table 1.1, where we represent a list of events that happened during an execution of WannaCry. Among all the events shown, only the sequence of events e 0 e 2 e 6 is the one truly representing WannaCry. This sequence is camouflaged among the other events.

Detection of future instances of an attack is thus hindered by the independence of actions composing it and the presence of side actions not contributing to the goal of the attacker. Given a set of actions such as the one in Table 1.1, a security analyst can think of several alternative attack scenarios. The analyst works then upon a number of hypotheses or cases, without being certain of which one would match a future manifestation of the attack.

Taken this context, we can define our research question:

How can we help the security analyst to decide between alternative scenarios of multi-step attacks in order to ease the detection of future occurrences? Can we perform detection at the same time as the learning process evolves?

Goals

The actions executed by the authors of a cyberattack generally leave a trace in the victim network. For instance, devices in the network keep a journal of activities, whose entries are called logs, that can be exploited by a cybersecurity team in order to find the trace of the attack actions. There are three major search activities according to the period of time on which the cybersecurity analyst is focused: the past, the present or the future. If the analyst is focused on finding the effects of a cyberattack that happened in the past, we talk about investigation, also called forensics or forensic investigation [START_REF] Khan | [END_REF]]. When the goal is to find cyberattacks occurring in the present moment, in order to fight against them and avoid further consequences, the activity is called detection [Zuech 2015]. Detection models referring to a specific type of cyberattack are commonly known as signatures. Finally, if we want to know in which possible ways the network could be attacked so we can be prepared against future threats we talk about prediction, that have risk assessment as one of its fields of action [Cherdantseva 2016].

The processes of prediction and detection are based on models. These models are built from the conclusions obtained from the investigation of past cyberattacks, together with what we call the structural information of the network. This information is the one that can be obtained by the analysis of the elements in the network assuming that no traffic exists between them. It contains, for example, the characteristics of assets, the vulnerabilities, the network configuration, among others. The analysis of structural information is out of the scope of this thesis. We are only focused on the dynamic information extracted from the actions performed in the network.

During the investigation there is a process of abstraction in which the analyst takes the available information and builds models from it. On the contrary, detection and prediction are a concretion of built models in order to search for instances of cyberattacks in the traces. This vision is represented in Figure 1.1. The stated research question (page 3) refers to the abstraction of the results coming from the investigation and to the confirmation of the defined abstract models. We call these two processes modelization and identification, respectively.

Motivated by the context presented in section 1.1, in this thesis our objective is to help the security analyst in the development of multi-step attack detection models from The temporal line below refers to the moment when the cyberattack happened with respect to when each process takes place.

Network traces

Results

Feedback

Contributions

an initial set of alternative scenarios. This process is executed in two phases. First, the analyst detects the symptoms of a multi-step attack and deduces a list of possible attack scenarios (modelization). Second, a human-guided algorithm is applied to learn which of the proposed scenarios is the one representing the successful cyberattack (identification). But to avoid missing another occurrence of the same multi-step attack, the modeled set of alternative scenarios have to also act as a detector, so detection alarms2 are sent to the analyst while the learning process is performed. Feedback from the analyst is then used in the learning process. This problem has not been solved yet by the literature about multi-step attack detection, as we will see in Chapter 4. This Ph.D. thesis has been financed by the French public investment bank Bpifrance (Banque publique d'investissement) in the frame of AAP-19 project. This project is called HuMa (L'humain au coeur de l'analyse de données massives pour la sécurité) and counts with the collaboration of both public institutions and private companies. The objective is the creation of a system for the analysis of complex attacks in massive sets of logs3 .

Contributions

In this thesis we present a series of contributions, that we introduce below, in order to answer our research question.

A survey on multi-step attack detection

Methods for multi-step attack detection has been developed since the beginning of 2000s, but the field lacked of an analysis of its evolution. One of our contributions is the first systematic bibliographic research about multi-step attack detection on traces. Only the methods focused on the detection of the whole structure of the attack and not of individual symptoms are considered. A total of 138 different methods presented in 201 publications are studied. This has allowed us seeing up to which point existent methods have contributed to answer our research question. The statistics extracted from this systematic survey are also intended to help future researchers in the development of multi-step attack detection methods. This contribution is presented in Chapter 4.

Abstract Attack Scenario Graphs (AASG)

In the scope of this thesis, events, represented as logs, are considered as the traces studied to search for the actions of the attackers. The analyst needs a mechanism to represent the alternative multi-step attack cases derived from investigation. We propose a new model, the Abstract Attack Scenario Graph (AASG), where these cases are represented to perform detection and identification on new incoming events. In opposition with the representation of a specific instance of a multi-step attack, that we call Concrete Attack Scenario Graph (CASG), an AASG can capture the abstraction involved in the deduction of future cases of the attack.

Alternative cases are arranged as branches of the AASG, which is a single-source directed acyclic graph (DAG). Each node in an AASG contains an abstract event, which corresponds to a set of possible events. Each abstract event can be seen as a set of rules indicating which events can be identified with the node. The representation of abstract events is based on the functions that define the relationship between two steps in a multi-step attack, as they are considered in the literature (see Chapter 3). This give the analyst enough flexibility to capture the conditions in the proposed hypotheses. AASGs are conceived to be easily read and interpreted by the analyst, which also eases the sharing with the community. Abstract events and the structure of the AASG are defined in Chapter 5.

Detection and identification of scenarios

An AASG is intended to be used by algorithms designed to perform identification and detection of the correct multi-step attack cases. Another contribution of this thesis is the proposal of two algorithms for this task: Morwilog and Bidimac. In both of them, the analyst is directly involved in the process, providing feedback about the malicious nature of the detected sequences.

Morwilog is an ant colony-based model where an artificial ant, called morwi, is created each time an event matching the root node of an AASG arrives at the system. When an AASG is used in Morwilog, a certain level of artificial pheromones is assigned to each one of the arcs, becoming a stigmergic AASG. The morwi goes through the stigmergic AASG waiting for the arrival of events matching subsequent nodes and randomly choosing a path based on the level of pheromones in each arc. The chosen path thus depends on previous history. The levels of pheromones are modified based on the feedback given by the analyst, that receives alarms each time a morwi detects a full multi-step attack case.

Publications

On its side, Bidimac is an adaptation of classical Bayesian inference for working with AASGs. The graph becomes then a Bayesian AASG, with probability parameters assigned to each arc. Every found case by Bidimac raises an alarm that the analyst has to evaluate. Her feedback results in the modification of the probability parameters in the Bayesian AASG. Due to the novelty of AASGs and the concept of identification of multi-step attacks, Bidimac offers a way to compare Morwilog with a classic method such as Bayesian inference.

Both Morwilog and Bidimac can detect the cases represented in the AASG while performing the identification of the correct cases. Methods in the literature of multistep attacks do not consider the human process of thinking of a set of possible cases and confirming correct ones. Concerning detection, the originality of our proposal resides on its human-centered approach. The analyst gets involved in the process, going beyond the classical tasks of alert verification after detection or development of models and methods before detection. Morwilog and Bidimac do not work as a black box, but as assistance mechanisms where the human can control at any moment how the system learns and which are the conclusions drawn from the learning process.

Visual investigation of attack scenarios

Although our biggest contributions are the ones already mentioned, there is an additional proposal that has been developed when exploring the investigation process leading to the construction of AASGs. This model, called SimSC, is used to investigate attack scenarios in sets of raw logs. It has been conceived to be used together with the methods developed by the rest of partners in the HuMa project, the project that has funded this doctoral research. SimSC is based on the automatic extraction of IP addresses and timestamps from the raw logs and the construction of graphs based on the similarity between these features.

The battleground: a connected world

Unauthorized use, appropriation, destruction or illegitimate seizure of someone else's resources, according to the limit of private property defined by each society, is probably as old as civilization. In the Mesopotamian Code of Ur-Namma, the oldest known law code (ca. 2100 BCE), we already find rules to punish the citizens who steal someone else's possessions or cultivate the field of another citizen [START_REF] Roth | [END_REF].

Information is something abstract, independent of the physical format where it is stored. That is why it is more difficult to protect information than physical possessions. Once known, a piece of information could be considered as 'stealth'. Interests on stealing information can be very numerous, as to disclose it publicly, to gain a competitive advantage or to get something else through extortion. But information can be also modified, and false information can be created for a dishonest purpose. Moreover, a source of information can be eliminated (e.g. 'erasing' someone knowing a secret) or the physical support containing the information can be destroyed.

A first requisite to alter, steal or erase information is to have access to it. Before the invention of digital computers, there were two ways to get unauthorized access to encoded information 1 : having physical access to the support where the information was stored or intercepting the communication, the process of information exchange [Huurdeman 2003]. Communication required a human emitter to initiate and coordinate the actions for sending the message. However, digital computing brought the possibility of making requests to a remote machine that automatically serves the information, without human intervention. The computer has access to the information in digital form and counts with a set of instructions to follow in respond of each type of request.

The evolution towards automatic remote access was progressive. Even if electronic storage of digital data was already possible since the invention of the Williams-Kilburn Tube at the end of the forties [Williams 1951], the remote connection of computers was not possible until 1965 [START_REF] Marill | [END_REF]]. A few years later, in October 1972 [START_REF] Leiner | [END_REF]], the first public demonstration of ARPANET, which soon became the Internet, took place. The ubiquitous access to information brought by the Internet since then has deeply transformed society. Now we can share a video with the rest of the world or send an image to a friend living in another continent in a matter of seconds. Email has become the preferred way of communication in business, and social networks allow us keeping in touch with people living abroad or even start a revolution. Lots of activities, including administrative transactions, increasingly rely on the Internet.

1 'Encoded' to distinguish it from information known by a person but not written down.

But the Internet also means global interconnectivity of computers. And since the moment when a user has remote access to a computer, he or she can try to exploit the weaknesses present in the machine or in the provided services to get unauthorized access. This brings a wide spectrum of new remote ways to commit crimes, from the illegal appropriation of intellectual property to the stealth of personal information, the ransom of critical data or the disruption of services. All that with just a computer located anywhere.

Threatened by cyberattacks

Crime committed exploiting remote network access exists since the beginning of computer networks [Akhgar 2014]. The goal of unauthorized access to network is not necessarily to get illicit economic benefit [Duffany 2018]. There are users who do it for the challenge, as a way to learn, to protest against an institution, to have access to shareable resources, to do a joke, etc.

In any case, from the point of view of the defended system we consider all these actions as cyberattacks. The definition of cyberattack followed in this thesis2 is the one that follows: a set of actions, via cyberspace, targeting an organization's use of computer networks for the purpose of disrupting, disabling, destroying, exposing or controlling without authorization a computing environment/infrastructure; or destroying, modifying or stealing data or blocking the access to it.

The prefix 'cyber' intuitively points to something related to the culture of computers and the Internet. Once the context is well defined, we can refer to 'cyberattacks' just with the general word 'attack'. In this thesis, only attacks performed intentionally and using digital methods are considered. That means that we do not consider any physical contact between the attackers and the victims.

We mention in the definition of cyberattack the word 'cyberspace'. It is a neologism which appeared for the first time in July 1982, in the short story "Burning Chrome" [Gibson 1982] by the science fiction author William Gibson, and that was soon incorporated into the technical language as a way to refer to the digital environment created by the Internet. More formally, The Oxford English Dictionary tells us that the cyberspace is "the notional environment in which communication over computer networks occurs" [OED 2018b]. This englobes not only communications over the Internet but also those done within local networks. The computers or other devices involved in the communication are also part of the cyberspace.

Throughout this thesis, the agent performing a cyberattack is called an attacker, a neutral term only addressing the action and not presupposing the objective or nature of the agent 3 . In contraposition to this term, the entity responsible of preserving the target system against potential attackers and, if these last ones are successful in their attempts, of detecting the attack and mitigate its effects is called defender. The attackers focus their effort on different elements on the attacked system [Stallings 2015]: either a piece of data, a service, a system capability (processing power or bandwidth, for example) or an item of system equipment (software or hardware). From the point of view of the defense of computer networks, and to do abstraction of their characteristics, these elements are called assets. An asset can be the final target of an attacker or just a partial step in the pursuit of another asset.

Constrained by vulnerabilities

Attackers can act because there exist vulnerabilities in the assets they target. A vulnerability is a flaw or weakness in the design or implementation of a piece of software or hardware that can be exploited by an attacker to perform an unauthorized action [Stallings 2015, Duffany 2018]. A defender has to deal with attacks in a scenario composed of vulnerable assets. There exist known and unknown vulnerabilities. The defender is aware of the existence of the known ones, whose exploitation can be prevented by the development of specific security mechanisms. However, unknown vulnerabilities are the ones that have not been found yet by the defender. Their existence is assumed when deploying the defenses of the organization.

Attack detection has a special relevance in current computer networks as the number of available services increases, bringing an uncontrollable amount of vulnerabilities. New vulnerabilities are discovered everyday. Only in 2018 a staggering total of 16,555 new vulnerabilities were incorporated into the CVE (Common Vulnerabilities and Exposures) database [CVEDetails 2019], around 45 per day. Figure 2.1 shows the impressive increase in the number of reported vulnerabilities per year since 2000.

The classification used for vulnerabilities can be also extended to attacks. An attack is known if it has been widely detected, analyzed and understood by the security industry, so prevention mechanisms against it can be effectively deployed and a signature characterizing it could be developed for its detection. Once an attack is known, 3 We do not judge in any case the sense of morality behind the actions of an attacker. A cyberattack is not forcibly seen by everybody as immoral (e.g. WikiLeaks, Anonymous). That is why we avoid in this thesis the terms hacker, with positive connotations, or cybercriminal, with negative ones 2.2. Cybersecurity: objectives and mechanisms 15 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 the vulnerabilities exploited during its execution also become known. On the other hand, unknown attacks rely on unknown vulnerabilities or on ways of access that were not considered by the defender.

Cybersecurity: objectives and mechanisms

The domain studying and implementing methods against cyberattacks is called Cybersecurity. A complete report about the formal definition of the term 'Cybersecurity', also written 'Cyber Security', was published in December 2015 by the European Union Agency For Network And Information Security (ENISA) [START_REF] Brookson | [END_REF]]. It analyzes the definitions given by the most relevant standard organizations. Surprising as it may seem, each one defines a different scope for the usage of the term. For example, the US CNSS4 , the NATO and the ITU-T consider within the scope of the term the 'physical security', the protection against physical threats which can affect the well-functioning of computer networks such as physical access to servers or insertion of malicious hardware. On the contrary, the ISO and the US NIST do not consider it. According to the report, it is not possible to formalize a definition to cover everything the term suggests to cover. The authors even conclude that there is no need of a conventional definition like the ones we apply to simple concepts, as 'Cybersecurity' is an enveloping term whose scope depends on the context where it is used. [START_REF] Craigen | [END_REF] try to capture the enveloping spirit of the term in an inclusive definition, well-chosen but too broad for the scope of this thesis.

Having defined our scope, we have coined a definition of Cybersecurity as it is understood throughout this thesis: the organization and collection of resources, processes, and structures used to protect cyberspace, cyberspace-enabled systems and the information contained on them from intentional cyberspace-based actions that compromise their confidentiality, integrity and availability.

According to the report published by ENISA, each definition of Cybersecurity contains a series of components. They represent them as a diagram, which is reproduced in Figure 2.2. We have shaded in gray the components included in our definition. The name of each component is self-explanatory. A full definition of them is given in the original document [START_REF] Brookson | [END_REF]]. [START_REF] Brookson | [END_REF]]. The components considered in our definition are shaded in gray.

Definition of Cybersecurity

The three last properties mentioned at the end of the definition of 'Cybersecurity' compose the CIA paradigm. The description of each one of the properties [START_REF] Qian | [END_REF], Stallings 2015, Duffany 2018] is given below:

• Confidentiality: Information is disclosed only to authorized users.

• Integrity: Assets or messages exchanged between users can only be modified in a specified and authorized way.

• Availability: Access is guaranteed only to authorized users at any moment in a timely manner.

The preservation of those properties in every asset is an ideal goal for any organization, although it may be impossible to attain. Anyways, the goal is not to be achieved by a single security service, but it is the whole Cybersecurity strategy set up by the organization which could eventually guarantee the safeguarding of these properties [START_REF] Qian | [END_REF]].

There is another property, accountability [START_REF] Qian | [END_REF], CNSS 2015], which ensures that actions performed by each user can be traced uniquely to that user. Its preservation is not an essential task of Cybersecurity but provides a source of valuable information to perform attack investigation and detection. Checking the actions performed in the network can help to reconstruct those ones oriented toward the same malicious goal and, therefore, being part of the same attack. Each one of these actions is also called a 'step' of the attack.

Traces in a network

The place of the defender is the one taken in the study of multi-step attacks done throughout this thesis, the same generally taken by the literature about attack detection. We could imagine an alternative model built from the point of view of the attackers if we take as a base, for example, the pieces of code or exploit kits used in every step [Ghosh 2015]. Placed on the defender's side, the only sources of information we have for knowing the actions performed by the attackers are the assets, whose capacity of recording the activities of users is guaranteed by the property of accountability.

We denominate trace to each preserved piece of information about actions performed within a computer network. The use of this term in Cybersecurity refers to the definition of the term 'trace' given by the Oxford English Dictionary: "a mark, object, or other indication of the existence or passing of something" [OED 2018f]. We denote the ensemble of all the possible traces by ⇥.

A trace [OED 2018c] is then the representation of something that happened, of an event. The same as our actions as individuals are limited by Nature and its laws, computer networks establish an environment where actions are limited by the technical characteristics of the used devices. The point of contact between the user and the network, the interface, offers a big but finite number of possible actions. In any case, the number is much smaller that the actions a human can perform outside the network. Events happening in the network are the consequence of actions, so they have also a reduced number of possibilities. But this number is even smaller when they are expressed as traces, as they have to be translated to a specific code of symbols to be understood by humans and machines. On top of that, timestamps in traces have a certain limit in accuracy. Different actions can then lead to the generation of identical traces associated to the same moment.

A trace counts with a series of attributes that we can call inherent, as the own information of the trace is enough to determine them. Opposed to them we could

Human actions

Actions in a computer network define extrinsic attributes, derived from the place of the trace among a set of traces.

In other words, extrinsic attributes depend on external complementary data coming from other actions, while inherent attributes do not. For instance, an inherent attribute could be the name of the machine generating it, which is usually contained within the information in the trace. Conversely, an example of extrinsic attribute is the probability of having a trace of the same type generated in a period of 5 seconds. More formally, a trace ✓ a 2 ⇥ can be represented as a finite tuple of inherent attributes, each of them containing information about a specific characteristic of the trace. We use att a for referring to a generic attribute. The name of the attribute att defines a unique meaning for each attribute ✓ a (att) = att a in the trace ✓ a . For example, commonly used names are ipsrc (source IP address), time (timestamp) or type (type of the trace). Names establish a correspondence with other traces, which could also contain attributes with the same name and, therefore, the same meaning. Moreover, a name univocally defines the type of value of the attribute, which could be a real number, an element from a finite set or an IP address, among others. The operation of attribute selection can be extended to be used with a set of attributes A, so ✓ a (N ) = A, with N the set of names corresponding to the attributes in A.

In the context of this thesis we deal with two kinds of trace, defined below: events (including alerts) and packets. Other work, such as the one focused on malware analysis, can find useful other types of trace, as for instance the files left by a malicious software in the victim computer. The following definitions are issued from the wide use of the term in the reviewed literature and our own experience in the Cybersecurity industry. specify the environment. A packet is composed of the transmitted data and the header [START_REF] White | [END_REF]]. The latest describes the nature of the former and includes the instructions for handling the packet in the context of the communication protocol used. Apart from its function in communication, a packet indirectly contains information about an action that happens between two or more network assets.

• Event. In this thesis we consider the definition given by the Standard on Logging and Monitoring published by the European Commission in 2010 [EC 2010]: "an event is an identifiable action that happens on a device", considering that 'device' is equivalent to 'asset'. We refer to 'events' when this information is processed and stored by the own asset. The distinction is then clear from the general definition of event as "a thing that happens" [OED 2018c], under which packets would be also the manifestation of events (the communication processes between assets).

An event is considered to be bound to the specific point in time when it took place [Meier 2004]. Events are usually represented as plain text in a format dependent on the used technology. This materialization of an event, stored in the asset, is called log. Parsed logs are the ones that have been preprocessed in order to make their attributes distinguishable, transformed into a format suitable for security analysis. On the contrary, raw logs are expressed in their original format as they are generated by the asset.

The process of transforming a raw log into a parsed log is called normalization.

The piece of software to do this job is called a log parser. In the industry, parsers are usually developed by the engineers working for the vendors and sent to the user. The problem faced by the manually created parsers is the need to be updated after changes in the log formats. Some interesting alternatives for automatic parsing exist, such as the ones based on NLP (Natural Language Processing) [START_REF] Kobayashi | [END_REF]] or the LTE (Log Template Extraction) method [START_REF] Ya | [END_REF]], but further development is needed until they can be applied to any log format.

Security systems in charge of log collection, including normalization, and correlation [START_REF] Kavanagh | [END_REF]] are known as SIEMs (System of Information and Event Management). Their main purposes are the unification and reinterpretation of logs collected from other assets in the network and the generation of alerts through event correlation (see page 57).

Current assets are conceived to register and save a certain number of logs related to their functioning and to their relationship with other assets and with users.

For example, a router can generate logs containing information about failing interfaces or details about communications managed by it. Note that logs are created to work just as traces, while packets have a determinant role in the functioning of the network, independently that they can be used as traces.

• Alert. Also referred to as alarm5 , it is an event generated by a security system in response to the detection of alleged malicious activities or faults [START_REF] Salah | A model-based survey of alert correlation techniques[END_REF]].

In other words, it is an indicator that something is not working as it should or that a resource is not properly used. As its name suggests, an alert demands the security analyst to be vigilant. An alert is an event, but not all events are alerts. There exist events reporting normal functioning of systems. As any other event, alerts are usually represented as a log. Alerts are generally triggered by an Intrusion Detection System (IDS), a piece of software or hardware conceived to automate the attack detection process [START_REF] Liao | [END_REF]].

To complement the given definitions, Figure 2.4 shows a visual representation of the considered types of trace.

Traces

Definition of multi-step attack

The term 'cyberattack', or 'attack', is popularly identified to an individual malicious action. For instance, we speak of SQL Injection attacks [START_REF] Nagpal | [END_REF]] or Denial of Service (DoS) attacks [START_REF] Peng | [END_REF]], where just one action, possibly repeated, is required 2.4. Definition of multi-step attack 21 to threaten the system. We can call them 'single-step attacks'. In contraposition to them, when an attack is composed of several different actions it is called a multi-step attack

Sequences of actions

Attackers usually follow a step-by-step strategy in their attempts to attack a system [START_REF] Qian | [END_REF]], thus performing multi-step attacks. There are two reasons to proceed in this way, both related to the probability of success of the attackers. First, it is the only way to get access to the most valuable resources in a complex network topology with different layers of security. Considering that the most important assets in terms of information value are in the less reachable areas of the network [START_REF] White | [END_REF]] and that more resources are deployed to protect and control the assets with higher sensitivity [Rhodes-Ousley 2013], it would be almost impossible to successfully complete an attack against them performing a single-step attack only. A progressive step-by-step access towards the deepest part of the network seems necessary for the success of the attack. The attacker can take control of intermediary assets, called stepping stones or laundering hosts [START_REF] Strayer | [END_REF][START_REF] Goutam | [END_REF][START_REF] Daud | [END_REF], in the hope of finding new information about the path to follow or an easier access to the final goal.

Second, if the attack is decomposed in several steps, it is more stealthy and difficult to be identified by the defender, especially if some of the steps do not pose a risk to the system by themselves. The correlation of more than one action is needed to understand how the attack works and to identify the threat. Even if some authors claim that an attack with several steps is composed only of elementary attacks [START_REF] Brogi | [END_REF]], this is not necessarily true, and each individual step may seem harmless [START_REF] Chintabathina | [END_REF]], which makes detection more difficult.

In contraposition to single-step attacks, attacks of this kind are called multi-step attacks. The name addresses the ensemble of steps taken by one or several agents with a single specific unauthorized objective inside the network. For an attack to be qualified as 'multi-step', it has to be composed of at least two distinct actions. If actions are similar between them, it should not be called a multi-step attack. For example, in a DoS attack against a device or a service we can find millions of packets but each of them represents an instance of the same type of action. We consider thus a regular DoS attack as a single-step attack. It would not be considered as multi-step even if it is launched from several locations, what we call a DDoS attack by annexation of the word 'Distributed'. Attacks concurrently executed by more than one attacker, whether or not they are single-step or multi-step, can be also called multi-agent, distributed or coordinated attacks [Zhou 2010].

Since the beginning of 2000s [START_REF] Cuppens | Managing Alerts in a Multi-Intrusion Detection Environmen[END_REF], Dain 2001b, Julisch 2001], the security research community has tried to propose solutions to detect this kind of attack and to predict further steps. If they started to be identified as a mere combination of regular attacks, they have later acquired relevance and even their own names, as it is the case of WannaCry [START_REF] Mohurle | [END_REF]], cited in the opening paragraphs of this chapter.

Multi-step attacks have many alternative names: multi-stage attacks [START_REF][END_REF]], multistage attacks [START_REF] Du | [END_REF]], attack strategies [START_REF] Huang | [END_REF]], attack plans [START_REF] Qin | [END_REF]], attack scenarios [START_REF] Mathew | [END_REF]] or, finally, attack sessions [START_REF] Cipriano | [END_REF]]. Some authors, such as Yu and Frincke [START_REF] Yu | [END_REF]], even make a subtle distinction between 'multistep' as the characteristic of being composed of "temporally and spatially separated legal and illegal actions" and 'multi-stage' as the term to indicate that the steps can be complex attacks by themselves. However, for most of the authors both terms are equivalent and correspond to the first definition. We prefer the term multi-step attack, the one used throughout this thesis, because it seems to be the one better reflecting the difficulties faced in the detection of this type of attack, as the main challenge resides in the fact that the attack is composed of many steps which can be of very different natures.

There are also some authors who talk about Advanced Persistent Threats (APTs) [de Vries 2012], complex attacks [Çamtepe 2007] or targeted attacks [Trustwave 2018], especially in the security industry. These three last terms refer to a type of multistep attack that is specifically crafted against a single victim and where the access of the attacker to the target network is maintained during a long period of time. In the literature, most of the analysis and methods developed with a focus on APTs or targeted attacks address any type of multi-step attack.

The incidence of multi-step attacks

A complete multi-step attack needs to be represented by a group of correlated actions [START_REF] Kawakani | [END_REF]. That means that it is necessary to complement the process of detecting the individual actions with an additional process of finding the links between those actions [Ussath 2016b], highlighting the relationship between them. On top of this, the steps of some multi-step attacks can be scattered through several assets [START_REF][END_REF]]. This adds the additional difficulty of identifying and bringing together a set of heterogeneous and delocalized evidences. Moreover, this process is hindered by the high volume of events registered in the network [Zuech 2015].

The incidence of multi-step attacks in current computer networks is important. Most 2018 security predictions agree on the increasing sophistication of cyberattacks, which also points to an increment in the number of involved actions in a single attack [START_REF] Pandalabs | PandaLabs. Annual Report[END_REF], CrowdStrike 2018, Trustwave 2018]. An indicator of attack sophistication is the long dwell time, the period elapsed between the entrance of the attack in the network and its detection. If the time until detection is long, the attacker can perform more actions to get a goal. The figures given in several 2017 security reports are very similar, with an average dwell time never inferior to 80 days (see Table 2.1).

[Fire Eye 2018] 101 days of median dwell time [CrowdStrike 2018] 86 days of average dwell time [Trustwave 2018] 83 days of average dwell time There are at least two reasons for explaining the increasing incidence of multistep attacks. First, the detection capabilities of organizations seem to have improved in the last years, as pointed out by Mandiant in its M-Trends report [Fire Eye 2018]. Second, the multiple security layers that protect the most valuable assets [START_REF] White | [END_REF]] are forcibly multiplied [Albanese 2017] due to the increasing complexity of computer networks. This takes the appetizing assets further from the attacker. In consequence, attackers find more difficult to remain undetected and need to perform several intrusion steps to reach their final goal, aiming at being more stealthy and elusive [START_REF][END_REF]].

Summary

In this chapter, we have presented a series of definitions that are fundamental to fix the context where this research takes place. We have presented the concept of cyberattack and narrowed its scope to actions performed with a malicious intention using digital methods (sections 2.1.1 and 2.1.2). Vulnerabilities have been presented as an inevitable constraint of current networks (2.1.3) that impels us to the development of detection methods in the domain of cybersecurity (2.2). We have seen that traces preserve information about the actions of the users in any network (2.3). Finally, we have ended the chapter by explaining what are multi-step attacks (2.4.1) and considering their current incidence (2.4.2). This prepares us to the next chapter, where these attacks will be explored in detail. A man is nothing but the series of his actions.

Chapter 3

Multi-step attacks

-Hegel, Encyclopedia of the Philosophical Sciences

Cybersecurity is a discipline whose origin is determined by the existence of cyberattacks. The threat they pose to computer networks justifies the deployment of solid defenses, detection processes and mitigation procedures. We have seen in the previous chapters that this thesis is focused on multi-step attacks, whose analysis will be the subject of the sections below.

We start our exposition in section 3.1 by giving a classification of multi-step attacks and clarifying the notion of Advanced Persistent Threats (APT), a subtype often unduly used as homonym. The chapter continues with the presentation of several examples of this kind of attack in section 3.2. In section 3.3, we review how multi-step attack are modeled. Finally, we analyze the existent types of relationship between the steps in section 3.4.

Multi-step attacks in context

The definition of multi-step attack was given in section 2.4. We complete below this definition by comparing the example of WannaCry with a single-step attack (section 3.1.1) and by offering a classification of multi-step attacks according to several criteria (3.1.2). Responding to the increasing popularity of the term 'Advanced Persistent Threat', we also clarify the place of APTs among multi-step attacks (3.1.3).

Comparing single and multiple steps

To be studied from the point of view of the defender, the actions performed by the attacker need to be captured on traces, collected and stored pieces of information about what happens in the network (see section 2.3). A whole single-step attack can be represented by only one trace. For example, a log from an Apache web server representing a successful SQL Injection attack is shown in Figure 3.1. Only this log suffices to describe the attack. However, a multi-step attack has to be described by a consecution of traces. Think of WannaCry, the multi-step attack taken as an example during Chapter 1. We can identify the attack by a sequence of three actions. The first one is a HTTP request from a host h A to a long domain name to test if the malware is executed in a sandbox. If the HTTP request is unsuccessful, the attack continues by a connection in port TCP 445 from h A to another host h B . Finally, there is a SMBv1 communication between h A and h B using command 'transaction2_secondary'.

At least these three steps, each one innocuous by itself, are necessary to characterize WannaCry. Note that the traces of these actions should not forcibly be searched in the same asset. The first one is more likely to be registered by an asset working with HTTP-related traffic, at the application level, such as a proxy or a DNS server. On the contrary, the other two are usually detected by a network asset able to deal with several layers in the OSI model, such as a firewall.

This set of steps constitutes a narrative of the attack. It is a straightforward matter to draw a temporal line joining the different actions or steps involved in the story. The result is a graph such as the one shown in Figure 3.2. We will see throughout this chapter that some other types of relationship between actions can be used to link them and model the attack as a graph, besides the temporal order.

A classification of multi-step attacks

In the reviewed literature, we have not found any reference proposing a classification of multi-step attacks. Nevertheless, the bibliographic research done during the elaboration of this thesis has revealed that multi-step attacks have certain features dif- ferentiating them. Based on these features, we propose the classification listed below and shown in Figure 3.3, according to four criteria.

Multi-step attacks in context h

A h A h B h A h B
• Activity location. A multi-step attack is scattered if the actions composing it take place in, at least, two different assets in the network. Conversely, it is gathered if all the steps happen in the same asset.

• Attack agent. An attack can be human-driven if the actions are directly executed by a human or malware-driven if the execution is automatically performed by a malicious piece of software. In a human-driven attack, the attackers gain knowledge about the target system after each of the steps of the attack [START_REF] Katipally | [END_REF]] and are able to better prepare the subsequent steps. On the contrary, in malware-driven attacks, the malware tries actions from a list in a predefined order. Information about the state of the system is gathered but it is not processed by human creative thinking. There also exist attacks that can have parts driven by malware while others are directly executed by a human attacker. We call them mixed-agent attacks.

• Presence of evidence. An attack that does not raise an alert in any security system at the victim's organization is considered as stealthy. If its activity is signaled by at least one alert, it is called discernible.

• Focus. An attack can be targeted or generic depending on whether it has been specially adapted against the victim or not, respectively. A completely human-driven multi-step attack is considered to be targeted1 , as the behavior of the attacker is adapted to the particularities of the victim after each step.

When the term 'multi-step attack' or any of its synonyms is used, authors generally refers to scattered human-driven discernible targeted attacks. We will see attack examples and their classification later in this chapter.

It is important to note that the defined categories, except the one referring to the Chapter 3. Multi-step attacks location of activity, could also be applied to single-step attacks. It is not the purpose of this thesis to offer a full classification of attack types. The classification is limited to the object of our study, multi-step attacks. Multi-step attacks can leave traces in the network where they take place. The ensemble of traces collected by any asset of the network containing information about any of the steps composing the attack is called in this thesis an evidence set. There are two kinds of evidence set: homogeneous and heterogeneous. An evidence set is homogeneous if all the traces contained in it have the same format, thus they are emitted by the same type of asset. A heterogeneous evidence set is composed of traces having at least two different formats, thus with a different origin. Among homogeneous evidence sets, if all the traces come from a single source the set is called homogeneous single-source. Otherwise, it is homogeneous multi-source. In Chapter 4, we will see that most of the past work dealing with multi-step attack detection use as an input a homogeneous single-source evidence set.

Advanced Persistent Threats

Since the beginning of the decade [de Vries 2012], the name Advanced Persistent Threat (APT ) has been used to denote multi-step attacks that use specialized malware and where the access of the attacker to the target network is maintained during a long period of time [Hu 2017]. Not every multi-step attack is an APT. As WannaCry infection [START_REF] Mohurle | [END_REF]] has recently demonstrated, even global malware campaigns, that are not targeted, can be based on an attack that can be decomposed in multiple steps affecting several assets in the network.

The term APT has become somehow distorted after having been adopted by the industry and used in marketing campaigns. Moreover, a lack of rigorous definition of what an APT is [Chen 2014b] makes this term valid for other contexts, as for attacks using advanced malware but being single-step.

The steps involved in an APT and their order are described in the literature under many forms, depending on the author defining them [Luh 2016]. For instance, Chen et al. [Chen 2014b] define six stages: (1) reconnaissance and weaponization; (2) delivery;

(3) initial intrusion; (4) command and control; (5) lateral movement, and (6) data exfiltration. In contrast, Hutchins et al. [START_REF] Hutchins | [END_REF]] define seven stages: (1) reconnaissance; (2) weaponization; (3) delivery; (4) exploitation; (5) installation; (6) command and control, and (7) actions on objective.

Examples of multi-step attacks

In this section we give some illustrative examples of multi-step attacks. These attacks are used in the experiments performed to validate our scientific contribution (Chapter 7) and in the examples shown throughout this thesis. WannaCry, explained in section 3.2.1, is an example of scattered malware-driven generic multi-step attack. In terms of presence of evidence, it can be stealthy or discernible depending on the systems implemented in the attacked network. The rest of the presented attacks are scattered human-driven discernible targeted multi-step attacks: LLDoS 1.0 and LLDoS 2.0.2 (section 3.2.2); UNB ISCX island-hopping (3.2.3), and HuMa (3.2.4).

WannaCry

We have already talked about WannaCry, the most important cyberattack in 2017. It has been the most notorious example of a multi-step attack crafted for a massive campaign, infecting more than 230,000 computers based on around 150 different countries [Ehrenfeld 2017]. Due to its relevance, we have chosen it to illustrate the exposition of the methods and the examples given throughout this thesis.

WannaCry is based on the use of a ransomware, a type of malicious software that locks the access to the file system of a computer, asking for a ransom in exchange of Chapter 3. Multi-step attacks going back to normal functioning [Kharraz 2015]. To compromise the victim machines, WannaCry takes advantage of an exploit called EternalBlue, stolen from the United States NSA (National Security Agency).

The steps followed by WannaCry are listed below:

1. Infection through EternalBlue. EternalBlue exploits a SMBv1 vulnerability using remote code execution through the TCP port 445. After opening the connection with the victim, the exploit sends several 'transaction2_secondary' SMB requests and, thanks to an error in the processing of these requests, gets access to the system [START_REF] Kulkarni | [END_REF]].

2. Access to the victim. The attacker guarantees her persistence on the victim machine using the DoublePulsar backdoor [CERT-MU 2017].

3. Sandbox test. The malware attempts to connect to a specific remote URL. The domain in the URL is not registered, so the connection in normal conditions would be unsuccessful. However, there exist virtual test environments (called sandboxes) with a mechanism that tries to fool malware code by giving a false signal of successful connection for any connection attempt. The theory proposed by researchers having studied WannaCry2 is that this step is performed just to check if the malware is in a sandbox or not, as the execution only continues when the response to the request is unsuccessful [EY 2017].

4. File encryption. A new service is started by the malware for trying to encrypt all the victim's files using a random AES-128 key [Panda 2017].

Demand of ransom.

A screen is shown to the victim asking for a ransom in bitcoins in exchange of the decryption key.

The malware used by WannaCry is a worm, so it has self-replicating capabilities [START_REF] Kramer | [END_REF]]. The propagation through the network is done using the same Eternal-Blue exploit and therefore is only effective against assets running Windows and using a vulnerable version of SMB [START_REF] Kulkarni | [END_REF]].

Notice that the first one of the representative actions represented in Figure 3.2 corresponds to the third infection step, while the two others represent the subsequent propagation of the malware (repetition of the first infection step).

LLDoS 1.0 and LLDoS 2.0.2

There are two multi-step attacks contained in the DARPA 2000 Intrusion Detection Scenario Specific Data Sets (see section 7.1.1, page 170), LLDoS 1.0 and LLDoS 2.0.2. The goal of both attacks is to take control of several hosts within the network and to launch from them a DDoS attack targeting an external victim. However, the followed process is not the same for the two. First, LLDoS 1.0 can be decomposed in the following five attack steps [Zhu 2006, Cheng 2011[START_REF] Kavousi | [END_REF][START_REF] Ramaki | [END_REF], Wang 2016[START_REF] Holgado | [END_REF], that are represented in Figure 3.4:

1. IP address sweeping. The attacker tests several IP addresses to identify which ones among them correspond to operative hosts. The scan is performed using ICMP (Internet Control Message Protocol) echo request packets [DARPA 1981a], known as 'pings', on several class C subnets in the network [START_REF] Kavousi | [END_REF]].

2. Sadmind ping. Among the active IP addresses identified, the attacker searches for Solaris hosts with the sadmind program running. The sadmind program is a

Chapter 3. Multi-step attacks daemon used for providing distributed system administration. It is implemented as a RPC (Remote Procedure Call), which allows providing a remote service using a method similar to classical procedure call [Nathoo 2005].

3. Privilege escalation. The attacker attempts to exploit a sadmind vulnerability in the found hosts. The exploitation is based on the insertion of a long string within a specific sadmind request, which could overflow a buffer associated to one of the function in sadmind, 'amsl_verify ' [Internet Security Systems 2001].

The process is successful in three hosts (called Mill, Locke and Pascal), where the attacker creates an account named 'hacket2' with administration privileges [START_REF] Lee | [END_REF]].

4. Trojan installation. The DDoS-Mstream trojan is installed on the three captured hosts using telnet and rsh. One of them (Mill) becomes the master who will control the other two when launching the DDoS attack. LLDoS 2.0.2, represented in Figure 3.5, has the same objective but it is stealthier. This time the attacker first breaks in a host and then uses it as a stepping stone (see page 21) to compromise another host. It is also composed of five steps [START_REF] Farhadi | [END_REF][START_REF] Ramaki | [END_REF], Shittu 2016]:

1. DNS probing. Instead of doing IP Address Sweeping, the attacker directly probes the public DNS server in the network, hosted in the Mill host, using the DNS HINFO query [START_REF] Mockapetris | Domain names -Implementation and specification[END_REF]].

2. Privilege escalation. The sadmind vulnerability is exploited in Mill. The exploitation process is the same as the one followed in LLDoS 1.0 (step 3).

3. Trojan installation. The DDoS-Mstream trojan is uploaded to Mill using FTP. Note the difference with LLDoS 1.0, where the trojan is directly installed using telnet and rsh (step 4).

4. Host hopping. The attacker runs the trojan in Mill server and tries to break in two other hosts, using Mill as stepping stone. Only one of those attempts succeeds, the one targeting the host Pascal.

5. DDoS attack. The same DDoS attack performed in LLDoS 1.0 (step 5) is launched with Mill as a master and Pascal as a slave.

We shall not confound the DDoS attack launched at the end with the whole process of intrusion seen in LLDoS 1.0 and LLDoS 2.0.2. These two attacks are multi-step, but the DDoS attack is not. Several actions are performed in the DDoS attack (the packets sent by each host) but they are repetitive. The DDoS attack could be performed by itself from a computer legitimately under the control of the attacker. However, some authors [START_REF][END_REF][START_REF][END_REF], Shittu 2016[START_REF] Holgado | [END_REF]] take the liberty of giving the name 'DDoS attack' to the two versions of LLDoS, leading to confusion.

UNB ISCX island-hopping

This island-hopping attack, represented in Figure 3.6, is contained in the ISCX 2012 Intrusion Detection Evaluation Data Set (see section 7.1.2, page 172). It is composed of the following steps:

1. Email with attached exploit. A system upgrade email is sent under the identity of admin to all the users in the network. This email contains a PDF file with an exploit that uses vulnerability -2008-4037) is exploited and user12 is also captured by the attacker.

5. Second scan. Another scan is launched from user12 towards the subnet where the internal servers are located, with IP addresses in range 192.168.5.0/24.

6. SQL Injection. The attacker identifies a server running an internal web application using MS SQL and creates a remote desktop connection to user12 for launching a SQL Injection attack from it. The details of this attack are well explained by the creators of the dataset [Shiravi 2012].

7.

Backdoor. In order to keep the connection from user12 to the server active and thus be able to perform further web-based attacks, the attacker establishes a backdoor connection between user12 and her own computer.

HuMa

The multi-step attack contained in the HuMa dataset (see section 7.1.3, page 172), represented in Figure 3.7, is composed of the following steps:

1. Port scan. A discrete port scan against the web server of the organization, in order to collect information.

2. Unsuccessful SSH brute-force attack. A brute-force attack against the SSH service in the web server, identified thanks to the previous step. This attack consists in trying different passwords on the login system of SSH until one of them works.

3. Successful SSH brute-force attack. As the previous brute-force attack against the web server is not successful, a second attack of this kind is performed against the mail server of the organization from a local asset. The steps of scanning and capturing this local asset are not contained in the HuMa dataset.

Probably they were done before the beginning of log collection. This time, the attacker successfully gets access to the SSH service.

Modeling multi-step attacks

An important question when facing multi-step attacks is how we are able to describe them in order to a) share the information about them with other systems or partners and b) feed a detection system with an exploitable description. The answer given to this question strongly depends on the features that are considered relevant to describe the attack. The purpose of this section is to review how multi-step attack modeling has been approached in the literature, taking the traces left by their execution as the building pieces of the model. We start defining the attack as a sequence of traces in section 3.3.1. The following section, 3.3.2, is dedicated to the languages to model multi-step attacks, used by some of the detection methods in the literature (see Chapter 4). In most of the publications about multi-step attack detection, a graph is used to model a multi-step attack from this sequence of traces. In section 3.3.3 we describe this type of model, that is called Concrete Attack Scenario Graph (CASG) throughout this thesis.

The attack as a sequence of traces

We can describe a multi-step attack by the set of traces left during its execution, as they were defined in section 2.3. This set can be ordered in time, as every trace has a certain timestamp associated to the moment when the represented action took place. To do this, we assume that all the clocks in the assets generating the traces are synchronized. It is a reasonable assumption if there is a NTP (Network Time Protocol) infrastructure in the network [START_REF] Mills | [END_REF]]. Using this time synchronization protocol, we can share the clocks of every asset in the network to a very low precision (232 ps) [Mills 2016]. Given that the timestamps of the traces we study have a precision of 1 second, a network using NTP should not have any synchronization problem in their traces. However, apart from time synchronization there exist other problems that can lead to not reliable timestamps, such as implementation errors at software or hardware level [START_REF] Micheel | [END_REF]]. These problems lie out of the scope of this thesis and will not be further considered.

The identification between step and trace is not always direct. A single action can be at the origin of multiple traces. For this reason, some authors aggregate the traces in a first stage and then work with abstract entities containing several traces. The goal is to make these abstract entities to better correspond to the attacker's actions. For example, a step corresponding to a brute-force attack, as it is the case of two of the steps in the HuMa attack (see section 3.2.4), generates one trace per failed login attempt. All these traces could be aggregated into one trace with the tag 'Bruteforce attack', to make the ensemble to correspond to the step in the multi-step attack. In the case of having only alerts as traces, the resulting aggregated traces are called 'hyper-alerts' [START_REF] Ning | [END_REF][START_REF] Anbarestani | [END_REF]. Inspired by this notation, we give the name 'hyper-trace' to the abstract entity containing an aggregated set of traces.

Languages to model multi-step attacks

In this section, we review some of the existent languages to describe multi-step attacks. We have found two families of languages: those based on prerequisites and consequences, presented in section 3.3.2.1, and another based on Petri nets, reviewed in section 3.3.2.2. Reviewed languages not fitting in any of these two families are presented in section 3.3.2.3.

Languages based on prerequisites and consequences

There is a family of languages for describing multi-step attacks that are conceived to be used on the detection methods based on prerequisites and consequences, that will be described in section 4.3.2.1. These languages assign a set of prerequisites or preconditions and consequences or post-conditions to each possible type of event. The cited detection methods use this knowledge to connect the events if they share pre and postconditions. Both the languages and the detection methods in this category limit themselves to the analysis of IDS alerts, as it is a trace with a limited and known list of types that can be classified and described in causal terms.

The first created language in this family was LAMBDA [START_REF] Cuppens | LAMBDA: A language to model a database for detection of attacks[END_REF]], proposed by Cuppens and Ortalo in 2000. It was soon followed by JIGSAW [Templeton 2001] and CAML (Correlated Attack Modeling Language) [Cheung 2003]. All these languages are described below.

LAMBDA language [START_REF] Cuppens | LAMBDA: A language to model a database for detection of attacks[END_REF]] is based on logical formulas that code the state associated to the pre and post-conditions of each event. It can be divided in three 'sublanguages': L 1 , L 2 and L 3 . L 1 uses the logic of predicates, with regular logical connectives (^, _, ¬), to describe the pre and post-conditions. A metapredicate 'knows' is also included to represent the gain of information of the attacker. For example, to describe the pre-condition "the server S has port 22 serving SSH and the attacker A knows that SSH is active in S", the predicate port (ssh,22,tcp) knows(A,active_service(S,sshd)) would be used. On its side, L 2 defines the events by the identification of its attributes and using the logical connectives ¬ and ^. To adapt it to the inherent attributes used in this thesis (listed in Appendix C), if we want to define an event e as "having 202.77.162.213 as source IP address and 'Admind' as type of alert"4 , we would express it as ipsrc(e)=202.77.162.213 ^type(e)='Admind'. Finally, L 3 is conceived to combine several events. The list of operators for doing so is given in the publication. An additional element of L 3 is the possibility of pointing out an event e as 'optional' in the attack sequence, using brackets ([e]). L 1 , L 2 and L 3 are then combined to describe each individual attack, as it is shown in the example in Figure 3.8. Thanks to the pre and post-conditions, these attacks can be easily combined to represent a multi-step attack.

Capabilities and concepts are the two key elements in the definition of JIGSAW [Templeton 2001]. A capability is similar to a pre-condition in LAMBDA: it is the information required for an attack to occur. It is defined as a list of attribute/value pairs defining the condition. On its side, concepts are abstract situations that defines the connection between two steps. They have two blocks containing capabilities: 'requires', expressing the pre-conditions, and 'provides', containing the post-conditions. An additional block, 'action', indicates what to do if the concept is identified. The language used by Ning et al. in their detection methods (see page 79) is a variation of JIGSAW [Ning 2004a]. The idea of capabilities was later retaken by Zhou et al. in their model [START_REF] Zhou | [END_REF]] and by the language ACML (Attack capability modelling language) [START_REF] Pandey | [END_REF]].

In CAML (Correlated Attack Modeling Language) [Cheung 2003], every attack signature is called a module. Each module has three sections: 'activity', 'pre' and 'post'. The last two refer to a list of pre and post-conditions, and a list of predicate categories is given to define them. The activity section includes the events to be identified as part of the attack, by the definition of their attributes. CAML can be used by representing an individual IDS alert as a module or with each module containing the full set of events in the attack.

Languages based on Petri nets

A Petri net is a mathematical representation of the dynamic behavior of a system [Peterson 1981]. It consists on a series of nodes, called places, that are connected by transitions. An input and an output functions control the entry and the exit of the model, respectively. There exist a couple of languages to model multi-step attacks by means of a Petri net (EDL and EPNAM), and several detection methods using Petri nets as detection models [START_REF] Yu | [END_REF][START_REF] Yu | [END_REF], Vogel 2011a, Vogel 2011b[START_REF] Chien | [END_REF]. The most important of the language, in terms of impact in multi-step attack detection, is EDL, which is based on colored Petri nets and taint analysis.

The purpose of taint analysis is to track an information flow from the source to the sink of a graph. It is generally used for the analysis of flows of execution in computer programs [START_REF] Schwartz | [END_REF]]. In the case of describing sequence of events, source nodes in the graph contain templates matching some of the events coming into the system. Some of these nodes are tainted. All the events matching with a tainted source are tainted too, while the others rest untainted. As tainted events are propagated in the graph, by the arrival of traces matching subsequent nodes, they create a tainted flow. A set of rules, called taint policies, determines how flows are tainted. For example, we can consider that the logs coming from an untrusted source are tainted from the beginning but not the ones coming from a trusted source. Taint policies also define how the taint is propagated through the graph and to other events.

The graph and the taint policies can be designed to represent multi-step attacks as tainted flows of events. EDL (Event Description Language) is based on this principle. It was developed by Meier [Meier 2007] and later improved by Jaeger, Ussath and Chen [Jaeger 2015], and it uses a colored Petri net as taint graph. In this Petri net, transitions lead from a state to another through the occurrence of an event.

Even if basic EDL is built on the intuitive idea of constructing a sequence of nodes for representing the concatenation of different events, its formal specification includes very innovative mechanisms which allow an accurate definition of the rules. For example, it incorporates the idea of a token for signaling which event the system should search. A token is placed in the first node to search and it is then moved to the second node once the first one is found. However, sometimes it may happen that we do not want to focus only on the first occurrence of the sequence, but we want to detect other events of the same nature as the first one but received after the first match. In this case, the token could be copied instead of being moved, so the system would be searching simultaneously (or by different processes, depending on the implementation) both the first event and the second one. Tokens in EDL are compliant with the principles of taint analysis. Figure 3.9: Example of a multi-step attack represented in a Petri net using the EPNAM language. Image from the publication where EPNAM is presented [START_REF] Zhao | [END_REF]].

Meier implemented EDL in a real system in Java, called jSAM, which works only for specific types of plugin. For overcoming this limitation, Jaeger proposes an extension of EDL being able to deal with normalized events in Object Log Format (OLF ) [START_REF] Azodi | [END_REF]], so any type of event can be represented in this format. The correlation using EDL becomes then more versatile. This also allows a more general rule definition mechanism. For example, a general rule for a brute-force attack can be written if we properly define which type of event represents a 'failed login' in each of the authentication systems in the network. The same rule would be valid for any of the considered authentication systems. Moreover, Jaeger et al. [Jaeger 2015] also propose to use the STIX (Structured Threat Information eXpression) format to make CTI (cyber threat intelligence) directly loadable in the security system that uses EDL. The main limitation to this is that CTI information is usually missing some context, as companies share only a very limited amount of information. The same laboratory also proposes the automatic derivation of EDL signatures from taint graphs [Ussath 2016a].

Another proposition of language using Petri nets to represent multi-step attacks is EPNAM (Extended Petri Net-based Advanced Persistent Threat Analysis Model) [START_REF] Zhao | [END_REF]]. However, it does not use tainting in flow propagation. The idea of EPNAM is an extension for multi-step attacks of the first attack model based on Petri nets that existed [START_REF] Mcdermott | [END_REF]]. An example of a multi-step attack represented in a Petri net using EPNAM is shown in Figure 3.9.

Other languages

There are other languages for representing multi-step attacks that do not fit into any of the categories described above. This is the case of ADeLe (Attack Description Language), that was developed in parallel to LAMBDA according to its authors Michel and Mé [START_REF] Michel | ADeLe: an attack description language for knowledge-based intrusion detection[END_REF]]. Anyways, it is not a language based on prerequisites and consequences like LAMBDA, as it is oriented to the full description of the multi-step attack and not to the definition of individual attacks that can be combined. The description of each attack is divided in three parts: the exploit, the detection and the response. The exploit part represents the point of view of the attacker, giving details about the code used to perform the attack, its pre-conditions and what the attacker gets after the execution (the post-conditions). The detection part contains a list of the events involved in the attack and a description of how they appear when the attack takes place: in an ordered sequence, repeated, with alternative names, etc. This part is intended to be used by a detection system. Finally, the response part defines the actions that should be taken by the defensive system to face the described attack.

STATL (State Transition Analysis Technique Language), developed by Eckmann et al. [START_REF] Eckmann | [END_REF], is a transition-based language conceived for centralized casebased detection, also used later in distributed detection [START_REF] Valeur | [END_REF]]. In STATL, an attack scenario is composed of a set of static elements and a dynamic behavior. The static elements are states or transitions, the two most fundamental concepts of this language. A state is a picture of the defended system at a certain moment. An attack represented in STATL is equivalent to a sequence of states, from a safe one to a compromised one. A transition represents the movement from one state to another by the means of an associated action. This action is only triggered by certain events, which make the next state possible. The dynamic behavior determines how a scenario evolves in a context of intrusion detection on incoming events.

While STATL is specifically thought for being used by a low-level search engine, Morin and Debar [START_REF] Morin | [END_REF]] propose to apply a high-level description based on Dousson's chronicle formalism [START_REF] Dousson | Suivi d'évolutions et reconnaissance de chroniques[END_REF]]. A chronicle is defined as a set of events that are connected according to certain time constraints. Time becomes in this formalism the main factor to determine the relationship between the events, which are defined by a series of rules. The chronicle formalism has been integrated in the M2D2 platform [Morin 2002]. Some other authors have adapted this language for other platforms [Wang 2004, Wang 2005a].

Apart from the languages already mentioned, there are some others, such as IDDL (Intrusion Detection Description Language) [START_REF] Tabia | [END_REF]] or PDDL (Planning Domain Definition Language) [START_REF] Hu | [END_REF], that have been also used in the description of multistep attacks. Almost every language conceived for event correlation [Sánchez 2003] could be use, in less or major extent, to represent multi-step attacks. The languages reviewed here are the most relevant ones among the ones specifically created for multistep attack representation, and the ones more connected to the contributions of this thesis.

Concrete Attack Scenario Graphs (CASG)

All the traces generated by a multi-step attack represent a sequence of steps in the pursuit of an objective. We could thus imagine a set of relationships between some of them and represent the set of traces as nodes in a graph, with the relationships defining the edges [START_REF] Valeur | [END_REF][START_REF] Shin | [END_REF][START_REF] Holgado | [END_REF]. A graph G = (V, E) consists of two non-empty finite sets, V (G) and E (G) [START_REF] Thulasiraman | Graphs: theory and algorithms[END_REF]]. The first one is the set of vertices, also called nodes [Wilson 2010]. In our case, each one of the nodes

v 1 , v 2 , . . . , v n represents a step of the attack in the form of traces ✓ 1 , ✓ 2 , . . . , ✓ n . E (G)
is the set of edges, which are pairs of distinct elements of V (G) that represent a relationship of certain kind between the two nodes (traces) composing them. Each edge contained in E (G) is named by the juxtaposition of the symbols representing the nodes joined by it. For example, v a v b is the edge joining nodes v a and v b .

Once a graph is built, we can consider traveling through it from node to node, using the edges as routes between two nodes. We define a trail as a finite alternating sequence of nodes and edges where all edges are distinct. If all nodes are also distinct, a trail is called a path. A graph is connected [START_REF] Thulasiraman | Graphs: theory and algorithms[END_REF]] if there exists a path between every pair of nodes. A circuit is a trail with all nodes distinct except for the one starting and the one finishing the sequence, that are identical. The sequence

[v 0 , v 0 v 1 , v 1 , v 1 v 2 , . . . , v k 1 , v k 1 v k , v k ] is thus a circuit if v 0 6 = v 1 6 = v 2 6 = . . . 6 = v k 1 , v 0 v 1 6 = v 1 v 2 6 = . . . 6 = v k 1 v k and v 0 = v k .
Another concept in graph theory that we are using in this thesis is that of a directed graph. An informal but intuitive definition of a directed graph is that it is a graph whose edges have an associated direction, namely v a v b 6 = v b v a [Bóna 2002, Guichard 2017]. Formally, a directed graph or digraph D consists of a non-empty finite set V (D) of vertices and a finite family A (D) of ordered pairs of elements of V (D) called arcs [Wilson 2010]. Arcs can also be called directed edges [Bóna 2002, Bollobás 2013] to make the sense of direction explicit.

Each node v a in a directed graph has an in-degree, the number of arcs of the form v x v a , and an out-degree, the number of arcs of the form v a v x . In other words, the in-degree is the number of arcs going in the node and the out-degree is the number of arcs going out. A node is called a source if it has in-degree 0 and a sink if it has out-degree 0. A directed graph with only one source is called single-source. A tree is for example a type of single-source graph.

Most researchers use directed acyclic graphs (DAG) to represent multi-step attacks [Cuppens 2002c, Ning 2002c[START_REF] Valeur | [END_REF][START_REF] Zhai | [END_REF][START_REF] Shin | [END_REF][START_REF] Holgado | [END_REF]. A DAG is a directed graph without any directed circuit [START_REF] Van Steen | Graph theory and complex networks[END_REF]. In other words, if we choose a node in a DAG we cannot find a walk from node to node that brings us back to the initial node. To our knowledge, in every publication about multi-step attack detection, arcs in an attack model follow the temporal evolution of the steps, going from the step that happens before (trace with older timestamp) to the step that happens after (trace with newer timestamp).

Even if the arcs are not explicit, a multi-step attack represented as a sequence of traces [START_REF] Chintabathina | [END_REF][START_REF] Brahmi | [END_REF], Li 2016] can get its elements connected to form a graph. There are also authors using non-directed graphs [Wang 2006d[START_REF][END_REF] or unordered sets [START_REF] Qiao | [END_REF], Zhang 2015]. These representations could be adapted to directed graphs, as we always count with a feature in the steps to give an order to the ensemble: the timestamp. A directed graph can be created just connecting the series of steps ordered in time. Even if there are two traces with exactly the same timestamp, we could assign an order based on any other of their attributes.

It is worth mentioning that there is an abuse of language in the multi-step attack detection literature when talking about directed graphs. Not many authors [START_REF] Stotz | INformation Fusion Engine for Real-time Decision-making (INFERD): A perceptual system for cyber attack tracking[END_REF][START_REF] Yu | [END_REF][START_REF] Luo | [END_REF][START_REF] Ramaki | [END_REF]] use the term 'arc' to refer to the connections between nodes in a directed graph. Authors do generally assign the term 'edges' [Cui 2002, Zhu 2006, Jemili 2008, Alserhani 2010[START_REF] Saad | [END_REF], Luo 2016, Shittu 2016] or 'links' [START_REF] Mathew | [END_REF][START_REF] Brogi | [END_REF]] to the arcs, while they do not have the same mathematical meaning in Graph Theory [Wilson 2010, Bollobás 2013]. Some of them mention them as 'directed edges' [Kruegel 2002, Ning 2003b, Li 2007d[START_REF] Khakpour | [END_REF] but they abbreviate as 'edges' in most of the occasions. In this thesis, this abuse of language is not followed, and we call 'arc' to the objects joining two nodes in a directed graph.

Among the names assigned in the literature to a DAG representing a multi-step attack, we prefer the term 'attack scenario graph' [Ebrahimi 2011[START_REF] Saad | [END_REF], Zali 2012[START_REF] Kavousi | [END_REF]], because it allows differentiating the trace-based models 5 from attack graphs. An attack graph is an abstract representation of the network with each node representing an asset with a set of associated vulnerabilities. The term 'attack graph' is well established and broadly used to designate this specific meaning. However, some authors use it for referring to an attack scenario graph [Amos-Binks 2017], which can be confusing.

From the term 'attack scenario graph', we have coined a new one, 'Concrete Attack Scenario Graph' (CASG), to make a clear distinction between an attack scenario graph and the graph proposed in Chapter 5 to represent alternative multi-step attack cases. This term will be used throughout this thesis as an equivalent of an attack scenario graph.

Connection of nodes in the CAGS

We have seen that multi-step attacks can be modeled as Concrete Attack Scenario Graphs (CAGS), with the nodes representing the steps of the attack in the form of traces. The existence of an arc between two nodes depends on the relationship between both and is decided according to a set of conditions. The definition of the conditions for creating an arc has to be based on a series of comparison features associated to each pair of nodes.

To illustrate this, we present an example from outside the domain of multi-step attacks. Imagine for a moment that we want to model the network of citizens of Strasbourg that have met at least once. We would choose each citizen as a node and we would create an edge between any two citizens that have met. In this case, we have only one condition to create an edge, "the citizens have met at least once", based on the feature "number of times they have met". We could imagine many different conditions for joining two nodes (people), such as "both like jazz concerts" or "one is less than 2 years older than the other".

We distinguish between three kinds of feature associated to pairs of traces: similarity, time-based and context-based. Similarity features are only based on the own attributes of each trace, excluding time. For example, a similarity feature of a couple of traces could be having or not in common the author of the actions that generated the traces. Time-based features work with the time when the action represented in the trace took place. An example of time-based feature would be the difference in time between the actions. Finally, context-based features rely on the place of the trace in the context of all the registered traces in the network, on extrinsic information. For instance, a context-based feature of two traces can be the number of occurrences of both traces in the same day during the past year.

In our previous example using the citizens of Strasbourg, "both like jazz concerts" would be a condition based on a similarity feature; "one is less than 2 years older than the other", one based on a time-based feature, and "they have met at least once", one based on a context-based feature. Remember that features in this context are always associated to a group of two entities, with the goal of performing a comparison between both.

The features chosen for our model will determine the information coded in the arcs of the CASG. An ample set of comparison features can be found in the literature. We review them in the pages that follow: similarity features in section 3.4.1, time-based features in section 3.4.2 and context-based features in section 3.4.3. Finally, in section 3.4.4 we will learn how they can be combined to define the arcs of our multi-step attack model.

Similarity features

According to the Oxford English Dictionary, 'similarity' is the "state or fact of being similar" [OED 2018e], where 'similar' refers to "having a resemblance in appearance, character, or quantity, without being identical" [OED 2018d]. Given that, it is clear that the similarity between two elements is related to the characteristics they share and their differences. The maximum similarity is reached when the two objects are identical [Lin 1998]. The degree of similarity depends on the subjective point of view of the observer [Wang 1997] and on the characteristics chosen to be compared. Even though, similarity can be numerically represented if we define the frame in which the comparison is made. Given two elements, an assumption considered is that the similarity between them is not influenced by a third element [START_REF] Deepak | [END_REF]]. A pairwise similarity function can then be defined to compute the similarity between them. A similarity function is the expression in numbers of a similarity feature of the pair of elements. To unify the output of all similarity functions, independently of the nature of the feature, we work only with functions whose output is between 0 and 1, thus normalized.

According to Chen et al. [START_REF][END_REF]], given a set X of elements to compare, a function f : X ⇥ X 7 ! R is a normalized similarity function if, 8x, y, z 2 X, it satisfies the following properties6 :

1. f (x, y) = f (y, x) 2. 0  f (x, y)  1 3. f (x, x) f (x, y) 4. f (x, y) + f (y, z)  f (y, y) + f (x, z) 5. f (x, x) = f (y, y) = f (x, y) = 1 if and only if x = y
Adapted to multi-step attack modeling, we define a similarity function [Li 2016] S : ⇥ ⇥ ⇥ 7 ! R as a relation associating a value to two traces according to their degree of similarity with respect to the set of their attributes7 .

If a similarity function covers just one aspect of the compared elements, it can be called an atomic similarity function. The similarity between two objects is assumed to be the combination of all possible points of view of the object, under different perspectives. Given so, the global similarity between two elements can be calculated as the combination of the results obtained from atomic similarity functions [Lin 1998].

In the case of CASG, atomic similarity functions directly work with one or more inherent attributes of the compared traces (see section 2.3, page 17).

For example, we can think of an atomic similarity function returning 1 if both traces have the same source IP address and 0 otherwise. IP addresses are inherent attributes commonly associated to every trace, regardless the type of trace taken as input. They generally point out to the source of the action (ipsrc) and the destination or receptor of the action (ipdst). IP addresses are one of the most present attributes in the literature about multi-step attacks, because studied attacks usually go against victims that use the Internet Protocol and actions are generally executed at the level 3 of the OSI model.

Other attributes 8 for building atomic similarity functions are the ports used in OSI level 4 (psrc or pdst, for source and destination, respectively) or the Internet domain names (dom) [Zhang 2015]. In an environment where attacks generally happen at the link layer (OSI level 2), such as wireless networks, we can even find MAC addresses taking the role of IP addresses (macsrc or macdst) [Chen 2014a]. If steps are considered as actions of transformation on input objects (inobj ) to create output objects (outobj ), they can also be relevant attributes in the definition of the arcs [START_REF] Brogi | [END_REF]]. The type of the trace (type), assigned conforming to a certain classification, is also used as an attribute to compute similarity, especially when the traces are IDS alerts and are associated to a specific type of attack [START_REF] Qiao | [END_REF], Saad 2014]. Finally, the most complete list of attributes used to define the link between steps in a scenario, with 19 inherent attributes, excluding timestamp, is given by Pei et al. [START_REF][END_REF]] and showed in Table 3.1. They assign a name to the attribute (first column), which is associated to a certain type of event (second column). Most of them are specific of a certain service such as DNS (e.g. the queried domain name), HTTP (e.g. the response code) or the Windows Filtering Platform or WFP (e.g. the identifier of the process). An atomic similarity function does not need to forcibly work with the same attributes for both traces. For example, we can compare the ipsrc of one trace with the ipdst of another trace. This is useful when modeling attacks where there is a stepping stone, as there is a certain point when the destination of one step becomes the source of the following actions. For instance, in LLDoS 2.0.2 (see section 3.2.2), the IP address of the Mill host is first the destination of the privilege escalation and the trojan installation (steps 2 and 3) and becomes the source of the attack against Pascal (step 4). Comparison between different attributes in two traces is called crossed comparison. Oppositely, it is called direct comparison if the attributes are the same.

There are six kinds of atomic similarity function, according to the type of comparison done between the attributes. The arguments of each function are the attributes used, extracted from the compared traces ✓ a and ✓ b . Functions working with individual attributes use n a and m b to refer to the attributes in each trace, respectively, being n and m their names (see page 18). For example, if we compare the source IP addresses of the two traces, we would make n = m = ipsrc, so n a = ipsrc a and m b = ipsrc b . Conversely, functions working with a set of attributes from each trace refer to each set with capital letters. In this case, if we want to compare both source and destination IP addresses of the two traces we would have N = M = {ipsrc, ipdst}, so N a = {ipsrc a , ipdst a } and M b = {ipsrc b , ipdst b }.

According to this nomenclature, atomic similarity functions used in the literature are described below:

• Equality. It returns 0 if the values of the attributes are not the same, and 1 if they are the same. It is expressed as follows:

f 1 (n a , m b ) = 8 < : 1, if n a = m b 0, otherwise (3.1)
It is the simplest similarity function and the most used to describe the arcs between actions in a multi-step attack. Some authors use it to compare the source and destination IP addresses [START_REF][END_REF][START_REF] Saad | [END_REF], Saad 2014] or ports [START_REF][END_REF][START_REF] Kavousi | [END_REF], Wang 2016]. The destination of the action is often considered as the main binding element between the steps, and thus some authors focus on it to apply the equality function, either at port level [Zhu 2006, Shittu 2016] or at IP address level, taking the full address [START_REF] Du | [END_REF][START_REF] Haas | [END_REF] or just a subnet [START_REF] Xian | [END_REF][START_REF] Zhang | [END_REF]. Crossed comparison (n = ipsrc, m = ipdst) is also used [START_REF] Kavousi | [END_REF], Wang 2016]. In some work dealing only with alerts as traces, an equality function is defined by using the attack types assigned by the IDS [START_REF] Qiao | [END_REF][START_REF] Saad | [END_REF], Saad 2014]. Finally, the amplest set of equality similarity features is given by Pei et al. [START_REF][END_REF]] and shown in Table 3.2, using the attributes already presented in Table 3

f 2 (N a , M b ) = 8 < : 1, if N a \ M b 6 = ? 0, otherwise (3.2)
This function is generally applied to the source and destination IP addresses (N = M = {ipsrc, ipdst}), so their place does not matter [START_REF] Cipriano | [END_REF][START_REF] Xuewei | An approach of discovering causal knowledge for alert correlating based on data mining[END_REF], Faraji Daneshgar 2016[START_REF] Kawakani | [END_REF]]. The compared attribute lists do not necessarily need to be the same for the two traces, as shown by Wang et al. [Wang 2010], who use the sets N = {ipsrc, ipdst} and M = {ipsrc}. Other attributes used are the MAC addresses [Chen 2014a], in a wireless environment, and input and output objects (inobj and outobj ) such as computer processes or filenames [START_REF] Brogi | [END_REF]].

• Prefix similarity. To compute this similarity, a transformation in binary form is made for the two compared values. Then, the number of common bits is counted, starting from the left and stopping when there is an uncommon bit. The result of the similarity function is a value between 0 and 1 coming from the division between this number, called l, and the total number of bits L in the attribute values, which are supposed to have the same length:

f 3 (n a , m b ) = l L (3.3)
In the literature, this function is exclusively used for the comparison of IP addresses [Zhu 2006[START_REF] Qiao | [END_REF], Li 2016, Shittu 2016, Wang 2016], where L = 32.

It is a good measure of the proximity of hosts in the network because IP subnets are identified by the higher-order bits of the IP addresses.

textual similarity metric, such as lexical matching [START_REF] Metzler | [END_REF]] or the Jaccard similarity [Gomaa 2013]. We give the name d(x, y) to the function returning the distance between the texts in an interval [0, 1), with 0 representing equal texts. If x and y are strings of characters, we can define the textual similarity function as:

f 4 (n a , m b ) = 1 d(n a , m b ) (3.4)
As far as we know, Zhang et al. [Zhang 2015]

f 5 (n a , m b ) = h(D(n a , m b )) (3.5)
This similarity feature was first proposed by Julisch [Julisch 2003a] to compare IP addresses and ports and then reviewed by other authors [Wang 2006a, Ren 2010].

The hierarchy trees used are shown in Figure 3.10. In these cases, the metric is defined as a dissimilarity, the opposite concept of similarity. Other authors [Xiao 2008, Li 2016] apply a hierarchy-based formula but without giving an ex-plicit definition of the properties in the tree and the measurement of distances. • Ad-hoc formula. Finally, we can find similarity functions created ad-hoc for a specific attribute. For example, Kavousi et al. [START_REF] Kavousi | [END_REF][START_REF] Kavousi | [END_REF]] define a formula to compare IP addresses, where the resulting value depends on the lowest Internet Protocol address class (A, B, C, D or E) [DARPA 1981b] that they have in common:

f Kav (n a , m b ) = 8 > > > > > > > > > < > > > > > > > > > : 1, if n a = m b 0.8, if class C match 0.4, if class B match 0.2, if class A match 0, otherwise (3.6)
The presented similarity features are summarized in Table 3.3. In the first column we can see the general atomic similarity function associated to each feature next to the name of the feature. The second column shows the particular inherent attributes chosen for their implementation and in the third column we can find the references where those functions were presented and used for multi-step attack detection. Note that most of the similarity features are based on the source or destination IP addresses.

Time-based features

Every trace can store temporal information about relevant moments related to it: the moment when the represented action took place, when the trace was generated, when the trace was collected, etc. This information is represented as timestamps, strings recording a reference to an instant in time. For example, the log represented in Figure 3.1 (page 26) contained a timestamp signaling when the action took place: "06/Aug/2018:08:16:00 +0900".

Feature Implementation References

Equality [START_REF][END_REF][START_REF] Saad | [END_REF][START_REF] Haas | [END_REF]] [START_REF][END_REF][START_REF] Du | [END_REF][START_REF] Saad | [END_REF][START_REF] Haas | [END_REF] n = m = ipdst, masked [START_REF] Saad | [END_REF][START_REF] Xian | [END_REF][START_REF] Zhang | [END_REF]] [START_REF] Kavousi | [END_REF], Wang 2016] [START_REF] Kavousi | [END_REF], Wang 2016] [START_REF][END_REF][START_REF] Kavousi | [END_REF], Wang 2016[START_REF] Haas | [END_REF]] [START_REF][END_REF][START_REF] Kavousi | [END_REF], Shittu 2016] [ Wang 2016[START_REF] Haas | [END_REF] See Table 3.2 [START_REF][END_REF]] [START_REF] Xuewei | An approach of discovering causal knowledge for alert correlating based on data mining[END_REF], Kawakani 2016] [Faraji Daneshgar 2016[START_REF] Kawakani | [END_REF]] Li 2016, Shittu 2016, Wang 2016] Li 2016, Shittu 2016, Wang 2016] Li 2016, Shittu 2016] Julisch 2003a, Wang 2006a] Wang 2006a, Xiao 2008, Li 2016] Xiao 2008, Li 2016] Ad-hoc formula n = m = ipsrc [START_REF] Kavousi | [END_REF]]

f 1 (na, m b ) = = ( 1, if na = m b 0, otherwise n = m = ipsrc [
n = m = ipdst [
n = ipsrc m = ipdst [
n = ipdst m = ipsrc [
n = m = psrc [
n = m = pdst [
n = m = type [Saad 2012, Qiao 2012] Common element f 2 (Na, M b ) = = ( 1, if Na \ M b 6 = ? 0, otherwise N = M = {ipsrc, ipdst} [Cipriano 2011,
N = Set of inobj M = Set of outobj [Brogi 2016] N = M = {macsrc, macdst} [Chen 2014a] N = {ipsrc, ipdst} M = {ipsrc} [Wang 2010] Prefix similarity f 3 (na, m b ) = l L n = m = ipsrc [Qiao 2012,
n = m = ipdst [Qiao 2012,
n = ipsrc m = ipdst [Qiao 2012,
n = ipdst m = ipsrc [Qiao
n = m = ipsrc [Julisch 2003a] n = m = ipdst [
n = m = pdst [Julisch 2003a,
n = m = pdst [Julisch 2003a,
n = m = ipdst [Kavousi 2014]
Table 3.3: Atomic similarity features and their uses in the literature.

Timestamps are also inherent attributes of the traces, as they are independent of the information contained in other traces. However, they have certain particularities as a) its presence in every trace, no matter of which type, as it does not make sense to register of an action without an associated moment in time, and b) the special characteristics of the entity that it represents, time. Timestamps bind the trace to a certain moment in time. If two traces have everything the same except a timestamp, we can consider that they represent the same action repeated at different moments. Moreover, time serves to determine an order of actions, which is important for the causality: supposing that the timestamps are well synchronized, an action with a greater timestamp cannot be the cause of an action with a lower timestamp. In other words, an action taking place before another one cannot be the consequence of this last one. Finally, as time can be represented as a scalar, we can easily define a metric. The distance in time between two traces can be a good indication of scenario membership [Dain 2001b].

The same as we defined similarity functions for other inherent attributes, we can define a set of functions linked to different time-based features. To simplify the presentation, the absolute value of the difference in time between ✓ a and ✓ b is called t a,b , namely t a,b = |✓ b (time) ✓ a (time)| = |time b time a |. The functions associated to each time-based feature are presented below:

• Threshold limit. Used by many authors to defined the limits of a multi-step attack, it establishes that two traces are related if the difference of time between their occurrence is less than a certain threshold ⌘ [Wang 2010, Wang 2016[START_REF][END_REF][START_REF] Zhang | [END_REF][START_REF] Kawakani | [END_REF]]:

f t 1 ( t a,b , ⌘) = 8 < : 1, if t a,b  ⌘ 0, otherwise (3.7)
In some cases, it is practical to check this limit using sliding time windows when an algorithm for multi-step attack detection is implemented [START_REF] Soleimani | [END_REF][START_REF] Cipriano | [END_REF], Chen 2014a[START_REF] Xian | [END_REF][START_REF] Zhang | [END_REF]. A time window is a subset of traces ordered in time where the difference in time between the first and the last traces of the subset is less than ⌘. We can make this window 'slide' over the traces, always maintaining the same time difference between the limits of the window.

• Gaussian function. Li et al. [Li 2016] propose a Gaussian formula to express the time difference by a continuous value:

f t 2 ( t a,b , ⌘) = 8 < : e ⇡ t a,b 2 , if t a,b  ⌘ 0, otherwise (3.8)
f t 3 ( t a,b , ⌘) = 8 < : 2 1+e t a,b , if t a,b  ⌘ 0,
otherwise (3.9)

• Linear decay. [START_REF] Kavousi | [END_REF][START_REF] Kavousi | [END_REF]] propose a function with a linear decay that they use in combination with time windows. They define two time thresholds, T W L and T W T , called here ⌘ 1 and ⌘ 2 , respectively, to be consistent with the notation used in this chapter. They do not specify in their publications why they choose a linear decay function. It is possible they were looking for a decay function with low computational complexity. The proposed function is:

f t Kavousi ( t a,b , ⌘ 1 , ⌘ 2 ) = 8 > > > < > > > : 1, if t a,b < ⌘ 1 1 t a,b ⌘ 2 ⌘ 1 , if ⌘ 1  t a,b  ⌘ 2 0, if t a,b > ⌘ 2 (3.10)
This equation does not follow the rules for normalized similarity functions, as it is < 0 for some values, regardless the value of ⌘ 1 and ⌘ 2 . To solve this, we define a new function which, furthermore, is continuous. The idea of linear decay is preserved:

f t 4 ( t a,b , ⌘ 1 , ⌘ 2 ) = 8 > > > < > > > : 1, if t a,b < ⌘ 1 ⌘ 2 t a,b ⌘ 2 ⌘ 1 , if ⌘ 1  t a,b  ⌘ 2 0, if t a,b > ⌘ 2
(3.11)

• Reciprocal function. Qiao et al. [START_REF] Qiao | [END_REF]] present a formula based on a reciprocal function:

f t 5 ( t a,b , ⌘) = 8 < : 1, if t a,b < ⌘ ⌘ t a,b
otherwise (3.12)

Context-based features

Apart from being related by their similarity, traces can also be considered as part of the same scenario because of their place among other traces. A set of context-based features can be derived from their extrinsic attributes (see section 2.3, page 18). An extrinsic attribute represents a piece of information that is not contained in the trace, such as the probability of finding two traces of the same type together, which can be computed from historic data, or the causal relationship between two types of trace, information that can be manually coded from experience and stored in a knowledge base.

Unlike similarity features, context-based features are not related to a function depending only on the content in the traces. But they can also be expressed by a value between 0 and 1, derived from the context of the trace. Once they are expressed in a normalized form, these features work in the same way as similarity ones, indicating how strong the relationship between two traces is in terms of extrinsic attributes. We distinguish three types of context-based feature used in the literature: probability of appearance, known causality and structural information.

• Probability of appearance. As two traces are seen more frequently together, it is more probable that there is a relationship between them [START_REF] Mathew | [END_REF], Ren 2010, Marchetti 2011b, Faraji Daneshgar 2016]. The probability of appearance feature is based on this observation. To determine it, researchers have to choose first a similarity feature to form pairs of traces to be studied. Then, the value assigned to the probability of appearance can be deduced using a frequentist approach: dividing the number of occurrences of each pair by the total number of pairs. A time threshold has to be established: only pairs of traces whose difference in time is lower than the defined threshold are chosen to compute the frequency and, from it, to deduce the probability.

For example, a typical case is to associate the probability to the type of the trace, as in the work presented by Marchetti et al. [Marchetti 2011b]. In this case, two traces are considered as forming a pair if a) their difference in time is below certain threshold and b) the value of their inherent attribute type is identical. All the pairs fulfilling these two conditions are considered in the same group in order to compute the probability of appearance.

• Known causality, usually coded as a set of prerequisites and consequences related to each trace [START_REF] Pandey | [END_REF][START_REF] Wang | [END_REF][START_REF] Ning | [END_REF][START_REF] Alserhani | Alert correlation and aggregation techniques for reduction of security alerts and detection of multistage attack[END_REF]. In this case, the relationship of causality for each of the steps of the attack is known. Each step is supposed to prepare the conditions of the following steps so if the prerequisites of a trace match the consequences of a previous trace, they are linked and considered as part of a multi-step attack. The information about prerequisites and consequences have to be externally learnt and assigned to each type of trace. There exist languages to model this extra attributes, such as LAMBDA [START_REF] Cuppens | LAMBDA: A language to model a database for detection of attacks[END_REF]] or JIGSAW [Templeton 2001] (see section 3.3.2.1, page 37).

There are other ways, more rigid, to consider known causality in the definition of the model. If we previously know the consecution of steps in the traces representing a multi-step attack, we can build a static and abstract model based on causality. It is the case of the Hidden Markov Models (HMMs) presented by some authors [START_REF] Liu | [END_REF][START_REF] Mathew | [END_REF][START_REF][END_REF]]. These models are based on the typical phases of a multi-step attack, such as reconnaissance (e.g. network scan), attack and stepping stone, as defined by Chen et al. [START_REF][END_REF]]. These authors consider that all the traces belonging to a multi-step attack can be classified in one of these phases, that are ordered in time following a rigid logical progression [Dain 2001b].

• Structural information. Another way of defining a multi-step attack is by connecting the vulnerabilities affecting the assets within the network [Wang 2006e, Roschke 2011, Zali 2012, Fayyad 2013, Luo 2016]. This feature is focused on the conditions that should be met to be able to exploit the vulnerabilities and on the consequences that exploiting them can have for the system. These conditions can be modeled in an attack graph or an attack tree, an abstract representation of the network containing the vulnerabilities of the network assets in each node [START_REF] Sheyner | [END_REF], Shostack 2014] (see page 43). In a CASG, arcs defined by structural information are created between two traces if the actions represented by them correspond to two adjacent nodes in the attack graph.

A variation of the classic attack graph is the cyber terrain or virtual terrain, which incorporates additional data to each node, apart from the vulnerabilities, such as services and software version. Structural information is also used to build game models, where the links between the steps is based on the possible decisions of the attacker and the defender [START_REF][END_REF][START_REF] Luo | [END_REF].

The richness of the information sources determines the quality of a model based on one of these features. In the case of the probability of appearance, the model is purely based on statistics, so it is more adjusted to reality as more representative data is available. The quality of the other two context-based features depends on the experience of the people building the database of context information. In the case of models based on known causality, the database contains the causality information associated to each trace. On its side, structural information is built from a good knowledge of the defended network and its vulnerabilities.

Combination of features

The characterization of the arcs in a CASG depends on the relationship between the involved traces. Each CASG defines certain conditions of existence of an arc. We say that there is a correlation between two traces or that they are correlated if the conditions to build an arc between them are met.

Trace correlation. In the field of Statistics, the term 'correlation' denotes the "linear relationship between pairs of variables for quantitative data", and it is quantified by a correlation coefficient [START_REF] Witte | [END_REF]]. In Security, the broader sense of a mutual relationship between traces [OED 2018a] is taken, and the term is also applied to the process of finding a set of correlated traces to group them into an attack scenario [Kruegel 2004]. Therefore, we can say that "there is a correlation between these two traces" (equivalent to say "these two traces are correlated") but we can also refer to a method for building attack scenarios from traces as a "correlation method". The same as the correlation coefficient used in Statistics, we can define a correlation coefficient for each pair of traces in a dataset, giving it a value between 0 and 1 as we did with the features presented in the previous sections. We refer to this correlation coefficient as correlation weight to differentiate it from the statistical coefficient, which can take a value between 1 and 1. Depending on the author, it can also take other names, such as 'causal correlation' [AmirHaeri 2009] or 'correlation index' [START_REF] Colajanni | [END_REF]].

The correlation weight. This element can be used to quantify the conditions for linking two traces [START_REF] Soleimani | [END_REF], Bateni 2013a], by the combination of several partial conditions. These conditions are determined by the three kinds of feature previously defined: similarity, time-based and context-based. The correlation weight can be based on just a single feature, such as equality of destination IP address (f 1 (ipdst a , ipdst b )) [START_REF] Du | [END_REF]] or an IP address in common (f 2 (N, M ) with N = M = {ipsrc, ipdst}) [START_REF] Xuewei | An approach of discovering causal knowledge for alert correlating based on data mining[END_REF]]. But the most used approach is the combination of several features [START_REF] Cipriano | [END_REF], Saad 2014[START_REF][END_REF], in which the relationship between the traces in a CASG is considered to depend on several aspects of the traces [START_REF] Mathew | [END_REF]].

A correlation weight can be easily built as a mathematical combination of similarity functions, because the properties of these functions are preserved under addition and multiplication [START_REF][END_REF]]. But if a time-based or a context-based feature is expressed as a function with the same properties (see page 45), it can also be combined with similarity features [START_REF] Kavousi | [END_REF], Wang 2016]. We give the generic name of feature function to a function that expresses numerically a feature associated to a pair of traces and following the properties of similarity functions. Given that, we define a correlation function to compute the correlation weight as C : F ⇥ ⇥ ⇥ ⇥ 7 ! R, with F a set of feature functions. All correlation and feature functions throughout this thesis have a range [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1].

Once a correlation function is defined, a threshold has to be established to determine above which value an arc in the CASG exists between two traces. If the result of the correlation function is preserved and attached to the arc, the model is a weighted CASG. Otherwise, the CASG is non-weighted. Preserving the correlation value between the traces gives an idea of the strength of each arc under the imposed conditions.

We review below the most used methods for combining the results from several features to derive a correlation weight:

• Maximum of a set. One option to combine features is to take the maximum value among the results from the feature functions. This method is much used to reduce the set of features to be used for computing the correlation weight.

As an example we can consider the atomic similarity function based on prefix similarity (f 3 ), conceived to work with IP addresses. Imagine that each trace has two attributes based on IP addresses, ipsrc and ipdst, as it is usually the case. Therefore, we can apply f 3 in four difference ways:

f 3 (ipsrc a , ipsrc b ), f 3 (ipdst a , ipdst b ), f 3 (ipsrc a , ipdst b ), f 3 (ipdst a , ipsrc b ).
As in a multi-step attack there can be stepping stones, the four functions are not equally appropriate to define all the arcs in the CASG (see page 47). A crossed comparison would signal the hop to the stepping stone, but not the relationship between actions performed in the same host. Choosing the maximum among the results returned by the four functions guarantees that we select the most relevant value for each pair of traces in the attack.

Some authors follow this logic. Shittu, for instance, chooses the highest similarity between the results obtained from f 3 (ipsrc a , ipsrc b ) and f 3 (ipsrc a , ipdst b ), and does the same with the ones from f 3 (ipdst a , ipdst b ) and f 3 (ipdst a , ipsrc b ) [Shittu 2016]. However, Li et al. [Li 2016] preserve only the maximum between

f 3 (ipsrc a , ipsrc b ), f 3 (ipdst a , ipdst b ), f 3 (ipsrc a , ipdst b ) and f 3 (ipsrc a , ipdst b ).
For its part, Qiao et al. use a formula to combine them [START_REF] Qiao | [END_REF]]:

f Qiao (✓ a , ✓ b ) = max {f 3 (s a , s b ) + f 3 (d a , d b ), f 3 (s a , d b ) + f 3 (d a , s b )} 2 (3.13)
with s = ipsrc and d = ipdst.

The formula in general terms, given a set of feature functions F , is:

3.4. Connection of nodes in the CAGS 59 C 1 (F, ✓ a , ✓ b ) = maxF (3.14)
• Inclusive disjunction. Given a list of features, resulting correlation weight based on inclusive disjunction can only take two values: 1 if at least one of the features in the set holds or 0 if none of them holds. This is the same as saying that for having a value of 1, at least one of the feature functions of the set F representing the selected features has to return a value greater than a certain threshold :

C 2 (F, ✓ a , ✓ b ) = 8 < : 1, if 9f (x, y) 2 F | f (✓ a , ✓ b ) 0, otherwise (3.15)
For instance, Chen et al. [START_REF][END_REF]] consider that two traces belong to the same scenario if they have either the same source IP address, or the same destination IP address or the same destination port. Cipriano et al. [START_REF] Cipriano | [END_REF]] follow a similar logic but taking crossed equality of IP addresses instead of destination port equality. In the mentioned cases, the features are binary, so = 1.

• Arithmetic mean. The correlation weight is the average of several feature functions. Given that N is the number of feature functions f (x, y) contained in

F : C 3 (F, ✓ a , ✓ b ) = 1 N X f (x,y)2F f (✓ a , ✓ b ) (3.16)
This is the method used by Saad [START_REF] Saad | [END_REF], Saad 2014], who incorporates f 1 (ipsrc a , ipsrc b ), f 1 (ipdst a , ipdst b ) and f 1 (type a , type b ).

• Weighted sum. A weight 0  w i  1 is assigned to each one of the considered features. These weights should not be confused with the correlation weight: the first ones determine the importance of each feature in the second one. Each w i represents the importance of each feature for the final result. We choose the sum of all weights to be always equal to 1 [Li 2016[START_REF] Haas | [END_REF], to preserve the range of the correlation function. Some authors do so by normalizing the result afterwards [START_REF] Kavousi | [END_REF], Shittu 2016].

The weighted sum is given by the following expression, which is equivalent to the arithmetic mean if all the weights are equal:

C 4 (F, ✓ a , ✓ b ) = X f i (x,y)2F w i f i (✓ a , ✓ b ) (3.17)
There are many examples in the literature of correlation functions using weighted sums. [START_REF] Wang | Alert Correlation System with Automatic Extraction of Attack Strategies by Using Dynamic Feature Weights[END_REF]] propose a set of eight features: two similarity features based on equality and two based on prefix similarity. They are applied on the source and destination IP addresses (f

1 (d a , s b ), f 1 (s a , d b ), f 3 (s a , s b ) and f 3 (d a , d b )
, with s = ipsrc and d = ipdst). They also use two more similarity features based on equality of port numbers (f 1 (psrc a , psrc b ) and f 1 (pdst a , pdst b )); a time-based feature based on threshold limit (f t 1 ), and a context-based feature quantifying the probability of appearance of traces with the same type. On their side, Li et al. [Li 2016] propose three features: a hierarchy-based similarity feature on the destination port number (f 5 (pdst a , pdst b )); a similarity feature on the source and destination IP addresses, which combines the maximum of a set of atomic prefix similarity functions (see page 58), and a time-based feature based on a Gaussian formula (f t 3 ). Finally, Qiao et al. [START_REF] Qiao | [END_REF]] combine a similarity function based on IP addresses (see equation 3.13), a reciprocal time-based function (f t 5 ) and a similarity equality function working with the type of the traces (f 1 (type a , type b )).

• Sigmoid weighted function. Pei et al. [START_REF][END_REF]] combine the similarity features shown in Table 3.1 using a sigmoid weighted function:

C 5 (F, ✓ a , ✓ b ) = S 0 @ X f i (x,y)2F w i f i (✓ a , ✓ b ) 1 A = 1 1 + e P f i (x,y)2F w i f i (✓a,✓ b ) (3.18)
They choose to transform the weighted function in sigmoid because the learning algorithms they apply to determine the values of the weights do not guarantee a non-negative result. The sigmoid function maps the weighted sum to a bounded range between 0 and 1.

• Machine learning techniques. The correlation weight of a pair of traces can be also obtained by applying machine learning techniques on a set of features.

Zhu and Ghorbani [Zhu 2006] proposed in 2006 to do so by a multi-layer perceptron, the most widely used type of neural network [START_REF] Kruse | [END_REF]]. They use six features, the same as Wang and Chiou [Wang 2016] with the exception of f 1 (psrc a , psrc b ) and f t 1 . The results of the feature functions become the input of 3.5. Summary 61 the neural network, which outputs a value between 0 and 1 corresponding to the correlation weight. The network is trained using a test dataset of alerts.

Summary

An overview of what multi-step attacks are and how they are considered in the literature has been presented in this chapter. We have started by comparing them with single-step attacks (section 3. Once we have analyzed how multi-step attacks are modeled, it is time to review the literature proposing methods to detect them. The goal is to collect, explain and put in context the detection methods that aim to reveal the whole structure of the attack from the study of real traces. As far as we know, it is the first time that the field is systematically studied taken this perspective. The survey presented in this chapter is then considered as a scientific contribution of this thesis This survey was the object of a journal article published in July 2018 in the issue 76 of Computers & Security [Navarro 2018a], one of the most important journal in Cybersecurity with an Impact Factor of 2.651 . This chapter partially takes the bibliographic study presented in that article, whose corpus of publications has been updated to consider the period 2017-2018. Some papers have also been differently classified, thanks to the knowledge acquired since the final version of the article was submitted.

We open this chapter by presenting multi-step attack detection in section 4.1. We later explain the systematic methodology followed to compile and select the reviewed publications in section 4.2. The corpus of selected publications is then reviewed in section 4.3. The conclusions and the statistics extracted from this corpus are the object of section 4.4. Finally, in section 4.5, we review some security systems where the analyst is directly involved in the detection process, as we did not find almost any method with this characteristic among the reviewed multi-step attack detection methods. All the models proposed as contributions of this thesis consider the human analyst as an essential element.

Presenting multi-step attack detection

The goal of studying and modeling multi-step attacks is to prevent their occurrence, detect their execution, response against them and recover from their consequences. We saw in section 1.1 that detection is a key piece in the Cybersecurity scenario. Prevention does not suffice in a scenario where newly discovered vulnerabilities are rising (see Figure 2.1) and hardening the systems against every known vulnerability can bring a loss in flexibility [START_REF] Wang | [END_REF]].

Multi-step attacks pose a series of particular challenges for detection, such as the presence of innocuous steps or the existence of alternative actions to attain the same goal. But the sequence of traces left by the attackers often follows a logical progression [Dain 2001b], as it represents a set of actions with a single objective. If the security analyst is able to highlight the links between the involved traces, the strategy conceived by the attackers can be unveiled. Identifying the global structure of the attack in the set of traces reveals itself as important for detection.

This approach should not be confounded with the detection of the symptoms of the multi-step attack. For instance, a detection method that has been designed for detecting escalation of privileges in a Linux machine will certainly detect when an attacker tries to become superuser. But if this is just a single piece of a multi-step attack, we are far from identifying the whole threat [START_REF] Ghafir | [END_REF]], which can have further consequences. Perhaps the infection of the Linux machine was a way to have a stepping stone or just a distraction movement.

Even if some seminal work about the importance of linking several traces to detect an attack already existed [Vigna 1998], Huang and Wicks were probably the first ones that pointed out the importance of attack strategies in detection in 1999 [START_REF] Huang | [END_REF]]. The new millennium brought an awareness against this kind of attack and the analysis of the global attack strategy became important in security research.

In the publications addressing the problem of finding multi-step attacks in sets of traces there is not a clear distinction between the search in the past (investigation) or in the present (detection). Detection methods are generally evaluated using past sets of traces, as it is difficult to generate real-time data containing the execution of a multi-step attack. They are then evaluated as we would do with an investigation method working with the past. Most of the proposed search methods could then be applied both for investigation and for detection.

As far as we know, the systematic survey we have presented in Computers & Security [Navarro 2018a] and continued here is the first published survey about multistep attack detection methods that use traces as input. Apart from being a good point of reference for the work developed in this thesis, we consider this survey as a relevant work for the community. Because of that, we consider it as a contribution of this thesis in its own right.

A methodology for bibliographic research

Systematic search [Kitchenham 2004] is a rigorous method for literature review that makes the result easily reproducible but requires more effort than traditional reviews. Nevertheless, we have chosen this method to avoid missing relevant publications that are not much cited in the literature and thus difficult to find if the search is not exhaustive. The process we have applied to select a corpus of multi-step attack detection methods is inspired in the one used by Luh et al. [Luh 2016] for semantics-aware detection of targeted attacks. We present below the methodology used in the search, starting with the defined inclusion and exclusion criteria (section 4.2.1) and continuing with the description of each one of the three search phases (section 4.2.2).

Inclusion and exclusion criteria

In any bibliographic search it is important to establish a rigorous list of criteria defining which publications are included in the corpus and which are not. This list serves as a guide during the entire research process. The inclusion criteria pointing out the work to be included in our corpus is listed below:

• A multi-step attack detection method is described in the paper.

• The method works on real digital traces such as events, alerts or network packets.

This does not mean that it needs to be evaluated with real traces. It can be tested by simulation or case studies but it should have been conceived for the analysis of traces.

• The method considers the structure of the multi-step attack and the potential 66 Chapter 4. Multi-step attack detection links between the steps.

• The structure of the document is that of a scientific research publication.

• The method is described in a clear and evident way.

• The publication is written in English and with an understandable style.

A special emphasis should be given to the second inclusion criterion, concerning the trace-based functioning. There exists a vast number of methods belonging to the domains of vulnerability analysis or risk assessment whose goal is to generate a list of possible paths of an attack in the network to deploy defenses, predict which assets could be affected and evaluate the risks of an attack. Possible paths are usually represented in an attack graph, also called attack tree, a concept already introduced in page 43. Methods only based on structural and static models, such as attack graphs, are excluded from this survey, except if those models are used as an instrument for the projection of real traces, such as the methods presented in section 4.3.3.

A set of exclusion criteria is also considered, referring to the categories of publications not included in the corpus:

• Focused on multi-step attacks but not on detection. There are many papers that address multi-step attacks but do not propose a detection method, focusing on other topics such as languages for attack modeling, risk assessment, vulnerability analysis or application of security policies. While we are not interested in the three last topics, we already reviewed the modeling languages in section 3.3.2.

• Only focused on one aspect of multi-step attack detection such as executable file analysis [START_REF] Nath | [END_REF]] or C&C identification [START_REF] Lamprakis | [END_REF]], among others. They do not consider the perspective of linking the different steps in the attack.

• About flow-based detection, where the structure of the multi-step attacks is not revealed. In these publications, detection is done analyzing the statistical effects on traffic produced by the attack (e.g. [Lu 2017]).

• About state-based detection, where the method analyzes the changes of state in each of the machines in the network and deduces from there the potential occurrence of a multi-step attack (e.g. [START_REF] Vert | [END_REF]).

• Not about multi-step attacks. For example, about coordinated or distributed attacks, such as DDoS attacks, where multiple attackers may have a common objective but they do not necessarily perform multiple distinct steps in the network.

• Not in English.

• About single-step attack detection, even if it is claimed that they are oriented towards multi-step attack detection.

• Not research, such as articles published in non-scientific magazines and commercial whitepapers.

• Slides or posters.

• Duplicated. Documents containing exactly the same content but that were published in different places or whose reference appears twice under different names.

• Of low quality. In the selection of the publications, we follow the position defended by Glass [Glass 2000], who considers that a systematic survey should include all the references found in the studied domain, both good and bad ones. Anyways, as there is not a clear benchmark to test multi-step attack detection methods and most of the publications do not offer the possibility of reproducing the experiments (see section 4.4.3), it would be difficult to apply a narrow exclusion criterion based on the quality of results. However, we discard some references which are below a minimum level of quality in style, form and presentation; where:

-there is not enough detail to understand how the method works, -text cannot be well understood because a bad use of English or -some elements taken from the work made by other authors are not properly credited.

We do not cite in this thesis any of the work excluded in terms of quality. Number of citations is such a relevant metric for the evaluation of quality in current scientific research that citing work that we do not consider acceptable would do research a disservice. Information about discarded publications is available under request.

Research process

In this section, we present the research process followed in the systematic review. We divide the process into three phases: A) bulk search of keywords in several research engines, B) selection of relevant results and C) recursive search for references. These three phases, developed when writing the article where our first multi-step attack detection survey was published [Navarro 2018a], have been followed again to update the corpus with the new material published on 2017 and 2018. After this process, the bibliographic corpus about multi-step attack detection has a size of 201 publications.

Phase A: Using the research engines

We start the systematic bibliographic research by searching a selected set of keywords in IEEE, ACM, Web of Science and Google Scholar, the most important web-based search engines among the ones specialized in the scientific literature on Computer Science. The search is made only on the title of the publications. In the case of Google Scholar, we exclude patents and citations. Citations correspond most of the time to sources that are not openly available or to non-scientific resources.

The set of keywords used has been selected among the ones frequently appearing in the title of publications addressing multi-step attack detection. We use the symbol '+' to indicate the combination of different keywords in the same search, while the curly brackets ('{...}') enclose alternative choices. An 's' between parentheses denotes a word considered both in singular and plural. Words enclosed by double quotations are searched as an ensemble, literally as they are written. We list below the used sets of keywords. The number of full strings to search for each set is shown between square brackets:

• Set of keywords 1: advanced persistent threat(s) [2 strings]

• Set of keywords 2: APT + {analysis, architecture, defense, detection, framework, mechanism, mitigation, prediction, prevention, strategy, system} [11 strings]

• Set of keywords 3: {multi level, multi-layer, multi-stage, multi-step, multi-stage} + {intrusion(s), threat(s), attack(s)} [30 strings]

• Set of keywords 4: {"attack plan", "attack scenario", "attack strategy"} + {detection, prediction, recognition} [9 strings]

The resulting total number of strings to search is 52. A visual representation of these sets of keywords is shown in Figure 4.1, with the combination of their parts indicated by arrows.

Once the search is launched, we only download the publications related to cybersecurity. Some of the publications found belong to other domains, even if the keywords used are mainly related to cybersecurity. For instance, the acronym 'APT' can refer to concepts in Finances and Medicine.

Phase B: Filtering the results

The resulting publications from Phase A are reviewed one by one in Phase B. It is now when the inclusion and exclusion criteria listed in section 4.2.1 are applied for selecting only the references proposing multi-step attack detection methods.

The followed method for generating a "bibliography of candidate studies" is the one proposed by Meline [Meline 2006]. This method is applied in two stages. First, the titles and the abstracts are reviewed and the publications that clearly meet one or more exclusion criteria are discarded. Then, the remaining documents are read and we include in the corpus those ones meeting all inclusion criteria and not exclusion criteria.

Phase C: Recursive search for references

Once the filtering in Phase B is done, we perform in Phase C a recursive search of references among the ones cited by the selected publications and among the ones citing them. First of all, we review the ones cited by the current corpus. This process is iteratively repeated on the newly discovered set of publications until no more new references matching the inclusion criteria are found.

This recursive search has the problem that it is oriented 'towards the past', as found publications are always older than the ones found before. That is why in a second stage we also look for references citing the ones included in the corpus so far.

To do that we use Google Scholar, where the 'cited by' button associated to each reference returns a list of other references citing it. Again, the process is iteratively repeated on the new publications until no further reference is found.

Description of detection methods

The problem of multi-step attack detection has been addressed by many different ways during the 18 years elapsed since the beginning of the field. Proposed methods are varied and work on the basis of a model of the attack. For instance, if researchers consider that there is a common structure laying behind any multi-step attack, they will develop methods that try to found these common elements, perhaps using automatic tools based on machine learning. On the contrary, researchers that see a multi-step attack as an isolated instance could be more predisposed to build patterns adapted to each individual attack and arrange them in a knowledge base of signatures.

We have defined a classification for multi-step attack detection methods by the approach they follow. Some of the approaches are further split into categories. The taxonomy of the classification is shown in Figure 4.2. We find five kinds of approach:

• Similarity-based. The degree of similarity between traces determines the construction of the attack scenarios. We find three categories in this approach: progressive construction, scenario clustering and anomaly detection.

• Causal correlation. Detection is focused on the causal relationship between the steps of the attack. Methods under this approach can be further classify into one out of two categories: prerequisites and consequences or statistical inference.

• Structural-based. Incoming traces are projected into a model of the network, where future attack paths can be predicted.

• Case-based. Detection of well-known attack scenarios as sets of rules or attack signatures.

• Mixed. More than one of the approaches are followed but none of them stands out among the others.

In this section, we offer a brief presentation of the work under each one of the five approaches. In Appendix D, the reader can find all the 138 analyzed methods and the 201 publications presenting them, with a summary of their characteristics.

Similarity-based methods

Similarity-based methods propose the composition of scenarios according to the similarity between the individual steps of the attack, represented as traces. These methods are based on the idea that similar traces are related to the same root cause [Julisch 2001[START_REF] Salah | A model-based survey of alert correlation techniques[END_REF]] and they therefore belong to the same multi-step attack. Computation of the similarity degree is the central focus of these methods. This dis- tinguishes them from causal correlation methods, which do not consider how similar two steps are but how they are consequences of one prepare for the other or how often one follows the other.

The similarity degree between traces is based on one or several similarity features among the ones we presented in section 3.4.1 (page 45). The type and number of features and the attributes considered (IP addresses, port numbers, etc.) depend on the election of the authors. Some of them just consider the comparison of one feature [START_REF] Shaneck | [END_REF]] while most of them look at the combination of several of them [START_REF][END_REF], Zhu 2006]. When several ones are chosen, some of the features can be considered as more important than others through the application of a weighted correlation function (see page 59).

Time-based features (section 3.4.2) also come into play, as they do in almost every multi-step attack detection method, because the limited resources of the detection system do not allow the search of attack scenarios during an indefinitely long time span. A similarity-based method compares each trace with the traces that are in the temporal proximity of it. As the maximum temporal span chosen is larger, the number of comparisons is increased and the time spent during the detection process is longer.

The main advantage of similarity-based methods is that the implementation is easy and can return non-previously known multi-step attacks. The analysis is just based on comparison between pairs of traces, so systems implementing these methods have usually a good performance. However, choosing how the traces should be linked is far from being an easy task. If the linking process is kept simple, only relying on the similarity of a few attributes, the results will contain too many false positive alerts. On the contrary, a complex linking process can be too specific to capture the characteristics of the whole range of multi-step attacks.

It is important to note that a method solely based on similarity-based connections between traces would never be able to detect all types of multi-step attacks. The logical statement "in every multi-step attack there are common inherent attributes between all its steps" can be falsified by a counterexample: the attacks in the dataset DARPA 2000 presented in section 3.2.2. In these attacks, the last step, represented by a 'Stream_DoS' alert if packets are processed by the RealSecure IDS, does not have any attribute in common with the rest of the alerts. This alert is not even similar to the other ones in the attack, at least no more similar than to many other alerts that are not part of the attack, due to the IP spoofing done by the attacker. More information about the alerts in DARPA 2000 can be found in section 7.1.1, page 170. Effective similarity-based methods have thus to incorporate other techniques to become universally applicable.

We can classify similarity-based methods in three categories according to how similarity features are used to bring the traces together and form attack scenarios. First of all, we have a set of methods based on progressive construction, where the sequence of actions conforming the attack is built step by step by the addition of similar traces. Secondly, methods doing scenario clustering apply a clustering method to all the set of traces and return the clusters as possible scenarios, without considering the order of the steps as it happens in progressive construction. Finally, in anomaly detection methods, the similarity of incoming sequences of traces is computed against a set of non-malicious traces and sequences are considered as part of an attack scenario if they differ from normality.

Progressive construction

In progressive construction methods, a potential multi-step attack sequence is built step by step. Traces are appended to a scenario according to the degree of similarity between them and the traces already contained in the scenario. The difference with clustering methods is that the order of the actions is an important factor. In progressive construction, the sequences are built step by step and following a logical progression.

The match between the compared attributes can be exact or partial. An exact match is only based on equality similarity features (using the atomic similarity function f 1 , presented in page 48), while a partial match depends on a correlation weight (see section 3.4.4) combining several types of similarity features.

Valdes and Skinner [START_REF] Valdes | [END_REF]] are one of the first authors in proposing a multistep attack detection method based on progressive construction. Their method is integrated in the EMERALD system [Porras 1997] and is based on a similarity matrix that contains the manually crafted correlation weights between each type of trace. The do not specify which aspects of the traces are compared, but it is still one of the most cited references in multi-step attack detection. Inspired by this work, Dain and Cunningham [Dain 2001b, Dain 2001a] propose a system where each time an alert arrives at the system, the probability of being assigned to one or another scenario is computed based on a similarity comparison against the last trace in the scenario. The comparison depends on several factors, such as the IP addresses or the difference of time.

Apart from Dain and Cunningham, many other authors solely work with IDS alerts and consider the multi-step attacks as sequences of elementary attacks. For example, Ebrahimi et al. [Ebrahimi 2011] propose a matching algorithm using both source and destination IP addresses. On the other hand, Khakpour and S. Jalili [START_REF] Khakpour | [END_REF]] consider more elaborated features, such as prefix similarity of destination IP addresses (f 3 (ipdst a , ipdst b )) or equality of ports (f 1 (pdst a , pdst b )). Convinced that the inherent attributes of IDS alerts are not enough to determine the correlation between them, they propose to also incorporate correlation weights between alert types coming from expert knowledge. They are arranged in a correlation matrix. The details of the deduction of the weights are not provided in their publication.

The idea of a manually crafted correlation matrix had been already proposed three years earlier as the main brick of the Statistical Filtering algorithm [Wang 2006d, Wang 2006c]. Although the construction of sequences is automatically made based on statistical measures, the final verdict about their nature as attacks relies on the human-crafted correlation weights. The first author of this proposal, Li Wang, continued the development of her idea several years later [Wang 2010], introducing more sophisticated time windows, whose size evolves in time, and a classification of candidate scenarios in three groups according to the relationship between their actions. In the work by Tian et al. [START_REF] Tian | [END_REF]], the correlation matrix is built from the probability of having a type of alert following another. Weights in this matrix are applied in the linking process together with several similarity features A manually crafted correlation matrix is also the base of the RTEAS algorithm [AmirHaeri 2009].

On the contrary, in the correlation matrix proposed by Zhu and Ghorbani, called ACM (Alert Correlation Matrix) [Zhu 2006], the weights are automatically deduced from a reference set of alerts. This deduction, based on six selected similarity features, is done by two machine learning methods: Multilayer Perceptron (MLP) and Support Vector Machine (SVM). They conclude that MLP is more precise but that SVM has a higher training speed. While they apply automatic learning once the similarity features are quantified, Chih-Hung Wang and Chiou [Wang 2016] do it inversely. They execute the Bayesian learning process developed by Kavousi andAkbari [Kavousi 2012, Kavousi 2014] (see section 4.3.2.2) and consider the result as an additional feature to be combined with seven other features (see Table 3.3 in page 52).

Another way to differentiate the membership of an alert to a specific scenario is by the assignation of tags containing a list of input and output objects. The search of additional alerts connected to a specific tag is made by linking inputs and outputs. This is the basis of TerminAPTor [START_REF] Brogi | [END_REF], Brogi 2018], which takes the sequence of alerts as a flow of information to propagate the tags.

Instead of only working with IDS alerts, some methods in this category use them just as the first indicator of the presence of an attack. Once the alert is detected, these methods launch a process to look for traces that have certain attributes equal to the ones in the triggering alert. Searched traces do not have to necessarily be alerts, but they can be events or network packets. Once found, they are appended to the original alert to form the attack scenario. These systems are mainly based on the match between IP addresses and they get the needed data from different locations in the network. While the Active Event Correlation (AEC) [START_REF][END_REF]] is placed in the same machine where the IDS is, the other ones are designed to be placed in other parts of the network. Both the BDB (Bi-directional, Distributed BackTracker) system [King 2005] and STARLITE (Stealthy Tracing Attackers Research Light TracE) [START_REF] Strayer | [END_REF]] require agents installed in other assets, the first one in the kernel of the monitored machines and the second one in the routers. The work done for BDB has a continuity in the SLEUTH (Scenario LinkagE Using provenance Tracking of Host audit data) system [START_REF] Hossain | [END_REF]], that has a higher performance and incorporates the collection of OS information. The framework developed by Shaneck et al. [START_REF] Shaneck | [END_REF]] works with a centralized set of collected traces, in a similar way.

Another proposal based on progressive construction is HERCULE, a system for doing "attack story reconstruction" [START_REF][END_REF]]. This method is inspired by relationships in social networks. Their authors define a long list of possible relationships between events (see Table 3.2 in page 49). These relationships are exploited to create weighted attack scenario graphs. Weights are calculated using a quadratic optimization algorithm. A very interesting aspect of the paper presenting HERCULE is the emulation of an ample group of real APTs from the existing literature.

Conversely, Artificial Immune Systems (AIS) have been much used in single-step intrusion detection [START_REF] Kim | [END_REF]], but the only proposal particularly addressing multistep attack detection is iCorrelator [Bateni 2013b, Bateni 2013a, Bateni 2014]. This system emulates the human immune system in a three-layer architecture. It is based on cells, which are vectors of similarity features that represent the correlation degree between two traces. Correlation is based on the set of cells stored in memory, which evolves through supervised learning from an initial set of basic rules.

Scenario clustering

The goal of clustering is to discover natural groups in a set of elements [START_REF] Jain | [END_REF]]. This is usually done through the application of automatic clustering algorithms. In this category, we find the methods applying a clustering algorithm to identify groups of correlated actions. These groups or clusters are then considered to be potential multi-step attacks. The degree of correlation between traces belonging to the same cluster should be higher than the degree between traces from different clusters.

As far as we know, the application of clustering to multi-step attack detection was first proposed by Julisch [Julisch 2001[START_REF] Julisch | [END_REF], Julisch 2003a, Julisch 2003b]. He was also the first one to propose hierarchy-based similarity features (see section 3.4.1, page 50) to be used in his approximative alert clustering method. The aim of the author is to reduce the huge number of alerts generated by IDS, mostly fruit of persistent configuration errors or particularities of devices, by bringing together alerts originated by the same root cause. The revelation of the root causes can also lead to the identification of attack scenarios and a better understanding of attacker's intention, even if his method was not design to fulfill this purpose. Julisch has become then a reference to multi-step attack detection, and his hierarchy-based similarity features have been much used in the literature [Xiao 2008, Li 2016]. A posterior proposal [Wang 2006a], based on a genetic algorithm, is proposed by other authors to improve the quality of the results returned by the method developed by Julisch.

As in the methods based on progressive construction, similarity for clustering methods is quantified by choosing a set of similarity features. But there are authors who have also incorporated extrinsic attributes to the methods. It is the case of Cuppens, that in the context of MIRADOR project developed a clustering method oriented to alert fusion [START_REF] Cuppens | Managing Alerts in a Multi-Intrusion Detection Environmen[END_REF]] which was successfully tested on multi-step attack detection. Their approach bases the similarity of two alerts on a set of expert rules defined for each one of the compared attributes and for each possible pair of alert type. However, his most important contribution to the domain is on causal correlation, about which we speak in section 4.3.2.1. Another example is the clustering method developed by [START_REF] Murphy | [END_REF][START_REF] Murphy | [END_REF], which uses a similarity matrix containing statistical data. The values of the cells represent the number of times each elementary attack has targeted each service in the network. Using this matrix, they find the links between elementary attacks using Divisive Hierarchical Clustering (DHC) on a social network graph. Hierarchical clustering techniques are also used in the work of de Alvarenga et al. [de Alvarenga 2018] to offer the analyst a selected and reduced visualization of attack scenarios.

On its side, the MLAPT system, proposed by Ghafir et al. [START_REF] Ghafir | [END_REF]], takes as input alerts generated by a set of detection methods developed by the same authors and oriented to detect specific parts of the attack, such as infiltration of malware or bad usage of SSL certificates. Alerts are assigned to each one of the phases of a multistep attack model. Clustering is based on the detection of alerts matching these phases in a proper order.

Nevertheless, most methods work only on similarity features based on the inherent attributes of the traces. For instance, Zhang et al. [Zhang 2015] introduce a clustering method based on a textual similarity feature applied to several attributes (see section 3.4.1, page 50). As the only published material is a poster in a conference, the method is not presented in detail. Their original contribution is that they work with alerts coming from a WAF (Web Application Firewall). A WAF works in a high level of abstraction, so the registered actions are more directly linked to the purpose of the attacker than, for example, the TCP connections that lay under them. Another example is GAC (Graph-based Alert Correlation) [START_REF] Haas | [END_REF], where the clusters are based on the equality of IP addresses and port numbers. On a later stage, clusters are joined to form multi-step attack scenarios by comparison of IP addresses using the Jaccard similarity index.

Clustering can also be applied to groups of traces instead of to individual traces. This is done by Kawakani et al. [Kawakani 2016[START_REF] Kawakani | [END_REF], who propose a method for hierarchical clustering of graphs representing attack strategies. The graphs are automatically derived from alerts in the same time window by a common element similarity feature considering the source and destination IP addresses (f 2 with N = M = {ipsrc, ipdst}). The resulting clusters can be later used to classify similar incoming scenarios.

There also exist approaches based on chaining several clustering steps. One example of this is the alert clustering method presented by Qiao et al. [START_REF] Qiao | [END_REF]], composed of two stages. In the first one, alerts are grouped into sequences by means of a correlation function built from the weighted sum of three similarity functions (see section 3.4.4, page 60). In the second stage, the sequences built in the first one are clustered together according to the distance between them. This distance depends on the number of operations of deletion and insertion needed to transform one sequence into the one we are comparing with. After the two clustering stages, the attack models are extracted by a loose application of LCS (Longest Common Subsequence).

Another example of chaining of methods is given by Manganiello, Colajanni and Marchetti [START_REF] Colajanni | [END_REF], Manganiello 2011], who propose the application of a Self-Organizing Map (SOM), a kind of auto associative neural network, followed by a k-means clustering phase. The input dataset of alerts is first preprocessed using the hierarchical clustering proposed by Julisch [Julisch 2003a] to merge similar alerts and reduce the number of elements to be processed. Then, the SOM reduces the dimensionality of the alerts by mapping similar alerts to close neurons in the model. The result is then clustered using k-means and the resulting clusters are joined according to a correlation weight, which is based on the distance between the neurons, the time difference between alerts and the alert type.

Anomaly detection

Anomaly detection methods learn from a dataset of traces clean of attacks and then consider as a threat the sequences differing from normal behavior. Similarity comparison is then made against a whole reference dataset, not only between the traces in the incoming data. The results are used differently than in the other similarity-based methods: we do not search the similarities but the differences. It is important to note that abnormal behavior do not necessarily correspond to an attack. The rate of false positives can then be high, but anomaly detection methods offer the possibility of finding previously unseen attacks.

While anomaly detection has been much used as a technique to detect singlestep attacks [START_REF][END_REF], not many solutions have been proposed for multi-step attack detection. One of them is presented by Mathew and Upadhyaya [START_REF] Mathew | [END_REF]], who apply Principal Component Analysis (PCA) to build a model from attack-free data. Next, they project incoming data on the model. Abnormal sequences are then identified as those whose distance to the model is higher than a defined threshold.

In the anomaly detection method developed by Skopik, Friedberg et al., events from a training set free of attacks are linked in a random way to create hypotheses [START_REF] Skopik | Dealing with Advanced Persistent Threats in Smart Grid ICT Networks[END_REF], Friedberg 2015]. They develop a mathematical framework to define hypotheses, rules and anomalies. Events not related to the hypothesis are considered as anomalous and raise alerts. The multi-step attack perspective is only present during the characterization of the clean dataset, as detection is made event per event.

Hidden Markov Models (HMMs), that are considered in more detail when talking about methods doing statistical inference (section 4.3.2.2, page 81), have also been used in anomaly detection. This time, clean sequences are represented by HMMs, whose parameters are deduced from a clean training dataset. New sequences not corresponding to the trained HMMs are considered as attacks. Anming et al. [START_REF] Anming | [END_REF]] implemented a method based on this in 2004, using the Segmental K-means algorithm to create the HMMs from a training dataset of OS audit data. 9 years later, Shin et al. [START_REF] Shin | [END_REF]] apply the same method on the same dataset but on IDS alerts.

Causal correlation methods

In causal correlation, the causal progression of the sequences of traces is the key factor in the identification of multi-step attacks. In other words, previous steps in an attack determine the ones that follow, and a causal scheme can be derived from this relationship. This completely differs from similarity-based methods, where the found links depend on the similarity features between traces. In progressive construction methods (see section 4.3.1.1), causality can arise as a result, as a causal relationship may exist between traces connected by similarity features. But this is a causality observed a posteriori, while in causal correlation methods it is previously deduced from human experience or from the own traces and incorporated into the detection process.

Causal correlation methods have an important advantage: their process and results can be easily interpreted by a human analyst [START_REF] Salah | A model-based survey of alert correlation techniques[END_REF]], as causality is intuitively associated to the progression made by the attacker towards her goal. There may still be a high number of false positives, but less than in similarity-based methods, as safer hypotheses are made.

Depending on how causality is considered, we find two categories of causal correlation methods: prerequisites and consequences, and statistical inference. In methods based on prerequisites and consequences, the causal relationship of individual actions is explicitly coded in a database. Statistical inference focuses on the extraction of causality from the frequency of occurrence of actions with respect to other actions.

Prerequisites and consequences

In these methods, each trace is supposed to have associated a series of known prerequisites, also called pre-conditions, and consequences, or post-conditions. The prerequisites are the conditions to be given for an action to be performed, while the consequences are the possible effects of the action.

All the methods included in this category, except one [START_REF] Zhai | [END_REF]], works with IDS alerts as the only type of trace. Each IDS alert represents an attack by itself, so the prerequisites become the conditions to be given for an attack to be successful, from the point of view of the attacker [Benferhat 2003[START_REF] Ning | [END_REF]]. But as an IDS usually generates several alerts for each detected attack, there is usually a preprocessing phase to form hyper-alerts [Zhang 2017] (see page 36). The alerts contained in a hyper-alert have the same prerequisites and consequences and are temporally close to each other. Hyper-alerts are correlated through the automatic identification of prerequisites to consequences, returning attack scenarios composed of elementary attacks.

Shortly after the creation of the LAMBDA language [START_REF] Cuppens | LAMBDA: A language to model a database for detection of attacks[END_REF]] (see section 3.3.2), Cuppens et al. became the pioneers in the development of a method based on prerequisites and consequences, under the MIRADOR project [Cuppens 2002c, Cuppens 2002a, Cuppens 2002b, Benferhat 2003]. In their proposal, the connection of two attacks, A and B, is made if the consequences of A partially match the prerequisites of B. Apart from a database of prerequisites and consequences, additional ontological rules are needed for the connection of some of the steps. Once this expert data is set up using the LAMBDA language, a set of correlation rules is automatically derived from it. These rules can then be applied to input alerts for finding attacks.

The other parent of multi-step attack detection based on prerequisites and consequences is Ning, the most cited author in the literature about multi-step attack detection. His team at North Carolina State University has been the most prolific one in this category of methods, both in terms of number of publications and of timespan of the project [Ning 2002a, Ning 2002c, Ning 2002b, Ning 2002d, Cui 2002, Ning 2003a, Ning 2003b[START_REF] Xu | [END_REF], Ning 2004a[START_REF] Xu | [END_REF][START_REF] Zhai | [END_REF][START_REF] Ning | [END_REF]. Their method was developed in parallel to the one by Cuppens et al., and independently according to Ning [Ning 2004a]. The formalism of both methods is different, but the principles behind the correlation process are very similar.

Over the course of the eight years during which Ning has made evolve his proposal, many improvements related to graph reduction or analysis have been incorporated. As an example, a proposed technique of link analysis gives some extra insight on the attributes of the steps in the attack scenario [Ning 2002b[START_REF] Ning | [END_REF]]. Ning's team has also developed a different way to represent the causal predicates [START_REF] Xu | [END_REF]], focusing on triggering events and applying a hierarchical taxonomy to the attributes in the alerts. Finally, they have proposed the enrichment of IDS alerts with the inclusion of OS-level event logging [START_REF] Zhai | [END_REF]] in the only method based on prerequisites and consequences that does not use only IDS alerts.

Cuppens and Ning have inspired a vast research about prerequisites and consequences for attack detection. Cheung et al. [Cheung 2003] use their own language CAML (see section 3.3.2) to develop a method under the EMERALD project [Porras 1997], the same as Zhou et al. [START_REF] Zhou | [END_REF]] do with ACML (Attack capability modelling language) [START_REF] Pandey | [END_REF]]. Wang, Liu and Jajodia [Wang 2005b, Wang 2006e, Wang 2008] improve the performance of the method proposed by Ning et al. [Ning 2002c] by adding a new element called Queue Graph. In their method, alerts are correlated only to the latest copy of each type of alert, not to all the past ones. Their attack graphs contain, apart from the causal information, the vulnerabilities of the attacked system. Finally, the most complete of the proposals extending the work of Ning is MARS (Multi-stage Attack Recognition System), the framework developed by Alserhani et al. [Alserhani 2010[START_REF] Alserhani | [END_REF], Alserhani 2012, Alserhani 2013[START_REF] Alserhani | Alert correlation and aggregation techniques for reduction of security alerts and detection of multistage attack[END_REF]]. MARS also complements the prerequisites and consequences with information about the vulnerabilities in the assets. Using the method provided by MARS, Alnas et al. [START_REF] Alnas | [END_REF]] are able to model the behavior of Zeus botnet.

Finally, Yan and Liu [START_REF][END_REF], Yan 2005] propose an original approach: the use of a case grammar where the relationship between actions is expressed in plain English. In their model, actions are connected as verbs in linguistics using text categorization methods, after being transformed in semantic vectors.

Statistical inference

Statistical inference is the process of inferring from a dataset the distribution that generated it [Wasserman 2013]. Many methods have been developed based on this process. They base detection on a context-based feature, the probability of appearance (see section 3.4.3, page 55). These methods consider that there is a causal relationship between traces when they are statistically correlated [START_REF] Qin | [END_REF]]. Following this idea, a statistical model is automatically extracted from a training dataset or from the own data where the detection process takes place. The probabilities contained in this model are used for detection and prediction of subsequent attacks, by linking pairs of traces with a high probability value. Although not specifying the details about the information that the statistical model should contain, the method proposed by Geib and Goldman [Geib 2001] can be considered as the beginning point of statistical inference for multi-step attack detection. They propose the adaptation of probabilistic plan recognition, a good established field in Artificial Intelligence.

In general terms, the two main approaches to statistical inference are frequentist inference and Bayesian inference [Wasserman 2013]. Without going into specifics, frequentist inference assumes that conditions for the studied phenomena do not change in the long run, while Bayesian inference considers the probability of the phenomena as random variables [Koski 2011]. This is translated in two very different ways of deducing probabilities from a dataset: under the frequentist approach, the probability of a phenomenon is directly calculated by counting its number of occurrences and dividing by the total number of occurrences of all different phenomena, while under the Bayesian approach, a probability based on prior belief is assigned to the phenomenon and the value is adapted according to the frequency of the phenomenon.

There exist multi-step attack detection methods following any of the two approaches. First of all, we consider those following Bayesian inference. Markov models are one of the models incorporating Bayesian logic. They are composed of a finite set of states linked by probability values. They can be represented as a graph, which makes them a very suitable model for multi-step attacks, the states representing the actions executed by the attackers. The steps in the model are generally defined at the beginning of the process, and an initial value is assigned to transition probabilities. In any case, traces representing subsequent steps have one or several common attributes, whose choice depends on the author. For example, Farhadi et al. [Farhadi 2010] choose only the destination IP address, while Xuewei et al. [START_REF] Xuewei | An approach of discovering causal knowledge for alert correlating based on data mining[END_REF]] also include the source IP address.

A Hidden Markov Model (HMM) is a special type of Markov model whose states are partially hidden. Only an observable outcome linked to each state is known. In multi-step attack detection, the states are the actions performed by the attackers and the observable outcomes are the traces corresponding to each action. The way to proceed stays the same as in classical Markov models, the HMM becoming a formalism to make the distinction between trace and action. Ourston et al. [START_REF] Ourston | [END_REF]] were probably the first ones to use HMMs in the detection of multi-step attacks. They use IDS alerts, which are linked by IP address and classified into categories corresponding to each of the usual actions of a complex attack, which are, according to them, 'probe', 'consolidate', 'exploit' and 'compromise'. There are other methods using five states [START_REF] Katipally | [END_REF][START_REF] Jia | [END_REF] or even three [START_REF][END_REF]] when defining the HMM. The method proposed by Lee et al. [START_REF] Lee | [END_REF]] considers distributed agents to detect each stage of the attack. In the paper by Luktarhan et al. [Luktarhan 2012], HMMs are used but there is not a clear explanation of how the links between the states are made.

Instead of working with just a single HMM for any attack, a recent proposal by Holgado et al. [START_REF] Holgado | [END_REF]] considers a different HMM for each type of multi-step attack. Another innovation with respect to the other methods is that the structure and the initial parameters of the HMMs are automatically derived from a training dataset of alerts. To do that, they apply a clustering algorithm based on the textual similarity between the alert types and the content of Common Vulnerabilities and Exposures (CVE) documents (f 4 , see page 49). Shawly et al. [START_REF] Shawly | [END_REF]] consider a very similar approach but not using the information from the CVE documents.

Furthermore, Kholidy et al. show in a set of three publications [Kholidy 2014b, Kholidy 2014c, Kholidy 2014a] that other variations of classical Markov models, such as Variable Order Markov Models (VMM), can be used to predict next steps in a multi-step attack. The approaches they propose highly depend on predefined models or signatures of attacks, but prediction is based on transition probabilities adapted from alert data. Fava et al. [START_REF] Byers | [END_REF][START_REF] Fava | [END_REF], Yang 2008] use another variation of Markov models, Variable-Length Markov Models (VLMM). They are derived from a set of known multi-step attacks, where incoming sequences are projected by attack description, category of the attack or destination IP address.

Despite of the ample use of Markov models, Bayesian networks seem the most pertinent model to model multi-step attacks for applying Bayesian inference. The main difference between a Bayesian network and a Markov model is that the former is directed and acyclic and the latter is not. This make Bayesian networks more useful in the expression of the causal relationships between the traces [Bishop 2006]. The same as with Markov models, methods working with Bayesian networks require a previously defined network with associated belief values. Some work exists where the Bayesian network is derived from expert data [START_REF] Qin | [END_REF], Ning 2007, Jemili 2008[START_REF] Jemili | [END_REF]. Even if the structure partially comes from expert data, Bayesian inference can be complemented by a statistical method not needing prior knowledge, as Qin and Lee do with a method based on the Granger Causality Test (GCT) [START_REF] Qin | [END_REF], Qin 2005[START_REF] Qin | [END_REF]], a statistical method much used in Economics. This method is then retaken by Saikia et al. [Saikia 2018].

An alternative to Bayesian networks based on expert knowledge is the automatic deduction of the network and its initial beliefs from a training dataset during a previous offline phase. Doing so, no previous knowledge about the attacks is needed. For example, Ren et al. [Ren 2010] do this by testing several similarity features to find the ones better representing the relationships between traces. Kavousi and Akbari [START_REF] Kavousi | [END_REF][START_REF] Kavousi | [END_REF]] present a similar method but incorporate additional expert information to complete the model. [START_REF] Anbarestani | [END_REF]] base their model on a similarity feature involving only one attribute: the destination IP address. Sun et al. [START_REF] Sun | Using Bayesian Networks for Probabilistic Identification of Zero-Day Attack Paths[END_REF]] use system calls as nodes in the network, linked together by the objects they generate and use, such as files. Once built, the Bayesian network has to be prepared for online detection. To do that, Marchetti et al. [Marchetti 2011b] propose a pruning phase to remove the nodes whose correlation probability is lower than a dynamic threshold defined by the current statistics of the training dataset.

Apart from the work applying Bayesian inference, there is much work following a frequentist logic. In much of it, the sequences of traces potentially representing a multi-step attack are built through progressive construction (see section 4.3.1.1) and the probability associated to each pair of traces is deduced from the built sequences. This is the case of Nexat [START_REF] Cipriano | [END_REF]], a system that groups into sessions the alerts with some connection between source and/or destination IP addresses. Lagzian et al. [Lagzian 2012] also consider only the IP addresses as linking feature, applying Bit-AssocRule, a variation of the Apriori algorithm. In the case of Man et al. [Man 2012], the matched features are the destination IP address, the attack type and the timestamp, while Kim and Park [Kim 2014] just use time differences and pairs of IP addresses, not giving much insight about the implementation. Other work [START_REF] Ma | [END_REF][START_REF] Xian | [END_REF][START_REF] Zhang | [END_REF], Lu 2018] simply takes the ID of the events and apply a sequential mining method to find frequent sequences.

There exist many different methods to extract the probabilities associated to each pair of traces from a training dataset. Z. Li et al. [Li 2007b, Li 2007c] present an algorithm based on classic association rule mining, where probabilities are obtained just by counting the times pairs of traces are found together. PrefixSpan algorithm is also used in some work, whether it be modified [START_REF] Brahmi | [END_REF][START_REF] Lv | An alert correlation algorithm based on the sequence pattern mining[END_REF] or in its original form [Li 2016]. Sadoddin and Ghorbani [START_REF] Sadoddin | [END_REF]] propose FSP_Growth, a method based on the FP_Growth algorithm [Bai 2011] that mines frequent patterns of alerts and arranges them in a tree. Ghorbani is also author of a later work with Soleimani [START_REF] Soleimani | [END_REF], where he reuses the correlation matrix proposed with Zhu [Zhu 2006] and commented in section 4.3.1.1, page 73. The method proposed by Ghorbani and Soleimani has a first phase of sequence identification using the correlation matrix. Then, a supervised Decision Tree (DT) learning method is applied. Other methods used are boosting algorithms [START_REF] Hossein | Alert correlation using correlation probability estimation and time windows[END_REF] or the Generalized Sequential Pattern (GSP) algorithm [START_REF] Bahareth | [END_REF]].

Structural-based methods

Many methods consider the structure of the network as a key element for intrusion detection. They incorporate in their detection engine information about the system to be defended, specially about the vulnerabilities affecting each asset. This information is structural in the sense that it only depends on the defended systems and not on the actions of the attackers. The potential actions done by an attacker can be deduced from this information. For example, if we know there is a Windows machine vulnerable to the EternalBlue exploit, we can predict that an attack such as WannaCry would include the infection of this machine in its path of actions (see section 3.2.1). As we mentioned in section 3.4.3, page 56, structural information is usually coded in the form of attack graphs.

We are not interested here in the construction of the attack graphs or in the prediction of the path taken on the resulting graph by a potential attack, but in the detection of multi-step attacks from real traces using attack graphs as a tool. This is the goal of structural-based detection methods. They project incoming traces into the attack graph representing the defended network to evaluate the most probable path the attack can follow.

Noel et al. [START_REF] Noel | [END_REF]] were probably the first ones to project received IDS alerts into prebuilt attack graphs in 2004. Each vulnerability in the graph is linked to a known exploit that can take advantage of it. Alerts are matched to the exploits and the distance in the graph determines the final correlativity between alerts. Angelini et al. [START_REF] Angelini | [END_REF]] follow a similar method but directly matching vulnerabilities and alerts, also incorporating a visualization interface to show the details of the detected attack to the analyst.

While some research uses traditional attack graphs as described in the literature, in standard [START_REF] Roschke | [END_REF], Fayyad 2013, Luo 2016, Kaynar 2017[START_REF] Sicilia | [END_REF] or enhanced [Çamtepe 2007] form, the network model used in TANDI [Holsopple 2006[START_REF][END_REF]] also includes information about the level of access privilege. TANDI is developed at the Rochester Institute of Technology (RIT), the birthplace of some of the most relevant ideas about structural-based multi-step attack detection. One of these ideas is the cyber terrain or virtual terrain, proposed by Fava, Holsopple et al. [Fava 2007[START_REF] Holsopple | [END_REF]. It is a manual model of a network where each asset is associated to its services, its version and the logical connections with other assets.

Another system born at the RIT [START_REF] Du | [END_REF]] considers four categories: current state of the attacking source, current state of the target, firewall rule configuration and open services at the target. Prediction is made using two methods. The first one uses Transferable Belief Model (TBM) to combine the concepts of Capability and Opportunity assessments developed in the context of the FuSIA system [START_REF] Holsopple | [END_REF]]. The second one uses Fuzzy inference to merge Variable Length Markov Model (VLMM) estimates based on the attributes extracted from the alerts.

Chien and Ho [START_REF] Chien | [END_REF]] present a system based on colored Petri nets. They model each attack plan in an abstract way and detection is made considering a metric of exploit certainty. On the other hand, Zhang et al. [START_REF] Zhang | [END_REF] propose to automatically build the trees used for detection. They do that assembling different elements (information about topology, vulnerability scan results, etc.) through the principles of causal correlation.

Some attempts have been made to apply Game Theory to capture the behavior of an attacker and a defender during the execution of a multi-step attack [START_REF] Xupeng | A Game Model for Predicting the Attack Path of APT[END_REF], Haopu 2016, Hu 2017, Rass 2017]. Some of them are conceived to perform multistep attack detection on incoming traces. In these proposals, the defender reduces the uncertainty of the attack through the signals received from IDS alerts, placing defenses in real time to avoid damages. For example, Lin et al. [START_REF][END_REF]] propose a model focused on attackers whose objective is to steal confidential data. And Yi Luo et al. [START_REF] Luo | [END_REF]] present an algorithm called RDFP (Responses by Dynamic game tree-based Fictious Play) to be applied in a dynamic game tree.

Case-based methods

A broadly spread approach for intrusion detection is the comparison between the observations and a knowledge base of previously seen attacks. There are many methods applying this approach to multi-step detection. The knowledge base, containing a set of attack models or signatures, can be manually populated by security experts or attacks can be extracted from a dataset using automatic techniques. Honeypots can aid in the collection of real multi-step attacks for the development of case-based signatures [START_REF] Vasilomanolakis | Multi-stage Attack Detection and Signature Generation with ICS Honeypots[END_REF]]. Modeling the behavior of human actors involved in security [START_REF] Dutt | [END_REF]] can also be important to better understand how to develop the signatures. Newly discovered multi-step attacks, through an inference mechanism or by human intervention [START_REF] Salah | A model-based survey of alert correlation techniques[END_REF], can be added to the database once they have been analyzed and a signature is built. Signatures can contain additional information that can ease detection, such as the criticality of the assets in the defended system [START_REF] Soleimani | [END_REF]].

It is important to highlight the differences between case-based methods, structuralbased methods and methods based on prerequisites and consequences, as their resemblance can lead to confusion. In cased-based methods, models of attacks representing a specific type of multi-step attack are stored in the form of detection signatures in a database. Those signatures are then used to detect repeated occurrence of the same attack, with room for subtle variations in certain methods. Conversely, in structuralbased methods, models are built only upon structural network characteristics. The received traces are projected against this model and the attack is detected by the match between the actions and the exploitable vulnerabilities in the network assets. Finally, in methods based on prerequisites and consequences, there is also a predefined model stored in a database: the set of prerequisites and consequences associated to each trace. Models are thus made trace by trace, and assumptions about a whole multi-step attack are deduced by combining them. Therefore, the way to proceed is different to that of case-based methods, where a model represents a complete attack.

The clear advantage of case-based methods over the others is that the number of false positives is low: we know what we search for and we look for the exact occurrence of it, so it is difficult to miss the mark. Nevertheless, if an attack is not in the database, it is not found. Case-based methods are only capable of detecting known multi-step attacks.

Multi-step attack signatures, generally conceived as a graph [START_REF] Mathew | [END_REF]], can be represented using a language for rule representation. For example, Chintabathina et al. [START_REF] Chintabathina | [END_REF]] propose A-prolog to apply logic programming to case-based detection, and Long and Schwartz propose XML [START_REF] Long | [END_REF]]. However, there are languages that have been specifically created to model multi-step attacks, such as STATL [START_REF] Eckmann | [END_REF][START_REF] Valeur | [END_REF]; the chronicle formalism [START_REF] Morin | [END_REF], Wang 2004], or the tainting-based EDL [Jaeger 2015, Ussath 2016a, Ussath 2016b]. The details of these languages were explained in section 3.3.2 when addressing the languages to represent multi-step attacks.

Case-based detection methods can be very simplistic, just based on pattern matching [START_REF] Kannadiga | [END_REF][START_REF] Panichprecha | [END_REF], Katipally 2010[START_REF] Xuewei | [END_REF], or cryptic about how the signatures are built [Schindler 2017[START_REF][END_REF]]. Some of them embellish the process with a previous phase of preprocessing, such as the alert aggregation proposed by Xiao and Han [START_REF][END_REF]]. But we can find more complex proposals, where the system incorporates additional mechanisms to improve the detection. For example, MASP (Mining Attack Sequential Pattern) [Li 2007e, Zhang 2007, Wang 2007b, Li 2007d, Wang 2007a] uses incremental mining of subsequences of known multi-step attacks. Thanks to that, MASP can find variations of the attack signatures. Zali et al. propose a similar method [Zali 2012[START_REF] Zali | [END_REF], where they represent the attack scenarios as Causal Relation Graphs (CRG), with queues of alerts placed in each of the vertex of the graph. This structure eases the implementation for real-time detection and the prediction of missing alerts. The correlation system proposed by Chien et al. [START_REF] Chien | [END_REF]] works with primitives representing parts of attack scenarios. Primitives are built from a pre-defined ontology, but not enough detail is given about how they are created. The ONTIDS framework [Zargar 2014] is also based on an ontology, which works at different levels: 'context', 'alert', 'attack' and 'vulnerability'. A similar ontology is proposed by Wang et al. [Wang 2018], who extend its application to general events. The connection between all these levels is exploited in the definition of combined signatures. Giura and Wang [Giura 2012a, Giura 2012b] propose a model where the stages of the attack are arranged in a layered pyramid, with the goal at the top of the pyramid and the previous steps stratified by layers. In each face of the pyramid we can find a different domain: physical, network, application, user, etc. This model is used in a detection framework where correlation rules are based on signatures, profiling or security policies. An example of knowledge base automatically built is JEAN (Judge Evaluation of Attack Intension) [Cheng 2011], where the attack database is built from a training set of IDS alerts using J-Fusion, an algorithm for alert fusion. The system mines other occurrences of the same attacks using a method inspired by the generalized Hough transform, an image processing method to identify geometric forms. Another example is the work of Amos-Binks et al. [START_REF][END_REF], where attack scenarios are represented in a plan library automatically generated from a set of IDS alerts, according to a list of pre-defined goals.

There are several methods that assume a fixed structure for any multi-step attack, performing case-based detection from a generalized model of the steps that an attack should have. For example, in the INFERD system, [START_REF] Sudit | [END_REF][START_REF] Stotz | INformation Fusion Engine for Real-time Decision-making (INFERD): A perceptual system for cyber attack tracking[END_REF][START_REF] Mathew | [END_REF] this model is called Guidance Template and has seven stages. Each one of these stages has a certain subset of IDS alerts associated to it, according to their type. INFERD groups the alerts to form sequences with common source and/or destination IP addresses according to the order defined in the Guidance Template. Z. Liu et al. [START_REF] Liu | [END_REF]] propose a similar system but using just four stages: (1) 'probe', (2) 'scan', (3) 'intrusion' and (4) 'goal'.

The case-based methods presented so far are centralized: traces are collected in a central point, where the detection of attack scenarios takes place. However, there are also some distributed methods where detection of individual steps is done by local agents scattered throughout the network. This kind of detection system has been thoroughly studied as a particular field of security detection [Zhou 2010]. An example of a distributed method for multi-step attack case-based detection is Quicksand [Kruegel 2002], where handmade multi-step attack signatures are translated into pattern graphs and sent to the local agents. Each agent is responsible of detecting the fraction of the signature represented by a node of the graph. Each time an agent detects its assigned pattern, a message is sent up in the tree, until Quicksand identifies the full signature, represented in the root node, and raises an alert. The distributed system proposed by Vogel et al. [Vogel 2011a, Vogel 2011b] is based on the Petri net principle and uses signatures written in EDL [Meier 2007] (see section 3.3.2). Signatures are divided in minimal parts and sent to the local agents. In both methods, rule division has to be manually made by the security expert.

Mixed methods

As we have mentioned earlier, there is some work where several approaches are integrated together in the same system, with no clear prevalence of one over the other. For instance, the framework RTECA [Ramaki 2015a] combines statistical inference, similarity of trace types through a correlation matrix and similarity of IP addresses and ports. Frequent sequences are arranged in event trees, which are fed with similar sequences during the execution. The analysis of frequent patterns can also be combined with a phase of clustering [Faraji Daneshgar 2016]. The creators of RTECA also propose in another paper [Ramaki 2015b] a very similar system to their previous one but based on Bayesian networks. Lessons learned from both systems are incorporated in a recent three-phase framework developed by the same authors [START_REF] Ramaki | [END_REF], where there is no dependence of a predefined correlation matrix.

In ASEA system [START_REF] Farhadi | [END_REF]], statistical inference and similarity-based correlation are merged to apply plan recognition using HMMs. On the other hand, Shittu proposes in the third chapter of her Ph.D. thesis [Shittu 2016] to combine Bayesian inference with similarity-based correlation, offering a different perspective to existent Bayesian methods. Furthermore, Du et al. [START_REF] Du | [END_REF]] start by identifying sequences of IDS alerts with the same victim IP address and assigning a severity score to each step. Then, the found sequences are mined using three techniques, each of them based on a totally different mechanism: Longest Common Subsequences (LCS), Fourier transform and social networks.

There is much work combining prerequisites and consequences with other approaches. Ning et al. propose to mix their method with similarity-based methods [Ning 2004c, Ning 2004b]. Their purpose is to merge the graphs belonging to the same attack scenario but being mistakenly separated due to missing IDS alerts. Yu and Frincke [START_REF] Yu | [END_REF][START_REF] Yu | [END_REF]] combine prerequisites and consequences and statistical inference, applying a colored Petri net with hidden states. Another proposal is that of [START_REF] Saad | Extracting attack scenarios using intrusion semantics[END_REF]], composed of a phase of clustering using an intrusion ontology and a subsequent phase based on prerequisites and consequences. This method is later improved by other authors to allow online analysis [Barzegar 2018]. A similar method is used by Al-Mamory and Hong [START_REF] Safaa | Scenario discovery using abstracted correlation graph[END_REF], who additionally propose the application of an Attribute Context-Free Grammar to model the attacks [START_REF][END_REF][START_REF][END_REF]. This grammar contains information about the level of similarity between the alerts, their prerequisites and consequences and the structure of known attack scenarios.

We also find some publications proposing the combination of methods that we have already mentioned in the context of other approaches. For instance, causality-based INFERD [START_REF] Sudit | [END_REF][START_REF] Stotz | INformation Fusion Engine for Real-time Decision-making (INFERD): A perceptual system for cyber attack tracking[END_REF][START_REF] Mathew | [END_REF]] is integrated with the structuralbased TANDI system [Holsopple 2006] by [START_REF][END_REF]]. Furthermore, the SATA (Security Alerts and Threat Analysis) platform [Wang 2006b] combines the SF algorithm [Wang 2006d, Wang 2006c] with MASP [Wang 2007b, Li 2007d, Wang 2007a[START_REF] Zhang | [END_REF]]. Marchetti, Colajanni and Manganiello propose a framework [Marchetti 2011a] to bring together their two approaches: the one using SOM [START_REF] Colajanni | [END_REF], Manganiello 2011] and the pseudo-Bayesian one [Marchetti 2011b].

There are some frameworks in the literature proposing a whole end-to-end correlation process focused on multi-step attack detection. In the one proposed by researchers from Palo Alto Research Center and Galois Inc. [Abreu 2015], a mixture of methods are applied in different stages, from activity classification to alert ranking. Valeur et al. [START_REF] Valeur | [END_REF]] introduce a whole correlation system divided in several phases. Among those phases, the ones related to our research are the four aiming to link different alerts for composing scenarios: thread reconstruction, session reconstruction, focus recognition and multistep correlation. WMAPRM (Wireless Multi-step Attack Pattern Recognition Method) [Chen 2014a] also merges different detection approaches for the specific case of wireless data, where the level 2 of the OSI model is more relevant than the network level. Another correlation framework is the one proposed by Ahmed [Saad 2014], where attack scenario construction is made combining semanticbased clustering and analysis of pre-defined consequences of alerts. He also proposes previous phases for alert aggregation and verification.

The field in perspective

Apart from the analysis of the methods proposed in the literature, a statistical analysis of the selected publications can give us an insight about how the field has evolved and its present state. The objective is to check how pertinent is our research question with respect to the trends in multi-step attack detection. We review the number of publications and the duration of research in section 4.4.1; the type of data and the origin of knowledge used in the methods in section 4.4.2, and the reproducibility of experiments in section 4.4.3. is still an active field but that does not represent much of the whole set of publications in Cybersecurity or even in general attack detection.

Number of publications and duration of research

On the other hand, we have extracted the most relevant publications and authors in the domain. The 20 most cited publications are listed in Table 4.1. A list of researchers appearing in 5 or more publications is presented in Table 4.2. The number of citations, in these tables and in the rest of this thesis, has been extracted from Google Scholar, which we consider as the most complete search engine in terms of number of references4 .

There are two remarkable conclusions that can be extracted from these tables and from the ones presented in the Appendix D. The first one is that only a reduce number of authors gets a high number of citations. This is probably true for any research domain, especially for a young field as multi-step attack detection, with only 18 years old.

The second conclusion is that there is a lack of continuity in developing multi-step attack detection methods. This does not mean that there are no long-lasting projects in multi-step attack detection. Some of the most cited authors have been working in the field for long time, in some cases collaborating in the development of different methods. The best examples are Peng Ning [Ning 2004c, Ning 2002c, Ning 2002b, Ning 2004a, Ning 2003b], and Frédéric Cuppens [Cuppens 2002c, Cuppens 2002a, Benferhat 2003, Cuppens 2002b], who in parallel laid the foundations of causal correlation through prerequisites and consequences. Ning, with the help of other collaborators as Yun Cui, has developed this method at the North Carolina State University during 8 years, being the author with the highest number of citations in multi-step attack detection. Although less prolific, Cuppens counts with the most cited publication in the field [Cuppens 2002c] and he has also explored clustering [START_REF] Cuppens | Managing Alerts in a Multi-Intrusion Detection Environmen[END_REF]]. The team directed by Ali A. Ghorbani [Zhu 2006[START_REF] Sadoddin | [END_REF], Wang 2010[START_REF] Soleimani | [END_REF], Bateni 2013a] has also conducted long-lasting projects about multi-step attack detection. This team is also a reference in the development of new datasets for testing the methods (see section 7.1.2).

The lack of continuity in research about multi-step attack detection methods enormously contrast with the threat posed by these attacks, their high incidence and the effort devoted in public and private institutions to fight them. A good example of the bad consequences a multi-step attack can have is WannaCry, presented in the Intro- duction of this thesis. One of the reason of this lack of continuity can be the absence of available real data for developing and testing the methods. In consequence, there is also a lack of possible multi-step attack instances to study. In the most broadly used public dataset, DARPA 2000, there are just two different multi-step attacks, the ones described in section 3.2.2. In the supposed successor of DARPA 2000, ISCX 2012 dataset, only one multi-step attack is found (section 3.2.3).

Type of data and origin of knowledge

None of the public datasets contains a set of events where all the actions in the multistep attack are represented. The traces contained in them are the raw packets captured by sniffing. Correlation of actions generally need a higher level of abstraction that the one contained in the packets. To properly exploit these traces, it is necessary to preprocess them by replaying the traffic and feeding with it an IDS that can express the malicious actions in the packets as a set of alerts (events). As a result, and despite of the effort made by researchers in using public datasets in the evaluation of the methods (see diagram in Figure 4.5), there is a lack of variety in the type of trace used in evaluation. The results are shown in Table 4.3, where the number of publications using each type of trace is shown5 . More than 85% of the publications are exclusively focused on the analysis of alerts. Even if authors such as Brogi and Tong [START_REF] Brogi | [END_REF]] consider that detecting a multi-step attack is the same as highlighting the links between elementary attacks, general events can represent actions that are not necessarily malicious but that can be part of an attack. The development of a public dataset composed of logs containing information about several variations of a multi-step attack would improve the quality of the evaluation.

Another aspect of the analyzed methods is how models are enriched to work in the detection of multi-step attacks. According to this, we classify methods into three categories: manual, supervised or automatic. In manual methods, detection models are manually built. The knowledge of the attack is directly coded by the analyst, who has to be experienced in attack modeling. The objective is to find known attacks or slight variations of them. All of the reviewed case-based methods (see section 4.3.4) and those based on prerequisites and consequences (section 4.3.2.1) are of this type. Then, supervised methods follow the same principle as the homonymous machine learning methods: attack models are created and enriched through a process of automatic learning from training data. Finally, in automatic methods, the specificities of the detection models are automatically learnt during the detection process. Supervised and automatic methods are developed thinking how an attack is, as no specific detection model is given.

In Figure 4.6 we represent the distribution of publications under each of these categories. We can see that publications presenting manual methods represent a 55.2% of the total. The lack of a global detection model, a set of characteristics shared by every multi-step attack, does not allow developing solid automatic methods. On its side, supervised methods are hindered by the availability of sound and reliable datasets for the training phase.

The prevalence of manual methods is an indicator of how the security analyst is a key piece in the process of detection. These methods require a knowledge base of detection models, sometimes called signatures. The research question of this thesis addresses this gap between the discovery of an attack, generally after investigation, and the construction of the detection model. The goal of this thesis is to propose a model which can act as a bridge joining the two processes and maintaining an active investment of the analyst. This process is what we call identification (see page 4). The wide presence of manual methods for detection and the absence of research addressing the identification problem for the context of multi-step attacks justify the need to answer the research question.

Reproducibility of experiments

An important aspect to study in multi-step attack detection is the reproducibility of presented methods and experiments. Reproducibility is the ability to replicate the results obtained in a published experiment in similar conditions as were set by the original researcher [Goodman 2016]. It can be distinguished from replicability, the ability of reproducing the results but using different data that the one proposed in the original research. Replicability is harder to attain, as the proposed hypotheses need to be true for any dataset and not only for the one used in the published experiments.

Reproducibility is a minimum standard for defending a claim as scientific [Peng 2011].

We have studied the reproducibility of the experiments presented in the selected corpus of publications. To well structure our study, we have defined reproducibility through a set of criteria that is similar to the one proposed by Leek and Peng [START_REF] Leek | [END_REF]]. Three conditions have to be met for considering a publication as 'reproducible' in terms of experiments: method, data and knowledge have to be accessible. Accessibility of these three elements is explained below:

• Accessibility of method (A m ): The proposed multi-step attack detection method is exposed in such a clear way that its functioning can be reproduced without elements from outside the publication. To fulfill this condition, method can rely on an explanation of the method in plain language or in the form of pseudocode. Another alternative is to present a downloadable implementation of the method [START_REF] Brogi | [END_REF]].

• Accessibility of data (A d ): At least a public dataset is used in the experiments.

It can be a well-known public dataset or a new one made available by the authors of the publication. This condition is not considered to be true if the method is tested with a case study.

• Accessibility of models (A k ): If the detection method relies on models, e.g. a set of signatures in case-based methods, the ones used in the experiments are provided in the publication. In the case that the method uses a training dataset for automatic learning, we consider that this condition is accomplished if this training dataset is available. This condition is not considered for automatic methods (see section 4.4.2), where no previous model is needed.

These three conditions have been studied for all the publications in the corpus and the results are shown in Figures 4.7a, 4.7b and 4.7c. In Figure 4.7d, we divided the corpus in publications with reproducible experiments, for which the three conditions are true, and those without them, when at least one of the conditions is not fulfilled. It is of serious concern that most of the publications (69%) do not offer full reproducible experiments. There is even a 19% of publications proposing multi-step attack detection methods that cannot be reproduced.

These are global statistics of a field lasting 18 years, and the situation could be better in the last few years. But if we look at the proportion of the publications including reproducible experiments per year, in Figure 4.8, we see that the evolution has not been very favorable. This casts doubts on the scientific quality of the work in

A m = yes 81% A m = no 19%
(a) Accessibility of method A m . The reasons behind this lack of reproducibility do not forcibly rely on neglects by authors but on the limitations of the field. Public datasets are scarce and a big number of researchers have to simulate their own data. On top of that, the most wellknown and spread datasets containing multi-step attacks, DARPA 2000 (see section 7.1.1) and ISCX (section 7.1.2), do not have enough instances of multi-step attacks. Conversely, datasets furnished by private companies, such as the HuMa dataset used in this thesis (section 7.1.3), cannot be published for confidentiality reasons, even if the benefit of sharing research data are evident [START_REF] Wicherts | [END_REF]]. The reason of this secrecy is the nature of the data, which can contain lots of sensitive information, both in terms of security and privacy. A possible solution to share this data would be to apply anonymization methods [START_REF] Slagell | [END_REF]], but they have been proved to be far from infallible [Narayanan 2008, Ji 2014].

A d = yes 55% A d = no 45% (b) Accessibility of data A d . A k = no 43.3% A k = yes 28.35% A k = not applicable 28.35% (
To bring this topic to a conclusion, many of the studied publications that contains reproducible experiments have a few or zero citations in Google Scholar, as we can see in the tables of Appendix D. We hope this systematic review will help to make them more known so other researchers can improve the methods proposed in them.

The involvement of the security analyst

After having analyzed the multi-step attack detection methods, we can conclude that the human analyst is considered most of the time as placed before or after the detection process. On the one hand, its role before detection is the development of the detection models and the configuration of the parameters of the detection method. For example, in methods based on prerequisites and consequences (section 4.3.2.1), a list of the possible events enriched with their pre and post conditions has to be provided. In the case of structural-based methods, structural information from the defended network is needed. On the other hand, the role of the analyst after the detection process is to verify the generated alerts and to fix the consequences of the attacks or even to stop them in time.

Only a couple of publications about multi-step attack detection propose the involvement of the human analyst during the detection process. On one side, we have the methods based on Game Theory [START_REF][END_REF][START_REF] Luo | [END_REF], where the analyst has an active part responding to each attack attempt by the deployment of defenses in real time. However, they are just reduced to theoretical models that have not been tested with data.

Another proposal is the framework developed by Shaneck et al. [START_REF] Shaneck | [END_REF]]. They claim that this framework keeps the "human analyst in the loop" by the control of the output from the first two phases of the system: the identification of relevant alerts (anchor points) and the context extraction. The analyst would have the role of selecting interesting events or critical points in the network to make the system focus on them. Unfortunately, the involvement of the human is just limited to this description and to the promising diagram of the framework, reproduced in Figure 4.9.

To find other examples of involvement of the security analyst in the process of detection we need to look to other domains. Majeed et al. [Majeed 2018] propose a system thanks to which the analyst can explore in real time how rules are matched in a SIEM (see page 19). The objective is to detect abnormal behavior the earliest as possible and being able to react against ongoing attacks. This is especially critical if the attack matched by the SIEM rule spans on a long period of time. In this system, the security analyst is involved in detection in the sense that she can check and analyze the process for preventing unwanted situations. However, the flow of information happens only from the system to the analyst, and it is not envisaged the improvement of the detection capabilities by online feedback from the analyst.

There exist several proposals where the analyst is involved in the online tagging of data. These methods are based on machine learning algorithms that send selected queries to the analyst for improving the learning process. This process is called active learning.

One system using active learning is AI 2 [Veeramachaneni 2016], based on a continuous process with several phases (see Figure 4.10). First, an outlier detection system reduces the amount of income events by the combined used of several unsupervised machine learning algorithms. This results in a much smaller set that can be presented to the analyst for labelling. Data is presented to the analyst through a user interface that ranks the outliers by their importance. Then, the labeled result is used by a supervised learning module to create a detection model.

Another example is ALIDS (Active Learning Intrusion Detection System), which uses a random forest classifier and k-means clustering [McElwee 2017]. Events sent to the analyst, called 'oracle', are those ones that are uncertainly classified, not a small set found using an unsupervised method, as it happens in AI 2 . A similar approach is followed by ActivSVDD [Görnitz 2009], where the results obtained using support vector domain description (SVDD), a data description for outlier detection, are improved by querying the analyst about low-confidence observations. On its side, Mao et al. [START_REF] Mao | [END_REF]] consider active learning in a multi-view approach using two views: networkbased and host-based. Lastly, the method proposed by Li and Guo [Li 2007a] applies TCM-KNN (Transductive Confidence Machines for K-Nearest Neighbors), querying the analyst for the most informative events.

Finally, we cannot end up this section without addressing the HuMa architecture [START_REF] Navarro | [END_REF]], the one proposed in the context of the homonymous project financing this doctoral research. HuMa considers the human as the main actor in the analysis of threats. In fact, the name HuMa directly refers to the presence of the human in the attack analysis: it stands for "the human at the center of Big Data analysis for Cybersecurity"6 . The analysis is organized around three layers: the event layer, where individual traces are represented; the context and attack pattern layer, which gathers information about technical requirements of the attacks; and the assessment layer, where information from complex attacks is extracted. Models developed in this thesis are intended to work in the assessment layer, together with the ones furnished by other partners in the project.

The model at the origin of HuMa is KILS (Knowledge and Information Logs-based System), proposed by Legrand et al. [Legrand 2014]. Its structure is divided in four levels: real world, storage, inference and expert knowledge. This model includes a feedback loop to introduce the knowledge from the human analyst into the system. Doing so, the attack detection algorithms contained on it can learn and improve their results. Communication with the human is eased by the decomposition of incoming events into abstract concepts. These concepts are inspired by the Action Theory and the principles of criminal investigations, but their details are not disclosed.

Summary

This chapter has been devoted to present one of our contributions: a systematic survey on multi-step attack detection. The results of the survey have been already published in a scientific journal [Navarro 2018a]. In this chapter, we have updated this research and improved the exposition of the reviewed methods. We have started describing the methodology followed in the systematic survey, listing the inclusion and exclusion criteria in section 4.2.1 and describing the research process in section 4.2.2. Following this, the methods chosen to be part of the bibliographic corpus have been described. They are classified by approach: similarity-based methods (section 4.3.1), causal corre-lation (4.3.2), structural-based methods (4.3.3), case-based methods (4.3.4) and mixed methods (4.3.5). In section 4.4, we have presented some conclusions about the state of the field based on the statistics extracted from the selected corpus. Finally, some examples of security systems placing the human analyst as an important piece in the detection process have been introduced in section 4.5. Little has been done in multistep attack detection to address this topic, so we had to look to other domains to get information that allows us responding our research question.

At the same time as being one of the contributions, this survey constitutes a solid bibliography for this thesis. We can conclude that, up to now, proposed multi-step attack detection methods consider the security analyst as being before the detection process, designing the detection models, or after it, verifying the alerts and acting in consequence. But no method proposes the identification of the detection models among the alternative cases derived by the analyst during investigation. We need to look in different fields to identify a similar process. This and other related topics are reviewed in the next chapter.

Chapter 5

Abstract Attack Scenario Graphs (AASG) Hold to the now, the here, through which all future plunges to the past.

-James Joyce, Ulysses

Our research question, as defined in page 3, points out to two objectives: a) to help the security analyst to decide between alternative scenarios of multi-step attacks (the identification process) and b) to perform detection of the attacks at the same time as this process takes place. The origin of these goals is the problem confronted by the security analyst of knowing which are the exact actions composing a multi-step attack among all the set of actions in the network registered in traces.

We propose in this chapter a structure to meet these objectives, called Abstract Attack Scenario Graph (AASG). It is a graph with each node representing a set of possible events generated in the network. Nodes are arranged in the AASG to represent different multi-step attack scenarios with some steps in common. Even if they seem similar, an AASG is very different to a CASG, the model to represent multi-step attacks presented in section 3.3.3, page 42. A CASG represents an existent multi-step attack, but an AASG codes the alternative scenarios conceived by the security analyst.

We start this chapter presenting the ideas behind AASGs in section 5.1. Then, the definition of an AASG is given in section 5.2, together with the definition of other concepts needed to build AASGs, such as abstract events or the operations to apply for matching real events. In section 5.3, we show an example of the steps followed to build an AASG from a detected multi-step attack. Finally, in section 5.4, we present details about how to code an AASG to be implemented in a real system.

From Concrete to Abstract ASG

The originality of AASGs mainly lies in the idea of flexibly representing alternative multi-step attack scenarios in the same structure, based on the similarity features defined in section 3.4.1, adapted to the needs of the security analyst. Before explaining the details of the AASG model, we have to describe its conception, from the attack scenario graphs used in the literature (CASG) to the definitive idea of AASG. We start exploring in section 5.1.1 the existent mechanisms for representing alternative hypotheses in a graph. A list of requirements derived from the reviewed literature to make the AASG a valid model to respond to our research question is presented in section 5.1.2. AASGs are inspired by two sources: the models for representation of alternative hypotheses, reviewed in section 5.1.1, page 104, and the mechanism of rulebased event correlation used in SIEMs (see page 19). In section 5.1.3, we explain how the idea of rule-based log correlation has influenced the creation of AASGs, before presenting in section 5.1.4 how alternative scenarios can be presented in the same structure. Finally, in section 5.1.5, we clarify the difference between CASGs and AASGs.

Representation of alternative hypotheses

The manifestation of a multi-step attack from the point of view of the defender is a sequence of traces, as we said in section 3.3.1, page 36. The hypotheses formulated by the analyst should then be identifiable with an eventual set of traces left by the attacker. The concept of alternative hypotheses has been already addressed in the literature about multi-step attack detection. However, these hypotheses are not considered as proposals coming from the human analyst in his quest of detection models, but as stated by the own detection methods. The hypotheses are then alternative choices created by the system from the information it has, for presenting them to the analyst [START_REF] Mathew | [END_REF]] or as an intermediary step of the detection process [START_REF] Skopik | Dealing with Advanced Persistent Threats in Smart Grid ICT Networks[END_REF]. They refer to one of the following four elements:

• Alternative goals or root causes of an attack [Geib 2001, Julisch 2001].

• The correlation between traces [Cuppens 2002c, Ren 2010, Friedberg 2015]. Rules 5.1. From Concrete to Abstract ASG 105 are tentatively proposed by the system but they need to be confirmed.

• The presence of missing steps [Cuppens 2002b, Ning 2004b[START_REF] Zhai | [END_REF]], if the expected sequence of events is incoherent with the observations.

• The whole attack scenario [START_REF] Mathew | [END_REF]], as it could be a false positive.

As far as we know, the only publication in the selected corpus about multi-step attack detection that addresses alternative hypotheses proposed by the analyst is the one where the system SLEUTH [START_REF] Hossain | [END_REF]] is proposed. But hypothesis decision is not fully integrated in SLEUTH. Its authors just propose to reclassify the data according to a different hypothesis and to "re-run the analysis".

In the literature about attack graphs, that is out of the scope of the systematic survey presented in Chapter 4, the hypotheses proposed by the analyst are more present. These hypotheses correspond to the different paths that a multi-step attack can take in a network according to structural data. Much work has been done about attack graphs [START_REF] Sheyner | [END_REF], Shostack 2014[START_REF] Singhal | [END_REF], which constitutes the base of the structural-based detection methods (section 4.3.3). However, hypotheses made on an attack graph consider only the structural information of the network and not the sequence of traces representing the attack. What interests us to address our research question is the proposal of hypotheses from an evidence set of traces, not from the topology and characteristics of the defended network.

Models for the representation of hypotheses can be found in other domains of Cybersecurity. For example, Yen et al. [Yen 2010] propose a hypothesis reasoning framework for cyber situation awareness. Their objective is to translate the hypotheses created in the "mental world" of the analyst to a specific platform allowing team collaboration. The framework is based on recognition-primed decision (RPD), a model of rapid decision making. The authors do not specify any formal detail of the model representing the hypotheses, but they give a very interesting list of requirements that such a model should meet:

1. Representativeness. The model should be able to represent all the important elements of the hypotheses.

2. Simplicity and intuitiveness. The analyst should be capable of building an instance of the model in a simple way and to intuitively interpret instances created by other analysts or the ones she could have created in the past.

3. Expressed in mathematical form. Hypotheses in the model should be expressed in a mathematical-based language and the model itself should be a math- ematical object. The purpose of this requirement is to be able to reduce the work of the analyst by an efficient analysis using mathematical-based tools.

4. Computation friendliness. The model and the hypotheses represented on it should be manageable by a computer system, that could assist the human analyst.

Yen et al. argue that traditional graphs cannot meet these requirements and that hypothesis models have to be represented as hypergraphs. They say so due to the broad scope of the problem they tackle: to represent any human hypothesis related to cyber security awareness. We will see in Chapter 5 that if we restraint the hypotheses to sequences of events representing multi-step attacks, models based on traditional graphs are perfectly possible.

The AOH (Action, Observation and Hypothesis) model is another reasoning system intended to capture the know-how of expert analysts to guide unexperienced ones [Zhong 2013[START_REF] Zhong | [END_REF][START_REF] Zhong | [END_REF]]. The experience-based reasoning process is expressed in a model called E-Tree, where actions are related to observations in the frame of a working hypothesis. A representation of an E-Tree is shown in Figure 5.1a. Each relationship action-observation is called an Experience Unit (EU). The disjunctive hypotheses in the E-Tree can be extracted into another model, the H-Tree (Figure 5.1b), so the analyst can just focus on them.

This model has evolved since it was first published. The idea of extracting the H-Tree has been abandoned and the E-Tree has become the AOH model itself. It has been used for other purposes: the identification of multimedia data that is interesting for the cybersecurity analysis [Alnusair 2017], the triage of security data coming to a Security Operations Center (SOC) [START_REF] Zhong | [END_REF]] and the sharing of the processes followed by the analyst [Thomas 2018]. All these proposals, always with Chen Zhong as the author in common, are based on capturing the activities performed by the analyst in the form of cognitive traces1 . Both actions (e.g. browse a log file) and observations (e.g. a lot of alerts representing an IRC connection) generate traces that can be automatically incorporated into the AOH model. Actions become traces thanks to a defined catalogue. On their side, observations become traces through the selection of data performed by the analyst. However, the model does not provide a format to represent the hypotheses, that are just described in plain text. One of the examples proposed by Zhong et al. [START_REF] Zhong | [END_REF]] is represented in Figure 5.2.

We do not want to end up this section without addressing the issue trees, also called logic trees. They were created to simplify the resolution of issues by logic reasoning [Wojick 1975]. They are applied in business decision taking. There are not many scientific publications analyzing them but they are very similar in structure to our AASG model presented in Chapter 5. In an issue tree, nodes represent a brief statement or question about an issue. The moves down the tree are made by responding to the parent node, getting to other nodes with new statements or questions. Paths in the tree represent a line of reasoning. An example of an issue tree representing a discussion about the appearance of the stirrup in History as the origin of Feudalism [Wojick 1975] is shown in Figure 5.3.

Requirements to define the model

We need to define a series of requirements that an AASG needs to fulfill to address the research question. Before doing so, the object with which an AASG will be dealing has to be defined. Said differently, as multi-step attack cases are conceived as sequences of traces, we should determine which type of trace is used (see section 2.3). An AASG is built only considering events, including alerts, being other types of trace, such as packets, excluded from the definition presented in this thesis.

The reason of this choice is that events are much more suitable than other traces to the proposition of alternative multi-step attack cases. They are concise in the expression of the actions and therefore better readable by a human. If we take the case of packets, for example, their design is conceived to be optimal for communications between computers and their content is difficult to read for a human. On top of that, there is an enormous quantity of them in a network. [START_REF] Nassar | [END_REF] give an example of a university network with an average traffic load of 650 Mbps and maximum peaks of 1 Gbps that creates several hundred million network flows per day, each flow representing a full communication session between two machines, so therefore composed of several packets.

On the contrary, the textual representation of an event, the log, has its origin in the need for stocking information that can be read by humans. They are created to keep a track of actions and to make the analyst understand what is happening in the network. Their volume is also lower than the volume of packets, because only the most relevant actions are chosen by each asset to be logged. Moreover, the most important datasets considered for multi-step attack detection contain events or they have to be expressed as IDS alerts, that are also events, to be used (see section 7.1, page 169).

Once it is decided that an AASG works with events, the first requirements to fulfill are the ones defined by Yen et al. [Yen 2010] for a model representing hypotheses for cyber situation awareness. These requirements have been listed in section 5.1.1, page 105, and adapted here for our specific problem:

1. Representativeness. The design of the model should be able to capture the hypotheses of the analyst about multi-step attacks in terms of sequences of traces.

2. Simplicity and intuitiveness. The model has to be human readable, so the analyst can directly represent the conceived alternative scenarios.

3. Mathematical form2 . Concepts in the multi-step attack cases have to be expressed in a mathematical language. The structure of the model itself should be the one of a mathematical object, and a set of mathematical operations should be defined for working with traces.

4. Computation friendliness. The model needs to have a format that can be used by computers, so we can develop algorithms using this representation.

Apart from these requirements, we propose a list of five additional ones, referring to the purpose and the functionality of the model: 5. Compliance with the purpose. The model should be adapted both for helping the decision between alternative attack scenarios (identification) and for detecting attack scenarios.

6. Boundness. The end of each represented attack needs to be well defined.

7.

Uniqueness. A criterion needs to be defined to univocally distinguish one model among the others in a set.

Flexibility.

The design of the model should be flexible enough to allow the representation of varied attack scenario. 9. Suitability for learning. A quantification of the probabilities of each subsequent step has to be permitted, to allow the application of learning algorithms.

We will see through this chapter how the AASG fulfills all the presented requisites.

Rule-based event correlation

SIEMs, the security systems for log collection and correlation (see page 19), generally apply rule-based reasoning [Müller 2009], which is based on the identification of matches between collected events and static correlation rules. The rules represent a set of conditions to be met by a set of events for raising an alert and they are written by security experts. They can be general or adapted to the characteristics of the network where the monitored devices are placed. Many commercial SIEMs base their detection mechanisms on rules furnished by the vendor [Oliver Rochford 2016] in combination with specific rules crafted by the security analysts in the organization.

The set of conditions represented in a rule can follow a specific order or not. For example, imagine a set of three conditions: "find event A", "find event B" and "find event C". We can define a rule looking for the fulfillment of the three conditions in any order: "find event A, B and C in a certain time window W T ". This is what we call a non-ordered rule. But we can also define a rule where the order is important, an ordered rule: "find event A and then event B and then event C in a certain time window W T ". The specification of a time window W T limits the time during which the search of conditions take place. This is necessary to limit the usage of computational resources in the SIEM. Henceforth, we only consider ordered rules, which better fit the idea of a multi-step attack as a sequence of actions.

In a SIEM applying rule-based reasoning on ordered rules, there is a linear check of each incoming event against the beginning of each rule. If an event matches the first condition of a rule, a new detection thread is opened to wait for other events matching the rest of the conditions in that rule. Different rules have forcibly some points in common. In that case, the search of following events is done concurrently for all the rules whose first conditions are matched so far. This would be the case of the LLDoS 1.0 and LLDoS 2.0.2 attacks, contained in the dataset DARPA 2000 (section 3.2.2, page 31). The second step of LLDoS 2.0.2 is the same as the third step in LLDoS 1.0, and the two last steps also involve the same actions in both attacks. The conditions in an ordered rule can be represented in the form of a graph, as a sequence of nodes. In Figure 5.4, we represent two sequences of conditions characterizing the steps 3 and 4 of LLDoS 1.0 and the steps 2, 3 and 4 of LLDoS 2.0.2. The conditions are expressed as the search for a RealSecure3 IDS alert of certain type in the set of incoming events. We use only the type of alert in each step to keep it simple and because it serves well to the purpose of the explanation. Nevertheless, rules generally contain other conditions based on other event attributes, such as the IP addresses or the port numbers.

What is interesting is that we can easily merge the two rules together in only one graph, such as the one shown in the right side of the figure. The concurrent search of alerts is then done as follows:

1. If the system finds an alert of type 'Sadmind_Amslverify_Overflow', a new detection thread is opened to search for alerts matching the subsequent conditions.

2. The system searches for an alert of type 'Admind'. So far the process for finding the two attacks is the same.

3. The detection thread looks for an alert of type 'FTP_Put' or one of type 'Rsh'. Depending on which of the two alerts is found the match corresponds to LLDoS 1.0 or LLDoS 2.0.2.

4. Independently of which is the path taken in the graph, both rules finish with a condition referring to the same type of alert ('MStream_Zombie').

The SIEM finally triggers an alert if all the conditions in a rule are matched or, in other words, when the end of a graph representing a rule is reached. Again, if a rule is not completely matched within a certain time window W T , the detection thread in charge of analyzing this rule is closed. This classical method is used by many correlation systems, such as OSSIM4 (Open Source SIEM), whose open code has helped to widely disseminate the idea of security event correlation [Alien Vault 2014].

The structure of AASGs and the mechanism to use them is directly inspired by ordered rules in rule-based event correlation. There are at least two reasons to take them as a reference. First, the expression of rules in the form of statements 'if ... then' is very intuitive for the human security analyst. At the same time, the possibility of arranging the rules in a graph is suitable for their use by automatic algorithms, as it is done in SIEMs. The requirements of simplicity and intuitiveness, and of computation friendliness (numbers 2 and 4, respectively, in the list defined in section 5.1.2) are thus met by the graphs for rule-based event correlation. We take therefore this model as the reference on top of which we append additional features to meet the rest of the defined conditions and fully define the AASG.

Defining alternative attack scenarios

Once we know that an AASG could have the same structure as a graph representing rule-based event correlation, we focus on how the alternative multi-step attack cases could be represented in the graph. A big challenge for the characterization of multistep attacks is that we usually have only one instance of them. A security analyst is then confronted to derive a general model from just this single occurrence. This is not an easy task, as the sequence of actions representing a multi-step attack can be hidden among other actions, some of them possibly performed by the same actors. The concept of AASG is born from a need of arranging the set of hypotheses made by the expert in a unified structure.

Continuing with the example given in page 3, we can imagine that the security analyst considers several hypotheses when facing an instance of WannaCry 5 , after an infected computer is detected. The list of involved events was shown in Table 1.1, also reproduced in Figure 5.5. First, the analyst chooses the event e 0 because it represents the first action made by the malware. She knows that an unsuccessful HTTP request to a long domain name D 1 , which is the event represented in e 0 , is used by many pieces of malware to check if they are executed in a sandbox that tries to fool them giving a positive response to any request. But she is not sure if the event e 1 , a successful HTTP request to another domain name D 2 , could be a step or not of the attack. Maybe the response coming from D 2 was containing an additional piece of malware to continue the infection process. Then, she considers than the event e 2 is one of the step of the attack because it represents a connection in the port 445, used by SMB, which seems to be the protocol used for the propagation. As she is not an expert in the SMB protocol, and she is facing one of the first instances of WannaCry, she does not know if the propagation of the malware is performed through the malformed headers in the 'NEGOTIATE PROTOCOL REQUEST' packet (e 3 ) or it is done through the command 'transaction2_secondary' (e 6 ). The final result is a list of four hypothesis or alternative scenarios: e 0 e 2 e 6 , e 0 e 2 e 3 , e 0 e 1 e 2 e 6 and e 0 e 1 e 2 e 3 . As we saw in page 3, only the first scenario represents the set of events to track for detecting an occurrence of WannaCry. If we adopt the same perspective as in rule-based event correlation, these four alternative scenarios can be arranged in a graph all together, as they share several steps. Alternative scenarios considered by the security analyst as the representation of a multi-step attack generally have one or more steps in common. The common steps correspond to those ones that take an evident part in the development of the attack under the point of view of the analyst. We can see the resulting graph on the right side of Figure 5.5. This is the definitive shape of an AASG, for which we will give a full definition in section 5.2. Once done so, it will become clear how this structure can fulfill the list of requirements defined in section 5.1.2.

Comparing CASG and AASG

Before formally defining an AASG, we present a list of the differences between CASGs and AASGs. The list is not exhaustive but it reflects how these two models are very different despite of the fact that share a similar structure:

• A CASG is a model of a single multi-step attack, built from a set of involved traces. Conversely, an AASG represents the alternative attack scenarios conceived by a security analyst.

• In a CASG, the nodes are traces or abstraction of traces (with not all the attributes represented) corresponding to each of the steps in the attack. In an AASG, the nodes represent a set of conditions defined by the analyst. These conditions indicate which events correspond to each of the nodes.

• An AASG can only have one source, while a CASG can have many.

• Similarity functions in a CASG are used to define the links between the different steps of the attack. On the contrary, similarity functions in an AASG are used to define the conditions under which incoming events match the nodes in the graph. They can be applied using predefined values in the model or the values of the attributes of previously found events (see sections 5.2.4 and 5.2.5).

Definition of AASG

Once the concept of AASG is introduced, we give in this section a rigorous definition of this model. As any directed graph, an AASG is composed of nodes and arcs. The nodes point out to a set of incoming events through a series of conditions, codified in what we call abstract events, which are defined in section 5.2.1. Alternative multi-step attack cases are represented as sequences of nodes joined by the arcs. Their structure and the rest of the formal characteristics of the AASG are explained in section 5.2.2. The mechanism allowing the match between real events and the abstract events in the nodes is presented in section 5.2.3. This matching process is based on two types of condition contained in the abstract events: absolute and relative. They are described in section 5.2.4 and 5.2.5, respectively. Finally, two additional elements of an AASG, counters and optional nodes, are introduced in section 5.2.6

Abstract events

As we said, Abstract Attack Scenario Graphs are conceived to work with events (including alerts), and not with other types of trace such as packets. A formal definition of an event can be given adapting the one proposed for a trace (see page 18). An event e is the record of an action happening in a certain asset. It is an entity in the set of all possible events E. As any trace, it contains a series of inherent attributes that can be arranged in a finite tuple e a = {m a , l a , . . . , n a , . . .}6 . This characterization is independent of how the inherent attributes are textually represented in the log. The same as in any trace, the name n of each attribute n a defines the type of value of the attribute and its meaning: an IP address, a port number, etc. The concept of abstract event lies in the base of an AASG. We define an abstract event e ⇤ as a set of K conditions {c 1 , c 2 , . . . , c K } met by a subset of events in E. For example, a condition c 1 could be to have the attribute indicating the destination port number (named pdst) equal to 23. An abstract event e ⇤ a with only this condition would refer to the subset of events having this destination port number. Conditions in an abstract event allow thus the selection of a set of events without specifying the concrete events within the selection, as filters in a search engine.

Apart from the condition of equality seen in the example ("having X value in an attribute"), we can define other types of condition, such as numerical intervals (e.g. process ID higher than 650, for events coming from a host), discrete ranges (e.g. ipdst in the IP address range 175.68.22.0/24), sets of values (e.g. destination port pdst is 80 or 443) or complementary definitions (e.g. logged user is not 'admin'). Conditions can also be built using the comparison features defined in section 3.4, that are based on how nodes in attack scenario graphs are linked in the literature. We will come back to how conditions can be built in section 5.2.3.

The set of all possible abstract events e ⇤ is denoted by E ⇤ . Each event can be represented by many abstract events. The set of all possible abstract events corresponding to an event e a is denoted by E ⇤ a .

Nodes and arcs

We can define an AASG using abstract events and considering matching operations against incoming events. Nodes in an AASG represent as abstract events the steps of attack scenarios, while arcs indicate the order in which the events matching the nodes are arranged to correspond to an attack sequence, always starting from a single initial node. We have thus three properties the graph has to satisfy: it has to be directed, acyclic and single-source.

Regarding the first property, an AASG is directed because the alternative attack scenarios it represents are defined with a certain chronological order. If the order of the events in a multi-step attack is always preserved, it can be a sign of causality between the events: one event follows another one because it depends on its previous occurrence. Because of this, it is important to the analyst to be able to represent her hypotheses about the temporal succession of steps in the attack. This is possible because we assume that the timestamps in the logs are synchronized (see 36).

The need for having an acyclic graph is related to the requirement of having a well-defined end for each alternative scenario (requirement 6 of boundness in section 5.1.2). If there are no cycles, an algorithm using AASGs can define the arrival to a node with no arcs going out from it as the condition to stop the search of events. The scenario would then be considered as found. Allowing cycles leads to the possibility of defining infinitely long scenarios, which are not realistic from a practical point of view.

Finally, AASG are single-source (see page 42) because we need a way to identify a particular AASG among many others. In a system exploiting this structure we could have several AASGs containing alternative cases for different multi-step attacks at the same time. The security analyst can be simultaneously investigating several multi-step attacks or using several AASGs to perform detection. We choose to force an AASG to have a single source representing the first element in the sequence of all the scenarios proposed in a particular AASG. This mechanism is the same as the one applied in rule-based event correlation (see Figure 5.4). The source of an AASG is called root node. Each AASG is unambiguously defined by its root node, which fulfills the requirement of uniqueness, the number 7 in the list presented in section 5.1.2. Any newly proposed alternative attack scenario starting by a node being the root of an existent AASG should be appended to it.

We have then that an AASG is a single-source directed acyclic graph (DAG). Moreover, we add the condition that all the nodes except the root node should have an in-degree of at least 1. Doing so, we guarantee that all the nodes contained in an AASG have an arc to or from other nodes. With all these elements, we can present a formal definition of an AASG: Definition 6.1. An Abstract Attack Scenario Graph (AASG) = (K, A) is a single-source directed acyclic graph (DAG) represented by an ensemble of N  nodes K = { 0 ,  1 , . . . ,  N } and an ensemble of arcs A, with each arc  n  m named after the juxtaposition of the names of its start node  n and its end node  m , with  n  m 6 =  m  n . has the following properties:

1. Each node  n contains an abstract event e ⇤ n .

2.  0 is the root node and it is the source of the graph.

3. 8 n 2 K| n 6 =  0 , in-degree of  n 1 4. Any possible path [ 0 ,  0  p ,  p , . . . ,  m ,  m  n ,  n ] from the root node  0 to a specific node
 n has the same length.

The set of N AASGs used by a system is = { 1 , 2 , . . . , N }. The system can then select which i to use based on its root node.

To complete the definition of AASG we have to introduce several concepts related to the path from the root node (the source) to one of the sinks (a node with an out-degree of 0):

• Definition 6.2: A branch b  is a path [ 0 ,  0  l ,  l , . . . ,  j ,  j  k ,  k ] that goes
from the root node  0 to any of the sinks. It corresponds to one of the alternative attack scenarios represented in the AASG. The set of all the branches in an AASG is denoted by B . We refer to each branch by the ordered sequence of the numbers corresponding to each node. For example, branch [ 0 ,  0  2 ,  2 ,  2  6 ,  6 ] would be expressed as [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]2,6].

• Definition 6.3: The node  b is a child of node  a if there exists an arc  a  b with its origin in  a and its end in  b .

• Definition 6.4: The node  a is a parent of node  b if there exists an arc  a  b with its origin in  a and its end in  b .

• Definition 6.5: All the nodes in the AASG with a parent  a in common are called  a -siblings, or just siblings to abbreviate.

• Definition 6.6: The depth of a node  n is the number of arcs that exists in the path between the root node  0 and  n . Due to the fourth property of an AASG, the depth of a node is unique, having all the paths starting from the root node and leading to the node the same number of arcs.

Matching events to nodes

We saw in section 5.2.1 that abstract events are designed to select a subset in a set of events. The subset of events selected by an abstract event is composed of the events fulfilling the conditions expressed in the abstract event. For each event e a meeting all the conditions in abstract event e ⇤ n we say that "e a matches e ⇤ n " or that "e ⇤ n is matched by e a ".

We can define a match function M to express the operation of checking if an event e a matches e ⇤ n . This function can be extended to work with conditions and nodes.

Definition 6.7.

Given an event e a , a node in an AASG  n , an abstract event e ⇤ n 2  n and a condition c k 2 e ⇤ n we can define a match function M in three different domains:

• Between e a and c k :

M (e a , c k ) = 8 < : 1, if e a meets c k 0, otherwise (5.1)
• Between e a and e ⇤ n :

M (e a , e ⇤ n ) = 8 < : 1, if M (e a , c l ) = 1 8c l 2 e ⇤ n 0, otherwise (5.2) or differently said, M (e a , e ⇤ n ) = 1 if e ⇤ n 2 E ⇤ a .
• Between e a and  n :

M (e a ,  n ) = 8 < : 1, if M (e a , e ⇤ n ) = 1 0, otherwise (5.3)
The condition c k is the basic brick to build abstract events and to define the events that match an AASG. There can exist two kinds of condition in an abstract event:

• Absolute conditions, only based on the inherent attributes of each individual event.

All the examples we have seen so far in this section use absolute conditions. Another example of absolute condition is "the type of the event is textually similar to the 'fail login' string".

• Relative conditions, that refer to the previous event in the sequence, the one that matches the parent node. For example, "the source IP address is the same as the destination IP address of the previous event" is a relative condition.

Absolute and relative conditions can be combined when defining an abstract event. They are defined in the following two sections (5.2.4 and 5.2.5, respectively) and listed in Table E.1. In any case, both absolute and relative conditions have certain common characteristics:

• They are associated to a function g, which returns the value 0 or 1 depending on the inherent attributes of the event e a .

• In some cases, they have an associated threshold to conform the result of an internal comparison function to the value 0 or 1 returned by g. In these cases, determines the value of the internal comparison function above which the condition is met (g = 1).

Many of the functions g that we have defined for the conditions are directly adopted from the set of atomic similarity functions used in the literature (see Table 3.3 in 52).

In the literature on multi-step attack detection they are used to define a model of the attack by linking the set of traces corresponding to the different steps. However, the application is radically different in AASG: the search for incoming events matching an abstract model derived from an instance of a multi-step attack but not representing the instance itself, as several alternative scenarios appear together in the same AASG.

Type Name of function Formula

Absolute conditions

Equality

g 1 (na, r) = ( 1, if na = r 0, otherwise Inequality g 2 (na, r) = ( 1, if na 6 = r 0, otherwise Prefix similarity g 3 (na, r, ) = ( 1, if l L > 0, otherwise Textual similarity g 4 (na, r, ) = ( 1, if jac(na, r) > 0, otherwise Set-based g 5 (na, R) = ( 1, if na 2 R 0, otherwise Relative conditions Equality f 1 (na, m b ) = ( 1, if na = m b 0, otherwise Common element f 2 (Na, M b ) = ( 1, if Na \ M b 6 = ? 0, otherwise Prefix similarity f ⇤ 3 (na, m b , ) = ( 1, if l L > 0, otherwise Textual similarity f ⇤ 4 (na, m b , ) = ( 1, if jac(na, m b ) > 0, otherwise Inequality fneq(na, mp) = ( 1, if na 6 = mp 0, otherwise
Table 5.1: Functions used in the definition of the conditions in abstract events.

Absolute conditions

An absolute matching condition always refers to a certain inherent attribute in the event. We refer to it with a superscript n (c n k ) indicating the name of the considered attribute 7 . For example, a condition c pdst k depends on the destination port number, while a condition c ipsrc k depends on the source IP address. The function g in an absolute condition takes as input the event e a to be tested and a reference r, the fixed element against which the test is made. We define two types of absolute condition, depending on which is the kind of data taken as a reference: value-based and set-based. We explain below the characteristics of each one:

• Value-based absolute conditions. The reference r is a single value, whose nature depends on the inherent attribute considered by the condition. For instance, in the case of taking the type of the event, r would be a string of characters. In other cases, it could be an IP address, a port number or a numerical value.

The following functions are defined:

-Equality. The same as f 1 in Table 3.3 (Equation 3.1, page 48), this function checks if the selected attribute is equal to r:

g 1 (n a , r) = 8 < : 1, if n a = r 0, otherwise (5.4)
-Inequality. It is the exact opposite of g 1 : this function checks if the selected attribute is different from r:

g 2 (n a , r) = 8 < : 1, if n a 6 = r 0, otherwise (5.5)
-Prefix similarity. The result of this function is determined by calculating f 3 (Equation 3.3, page 49) and comparing to a threshold to get a binary result. We use this function only for comparison between IP addresses. Remember that in f 3 , l represents the number of common bits in the binary representations of the compared IP address n a and r, starting the count from the left and stopping when there is an uncommon bit. L is the total number of bits in the binary representation, which in this case is 32.

g 3 (n a , r, ) = 8 < : 1, if l L > 0, otherwise (5.6)
-Textual similarity. Taking the idea from f 4 (Equation 3.4, page 50), we also incorporate a textual similarity function. We saw that Zhang et al. [Zhang 2015] use the Levenshtein distance as textual metric for comparing IP addresses. The Levenshtein distance works well if the two compared strings have a similar length, as it is the case of IP addresses. However, a generic text could have any length, and the Levenshtein distance is no longer valid. For example, imagine we want to use the string s 1 = "SQL" in our condition of matching and we want to calculate the textual distance against s 2 = "This is a SQL injection attack" and s 3 = "CSS attack". We would expect lev(s 1 , s 2 ) < lev(s 1 , s 3 ), but using the Levenshtein distance we have that lev(s 1 , s 2 ) = 27 and lev(s 1 , s 3 ) = 9, just because s 2 is longer than s 3 . Even normalizing by the maximum length of the two compared strings we have f lev(s 1 , s 2 ) ⇡ 0.87 and f lev(s 1 , s 3 ) ⇡ 0.82.

The example given above represents a typical case of application of textual similarity in an AASG: the analyst wants to find a type of event but she does not know exactly which are the set of text strings referring to this type, so she uses one or several keywords when defining the abstract event.

Because of this, we choose another similarity function, the Jaccard index [Jaccard 1901], applied to the set of words in the text strings. If we name W x and W y the set of words in strings x and y, respectively, we can define the Jaccard index as:

jac(x, y) = |W x \ W y | |W x [ W y | = |W x \ W y | |W x | + |W y | |W x \ W y | (5.7)
The Jaccard index is proportional to the similarity between the strings, oppositely to the Levenshtein distance, that measures the difference instead of the similarity. Taking the previous example, we have that jac(s 1 , s 2 ) ⇡ 0.17 and jac(s 1 , s 3 ) = 0. Considering a threshold , we can then define a function based on the Jaccard index:

g 4 (n a , r, ) = 8 < : 1, if jac(n a , r) > 0, otherwise
(5.8)

• Set-based absolute conditions. They do the comparison against a set of values, instead of against an individual value. r becomes then a set, which we call R. We define only one function of this type, that consists on checking if the value of the attribute is in the set R:

g 5 (n a , R) = 8 < : 1, if n a 2 R 0, otherwise
(5.9)

Relative conditions

Relative conditions defined for the abstract event in a node  y refer to a parent  x of  y in the AASG. Each branch of an AASG represents a sequence ordered in time, so events matching  x always precedes those matching  y . The function g defined for each relative condition takes as least two arguments. The first one is an attribute n a or a set of attributes N a from an incoming event e a . The second, an attribute m p or a set of attributes M p from the event e p that has matched one of the parents of the node containing the abstract event with the relative condition.

We derive the matching functions directly from the atomic similarity functions considered in the literature and listed in Table 3.3, page 52. For f 1 and f 2 , the identification of M (e a , c k ) with the value returned by the function is direct, as they can just take values 0 and 1. However, functions such as f 3 or f 4 , which returns a real value between 0 and 1, should be modified to have a binary result depending on a threshold . In an AASG, we are not interested in the degree of similarity between two traces but in knowing if an incoming event matches or does not match the node. The resulting modified functions f ⇤ 3 and f ⇤ 4 are shown in Table 3.3. For textual similarity (f 4 ) we use the Jaccard index as in g 4 .

Additionally, we define another atomic similarity function to evaluate the inequality of an attribute between the events (similar to g 2 ):

f neq (n a , m p ) = 8 < : 1, if n a 6 = m p 0, otherwise
(5.10)

Additional elements

We end the definition of AASGs with two additional elements: counters and optional nodes. This two elements serve to simplify the definition of some kinds of scenario, 5.2. Definition of AASG 123 which could be anyways described just using the properties defined so far.

Counters

Sometimes, there are repetitions of actions in a multi-step attack. Think of an attack starting with a simple ping-based port scan. Supposing that the ping action is registered as an event in the firewall, we could define an abstract event to match it containing two absolute conditions with the following functions:

• g 1 (type a , 'ping')

• g 1 (origin a , 'firewall')

However, we cannot consider we are being scanned just because we detect one ping event. Several repetitions of the action against different ports are necessary to arrive at this conclusion. Each repetition would have the same target IP address and a different target port number8 . We can define this as a sequence of nodes, where each abstract event has, apart from the already defined absolute conditions, two abstract conditions referring to the previous event e p in the sequence:

• f 1 (ipdst a , ipdst p ) • f neq (pdst a , pdst p )
Given that the abstract event is the same for each node representing an individual ping action, we develop a mechanism, the counters, to indicate this repetition with just one node. A counter is a natural number associated to a node indicating how many events matching the abstract event in the node have to be found before considering the node as matched.

In a graphical representation of an AASG, counters are represented as self-loops. We show in Figure 5.7 both representations, before and after the implementation of a counter, for an AASG with a repetition of the same abstract event in subsequent nodes. Restraining counters as an element for representation, AASG do not still lose their acyclic character. Counters are just a formality to express differently a concept that could be implemented using the base definition of an AASG. However, we will see that when using algorithms such as Morwilog (Chapter 6), the self-loop represented by the counter is considered during the execution as being different than its alternative representation with all the nodes expanded. In this case, the AASG is not acyclic anymore and becomes a single-root directed graph where only self-loops are allowed.

Optional nodes

Another additional mechanism to define AASGs is the use of optional nodes. This idea is similar to the one of optional event used in the LAMBDA language [START_REF] Cuppens | LAMBDA: A language to model a database for detection of attacks[END_REF]] (see section 3.3.2.1, page 37). An optional node is a node representing a step in the scenario that the analyst does not know if it takes part in the attack or not. Think of event e 1 represented in Figure 5.5 and mentioned in the example of page 112. It corresponds to a "successful HTTP request to long domain name D 2 " in the set of logs containing the evidence of WannaCry attack. The analyst is not sure about its membership in the attack. We could then mark this event as 'optional' in our hypothesis.

Optional nodes are drawn with a dashed contour in the graphical representation of an AASG. Figure 5.7 shows the process of transforming several alternative scenarios into an AASG with two optional nodes,  2 and  5 . The representation of the middle, without optional nodes, is totally equivalent. Again, this mechanism serves just to help the analyst in the definition of AASGs but it does not change the structure of the graph. In fact, the infection of Mill is by itself a multi-step attack, even if it is part of the biggest LLDoS 1.0 attack.

Creating Abstract Attack Scenario Graphs

We display only seven fields: an identifier assigned to each alert; the timestamp; the type of the alert, and the IP address and port number for both the source and the destination. These alerts come from the dataset provided by Ning et al. [Ning 2002a], who generated them using the RealSecure IDS on the original captures of traffic in DARPA 2000. That is why the timestamps of the alerts do not correspond to the moment when the original dataset was generated (between March and April 2000 [Shittu 2016]). We will come back to this topic in section 7.1.1. The list of all the RealSecure alerts included in this thesis is presented in Table 7.1.

If it is the first time that the analyst faces this attack, it can be difficult to develop a signature representing it to detect future occurrences. An additional difficulty is the presence of alerts containing Mill's IP address but not representing any step in the attack, such as that one of type 'Email_Ehlo' (alert 67405). Here is an example of how the analyst could proceed to reflect her ideas about the multi-step attack in an AASG. The resulting AASG, called Mill-1, is represented in Figure 5.8 together with the conditions included within the abstract events of each node. 2. The 'Sadmind_Amslverify_Overflow' alert (abbreviated in the table as 'Sad-mind_AO') represents an attempt of buffer overflow against the sadmind daemon. This is the attack through which the attacker can have access to the Mill machine. It is evident that each action involving the sadmind daemon ('Sad-mind_Ping' or 'Sadmind_AO') also involves an 'Admind' alert. However, the order of the alerts seems to vary, sometimes having the 'Admind' alert preceding the other alert and some others the opposite. This can be coded by the analyst using absolute and relative conditions, contained in abstract events e ⇤ 1 and e ⇤ 3 .

3. As the alert 'Sadmind_AO' is repeated exactly 6 times, she considers this repetition as another possible indicator of the attack. Moreover, there is a 'Tel-netTerminaltype' alert (abbreviated as 'TelnetTermtype') that she decides to incorporate to the AASG as the next step. These suppositions are reflected in e ⇤ 2 and e ⇤ 4 .

4. After the buffer overflow attack, the attacker seems to get access to Mill using rsh (remote shell command). There are 'Rsh' alerts where the IP address of the attacker is in the attribute ipsrc (67540 and 67542), while there are others where it is in ipdst (e.g. 67549 or 67545). The analyst does not know if in a future occurrence of the attack the IDS will generate alerts of the two types, so she includes both options in the AASG (e ⇤ 5 and e ⇤ 6 ).

5. The analyst thinks that the presence of telnet communication after the 'Rsh' alerts could be part of the attack. However, it is not clear if it will be always the case or not, so she adds a node referring to 'TelnetTermtype' as an optional node in the AASG ( 7 ).

6. Finally, the analyst identifies two different types of 'Mstream_Zombie' alert, one having as destination a specific IP address in the network (67776 and 67777) and the other being a broadcast message (67767 and 67537). Both possibilities are included in the AASG in separated nodes, coded by abstract events e ⇤ 8 and e ⇤ 9 , so both could be detected in the future.

Implementation

Given that the structure of the AASG has been well defined in section 5.2, it is fairly straight to express it in a language that can be interpreted by a system using this model. An AASG is implemented in JavaScript Object Notation format (JSON) [IETF 2017]. The implementation captures all the defined elements in an AASG (abstract events, conditions, etc.), allowing at the same time the possibility of incorporating new elements to be used by algorithms exploiting AASGs (see Chapter 6).

Node

Abstract event List of conditions

 0 e ⇤ 0 g 1 (typea, 'Sadmind_Ping') = 1  1 e ⇤ 1 g 5 (typea, {'Sadmind_AO', 'Admind'}) = 1, f 1 (ipsrca, ipsrcp) = 1, f 1 (ipdsta, ipdstp) = 1  2 e ⇤ 2 g 1 (typea, 'Sadmind_AO') = 1, f 1 (ipsrca, ipsrcp) = 1, f 1 (ipdsta, ipdstp) = 1  3 e ⇤ 3 g 5 (typea, {'Sadmind_AO', 'Admind'}) = 1, fneq(typea, typep) = 1, f 1 (ipsrca, ipsrcp) = 1, f 1 (ipdsta, ipdstp) = 1  4 e ⇤ 4 g 1 (typea, 'TelnetTerminaltype') = 1, f 1 (ipdsta, ipdstp) = 1  5 e ⇤ 5 g 1 (typea, 'Rsh') = 1, f 1 (ipdsta, ipdstp) = 1  6 e ⇤ 6 g 1 (typea, 'Rsh') = 1, f 1 (ipsrca, ipdstp) = 1  7 e ⇤ 7 g 1 (typea, 'TelnetTerminaltype') = 1, f 2 ({ipsrca}, {ipsrcp, ipdstp}) = 1, f 2 ({ipdsta}, {ipsrcp, ipdstp}) = 1  8 e ⇤ 8 g 1 (typea, 'Mstream_Zombie') = 1, fneq(ipdsta, ipdstp) = 1  9 e ⇤ 9 g 1 (typea, 'Mstream_Zombie') = 1, f 2 ({ipsrca}, {ipsrcp, ipdstp}) = 1, g 1 (ipdsta, 255.255.255.255) = 1  7  0  1   3   5   8  Figure 5
.8: Representation of AASG Mill-1, built from an instance of LLDoS 1.0. Logs used to build the AASG are shown in Table 5.2

Structure and notation

In the implementation, each AASG is a JSON object containing the following members:

• id: A unique integer identifying the AASG among a set of AASGs. This allows making reference to any AASG during working operations.

• nodes: A list of objects representing the nodes of the AASG.

• arcs: A list of objects, each one representing all the arcs starting from a certain node in the AASG.

Each node  n has the following members:

• id: A unique integer i identifying the node. It is mandatory to assign the value 0 to the root node, the source of the graph.

• e_star: The abstract event e ⇤ , expressed as a list of conditions. Each condition is also an object, whose members are different depending on whether the condition is absolute or relative. Both types have the member function, which indicates the type of function to apply in each case. The names given to each function in the implementation are collected in Table 5.3. There is also an additional member, threshold, which is a float representing , the variable determining when the condition is met for functions g 3 , g 4 , f ⇤ 3 and f ⇤ 4 . This member is not needed if we use other functions.

An absolute condition has the following specific members:

• att: The name of the attribute to which the condition is applied. The full list of attribute names can be found in Appendix C.

• r: The reference value, the value against which the comparison is made. It can be any kind of scalar corresponding to the type of value defined for the attribute (a string, an integer, etc.) or an array in the case of the set-based function (g 5 ).

A relative condition has other two different specific members:

• attP: The name of the attribute of the previous event matching the parent node.

• attC: The name of the attribute of the event found to match the node.

Type Name of function Implem. name

Absolute conditions

Equality EQL Inequality NEQ

Prefix similarity PFX

Textual similarity TXT

Set-based SET

Relative conditions

Equality SIM_EQL

Common element SIM_COM

Prefix similarity SIM_PFX

Textual similarity SIM_TXT

Inequality SIM_NEQ Table 5.3: Implementation in JSON of condition functions Finally, there are two additional and optional members in each node object, to implement counters and optional nodes:

• counter: It is an integer different from 0 corresponding to the counter of the node. If the member does not exist, the counter is considered to be 1.

• optional: A boolean being true if the node is optional or false if it is not. When the member is not present, it is assumed as false. The root node can never be optional.

Objects representing arcs do not contain the information of just one arc in the node, but of all the arcs that start from each node with children. This eases the implementation of algorithms going through the AASG from the root node to the end of a branch. Each time an algorithm of this kind evaluate a node, it can easily check if this node has any children and, if this is the case, find all the arcs leading to them. The members contained in an object representing a set of arcs are:

• start: The identifier of the node where this set of arcs starts. There is only one object representing a set of arcs for each starting node, so it also acts as a unique identifier of the object.

• children: A list of objects representing the nodes to which the arcs going out from start are pointing. In the basic implementation of an AASG, each object representing a child has only one member, id, corresponding to the identifier of the child node. We will see in Chapter 6 that representing it as a list of objects and not as a mere list of identifiers allows adding other members required by the algorithms using AASGs.

Example of implementation

We present below an example of implementation in JSON format of the AASG represented in Figure 5.8.

"id": 1, "nodes": [ {"id": 0,"e_star": [ {"function": "EQL","att": "type","r": "Sadmind_Ping"}]}, {"id": 1,"e_star": [ {"function": "SET","att": "type","r": ["Sadmind_Amslverify_Overflow","Admind"]}, {"function": "SIM_EQL","attC": "ipsrc","attP": "ipsrc"}, {"function": "SIM_EQL","attC": "ipdst","attP": "ipdst"}]}, {"id": 2,"e_star": [ {"function": "EQL","att": "type","r": "Sadmind_Amslverify_Overflow"}, {"function": "SIM_EQL","attC": "ipsrc","attP": "ipsrc"}, {"function": "SIM_EQL","attC": "ipdst","attP": "ipdst"}],

"counter": 6}, {"id": 3,"e_star": [ {"function": "SET","att": "type","r": ["Sadmind_Amslverify_Overflow","Admind"]}, {"function": "SIM_NEQ","attC": "type","attP": "type"}, {"function": "SIM_EQL","attC": "ipsrc","attP": "ipsrc"}, {"function": "SIM_EQL","attC": "ipdst","attP": "ipdst"}]}, {"id": 4,"e_star": [ {"function": "EQL","att": "type","r": "TelnetTerminaltype"}, {"function": "SIM_EQL","attC": "ipdst","attP": "ipdst"}]}, {"id": 5,"e_star": [ {"function": "EQL","att": "type","r": "Rsh"}, {"function": "SIM_EQL","attC": "ipdst","attP": "ipdst"}]}, {"id": 6,"e_star": [ {"function": "EQL","att": "type","r": "Rsh"}, {"function": "SIM_EQL","attC": "ipsrc","attP": "ipdst"}]}, {"id": 7,"e_star": [ {"function": "EQL","att": "type","r": "TelnetTerminaltype"}, {"function": "SIM_COM","attC": ["ipsrc"],"attP": ["ipsrc","ipdst"]}, {"function": "SIM_COM","attC": ["ipdst"],"attP": ["ipsrc","ipdst"]}]}, "optional": true}, {"id": 8,"e_star": [ {"function": "EQL","att": "type","r": "Mstream_Zombie"}, {"function": "SIM_NEQ","attC": "ipdst","attP": "ipdst"}]}, {"id": 9,"e_star": [ {"function": "EQL","att": "type","r": "Mstream_Zombie"}, {"function": "EQL","att": "ipdst","r": "255.255.255.255"}, {"function": "SIM_COM","attC": ["ipsrc"],"attP": ["ipsrc","ipdst"]}]}],

5.4. Implementation

131

"arcs": [ {"start": 0,"children": [{"id": 1},{"id": 2}]}, {"start": 1,"children": [{"id": 3}]}, {"start": 2,"children": [{"id": 4}]}, {"start": 3,"children": [{"id": 5},{"id": 6}]}, {"start": 4,"children": [{"id": 5},{"id": 6}]}, {"start": 5,"children": [{"id": 7}]}, {"start": 6,"children": [{"id": 7}]}, {"start": 7,"children": [{"id": 8},{"id": 9}]}]

Graph editor

The JSON format defined to represent AASGs can become difficult to use by the analyst if the defined AASGs contain many nodes. Special care must be observed to avoid punctuation errors or unbalanced brackets. A graphical representation of the AASG is more human friendly. For this reason, we propose a method for graphically designing an AASG. The graph is then automatically converted to JSON, so it can be used by a computer system. We propose the use of Cytoscape9 , a renowned open source program for graph design and processing. It was conceived for being used on biological networks, but its interface is generic and allows working with any kind of graph. A screenshot of the AASG of Figure 5.8 as it is represented in Cytoscape is shown in Figure 5.9. We have given a name to each node based on the type of event it identifies. The names given to the nodes do not affect the final structure of the AASG in JSON, and it is just a form to help the analyst during the creation of the graph.

Each node should have an attribute e_star where the list of conditions is coded. Conditions are strings composed of three parts separated by the character '#'. Each part represents a member of the condition in order: function, att and r if it is an absolute condition, and function, attP and attC if it is a relative condition. In case that one of the parts is a list, as it happens for example with r when using function SET, its elements are separated by '$_'. For instance, the first condition of e ⇤ 1 would be expressed as 'SET#type#Sandmind_Amslverify_Overflow$_Admind'.

We have developed a program in Python to do the automatic conversion between one of the standard exportation format used by Cytoscape, Cytoscape.js JSON (.cyjs), and the JSON format defined in section 5.4.1. It also allows defining several AASGs in the same Cytoscape document without specifying which node belongs to each AASG. The coded algorithm automatically analyzes all the nodes and arcs to return a JSON where the AASG are separated and their root nodes identified. We have also developed a program to convert back from AASG JSON to Cytoscape.js format.

Summary

In this chapter we have defined what is an Abstract Attack Scenario Graph (AASG) and how we can use it to represent alternative attack scenarios. AASGs have been introduced in section 5.1 using some examples of practical applications, involving multistep attacks such as WannaCry or the attacks contained in the DARPA 2000 dataset. We have then given a formal definition of AASG in terms of graph theory in section 5.2, followed by a full example of creation of an AASG in section 5.3. Details about the implementation of an AASG using a JSON format are shown in section 5.4, together with a format for graphically representing the AASG in Cytoscape. These formats are conceived to be understood both by humans and machines. All the examples of AASG used throughout this thesis are gathered together in Appendix F.

The AASG model fulfills all the requirements we had fixed in section 5.1.2:

1. Representativeness. An AASG is able to capture the hypotheses of the analyst about multi-step attacks. We saw an example in section 5.3.

Simplicity and intuitiveness.

The AASG is human readable, whether in its mathematical formulation (section 5.2), in its visual representation (e.g. Figure 5.8) or in the JSON format (section 5.4.1).

3. Mathematical form. A mathematical definition of the AASG using elements from graph theory has been given in section 5.2.

4. Computation friendliness. An AASG can be easily adapted to work with computers. We have proposed the JSON format in section 5.4.1 specifically to do so.

5.

Compliance with the purpose. We will see in Chapter 6 how AASGs are suitable for the tasks of identification and detection of multi-step attacks.

6. Boundness. The end of a scenario is well defined in an AASG as a node with no further children. This requirement is enforced because an AASG has no cycles.

7.

Uniqueness. Each AASG is univocally identified by its root node  0 .

8. Flexibility. Absolute and relative conditions, presented in sections 5.2.4 and 5.2.5, respectively, allow representing a wide variety of sequences of events. 9. Suitability for learning. Probabilities can easily be assigned to each arc in an AASG. This is the reason why children are represented as objects in the JSON format (see page 130). We will address this topic in Chapter 6.

Once the AASG has been defined, the challenge now is the development of algorithms able to exploit its characteristics. We will be seeing a couple of them in the next chapter.

Chapter 6

Algorithms to exploit AASG In that deep senselessness I had a vision: There was the oak, as many-leaved as ever, As many ants among its many branches --Ovid, Metamorphoses (The Myrmidons)

We have seen in Chapter 5 how different multi-step attack cases can be arranged into an AASG. The motivation under the design of AASGs is to have a solid link between the alternative cases of attack conceived by the human analyst and the exploitation of these alternatives by an algorithm. The objective is to guide the human in a) the determination of which alternatives better represent the attack and b) the detection of any of the proposed alternatives when they are identified within the events in the network.

To reach this goal, an algorithm exploiting AASGs should be built on the following premises:

• Identification. An evaluation of the importance of each arc is needed to determine which branch better correspond to the attack. An AASG allows the assignation of weights to numerically represent this importance.

• Detection. Alarms should be generated to signal potential attacks.

• Human in the loop. The evaluation of these alarms as truth detections or false positive should be used to improve the information coded in the AASGs.

One of our proposal to this respect is Morwilog, a method based on Ant Colony Optimization (see section 6.1.1). We present it in detail in section 6.1. A second method is Bidimac, an adaptation of Bayesian inference for the exploitation of AASGs, presented in 6.2. The evaluation of different multi-step attack alternatives proposed by the human analyst is original and has not been considered in the current literature. As it is based on classical Bayesian inference, Bidimac provides a reference to compare Morwilog with an existent paradigm. The theoretical similarities between the two methods are discussed in section 6.3.

Morwilog

Morwilog is the main algorithm we propose for the exploitation of AASGs. It was first presented in 2016 at the Symposium Series on Computational Intelligence (SSCI) [Navarro 2016] in Athens and retaken later for another paper published in the EURASIP Journal on Information Security [Navarro 2018b]. The implementation presented then worked on what we called 'event trees', which have evolved to become the current AASGs.

Before presenting Morwilog, we start with a review of Ant Colony Optimization (ACO), the metaheuristic on which Morwilog is based, section 6.1.1. We continue giving a general overview of its functioning in section 6.1.2, before diving into the technical details. In section 6.1.3, we present how the AASG is adapted to become a stigmergic AASG that can be used by Morwilog. We also explain how the evolution of pheromones in the model works. Finally, in section 6.1.4 we present the algorithm in the form of pseudocode, describing its functioning step by step.

Ant Colony Optimization

Morwilog is based on Ant Colony Optimization (ACO) [START_REF] Dorigo | [END_REF]], a metaheuristic to solve discrete optimization problems that is inspired by the behavior of foraging ants. We refer to the three diagrams in Figure 6.1, presented in chronological order, during the explanation of this behavior. When the first foraging ant goes out from the anthill (diagram A), it does not know which direction it should take to arrive at the nearest food source. It then starts to randomly wander in the search of food, and so is done by the next ants following it. When one ant eventually discovers a food source, it deposes chemical substances, called pheromones, in its way back home, creating a trail between the anthill and the food source. This trail helps the own ant to retrace the same path back to the food source, but it can also be perceived by other ants. Ants are attracted by pheromones, and this attraction is stronger as the level of pheromones gets higher. There is then a process of indirect communication between the members 6.1. Morwilog 137 of the colony through the modification of the environment, which is called stigmergy [START_REF] Theraulaz | [END_REF]].

As an ant follows a trail created by other ant, it also deposes pheromones, which are added up to the previous ones in the trail. It may happen that several ants find different food sources or different paths to the same food source (diagram B). In that case, a phenomenon of emergence arises and only the shortest path tends to prevail after a certain time, as we can see in the diagram C. This happens because the deposition of pheromones is higher in the shortest paths, where each ant takes less time to go back and forth.

This does not mean that new food sources could not be found once a trail is established. Pheromones are not imperatively followed by all ants, and there exist some of them which explore other directions, such as the one on the right of the diagram C. If one of them finds a closer food source, all the rest will eventually end up going to this source, even if it can take time to do the change. This is possible because the pheromones evaporate upon air contact, avoiding stagnation when disappearing from a previously preferred trail as more and more ants use the new one.

F

ACO is intended to find the optimal solution to a problem by generating artificial ants that, as the real ones, randomly move through a parameter space, tending to follow the trails of pheromones left by themselves and by other ants. The same as an ant colony converges to the shortest path to food, ACO converges to the optimal solution of the problem. We will explain more specifically how the natural behavior of foraging ants is translated into the mechanisms in ACO when explaining the details of Morwilog in section 6.1.2.

There are many algorithms based on the ACO metaheuristic. The first one was Ant System, published in 1991 in the Ph.D. thesis by Marco Dorigo [START_REF] Dorigo | [END_REF]], the founding father of ACO. He applied the algorithm to the traveling salesman problem (TSP), where the search space is fairly straight to define, as routes can be directly translated to the trails taken by the artificial ants. Since then, ACO has been successfully applied to many NP-hard optimization problems such as control of traffic control signals [START_REF] Haldenbilen | [END_REF]] or galvanizing line scheduling [Fernandez 2014]. Note that ACO-based methods are not the only ones inspired by the behavior of ants. There is another family of algorithms to perform clustering that is inspired by how a certain type of ant piles the bodies of its dead mates [START_REF] Zhe | [END_REF]].

We find several proposals of ACO-based algorithms applied to attack detection. Some of them implement the artificial ants as agents that move from one asset to the other and collaborate in the detection and anticipation of attacks [Hui 2009[START_REF] Fink | [END_REF]]. Other work uses the inspiration from ant behavior to perform anomaly detection through the clustering of traces [START_REF] Jeyepalan | [END_REF], Fernandes 2016], in some cases in combination with supervised methods such as SVM [START_REF] Feng | [END_REF]]. ACO has also been combined with an evolutionary fuzzy system for the generation of detection rules [Abadeh 2015]. More examples have been collected in two surveys, one about swarm intelligence in intrusion detection [START_REF] Kolias | [END_REF]] and the other about bio-inspired security approaches [START_REF] Rauf | A Taxonomy of Bio-Inspired Cyber Security Approaches: Existing Techniques and Future Directions[END_REF]]. None of these examples addresses multi-step attack detection. We have found some approaches modeling the behavior of an attacker in an attack graph when performing a multi-step attack [START_REF] Mahanti | [END_REF], Zhang 2009], but none of them proposes a detection method on incoming traces.

The version of ACO that directly inspired the creation of Morwilog is the Hommilière (Manhill) system developed by Valigiani [START_REF] Valigiani | Développement d'un paradigme d'optimisation par Hommilière et application à l'enseignement assisté par ordinateur sur Internet[END_REF]] in his Ph.D. thesis. This system has been implemented in an e-learning platform, and its goal is to recommend personalized learning paths to each student. The recommendations depend on a mix between the past performance of the student and the results obtained by other students following similar paths. In the Manhill algorithm, the paths traversed by the artificial ants are built through the different lessons, which are arranged in the form of a graph [START_REF] Gutiérrez | [END_REF]]. The level of deposed pheromones depends on how good are the results got by the student after each lesson, confirming or not the pertinence of that lesson in the educational evolution of the student. The most interesting Table 6.1: List of parameters for Morwilog, together with their description and the reference value used in the examples contribution made by this algorithm is the interaction between the students and the ACO model. An artificial ant is created when a student connects to the platform. This notably differs from most of the existent implementations of ACO, where a fixed amount of artificial ants is created when the algorithm begins its execution. This brings the possibility of incorporating the variability of natural events, in this case the arrival of students, to the generation of the artificial ants. We have taken this idea in the conception of Morwilog, where the natural entity are the traces, that generate an artificial ant when they are collected by the system.

General overview of Morwilog

Morwilog applies an ACO-based mechanism on AASGs to help the security analyst in the confirmation or refusal of the alternative scenarios represented in each of the branches. An artificial ant generated within the execution of the algorithm is called morwi. This term is the prefix meaning 'ant' in Proto-Indo-European [Pokorny 2007], a theoretical reconstruction of the common ancestor of the Indo-European languages [Clackson 2007]. The creation of each morwi is linked to an external phenomenon: the arrival of an event matching the root node  0 of one of the AASGs stored in the database. Once a morwi is created, it moves through the AASG in a process similar to the one used by rule-based correlation methods (see section 5.1.3, page 110). From each node, the morwi searches for events matching the children of that node among the incoming events. This search is performed during a maximum time T max , defined for avoiding the saturation of system resources. T max is one of the parameters in Morwilog. All the parameters used are listed in Table 6.1 together with a reference value used in the examples of this chapter. Their purpose will be explained as we describe how the algorithm works.

Once the matched children are found, the morwi chooses one of them to continue its journey through the AASG. This choice is based on a certain level of pheromones previously deposed by other morwis. We explain how pheromones are associated to the different arcs in the AASG in section 6.1.3. So far we just need to consider that each arc  n  m has a number ⌧ n,m associated to it representing a level of pheromones.

A morwi chooses the following node with a probability that is proportional to the level of pheromones associated to the arc leading to that node. There is then a higher probability of choosing a path with a higher level of pheromones, like in classic ACO. We define the choosing probability of an arc  n  m in the AASG as the probability that a morwi being in the node  n chooses the node  m given that events matching also all the rest of the children of  n are found. This probability is expressed as:

P n,m = P ( n  m ) = ⌧ n,m P a b 2A|a=n ⌧ a,b (6.1)
The morwi follows this process of event search and random selection until it reaches a node with no children. When this happens, it returns the found sequence to the security analyst. The security analyst needs to check the effects of the actions reflected in the events to verify if they represent an attack or not. Once a verdict is taken, the analyst transmits it to Morwilog, which accordingly updates the level of pheromones associated to each arc in the AASG. If the sequence is considered as an attack, the levels of pheromones associated to the selected branch are incremented and the branch is thus reinforced. If it is not evaluated as an attack, the level of pheromones is decremented. In both cases, a mechanism of pheromone evaporation takes place to avoid stagnation, as it is proposed in classic ACO. More details about the evolution of pheromones are presented in section 6.1.3.

Signals sent to the analyst to indicate the identification of a branch are called 'alarms' to differentiate it from 'alerts'. This distinction avoids confusion with IDS alerts, that can be at the input of both Morwilog and Bidimac. Anyways, alarms generated by both algorithms are also alerts in the sense of the definition in section 2.3.

Before going into the technical details of Morwilog, we present an example of how it works in general terms. The AASG used is built for the WannaCry attack (see section 3.2.1). The example is illustrated in Figure 6.2 and the list of the types of event represented by each node is given in Table 6.2. The evolution of pheromones in the example will be explained later in this chapter.

The steps followed by Morwilog from the creation of a morwi until it returns a sequence of events as an alarm are described hereunder. b) Starting in  0 , the morwi searches for events matching each one of the nodes being children of  0 . The maximum search time is T max . In this case, events e j and e k are found, corresponding to  1 and  2 , respectively. Now the morwi has to decide a node for continuing its trip through the AASG doing a pheromonebased weighted random selection. The node whose connection with the present node has a higher level of pheromones,  1 , is the most probable option. c) Imagine the morwi chooses this node  1 , matched by the event e j . Now it has to search the events matching the nodes among the children of  1 . In this case, no event is found corresponding to  4 , which represents the exploitation of a vulnerability in SMBv21 . Only events e l and e n are found, matching  3 and  5 , respectively. The morwi needs to choose between these two nodes, the first one having a higher probability.

d) We can imagine the morwi chooses  3 . It then stops because the node has no children. The sequence (e i , e j , e l ) is returned then as a possible attack.

In this case, the sequence corresponds to a real instance of WannaCry and the hypothesis is reinforced. The reinforcement is done through the modification of the level of pheromones based on the feedback coming from the human analyst. When she confirms the malicious nature of the sequence, the pheromones associated to the matched branch in the AASG are incremented. We will continue with the example in the following section (page 146), where we analyze how the pheromones change.

 0  1  3  4  5  2
Events arrived in Morwilog: ei, ej, ek

t  Tmax Tmax During t  Tmax 9ej : M (ej, 1) = 1 9ek : M (ek, 2) = 1 During t  Tmax 9el : M (el, 3) = 1 @em : M (em, 4) = 1 9en : M (en, 5) = 1 ⌧0,1 = 2700 ⌧0,2 =
 0  1  3  4  5  2
Events arrived in Morwilog: ei, ej, ek, el, en

t  Tmax Tmax During t  Tmax 9ej : M (ej, 1) = 1 9ek : M (ek, 2) = 1 During t  Tmax 9el : M (el, 3) = 1 @em : M (em, 4) = 1 9en : M (en, 5) = 1 ⌧0,1 = 2700 ⌧0,2 =
 0  1  3  4  5  2
Events arrived in Morwilog: ei, ej, ek, el, en

t  Tmax Tmax During t  Tmax 9ej : M (ej, 1) = 1 9ek : M (ek, 2) = 1 During t  Tmax 9el : M (el, 3) = 1 @em : M (em, 4) = 1 9en : M (en, 5) = 1 ⌧0,1 = 2700 ⌧0,2 =

AASG as the stigmergic scenario

The AASG is then the scenario where the process of stigmergy (see page 137) between morwis is performed. Pheromones are deposited in the arcs of the AASG for reinforcing a path leading to a confirmed attack or retired to penalize one leading to a false alarm. This stigmergic process gives information to the newly generated morwis.

The values of pheromones are easily incorporated into the AASG model. Their accumulation is represented by ⌧ n,m 2 R >0 for each existent arc  n  m . A modified AASG including ⌧ n,m in its arcs is called a stigmergic AASG. To represent pheromones in the JSON format, we just add the numeric member ph to each object in children for each one of the sets of arcs (see page 130).

The increment and decrement of pheromones is performed according to the evaluation of the alarms done by the security analyst, who provides feedback to the system. The amount of pheromones to be added up to the existent level of pheromones in an arc once the analyst has decided to reinforce the branch is called ⌧ + . The amount of the decrement is called ⌧ . To refer to any of the two, we use ⌧ +, . We have that ⌧ + 2 R >0 and ⌧ 2 R <0 .

If we consider ⌧ [t] as the level of pheromones after update t, with t 2 N:

6.1. Morwilog 143 ⌧ [t + 1] = ⌧ [t] + ⌧ +, (6.2)
The same as in classic ACO, a mechanism of pheromone evaporation is needed to avoid stagnation. Thanks to this, the morwis statistically have an opportunity to stop favoring branches where the level of pheromones is high but that have not been identified for long time. The evaporation consists in the decrease of the previous level of pheromones by an evaporation rate ⇢, with ⇢ 2 R and 0 < ⇢ < 1. The equation to calculate the resulting level of pheromones after evaporation is:

⌧ [t + 1] = (1 ⇢) • ⌧ [t] (6.3)
Evaporation is applied to every arc in the AASG each time there is an update of pheromones, right before the addition of ⌧ +, , independently if the selected branch has its pheromones incremented or decremented.

While evaporation is done as in classic ACO, we have introduced an important variation in the increment and decrement. In the previous literature, both changes are constant and independent of the level of pheromones at the moment when the update is made. The values of ⌧ + and ⌧ are thus fixed before the execution of the algorithm, as parameters. The combination of this fixed addition with the evaporation of Equation 6.3 results in a variation of pheromones whose absolute value decays as subsequent updates of pheromones of the same sign are applied in an arc.

This constant pheromone variation is not enough for strongly penalizing badly chosen branches. We need to have in mind that the analyst can arrive at wrong conclusions when building the AASG, and we want those wrong paths to be out of the selective process as soon as possible. That is why we have introduced in ⌧ + and ⌧ a dependence on the current level of pheromones (⌧ [t]). The proposed function is Gaussian, and ⌧ + = ⌧ :

⌧ + (⌧ [t]) = ⌧ + 0 e (⌧ [t] ⌧ 0 ) 2 2w 2 (6.4)
There are three parameters in this equation: ⌧ 0 , ⌧ + 0 and w. The first one, ⌧ 0 , is the initial level of pheromones in the arc (⌧ [0] = ⌧ 0 ). It is taken as a parameter of the system and every arc in every new AASG is initialized with ⌧ 0 pheromones. The Gaussian function for ⌧ +, is centered to ⌧ 0 to have the highest rate of change right after the creation of the AASG. The amount of change for the first update, when

⌧ [t] = ⌧ 0 , is precisely ⌧ + 0 .
It has the same value for both ⌧ + and ⌧ . Finally, w is a parameter determining how spread the Gaussian function is.

In a complete update, pheromones are first evaporated and then incremented or decremented, based on the new value after the evaporation. Having this in mind, we have the following final equations for increment and decrement updates, respectively:

⌧ [t + 1] = (1 ⇢) • ⌧ [t] + ⌧ + 0 e ((1 ⇢)•⌧ [t] ⌧ 0 ) 2 2w 2
(6.5)

⌧ [t + 1] = (1 ⇢) • ⌧ [t] ⌧ + 0 e ((1 ⇢)•⌧ [t] ⌧ 0 ) 2 2w 2 (6.6)
It is desirable that the absolute value of the level of pheromones in each arc do not exceed certain threshold, to detect the moment from which a branch is clearly confirmed over the others. This also prevents the system to unlimitedly favor an arc. To do so, the difference between consecutive updates of the level of pheromones should decrease as the system evolves. This is the case of the classic ACO equation, whose convergence has been proven by Dorigo and Stützle [START_REF] Dorigo | [END_REF]]. Equations 6.5 and 6.6 given here also converge to a certain value once the parameters are fixed.

For proving that, we choose one of the equations, for example the one corresponding to the increment (Equation 6.5). We can imagine a really large number N of continuous increments in one of the arcs, so we constantly apply the same equation for each update. This scenario is known as a situation of continuous reinforcement. Calculating the exact limit of the Equation 6.5 in this scenario is not as trivial as in classic ACO, due to the recursive nature of the function. But we have empirically proven that this upper limit exists for certain values of the parameters just running the recursive function during a high number of pheromone updates.

The results are shown in Figure 6.3, where the evolution of the level of pheromone in one arc is represented against the number of pheromone updates. We use the parameters shown in Table 6.1. The curve 'Increment' represents the evolution of pheromones under the situation of continuous reinforcement, supposing there is an increment in every update. An upper limit, 3051, is almost reached in around 10 updates.

For comparing this result with classic ACO, we have also represented the result of the fixed increment in a continuous reinforcement scenario in the curve called 'Classic'. To make the two curves comparable, we have chosen an increment value of 62.1, which is approximately the one needed to reach the same upper limit as in 'Increment', 3104,63. We see that our approach reaches the limit much earlier than the classical one.

The same logic can be applied to the decrement function ⌧ . We could imagine a scenario of continuous penalization, where an arc sees its level of pheromones decremented after each pheromone update in the AASG. The function also converges, in this case to a lower limit. But this limit can be negative depending on the parameters chosen. Negative values of pheromones should be avoided, not only to adjust to the biological metaphor but also to make the operations in the algorithm easier, without needing the implementation of negative integers. As in classic ACO, a minimum value of pheromones ⌧ min is artificially set. The level of pheromones in any arc is then force

 0  1  3  4  5  2
Human expert dismiss (e i , e j , e l ) as false positive Evaporation in every arc. Decrement of ⌧ 0,1 and ⌧ 1,3

t  T max T max During t  T max 9e j : e j  1 = 1 9e k : e k  2 = 1
During t  T max 9e l : e l  3 = 1 @e m : e m  4 = 1 9e n : e n  5 = 1 to stay over this value. The curve 'Decrement' in Figure 6.3 shows the results of this continuous penalization, applying ⌧ min = 100.

To finish this introduction, we retake the example we presented in last section (page 140), where the main steps of WannaCry were represented in the AASG. If the sequence returned by the morwi is evaluated as an attack, the level of pheromones of that branch is incremented. The result is shown in Figure 6.4.

On the contrary, we show the mechanism of decrement of pheromones in Figure 6.5. This process is performed because the returned sequence is considered as a false alarm by the analyst. In the case of WannaCry, the command 'transaction2_secondary' in SMBv1, represented in node  3 , can be used for testing purposes and not with a malicious objective, even if it is an important step in the attack. If this happens, the feedback provided by the analyst leads to the process of decrement.

The Morwilog algorithm

The process explained above is formalized in the Morwihill and Morwi algorithms. Morwihill is in charge of generating a morwi each time an event arrives at the system, whose behavior is determined by the algorithm Morwi. We explain first the operations made by each morwi, expressed in pseudocode in Algorithm 6.1, for later presenting the Morwihill operations for interpreting the results returned by the morwi and update the pheromones in the corresponding AASG (Algorithm 6.2).

Each morwi is created after the arrival of an event e i from the set E in of all events that arrive at the system. E in is assumed to be ordered in time. A morwi returns the following elements:

6.1. Morwilog 147 Algorithm 6.1 Morwi algorithm Require: E in ✓ E; e i 2 E in Ensure: s i 2 S E in ; u = (K u , A u ) 2 ; b  2 B u ; isresult 2 {true, false} 1: isresult false 2: u 2 | M (e i ,  0 ) = 1 3: if u 6 = ? and not ( u = last ^ t i,last < T max ^⇧last =true) then 4: s i [e i ] 5:  n  0 2 K u 6: b  [ n ] 7: F n { a  b 2 A u | a = n} 8:
while F n 6 = ? do 9:

C ?

10:

for each  n  b 2 F n do 11:

Find

1 st e q 2 E in | q > i, M (e q ,  b ) = 1, f t 1 ( t i,q , T max ) = 1 12:
if 9 e q then 13:

Add ( n  b , e q ) to C 14:

end if 15:

end for 16:

if C 6 = ? then 17:

( n  c , e c ) c 2 C, ⌧ -based selection 18:
Add e c to s i 19: • s i -A sequence of the found events, in temporal order.

Add  c to b  20:  n  m 21: F n { a  b 2 A u | a =
• u = (K u , A u ) -An AASG among the ones stored in the system with a set of nodes K u and a set of arcs A u . It corresponds to the AASG used by the morwi.

• b  -A succession of nodes representing the branch of u traversed by the morwi.

• isresult -A boolean variable that is true only if the morwi has reached a node without children in u .

First of all, the variable isresult is set to f alse: it becomes true only when the morwi reaches a sink in the AASG. The AASG u is chosen in line 2 as that one whose root node  0 is matched by the event e i (M (e i ,  0 ) = 1). If no AASG is found, the execution of Morwi is interrupted: the event does not represent the beginning of any of the cases proposed by the analyst.

There is another reason why a morwi can interrupt its trip: if the previous morwi generated by the system is similar to the new one, uses the same AASG and it was created less than a period T max before. This interruption is introduced to avoid the creation of several morwis when there is a burst of very similar events, such as the ones present during a port scan. There are three elements referring to the last morwi that help us to set the conditions for this interruption:

• last -The AASG used by the last morwi.

• e last -The event that caused the creation of the last morwi.

• ⇧ last -A function that is true if the current morwi is similar to the last morwi.

This similarity can be defined by the atomic similarity functions listed in Table 3.3, page 52. In the implementation of Morwilog done for this thesis, we have considered two morwis as similar if the events at the origin of them share the type, the source IP address and the source port number. Assuming the value 1 as true and the value 0 as f alse, we can express the used function as

⇧ last = f 1 (type i , type last ) ^f1 (ipsrc i , ipsrc last ) ^f1 (psrc i , psrc last ).
The conditions for the interruption, in the same order as presented, can be then expressed as: ⇧ last = true, u = last and t i,last < T max .

If the trip of the morwi is not interrupted for one of the two reasons stated above, Morwilog substitutes by this morwi the one considered as last at that moment. The morwi then starts going through the AASG u , storing e i and  0 as first event and first node in the sequence, respectively (lines 4 to 6). The arcs going out from  0 are selected in F n and an iterative process for traversing the AASG starts. The process only finishes if the morwi arrives at a sink in the AASG (F n = ?) or no event matching any of the children of the current node is found.

The set of found children is stored in a variable that we have called C. The process of finding an event e q matching a children node  b (line 11) takes into account not only the matching condition itself (M (e q ,  b ) = 1), but also two temporal conditions:

(a) e q should come later in time than e i (q > i), something straightforward as we consider that elements in E in are ordered in time.

(b) The time difference between e q and e i should not be superior to T max . This condition is expressed by the function in Equation 3.7, page 53, as f t 1 ( t i,q , T max ) = 1.

Each found event is stored, together with the corresponding arc, in the set C (line 13). Have in mind that the Morwi algorithm only looks for the first of the events, e q , matching the conditions defined by the node to which each arc leads, even if there are subsequent events that could be eligible.

If no event has been found, the morwi finishes its journey in line 24. If several events are found, a weighted random selection of one of the elements in C is made in line 17. The selection, called ⌧ -based selection, is based on the level of pheromones of the arcs leading to the matched nodes. The probability of each node  c of been chosen is like the choosing probability defined in Equation 6.1 but only applied to the found children:

P ( c ) = ⌧ n,c P (n j ,ec)2C ⌧ n,i (6.7)
The selected event is directly added to the output sequence s i and its corresponding node  c is added to b  . The process is repeated from  c if it has further children (lines 18 to 21). The event e q is preserved in line 22 because the matching operation M (e, ) can depend on the previously found event, as we saw in section 5.2.3, if there are relative conditions in the abstract event contained in the node. If the morwi successfully arrives at a sink in the AASG, isresult becomes true.

The set of morwis is managed by the Morwihill algorithm, whose pseudocode is shown in Algorithm 6.2. Notice that every time an event e i arrives at the system, a morwi is created (line 2) but as an independent thread. Morwihill has to be prepared to pass right after to new events just when they arrive, so a new morwi can be generated each time. For each event, the algorithm verifies if any morwi has finished its execution returning an event sequence that ends by e i (line 3). If it is the case, Morwihill manages the results returned by all these morwis.

The boolean variable isresult is a way to tell the Morwihill algorithm to consider the returned sequence as matching one of the multi-step attack cases proposed by the analyst in an AASG. If the morwi properly finishes its journey through an AASG, reaching a node with no further children, a sequence of events matching one of the branches of that AASG is signaled to the analyst by raising an alarm (line 6). Depending on whether the analyst considers the sequence an attack or not, pheromones in the branch will be incremented (line 10) or decremented (line 12), respectively. In any of the two cases, all pheromones in the AASG are previously evaporated (line 7).

It is difficult to give an exact order of the computational complexity of Morwilog. There are too many factors involved to theoretically set the limiting behavior of the algorithm. Apart from the size of the dataset, it also depends on the structure of the AASGs or on the parameters of the system. We give then a list of dependencies related to the computational complexity of Morwilog: Chapter 6. Algorithms to exploit AASG Algorithm 6.2 Morwihill algorithm Require:

E in ✓ E 1:
for each e i in E in do 2:

Create thread Morwi(E in , e i ) . Launch morwi µ i 3:

for each morwi µ x | last element in s x = e i do 4:

{s x , u = (K u , A u ), b  , isresult} result from µ x 5:
if isresult = true then 6:

Raise an alarm returning {s

x , u = (K u , A u ), b  } 7: ⌧ n,m (1 ⇢) • ⌧ n,m 8  n  m 2 A u . Evaporation of pheromones 8:
for each

 n  m 2 b  do 9:
if s x is an attack then 10: end for 17: end for

⌧ n,m ⌧ n,m + ⌧ + 0 • exp( (⌧ n,m ⌧ 0 ) 2 /2w 2 ) 11: else 12: ⌧ n,m ⌧ n,m ⌧ + 0 • exp( (⌧ n,m ⌧ 0 ) 2 /2w
• The number of created morwis is equal to the number of incoming events, as each event generate a morwi.

• The number of morwis that start to work with an AASG is equal to the number of events matching a root node  0 of one of the AASGs used.

• The number of comparisons between a node and an event depends on several factors:

-The maximum depth of the branch chosen by the morwi in the selected AASG.

-The distance in terms of number of events between the events found for that specific branch.

-The maximum search time T max .

-The number of children of each evaluated node.

Notice that there is an important assumption in the functioning of this algorithm: the response of the analyst is considered to be immediate after an alarm is raised. This allows a better understanding of how the algorithm works and eases the execution of the experiments. However, we know that this is never the case in a real security system, where the alarms accumulate in a console until the analyst can verify and acknowledge them. Morwilog would work exactly in the same way if we hold the generated alarms in a queue and pheromones are modified once the analyst has been able to confirm or refuse the returned sequences as attacks. The only constraint in this case is that if an event arrives and matches an AASG whose pheromones are pending to be updated, the new morwi will go through a non-updated version of the AASG. To simplify the explanation, the description of Morwilog given so far does not consider either counters nor optional nodes, presented in section 5.2.6. When a morwi finds a node with a counter higher than 1 among the children of a node, it will simply repeat the process of looking for an event matching the node as many times as the counter indicates. The maximum difference of time T max is then considered between each one of repeated matches. If every repetition is found, the node is considered to be 'matched' and the first of the events in the sequence is returned as part of s i .

Optional nodes are considered when loading new AASGs, before the execution of the algorithm. Each AASG with optional nodes is transformed into a new structure where the number of branches is augmented to reflect the facultative occurrence of the optional nodes. This new structure is an AASG except for one detail: the fourth property of AASGs (page 117) is not preserved, meaning that not all the nodes have a unique depth. We choose to do so to simplify the execution of the algorithm. An alternative AASG that preserves this property could be easily built duplicating the nodes, but that would force the algorithm to consider them as distinct nodes, which could be confusing for the analyst that has designed the AASG. In Figure 6.6 we see how the lower part of the AASG coming from Figure 5.8 is transformed under both approaches: option a) maintains the fourth property of AASGs duplicating the nodes and option b) does not, but it eases the implementation in Morwilog.

Bidimac

The second of the proposed algorithms to perform identification and detection using AASGs is Bidimac. Its details have not been published yet. Bidimac is based on Bayesian inference, a type of statistical inference. In section 6.2.1, we explain how Bayesian inference works and introduce several assumptions to adapt Bayesian networks to AASGs. We have chosen a Bayesian approach for Bidimac because of its similarities with Morwilog. These similarities, reviewed in section 6.2.2, are at the basis of choosing Bayesian inference as an alternative to Morwilog, so it is important to understand them before explaining the Bidimac algorithm in section 6.2.3. Bidimac is more than another algorithm to work with AASGs, but also a way to compare Morwilog with the widely used Bayesian inference.

Adapting Bayesian inference to AASG

Bayesian inference is a type of statistical inference based on the use of the Bayes' theorem. We already introduced the concept of statistical inference in section 4.3.2.2, page 80. In Computer Science it is also referred to as 'learning'.

Bayesian networks are the support used for this kind of inference. A Bayesian network is a model that represents a set of probability-based relationships between n random variables [START_REF] Husmeier | Introduction to learning Bayesian networks from data[END_REF]]. It is composed of a DAG, with the nodes representing the variables and a set of probability distributions associated to each variable with regard to its parents [Koski 2011]. Two nodes are connected if the model considers a causal relationship between them. Conversely, two variables that are not connected by any arc are conditionally independent of each other [Stephenson 2000]. Figure 6.7 shows an example of a Bayesian network. In this network, variables X 2 and X 1 , for example, are conditionally independent, while X 0 and X 4 are not.

We will be working only with Bayesian networks in which every random variable X i has the same sample space. Moreover, they will be discrete variables, having a finite set of possible values x k associated to them. Notation is remarkably simplified under this scope. We can define a probability parameter ✓ ijk , which represents the probability that X i = x k given that X j is the parent. In other words:

✓ ijk / P (X i = x k |X j ) (6.8) ✓ 3,1 ✓ 4,1 ✓ 5,1 ✓ 6,2 ✓ 7,2 ✓ 1,0 ✓ 2,0 X 0 X 1 X 3 X 4 X 5 X 2 X 6 X 7 Figure 6.7: Example of a Bayesian network.
This represents the probability of what we call an ijk case, an instance of a variable X i associated to a parent j with a value corresponding to k. If the sample space of the variables has only two elements ({x 1 , x 2 }), we can select one of them (e.g. x 1 ) to use it as a reference and simplify notation, removing the k from the probability parameter:

✓ ij / P (X i = x 1 |X j ) (6.9)
The information about the transition become complete if we assume that ✓ ij =

P (X i = x 1 |X j ) = 1 ✓ ij2 = 1 P (X i = x 2 |X j ).
Each Bayesian network has an associated joint probability function. Given that the network is composed of the set of n variables X = X 0 , . . . , X n , the probability P (X) can be calculated as the product of every conditional probability between pairs parent-children [Stephenson 2000[START_REF] Jensen | [END_REF]]:

P (X) = n Y i=0 P (X i |parents(X i )) (6.10)
Bayesian inference always needs a starting point, a previous definition of the model. It does not matter if the structure of the network is manually built or if it is learned from a set of training data [START_REF] Husmeier | Introduction to learning Bayesian networks from data[END_REF]], but prior probabilities are needed to perform the induction. These probabilities thus represent a degree of belief of each causal relationship in the network, which is updated as more information about the modeled process is obtained.

Different methods exist to do Bayesian learning from new data D, depending on how complete is the network topology and the used data. In the context of Bidimac, we already have the Bayesian network, which is an AASG previously defined by the security analyst (see section 6.2.3). We just need to learn the parameters or beliefs. Concerning the data, we assume that it is fully observable. In consequence, we just need to focus on the simplest case [Cao 2014]: Bayesian learning with known network structure and full observability.

Heckerman derives a formula for this Bayesian estimation assuming that the prior probabilities are represented by Dirichlet distributions. The reader is referred to Heckerman's technical report [Heckerman 1995] to get details about the deduction. The result is summed up by Stephenson [Stephenson 2000] as:

✓ ijk = ↵ ijk + N ijk ↵ ij + N ij (6.11)
Here, ↵ ijk represents the number of times that a certain ijk case appears in the learning dataset D. N ijk represents the prior belief about how many times the ijk case would occur, assuming D is unknown. ↵ ij and N ij are equivalent to the previous ones but adding up all the occurrences in every possible instantiation k: ↵ ij = P 8k ↵ ijk and N ij = P 8k N ijk . However, it is not very intuitive to express prior beliefs as the number of times an event could happen. We always tend to directly assign a probability to uncertain events. The prediction "there is a 30% chance of rain" is more understandable than "if the day of today was repeated 100 times, we would have rain in 30 of them". We can express the probability parameters in terms of the prior estimation without specifying the estimated number of times for each ijk case. To represent the importance of prior estimations against new ones, we can use a learning rate 0 < ⌘  1, as the one used by Qin and Lee [START_REF] Qin | [END_REF]]. The expression to derive the new probability parameter ✓ t ijk from the previous one ✓ t 1 ijk is now:

✓ t ijk = ⌘ N ijk N ij + (1 ⌘)✓ t 1 ijk (6.12)
The main difference between the two approaches is that if we use equation 6.11 the size of the dataset D used is taken into account for each estimation. If D is bigger, the statistical update is supposed to be more reliable and the prior belief is less important. This approach is thus very convenient if we update the network with datasets of different sizes. Another advantage of this method is that ✓ t ijk exactly corresponds to the probability of the transition.

On the contrary, using equation 6.12, we give the same importance to any new dataset, independently of its size. The statistical relevance of the dataset is thus not considered. However, this second approach is more advantageous if the datasets used have more or less the same size, as it happens if we want to update the parameters in real time, when the size of D is 1 if we update sample by sample. Moreover, instead of having an input parameter ↵ ijk for each ijk case, we only have the learning rate ⌘. We lose in statistical accuracy but we gain in simplicity of computation and number of parameters.

Morwilog and Bayesian inference

The reader may see a certain parallelism between Morwilog and methods doing Bayesian inference. This resemblance indeed exists, even if classic ACO, in which Morwilog is based, is not directly comparable with Bayesian inference. ACO and Bayesian inference are applied for different purposes: while the former is a metaheuristic for optimization, the latter is a method for statistical inference. That does not mean that they cannot complement each other. As ACO is used for optimization, it can be adapted to find the best possible Bayesian model for a giving problem. In general terms, the two elements defining a Bayesian network are the structure of the DAG representing it and the probabilities or beliefs assigned to each node. For the second one there exist several algorithms for Bayesian inference, but none of them uses, as far as we know, the ACO metaheuristic. However, some work exists in the literature about how to learn the structure of the Bayesian network using ACO [START_REF] Daly | [END_REF], Wu 2010, Salama 2013].

Even if Morwilog is ACO-based, it does not work as classic ACO, and the comparison with Bayesian is more than pertinent. The objective of Morwilog is not to look for an optimal solution among a set of possible solutions, but to give the security analyst the events corresponding to a multi-step attack case and to modify the AASG according to the analyst's verdict. The result after several iterations is finally similar to that of Bayesian inference methods, a DAG whose transitions have an associated probability, coded as artificial pheromones. Morwilog is comparable to Bayesian inference if we follow the general definition given by Dempster [START_REF] Dempster | A generalization of Bayesian inference[END_REF]]. The same as Bayesian inference, it starts with a global probability distribution for all the sequences (initialization of pheromones) and deduces the conditional dependences between the events after verification by the analyst. A direct comparison between the two techniques reveals then necessary to define the place of Morwilog among data analysis methods.

The similarities between Morwilog and Bayesian inference are listed below:

• Bayesian logic. Both of them follow the Bayesian logic: the probabilities are defined a priori based on personal belief and evolve based on the incoming data.

In Morwilog, initial beliefs, represented as pheromones, are the same for every transition.

• DAG. They use Directed Acyclic Graphs (DAG) to represent the relationships between different pieces of data. In the implementation presented in this thesis, Bayesian inference is adapted to work with AASGs.

• Probabilities of transition. Nodes in the DAG are linked by numbers suggesting the probability of transition. In the case of Morwilog, these numbers are the artificial pheromones.

• Statistical information. The resultant graph gives information about the statistical distribution of the events associated to each node, after the adaptation of the numbers associated to each transition to new data.

We will see in section 6.3, after presentation of the Bidimac algorithm, that there are also many differences between the two approaches.

The Bidimac algorithm

We adapt the Bayesian inference mechanism to work towards the same goal as Morwilog, using the AASGs as Bayesian networks. The resulting algorithm is called Bidimac, that stands for Bayesian Inference for Detection and Identification of Multi-step Attack Cases. Some requirements have to be taken into account:

1. Each one of the arcs  n  m in the AASG should have a probability parameter ✓ n,m associated to it, in the same way as the level of pheromones in Morwilog.

2. Feedback from the security analyst has to be incorporated into the system, so the probability parameters can evolve according to her verdict.

3. The AASG has to be updated in real time, as the feedback from the analyst is received.

The first requirement is easy to be fulfilled, just by substitution of the level of pheromones ⌧ n,m in the stigmergic AASG by the probability parameter ✓ n,m . It should represent the probability of  n being matched by an event e i and  m being matched by an event e j given that e j is immediately following e i in a sequence of events that a) entirely matches event by event a branch in the AASG and b) is considered a multistep attack after verification by the analyst. The resulting AASG is called a Bayesian AASG. In the JSON format of the AASG, ✓ n,m is incorporated into each set of arcs as the numeric member prob inside the objects in children (see page 130).

The probability parameters are equivalent to the choosing probability defined in Equation 6.1 for the pheromones. This gives us a way for weight comparison between stigmergic AASGs (pheromones) and Bayesian AASGs (probability parameters):

P n,m = P ( n  m ) = ✓ n,m P a b 2A|a=n ✓ a,b = ✓ n,m (6.13)
For the initialization of the stigmergic AASG, the same level of pheromones ⌧ 0 is assigned to every arc. This result in the same value of P n,m for all the arcs leading to a set of siblings. In other words, right after initialization of the stigmergic AASG,

⌧ n,m = ⌧ 0 8 n  m 2 A and thus P n,m = P o,p 8P n,m , P o,p | n = o.
In the initialization of a Bayesian AASG, we preserve the same property by assigning the same probability parameter to every arc going out from a parent and establishing that the addition of the elements in this set should be equal to 1. In fact, what we do when initializing a Bayesian AASG is to take a newly created stimergic tree and to change the level of pheromones ⌧ n,m to ✓ n,m = P n,m as defined in Equation 6.1.

This equivalence between initial value of ✓ n,m in the Bayesian AASG and the choosing probability P n,m can also be used in the adaptation of a stigmergic AASG where there have already been pheromone updates. An example of this is shown in Figure 6 The second requirement is the incorporation of feedback from the analyst. This is done by sending an alarm to the analyst each time that a sequence of events matches a branch in the Bayesian AASG and updating the probability parameters only when that sequence is confirmed as an attack. As in Morwilog, we only consider the sequences whose consecutive events have a difference in time not bigger than T max .

Finally, to fulfill the third requirement, addressing real time update, we just need to consider that the learning dataset D contains only one element each time an update is made, so 6.12. Sequences matching a branch are evaluated by the analyst one by one. Once she considers that the returned sequence is an attack, the update of the probability parameters is done according to the following formula:

N ijk N ij = 1 in Equation
✓ t n,m = 8 < : ⌘ + (1 ⌘)✓ t 1 n,m if  n  m belong to the matched branch (1 ⌘)✓ t 1 n,m otherwise (6.14)
That means that only those arcs in the matched branch are reinforced in terms of their probability parameters, while all the others are penalized. The statistical coherence with respect to the incoming data is then preserved, and no specific penalization mechanism is considered when a false positive is found. As the Bayesian AASG does not reflect all the possible relationships of causality between the events, but only those contained in the hypotheses formulated by the analyst, sequences that are not an attack do not contribute to the update of the AASG. Penalization of branches not representing an attack is indirectly done when an attack matching any other branch is found.

The Bidimac algorithm is represented in the form of pseudocode in Algorithm 6.3. The subroutine to search for new matched branches from each given event e i , called BranchesSearch, is shown in Algorithm 6.4. Notice that oppositely as it happens in the Morwi algorithm, this routine can return several matches, corresponding to different branches of the selected AASG. In this way, the Bayesian AASG fully represent the statistics of the incoming events. We consider only the first match when looking for events corresponding to the nodes in the branch (line 8 in Algorithm 6.4).

The same as it happens with Morwilog, it is difficult to precise the complexity of the algorithm because it depends on many factors. All the dependencies mentioned for Morwilog are totally applicable to Bidimac if we substitute the word 'morwi' by 'search process' in the list of page 149. However, there is an additional characteristic of the AASGs that directly affects the complexity of Bidimac: the number of branches. Each time an event matches the root node of an AASG, Bidimac searches for events matching each one of the branches, while Morwilog chooses just one. The number of searched sequences in Bidimac for a given AASG is thus proportional to the number of branches. for each element r x 2 R found | last element in s x = e i do 4:

Differences between

(s x , u = (K u , A u ), b  , isresult) r x 5:
if isresult = true then 6:

Raise an alarm returning {s

x , u = (K u , A u ), b  } 7:
if s x is an attack then 8:

for each  n  m 2 A u do . Update probability parameters end for 18: end for ⇤ When the execution finishes, the returned set of elements is stocked in R found

9: if  n  m 2 b  then 10: ✓ n,m ⌘ + (1 ⌘)✓ n,

Differences between Morwilog and Bidimac

There are some characteristics of Morwilog and Bidimac that make them very different, even if they share a similar approach towards the use of AASGs. These differences lie in the following elements:

• Choice among options. In Morwilog, each morwi evaluates the nodes in the AASG step by step, choosing only one path among the ones found. When more than one sequences of events match an AASG, just one of them is chosen to be evaluated by the security analyst. In Bidimac all the found sequences are returned to the analyst.

• Statistical meaning of weights. The level of pheromones does not correspond to the probability of appearance of a sequence, even if some information in this regard can be deduced from its value. It indicates the probability of a node to be chosen against its found siblings as the following element in the path. In Bidimac, the probability parameters directly represent the transition probability between nodes according to the existence of pairs of events matching the nodes.

• Mechanism to penalize or reinforce paths. The mechanism for incrementing or decrementing the level of pheromones can be implemented by any kind Algorithm 6.4 BranchesSearch algorithm Require:

E in ✓ E; e i 2 E in Ensure: Set R x of 4-tuples with the form (s i 2 S E in , u = (K u , A u ) 2 , b  2 B u , isresult 2 {true, false}) 1: u 2 | M (e i ,  0 ) = 1 2: R x ? 3: if u 6 = ? then 4:
for each branch b  2 u do 5:

s i [e i ] 6: isresult false 7:
for each node  a 6 =  0 2 b  , taken in order do 8:

Find

1 st e q 2 E in | q > i, M (e q ,  a ) = 1, f t 1 ( t i,q , T max ) = 1 9:
if 9 e q then 10:

Add e q to s i 11:

if @ x  y 2 A u | x = a
Add (s i , u , b  , isresult) to R x 19:
end for 20: end if 21: return R x of function, while in Bidimac the penalization or reinforcement of a path only depends on statistical evidence.

• Decrement of choosing probability. Morwilog incorporates two mechanisms for decrementing the choosing probability: evaporation and penalization. Bidimac does not incorporate a mechanism of explicit penalization for found sequences that are not attacks.

In this section we present each one of the listed differences and their connotations.

Choice among options

In both algorithms, events matching each node in the AASG are searched sequentially, considering a maximum difference of time T max between consecutive events. This T max should be long enough to ensure that all the events matching each set of children are found, but not so long as the resources of the system in terms of number of processes are fully used.

In Morwilog, once all the children have been found or no more events fulfill the condition of time difference, a weighted random choice is made based on the level of pheromones assigned to each arc. This process is also called a ⌧ -based selection (see page 149). For every event matching the root node  0 of an AASG, only one branch is followed, even if other sequences that start with the same event could match another branch in the same AASG.

Conversely, in Bidimac there are no options. Bayesian inference is intended to reflect the statistics of the incoming dataset, so it takes into account all the sequences matching the AASG and representing a multi-step attack, even if some of them have events in common. Every matching sequence is presented to the analyst for evaluation.

The consequence of this is that, in general, Bidimac returns more sequences for verification (alarms) than Morwilog, thereby demanding more effort to the security analyst. The number of sequences is exactly the same if no sequence matching the AASG has an event in common with the others, considering the limit of time of T max . In this case there is no election of choices in Morwilog because there are no choices, and both approaches return the same sequences. Figure 6.9 shows an example of the evolution of two equivalent AASGs under the two approaches. We have chosen a very simple AASG, with a root node  0 that has two children  1 and  2 . For the evolution of the pheromones, we use the parameters presented in Table 6.1. To update the probability parameters in Bidimac, we use a learning rate ⌘ = 0.4. The events involved in the evolution of the AASG are shaded in dark blue.

Suppose that in a first phase an event matching  0 is found, followed by two other events matching  1 and  2 with a difference of time with the first one inferior than T max . Both sequences represent an attack. When this happens in Morwilog, the morwi chooses just one branch. We can then consider two alternative cases: one in which  1 is chosen (Case A) and a second one in which  2 is chosen (Case B). The chosen sequence is sent to the analyst for verification. In Bidimac, both sequences generate alarms because no choice process exists.

We also represent in the right of the figure the effect on the AASGs of a second phase in which another sequence of events matching  0 ,  1 and representing an attack arrives to the system. As there is only one sequence matching the AASG and no event is found matching  2 , there is not a choice process in Morwilog and both approaches, Morwilog and Bidimac, return just one alarm.

Concerning Morwilog, Case A is the most probable in terms of the ⌧ -based selection. It is evident how the presence of a choice makes the result from Morwilog different than 1000 200

 0  1  2 1480 196  0  1  2 1902 192  0  1  2 Case A 1000 200  0  1  2 980 558  0  1  2 1460 547  0  1  2
Case B Morwilog execution 0.83 0.17

 0  1  2 0.54 0.46  0  1  2 0.72 0.28  0  1  2 Bayesian execution First phase Second phase { 0 ,  1 } ! attack { 0 ,  2 } ! attack { 0 ,  1 } ! attack Figure 6
.9: Example of Morwilog (parameters from Table 6.1) and Bidimac (⌘ = 0.4) with a simple AASG.

the one from Bidimac. The security analyst reviews just 2 sequences with Morwilog, while using Bidimac she checks 3.

To compare the resulting AASGs, we need to calculate the choosing probability for the two branches. If we focus on Case A in Morwilog, P 0,1 = 1902 2094 = 0.91 and P 0,2 = 192 2094 = 0.09. Note that this does not correspond at all to the probabilities found using Bidimac, where the equality P n,m = ✓ n,m is preserved.

Statistical meaning of weights

The choice mechanism in Morwilog does not allow finding a direct correspondence between the probability of occurrence of one attack sequence and the level of pheromones. The level of pheromones indicates the probability of choosing one arc against the others when events matching several children nodes are found, based on the previous history of events. But this history is not deterministically built from the observed data. There is a random factor in the increment or decrement of pheromones coming from the choice made in each one of the nodes.

Apart from this randomness, another reason why the level of pheromones does not directly correspond to the statistics of the events is given by the evaporation. We have seen in section 6.1.3 that the mechanism of pheromone evaporation avoids the stagnation of the choice in one branch of the AASG. The consequence is a reduction in the number of pheromones. This reduction is not linked to the statistical distribution of the incoming events, as it is done in every arc and not just in those connecting the matched nodes.

Due to this two factors, the level of pheromones is not a direct translation from statistical evidence, even if an intuition about which is the most probable path representing a multi-step attack can still be grasped from the pheromones. Pheromones are conceived as a resource for Morwilog, not as a numerical result, independently that they give valid information about correct multi-step attack cases among the ones proposed in the AASG. On the contrary, the probability parameters used in Bidimac directly code the probability of a sequence to be an attack, as there is neither a phase of random choice of paths nor of evaporation.

Going back to Figure 6.9, presented in section 6.3.1, the stigmergic AASG in Case A and Case B has in the last phase different choosing probabilities: P 0,1 = 0.91 and P 0,2 = 0.09 for Case A, and P 0,1 = 1460 2007 = 0.73 and P 0,2 = 547 2007 = 0.27 for Case B. Being the input dataset identical in both cases, this difference is due to the random choice and the evaporation mechanism. In contrast to Bidimac, choosing probabilities do not necessarily correspond to the statistical distribution of the dataset.

Mechanism to penalize or reinforce paths

The idea behind both Morwilog and Bidimac is to reinforce the branches in the AASG representing multi-step attacks, thus confirming the hypotheses, and to penalize the branches not corresponding to attacks, thus refusing false positives. However, the way of doing so is very different: in Morwilog, the increment or decrement is made by an arbitrary function while in Bidimac, the change of probabilities always follows the statistics of the events.

In other words, when using Bidimac, the increment of probability corresponds to an increment in the number of sequences representing an attack. This entails a linear change in the probability parameters, always controlled by the learning rate ⌘. However, the evolution of pheromones in Morwilog can be implemented using any function. In our case, we have chosen a Gaussian function (see equations 6.5 and 6.6) to get a higher initial change in pheromones than in the linear formula used in classic ACO, but we could have chosen any kind of function. This gives freedom to set the maximum attainable value for the choosing probability at any level.

To compare the evolution of the choosing probabilities both under Morwilog and Bidimac, we consider the scenario of continuous reinforcement introduced in section 6.1.3, page 144. The AASG chosen is the simple one presented in Figure 6.9 but right after the initialization, with ⌧ 0,1 = ⌧ 0,2 = ⌧ 0 = 1000 for the stigmergic AASG and ✓ 0,1 = ✓ 0,2 = 0.5 for the Bayesian AASG. To set a continuous reinforcement, we imagine that the incoming data contains instances of { 0 ,  1 } confirmed as attacks but no instances of { 0 ,  2 }. This situation is represented in Figure 6.10. Table 6.3 contains the evolution of the elements in the continuous reinforcement scenario: the pheromones and the choosing probability P 0,1 for Morwilog, and the probability parameters for Bidimac. Morwilog takes the parameters from Table 6.1. Bidimac is executed with ⌘ = 0.4 and ⌘ = 0.6. The choosing probabilities are represented in the graph of Figure 6.11 (remember that ✓ 0,1 = P 0,1 ).

We can observe that in Bidimac, the continuous reinforcement scenario brings a convergence of P 0,1 to 1 whose speed depends on the value of ⌘. On the contrary, in the case of Morwilog, a maximum and a minimum level of pheromones are eventually reached. In this case, the upper limit is 3051 pheromones (see page 144) and the minimum level is defined by ⌧ min = 100. When doing continuous reinforcement, we have a maximum choosing probability P 0,1 = 3051 3151 = 0.97 when no further pheromones 1000 1000

 0  1  2 1480 980  0  1  2 1902 960  0  1  2 Morwilog execution 0.5 0.5  0  1  2 0.7 0.3  0  1  2 0.82 0.18  0  1  2

Bayesian execution

Unlimited phases with { 0 ,  1 } ! attack ... ... 6.3).

are accumulated in the arc  0  1 and the evaporation brings ⌧ 0,2 to ⌧ min = 100. This probability is high enough to be comparable to 1, but Morwilog takes a lot of iterations to get to this value. In Table 6.3, we see that in 10 iterations the maximum level reached is P 0,1 = 0.78. This fast convergence seems an advantage of Bidimac with respect to Morwilog. The sooner a branch gets a high choosing probability, the sooner we can confirm it as a correct hypothesis. However, there is a subtle reason to not want a too fast convergence in this scenario: no sequence of events matching { 0 ,  2 } has been found. What if this sequence is just rarer but it also represents the attack? Morwilog is able to distinguish between not found sequences and found ones that are not evaluated as attacks after verification, as we explain in the following subsection.

Decrement of choosing probability

In Morwilog, not found sequences and found sequences that are not attacks are not evaluated in the same way. For the branches corresponding to the first ones, evaporation guarantees a slow diminution in the choosing probability. On the contrary, for found sequences that are not attacks, the mechanism of pheromone decrement (Equation 6.6) makes the choosing probability of the matched branches to rapidly decrease.

The existence of these two separated mechanisms in Morwilog is necessary because of the decision process performed by the morwis. Pheromone-based elections are made when several sequences starting with the same event match different branches in the AASG. Paths involving not found sequences have to be kept with a level of pheromones high enough to allow its selection in case of the eventual appearance of events corresponding to these paths.

On the other hand, when applying Bidimac, the decrement of the choosing probability is made only responding to the statistics of found sequences that are evaluated as attacks. There is no additional mechanism to penalize false positives. The possibility of implementing a mechanism of this sort should be discarded if we want to preserve the correspondence of the probability parameters to the statistics of the sequences represented in the AASG.

Summary

This chapter has been devoted to present Morwilog and Bidimac, the algorithms we propose to exploit the AASG. They perform the identification of the correct multi-step attack case among the alternative ones proposed by the security analyst. At the same time, both are able to perform detection of matched cases, returning alarms to the analyst.

We have first presented Morwilog, that is based on the behavior of foraging ants. After presenting Ant Colony Optimization in section 6.1.1 and a general overview of the algorithm in section 6.1.2, we have explained in section 6.1.3 how an adapted AASG becomes the stigmergic scenario where the artificial ants, called morwis, build their trails. The Morwilog algorithm is presented in detail in section 6.1.4. For the presentation of Bidimac, we have first devoted section 6.2.1 to explain Bayesian inference, on which the algorithm is based. In section 6.2.2, the parallelism between 6.4. Summary 167 Morwilog and Bayesian inference has been analyzed. The Bidimac algorithm itself has been then explained in section 6.2.3. Once the two algorithms have been explained, they have been compared to understand their differences: the choice among options (section 6.3.1), the statistical meaning of weights (6.3.2), the mechanism to penalize or reinforce paths (6.3.3) and the decrement of choosing probability (6.3.4). In the next chapter, we will proceed to evaluate Morwilog and Bidimac with examples of AASGs. We have seen how an analyst can capture her hypotheses about multi-step attacks in an AASG, which can later be used to perform detection and identification of correct cases using Morwilog and Bidimac. In this chapter, we perform a set of experiments to evaluate both the AASGs and the algorithms. All the experiments are carried out on an Intel Core i5 machine running at 1.4 GHz with 8 GB RAM. The parameters used in Morwilog take the values listed in Table 6.1, page 139, unless stated otherwise. The exception is T max , whose value depends on the dataset used in each occasion. In the same way, the learning rate in Bidimac takes the value ⌘ = 0.4 by default.

This chapter starts with the presentation of the datasets used for the experiments in section 7.1. Then, evaluation is divided into two parts. In the first one, addressed in section 7.2, some examples of AASG are proposed and evaluated in different datasets using Morwilog and Bidimac. The second part, presented in section 7.3, is focused on the evaluation of different aspects of these algorithms.

Introducing the evaluation datasets

Several datasets have been used in the evaluation of AASGs and the algorithms working with them. In this section, we introduce these datasets, their composition and the way they need to be preprocessed to be used for the proposed evaluations: DARPA 2000 Intrusion Detection Scenario Specific Data Sets, abbreviated as DARPA 2000 (section 7.1.1); ISCX 2012 Intrusion Detection Evaluation Data Set, abbreviated as ISCX (7.1.2), and the one generated within the HuMa project, called the HuMa dataset (7.1.3). The first two are publicly available, but the HuMa dataset is private and cannot be disclosed due to restrictions on the project. We then present in section 7.1.4 the common format into which we parse the events coming from the three datasets. Finally, a new set of simulated datasets, the eventgen datasets, is presented in section 7.1.5. It is created to compensate for the lack of multiplicity of multi-step attacks in the existent datasets.

DARPA 2000 datasets

DARPA 2000 is actually composed of two datasets, one containing the attack LLDoS 1.0 and the other, the LLDoS 2.0.2 (see section 3.2.2, page 31). They were created by the MIT Lincoln Laboratory [MIT Lincoln Laboratory 2018] between March and April 2000 [Shittu 2016] to respond to the interest shown by the scientific community in the evaluation of techniques for complex attack detection [START_REF] Valeur | [END_REF]].

We saw in section 4.4, page 94, that most of the publications about multi-step attack detection use public datasets in the evaluation of the methods. This represents 110 publications, out of which 89 use DARPA 2000. It is then the most used public dataset containing multi-step attacks. Even if it has received some critics about not being very representative [START_REF] Valeur | [END_REF]], the attacks LLDoS 1.0 and LLDoS 2.0.2 are well known and contain a sufficient number of steps [START_REF] Wang | [END_REF]].

The attacks in DARPA 2000 are performed in a simulated network with several Linux and Solaris machines. Each dataset is composed of two tcpdump files. The information in the first one, called 'inside', comes from a sniffer located in the inner part of the network, where the attacked machines Mill, Locke and Pascal are located. The second one, called 'dmz', contains information coming from the DMZ, where public servers are connected. This is complemented by the Solaris BSM audit data coming from Pascal.

The audit data from the Pascal machine is only used by two of the reviewed methods [START_REF] Anming | [END_REF], Wang 2018]. The rest of the methods work only with a set of alerts generated by an IDS from the packets in DARPA 2000. Some of them use Snort IDS [START_REF][END_REF], Yan 2005[START_REF] Lee | [END_REF], Alserhani 2010[START_REF] Xuewei | An approach of discovering causal knowledge for alert correlating based on data mining[END_REF], Wang 2016, Shittu 2016[START_REF] Holgado | [END_REF]; some others, RealSecure [Ning 2004a, Zhu 2006[START_REF] Yu | [END_REF][START_REF] Liu | [END_REF][START_REF] Farhadi | [END_REF][START_REF] Anbarestani | [END_REF][START_REF] Kavousi | [END_REF][START_REF] Ramaki | [END_REF], and a few, Bro IDS [START_REF][END_REF], Saad 2014]. We have chosen RealSecure for our evaluation because the resulting alerts have the same name independently of the IDS software version, something that does not happen with Snort. Moreover, some authors [START_REF] Zali | [END_REF], Ramaki 2015a] consider the alerts generated by RealSecure as more accurate and less redundant. Ning et al. [Ning 2002a] already provide an output of RealSecure alerts from DARPA 2000 that is used by some of the cited authors [START_REF] Zhou | [END_REF][START_REF] Sadoddin | [END_REF][START_REF] Hossein | Alert correlation using correlation probability estimation and time windows[END_REF][START_REF] Anbarestani | [END_REF]. We also use this data in our evaluation. It is divided in four files: 'inside1' and 'dmz1' for LLDoS 1.0, and 'inside2' and 'dmz2' for LLDoS 2.0.2. Alerts in these files have a timestamp associated to the moment when the RealSecure IDS processed the original tcpdump files, so the reader should not be surprised if the time does not correspond to the moment when DARPA 2000 was created. Conversely, the period of 'inside' alerts and the one of 'dmz' alerts is not the same because files had to be processed sequentially. A simultaneous analysis of the alerts coming from the two subnetworks is then incoherent in terms of time. In consequence, we just keep the files 'inside1' and 'inside2', where all the steps of the attacks are represented.

As the RealSecure IDS drops ICMP packets, there are no alerts corresponding to the first step of both attacks [START_REF] Ramaki | [END_REF]]. The rest of the RealSecure alerts mentioned in this thesis are shown in Table 7.1. The description of each alert and its level of risk have been extracted from the version 6.5 of the RealSecure Signatures Reference Guide [Internet Security Systems 2001].

ISCX dataset

The lack of public datasets to evaluate detection methods motivated the ISCX team at the University of New Brunswick (UNB) to create a systematic approach for the generation of evaluation data in 2011 [Shiravi 2012]. The ISCX 2012 Intrusion Detection Evaluation Data Set and the CICIDS2017 dataset have been generated thanks to this approach. Both datasets contain several types of attack mixed with simulated normal traffic. Even if the second one is more recent, the multi-step attacks it contains have a limited number of steps and they have not been extensively described. However, the 2012 dataset contains an interesting multi-step attack with 7 steps, which has been used by some published multi-step attack detection methods [Saad 2014, Zargar 2014[START_REF] Ramaki | [END_REF], Faraji Daneshgar 2016].

This island-hopping multi-step attack described in section 3.2.3, page 33, is contained in the third day of the seven days of network activity captured by the dataset. This period goes from Friday 6th to Thursday 17th November 2010. The network activity from the rest of the days contains other types of attack that are not multi-step.

We need to process the network activity in the dataset by an IDS if we want to work with events, as we explained for DARPA 2000 in the previous section. This time, we have done this process in our lab using Snort IDS, because a public set of previously generated alerts has not been found. In this case, it does not make sense to use RealSecure IDS, a product that is not used since the beginning of 2000's, way before the ISCX dataset was created.

The same as it happens in DARPA 2000, the timestamps of the resultant alerts correspond to the moment when they were generated, in June 2017, and not with the date shown in the original network packets. 57 different Snort alert types have been generated. They are listed in Table 7.2, together with the number of alerts of each type.

HuMa dataset

To test and improve the methods developed under the HuMa project, a dataset of logs containing the traces of a multi-step attack (see section 3.2.4, page 34), among other single-step attacks, has been furnished by one of the industrial partners. The dataset has been created using a virtual environment which replicates the infrastructure of a typical business network. The logs generated in the network assets during the execution of the attacks have been brought together to conform the dataset. This dataset is really big in number of lines, demonstrating that many filters and automatic processes are needed to deal with the massive amount of logs generated by unit of time in an average size company. It has a size of 2,844,691 lines, once it is cleaned from events that do not contain enough information to be processed. The data correspond to a period of five days, from a Monday to a Friday.

Logs are coming from different origins, that are listed in Table 7.3. To preserve the confidentiality of the test environment, we have been told not to reveal any of the involved IP addresses.

Normalization of events

Events contained in the presented datasets need to be adapted to a common format if we want to easily define AASGs and to work with Morwilog and Bidimac. This transformation process is called normalization (see section 2.3, page 19), and it is usually done in every event-based security system in the industry, to compare events coming from different sources and with different formats.

We have defined a list of 13 fields in the normalized format. They are listed and described in Table 7.4. For DARPA 2000 and ISCX datasets we have just developed a parser that maps attributes in the IDS alerts to the correspondent equivalents in the proposed format. It is straightforward to do it because all the events come from the same device. However, adapting HuMa requires more work due to the heterogeneous origins of the events in the dataset. Special parsers have been developed for each one of the devices listed in Table 7.3, trying to keep the equivalence in the meaning of the attributes between all the devices. Another purpose of normalization is to order the Table 7.4: Fields used in parsed events.

events in time, guaranteeing that each log has a timestamp equal or higher than the previous ones.

When evaluating Morwilog and Bidimac, we need to know where the multi-step attacks are, so we can simulate the feedback provided by the analyst after verification of the generated alarms. To do that, we include in the normalized format the field tag, where a number indicates if the event belongs to a multi-step attack, and to which one of them in case that there are several ones. None of the used datasets are labelled, so one of our tasks has been the manual identification of the attacks in each dataset and the assignation of the tags.

To summarize the information about the datasets, we present in Table 7.9 a comparison of them in terms of number of events, number of aggregated events (see section 7.2.3, page 187), duration of the actions represented in the dataset and duration of the multi-step attack contained in it.

The eventgen datasets

The datasets mentioned so far have the big limitation of only containing a single instance of a multi-step attack. We have then created a new set of simulated datasets using Splunk Event Generator1 , a software developed to create artificial events to Table 7.5: Summary of the datasets used in evaluation.

test Splunk, a commercial SIEM. The generation of events has been configured to be adapted to our needs in each experiment. More than creating a realistic dataset, our goal is to produce sequences of events that can be confounded among background data.

The exact composition of an attack does not matter, the important thing is that we are able to identify it as a different sequence. Table 7.6: Parameters in the creation of the eventgen datasets.

When generating the dataset, each new event has one out of three origins randomly assigned according to a probability distribution: firewall ('FW'), web server ('WS') and mail server ('MS'). Once the attribute origin has been selected among these three values, the values for service, type and action are also randomly selected, with the possible values depending on the origin. The result is a total of 1038 different kinds of event, considering the combination of the fields origin, service, type and action.

Source IP addresses are also randomly chosen, with a 95% of chance of picking up one that has already been used in another event. Timestamps are generated by a counter, with intervals of increment that are also random.

Once the events have been created, a set of event sequences with the source IP address as the overarching element are injected in the dataset. Some of them are labelled as attacks and some of them are not. The distance between the events in the sequences is also random, with a maximum distance given in number of events by the parameter seq_step. The proportion of events that represents an attack is one of the parameters in the generation of events, called prop_attack. All the parameters are listed in Table 7.6.

The datasets created using this method are called the eventgen datasets. They are used in the evaluation of the algorithms in section 7.3.

Evaluation of different AASGs

In this section we propose several use cases of different AASGs. They have been built following the logic of a security analyst. The application to each dataset is done through Morwilog and Bidimac algorithms. Therefore, the algorithms and the utility of the designed AASGs are evaluated in parallel, although a specific evaluation of the algorithms is presented in section 7.3.

We assume so far that the security analyst is infallible when evaluating the raised alarms. Her behavior is simulated within the execution of the algorithms, thanks to the tags assigned to the attacks contained in each dataset (see Table 7.4). If the sequence of logs that triggers the alarm is marked as an attack, the alarm is considered as true. We also suppose that the evaluation of the analyst takes place immediately after the alarm is raised. The values used for T max depend on the dataset and are shown in Table 7.7. Table 7.7: Values of T max for evaluation.

DARPA 2000 LLDoS 1.0

The first AASG we evaluate is Mill-1, the one represented in Figure 5.8 (page 128), which was built from the excerpt of DARPA 2000 shown in Table 5.2. To remind the structure of Mill-1, we show it again in Figure 7.1, but expressed differently than in Figure 5.8. Instead of basing the representation on the numbering of functions defining each condition, we use the JSON members defined in section 5.4.1 for AASG implementation. Even if this representation does not exactly correspond to the formal definition of an AASG, it is more intuitive when working with real AASG and it has the same elements as the one used in the graph editor presented in section 5.4.3. This new form is called functional representation, while the one in Figure 5.8 is the formal representation. In the functional representation, conditions are expressed as boxes with the members arranged in order: the name of the function is followed by the name of the attribute and the reference value, in case of being absolute, or the names of the attribute of the parent and children nodes, in case of being relative. If there is a counter associated to the node or it is an optional node, this is also indicated next to the name of the node. Remember that the attack from which Mill-1 is built corresponds to a part of the LLDoS 1.0 attack (see section 3.2.2), more precisely to the infection of the Mill server. In LLDoS 1.0, the attacker infects two other machines, Locke and Pascal. The three infections are similar and separately correspond to the steps 1 to 4 of the attack. We have thus three different occurrences of the scenario represented in the AASG, which are multi-step attacks by themselves, even if in absolute terms the dataset only contains one multi-step attack.

We want to see if the infections of Locke and Pascal are detected using the AASG Mill-1. First, we remove the 37 IDS alerts corresponding to the infection of Mill from the dataset inside1. This results in a new dataset, called inside1-NoMill. Then, we execute Morwilog and Bidimac. In both cases, the two infections raise alarms, which means that the AASG Mill-1 is valid for the detection of the attacks against Locke and Pascal. But not all the branches match the involved alerts as they would do when facing an exact repetition of the infection of Mill. This reflects the fact that some of the cases proposed by the analyst were valid for that infection but not for the other ones. The branches matched by Locke and Pascal2 are actually the same ones in both cases: [0, 1, 3, 5, 8], [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3,5,9], [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3,6,8] and [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3,6,9].

The analysis of the results returned by Bidimac is the best way to determine how many branches are matched by each attack, because this method looks for matches against every single branch in the AASG, raising an alarm for each match. As every branch corresponding to a sequence in the data raises an alarm, the generated alarms are a direct representation of the statistics of the dataset in terms of the cases proposed by the analyst. Conversely, morwis in Morwilog explore only one branch of the AASG for each event matching  0 . There is then a difference in the number of generated alarms, up to 8 alarms for Bidimac and just 2 for Morwilog.

Apart from counting the number of alarms, it is interesting to check when they are generated. A plot of the number of alarms versus the number of each log in the dataset is presented in Figure 7.2. This 'log number' is just the position of each log in the list of logs conforming the dataset. Each log has thus a different number and, because they are ordered in time, it is guaranteed that if a log number b is bigger than another one a, the timestamp of the event numbered a is equal or inferior than that of the one numbered b.

The reason of using the log number and not the timestamp in the figures is to avoid that two different logs with the same timestamp can lay in the same x coordinate, making visualization of results more difficult. Anyways, the timestamp of each coordinate is indicated below the log number in the subsequent figures, as a reference. Figure 7.2 covers the whole period where the infections take place, but in subsequent plots representing the number of alerts in DARPA 2000, only the period when the alarms are launched will be covered.

The researchers that have previously worked with DARPA 2000 are probably surprised about not using the alert ID as the number to identify each log in the figures. The reason is that an order based on alert ID does not correspond at all with an order based on the time of the event. We will see it clearly in Figure 7.10, where we do use the alert ID because we are not interested in show the distance between the logs like in Figure 7.2.

To have an overview of the possible branches matched for this dataset, all the Bidimac matches are represented in Figure 7.3, in diagrams where the matched nodes are placed in the vertical axis and the log number is represented in the horizontal axis. The red node at the end of each branch indicates the moment when the alarm is risen.

In the case of Morwilog, only two of the represented patterns raise alarms. We see three of these patterns in Figure 7.4. Paths for both infections, Locke and Pascal, are separated to ease visualization because they happen almost simultaneously. The path to nodes that have not been chosen by the morwi but have been matched is represented by a dashed line. The moment of launching the two alarms is indicated with a red bar. They are always launched in position 467 (time 5:33:18) because it is the moment when the search of children of node  0 finishes due to the limit established by T max . If we look closely to the figure, the node  2 has never been found, so when the morwi arrives at the last node in the AASG ( 8 or  9 , depending on the decision made) and the alarm is launched, logs before the one in position 467 have already arrived at the system. This translates into a late pheromone update, after the two infections are detected.

As both attacks are detected when the stigmergic AASG Mill-1 has just been initialized, thus having all the arcs the same level of pheromones, the decisions of the morwi are uniformly random. When running the execution, a high number of

 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9
 0  1  2  3  4  5  6  7  8  9
 0  1  2  3  4  5  6  7  8  9

Nodes

Log number

Locke Pascal times, we should see that any branch is equally chosen. This is shown in Figure 7.5, where we represent the number of times each branch is matched for each one of the infections after 5000 executions. The small differences in the number of branches is due to randomness, but it is easy to infer that an infinite number of executions would end up with the same number of occurrences for each branch.

1 2 3 4 5 6 7 8 9 Alarms 1, 2 0 1 2 3 4 5 6 7 8 9 Alarms 1, 2 0 1 2 3 4 5 6 7 8
As a conclusion of this section, the advantage of Morwilog over Bidimac in terms of number of alarms is clear. It could be argued that with Morwilog we do not know every possible branch that could be matched by the sequences of alerts, but at the same time the work for processing the alarms and providing feedback is less. Think that when building an AASG from a sample of a multi-step attack it is normal that several of the proposed cases are correct, because they are based on solid ground and developed by a security expert. But the goal is not to match all the occurrences but a) to launch an alarm when any of the branches is matched so we can detect the new instance of the attack and b) to develop a detection model with the essential elements of the attack or the most repeated ones. We look for a case that could be always valid for detection, independently that other cases can be equally valid. Many alarms would be risen at any repetition of the multi-step attack if we execute Bidimac on an AASG with many correct hypotheses.

7.2.2

From LLDoS 1.0 to LLDoS 2.0.2

Imagine that the analyst wants to create an AASG more general than Mill-1 to detect and identify a broader range of similar attacks. The following modifications to Mill-1 could be done to create Mill-2, a different AASG:

1. Suppression of node matching the 'SadmindPing' alert ( 0 ). The 'Sad-mindPing' alert represents a reconnaissance stage in which the machines are probed to check if they have the sadmind service running. This stage could be done weeks before the infections take place, resulting in a partial match of the AASG Mill-1. The new AASG Mill-2 now matches alerts of the type 'Sad-mind_Amslverify_Overflow' in node  0 .

2. Consideration of another protocol different than rsh to send the malware, such as FTP (nodes  5 and  6 ). 3. Suppression of optional node  7 . As 'TelnetTerminaltype' is such a common alert in our network and the analyst was not sure about its presence in the attack when she created Mill-1, the node  7 can be erased to simplify the AASG.

 0  5  6  8  9 Node Abstract event List of conditions  0 e ⇤ 0 g 1 (typea, 'Sadmind_AO') = 1  5 e ⇤ 5 g 4 (typea, {'Rsh', 'FTP_Put'}) = 1, f 1 (ipdsta, ipdstp) = 1  6 e ⇤ 6 g 1 (typea, {'Rsh', 'FTP_Put'}) = 1, f 1 (ipsrca, ipdstp) = 1  8 e ⇤ 8 g 1 (typea, 'Mstream_Zombie') = 1, f 6 (ipdsta, ipdstp) = 1  9 e ⇤ 9 g 1 (typea, 'Mstream_Zombie') = 1 f 2 ({ipsrca}, {ipsrcp, ipdstp}) = 1 g 1 (ipdsta,
This results in a new AASG Mill-2 whose formal representation is shown in Figure 7.6 and its functional one in Figure 7.7. The numbers assigned to each node have been kept to ease the comparison with Mill-1.

Reducing the number of steps and conditions associated to the AASG results in a more general AASG, but the cost to pay is an increase in the number of alarms for both algorithms: 8 alarms in Morwilog and 32 in Bidimac. The diagram in Figure 7.8 shows the evolution in the number of alarms in terms of the log number. Notice that for Morwilog we have two cases: one in which the first four alarms are triggered at log number 451 and the second four alarms at 574, and another one in which all of them are triggered at 451. This just depends on the randomness of the path followed by the morwis.

More details about which are the matched paths are shown in Figure 7.10 for Bidimac and in Figure 7.11 for Morwilog. In both images, we can see which is the alert ID of the events matching each one of the branches in the AASG. In this case, the distance between the events in the plot is not proportional to the distance between the corresponding events in term of log number, as it happens in Figure 7.8. Anyways, the time when each event occurs is indicated underneath. This helps the visualization of the branches, as some events matching subsequent nodes are very close in terms of log number. In both figures, we can see how the order of the alert IDs does not correspond to the temporal order of the events, as we pointed out in page 180. For example, event with alert ID 67442 precedes in time the one with alert ID 67438.

In the case of Bidimac (Figure 7.10), the sequences are superimposed to the plot of the number of triggered alarms. Again, alarms in Bidimac are always generated at the last matched node in the sequence. We see that the effect of having 32 alarms is a consequence of having 4 branches that always match with the attacks Locke and Pascal, with eight events matching  0 and starting the sequence: the ones with alert IDs 67430, 67428, 67442, 67438, 67440, 67436, 67432 and 67434.

Conversely, only one branch is chosen in Morwilog for each time event matching  0 . We have represented the possibilities that each generated morwi has for choosing in Figure 7.11. If we compare with Figure 7.10, we can see that the matched branches are the same and the only cause determining a lower number of alarms in Morwilog is the random pheromone-based choice.

The interesting thing about the AASG Mill-2 is that it is also able to detect the attack LLDoS 2.0.2. The number of alarms triggered by the application of Mill-2 on the dataset inside2 is shown in Figure 7.12. Both Morwilog and Bidimac trigger two alarms, but at different moments. The branch matched this time is only one for both alarms: [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]5,8]. It is possible then to create an AASG that is able to detect two similar but not identical attacks. It depends on the generalization of the conditions expressed in each one of the cases represented in the branches.

Introducing an aggregation phase

The repetition of alarms representing the same matched branches in Figures 7.10 and 7.11 may be a result of the duplication of events in the dataset.

Rules for the generation of logs are not necessarily too complex. Their simplicity can easily lead to duplicated or very similar logs representing the same event. For example, imagine a rule in an IDS that creates a 'SSH Brute-force' event each time it detects five failed SSH login requests. A real SSH brute-force attack where the attacker makes fifty failed attempts before getting in the system will result in ten consecutive alerts with a variation in the timestamp at most.

Many authors [Alserhani 2013[START_REF] Ramaki | [END_REF], Zhang 2017, Saikia 2018] apply a prefiltering to the dataset to avoid redundancies. The process of merging several events meaning the same into one event is called aggregation. To transform the datasets, we have designed an aggregation process inspired by the Rule 1 in the ONTIDS system [Zargar 2014]. This process considers that two events are the same if they share ipsrc, ipdst and type, and the difference between timestamps (attribute time) is less than 60 seconds. To keep it simple, only the first log in the aggregated set is preserved. The results of applying Morwilog and Bidimac using the AASG Mill-2 in inside1-NoMill after it has been processed by the aggregation algorithm are shown in Figure 7.9. To easily compare with the results before aggregation, Figure 7.9 is placed next to Figure 7.8 and the original log numbers are preserved. The number of alarms after aggregation is considerably lower: 8 alarms in Bidimac and just 2 in Morwilog. However, the moments when the alarms are triggered are still the same.

This experiment shows how filtering the input events is important to avoid the generation of duplicated alarms. Notice that the number of alarms has been divided by 4 using a simple aggregation algorithm. When implementing a detection algorithm in a real network, it is expected to have even more complex and adapted algorithms for event aggregation. The aggregation algorithm has been applied to all the datasets we use in the evaluation. The resulting number of logs is shown in the fourth column of Table 7.9 in page 192. The reduction of logs is impressive in HuMa, where just around 5% of the logs are preserved.

AASG with scan and double attack

Hypotheses about multi-step attacks represented in an AASG do not forcibly need to be related to a single attack process. The analyst may be interested in a succession of alternative attacks. She could make of the AASG a tool for detecting any of these alternatives and for identifying the most probable one. For example, if she knows that a port scan could be followed by the exploit of two different vulnerabilities, both could be coded in separate nodes that would be children of the node representing the scan.

Taking this point of view, we have developed an AASG representing a scan followed by two consecutive attacks in which the attacker changes her IP address. This AASG is called 'Scan and double Attack' (S2A). Its formal representation is shown in Figure 7.13 and its functional one, in Figure 7.14. The represented multi-step attack is composed of the following steps:

1. Beginning of the scan. The node  0 represents the initial identification of an ICMP message sent to an internal IP address. To identify the target as an internal host, we use the prefix similarity function g 3 to check if the destination IP address (ipdst) belongs to a subnetwork of private addresses of the form '192.168.0.0'. A threshold = 0.45 is used, slightly lower than the one corresponding to a network mask /16 (threshold = 0.5). To avoid false positives, we do not consider events coming from the internal servers. For doing that, the inequality function g 2 is used, in this case with 192.168.5.122 and 192.168.5.123, which correspond to the IP addresses of two servers in the ISCX dataset.

2. Continuation of the scan. The next nodes of the AASG represent two alternative ways to perform the scan: on IP addresses (node  1 ) and on services (node  2 ). Both nodes have an associated counter of 20, which means that 20 events matching the node are expected to be found. It is the minimum number of events from which we consider a scan occurs. On the one hand, events considered by  1 as being part of an IP address scan have a destination IP address that is different than the previous event (f neq (ipdst a , ipdst b ) = 1) but belongs to the same class C subnetwork (f ⇤ 3 (ipdst a , ipdst b , 0.75) = 1). On the other hand, in the service scan represented in  2 , the destination IP address is the same (f 1 (ipdst a , ipdst b ) = 1) but it is the service that changes (f neq (service a , service b ) = 1).

 0  1  2  3  5  4  6  8  7 Node Abstract event List of conditions
 1 e ⇤ 1 f 1 (typea, type b ) = 1, f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, fneq(ipdsta, ipdst b ) = 1  2 e ⇤ 2 f 1 (typea, type b ) = 1, f 1 (actiona, action b ) = 1, f 1 (ipsrca, ipsrc b ) = 1, f 1 (ipdsta, ipdst b ) = 1, f 1 (psrca, psrc b ) = 1, fneq(servicea, service b ) = 1  3 e ⇤ 3 f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'SQL', 0.1) = 1  4 e ⇤ 4 f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'failure SSH', 0.5) = 1  5 e ⇤ 5 f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'EXPLOIT Attempt', 0.1) = 1  6 e ⇤ 6 fneq(ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'SQL', 0.1) = 1  7 e ⇤ 7 fneq(ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'failure SSH', 0.5) = 1  8 e ⇤ 8 fneq(ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'EXPLOIT Attempt', 0.1) = 1
3. First attack. A first attack launched from the same IP address that launched the scan (f 1 (ipsrc a , ipsrc b ) = 1) is represented in the nodes  3 ,  4 and  5 . The kind of attack is identified by textual similarity (g 4 ) with a string naming it. Three kinds are considered: SQL injection, identified by 'SQL' in  3 ; SSH bruteforce, identified by 'failure SSH' repeated 20 times in  4 , and an exploit execution, identified by 'EXPLOIT Attempt' in  5 .

4. Second attack. This step consists on a second attack of any of the three kinds proposed in the previous step but launched from a different IP address (f neq (ipsrc a , ipsrc b ) = 1).

This AASG S2A fully represents the HuMa attack described in section 3.2.4, but also the three last steps of the ISCX island-hopping attack presented in section 3.2.3. In terms of evaluation, it does not make sense to create an AASG fully representing the ISCX island-hopping attack because in the ISCX dataset there are only alerts corresponding to the three last steps. This is one of the problems of this dataset, together with the fact that it contains only one multi-step attack.

The AASG S2A has been successfully tested both in ISCX and HuMa datasets in their aggregated version. The results are shown in Table 7.8. Only one branch in the AASG is matched for each dataset, corresponding to the multi-step attack they contain. We see that the number of alarms returned by Bidimac is really high, despite of only existing one attack in each dataset. This is due to the high number of events involved in each attack and the repetition of actions within them (e.g. in the scans), partially maintained even after the aggregation process. In any case, the AASG S2A has demonstrated its versatility to find two attacks with similar structure but different content in two different datasets.

Evaluation of the algorithms

In the previous section, we have evaluated different examples of AASG on the prebuilt datasets presented in section 7.1. Now it is time to focus on the evaluation of the algorithms working with AASGs: Morwilog and Bidimac. In this case, the datasets used so far are no longer valid, because they have just one instance of each attack. We need several instances of them to see how the levels of pheromones and the probability parameters evolve. To solve this issue, we have created the eventgen datasets, presented in section 7.1.5. The evaluation of the algorithms starts with the analysis of their time performance in section 7.3.1. We continue studying how the choosing probability evolves with respect to the found attacks in section 7.3.2. The effects of varying the parameters of the algorithms are analyzed in section 7.3.3. Finally, the consequences of facing overlapped sequences of events representing an attack are addressed in section 7.3.4.

Time performance

To evaluate the time performance of the algorithms, we should check first the execution time of the evaluations done so far. The results are shown in Table 7.9. Each value of the execution time, expressed in seconds, is the resulting average from 10 executions. The exception is the HuMa dataset, whose execution time comes from a single execution.

The first observation about the results in Table 7.9 is that none of the executions takes a time longer than the period represented in each dataset. This constitutes a minimum requisite for applying Morwilog and Bidimac on real-time events. The computer used for the simulations, whose characteristics were indicated in page 169, is a working laptop with more than 4 years old. Times are thus expected to be much lower in a real implementation.

The execution times are in fact very low with respect to the period covered by the datasets, with the exception of the execution of Bidimac on HuMa. This execution took almost half of the time represented by the logs, probably because T max is long and most of the branches in the AASG S2A are not matched by any event after  0 is matched, so Bidimac keeps looking for matches until the limit established by T max is reached.

Otherwise, it is difficult to infer general conclusions about the execution time from the information given in the table: Bidimac is slower than Morwilog in some executions (e.g. inside1-NoMill with Mill-1 or ISCX), but both behave similarly in some others (e.g. inside1-NoMill with Mill-2 or inside2). This happens because there are many factors in play, such as the AASGs, the size of the dataset or the distribution of the attacks.

0  1  3  2  4  5  6
To be able to properly study the execution time, some eventgen datasets have been generated (see section 7.1.5). Each one of the generated datasets has only 1 type of multi-step attack of length 3 and maximum distance between the steps of 3 logs. The injections of the attack sequences in the dataset is calculated for resulting in around 0.5% of logs involved in an attack.

Respecting the AASG, a structure like the one shown in Figure 7.15 is generated, with the nodes in dark blue coding the events corresponding to the multi-step attack. The goal is just to check how the algorithms behave with a fixed structure of AASG being matched by the same attack. All the nodes in the AASG are related with their parents by the condition f 1 (ipsrc a , ipsrc b ) = 1, which means that the source IP address will be preserved for all the events in the matched sequences. We will be using this AASG, called AASG Eventgen, for the rest of the simulations in this chapter.

Under these conditions, the execution time has been evaluated for different sizes of the dataset and for different values of T max . The results are represented in Figure 7.16 and Figure 7.17, respectively. Each represented point represents the average result from 10 different executions. In Figure 7.16, T max = 20s. For both Morwilog and Bidimac, the execution time seems to be linearly proportional to the size of the dataset and the maximum search time T max . However, while the two algorithms seem equally affected by the size of the dataset, with a slight advantage for Bidimac, the increment of the parameter T max clearly affects Bidimac more than Morwilog. Figure 7.17: Execution time with respect to T max in an eventgen dataset with 16000 logs.

This difference is not linked to the matched branches but to the non-matched ones. In Bidimac there is not a choice of path like the one we found in Morwilog. Therefore, sequences of nodes that are not found heavily penalize the algorithm, as it continues the search until the end of the period determined by T max . This is the price to pay for being coherent with the statistics of the incoming events and trying to find all the possible hypotheses.

Evolution of the choosing probability

The levels of pheromones in a stigmergic AASG and the probability parameters in a Bayesian AASG are the elements that determine the importance of each path. We defined the choosing probability for both types of AASG in Equation 6.1 and Equation 6.13, respectively. To study the evolution of the strength of a branch over the others after the detection of several attacks, we define the choosing probability of one branch as:

P b = Y nm2 b P ( n  m ) (7.1)
As it is represented in Figure 7.15, the attacks in the eventgen datasets are matched by the branch [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] in the AASG Eventgen. We are interested in the choosing probability of this branch, denoted as P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] . Several eventgen datasets have been created to study the evolution of this probability. They have a size of 1000 logs and different number of 3-step multi-step attacks, determined by the eventgen parameter prop_attack (see Table 7.6, page 176). The algorithms are first tested in a scenario of continuous reinforcement, like the one that was used for the theoretical analysis of the evolution of pheromones presented in page 144. The results are represented in Figure 7.18 for both Morwilog and Bidimac, with T max = 20s. We see how P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] grows faster in Bidimac and gets almost equal to 1 after 16 attack sequences. On its side, P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] in Morwilog grows fast at the beginning but the growing rate gradually decreases as the number of attacks is incremented. This is the same behavior we could see in the theoretical analysis, whose results were presented in Figure 6.11. There, we just focused on the choosing probability of one arc, which in that case also corresponded to the choosing probability of the matched branch. Having a choosing probability in Morwilog that does not get up to the maximum of 1 avoids the morwi to get stagnated in the same path, even if it has been matched many times. Anyways, once the choosing probability is high enough, the analyst can consider that the hypothesis represented in this branch has been confirmed and she can retire this branch from the AASG.

Another aspect to study is the evolution of the choosing probability when found sequences are not confirmed as attacks. The results for a scenario of continuous penalization are represented in Figure 7.19. This scenario, where only false positive sequences matching branch [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] are found, is similar to the one proposed in page 145. We see how P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] does not vary at all in Bidimac. As we explained in section 6.3.4, the probability parameters in the Bayesian AASG are never affected by false positives, only by confirmed attacks. This is done to be coherent with the statistics of attack sequences.

Conversely, the decrement of pheromones in Morwilog leads to a big drop of P [0,1,3] right after a few false positive sequences have been found. However, the value of P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] starts then to slowly rise as more false positive sequences match the branch [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3]. This behavior is explained by the minimum level of pheromones ⌧ min and the evaporation mechanism. The levels of pheromones in the arcs of the branch [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] never goes below ⌧ min . Once this limit is reached, these levels of pheromones do not change, but the levels of pheromones of the rest of the arcs in the stigmergic AASG decrease due to the evaporation mechanism, resulting in an increase of P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] .

Values of parameters

The evolution of the choosing probability P b can be controlled thanks to some of the parameters of the algorithms. In Bidimac, the only parameter we have apart from T max is the learning rate ⌘. On the contrary, in Morwilog we have five parameters excluding T max , among which only the evaporation rate (⇢) and the spreading of the ⌧ +, function (w) actually affect P b . The rest (⌧ 0 , ⌧ + 0 and ⌧ min ) are just used as reference points to determine the range of values taken by the levels of pheromones.

The evolution of P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] in the AASG Eventgen with respect to the learning rate ⌘ is shown in Figure 7.20, after having detected 3 and 16 attack sequences in a set of eventgen datasets with 1000 logs. We see that ⌘ allows an ample variation of P [0,1,3] after 3 attacks have been found. However, after the detection of 16 attacks, P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] is equal to 1 for ⌘ > 2 and really high for the values below. This means that the possibility of personalizing the convergence speed of the choosing probability to a maximum value using ⌘ is just limited to the first few found attacks.

On the contrary, in Morwilog we have the exactly opposite situation: the variation of the parameters ⇢ and w has a bigger influence on P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] if more attack sequences are found. This can be seen in the three-dimensional graphs shown in Figures 7. 21, 7.22 and 7.23, which represent the P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] with respect to ⇢ and w for a set of eventgen datasets with 1000 logs and 3, 16 and 66 attacks, respectively. The amplitude of choice in the convergence of P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] is clear in the results from Figure 7.23, where even after 66 attacks we could regulate the parameters to get a P [START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] in a range from 0.4 to almost 1.

Overlapped attacks

The eventgen datasets used so far contain multi-step attacks whose steps are really close in time from each other, having no more than 3 logs between them. In this section, we want to analyze the behavior of Morwilog and Bidimac when the distance between the steps is higher and, in consequence, the attacks gets overlapped in time.

For doing so, we have generated five eventgen datasets of 1000 logs with 33 attacks (prop_attack = 10% and 3 steps per attack) and different maximum distances in number of logs (max_step) between the steps of the attacks: 10, 25, 50, 75 and 100, which result in a maximum distance in seconds of 16, 39, 65, 89 and 115, respectively. We have chosen T max = 120s for all the executions.

Two metrics are considered to evaluate the algorithms: the number of alarms corresponding to attacks (true positives or TP) and the numbers of alarms rejected by the analyst as false positives (FP). The addition of these two metrics is the total number of alarms. The results of the execution of Morwilog and Bidimac are represented in Figures 7.24a and 7.24b, respectively. There is only a single difference between the execution of the two algorithms: in the first dataset, with a maximum difference between the steps of 16 seconds, Morwilog misses one of the attacks. This is the consequence of a morwi taking one of the alternative branches in the AASG that ends up without generating any alarm. Regarding the false positive alarms, there is just one for both algorithms, in the third dataset. As the datasets are randomly generated, it can happen that the position of certain sequence of actions within the dataset can be at the origin of a false positive alarm in one of the executions and not in the other ones.

There is not a visible impact of the presence of overlapped attacks in these results. The reason is that our AASG is very well defined, with conditions of preservation of the source IP address in each of the branches. But we can try to remove this condition (f 1 (ipsrc a , ipsrc b ) = 1), so the relationship between the events matching the sequence is less rigid. This modification results in a new AASG called Eventgen-Noipsrc.

The results in terms of TP and FP on the same datasets are shown in Figure 7.25a for Morwilog and in Figure 7.25b for Bidimac. Now the effect of overlapped attacks is more clear, resulting in an increase of false positive alarms for both algorithms. Notice that, apart from some minor variation probably due to the random choices of the morwis, the results from Morwilog and Bidimac are equivalent.

These results suggest that detection mainly relies on the design of the AASG. The choice of the algorithm should then be made thinking on a) time performance with respect to the input data and the used T max , and b) number of alarms generated by the system.

Summary

This chapter has addressed the evaluation done on the AASGs and the algorithms conceived for working with them, Morwilog and Bidimac. We have started introducing the datasets used in this evaluation: DARPA 2000 (section 7.1.1), ISCX (7.1.2) and HuMa (7.1.3). The first two are the most popular public datasets containing multi-step attacks, while the third one is a private dataset developed under the HuMa project. To be treated by our algorithms, the events in these datasets have to be normalized to a common format, that has been introduced in section 7.1.4. As the mentioned datasets have only one multi-step attack each, we have developed a set of artificial datasets, called eventgen datasets, to evaluate the algorithms using several instance of the same multi-step attack. The details of these datasets have been presented in section 7.1.5.

Evaluation has been divided in two parts: the evaluation of the AASGs and the evaluation of the algorithms. The first part has started in section 7.2.1 with the evaluation of the AASG Mill-1 (see section 5.3) on the dataset DARPA 2000 inside1. We have then proposed in section 7.2.2 a new AASG, Mill-2, that works with both DARPA 2000 inside1 and inside2. A simple aggregation algorithm to reduce the number of logs in a dataset has been proposed in section 7.2.3 and applied to the three datasets used in this first part. After aggregation, the multi-step attacks contained in the ISCX and HuMa datasets have been found using the same AASG, called S2A, in both cases. This AASG and the results of its evaluation are shown in section 7.2.4.

For the second part of the evaluation, the evaluation of the algorithms, we have used the eventgen datasets. We have started by evaluating the time performance of both Morwilog and Bidimac in section 7.3.1. The following aspect to evaluate, in section 7.3.2, has been the evolution of the choosing probability in the scenarios of continuous reinforcement and continuous penalization. We have then evaluated in section 7.3.3 how this probability is affected by the choice of the parameters in the algorithms. Finally, we have studied the effect of overlapped attacks on the two systems in section 7.3.4.

In the next chapter, we will present the last of the contributions of this thesis: SimSC, a model for the visual investigation of attack scenarios. Up to this point, we have not paid much attention to the phase of investigation of past attacks, the one leading to the identification of the different multi-step attack cases that form an AASG. In this chapter, we propose a model for the investigation of attack scenarios based on the idea of similarity: SimSC (Similarity-based Scenario Creation). The difference with the methods reviewed in section 4.3.1 is that we have limited ourselves to work with raw logs, in plain text. This constraint limits the analysis to attributes that can be automatically extracted, but it allows working with heterogeneous sets of logs that have not been processed. Attack scenarios found using SimSC are intended to be used in the creation of AASGs, the same as the infection of Mill in LLDoS 1.0 was used to create the AASG Mill-1 (see section 5.3).

SimSC is directly linked to the contributions made by the other partners in the HuMa project, and conceived to work and be complemented by them. An introduction to HuMa reference architecture can be found in the work published in the proceedings of the 10th International Symposium on Foundations and Practice of Security (FPS) [START_REF] Navarro | [END_REF]] and presented by the author of this thesis in Nancy (France) in October 2017. Since then, methods proposed within HuMa have evolved and new ones have been developed. The work made by the industrial partners cannot be publicly disclosed, but new publications by the academic partners are expected. This chapter is divided as follows. We explain in section 8.1 how SimSC works for later presenting two working implementations of the model in section 8.2: as part of the HuMa project and on the medical information platform GenIDA. Finally, in section 8.3, Raw-SimSC, a version conceived to work with any dataset, is presented and it is tested with events from DARPA 2000.

SimSC

The format of logs is dependent on the system generating them. If we compare the Apache log shown in Figure 3.1 (page 26) and the log representing an IDS alert in Figure 8.1, we see how their aspect is completely different. These logs could even be related, as both represents a SQL Injection attack coming from the same IP address (192.168.2.112). SimSC offers a mechanism to link these two logs without the need for normalizing them into a common format. There exist two types of attribute that preserve their format and can be automatically found: IP addresses and timestamps. Both are present in almost every log contained in the studied datasets. They are the types of attribute used by SimSC. We could think of other types of attribute with a fixed format, such as MAC addresses, but they are not as common as the selected ones.

For the extraction of IP addresses, we identify their format as four numbers between 0 and 255 separated by points. From the log in Figure 3.1 we have the address 192.168.2.112, while for the one in Figure 8.1 we got the same one and also 192.168.5.122. If we automatically extract the IP addresses, we cannot make the distinction between which is the source and which is the destination, as we know nothing about the position of each attribute in the log. The result of this extraction is thus an unordered set of IP addresses.

Respecting the timestamp, several formats exist. We have built a set of regular expressions, shown in Table 8.1, to identify all the timestamp formats that we have found in the studied datasets. Once extracted, timestamps are converted into POSIX format to be easily compared. Again, it is possible to find several timestamps in a log, referring to different moments such as the occurrence of the event, the moment when the log was stocked in the file, etc. In SimSC, we need to attach each log to a single moment, so we need a unique timestamp. We have tested the automatic extraction of timestamps in the HuMa dataset, that has also been parsed (see section 7.1.4). The result is that for each raw log, the timestamp with the minimum value among the ones automatically extracted always corresponds to the one selected for the parsed log. Therefore, the minimum timestamp is the one used in SimSC.

For example, the extracted timestamps in Figure 3.1 and Figure 8.1 are, respectively, "06/Aug/2018:08:16:00", matching to regular expression 3a in Table 8.1, and "Aug 6 08:21:40", matching to 1b.

The output of SimSC is a graph that is built using the extracted IP addresses and timestamps. Each node in the graph represents a log. An edge between two logs is built depending on their difference in time and the IP addresses they have in common. The sets of IP addresses extracted from the two logs are called A ip and B ip . The minimum number of IP addresses in common to create an edge is determined by the parameter n ip . For any n ip 0, an edge is built if the difference in time is below a certain threshold T max and one of the following conditions is met: a)

A ip ✓ B ip , b) B ip ✓ A ip or c) |A \ B| n ip .

Implementations

The development of SimSC has led to two working implementations. The first implementation (section 8.2.1), HuMa-SimSC, is the one designed to work within the HuMa architecture [START_REF] Navarro | [END_REF] and it is at the origin of the conception of SimSC. The second one (section 8.2.2) has been developed by Timothée Mazzucotelli to work with web logs generated by the web medical platform GenIDA.

HuMa-SimSC

HuMa-SimSC is the implementation giving birth to SimSC. It was conceived to be integrated in the HuMa architecture (see section 4.5), where the analysis is organized in three layers, as we mentioned in section 4.5. These layers are the ones shown in Figure 8.2. HuMa-SimSC works in the top layer, helping the analyst to build the assessment model of the attack. It takes as input the output of a previous process of filtering and clustering, as it is represented in Figure 8.3. More precisely, there are two previous steps, that are described in the publication about the HuMa architec- [START_REF] Offroy | [END_REF]] is to reduce the high dimensionality of data by decomposing the space in overlapped hypercubes and clustering the data laying in each of them. The connection of common points in different hypercubes results in a graph at the output.

Each node of the graph returned by TDA is a cluster containing several logs. It is here where HuMa-SimSC comes into play, as a sort of 'zooming' tool to analyze the logs contained in each cluster with up to 1000 logs. It works on the raw logs, whose content is preserved. The color assigned to each log in the visual representation of HuMa-SimSC corresponds to the CVSS assigned in Step 1.

In Figures 8.4 attempt. We use T max = 10s and n ip = 2 to create them. All the nodes represent logs coming from a firewall and containing the message "possible attack on capacity (host)", which indicates a threat against the maximum capacity of the destination. These three potential attacks are performed from different IP addresses and have the same mail server as target.

In Figure 8.5, there are two ensembles of logs in color brown that correspond to two different port scans targeting the same mail server. We have used T max = 5s and n ip = 3 to generate the graph. Each scan is executed from a different IP address: the one represented by the logs on the left from an external one and the other, from a local IP address. The isolated nodes in the lower left corner correspond to logs generated by the Centreon monitoring system. The turquoise ones do not have any IP address and the light pink ones have just one each corresponding to different machines.

Finally, we show in Figure 8.6 two screenshots associated to the same example. All the logs in the images represent the execution of Linux CRON tasks. These tasks are always executed at regular intervals. In the image on the left, we execute HuMa-SimSC with n ip = 0, as CRON logs do not have any associated IP address, and T max = 59s. Only those logs representing the same task, and thus being coincident in timestamp, are linked together. However, if we increase the time to T max = 60s, all the logs are chained together, as we can see in the image on the right side. This means that they represent periodic tasks intended to be executed each minute. This result is very interesting for the HuMa project as many malicious actions, such as communications with a Command & Control server, are periodically performed at regular intervals.

Logan

GenIDA (Genetically determined Intellectual Disabilities and Autism Spectrum Disorders) is a project started in 2014 by Jean-Louis Mandel, member of the IGBMC (Institut de Génétique et de Biologie Moléculaire et Cellulaire) in Strasbourg. Its goal is the collection and analysis of medical information about genetic intellectual disabilities (ID) and autism spectrum disorders (ASD). The collection of data is done through a website2 that allows the participation and sharing of families affected by one of these diseases.

One of the developer of the GenIDA website, Timothée Mazzucotelli, has adapted SimSC to work with the logs generated by the Apache server hosting the website. The resulting interface, that could be adapted to any kind of Apache web log, is called Logan. A screenshot of the interface of Logan is shown in Figure 8.7.

There are three characteristics of each node that give information about the represented log:

• Its size is proportional to the number of bytes in the response sent by the web server.

• Its color depends on the returned HTTP status code: purple for 100 and 200; blue for 300 and 400, and turquoise for 500 and 600. These sets of codes are considered as representing activities with low, medium and high risk, respectively.

• Its shape, that represents the type of HTTP request by the codes in Table 8.2.

Another adaptation of Logan with respect to the basic SimSC is that edges are now directed according to the time order of connected logs. Regarding the IP addresses, Apache logs only contain the one from the user doing the request, so we use n ip = 1.

To begin the inspection of the logs, the analyst has to specify the period she wants to analyze. The amount of logs in a certain period of time depends on how many users access to the website but also on the logging configuration in the server, that determines which actions are recorded as logs. In the case of GenIDA, if we execute Logan for the period from the 23/09/2014 to the 2/11/2014, we obtain the graph shown in Figure 8.8. Some transformation is needed to comfortably dive in this graph. One of the functions in Logan is to filter the visualized logs by their HTTP status code. Web An example of web attack found using this method is shown in Figure 8.10. We clearly see that the attacker has searched for the PHP script 'setup.php' in several paths of the URL. This is the typical behavior of the ZmEu scanner3 . The presence of this bot in the high risk logs is confirmed by the sequence of requests shown in Figure 8.11, containing the message "w00tw00t.at.blackhats.romanian.anti-sec:)". Notice that we are dealing with real requests coming from the outer world, and not with simulated data.

Raw-SimSC

The mentioned implementations of SimSC, HuMa-SimSC and Logan, are conceived for working with a specific type of log. The process behind is the same as the one shown in Algorithm 8.1, but the interfaces include additional elements to ease visualization. However, we have implemented a version of SimSC, called Raw-SimSC, where the user can upload any raw log file, execute the algorithm and visualize the results. Nodes have no colors this time, except for the RealSecure alerts listed in Table 7.1, page 171. The names of the listed alerts are searched in the raw log and, if one is found, a color is assigned according to the associated risk level: red for 'high', orange for 'medium' and green for 'low'. The rest of the nodes are colored in gray.

Although there are no theoretical limitations about the number of logs SimSC can manage, there is a practical limitation in the visualization using Raw-SimSC, which can represent up to 1000 nodes. This means that a full representation of ISCX (section 7.1.2) or HuMa (7.1.3) is not feasible, as it is indicated by their size in Table 7.9, page 192. However, the DARPA 2000 dataset is not that big and we can test Raw-SimSC with it.

In Figure 8.12 we show a screenshot taken after the execution of Raw-SimSC in inside1, with T max = 8s and n ip = 2. Of course, the amount of logs in the dataset is too high to see the details. But as some of the nodes are colored according to the risk level in the RealSecure alert, we can locate the 'hot spots', those parts of the graph where there are alerts with high risk level (nodes in red).

Zooming in one of these areas, the one on the top of Figure 8.12, we can find that 'Sadmind_AO' and 'Admind' alerts that are related have been connected in the same scenario, as we can see in Figure 8.13. If we click in a node, the corresponding raw log is displayed next to it. Notice that we do not have processed the alerts using the normalization process described in section 7.1.4. The log is preserved in raw, as it was furnished by Ning (see page 171).

More on the right of this scenario, there is another one with 'Sadmind_AO' and 'Admind' alerts. Next to it, there is a scenario containing the traces of the rsh communication ('Rsh' alerts). Both are shown in Figure 8.14. LLDoS 1.0, the attack contained in DARPA inside1, has another interesting characteristic that can be visualized in Raw-SimSC: the last step of the attack, represented by the RealSecure alert 'Stream_DoS', does not have any IP address in common with any other step in the attack. We can see its isolation in Figure 8.15, where the node representing it, colored in black because it is 'selected' in the interface, is only connected to a 'Port_Scan' alert not related to LLDoS 1.0. The reason for this lies in the source IP address spoofing performed when launching the DDoS attack against the external machine, a process explained in section 3.2.2. Source and destination IP addresses are actually not the only attributes of this step that are different from the ones in the other steps. There is no attribute in common between the 'Stream_DoS' alert and the others, unless a textual similarity in type with 'Mstream_Zombie' alerts because of the word 'stream'. This is a clear example of similarity-based methods (see section 4.3.1, page 70) not being valid for the identification of all kinds of scenario.

Summary

We have presented our last contribution, SimSC, in this chapter. SimSC is conceived for the visual investigation of scenarios in raw logs. First, this model has been explained in section 8.1. Then, two implementations, HuMa-SimSC and Logan, have been presented in section 8.2.1 and section 8.2.2, respectively. We have ended up the chapter presenting Raw-SimSC, an interface for SimSC that can be applied to any set of raw logs, in section 8.3. Raw-SimSC has been tested with the DARPA 2000 dataset. In the next chapter, we will present the perspectives of this thesis. Several contributions have been presented throughout this thesis: the systematic bibliography about multi-step attack detection; the concept and creation of Abstract Attack Scenario Graphs for expressing alternative multi-step attack cases; two algorithms, Morwilog and Bidimac, to perform detection and identification of attacks using AASGs, and SimSC, a model for visual investigation of attack scenarios. The concepts and models presented here provide new research elements to the not much explored field of modelization and identification of multi-step attacks.

In this chapter, we discuss about the future work that can be done from the advances presented in this thesis. We have divided the chapter in four sections, corresponding to the four different ambits in which we can classify the presented contributions. In section 9.1, we present some perspectives on the conclusions extracted from the multi-step attack detection literature. Concretely, we propose an architecture called OMMA that could contribute to open research in the future. Then, in section 9.2, we discuss the possible evolution of the AASG model, to make it more flexible and with a higher number of available functions. Perspectives on the detection and identification of attack scenarios are the subject of section 9.3, where we propose the evolution of Morwilog and Bidimac and the creation of new algorithms. Finally, in section 9.4 we discuss about the future of SimSC and its different implementations.

On research about multi-step attack detection

Apart from being the first time, as far as we now, that the literature about multi-step attack detection on traces is brought and analyzed together, the systematic survey presented in Chapter 4 has allowed us to make a statistic about the selected corpus and extract some conclusions about the field. Some future ways of research can be derived from them:

• To apply the systematic bibliographic methodology used for the survey and presented in section 4.2 to other fields, not necessarily related to Cybersecurity.

Being systematic and rigorous is a way of giving bibliographic research a scientific character.

• To develop new public test datasets containing different instances of multi-step attacks and containing several types of logs, not only IDS alerts. We will come back to this topic in section 9.3, as it is a question that has directly affected the evaluation of Morwilog and Bidimac.

The OMMA framework

The name OMMA stands for Operator-guided Monitoring of Multi-step Attacks, but it also comes from ancient Greek , which means [START_REF] Aristophanes | Aristophanes. "Clouds. Wasps. Peace[END_REF]] 'the eye of heaven'. OMMA follows the same perspective as HuMa [START_REF] Navarro | [END_REF]] and KILS [Legrand 2014]: the investment of the human analyst in the investigation and detection of the attacks (see section 4.5). However, there are some key differences between OMMA and the mentioned systems:

• Unlike HuMa, that is solely oriented towards the forensic investigation, OMMA is also focused on real-time detection, taking the approach of classic signaturebased detection but giving elements for the integration of learning algorithms.

• OMMA differs from KILS in that it offers an open architecture for the integration of different detection methods. KILS presents a general cognitive model but not a description of the specific modules to be implemented.

The design of OMMA is based on three axis: our experience in security research, part of it acquired during the writing of this thesis; our knowledge about attack detection methods used in the industry, especially of SIEM (Security Information and Event Management) [START_REF] Kavanagh | [END_REF]], and the study of the bibliography about multistep attack detection presented in Chapter 4. The two goals present in the conception of OMMA are:

• To make it an open system, in the sense that its components should be modular and other researchers could develop new methods or adapt existing ones for including them into the system. The open challenge is to offer a framework for improving research collaborations and profit from past work. This would help to mitigate the lack of reproducible research in multi-step attack detection.

• To keep the human in the loop from investigation to detection, as proposed by Legrand et al. [Legrand 2014]. We consider that the last verdict about what suppose a threat must be given by the human, whose creative thinking and knowledge about the network she is defending allow her to determine the consequences of events marked as malicious by the system. This information can be fed into OMMA, which makes it compatible with Morwilog, Bidimac or SimSC, whose functioning is based on feedback from the human.

The OMMA architecture is organized in different modules that can be grouped in four domains: Connection, Analysis, History and Knowledge. These domains are compliant to the four levels defined in the KILS model: real world, storage, inference and expert knowledge. A global diagram of OMMA is represented in Figure 9.1. In the following subsections we will briefly explain each one of the modules so they can be completely implemented in the future. 7.4, page 175, represents a first step in the development of a universal format for event-based security research. We have developed several log parsers to transform the datasets used in this thesis (DARPA 2000, ISCX and HuMa) to that common format, that would integrate a library of parsers in the Collector that would be shared with the community. Another task of the Collector is the application of basic filtering, discarding events that are not intended for analysis. Additionally, the algorithm for event aggregation presented in section 7.2.3, page 187, could be included in this module.

Actuator (AC) The other piece in the Connection domain is the Actuator, that would be responsible for performing actions in the network in response to detected attacks or security flaws. These actions can be very diverse, from the activation of a firewall rule to the disconnection of a server from the Internet. Intrusion response is not easy to automate. Even a security analyst may not have a direct answer about how to fight a threat and has to try different methods before getting to block an attack. However, it is expected that it will become a hot topic in the near future [START_REF] Ossenbühl | [END_REF]], so a module like the Actuator cannot be missing in a framework that tries to englobe all the aspects of investigation and detection.

Analysis domain

Two of the modules in the Analysis domain perform real-time detection of multi-step attacks: the Matcher and the Classifier. The third module, the Orchestrator, is in charge of the coordination of the whole system.

Matcher (MT) This module would apply classical attack detection based on signatures or rules, so well-known threats can be rapidly detected. Detected events would be tagged as malicious, so the rest of the system knows about their nature. It is important to keep them in the analysis, as they can be part of a more complex attack scenario, like it happens with the individual IDS alerts in DARPA 2000 (see section 7.1.1). The resulting tagged set of events is called E tag . Tags can be just appended to the log as an additional attribute. Particular attention should be given to the input and output formats, which have to be well designed to ease the implementation of new methods.

Orchestrator (OR) After the Matcher, events are sent to the Orchestrator, the central module of the system. It coordinates the detection process and makes the final decision about which set of events is a threat for the network. It counts with the tagged events coming to the Matcher, that can be sent to the machine learning algorithms in the Classifier (see below). It also manages the feedback provided by the analyst through the Visualizer. Once a verdict is issued about the nature of the events, attack alerts ( ÂEout ) are sent to the Visualizer, to the Actuator and to the Logger, which also receives the events to store them (E out ), possibly enriched during the process.

Classifier (CS) Machine learning classifiers of attacks are intended to be contained in this module. A workflow could be defined inside the Classifier to decide which types of events are processed by which of the implemented algorithms and in which order. The output would be a set of classified events that can be used by the Orchestrator. The development of this module would require a deep knowledge about the different families of machine learning methods and the possible outcomes.

Chapter 9. Perspectives

History domain

This domain is in charge of storing historical data and it includes just one module, the Logger.

Logger (LG) This module is the responsible of stocking and managing the historical data of the system, both events and alerts. Its implementation should be prepared for the big amount of logs generated by current networks per instant of time. Routines have to be developed to manage the usage of disk space and memory. Stocking events and alerts for a long period allows to do investigation of past attacks, that would be managed by the Visualizer.

Knowledge domain

The Knowledge domain has two modules in charge of expert data: the Advisor, that stores information from past experiences, and the Visualizer, that takes feedback from the analyst from a visualization interface.

Advisor (AD) This is the module in charge of managing and storing expert knowledge, which is either manually introduced by security analysts or automatically learned by machine learning algorithms. Within this knowledge we could find, for instance, the AASGs used by Morwilog and Bidimac (Chapter 6) or the list of prerequisites and consequences used by the methods presented in section 4.3.2.1. If methods using automatic learning are integrated in OMMA, data in the Advisor could be updated as new events are processed. This would be managed by the Orchestrator, that also distributes data from the Advisor to the modules needing it, such as the Matcher and the Classifier. A challenge in the development of the Advisor is to create a format for expert data that could be useful for different methods.

Visualizer (VZ) This module is intended to visually represent the information of alerts and events to the human analyst and to get feedback from her. The visualization interface has to be adapted to any new method incorporated into the system. An implementation of the Visualizer should consider the best way to combine different kinds of visualization and to manage the input coming from the analyst. It would also act as a console for system configuration. Moreover, it should contain tools for forensic investigation on the events and alerts contained in the Logger.

Modularity in OMMA

A future implementation of OMMA should be totally modular. Each module has been designed for being independent from the others and replicable to several instances. There are several good reasons to preserve this idea of modularity:

• Different types of event can be processed separately. We can have, for instance, several Classifiers, each one with a set of algorithms dedicated to a specific type of event. This can also ease the combination of modules developed by different research units.

• A hierarchical design is possible, with an instance of one module acting as master and some others as slaves. This is important if we deploy the system in a large network. We can, for example, have an Orchestrator master controlling some other ones acting as agents, in different areas of the network or remote sites.

• We can do load balancing between different instances of the same module. Doing so, we can combine small modules for having a processing power equivalent to a bigger unit, therefore saving cost. For example, we can think of some instances of the Collector module working together for processing a high volume of events.

• A module can be doubled for High Availability. If one instance fails, the other one can automatically take its place, avoiding system interruptions. The most suitable element for High Availability is the Logger, as it stores sensitive information which is worthy to be replicated, avoiding data loss in case of failure.

• It can lead to economies of hardware or design, as several modules can be grouped into the same device, especially the ones belonging to the same domain.

For example, we can have an Orchestrator, a Classifier and a Matcher in the same box.

In Figure 9.2, an example of modular implementation of the OMMA architecture in a final network is represented. There is a Collector for each of the subnetwork A and B, reporting to the same Matcher, and only one Actuator for both subnetworks. In the case of subnetwork C, it has its own Actuator and Matcher, but also two active Collectors configured to do load balancing. The Orchestrator, the Classifier and the Advisor share the same hardware, which reduces delays in the transmission of information. However, the Visualizer is implemented in a different asset. Finally, there are two Loggers in High Availability configuration (HA) into which all the information is duplicated. If one stop working, the other can continue its task.

On the evolution of AASGs

The AASG model (Chapter 5) is probably the first one conceived for representing a set of alternative multi-step attack hypotheses for their detection and identification.

There is substantial room for new contributions in both the composition of the AASG itself and its creation from a detected instance of a multi-step attack. Perspectives on this two aspects are presented below, in sections 9.2.1 and 9.2.2, respectively.

The structure of the AASG

The building blocks of an AASG are the abstract events contained in its nodes, which determine the events that could match each node. Matching is determined by a set of conditions composing the abstract event. We have defined 10 different conditions, that are listed in the Appendix E. Half of them are absolute, thus referring to a certain external value or set of values, and the other half are relative, thus pointing towards the previous event in the sequence. The conditions defined so far give the analyst much flexibility in the creation of the AASG, as we saw in the AASGs presented throughout this thesis, listed in Appendix F. However, an analyst could still imagine comparisons that would be hard to implement using the conditions proposed so far. The first evident way to improve the definition of the abstract events is the development of new conditions. For example, the hierarchybased similarity feature defined by Julisch (see page 50) could be implemented for different types of inherent attributes: IP addresses, port numbers, etc.

Another way of improving conditions would be by the extension of the existent ones. For instance, textual similarity (conditions TXT and SIM_TXT) could be implemented by means of another function different from the Jaccard index, such as lexical matching [START_REF] Metzler | [END_REF]] or the Levenshtein distance [START_REF] Vladimir I Levenshtein | Binary codes capable of correcting deletions, insertions, and reversals[END_REF]]. On its side, the set-based condition (SET) could also incorporate alternative definitions of sets R for different types of attribute, without the need of listing all the elements in the set. These definitions could be based, for example, on a numerical interval (e.g.

[1024, 5000]) or, in the case that the attribute has IP addresses as values, a subnetwork defined by a mask (e.g. 175.68.22.0/24).

An additional improvement could come from the objects that are compared in the relative conditions. So far, we have only defined relative comparisons between attributes in different events, but we could think of comparing attributes within the event itself. For example, it could be interesting to define a condition based on the similarity between the source and destination IP addresses. A prefix comparison (condition SIM_PFX) between the two values could tell us when the source and destination are too far in terms of network distance.

Regarding the combined used of the conditions, all the conditions contained in the abstract event have to be fulfilled to considered the event as matched with the abstract event at the present state of the model. This is equivalent to an AND (^) logical relationship between the conditions. To broaden the possibilities given to the analyst for the definition of the hypotheses, some other logical relationships between conditions could be proposed, such as OR (_). This logical combination of conditions could be inspired in the ones used by modeling languages such as LAMBDA [START_REF] Cuppens | LAMBDA: A language to model a database for detection of attacks[END_REF]] (see page 37).

The creation of the AASG

An example of how the analyst can create an AASG from a set of logs representing a multi-step attack was given in section 5.3. However, we have not addressed in detail the steps for creating a general AASG. A formal methodology for the creation of AASGs is fundamental if we want to continue working with the model. This methodology could be first developed from the study of several examples of multi-step attacks. The process of hypothesis derivation can then be reproduced taking the point of view of the security analyst. Once this basic methodology is developed, it could be improved by the development of AASGs in a real environment. A set of working security analyst, from a public institution or a private company, would be trained in what an AASG is and how it can be built. They would then choose some multi-step attacks to develop their own AASGs, writing down all the steps done during the deduction process. This notes, together with the resulting AASGs, would be studied by the researcher to improve the methodology firstly developed. On top of that, the researcher would have a new set of AASGs to perform experiments. The evaluation of the difficulties found in the creation of the AASGs could also lead to an improvement in the definition of an AASG and in the conditions contained in the abstract events.

The AASG model has been conceived to be manually built from the analyst's working hypotheses. But we could also imagine the automatic derivation of AASGs by means of an automatic learning algorithm. Automatic methods could derive a set of alternative cases from a dataset that would be part of the AASG, which would be later used to detect and identify the correct hypotheses in real events.

As we saw in Chapter 3, there does not exist a standard way of modeling a multistep attack. Having a library of AASGs shared by the community would allow having together the working hypotheses about multi-step attacks. Inspiration can be taking from existent alert sharing platforms [START_REF] Husák | [END_REF]]. Specific models, in the form of CASGs, could be built once the hypotheses are confirmed, by deduction from the AASGs and the associated sample events detected by them. We could even extract different hypotheses about the same attack in several alternative CASGs. Improvements done on the structure of the AASGs would not diminish the power of a library of AASG if changes are thought to be compliant with the existent structure.

Comparing existent AASGs would allow finding common patterns between the alternative cases of different multi-step attacks. The fusion of AASGs could result on more general AASGs that would have never been separately developed. AASGs in the common library could be also studied using graph theory and characterized by some of the metrics used in this field, such as the dimension. This could maybe lead to a classification of the multi-step attacks according to the arrangement of the deduced hypotheses.

On attack case detection and identification

The goal of the algorithms presented in Chapter 6, Morwilog and Bidimac, is the detection and identification of the alternative cases represented in an AASG. Even if they work well, as we saw in Chapter 7, they still have limitations and there is much room for improvement. Possible future ways of improving attack case detection and identification using AASGs are presented below. First of all, we address in section 9.3.1 the limitations of datasets and how further evaluation of the presented algorithms could be done if they are overcome. In section 9.3.2, we propose the exploration of case confirmation and the incorporation of step prediction into the models. To implement these two functions, there is no need of modifying the current AASG, but only a different view on pheromones and probability parameters. We continue by proposing the implementation of real-time functioning in section 9.3.3 and automatic functioning in section 9.3.4, as possible improvements of Morwilog and Bidimac. Finally, we open the door to the development of new algorithms in section 9.3.5.

Further evaluation

It was mentioned in section 4.4.2 that existent public datasets are composed by raw packets, so they need to be processed by an IDS in order to get a set of events, the alerts, with the IDS as the single source. Moreover, none of the most used public datasets contains several instances of a multi-step attack, but just one. Remember that for the experiments with DARPA 2000 we had to consider the infections of the Mill, Locke and Pascal machines as different multi-step attacks, even if they constitute three parts of the same attack, performed in parallel (see section 7.2.1). A complete evaluation of Morwilog and Bidimac requires similar instances of a multi-step attack, so we had to artificially create the Eventgen datasets, presented in section 7.1.5.

Of course, many private datasets such as HuMa (section 7.1.3) exist, but their content cannot be disclosed, as we commented at the end of section 4.4.3. Some researchers use data collected from their own university [Chen 2014a] or company [Julisch 2001], or from partners [START_REF] Sudit | [END_REF][START_REF] Skopik | Dealing with Advanced Persistent Threats in Smart Grid ICT Networks[END_REF], Zhang 2015]. There is even a shared private dataset, the one generated by Skaion Corporation [START_REF] Shaneck | [END_REF][START_REF] Mathew | [END_REF]], but access to it is limited to official U.S. government's research.

An important future line of research is the generation of new public event-based datasets, either from real events or from a test network. To be useful to our research, they should a) contain several instances of a multi-step attack and b) have labels in the events indicating where the attacks are1 . The availability of these datasets would allow the execution of new experiments to evaluate Morwilog, Bidimac and any other new method working with AASGs.

For example, with new correctly built datasets we could better study the effect of different types of AASG in the execution of the algorithms, checking the influence of their size or depth. A catalog of AASGs (see section 9.2.2) would be developed in parallel to allow this evaluation.

Case confirmation and step prediction

Both in Morwilog and Bidimac, we have left at the sole discretion of the analyst the moment when one of the cases in the AASG is considered as confirmed. Future work could address different ways to determine when to stop in the identification process based on the values of the levels of pheromones and the probability parameters. The most intuitive conditions to consider a case as confirmed would be based on the choosing probability P b of the branches, defined in Equation 7.1, page 194. For example, if we set a certain threshold p , some possible conditions to stop could be:

• The highest P b is above p .

• The different between the highest P b and the second highest one is above p .

• The different between the highest P b and the addition of the rest is above p .

Conditions to identify when a branch in a DAG is clearly dominant with respect to the other ones are also found in the literature and can be adapted to the algorithms working with AASGs. For instance, Jiang et al. [START_REF] Jiang | [END_REF] propose the concept of importance of a branch as an indicator for pruning a tree. Defining an entropy of an AASG in terms of Information Theory could also serve to decide at which moment the AASG stops giving enough new information.

Apart from the confirmation of cases, another way to explore is the use of the AASG as a model for prediction. When the proposed algorithms are executed, information about the history of incoming sequences is coded in the level of pheromones or in the probability parameters. This information could be used to trigger early warning alarms to inform the analyst about which are the most probable events continuing the sequence. This would be a complement to the current mode of functioning of Morwilog and Bidimac, in which alarms are only triggered once the sequence has been totally discovered. We could imagine a predictive models in which alarms are sent right before a very probable path is detected, even if the execution of the full detection process continues in parallel.

Real-time functioning

Even if both Morwilog and Bidimac have been conceived for working in real time, they have been neither implemented nor tested yet in a real environment. However, special attention has been taken to simulate this real behavior: happens sequentially, alarms are not raised until the last event in the found sequence appears in the input.

• The stigmergic or Bayesian AASGs do not evolve until the simulated analyst evaluates the alarms.

Despite of this measures, some assumptions not present in a real environment has been also taken into consideration. The development of new implementations overcoming these assumptions constitutes a good base for future work:

• Events are stocked in a file and load into the system during initialization. Without modifying the algorithms, the two models could be adapted to work with real incoming data by deploying a previous layer in charge of the collection of events. To do that, some available software already exists, such as Logstash [Turnbull 2013].

• The simulated analyst evaluates the alarms immediately after they are triggered. It is clear that a human security analyst could not be able to do so. To get a more realistic model, a system of alarm queues could be developed and the simulated analyst could incorporate a random delay. The only effect this would have in the algorithms is that the evolution of the AASGs would be performed later. The impact of this delay could be evaluated in real data. Inspiration to create the queues could be taken, for instance, from the work by Zali et al. [START_REF] Zali | [END_REF]], which could also help in the implementation of a predictive version of the models (see section 9.3.2).

• As our security analyst is simulated, there is no monitor to visualize and acknowledge the alarms. The development of such a monitor would allow the researcher to test the models in a real environment with a human analyst.

• The parallel execution is simulated. The search processes are not executed in different computer threads. However, both Morwilog and Bidimac have been conceived to be parallelized, being each search process autonomous from the others. A parallel implementation would be an excellent goal for future work, certainly increasing the speed of the execution and making the systems able to deal with big amounts of real-time data.

Automatic functioning

Morwilog and Bidimac have been conceived to work with AASGs created by the analyst from her working hypotheses, but we already mentioned in section 9.2.2 the possibility of having these AASGs automatically created from event data using a learning algo- 6.1 and P tree = 0.5, P jump = 0.1. The size of the dataset is indicated next to the points. L is the length of injected sequences. rithm. This process could be directly integrated in the execution of Morwilog, Bidimac or any other algorithm doing detection and identification with AASGs.

In fact, we already explored this possibility for Morwilog when the algorithm was first presented in public, at the SSCI conference in December 2016 [Navarro 2016]. Back then, we had not developed all the theory around AASGs. The structures used were then called event trees. They were created randomly from incoming data, as we wanted to test how the pheromones made the system evolve and not how the trees could be built by a human analyst.

Random creation of event trees was controlled by two parameters: P tree and P jump . For each event e i creating a morwi, if e i did not match the root node  0 of any event tree among the existent ones, a new event tree with a single branch was created from a random sequence of events starting in e i . Moreover, every time a morwi had to choose among events matching the children of a certain node, there existed a probability P jump of choosing a random event instead of one in the selected list. If this was the case, a node containing an abstract event representing this random event was appended to the tree with a minimum level of pheromones. This automatic mechanism was not practical since it returned a lot of alarms to the analyst, but even without having a previous library of event trees we could see the positive effect of the evolution of pheromones as the size of the dataset increased. These results, obtained from simulations on a set of Eventgen datasets (see section 7.1.5), are shown in the two ROC plots in Figure 9.3. They were previously published in the article about OMMA [Navarro 2018b].

New mechanisms for automatizing the functioning of Morwilog and Bidimac, not necessarily related to the one just mentioned, could be incorporated into the systems in future work.

New algorithms

The last future line of research about attack case detection and identification is the development of new algorithms working with AASGs. The three premises on which such an algorithm should be built are listed in the introduction of Chapter 6, in page 135: capability of performing identification, generation of alarms when a sequence matching a branch is detected and presence of the human in the loop. These premises establish the minimum requisites an algorithm should fulfill to be comparable to Morwilog and Bidimac.

To create new algorithms, the first step could be to modify the two existing ones. For example, remember that some conditions were defined for a morwi to interrupt its journey if a similar morwi was recently created (see page 148). This avoids the creation of too many morwis when there are a lot of very similar events in a short period of time, as it happens in a scan. This feature was not implemented in Bidimac because we wanted it to be a pure Bayesian method, with probability parameters always in accord to the statistics of the matched attack sequences. A new pseudo-Bayesian model could be derived from Bidimac introducing this feature or other similar ones.

On the visual investigation of multi-step attacks

SimSC, that constitutes the last contribution of this thesis and was presented in Chapter 8, was conceived when exploring how the analyst could perform investigation on a set of raw logs. Even if some implementations of SimSC, such as HuMa-SimSC and Logan, have been created, there is still a lot of aspects to explore and improve that could constitute the subject of future research.

For instance, we did not define how found attack scenarios could give rise to the cases that would conform an AASG. SimSC could be implemented together with an AASG editor, so the analyst could build the hypotheses by directly selecting the suspicious nodes and arranging them in branches.

Moreover, the inherent attributes with which SimSC works so far are just two, the IP addresses and the timestamp. Further work could be done to automatically extract other attributes that also have a fixed and particular format, such as MAC the extraction on the format of the attribute, as we did so far, it could be based on the context of the information within the log. For example, we know that in many logs a port number usually follows the IP addresses, separated by them by a colon (':'). Additional information for attribute extraction could come from the position of strings within the log. For instance, the source IP address is usually placed before the destination IP address.

Regarding the shape of the scenarios, the order of events is difficult to visualize in the current version of SimSC, even if it allows the easy identification of port scans as conglomerations of events, as we could see in Figure 8.5. To make the order of events explicit, direction could be added to the edges joining each couple of nodes in the visualization screen. This direction would point from the node representing the earlier event in the couple to the one representing the later one.

On top of that, calculating and representing the transitive reduction of the resulting graphs could help the visualization of the sequences. The transitive reduction [Aho 1972] of a directed graph D is the graph resulting from the preservation of only the longest path among all the existent paths joining two nodes. An example of transitive reduction is shown in Figure 9.4. The arc ae, for example, is erased, and only the paths a-b-d-e and a-c-d-e joining a and e are preserved. As we can see in this example, the number of arcs is reduced and the order followed by the nodes is more easily visualized. This could probably lead to a better deduction of the causality of events within the scenarios in SimSC.

Finally, an interesting line of research would be to adapt SimSC to work with parsed logs, in which the inherent attributes are distinguishable. Doing so, all the similarity and time-based features presented in sections 3.4.1 and 3.4.2, respectively, could be applied to build connections between the logs. Features could be used either individually or combined by means of correlation functions, such as the ones presented in section 3. to improve automatic detection methods.

We have explored different similarity features on several attributes to compose a set of graphs with the alerts related to the attack LLDoS 1.0 in DARPA 2000. The obtained results have been represented in Cytoscape. One of the resulting graphs is shown in Figure 9.5. This work is still in a preliminary stage, but we are convinced that a further exploration of similarity and time-based features in a selected corpus of multi-step attacks would give us a better insight on how steps are related. Developing a tool for the exploration of these features would help researchers on the development of new methods. Anyways, researchers should be aware that a pure similarity-based method would never be able to detect all types of multi-step attacks, as the attacks in DARPA 2000 clearly indicate. This limitation was addressed in page 72.

Summary

A Ph.D. thesis would not be complete without the exposition of the perspectives opened by the performed research. In this chapter, new lines of research have been proposed based on each of the four contributions of this thesis:

• In section 9.1, we have proposed OMMA, an open framework that tries to alleviate the lack of reproducibility in the multi-step attack detection methods reviewed in Chapter 4. OMMA has been presented in section 9.1.1 and its modularity is explained in section 9.1.2.

• In section 9.2, we have presented possible future work for the evolution of the AASG model (Chapter 5) in two ambits: the improvement of it structure (section 9.2.1) and the development of methods for the creation of AASGs (section 9.2.2).

• In section 9.3, several lines of research for the development of models for multistep attack detection and identification using AASGs, such as Morwilog and Bidimac (Chapter 6), have been introduced. We have proposed the further evaluation of Morwilog and Bidimac with new test datasets (section 9.3.1), and their improvement by the incorporation of case confirmation and prediction mechanisms (9.3.2) or an automatic functioning mode (9.3.4). Finally, we have proposed the development of new algorithms in section 9.3.5.

• In section 9.4, some improvements of SimSC (Chapter 8) has been proposed, such as the automatic extraction of additional attributes, the transformation of the graphs to their transitive reduction or a version of the model for parsed logs. The present Ph.D. thesis is written in a context in which multi-step attacks, such as WannaCry, continue to wreak havoc on organizations from all around the world. Once an attack with these characteristics is performed, it is a challenge for a security analyst within the attacked organization to identify the actions that took part on it and, more importantly, to determine how the attack could be repeated in the future. A correct identification of the involved steps is essential for the development of solid detection models.

Our research question, presented in Chapter 1, page 3, is:

How can we help the security analyst to decide between alternative scenarios of multi-step attacks in order to ease the detection of future occurrences? Can we perform detection at the same time as the learning process evolves?

It addresses the development of a model for helping the analyst in the modelization of alternative multi-step attack cases, the detection of these cases on incoming events and the identification of the correct ones.

Before giving answer to this question, Chapter 2 is devoted to the definition of the concepts used throughout this thesis. This step is fundamental, as we find that not even englobing concepts such as Cybersecurity have a standard and widespread definition. We see that the 'traces' constitute a set in which the actions of the attacks are represented. They act as a source of information for the security analyst.

The object of our study are the multi-step attacks, that are addressed in Chapter 3. Multi-step attacks can be modeled as directed graphs, called CASGs, with the arcs of the model representing a certain relationship between two traces, that constitute the nodes. This relationship is characterized in the literature by one or more features. We distinguish between three types of feature: similarity, time-based and contextbased. They are generally expressed by functions, whose results can be combined to numerically define the arcs in the CASG.

Once the multi-step attacks are well defined, we study in Chapter 4 the methods developed for detecting them. The resulting corpus of publications addressing multistep attack detection methods and the conclusions extracted from them constitute the first contribution of this thesis. At the same time, the selected corpus, built following a systematic review methodology, represents a solid bibliography for this thesis. We find five kinds of approach in multi-step attack detection: similarity-based, causal correlation, structural-based, case-based and mixed. The most important conclusion we can extract from this chapter is that no method exists to integrate the multi-step attack cases proposed by the human analyst in the detection process, in pursuit of their identification on the incoming traces. Another conclusion, that is secondary for answering our research question but very relevant for the field, is that most of the publications in the selected corpus contain experiments that are not reproducible, which is probably a collateral effect of the lack of publicly shareable datasets containing multi-step attacks.

The model we propose to represent the alternative cases or hypotheses of multi-step attacks as they are conceived by the analyst constitutes the second of our contributions of this thesis. We focus on the events as the traces in which attacks are expressed. The model is called Abstract Attack Scenario Graph (AASG) and it is presented in Chapter 5. An AASG is a directed acyclic single-source graph where the alternative cases are arranged in different branches, with each node represented by an object, called abstract event, that refers to a selection of events through a set of conditions. The formal definition of the model is complemented by a functional JSON-based language and by a graph editor to easily express the AASGs.

Specific algorithms have to be developed to work with the AASG model, which is prepared both for detection and identification of correct multi-step attack cases. Our third contribution is composed of two models to perform these tasks, Morwilog and Bidimac, which are presented in Chapter 6. Both models rely on the feedback provided by the security analyst once a case is detected and the malicious nature of the corresponding sequence of events is evaluated. Morwilog is based on the behavior of foraging ants when they look for food sources. An artificial ant, called morwi in the model, is created each time an event arrives to the system. It then looks for a branch in an AASG matched by this event and subsequent ones. Bidimac transforms the AASGs in a Bayesian model reflecting the statistics of the correct multi-step attack cases.

Evaluation of the AASG model, Morwilog and Bidimac is presented in Chapter 7. Regarding the first model, we see that the implemented mechanisms are generic enough to define AASGs for the three studied datasets: DARPA 2000, ISCX and HuMa. In the two last datasets, we can even define one general AASG capturing the general sequence of actions of several types of attack. All the defined AASGs allows successful attack detection in the respective datasets. Regarding Morwilog and Bidimac, the first one returns fewer alarms to the analyst than the second one, as it chooses only one path in the AASG among the possible ones. Because of this, it is also more adaptable to big amounts of incoming events. In terms of precision and recall, both models behave similarly. The ability of detecting multi-step attacks relies on how the AASG is defined.

Our fourth and last contribution is a model for visual investigation of attack scenarios in sets of raw logs. It is called SimSC and it is presented in Chapter 8. SimSC is based on the automatic extraction of IP addresses and timestamps from logs that have not been normalized, thus expressed as plain text. The logs are represented as nodes in a graph whose edges are defined by similarity of the extracted attributes. Our goal conceiving SimSC is to explore the process of investigation performed by the analyst after the occurrence of an attack. The evaluation of the model is done through its implementation on the HuMa architecture and on a web platform working with medical data. A standalone version is also implemented and tested with the events in the DARPA 2000 dataset. Although the current visualization of SimSC is simple and the analyst is responsible for the interpretation of what is represented, the idea we want to highlight is the possibility of identifying scenarios on logs that have not been processed. This is important in a computer environment allowing the connection of non-standard devices with unknown log formats.

The lack of public datasets with several instances of multi-step attacks hinders the evaluation of the presented contributions. For evaluating Morwilog and Bidimac beyond the performance of specific AASGs, we had to create our own artificial set of datasets. Solving this problem with datasets constitutes the base of one of the future lines of research presented in Chapter 9. This Ph.D. thesis opens an ample range of perspectives linked to any of the four contributions. The systematic survey of multi-step attack detection methods reveals the lack of reproducibility of experiments in the field. This brings us to the proposal of OMMA, an open framework for multistep attack investigation and detection that we expect will be further developed in future research. AASGs can be improved in many ways, by the development of new matching conditions or the establishment of a formal methodology to create them. The limitations of Morwilog and Bidimac with respect to a functional implementation are numerous. We expect that future research will continue the development of these models to better adapt them to real situations so they can be tested by security analysts in real time. Finally, SimSC still represents a preliminary contact to the vast and unexplored world of attack scenario investigation in raw logs. By conceiving it as visually-based, we want to emphasize the importance of the human analyst in the investigation and detection of multi-step attacks.

To these two activities, investigation and detection, we append in this thesis the process of identification, the confirmation of correct hypotheses about a found attack. There is no much research work addressing this phase of Cybersecurity that lies between investigation and detection, even if it is obvious that this process takes place every time a security analyst develops a detection model. Machines are far from substituting human beings in this process. Instead of trying to unsuccessfully develop automatic detection methods tested on scarce and not very representative datasets, we propose to concentrate the research effort on models to help the human analyst, assuming the essential role of her creative thinking. We modestly expect that the proposed contributions will lead the way to further progress on this, especially with respect to multi-step attacks, a threat that seems to have come to stay. La question de recherche à laquelle répond cette thèse est :

1 (typea, 'Sadmind_Ping') = 1  1 e ⇤ 1 g 5 (typea, {'Sadmind_AO', 'Admind'}) = 1, f 1 (ipsrca, ipsrcp) = 1, f 1 (ipdsta, ipdstp) = 1  2 e ⇤ 2 g 1 (typea, 'Sadmind_AO') = 1, f 1 (ipsrca, ipsrcp) = 1, f 1 (ipdsta, ipdstp) = 1  3 e ⇤ 3 g 5 (typea, {'Sadmind_AO', 'Admind'}) = 1, fneq(typea, typep) = 1, f 1 (ipsrca, ipsrcp) = 1, f 1 (ipdsta, ipdstp) = 1  4 e ⇤ 4 g 1 (typea, 'TelnetTerminaltype') = 1, f 1 (ipdsta, ipdstp) = 1  5 e ⇤ 5 g 1 (typea, 'Rsh') = 1, f 1 (ipdsta, ipdstp) = 1  6 e ⇤ 6 g 1 (typea, 'Rsh') = 1, f 1 (ipsrca, ipdstp) = 1  7 e ⇤ 7 g 1 (typea, 'TelnetTerminaltype') = 1, f 2 ({ipsrca}, {ipsrcp, ipdstp}) = 1, f 2 ({ipdsta}, {ipsrcp, ipdstp}) = 1  8 e ⇤ 8 g 1 (typea, 'Mstream_Zombie') = 1, fneq(ipdsta, ipdstp) = 1  9 e ⇤ 9 g 1 (typea, 'Mstream_Zombie') = 1, f 2 ({ipsrca}, {ipsrcp, ipdstp}) = 1, g 1 (ipdsta, 255.255.255.255) = 1  7  0  1   3   5   8  Figure F
0  5  6  8  9 Node Abstract event List of conditions  0 e ⇤ 0 g 1 (typea, 'Sadmind_AO') = 1  5 e ⇤ 5 g 4 (typea, {'Rsh', 'FTP_Put'}) = 1, f 1 (ipdsta, ipdstp) = 1  6 e ⇤ 6 g 1 (typea, {'Rsh', 'FTP_Put'}) = 1, f 1 (ipsrca, ipdstp) = 1  8 e ⇤ 8 g 1 (typea, 'Mstream_Zombie') = 1, f 6 (ipdsta, ipdstp) = 1  9 e ⇤ 9 g 1 (typea, 'Mstream_Zombie') = 1 f 2 ({ipsrca}, {ipsrcp, ipdstp}) = 1 g 1 (ipdsta,
0  1  2  3  5  4  6  8  7 Node Abstract event List of conditions  e ⇤ 0 g 4 (typea, 'ICMP detected', 0.3) = 1, g 3 (ipdsta, '192.168.0.0 0 , 0.45) = 1, g 2 (ipsrca, '192.168.5.122 0 ) = 1, g 2 (ipsrca, '192.168.5.123 0 ) = 1  e ⇤ 1 f 1 (typea, type b ) = 1, f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, fneq(ipdsta, ipdst b ) = 1  e ⇤ 2 f 1 (typea, type b ) = 1, f 1 (actiona, action b ) = 1, f 1 (ipsrca, ipsrc b ) = 1, f 1 (ipdsta, ipdst b ) = 1, f 1 (psrca, psrc b ) = 1, fneq(servicea, service b ) = 1  e ⇤ 3 f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'SQL', 0.1) = 1  e ⇤ 4 f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'failure SSH', 0.5) = 1  e ⇤ 5 f 1 (ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'EXPLOIT Attempt', 0.1) = 1  e ⇤ 6 fneq(ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'SQL', 0.1) = 1  e ⇤ 7 fneq(ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'failure SSH', 0.5) = 1  e ⇤ 8 fneq(ipsrca, ipsrc b ) = 1, f ⇤ 3 (ipdsta, ipdst b , 0.75) = 1, g 4 (typea, 'EXPLOIT Attempt', 0.1) = 1
Comment peut on aider l'analyste de sécurité à décider les plus probables parmi plusieurs hypothèses des attaques multi-étapes ? Peut on réaliser la détection en même temps que ce processus d'identification a lieu ?

L'objectif de cette thèse est la création de modèles pour :

• Exprimer les di↵érents hypothèses sur une attaque multi-étape.

• Identifier les hypothèses correctes en faisant au même temps de la détection.

On va voir que ce problème n'a pas été abordé par la littérature sur les attaques multi-étapes.

Définitions préliminaires

Dans cette section, nous présentons quelques définitions qui sont clés pour comprendre les contributions de la recherche.

Cyberattaque

Le premier concept basique à définir est la cyberattaque. Une cyberattaque est un acte qui compromet la confidentialité, l'integrité ou la disponibilité d'un réseau d'ordinateurs ou de l'information qu'il contient.

Dans le cadre de cette recherche, on se focalise exclusivement sur ceux qui ont lieu au Cyberspace, qui est l'environment abstrait où la communication des ordinateurs a lieu. Nous ne considérons pas de cyberattaques qui a↵ectent le monde physique.

Dans ce contexte, on peut considerer deux acteurs principaux, l'attaquent, qui est l'agent qui exécute une cyberattaque, et le défenseur, qui est l'entité en charge de protéger le réseau attaqué. Nous prenons la place du défenseur, qui est personnifié dans la figure de l'analyste de sécurité. Elle va être la responsable de développer les modèles de détection pour détecter les cyberattaques.

Trace

Pour savoir qu'est-ce qui se passe au réseau, l'analyste compte sur les traces, qui enregistrent de l'information sur les actions faites. Il y a deux grands types de traces très utilisés (Figure 1) :

Le processus de cybersécurité

L'analyste est une pièce centrale [Caulkins 2018] qui est capable d'incorporer au processus de détection la créativité humaine et un ensemble des connaissances construit à partir de son expérience.

Les réseaux d'ordinateurs sont devenus indispensables dans le quotidien. Ils nous permettent de communiquer avec des personnes distantes, partager des fichiers ou simplifier les tâches administratives. Malgré ses avantages, il y a aussi des risques dans l'interconnexion des ordinateurs. Par exemple, la cyberattaque WannaCry a provoqué des ravages en 2017, en a↵ectant plus de 230.000 ordinateurs dans 150 pays, comme la Russie ou l'Espagne [Ehrenfeld 2017]. WannaCry est un exemple de cyberattaque multi-étapes, un terme qui désigne une cyberattaque composée de plusieurs phases ou étapes di↵érentes.

Ces actions sont enregistrées dans les traces du réseau, présentées dans la section 2.2. Un exemple de trace sont les fichiers de logs, des journaux des événements qui sont sauvegardés dans les dispositifs connectés au réseau. Ils existent trois activités majeures d'exploitation de ces fichiers : l'investigation, la détection et la prédiction. Chacune est liée à un moment de temps : le passé, le présent et le futur, respectivement. La détection des attaques en temps réel et la prédiction des attaques futures sont basés sur modèles construits grâce aux conclusions obtenues après l'investigation des attaques exécutées dans le passé. Notre question de recherche fait référence au processus d'abstraction de ces conclusions, ou modélisation, et à la confirmation des modèles construits, ou identification.

Attaques multi-étapes

Les nombre des actions contenues dans une attaque nous permet de distinguer deux types d'attaques : mono-étape et multi-étape. Dans un côté, les attaques mono-étape sont composées par seulement une action. Une injection de SQL et une dénégation de service sont des examples d'attaques mono-étapes. Si l'attaque est composé de plusieurs actions di↵érentes, on l'appelle attaque multi-étape.

Nous nous sommes focalisé sur les attaques multi-étapes par son grande répercussion actuelle. Un indicateur de ça c'est le longue temps moyenne qui passe entre le début d'une cyberattaque et la découverte de l'intrusion, qui permet aux attaquants de developper des attaques avec plusieurs étapes (Table 1). Un example concret d'une attaque multi-étape récente est WannaCry, apparue en mai 2017. Elle est probablement la pire attaque de l'histoire des réseaux informatiques. Elle a a↵ecté des centaines de milliers d'ordinateurs dans le monde. L'attaque est basée sur un malware qui crypte l'information de la machine infectée et se propage en profitant d'une faille du protocol SMB v1. La mitigation de cette attaque a été pas facile : même si de signatures simples pour détecter le malware ont été développé le même jour de l'infection, les analystes de sécurité ont passé au moins un mois a dévoiler tous les étapes de l'infection (Figure 2). La mise en place des modèles de détection focalisés sur les étapes intermédiaires et pas seulement sur la fin de l'attaque (l'infection de malware) aurais pu réduire l'impact de l'infection.

Présentation des contributions

La littérature scientifique se focalise seulement sur des modèles des detections finales, construits à partir des événements qui appartiennent à une attaque concrete. L'analyste de sécurité modélise directement l'attaque trouvé pour l'incorporer au processus de détection sur les événements à venir.

Ce modèle ne laisse pas de la place pour les possibilités alternatives de l'attaque. Ces possibilités viennent des questions qui se pose l'analyste : quelles sont les actions exactes qui participent à l'attaque, est-ce qu'elles vont se répéter, est-ce que le même ordre va être respecté, etc. En plus, si l'attaque est ciblé, l'analyste a seulement une example d'attaque à étudier et les questions ne peuvent pas être résolu.

Ça ramène à l'analyste à poser une série des hypothèses alternatives sur l'attaque, qui donnent comme résultat des modèles alternatifs. Notre idée est de préserver ces modèles pour le processus de détection donc on peut détecter des sequences qui correspondent aux modèles et au même temps faire un processus d'identification des modèles correctes pour consolider un modèle de détection.

Nous proposons un nouveau modèle pour confronter les attaques. Si dans le modèle classique on a l'analyste seulement dans un côté du processus, avec les alarmes générés par la détection envoyées à lui dans un seul sense, notre modèle place l'analyste dans le centre du processus, en lien avec la philosophie suivie par tous les partenaires du projet HuMa, qui a financé cette recherche.

On introduit un nouveau processus que c'est l'identification, grace auquel on va pouvoir déterminer quels sont les modèles identifiés et plus pertinents pour créer un modèle de détection définitif. Dans notre modèle, l'analyste modélise tout un ensemble des hypothèses alternatives au lieu d'un modèle de détection unique. Pour faire ça, Nous devons d'abord proposer un modèle pour que l'analyste puisse exprimer ses hypothèses. Ces hypothèses doivent être représentés dans une structure commun pour exécuter le processus de détection. Nous proposons comme structure commun le modèle AASG, une des contributions de cette recherche.

L'AASG est fait pour représenter les hypothèses comme des chemins qui peuvent être parcouru par des algorithmes de recherche. L'objectif des algorithmes est faire de la détection et identification d'attaques multi-étapes sur le modèle AASG. Il faut donc développer des algorithmes qui travaillent sur les événements qui arrivent au système et génèrent des alarmes qui peuvent être évalués par l'analyste de sécurité. Elle pourra donc donner de l'information à l'algorithme pour son apprentissage. Nous proposons deux algorithmes pour ce propos : Morwilog, basé sur le comportement des fourmis, et Bidimac, basé sur la statistique Bayésienne.

Pour arriver aux conclusions qui nous ont permis de développer ces contributions, on a fait la première recherche bibliographique qui existe sur la détection des attaques multi-étape, qui représente aussi une contribution de cette thèse.

Les contributions mentionnés sont présentés brièvement dans la liste suivante :

• Bibliographie systématique sur la détection d'attaques multiétapes. Dans les publications traitant le problème de recherche des attaques multi-étapes dans des jeux d'événements il n'y a pas de distinction claire entre les attaques passées (investigation sur des fichiers de traces statiques) et présentes (détection sur des données en temp réel). En fait, la plupart des méthodes de détection sont évaluées sur des jeux estatiques, car il est di cile de générer des attaques multi-étapes et les analyser en temps réel. On parle donc de méthodes de détection pour parler des méthodes de recherche des attaques qui peuvent éventuellement être utilisées aussi pour l'investigation. Des méthodes spécifiques pour la détection d'attaques multi-étapes ont été développées depuis le dernier changement de siècle, mais jusqu'à maintenant il n'existait pas d'une analyse du domaine, ses défis et ses perspectives. Une de nos contributions est le premier travail de bibliographie systématique sur la détection d'attaques multi-étapes dans des enjeux de traces. • Graphes des scénarios d'attaques abstraits (AASG). L'ensemble des hypothèses proposées par l'analyste de sécurité sur la manière dont une attaque multi-étape peut se répéter doit être modélisé pour effectuer le processus d'identification des celles qui sont avérées. Nous proposons un nouveau modèle, le AASG (Abstract Attack Scenario Graph en anglais), où les propositions alternatives sont représentées pour être évaluées avec l'arrivée de nouveaux événements. Au contraire de la représentation concrète d'une attaque multi-étape, que nous appelons CASG (Concrete Attack Scenario Graph), un AASG peut capturer l'abstraction nécessaire pour la définition des cas futurs de l'attaque. Les cas alternatifs sont organisés dans les di↵érentes branches de l'AASG, toujours à partir d'un noeud racine qui permet l'identification du premier événement de la séquence et la sélection de l'AASG adéquat. Chaque noeud contient un événement abstrait qui représente les événements qui peuvent être identifiés dans cette étape de l'attaque en utilisant un ensemble de fonctions. 4 Étude bibliographique sur la détection d'attaques multi-étapes La première contribution est une recherche systematic qui a été publié en 2018 [Navarro 2018]. Nous avons défini deux critères d'inclusion : on considère seulement des méthodes de détection qui travaille sur des traces réels qui arrive au système, et la structure complète de l'attaque doit être considéré. Ça veut dire qu'on ne considère pas des méthodes, par example, de détection de malware, qui sont capable de détecter la présence de l'attaque mais seulement par une étape.

Le champ de détection d'attaques multi-étape est relativement nouveau, de début des années 2000. Le résultats du survey est un corpus de 201 papiers qui présentent 138 méthodes di↵érents.

Une des conclusions de l'étude bibliographique est sur les set de données utilisés dans les expériences. On voit que la plupart des publications travaillent avec au moins un set de données publique (Figure 3). Pour notre recherche, aux sets de données publique trouvés dans l'étude bibliographique on doit ajouter le set HuMa, crée en 2015 par un des partenaires membre du projet qui a financé cette thèse. Malheureusement, même s'il y a quelque datasets disponibles, aucun d'entre eux a ses donnés éttiquetés pour indiquer où sont les attaques. Seulement trois viennent avec des informations sur les attaques, donc on peut étiqueter les données à la main. Nous avons donc choisi ces trois pour évaluer nos contributions : ISCX, HuMa et DARPA 2000. Il faut savoir que chaque dataset choisi contient seulement une attaque par ensemble de données, et ça pose des di cultés pour l'évaluation.

Une autre conclusion est que les attaques multi-étape sont généralement modélisé comme des graphes acycliques dirigés (DAGs). Dans ces modèles, le noeuds contiennent des traces qui représentent les actions ou étapes de l'attaque. Les arêtes représentent la relation entre les actions, comme par example une relation de similarité. Vu que chaque auteur nomme ce structure d'une façon di↵érent, on lui a donné le nom de Graphe de Scénario d'Attaques Concrets (CASG). On voit que ces modèles sont utilisés seulement pour la modélisation des attaques concrets : la modélisation des scénarios alternatives n'est pas considérés dans la littérature.

Graphes des scénarios d'attaques abstraits (AASG)

L'idée du CASG a été prise pour développer un modèle où les hypotheses alternatives de l'attaque puisse être modélisés. Un CASG permet de repré-senter seulement une attaque. On a du donc faire un processus d'abstraction qui nous a amené au nouveau modèle.

Ce nouveau modèle s'appelle Graphe de Scénario d'Attaque Abstrait (AASG), et c'est la prochaine contribution qu'on va analyser. Les CASGs representent un résultat de la détection, et l'AASG est vraiment un modèle pour faire de la détection des hypothèses alternatives. Pour définir l'AASG il faut deux pas : la modélisation des hypothèses et la définition de la structure du modèle.

Modélisation des hypothèses

On peut commencer par la modélisation des hypothèses de l'analyste sur des attaques multi-étapes. Cette idée des hypothèses alternatives a été récupéré d'un papier de Pirolli et Card de 2005. Ces auteurs posent l'idée mais les hypothèses ne sont pas formellement définies.

Pour les définir formellement, il faut que chaque hypothèse represent une possible voie d'action d'une attaque multi-étape, donc le modèle doit être composé par chacune des étapes présentes dans l'attaque. Chaque fragment du modèle doit représenter un ensemble des événements, qui éventuellement vont se correspondre à chacune des étapes de l'attaque.

Pour représenter l'ensemble des événements qui correspondent à chaque étape, nous avons défini un événement abstrait comme un ensemble de conditions. On propose deux types de conditions : des conditions absolus, qui sont basées sur la comparaison avec des valeurs prédéfinies, et les conditions relatives, qui sont basées sur la comparaison avec les étapes précédentes de l'hypothèse.

Nous avons établi 10 conditions, 5 absolus et 5 relatives, qui sont définis par une série de functions mathématiques. Tous les conditions sont listés dans la Table 2.

Définition de la structure d'un AASG

Une fois les hypothèses sont modélisées, il faut définir la structure de l'AASG. Nous nous sommes inspirés dans le modèle AOH, développé pour l'analyse du comportement des analystes pendants la résolution de conflits. Dans ce modèle, les hypothèses sont simplement définies en format de texte libre, mais nous voulons les exprimer dans une façon mathématique pour les définir formellement et pour permettre aux algorithmes d'utiliser le modèle. Nous arrivons à donner un caractère mathématique au modèle en utilisant les concepts de la Théorie de Graphes. Un autre condition pour le modèle est qu'il soit fini, parce que les hypothèses définies par l'analyste vont avoir un nombre limités des étapes. C'est pour ça que nous avons utilisés des graphes acycliques dirigés (DAG), sans boucles, pour éviter des possibles chemins infinis. Et finalement, le modèle doit être unique, pour permettre aux algorithmes de pouvoir choisir un AASG à parcourir pour chaque événement qui arrive au système. On peut avoir ça en utilisant un graphe avec une seule source.

En prenant en compte tous ces conditions, nous avons défini le AASG comme un graphe avec les hypothèses représentés dans chacune des branches. Chaque AASG va être identifié par la source, appelé noeud racine. Dans ce modèle, si on prends deux noeuds connectés, on appelle parent au noeud les plus proche au noeud racine et enfant au noeud le plus loin.

Example d'AASG

Représentation JSON

Une autre contribution lié aux AASGs est la représentation dans un format que les machines puissent lire et utiliser. Dans les AASGs, chaque noeud contient une représentation abstrait d'un log. On a défini un format JSON pour codifier les AASGs. Le format de ce JSON est assez simple :

• Le fichier représente un ensemble des arbres, qui sont contenus dans une liste sous la rubrique « trees ». • Chaque arbre contient un identifiant (« id ») et une liste de noeuds (« nodes »). • Chaque noeud contient quatre éléments :

• Un identifiant (« id »)

Conclusions AASG

Pour conclure cette section sur les AASGs, on a développé une représentation abstrait pour exprimer les hypothèses de l'analyste qui contraste avec le caractère concret du modèle CASG, qui représente seulement une attaque multi-étape spécifique.

Ce modèle peut être utilisé pour faire de la détection, en lançant de proces-sus de détection sur chacune des hypothèses contenu dans l'AASG. Et aussi pour faire de l'identification, pour signaler les hypothèses correcte trouvés, vu qu'on peut assigner des poids aux arrêtes de l'AASG pour enregistrer l'apprentissage sur la pertinence de chacune des hypothèses. Ils nous faut des algorithmes pour faire ces détection et identification. C'est pour ça que nous avons développé Morwilog et Bidimac, deux autre contributions de cette thèse, présenté dans la prochaine section.

6 Algorithmes pour l'exploitation d'AASG

Chacun des algorithmes développés suit une approach complètement di↵érente. D'abord, Morwilog suit une recherche stochastique où seulement une branche (une hypothèse) est cherchée chaque fois. Il y aura donc des choix aléatoire des chemins dans l'AASG.

De son côté, Bidimac suit une recherche déterministe où tous les branches de l'AASG sont cherchées. Le statistique des sequences d'entré est donc préservée.

Morwilog

Morwilog est basé sur l'optimization par colonie de fourmis (ACO), une metaheuristique d'optimization inspirée par le comportement des fourmis quand elles cherchent de la nourriture. Une colonie des fourmis converge toujours au chemin le plus court vers la nourriture grâce au dépôt de phéromones (Figure 8). Cette idée est directement pris par ACO, où les plus haut concentration de pheromones corresponds avec le chemin le plus court dans un graphe d'optimisation. Mais en Morwilog, l'increment de pheromones va signaler les branches dans l'AASG qui sont trouvés et confirmés par l'analyste.

Plus précissement, Morwilog est basé sur le moteur des hommilières (manhill) développé au sein d'ICube. L'idée principale est la génération de fourmis artificielles après l'arrivage d'un log au système. Ces fourmis s'appellent « morwis », nom qui vient du préfix Proto Indo-Européen pour fourmi.

Le comportement de ces morwis est basé sur le comportement des fourmis quand elles sont à la recherche de nourriture. Similairement, les morwis traversent les AASGs, qui représentent séquences d'évènements, à la recherche des hypothèses. Pour pouvoir utiliser l'AASG dans ce contexte il faut ajouter 3. Dans cet exemple, l'option la plus probable est k 1 . Imaginez que la morwi choisit ce noeud. Maintenant elle doit répéter le même procédé pour le niveau suivant. Le procédé est répété jusqu'à la morwi arrive sur un noeud sans enfants.

4. Une fois le parcours est fini, la morwi rendre comme résultat la séquence complète choisie si le taux de phéromones est plus grand qu'un certain seuil fixé.

Le prochain pas est l'évaluation de l'expert en sécurité de la séquence proposée par l'algorithme. L'expert va étudier la séquence d'événements et va indiquer au système s'il s'agit ou pas d'une attaque. Si c'est une attaque, le taux de phéromones de tout le chemin est incrémenté (voir Figure 11). Si ce n'est pas considéré comme une attaque, il y a un décrément du niveau de phéromones (voir Figure 12).

L'evolution de pheromones chaque fois qu'une alarme est évaluée se fait par deux pas. D'abord, il y a un processus d'évaporation dans tous les arrêtes de l'AASG :

⌧ [t + 1] = (1 ⇢) • ⌧ [t] ( 1 )
Après, il y a l'increment ou le décrément dans les arrêtes qui sont dans la (2)

Les formules pour les deux opérations donne les paramètres de Morwilog, auxquelles il faut ajouter le temps maximum de recherche et le niveau minimum

Bidimac

Mais pour quoi l'inference Bayésienne ? D'abord, c'est une méthode assez étendue et bien étudié. Mais aussi la définition de l'AASG stigmergique correspond avec la logique Bayésienne. Quand on prend un AASG et on le transforme dans une AASG stigmergique, les niveaux de pheromones sont toujours initialisés au même valeurs, ⌧ 0 , un des paramètres de Morwilog.

On peut définir la probabilité de choix comme la probabilité de choisir un noeud depuis son parent quand tous les enfants ont été trouvé. Si on change le niveau de pheromones par la probabilité de choix, on obtient directement un modèle Bayésien. On a donc l'AASG stigmergique, où les pheromones sers à sélectionner aléatoirement un chemin, et l'AASG Bayésien, où les paramètres des probabilités vont refléter le statistic du système et tous le branches sont cherchées.

En Bidimac, le AASG Bayésien va être divisé dans tous ses branches et une séquence d'événements qui correspond à chacune des branches va être cherchée. Tous les branches trouvés vont générer des alarmes pour l'analyste. Une fois les alarmes sont confirmées, tous les paramètres de probabilités de l'AASG Bayésien vont évoluer par rapport un certain taux d'apprentissage ⌘.

Comparaison Morwilog et Bidimac

Les similarités entre Morwilog et Bidimac sont :

• Le deux suivent la logique Bayésienne, où des probabilités de parcours de l'arbre sont connues a priori. Mais la méthode Bayésienne, comme son nom l'indique, suit une actualisation des probabilités Bayésienne classique : la probabilité associée à chaque lien est obtenue à partir de l'observation directe des séquences des événement. Morwilog par contre fonctionne à partir de la métaphore biologique des fourmis artificielles, et incorpore des mécanismes comme l'évaporation de phéromones ou l'élection des chemins qui ne sont pas supportés par la statistique des modèles Bayésiennes. • Le deux utilisent des Graphes Dirigés et Acycliques (DAG, Directed Acyclic Graphs) pour représenter les relations entre les di↵érents événements.

• Les noeuds dans les DAGs sont liés par des lien avec une probabilité associée. La probabilité dans Morwilog est codée sous forme de phéromones (Figure 13).

• Les graphes résultant de l'exécution des deux méthodes donnent de l'information sur la distribution statistique des séquences représentant des attaques possibles.

1000 200 800 On a défini la probabilité d'élection comme la probabilité assignée à un chemin de l'AASG. Dans le cas de Morwilog, la probabilité dépend des phéromones, et on peut la calculer en divisant le niveau de phéromones du chemin par l'addition des niveaux de phéromones de tous les chemins partant du même noeud (celui-ci compris). Si on fait une étude théorique de l'évolution de la probabilité d'élection dans les deux méthodes, on constate que Morwilog nous donne plus de liberté pour faire converger l'algorithme au chemin de l'arbre qui représente l'attaque. Si seulement une entre les hypothèses proposées est correcte, l'expert va être notifié plus rapidement avec Morwilog qu'avec la méthode Bayésienne (Figure 14).

 0  1  2  3 (

Évaluation

Les résultats de l'évaluation des AASGs et les algorithmes a été soignoisement présentée dans la thèse et on ne va pas reproduire ici les résultats. La conclusion principale est que le choix entre Morwilog et Bidimac depend de l'application, des nombres des événements attendu et de l'expectative de l'analyste par rapport aux AASGs construits.

La détection a été évalué sur trois datasets : ISCX (développé par UNB), HuMa (le dataset développé au sein du projet) et DARPA 2000 (le dataset classique pour la détection d'attaques multi-étapes). Comme ces datasets contiennent seulement une instance d'attaque multi-étape et on a besoin de au même scenario ont typiquement des adresses IP en commun et ils sont temporellement proches.

SimSC a été conçu pour tenir en compte des autres relations entre les attributs des logs pour faire les liens entre les logs. Cependant, pour travailler avec les résultats de HuMa on ne peut qu'utiliser les adresses IP et le temps de chaque log, parce que les logs sont présentés en format de texte, sans aucune di↵érentiation entre les champs des logs. Ceci est expliqué par le fait que les logs sont des logs massifs (Big Data) desquels on ne connaît pas son format spécifique.

L'implémentation de SimSC fonctionne de la façon suivante quand il traite les graphes provenant de l'algorithme TDA :

• D'abord, on extrait automatiquement la liste des adresses IP présentes dans le log. On peut les extraire facilement car elles suivent un format normalisé X.X.X.X, avec X un octet. Par contre, il n'est pas possible de faire la distinction entre les adresses IP qui correspondent aux sources et à celles qui correspondent aux destinations. • La date correspondant à la génération du log est aussi extraite. On cherche des formats de dates dans le log, on transforme en timestamp POSIX (millisecondes) et on prend la valeur minimum comme correspondant au timestamp du log. La valeur minimum permet d'identifier le plus vieux timestamp associé au log. On a fait la comparaison entre cette valeur minimum extraite automatiquement et le timestamp réel dans un jeu de logs étiqueté avec des timestamps corrects contenant plus de 3 million de logs. Le résultat a été toujours le même : le plus bas d'entre tous les timestamps automatiquement extraits du log correspond à la valeur du timestamp réel. • Une fois que l'information est extraite depuis les logs, l'algorithme compare tous les logs entre eux et crée un lien entre deux logs si a) la di↵érence entre 2 timestamps ne surpasse pas un certain seuil et b) s'il y a au moins un certain nombre d'adresses IP en commun dans la liste. Les métriques basées sur la di↵érence de timestamp et la similitude entre des adresses IP sont les métriques les plus utilisés dans la reconnaissance des attaques multi-étapes (plus de détails dans l'article A Systematic Survey on Multi-step Attack Detection, publié dans le cadre de cette thèse et référencé à la fin de ce document).

TDA a pour but de générer des représentations agrégées à partir de la projection des logs sur de nombreuses dimensions. Comme les logs sont de pièces d'information multi-dimensionnels (ils sont plusieurs champs ou attributs), ils L'algorithme SimSC est maintenant appliqué sur chacun des noeuds du graphe de la Figure 16. Pour visualiser les résultats nous avons utilisé une interface graphique basée sur une application web, développée en JavaScript, HTML et Python. C'est une plateforme interactive dans laquelle l'expert peut cliquer sur les noeuds des graphes pour a cher l'information des logs et même entraîner les noeuds pour explorer la structure des scenarios de comportement. Les couleurs assignées aux noeuds sont choisies en fonction de l'étiquette CVSS qui correspond à chaque log. Visuellement il donne à l'analyste une idée des logs plus dangereux.

L'analyste peut analyser le contenu de chaque noeud du graphe issue de l'algorithme TDA en cliquant sur lui et en appliquant l'algorithme SimSC sur Quelques exemples de scénarios d'usage anormaux découverts par l'analyse sont maintenant présentés. On considère 2 noeuds représentatifs du graphe de la Figure 16, qui a 11 noeuds :

• Noeud 4 (Figure 17) : Il contient des logs réguliers générés par le daemon CROND périodiquement. Son agrégation en couples ou trio est très particulière et donne à l'analyste une vision du temps dans lequel les tâches sont exécutées. Comme ils sont des tâches périodiques, les liens sont créés seulement quand la di↵érence de temps entre les logs surpasse certain seuil et pour tous les logs au même temps. Par exemple, dans le graphe de la Figure 17, fait avec une di↵érence de temps maximum pour construire chaque lien de 59 secondes, on a observé que si on monte la di↵érence de temps à 60 secondes, tous les logs sont liés par des liens. Ça veut dire que la di↵érence de temps entre les logs suit un pattern établi entre chaque couple de logs. • Noeud 6 (Figure 18) : Le cluster des logs que l'on voit indique un scan : l'adresse IP source est la même tout le temps et il y a une grande quantité de paquets de connexion en direction du même serveur dans un espace de temps réduit, en changeant les numéros de ports. Un scan est utilisé par un attaquant pour trouver de l'information nouvelle sur les systèmes à attaquer. Le plus intéressant est que le fournisseur de ces données n'avait pas prévenu de ce scan, et on l'a trouvé grâce à SimSC.

Logan : une adaptation de SimSC

Le laboratoire ICube a aussi développé Logan, une implémentation de SimSC qui démontre les capacités de ce modèle. Le but de cette implémentation est de tester SimSC, développé pour HuMa, dans un environnement réel afin de supporter les tests à faire par les partenaires industriels. L'interface montre les résultats de SimSC appliqué à l'analyse des logs Web générés par Genida, une plateforme de centralisation, stockage et coordination de donnés de cohortes de maladies génétiques rares développée au sein d'ICube. Mais, en filtrant les logs de haut risque (code http 400-500), l'analyste peut facilement détecter les tentatives d'intrusion. Si on ne prend qu'un type de logs, on peut facilement les chemins qui décrit le comportement d'un utilisateur. Ça permet à l'analyste d'identifier visuellement des attaques comme des injections SQL ou des tentatives d'exécution de scripts (Figure 20). Les attaques trouvées sont transmises aux développeurs du système de stockage des données pour prévoir les vecteurs d'attaque possibles lors du développement.

Conclusion

Le problème qu'on a a↵ronté dans ce thèse est la non consideration dans le modèle classique de détection d'attaques multi-étape des hypothèses posés par l'analyste. Nous avons proposé pour ça un modèle où l'analyste est placé dans le centre pour modéliser ses hypothèses sur les attaques multi-étapes et pouvoir les détecter et identifier les hypothèses correctes.

L'étude bibliographique, un des contributions de cette thèse car elle est la première étude complète fait sur la détection d'attaques multi-étape, nous a montré que dans le modèle classique, on doit délivrer des modèles de détection définitifs.

Nous avons développé une série d'outils pour donner à l'analyste la possibilité de proposer des modèles intermédiaire comme des hypothèses. D'abord, une structure, l'AASG, pour les modéliser. Ensuite, deux algorithmes, Morwilog et Bidimac, pour faire de la détection et de l'identification des hypothèses sur les AASGs.

Avec ce nouveau modèle, une fois la présence d'une attaque comme Wanna-Cry, la pire attaque que les réseaux informatiques ont sou↵ert, est découverte, l'analyste peut commencer depuis sa réception à coder ces hypothèses dans un ou plusieurs AASG. Ces AASGs pourront être envoyer à des algorithmes comme Bidimac ou Morwilog pour la détection et l'identification des hypothèses correctes et, entre temps, l'analyste peut continuer son processus d'investigation sur l'attaque pour arriver à un modèle définitif de détection.

Publications

Articles de journal :

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 1 . 1 :

 11 Figure 1.1: Diagram showing the different processes when finding cyberattacks. The temporal line below refers to the moment when the cyberattack happened with respect to when each process takes place.

Figure 2

 2 Figure 2.1: Number of reported CVE vulnerabilities per year. Data extracted from CVE Details [CVEDetails 2019]

  Figure 2.2: Components of a definition of 'Cybersecurity' according to ENISA [Brookson 2015]. The components considered in our definition are shaded in gray.

Figure 2 . 3 :

 23 Figure 2.3: Diagram representing the range of actions in each environment.

Figure 2

 2 Figure 2.4: Diagram representing the scope of traces, packets, events and alerts. Every alert is an event signaling a security incident. Both events and packets are traces.

  -step attacks in context . . . . . . . . . . . . . . . . . . . 25 3.2 Examples of multi-step attacks . . . . . . . . . . . . . . . . . . 29 3.3 Modeling multi-step attacks . . . . . . . . . . . . . . . . . . . . 35 3.4 Connection of nodes in the CAGS . . . . . . . . . . . . . . . . 44 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 3

 3 Figure 3.1: An Apache log representing a SQL Injection attack.

Figure 3

 3 Figure 3.2: A sequence of actions revealing the presence of WannaCry.

Figure 3 . 3 :

 33 Figure 3.3: Classification of multi-step attacks.

Figure 3 . 4 :

 34 Figure 3.4: LLDoS 1.0 attack in DARPA 2000.

Figure 3 . 5 :

 35 Figure 3.5: LLDoS 2.0.2 attack in DARPA 2000.

Figure 3

 3 Figure 3.6: UNB ISCX island-hopping attack. Representation inspired by the one by Sadighian et al. [Zargar 2014].

Figure 3 . 7 :

 37 Figure 3.7: HuMa attack.

Figure 3 . 8 :

 38 Figure 3.8: Example of LAMBDA signature of an NFS_abuse attack. Image extracted from the first publication about LAMBDA [Cuppens 2000].

Figure 3

 3 Figure3.10: Hierarchy trees for IP addresses and port numbers[Julisch 2003a]

  2012, Li 2016, Shittu 2016] Textual similarity f 4 (na, m b ) = 1 d(na, m b ) n = m = ipsrc [Zhang 2015] n = m = dom [Zhang 2015] n = m = type [Zhang 2015] Hierarchy-based similarity f 5 (na, m b ) = h(D(na, m b ))

  Figure 4.1: Diagram representing the keywords used in the Phase A of the systematic research. Different tones are assigned to each set of keywords used.

  Figure 4.2: Taxonomy of multi-step attack detection classification.

  Figure 4.3: Number of publications on multi-step attack detection per year.

Figure 4

 4 Figure 4.4: Number of publications on multi-step attack detection per year, classified according to the followed approach.

Figure 4

 4 Figure 4.6: Distribution of publications by the origin of the knowledge about attacks.

  c) Accessibility of models A k .

Figure 4

 4 Figure 4.7: Distribution of publications by reproducibility factors

Figure 4

 4 Figure 4.9: Diagram of the framework by Shaneck et al., adapted from [Shaneck 2006].

Figure 4 .

 4 Figure 4.10: The AI 2 system. Image adapted from [Veeramachaneni 2016].

Figure 5

 5 Figure 5.1: Trees in the AOH model. Image adapted from [Zhong 2013].

Figure 5 . 2 :

 52 Figure 5.2: Example of the AOH model for capturing the cognitive process of the analyst in the investigation of an abnormal quantity of IRC alerts. Image adapted from one of the publications by Zhong et al. [Zhong 2015].

Figure 5 . 3 :

 53 Figure 5.3: Example of an issue tree representing the discussion about the creation of the stirrup marking the beginning of Feudalism [Wojick 1975].

  Figure 5.4: Combination in a graph of two detection rules for DARPA 2000

Figure 5

 5 Figure 5.5: Example of alternative case derivation from WannaCry.

Figure 5

 5 Figure 5.6: Example of the implementation of a counter in an AASG. The AASG on the right is the same as the one on the left but expressed with a counter.

Figure 5

 5 Figure 5.7: Example of the implementation of optional nodes in an AASG. On the left we have the alternative scenarios, on the center the AASG defined without optional nodes and on the right, the same AASG expressed with optional nodes.

Figure 5

 5 Figure 5.9: The AASG in Figure 5.8 represented in the program Cytoscape.

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.2 Bidimac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 6.3 Differences between Morwilog and Bidimac . . . . . . . . . . . 159 6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

  Tmax 9ej : M (ej, 1) = 1 9ek : M (ek, 2) = 1 During t  Tmax 9el : M (el, 3) = 1 @em : M (em, 4) = 1 9en : M (en, 5) e i arrives, morwi chooses AASG u with M (e i ,  0 ) = 1

  morwi has to choose between found children of  0

  Pheromone-based weighted random selection

Figure 6 . 2 :

 62 Figure 6.2: Example about the progress of a morwi through an AASG.

Figure 6 ⌧0Figure 6 . 4 :

 664 Figure 6.3: Graph representing the evolution of pheromones for continuous reinforcement in Morwilog ('Increment') and classic ACO ('Classic'), and for continuous penalization ('Decrement')

Figure 6

 6 Figure 6.5: Example of evolution of the AASG when the attack is a false alarm.

Figure 6

 6 Figure 6.6: Two alternative transformations of (a) an AASG excerpt to express the optionality of node containing e ⇤ 7 : (b) duplicating the nodes to preserve the uniqueness of depth or (c) adding additional arcs to get the representation for Morwilog.

Figure 6 . 8 :

 68 Figure 6.8: Equivalence between a stigmergic and a Bayesian AASG.

Figure 6 .

 6 Figure 6.10: Example of continuous reinforcement in Morwilog (parameters from Table6.1) and Bidimac (⌘ = 0.4) with a simple AASG

  the evaluation datasets . . . . . . . . . . . . . . . 169 7.2 Evaluation of different AASGs . . . . . . . . . . . . . . . . . . . 177 7.3 Evaluation of the algorithms . . . . . . . . . . . . . . . . . . . . 191 7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200"Ciertamente, no lo sé. En materia de conocimiento he tratado siempre de limitarme al terreno de mis experiencias." [ "Certainly, I do not know. In matters of knowledge, I have always tried to limit myself to the realm of experience." ] -Juan Benet, Return to Región

  associated to the event (e.g. request, exit, blocked) process_id Identifier of the OS process related to the event psrc Source port number pdst Destination port number log The text of the raw log tag Indication of attack for evaluation

  events in the dataset num_typ_attack Number of different kinds of attack sequence num_typ_inn Number of different kinds of innocent sequence prop_attack Proportion of events corresponding to attack sequences prop_inn Proportion of events corresponding to innocent sequences seq_size Number of events (steps) in the sequences seq_step Maximum difference between events in a sequence

Figure 7 . 1 :

 71 Figure 7.1: Functional representation of the AASG Mill-1.

Figure 7

 7 Figure 7.2: Number of alarms vs. log number in inside1-NoMill using Mill-1

Figure 7 . 3 :

 73 Figure 7.3: Results of the execution of Bidimac with AASG Mill-1 in inside1-NoMill. The red-colored nodes represent the generated alarms.

0

  Figure 7.4: Examples of execution of Morwilog with AASG Mill-1 in inside1-NoMill.The uncolored nodes represent matched events that have not been chosen by the morwi.

Figure 7 . 5 :

 75 Figure 7.5: Number of branch matches in Morwilog using dataset inside1-NoMill with AASG Mill-1 after 5000 executions.

  Figure 7.6: Formal representation of AASG Mill-2.

Figure 7 Figure 7 . 8 :

 778 Figure 7.7: Functional representation of AASG Mill-2.

Figure 7 . 9 :

 79 Figure 7.9: Number of alarms with AASG Mill-2 in the aggregated version of inside1-NoMill.

Figure 7

 7 Figure 7.10: Results of Bidimac with AASG Mill-2 in DARPA inside1-NoMill, on the infections of the machines Locke and Pascal.

Figure 7

 7 Figure 7.11: Results of Morwilog with AASG Mill-2 in DARPA 2000 inside1-NoMill, on the infections of the machines Locke and Pascal.

Figure 7

 7 Figure 7.12: Number of alarms with AASG Mill-2 in inside2.

0 g 4

 04 (typea, 'ICMP detected',[START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]3) = 1, g 3 (ipdsta, '192.168.0.0 0 , 0.45) = 1, g 2(ipsrca, '192.168.5.122 0 ) = 1, g 2(ipsrca, '192.168.5.123 0 ) = 1

Figure 7 .

 7 Figure 7.13: Formal representation of the AAGS S2A.

Figure 7 .

 7 Figure 7.14: Functional representation of the AASG S2A.



Figure 7 .

 7 Figure 7.15: Formal representation of the AASG Eventgen. Nodes matched by the attack are colored in dark blue.

Figure 7

 7 Figure 7.16: Execution time with respect to the size of the dataset.

Figure 7

 7 Figure7.18: P[START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] in AASG Eventgen with respect to the number of attacks in the case of continuous reinforcement (eventgen datasets).

  Figure7.19: P[START_REF]FIRST-Forum of Incident Response and Security Teams[END_REF]1,3] in AASG Eventgen with respect to the number of false positive sequences in the case of continuous penalization (eventgen datasets).

Figure 7

 7 Figure 7.20: P [0,1,3] in AASG Eventgen with respect to the parameter ⌘ in Bidimac after 3 and 16 attacks (eventgen datasets).

Figure 7

 7 Figure 7.21: P [0,1,3] in AASG Eventgen vs. parameters ⇢ and w in Morwilog after 3 attacks (eventgen).

Figure 7 .

 7 Figure 7.22: P [0,1,3] in AASG Eventgen vs. parameters ⇢ and w in Morwilog after 16 attacks (eventgen).

Figure 7

 7 Figure 7.23: P [0,1,3] in AASG Eventgen vs. parameters ⇢ and w in Morwilog after 66 attacks (eventgen).

Figure 7 .

 7 Figure 7.24: TP and FP with respect to the maximum step distance in the attacks in eventgen datasets with AASG Eventgen

Figure 7 .

 7 Figure 7.25: TP and FP with respect to the maximum step distance in the attacks in eventgen datasets with AASG Eventgen-Noipsrc

  [ ** ] [1:2010937:2] ET POLICY Suspicious inbound to mySQL port 3306 [ ** ] [Classification: Potentially Bad Traffic] [Priority: 2] Aug 6 08:21:40 192.168.2.112:53508 -> 192.168.5.122:3306 TCP TTL:38 TOS:0x0 ID:31936 IpLen:20 DgmLen:44 ****** S * Seq: 0x69268A6B Ack: 0x0 Win: 0xC00 TcpLen: 24 TCP Options (1) => MSS: 1460 [Xref => http://doc.emergingthreats.net/2010937]

Figure 8

 8 Figure 8.1: An IDS log from ISCX indicating a possible SQL Injection attack.

  Figure 8.4: Three potential DoS attempts in HuMa-SimSC. T max = 10s and n ip = 2.

Figure 8

 8 Figure 8.5: Two port scans in HuMa-SimSC. T max = 5s and n ip = 3.

Figure 8 . 6 :

 86 Figure 8.6: The regularity of interval between periodic Linux CRON tasks in HuMa-SimSC. Left: n ip = 0 and T max = 59s. Right: n ip = 0 and T max = 60s.

Figure 8 . 7 :

 87 Figure 8.7: Screenshot of Logan interface.

Figure 8 . 8 :

 88 Figure 8.8: The global graph in Logan.

Figure 8 . 9 :

 89 Figure 8.9: Screenshot of a high risk scenario in Logan.

Figure 8 .

 8 Figure 8.10: Screenshot of Logan with a scenario where a user test to execute a script.

Figure 8 .

 8 Figure 8.11: Screenshot of Logan with script testing using ZmEu scanner.

Figure 8 .

 8 Figure 8.12: The events in DARPA 2000 inside1 represented in Raw-SimSC. T max = 8s and n ip = 2.

Figure 8 .

 8 Figure 8.13: A 'Sadmind_AO' scenario extracted by Raw-SimSC on the events in DARPA 2000 inside1.

Figure 8 .

 8 Figure 8.14: A 'Sadmind_AO' scenario and a 'Rsh' scenario extracted by Raw-SimSC on the events in DARPA 2000 inside1.

Figure 8 .

 8 Figure 8.15: An isolated 'Stream_DoS' alert extracted by Raw-SimSC on the events in DARPA 2000 inside1.

  research about multi-step attack detection . . . . . . . . . 218 9.2 On the evolution of AASGs . . . . . . . . . . . . . . . . . . . . 224 9.3 On attack case detection and identification . . . . . . . . . . . 226 9.4 On the visual investigation of multi-step attacks . . . . . . . . 231 9.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Et c'est toi maintenant, qui vas ouvrir la porte à l'ère nouvelle que j'entrevois... [And it is thou who wilt now open the door for the new era I have glimpses of...] -Maurice Maeterlick, Pelléas and Mélisande

•

  To keep an updated database of multi-step attack detection methods, taking as a basis the effort made in the elaboration of the survey. Despite of all these fields of action, what worries us the most is the lack of reproducible research in multi-step attacks, pointed out in section 4.4.3, page 96. To reduce the amount of non-reproducible work, we have conceived the OMMA architecture, an open framework for combining event-based investigation and detection methods coming from different researchers. It is a first brick in the pursue of a broadly used open system. Its design has been thought to be compatible with the bricks proposed in this thesis (SimSC, Morwilog, Bidimac) and presented in an article in the EURASIP Journal on Information Security [Navarro 2018b]. The development of each of the modules in OMMA can be a good subject for other Ph.D. thesis or postdoctoral projects.

  Figure 9.1: Global architecture of the OMMA framework.

Figure 9 . 2 :

 92 Figure 9.2: Example of an implementation of OMMA where we can see its modularity

Figure 9

 9 Figure 9.3: ROC curves (PFA vs. PD) representing the results from automatic Morwilog. Each point is the average of the result of 50 simulations with the parameters in Table6.1 and P tree = 0.5, P jump = 0.1. The size of the dataset is indicated next to the points. L is the length of injected sequences.

Figure 9 . 4 :

 94 Figure 9.4: Example of transitive reduction of a graph. Source: Wikimedia Commons

  Figure 9.5: Similarity-based graph of alerts related to LLDoS 1.0. Representation made in Cytoscape (https://cytoscape.org/).

  g

Figure F. 2 :

 2 Figure F.2: Functional representation of AASG Mill-1. Presented in page 178.





Figure F. 5 :

 5 Figure F.5: Formal representation of AAGS S2A. Presented in page 189.

Figure 1 -

 1 Figure 1 -Représentation des traces

Figure 2 -

 2 Figure 2 -Une séquence d'actions appartenant à WannaCry.

Figure 3 -

 3 Figure 3 -Distribution des publications par le type des éxperiences.

  Comme example de modélisation des hypothèses et d'AASG on va prendre l'attaque contenue dans le dataset ISCX, représenté dans la Figure 4. Dans cette attaque, l'attaquant commence par capturer un des ordinateurs du réseau pour après sauter dans un autre. Depuis cette deuxième machine, un scan est fait contre le réseau de serveurs interne. Une fois la cible finale est trouvé, un SQL injection permets l'accès à la machine et l'accès est consolidé par l'installation d'un backdoor.

Figure 4 -

 4 Figure 4 -Attaque UNB ISCX island-hopping [Zargar 2014].

Figure 6 -

 6 Figure 6 -AASG S2A (représentation fonctionnelle).

Figure 7 -

 7 Figure 7 -Exemple AASG dans le format JSON.

Figure 8 -

 8 Figure 8 -Exemple de la convergence des fourmis au chemin le plus court.

Figure 9 -

 9 Figure 9 -Événements dans le hypothèses sur WannaCry.

⌧0⌧0⌧0⌧0Figure 10 -

 10 Figure 10 -Exemple de fonctionnement de Morwilog.

⌧0Figure 11 -

 11 Figure 11 -Exemple d'évolution de l'AASG si la séquence est confirmée comme attaque.

Figure 14 -

 14 Figure 13 -Comparaison entre un AASG utilisé par Morwilog et un AASG Bayésien, qui codent la même information

Figure 16 -

 16 Figure 16 -Graphe fourni par l'algorithme TDA et utilisé dans l'exemple de SimSC.

Figure 17 -

 17 Figure 17 -SimSC sur le noeud 4 de la Figure 16.

Figure 18 -

 18 Figure 18 -SimSC sur le noeud 6 de la Figure 16.

Figure 19 -

 19 Figure 19 -Vue globale d'une analyse de SimSC dans l'implémentation Logan.

Figure 20 -

 20 Figure 20 -Test de scripts par un utilisateur malveillant détecté en utilisant Logan (SimSC)

  Firewall 09:10:54 Successful connection in port TCP 445 from h A to h B

	1.2. Goals		3
	Event Asset	Time	Description
	e 0	Proxy	09:10:34	Unsuccessful HTTP request from a host h A to long domain name D 1
	e 1	Proxy	09:10:42 Successful HTTP request to long domain name D 2
	e 2
	e 3	Endpoint h B 09:11:04	Malformed SMB headers for the NEGOTIATE PRO-TOCOL REQUEST from h A to h B
	e 4	Proxy	09:11:28 Successful HTTP request to long domain name D 2
	e 5	IDS	09:11:40 SQL injection alert coming from h A
	e 6	Firewall	09:12:38	SMBv1 communication between h A and h B using com-mand 'transaction2_secondary'

Table 2 .

 2 1: 2017 dwell time values of attacks according to different sources.

  CVE-2008CVE- -2992 in Adobe Reader for opening a reverse TCP shell on port 555. 2. Reverse TCP shell. One of the users, user5 in the host with IP address 192.168.1.105, opens the file and get her machine infected. A remote connection with the attacker is established. Vulnerability exploitation. A host user12 running Windows XP SP1 with a vulnerable SMB authentication protocol on port 445 is identified. The vulnerability (CVE

	4.
	3. Nmap scan. From user5 3 , the attacker launches a network scan using the
	program Nmap on subnets 192.168.1.0/24 and 192.168.2.0/24.

Table 3

 3

	.1: Inherent attributes considered by Pei et al. [Pei 2016] when modeling
	multi-step attacks.

  One of the selected metrics is the number of publications per year. It is represented in aggregated form in the histogram of Figure4.3 and separated by approach in Figure4.4. We see that the publication activity has been more or less constant during the years, giving an average of around 10 published papers about multi-step attack detection per year. This amount is not too high if we compare it with the total number of publications about Cybersecurity. Only in Springer 2 , 5,822 conference papers about Cybersecurity were published in 2018. If we filter by the same year in Google Scholar,

					Similarity-based
	Number of papers				Causal correlation Structural-based Case-based
					Mixed
	2002	2006	2010	2014	2018
			Year
	around 7,230 results are returned when searching for "intrusion detection", and 3,560
	when searching for "attack detection" 3 . It seems clear that multi-step attack detection

  The first indicator of this is the high number of proposed methods, 138, in only 201 publications. This means that almost 70% of the publications propose a new method instead of working in the improvement of existent ones.

	92	Chapter 4. Multi-step attack detection
	Ref.	Title	Year	Cit.
	[Cuppens 2002c]	Alert correlation in a cooperative intrusion detection framework	2002	978
	[Valdes 2001]	Probabilistic alert correlation	2001	961
	[Ning 2002c]	Constructing attack scenarios through correlation of intrusion alerts	2002	693
	[Julisch 2003a]	Clustering intrusion detection alarms to support root cause analysis	2003	543
	[Valeur 2004]	Comprehensive approach to intrusion detection alert correlation	2004	542
	[Eckmann 2002]	STATL: An attack language for state-based intrusion detection	2002	514
	[Cuppens 2001]	Managing Alerts in a Multi-Intrusion Detection Environment	2001	379
	[Ning 2004a]	Techniques and tools for analyzing intrusion alerts	2004	376
	[Dain 2001b]	Fusing a heterogeneous alert stream into scenarios	2001	349
	[Julisch 2002]	Mining intrusion detection alarms for actionable knowledge	2002	348
	[Cheung 2003]	Modeling multistep cyber attacks for scenario recognition	2003	309
	[Qin 2003]	Statistical causality analysis of infosec alert data	2003	280
	[Julisch 2001]	Mining alarm clusters to improve alarm handling efficiency	2001	247
	[Morin 2003]	Correlation of intrusion symptoms: an application of chronicles	2003	239
	[Ning 2003b]	Learning attack strategies from intrusion alerts	2003	237
	[Wang 2006e]	Using attack graphs for correlating, hypothesizing, and predicting intrusion alerts	2006	229
	[Ning 2002b]	Analyzing intensive intrusion alerts via correlation	2002	228
	[Qin 2004]	Attack Plan Recognition and Prediction Using Causal Networks	2004	213
	[Geib 2001]	Plan recognition in intrusion detection systems	2001	206
	[Ning 2004c]	Building Attack Scenarios through Integration of Complementary Alert Correlation Method	2004	200

Table 4

 4

.1: Top 20 entries according to the number of citations in Google Scholar. 117 out of 138 methods are so far considered only in one publication, with no further continuity.

Table 4

 4

.2: Ranking of top authors according to the number of publications about multi-step attack detection included in the survey.

  Distribution of publications by the type of data for experiments.

	Public dataset
		54.7%
			3.5%
			No experiments
			7.5%
		20.4%	Attack example
			13.9%
	Private dataset
			Simulated data
	Figure 4.5: Type of Trace	Number of pub.	Approaches
	Only alerts	172	All types
	General events	22	Similarity-based, mixed, case-based and causal correlation
	Traces with triggering alerts 5	Similarity-based and causal correlation
	Packets	2	Case-based and causal correlation

Table 4

 4

.3: Types of trace and number of publications using them.

  Contents 5.1 From Concrete to Abstract ASG . . . . . . . . . . . . . . . . . 104

5.2 Definition of AASG . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.3 Creating Abstract Attack Scenario Graphs . . . . . . . . . . . 124 5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Table 5 .

 5 2: Alerts from DARPA 2000 representing the infection of Mill 1. The analyst clearly sees that the attack started with a phase for checking if the sadmind daemon is installed in Mill (alert 'Sadmind_Ping', 67286). It is also clear for her that the culmination of the infection is the installation of the mstream daemon, whose communications are captured by the alerts of type 'Mstream_Zombie' (67537, 67767, 67776 and 67777). The AASG should then have the identification of 'Sadmind_Ping' in the first node ( 0 ) and that of 'Mstream_Zombie' in the last one.

	id	time	ipsrc	psrc	ipdst	pdst	type
		10/11 04:46:23	202.77.162.213	54792	172.16.115.20	32773	Admind
		10/11 04:46:23	202.77.162.213	54792	172.16.115.20	32773	Sadmind_Ping
		10/11 05:07:25	135.8.60.182	46847	172.16.115.20	25	Email_Ehlo
		10/11 05:11:27	202.77.162.213	60251	172.16.115.20	32773	Admind
		10/11 05:11:27	202.77.162.213	60251	172.16.115.20	32773	Sadmind_AO
		10/11 05:11:29	202.77.162.213	60255	172.16.115.20	32773	Admind
		10/11 05:11:29	202.77.162.213	60255	172.16.115.20	32773	Sadmind_AO
		10/11 05:11:35	202.77.162.213	60269	172.16.115.20	32773	Sadmind_AO
		10/11 05:11:35	202.77.162.213	60269	172.16.115.20	32773	Admind
		10/11 05:11:37	202.77.162.213	60276	172.16.115.20	32773	Admind
		10/11 05:11:37	202.77.162.213	60276	172.16.115.20	32773	Sadmind_AO
		10/11 05:11:43	202.77.162.213	60289	172.16.115.20	32773	Admind
		10/11 05:11:43	202.77.162.213	60289	172.16.115.20	32773	Sadmind_AO
		10/11 05:11:45	202.77.162.213	60300	172.16.115.20	32773	Sadmind_AO
		10/11 05:11:45	202.77.162.213	60300	172.16.115.20	32773	Admind
		10/11 05:21:29	197.182.91.233	47288	172.16.115.20	23	TelnetTermtype
		10/11 05:28:18	172.16.115.20	1023	202.77.162.213	514	Rsh
		10/11 05:28:18	172.16.115.20	1022	202.77.162.213	514	Rsh
		10/11 05:28:20	172.16.115.20	1022	202.77.162.213	514	Rsh
		10/11 05:28:20	172.16.115.20	1022	202.77.162.213	514	Rsh
		10/11 05:28:21	172.16.115.20	1021	202.77.162.213	514	Rsh
		10/11 05:28:22	172.16.115.20	1021	202.77.162.213	514	Rsh
		10/11 05:28:23	202.77.162.213	1023	172.16.115.20	514	Rsh
		10/11 05:28:37	172.16.115.20	33786	255.255.255.255	9325	Mstream_Zombie
		10/11 05:28:37	202.77.162.213	1023	172.16.115.20	514	Rsh
		10/11 05:59:11	195.73.151.50	49054	172.16.115.20	23	TelnetTermtype
		10/11 06:04:32	202.77.162.213	49212	172.16.115.20	23	TelnetTermtype
		10/11 06:04:32	202.77.162.213	49212	172.16.115.20	23	TelnetXdisplay
		10/11 06:04:32	202.77.162.213	49212	172.16.115.20	23	TelnetEnvAll
		10/11 06:05:25	172.16.115.20	33799	255.255.255.255	9325	Mstream_Zombie
		10/11 06:06:07	172.16.115.20	33800	172.16.112.50	7983	Mstream_Zombie
		10/11 06:06:07	172.16.115.20	33800	172.16.112.10	7983	Mstream_Zombie
		10/11 06:15:42	196.227.33.189	49619	172.16.115.20	23	TelnetTermtype
		10/11 06:46:15	194.7.248.153	51115	172.16.115.20	23	TelnetTermtype
		10/11 06:48:07	197.182.91.233	51220	172.16.115.20	23	TelnetTermtype
		10/11 06:59:53	196.37.75.158	51923	172.16.115.20	23	TelnetTermtype
		10/11 07:08:49	172.16.112.50	33488	172.16.115.20	23	TelnetTermtype

  Each time a suspicious event e i arrives at Morwilog, a morwi is generated and it looks for the AASG, if there is any, whose root node  0 matches the event. In this case, the chosen AASG is u .

	Level	Node	Matched event	Origin
	0	 0	Unsuccessful HTTP request from a host, called A, to long do-	Proxy
			main name D 1
	1	 1	Successful connection in port TCP 445 from A to any another	Internal firewall
			endpoint (B) in the local network
	1	 2	Successful HTTP request to long domain name D 2	Proxy
	2	 3	SMBv1 communication between A and other machine using	Internal Firewall
			command 'transaction2_secondary'
	2	 4	Malformed SMB headers for the NEGOTIATE PROTOCOL	Endpoint B
			REQUEST from A to B (CVE-2009-3103)
	2	 5	SQL Injection alert coming from A	IDS
	Table 6.2: Nodes in the example represented in Figure 6.2, containing the propagation
	steps in WannaCry
	a)

  Bidimac algorithm Require: E in ✓ E 1: for each e i in E in do Create thread BranchesSearch(E in , e i ) ⇤ . Launch search ⌫ i

	Morwilog and Bidimac	159
	Algorithm 6.3 2:
	3:

  then.  a has no children

	12:	isresult	true
	13:	end if
	14:	else
	15:	break
	16:	end if
	17:	end for
	18:

Table 6

 6

	#		Morwilog	Bay. ⌘ = 0.4 Bay. ⌘ = 0.6
		⌧ 0,1	⌧ 0,2	P 0,1 ✓ 0,1	✓ 0,2	✓ 0,1	✓ 0,2
	0	1000	1000	0.50 0.50 0.50	0.50 0.50
	1	1479.9 980	0.60 0.70 0.30	0.80 0.20
	2	1902.1 960.4 0.66 0.82 0.18	0.92 0.08
	3	2208.3 941.2 0.70 0.89 0.11	0.97 0.03
	4	2418	922.4 0.72 0.94 0.06	0.99 0.01
	5	2565.4 903.9 0.74 0.96 0.04	0.99 0.01
	6	2673	885.8 0.75 0.98 0.02	1	0
	7	2754.2 868.1 0.76 0.99 0.01	1	0
	8	2817.2 850.8 0.77 0.99 0.01	1	0
	9	2867	833.7 0.77 0.99 0.01	1	0
	10 2906.9 817.1 0.78 1	0	1	0
	Table 6.3: Pheromones and probability parameters for the case of continuous rein-
	forcement (parameters of Morwilog from Table 6.1)

.1) and Bidimac (⌘ = 0.4) with a simple AASG Figure

6

.11: Evolution of choosing probability P 0,1 in continuous reinforcement (example from Table

Table 7

 7

.2: Snort alerts in ISCX dataset.

Table 7 .

 7

3: Origins of logs in HuMa dataset.

Table 7

 7

	.8: Results of AASG S2A.

Table 7 .

 7 9: Execution time for Morwilog and Bidimac on the combinations of AASG and dataset used.

  SimSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 8.2 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 8.3 Raw-SimSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 "You see, but you do not observe." -Arthur Conan Doyle, A Scandal in Bohemia

	Chapter 8
	Visual investigation of attack
	scenarios
	Contents
	8.1

Table 8 .

 8 1: Regular expressions used for the extraction of timestamps.

  In Algorithm 8.1, the steps of this process are detailed in the form of pseudocode. SimSC Require:E in ✓ E ordered in time, T max , n ip Ensure: Graph G = (list_nodes, list_edges) if t b > 0 and t b t a < T max then 11: if A ip ✓ B ip or B ip ✓ A ip or |A \ B| n ip then

	206			Chapter 8. Visual investigation of attack scenarios
	Algorithm 8.1 1: list_nodes	E in
	2: list_edges 3: for each e i in E in do ;
	4:	A ip	Extracted IP addresses from e i
	5:	t a	min(Extracted timestamps from e i )
	6:	if t a > 0 then
	7: 8:	for each e j in E in |j > i do B ip Extracted IP addresses from e j
	9:		t b	min(Extracted timestamps from e j )
	10:
	12:			Append edge e i e j to list_edges
	13:			end if
	14:		else
	15:			Break
	16:		end if
	17:	end for
	18:	end if
	19: end for
	20: return G = (list_nodes, list_edges)

Table 8 .

 8 2: Shapes of nodes in Logan, according to the HTTP request.

  Table D.1: List of reviewed similarity-based multi-step attack detection methods in the category of progressive construction. Table D.4: List of reviewed multi-step attack detection methods based on causal correlation in the category of statistical inference.

	Total	cit.	379	247	348	543	79	14 15	11 1 1 11	25 0	0 14	130 9	0	0 4	1	1 2	12 1	18 0	9	0 17	9	0 2	7 41 6 25 5 72 0
	Datasets Knowledge extraction A m A d A k Rep. Attack model	Private Automatic Yes No -No No		Private Automatic Yes No -No Yes	DARPA 2000 Automatic Yes Yes -Yes Private No Private Automatic Yes No -No No	DARPA 2000 Manual Private Yes Yes Yes Yes Yes Simulation Automatic Yes No -No Yes	Private Automatic No No -No No DEFCON 18 Automatic No Yes -No Yes	DARPA 2000 Automatic Yes Yes -Yes Yes Private Automatic Yes No -No No	Private Automatic Yes No -No No	DARPA 2000 Manual Yes Yes Yes Yes Yes Private Automatic Yes No -No Yes	DARPA 2000 Supervised No Yes No No Yes Private Automatic Yes No -No Yes	DARPA 2000 Automatic Yes Yes -Yes Yes Simulation Automatic Yes No -No Simulation Automatic Yes No -DARPA 2000 Supervised Yes Yes No No Private Yes Private No DARPA 2000 Supervised Yes Yes Yes Yes No No No	Case study Automatic Yes No -No Yes Private Automatic Yes No -No No	Simulation Automatic Yes No -No Yes DARPA 2000 Supervised Yes Yes Yes Yes DARPA 2000 Automatic Yes Yes -Yes Yes Private Private Manual Yes No Yes No Simulation Simulation Automatic Yes No -No Supervised Yes No No No Yes Yes No No
	Type of	data	A		A		T A		A	A		T A	A A	A	A A	A A	A A	A	A	E	A E	E A A	E E	A
	Authors References Period	Cuppens [Cuppens 2001] 2001	[Julisch 2001]	Julisch [Julisch 2002] [Julisch 2003a] 2001-2003	[Julisch 2003b]	B. Chen et al. [Chen 2006] 2006 J. Wang et al. [Wang 2006a] 2006	Li Wang et al. [Wang 2006c] 2006-2010 [Murphy 2010] [Wang 2006d] Murphy et al. [Murphy 2009] 2009-2010 Colajanni, [Wang 2010] Marchetti and Shaneck et al. [Shaneck 2006] 2006 Manganiello Zhu and [Zhu 2006] Ghorbani 2006 [Colajanni 2010] [Manganiello 2011] 2010-2011 Qiao et al. [Qiao 2012] 2012 Zhang et al. AmirHaeri [AmirHaeri 2009] 2009 and R. Jalili [Zhang 2015] 2015 Kawakani et al. [Kawakani 2016] [Kawakani 2017] Khakpour [Khakpour 2009] 2009 and Jalili 2016-2017 Ghafir et al. Ebrahimi et al. [Ebrahimi 2011] 2011 [Ghafir 2018] de Alvarenga et al. [de Alvarenga 2018] 2018 2018	[Bateni 2013a] Haas and Fischer [Haas 2018] 2 0 1 8	Bateni et al. [Bateni 2013b] 2013-2014 Anming [Bateni 2014] and Chunfu [Brogi 2016] Brogi et al. [Brogi 2018] 2016 [Anming 2004] Mathew and Upadhyaya Pei et al. [Pei 2016] 2016 [Mathew 2009] Shin et al. C. Wang et al. [Wang 2016] 2016 [Shin 2013] Skopik, Hossain et al. [Hossain 2017] 2017 Friedberg et al. Tian et al. [Tian 2017] 2017 [Skopik 2014] [Friedberg 2015] 2004 2009 2013 2014-2015
	Category						Scenario clustering														Anomaly	detection

Table D.2: List of reviewed similarity-based multi-step attack detection methods in the categories of scenario clustering and anomaly detection.

  Table D.5: List of reviewed multi-step attack detection methods based on causal correlation in the category of statistical inference (cont'd).

	2	2	10	2	2 2	14	0	9	1	0	0	6	0	0	0	0	0
	NSA Automatic Yes Yes -Yes No		DARPA 2000 Supervised Yes Yes Yes Yes Yes		P r i v a t e A u t o m a t i c N o N o -N o N o	DARPA 2000 Supervised Yes Yes Yes Yes Yes	Private Automatic Yes No -No Yes	Private Manual Yes No Yes No Yes	DARPA 2000 Automatic Yes Yes -Yes Yes	DEFCON 9 Automatic Yes Yes -Yes DEFCON 19 No	DARPA 2000 Manual Simulation Yes Yes Yes Yes Yes	Simulation Manual Yes No Yes No Yes	Private Manual Yes No No No No	DARPA 2000 Automatic Yes Yes -Yes No	DARPA 2000 Manual Yes Yes Yes Yes Yes	Simulation Automatic Yes No No No Yes
	A		A		A	A	A	E	A	A	A	P	A	A	A	E
	2013		2014		2 0 1 4	2014	2015	2016	2016	2016	2017	2017	2018	2018	2018	2018
	[Brahmi 2013]	[Kholidy 2014a]	[Kholidy 2014b]	[Kholidy 2014c]	[Kim 2014]	[Xuewei 2014]	[Lv 2015]	[Chen 2016]	[Li 2016]	[Xian 2016]	[Zhang 2016]	[Holgado 2017]	[Jia 2017]	[Lu 2018]	[Saikia 2018]	[Shawly 2018]	[Sun 2018]
	Brahmi et al.		Kholidy et al.		Kim & Park	Xuewei et al.	Lv et al.	Chen et al.	Y. Li et al.	Zhang, Xian et al.	Holgado et al.	Jia and Xu	Lu et al.	Saikia et al.	Shawly et al.	Sun et al.

  .1: Formal representation of AASG Mill-1. Presented in page 128.

				Node 0
				EQL
				type
				"Sadmind_Ping"
	Node 1		Node 2
		SET			counter: 6
		type		EQL
	["Sadmind_Amslverify_Overflow",	type
	"Admind"]		"Sadmind_Amslverify_Overflow"
	SIM_EQL	SIM_EQL	SIM_EQL	SIM_EQL
	ipsrc		ipdst	ipsrc	ipdst
	ipsrc		ipdst	ipsrc	ipdst
	Node 3		Node 4
	SET type ["Sadmind_Amslverify_Overflow", "Admind"]	EQL type "TelnetTerminaltype"
	SIM_EQL	SIM_EQL	SIM_NEQ	SIM_EQL
	ipsrc	ipdst	type	ipdst
	ipsrc	ipdst	type	ipdst
	Node 5		Node 6
	EQL		SIM_EQL	EQL	SIM_EQL
	type		ipdst	type	ipsrc
	"Rsh"	ipdst	"Rsh"	ipdst
				Node 7
				optional: true
				EQL
				type
				"TelnetTerminaltype"
				SIM_COM	SIM_COM
				[ipsrc]	[ipdst]
				[ipsrc,ipdst]	[ipsrc,ipdst]	Node 9
	Node 8			EQL type
	EQL				"Mstream_Zombie"
	type
	"Mstream_Zombie"		EQL
					ipdst
	SIM_NEQ			"255.255.255.255"
	ipdst
	ipdst				SIM_COM
					[ipsrc]
					[ipsrc,ipdst]

  255.255.255.255) = 1 Figure F.3: Formal representation of AASG Mill-2. Presented in page 183.

	Node 0
	EQL
	type
	"Sadmind_Amslverify_Overflow"
	Node 5	Node 6
	SET	SET
	type	type
	["Rsh","FTP_Put"]	["Rsh","FTP_Put"]
	SIM_EQL	SIM_EQL
	ipdst	ipsrc
	ipdst	ipdst
	Node 8	Node 9
	EQL	EQL
	type	type
	"Mstream_Zombie"	"Mstream_Zombie"
	SIM_NEQ	EQL
	ipdst	ipdst
	ipdst	"255.255.255.255"
		SIM_COM
		[ipsrc]
		[ipsrc,ipdst]
	Figure F.

4: Functional representation of AASG Mill-2. Presented in page 184.

  Nous nous sommes focalisé sur un type spécifique de cyberattaque : les attaques multi-étapes. Ce terme désigne une cyberattaque composée de plusieurs phases ou actions di↵érentes, chacune représentée par une ou plusieurs événements. Les actions exactes des attaquants sont souvent di cile d'analyser quand on fait l'analyse d'attaques multi-étapes. Un des problèmes est que les actions qui composent une attaque multi-étapes n'ont pas nécessairement une corrélation causale forte avec les autres, et plusieurs combinaisons d'étapes sont possibles. Il y a aussi des actions qui peuvent sembler de faire partie de l'attaque mais qui ne sont pas des étapes fondamentales qui doivent se répéter dans une future occurrence de l'attaque.

			Node 0
			TXT		PFX
			type		ipdst
			"ICMP detected"	"192.168.0.0"
			0.3		0.45
			NEQ		NEQ
			ipsrc		ipsrc
			"192.168.5.122"	"192.168.5.123"
		Node 1			Node 2
		counter: 20			counter: 20
	SIM_EQL type type	SIM_PFX ipdst ipdst 0.75		SIM_EQL type type	SIM_EQL action action	SIM_NEQ service service
	SIM_EQL	SIM_NEQ	SIM_EQL	SIM_EQL	SIM_EQL
	ipsrc	ipdst		ipsrc	ipdst	psrc
	ipsrc	ipdst		ipsrc	ipdst	psrc
	Node 3		Node 5		Node 4
						counter: 20
	TXT	SIM_PFX	TXT	SIM_PFX	TXT	SIM_PFX
	type	ipdst	type		ipdst	type	ipdst
	"SQL" 0.1 1 Introduction ipdst 0.75	"EXPLOIT Attempt" 0.1	ipdst 0.75	"failure SSH" 0.5	ipdst 0.75
	SIM_EQL		SIM_EQL		SIM_EQL
	ipsrc			ipsrc		ipsrc
	ipsrc Dans un monde dans lequel les réseaux d'ordinateurs sont devenus indispen-ipsrc ipsrc
	sables dans le quotidien, une multitude de mécanismes ont été mises en place
	pour protéger ces réseaux des possibles cyberattaques. Ces mécanismes sont
	Node 6 basés sur l'utilisation d'outils et processus gérés par des analystes de sécurité Node 7 Node 8
	counter: 20 [Sundaramurthy 2015]. Une des sources d'information utilisées par l'analyste
	TXT type de sécurité vient des événements enregistrés par chaque dispositif, service ou SIM_PFX ipdst TXT type SIM_PFX ipdst TXT type SIM_PFX ipdst
	"SQL" 0.1 application du réseau. ipdst 0.75	"EXPLOIT Attempt" 0.1	ipdst 0.75	"failure SSH" 0.5	ipdst 0.75
	SIM_NEQ ipsrc ipsrc Dans ce thèse, nous nos sommes intéressé à la modélisation et identification SIM_NEQ ipsrc ipsrc SIM_NEQ ipsrc ipsrc des cyberattaques à partir de l'information contenue dans ces événements.
	La modélisation est le processus d'abstraction des conclusions déduites par
	l'analyste à partir d'un ensemble d'événement où les actions d'une attaque Figure F.6: Functional representation of AASG S2A. Presented in page 191. sont représentées. Le résultat de ce processus sont des modèles qui repré-
	sentent chacune des hypothèses posés par l'analyste. L'identification est la
	confirmation de ces modèles auprès de la arrivée de nouvelles attaques qui
	les correspondent. L'identification correcte de modèles est fondamentale pour
	éviter des attaques similaires dans le futur.
			1

  Ils sont l'unité minimale d'exchange d'information dans un protocol de communication.• Les événements. Ils sont des actions préservées dans les actifs du réseau dans un format de texte qui s'appelle log. Il y a un type spécial d'événements, les alertes, qui sont des événements qui signalent sur une action malveillante ou une faille.

		Traces
		Events
		E.g. Apache log
	Packets	recording a HTTP request
	E.g. TCP datagram containing part of a	Alerts
	Telnet connection	E.g. IDS log
		signaling a SQL
		Injection

• Les paquets.

Table 1 -

 1 Temps qui passe entre le début d'une cyberattaque et la découverte de l'intrusion (dwell time) pour l'année 2017.

	[Fire Eye 2018]	101 days of median dwell time
	[CrowdStrike 2018] 86 days of average dwell time
	[Trustwave 2018]	83 days of average dwell time

•

  Algorithmes pour la détection et l'identification de scénarios. Une autre contribution de cette thèse est la proposition de deux algorithmes pour faire la détection et l'identification d'attaques multiétapes en utilisant les AASGs : Morwilog et Bidimac. Dans les deux, l'analyste est directement impliqué dans le processus, en envoyant l'information sur la nature malicieuse des attaques détectés. Morwilog est un algorithme basé sur le comportement des fourmis où une fourmi artificielle, appelé morwi, est créé chaque fois qu'un événement qui correspond au noeud racine d'un AASG est detecté dans le système. En utilisant des niveaux de phéromones assignés à chaque arc du graphe, les morwis sont guidées vers la solution plus probable en termes d'historique du réseau. Une alerte est envoyée à l'analyste chaque fois qu'une morwi arrive à un noeud sans descendance, pour permettre l'apprentissage du système à partir de l'information donnée par l'expert. D'autre part, Bidimac est une adaptation des méthodes classiques d'inférence bayésienne. Le graphe devient un AASG bayésien, avec des paramètres de probabilité assignés à chaque arc. Vu le caractère nouveau des AASGs, Bidimac o↵re une façon de comparer Morwilog avec une méthode bayésienne classique. • Investigation visuel des scénarios d'attaques. Nous proposons une contribution additionnelle qui contribue au contexte de notre recherche principale. Cette contribution est SimSC, un modèle pour l'identification de scénarios d'attaques dans des sous-ensembles de logs de formats hétérogènes. Il est basé sur la similarité entre les adresses IP, en prenant en compte la distance temporelle entre les logs.

  Par contre, nous avons remarqué qu'il existe trop peu des set de données publiques. En plus, la plupart des publications utilisent le set DARPA 2000, qu'il a été crée il y a 19 ans.

	Public dataset
	54.7%
		3.5%	No experiments
		7.5%
	20.4%	13.9%	Attack example
	Private dataset	Simulated data

Table 2 -

 2 Fonctions utilisées pour le développement des événements abstraits dans les AASGs.

  • Un set de comparaisons à faire (« e star ») pour identifier ce noeud à une classe de logs. Par défaut les comparaisons sont faites par égalité. Le pair champ/value (« field » et « value ») in-

			Node 0
			TXT		PFX
			type		ipdst
			"ICMP detected"	"192.168.0.0"
			0.3		0.45
			NEQ		NEQ
			ipsrc		ipsrc
			"192.168.5.122"	"192.168.5.123"
		Node 1			Node 2
		counter: 20			counter: 20
	SIM_EQL type type	SIM_PFX ipdst ipdst 0.75		SIM_EQL type type	SIM_EQL action action	SIM_NEQ service service
	SIM_EQL	SIM_NEQ	SIM_EQL	SIM_EQL	SIM_EQL
	ipsrc	ipdst		ipsrc	ipdst	psrc
	ipsrc	ipdst		ipsrc	ipdst	psrc
	Node 3		Node 5		Node 4
						counter: 20
	TXT	SIM_PFX	TXT	SIM_PFX	TXT	SIM_PFX
	type	ipdst	type		ipdst	type	ipdst
	"SQL"	ipdst	"EXPLOIT Attempt"	ipdst	"failure SSH"	ipdst
	0.1	0.75	0.1		0.75	0.5	0.75
	SIM_EQL		SIM_EQL		SIM_EQL
	ipsrc			ipsrc		ipsrc
	ipsrc			ipsrc		ipsrc
	Node 6		Node 8		Node 7
						counter: 20
	TXT	SIM_PFX	TXT	SIM_PFX	TXT	SIM_PFX
	type	ipdst	type		ipdst	type	ipdst
	"SQL"	ipdst	"EXPLOIT Attempt"	ipdst	"failure SSH"	ipdst
	0.1	0.75	0.1		0.75	0.5	0.75
	SIM_NEQ		SIM_NEQ		SIM_NEQ
	ipsrc			ipsrc		ipsrc
	ipsrc			ipsrc		ipsrc

•

  Navarro, J. ; Deruyver, A. & Parrend, P. A systematic survey on multi-step attack detection. Computers & Security, Elsevier, 2018, 76, 214-249 • Navarro, J. ; Legrand, V. ; Deruyver, A. & Parrend, P. OMMA : open architecture for Operator-guided Monitoring of Multistep Attacks. EURASIP Journal on Information Security, Nature Publishing Group, 2018, 2018, 6 • Parrend, P. ; Navarro, J. ; Guigou, F. ; Deruyver, A. & Collet, P. Foundations and applications of artificial Intelligence for zero-day

We abbreviate it as 'attack' from this point onwards.

We use the term 'alarms' to denote the alerts generated by the methods proposed by us. This allows the distinction with other types of alert, which could even be part of the input of the methods (see section 2.3)

http://www.huma-project.org/

It considers elements from the definitions given by the US Committee on National Security Systems (CNSS) [CNSS 2015], the US Federal Financial Institutions Examination Council (FFIEC) [FFIEC 2018] and the ISO/IED 27000 standard [ISO/IEC 2016]

The full name of each organization can be found in Appendix B.

• Packet. It is the minimal unit of data exchanged in a network communication protocol. In Cybersecurity, the word network is usually preceding the term to

In this thesis, the term 'alarm' is exclusively used to denote an alert generated by Morwilog and Bidimac (see Chapter

6).

Do not confound a targeted multi-step attack with one using targeted malware, the one specifically programmed against the victim. A multi-step attack can be targeted even if standard software is used.

https://www.theverge.com/2017/5/13/15635050/wannacry-ransomware-kill-switch-protect-nhsattack

Even if it is an abuse of language, we allow ourselves this identification of hosts by a user name to ease the explanation

This represents a real alertin DARPA 2000 (see Table

5.2)

The fact that the cited authors employ hyper-alerts instead of the original traces for the nodes of the graph is not important for the global idea of the model.

The properties given by Chen et al. for non-normalized functions are adapted here to incorporate their idea of normalized function presented later in their paper.

Remember that ⇥ is the set of all possible traces (see section 2.3, page 17)

• Common element. Given a list of attributes for each trace, this similarity function is 1 only if there is at least one attribute value in common between the sets of selected attributes of each trace, and 0 otherwise:

• Textual similarity. A similarity function can be based on some standard

From https://www.journals.elsevier.com/computers-and-security (Checked the 13 January

2019).

https://link.springer.com/

The lack of an API in this platform allowing a high number of requests has forced us to program a Python script where each request follows the previous one after a random interval of time, to avoid being blocked by Google

Methods using "traces with triggering alerts" are those ones where alerts are used to identify the presence of the attack and other traces are incorporated then to complete the detection process.

L'humain au coeur de l'analyse de données massives pour la sécurité in French

Not to be confounded with the traces considered in this thesis (see section

2.3)

We change the name to also make it a noun, like the others.

RealSecure is a brand of IDS, used by many authors in the extraction of alerts in DARPA 2000[Ning 2004a, Zhu 2006[START_REF] Yu | [END_REF][START_REF] Liu | [END_REF][START_REF] Sadoddin | [END_REF][START_REF] Farhadi | [END_REF][START_REF] Anbarestani | [END_REF][START_REF] Kavousi | [END_REF], Ramaki 2015a, Faraji Daneshgar 2016] (see section 7.1.1)

https://www.alienvault.com/products/ossim

We imagine that the example is built on one of the first instances of WannaCry, before its details were disclosed to the public

We write an event e in bold characters to distinguish it from its individual components, not written in bold, adopting the same notation used for mathematical vectors. However, in cases where this ambiguity does not exist, we write e, not using the bold font. We adopt the same formalism for abstract events e ⇤ .

Notice that this rule considers that the attacker could change its IP address.

https://cytoscape.org/

http://seclists.org/fulldisclosure/2009/Sep/39

https://github.com/splunk/eventgen

To simplify, we refer to the 'infection of machine X' as 'X'.

The Common Vulnerability Scoring System (CVSS) is a standard to scoring vulnerabilities in computer networks[Mell

2007].

https://genida.unistra.fr/

https://ensourced.wordpress.com/2011/02/25/zmeu-attacks-some-basicforensic/

http://www.mlsecproject.org/blog/the-importanceof-good-labels-insecurity-datasets

• Datasets are loaded event per event, in order, simulating the incoming events in a real environment.• Even if each search process (the journey of a morwi in the case of Morwilog)

Acknowledgements

Step 1 Concept Assignation

Step 2 INRIA TDA ture [START_REF] Navarro | [END_REF]]: assignation of vulnerability-based concepts and Topological Data Analysis (TDA). The first step (Step 1) consists on the extraction from the logs of general concepts based on the CVSS code 1 . The catalog of concepts and the automatic process for assigning them to the logs have been developed by one of the industrial partners of the HuMa project. Their details must thus be kept confidential. The output of this process is the same list of raw logs from the input with several abstract concepts appended to each log as additional attributes. Logs related to similar vulnerabilities share similar concepts.

HuMa-SimSC

This output is then processed using an implementation of TDA (Step 2) developed by a research team based at the INRIA (French Institute for Research in Computer Science and Automation) in Nancy (France) [START_REF] Coudriau | [END_REF]]. The objective of TDA

Summary of definitions

In this appendix we collect the definitions of basic terms as they are used in this thesis. Most of the terms were defined in Chapter 2.

AASG (Abstract Attack Scenario Graph): A DAG for representing alternative hypotheses of multi-step attacks. Each step is represented as a node in the graph, containing an abstract event. More information in Chapter 5.

Accountability: Referring to a system, the property of guaranteeing that actions performed by each user can be traced uniquely to that user.

Advanced Persistent Threat (APT): Also called complex attack or targeted attack, it is a type of multi-step attack that is specifically crafted against a single victim and where the access of the attacker to the target network is maintained during a long period of time.

Alert: An event generated by a security system in response to the detection of alleged malicious activities or faults [START_REF] Salah | A model-based survey of alert correlation techniques[END_REF]].

Analyst: As it is used in this thesis, a cybersecurity expert in charge of the analysis and evaluation of potential threats, of the development of detection signatures and of the actions to be taken in the organization when an attack is detected.

Asset: A piece of data, a service, a system capability (processing power or bandwidth, for example) or an item of system equipment (software or hardware) being part of or connected to a computer network [Stallings 2015].

Attack: In the context of this thesis, a cyberattack.

Attack graph: An abstract representation of the network with each node representing an asset with a set of associated vulnerabilities.

Attack scenario:

In the context of this thesis, a multi-step attack.

Attacker:

The agent or set of agents performing a cyberattack, i.e. the author or the set of authors of the actions involved.

Availability: Referring to a system, the property of guaranteeing access only to authorized users at any moment in a timely manner.

CASG (Concrete Attack Scenario Graph):

A DAG that represents a multi-step attack, with the nodes corresponding to the traces describing each step of the attack. See section 3.3.3.

Confidentiality: Referring to a system, the property of ensuring that information contained in that system is disclosed only to authorized users.

Cyberattack: A set of actions, via cyberspace, targeting an organization's use of computer networks for the purpose of disrupting, disabling, destroying, exposing or controlling without authorization a computing environment/infrastructure; or destroying, modifying or stealing data or blocking the access to it [CNSS 2015, ISO/IEC 2016, FFIEC 2018].

Cybersecurity:

The organization and collection of resources, processes, and structures used to protect cyberspace, cyberspace-enabled systems and the information contained on them from intentional cyberspace-based actions that compromise their confidentiality, integrity and availability.

Cyberspace: The notional environment in which communication over computer networks occurs [OED 2018b].

Defender: Entity responsible of preserving the target system against potential attackers and, if these last ones are successful in their attempts, of detecting the attack and mitigate its effects.

Device: An term equivalent to 'asset'.

Distributed attack: See 'multi-agent attack'.

Event: A trace corresponding to an identifiable action that happens on an asset. It is preserved as a line of text called log.

Evidence set: The ensemble of traces collected by any asset of the network containing information about any of the steps composing a multi-step attack. It can be homogeneous, if all the traces contained in it have the same format, or heterogeneous, if there are at least two different formats.

Extrinsic attribute: An attribute of a trace that is determined by the place of the trace among a set of traces. E.g. the probability of having a trace of the same type generated in a period of 5 seconds.

Hyper-trace: An abstract entity containing an aggregated set of traces.

Inherent attribute: An attribute of a trace that is fully determined by the information contained in the trace. E.g. the name of the machine generating the trace. See Appendix C for a full list of the inherent attributes mentioned in this thesis.

Integrity: Referring to a system, the property of ensuring that assets or messages exchanged between users of that system can only be modified in a specified and authorized way.

Intrusion Detection System (IDS): A piece of software or hardware conceived to automate the attack detection process.

Known attack: A cyberattack that has been widely detected, analyzed and understood by the security industry, so prevention mechanisms against it can be effectively deployed and a signature characterizing it could be developed for its detection. Known vulnerability: A vulnerability which the defender is aware of and whose exploitation can be prevented by the development of specific security mechanisms.

Laundering host: See 'stepping stone'.

Log: A representation of an event in text.

Multi-agent attack: An attack concurrently executed by more than one attacker. They are also called 'distributed' or 'coordinated' attacks.

Multi-step attack: A cyberattack composed of at least two distinct actions or steps. Also called by many alternative names: multi-stage attacks, multistage attacks, attack strategies, attack plans, attack scenarios or attack sessions.

Packet: The minimal unit of data exchanged in a network communication protocol. It can be preserved as a trace.

Parsed log: A log that has been preprocessed in order to make its attributes distinguishable, transformed into a format suitable for security analysis.

Path: In a CASG or an AASG, a finite alternating sequence of nodes and arcs with all of them distinct.

Raw log: A log in its original format as it is generated by the asset, in plain text.

Single-step attack:

A cyberattack where just one action, possibly repeated, is required to threaten the system.

Step: In a computer network, each one of the actions being part of the same multi-step attack.

Stepping stone: In a multi-step attack, an asset attacked and controlled by the attacker as a intermediary step in the consecution of her goal. It is also called a laundering host.

Structural information: In a computer network, the information that can obtained supposing that no traffic is exchanged between any of the assets. Some examples of structural information are the characteristics of each asset, the vulnerabilities or the network configuration.

Trace: A preserved piece of information about actions performed within a computer network.

Unknown attack: A cyberattack that relies on the exploitation of unknown vulnerabilities or on ways of access that were not considered as such by the defender.

Unknown vulnerability: A vulnerability not found yet by the defender but whose existence is assumed when deploying the defenses of the organization.

Vulnerability: A flaw or weakness in the design or implementation of a piece of software or hardware that can be exploited by an attacker to perform an unauthorized action [Stallings 2015, Duffany 2018].

List of acronyms

• AASG. Abstract Attack Scenario Graph

List of inherent attributes

The reader can find below the list of inherent attributes from traces used throughout this thesis. The names have been chosen to be intuitively understood. A brief description is shown next to them. We have chosen not to list here the attributes proposed by Pei et al. [START_REF][END_REF]] and listed in Table 3.1, as they are not used in any other part of this thesis.

• action -Type of action associated to the trace.

• dom -Internet domain name.

• id -Identifier of the trace.

• inobj -Input object.

• ipdst -Destination IP address.

• ipsrc -Source IP address.

• log -The original raw trace.

• macdst -Destination MAC address.

• macsrc -Source MAC address.

• origin -Device generating the trace.

• outobj -Output object.

• pdst -Destination port number.

• process_id -Identifier of the OS process related to the trace.

• psrc -Source port number.

• service -Service associated to the trace.

• tag -Indication of the malicious nature of the trace (label).

• time -Timestamp.

• type -Type of the trace.

Appendix D

Multi-step attack detection methods

In this Appendix we present several tables with information about the methods reviewed in Chapter 4. We include information about the type of data used by the methods as presented in section 4.4.2 for further details: 'A' stands for only alerts; 'E', for events; 'P', for packets, and 'T' indicates that alerts are used in triggering the detection process but other traces like events or packets are used in the identification of the steps. Moreover, we show the type of dataset used in the experiments, also indicating when a private dataset is used ('Private'), when there is just an attack example ('Case study'), when there is a simulation with data expressly created for the experiment ('Simulation') and when there are no experiments ('No exp.'). We also indicate how the knowledge about the attacks is extracted ('Automatic', 'Manual' or 'Supervised', as in section 4.4.2) under the column 'Knowledge extraction'. Regarding reproducibility, we indicate if the method, the data and the models are accessible ('A m ','A d ','A k ', respectively), if the experiments are reproducible ('Rep.') and if the model of an example attack is provided (see section 4.4.3). Finally, the last column show the total number of citations of the publications presenting the method ('Total cit.'), extracted from Google Scholar. Appendix E

Summary of AASG conditions

Type Name of function Short name Formula

Absolute conditions

Table E.1: Functions used in the definition of the abstract events in the AASGs.

Appendix F

Examples of AASGs

Throughout this thesis, we have worked with three examples of AASG: Mill-1, Mill-2 and S2A. The first two were intended to be applied to the dataset DARPA 2000, while S2A has been conceived for both ISCX and HuMa. In this appendix, the formal and functional representations of the three mentioned AASGs are gathered together.

Julio NAVARRO Modelization and Identification of Multi-step Cyberattacks in Sets of Events

Résumé

Une cyberattaque est considerée comme multi-étapes si elle est composée d'au moins deux actions différentes. L'objectif principal de cette thèse est aider l'analyste de sécurité dans la création de modèles de détection à partir d'un ensemble de cas alternatifs d'attaques multi-étapes. Pour répondre à cet objectif, nous présentons quattre contributions de recherche. D'abord, nous avons réalisé la première bibliographie systématique sur la détection d'attaques multiétapes. Une des conclusions de cette bibliographie est la manque de méthodes pour confirmer les hypothèses formulées par l'analyste de sécurité pendant l'investigation des attaques multi-étapes passées.

Ça nous conduit à la deuxième de nos contributions, le graphe des scénarios d'attaques abstrait ou AASG. Dans un AASG, les propositions alternatives sur les étapes fondamentales d'une attaque sont répresentées comme des branches pour être évaluées avec l'arrivée de nouveaux événements.

Pour cette évaluation, nous proposons deux modèles, Morwilog et Bidimac, qui font de la détection au même temps que l'identification des hypothèses correctes. L'évaluation des résultats par l'analyste permet l'évolution des modèles.

Finalement, nous proposons un modèle pour l'investigation visuel des scénarios d'attaques sur des événements non traités. Ce modèle, qui s'appelle SimSC, est basé sur la similarité entre les adresses IP, en prenant en compte la distance temporelle entre les événements.

Mots-clés : Cybersécurité, attaque multi-étapes, correlation d'événements, détection d'attaques

Summary

A cyberattack is considered as multi-step if it is composed of at least two distinct actions. The main goal of this thesis is to help the security analyst in the creation of detection models from a set of alternative multi-step attack cases. To meet this goal, we present four research contributions.

First of all, we have conducted the first systematic survey about multi-step attack detection. One of the conclusions of this survey is the lack of methods to confirm the hypotheses formulated by the security analyst during the investigation of past multi-step attacks. This leads us to the second of our contributions, the Abstract Attack Scenario Graph or AASG. In an AASG, the alternative proposals about the fundamental steps in an attack are represented as branches to be evaluated on new incoming events.

For this evaluation, we propose two models, Morwilog and Bidimac, which perform detection and identification of correct hypotheses. The evaluation of the results by the analyst allows the evolution of the models.

Finally, we propose a model for the visual investigation of attack scenarios in non-processed events. This model, called SimSC, is based on IP address similarity, considering the temporal distance between the events. Comme c'est le premier algorithme développé pour travailler dans la détection et identification des hypothèses alternatives d'attaques multi-étapes, on n'a pas de références pour comparer. Ça nous a poussé à développer Bidimac, basé sur l'inference Bayésienne.

Step 1 Concept Assignation

Step 2 INRIA TDA faire évoluer les AASG, pour l'identification on a généré un set de datasets artificielles en utilisant Splunk Event Generator.

HuMa-SimSC

Investigation visuel des scénarios d'attaques

Une autre contribution développé dans le cadre de cette thèse est SimSC, un modèle qui sert pour l'investigation visuel des scénarios d'attaques.

SimSC pour HuMa

La version originale de SimSC travaille comme un « zoom » sur les noeuds des graphes crées par TDA, un des autres outils du projet HuMa, le projet qui a financé cette thèse. Ces graphes ont un ensemble de logs représentés dans chaque noeud. Deux noeuds sont liés s'ils ont au moins un log en commun.

Si l'analyste veut mieux explorer le contenu d'un noeud, il ou elle va le sélectionner et lancer l'outil SimSC (Figure 15). La sortie de SimSC est un graphe de comportement où chaque noeud représente un seul log.

On résume ici le processus suivi par SimSC pour la création de ces graphes de comportement. Deux logs sont liés s'ils ont un certain nombre d'adresses IP en commun et que la distance temporelle entre eux est sous un certain seuil. Ces relations entre logs permettent à l'expert de se focaliser dans des logs similaires, qui appartiennent au même scenario. Les logs qui appartiennent and multi-step attack detection. EURASIP Journal on Information Security, Nature Publishing Group, 2018, 4

Articles de conférence :