Gerardo Canfora

Eric Medvet

Francesco Mercaldo

Corrado Aaron Visaggio

Detection of Malicious Web Pages using System Calls Sequences

Web sites are often used for diffusing malware; an increasingly number of attacks are performed by delivering malicious code in web pages: drive-by download, malvertisement, rogueware, phishing are just the most common examples. In this scenario, JavaScript plays an important role, as it allows to insert code into the web page that will be executed on the client machine, letting the attacker to perform a plethora of actions which are necessary to successfully accomplish an attack. Existing techniques for detecting malicious JavaScript suffer from some limitations like: the capability of recognizing only known attacks, being tailored only to specific attacks, or being ineffective when appropriate evasion techniques are implemented by attackers. In this paper we propose to use system calls to detect malicious JavaScript. The main advantage is that capturing the system calls allows a description of the attack at a very high level of abstraction. On the one hand, this limits the evasion techniques which could succeed, and, on the other hand, produces a very high detection accuracy (96%), as experimentation demonstrated.

Introduction

In recent years, the web applications became an important vector of malware, as many reports state [START_REF]2013 threats predictions[END_REF]2]. A number of attacks are performed leveraging malicious web sites: drive-by-download, which consists of downloading and installing or running malware on the machine of the victim; csrf, which deviates the victim's navigation on a malicious web site; phishing, web sites which reproduce existing benign sites for obtaining credentials or other sensitive information from the victim; malvertisement, which is advertisement containing malware; malware serving, which collects traffic with different techniques and hosts malware; and rogueware, which is a fake antivirus which realizes illegal tasks, like stealing information or spying victim's machine.

Existing techniques may be very efficient in identifying specific and wellknown attacks [START_REF] Eshete | Effective analysis, characterization, and detection of malicious web pages[END_REF], but they often fail in detecting web threats which are new or scarcely diffused [START_REF] Micro | Web threats[END_REF]. Since the attackers know that the approaches for detecting attacks are usually successful only against some kinds of attacks, different combinations of attacks are mixed together in order to evade detection [START_REF] Eshete | Effective analysis, characterization, and detection of malicious web pages[END_REF].

Furthermore, the turbulent evolution of web technology entails a parallel evolution of web threats, which makes ineffective all those detecting techniques which are strictly based on the technology of the web pages, because they observe the behavior of only certain components or characteristics, neglecting others which may be exploited by attackers. The introduction of HTML5, for instance, is bearing new functions like inline multimedia and local storage, which could be leveraged for designing new attacks [START_REF] Weiss | Top 5 security threats in html5[END_REF], whose dynamics are not expected by current detectors.

A system for circumventing these hurdles is to analyze the web threats at a finer grain, which is the one of the operating system. The conjecture which we aim to demonstrate with this paper is that observing the behavior of a web application as the sequence of system calls invoked by the system when the browser connects to the web application makes the capability of detection independent of the specific web threat. This should result in a more effective detection system, which is able to exhibit a higher accuracy, i.e., reduce the number of false negatives and false positives. To observe the behavior of a web application at the level of system calls means decomposing at the smallest units of computation, or rather obtaining a very high level of abstraction of the code features.

The conjecture relies on the idea that a web application designed for performing an attack instead of performing some specific (and benign) business logic should show characteristics, in terms of sequence of system calls, which are common to many attacks, independently from the type of attack and its implementation. For instance, a malicious web application is often hosted on web server with poorer performances (often due to the fact that a malicious web application must frequently change hosting server because these servers are blacklisted) than a benign web application (which needs high speed server for business reasons). Moreover, benign web applications have a more complex structure than malicious web application, whose only purpose is to perform attacks and not to provide business services, several functions to user, or many pieces of information. This could cause, for instance, a fewer number of open system calls invoked by the malicious web application, than by the benign ones.

We wish to investigate whether malicious web applications and benign web applications differ in terms of the system calls they invoke. Thus, we pose two research questions:

-RQ1: is there a significant difference in the occurrences of system calls invoked by malicious and by trusted web applications? -RQ2: are there sequences of system calls which are more frequent in malicious web applications than in trusted web applications?

RQ1 aims at verifying whether malicious web applications have system calls with different occurrences of benign web applications. A similar finding was observed for malware, where some op-codes had a larger or smaller number of occurrences than in non-malware code [START_REF] Canfora | Static analysis for the detection of metamorphic computer viruses using repeated-instructions counting heuristics[END_REF]. RQ2 consists of exploring the possibility that specific sequences of system calls could characterize malicious web applications, i.e., are more (or less) frequent in malicious web applications than in benign ones. As data analysis demonstrates, both RQ1 and RQ2 have a positive answer.

The paper proceeds as follows: Section 2 analyses the related literature, Section 3 and 4 discuss experimentation and results obtained, respectively for RQ1 and RQ2, and, finally, Section 5 draws the conclusions.

Related work

A wealth of techniques exist to detect, prevent or characterize malicious activities carried on using web pages.

Blacklists collect malicious URLs, Ip addresses, and domain names obtained by manual reporting, honeyclients, and custom analysis service [START_REF] Eshete | Effective analysis, characterization, and detection of malicious web pages[END_REF]. Blacklisting requires trust by the users and a huge management effort for continuously updating the list and verifying the dependability of the information.

Heuristic-based techniques [START_REF] Dewald | Adsandbox: Sandboxing javascript to fight malicious websites[END_REF][START_REF] Seifert | Identification of malicious web pages with static heuristics[END_REF] leverage signatures of known malicious codes: if a known attack pattern is found within a web application, it is flagged as malicious. However, signatures can be successfully evaded by malicious codeobfuscation being the most commonly used technique. Moreover, this mechanism is not effective with unknown attacks.

Static Analysis techniques [9-12, 8, 13, 14] extract features from URL string, host identity, HTML, JavaScript code, and reputation metadata of the page. These values are entered in machine learning based classifiers which decide whether the web application is malicious or not. Obfuscated JavaScript, exploiting vulnerabilities in browser plug-ins and crafted URLs are common practices to evade this form of detection.

Dynamic analysis [START_REF] Kim | Suspicious malicious web site detection with strength analysis of a javascript obfuscation[END_REF][START_REF] Ikinci | Monkey-spider: Detecting malicious websites with low-interaction honeyclients[END_REF][START_REF] Kolbitsch | Rozzle: De-cloaking internet malware[END_REF][START_REF] Cova | Detection and analysis of drive-by-download attacks and malicious javascript code[END_REF][START_REF] Thomas | Design and evaluation of a real-time url spam filtering service[END_REF] observes the execution of the web application. Proxy-level analysis [START_REF] Moshchuk | Spyproxy: Execution-based detection of malicious web content[END_REF] captures suspicious behaviors, such as unusual process spawning, and repeated redirects. Sandboxing techniques [START_REF] Dewald | Adsandbox: Sandboxing javascript to fight malicious websites[END_REF][START_REF] Rieck | Cujo: efficient detection and prevention of drive-by-download attacks[END_REF] produce a log of actions and find for known patterns of attacks or unsual sequence of actions. Honeyclients [START_REF] Qassrawi | Detecting malicious web servers with honeyclients[END_REF] mimic a human visit in the website, but by using a dedicated sandbox. Execution traces and features are collected and analyzed to discover attacks. Low-interaction honeyclients [START_REF]The honeynet project[END_REF] compare the execution traces with a set of signatures, which makes this approach ineffective with zero-day attacks. High-interaction honeyclients [START_REF]Mitre honeyclient project[END_REF][START_REF]Capture-hpc client honeypot / honeyclient[END_REF][START_REF] Wang | Automated web patrol with strider honeymonkeys[END_REF] look for integrity changes of the system states, which means monitoring registry entries, file systems, processes, network connections, and physical resources (memory, CPU). Honeyclients are powerful, but at a high computational cost, as they need to load and execute the web application. Honeyclients are useless for time-based attacks, and, moreover, malicious server can blacklist honeyclients IP address, or they can be discovered by using Turing Test with CAPTCHAs [START_REF] Eshete | Effective analysis, characterization, and detection of malicious web pages[END_REF].

Different methods have been proposed for detecting and analyzing malicious Java script code. Zozzle [START_REF] Curtsinger | Zozzle: Low-overhead mostly static javascript malware detection[END_REF] extracts features of context from AST, such as specific variable names or code structure. Cujo [START_REF] Rieck | Cujo: efficient detection and prevention of drive-by-download attacks[END_REF] obtains q-grams from the execution of JavaScript and classifies them with machine learning algorithms. Code similarity is largely used to understand whether a program is malicious or not, by comparing the candidate JavaScript with a set of known malicious JavaScripts. Revolver [START_REF] Kapravelos | Revolver: An automated approach to the detection of evasive web-based malware[END_REF] computes the similarity by confronting the AST structure of two JavaScript pairs. Clone detection techniques have been proposed in some papers [START_REF] Pate | Clone evolution: a systematic review[END_REF][START_REF] Roy | A survey on software clone detection research[END_REF], but they assume that the programs under analysis do not show an adversarial behavior. Such an assumption does not hold when analyzing malicious programs. Attackers usually change the code corresponding to the payload taken form other existing malware for evading clone detection. Another strong limitation is the large number of source code the candidate code sample must be compared with. Bayer et al. [START_REF] Bayer | Scalable, behavior-based malware clustering[END_REF] intend to solve this problem by leveraging locality sensitive hashing, while Jong et al. [START_REF] Jang | Bitshred: feature hashing malware for scalable triage and semantic analysis[END_REF] make use of feature hashing for reducing the feature space.

At the best knowledge of the authors the method we propose is new in the realm of malicious JavaScript detectors, and its main advantages are: the success is independent from the type of attack, and it is designed to be robust against evasion techniques, as discussed later in the paper.

RQ1: system call occurrences

Data collection

We performed an experimental analysis aimed at investigating the point addressed by RQ1-i.e., whether a significant difference exists in the occurrences of system calls invoked by malicious and by trusted web applications. To this end, we composed a set including malicious and trusted web pages and recorded the system call traces which are generated while visiting them.

We chose at random more than 3000 URLs from the Malware Domain List3 archive: this archive contains about 80 000 URLs of malicious web pages implementing different attacks patterns. We chose the first 3000 URLs included in the Alexa Global Top Sites4 ranking for making up the set of trusted websites.

We then systematically visited each of these URLs and recorded the system calls traces. In order to collect system calls traces, we used Strace5 , which is a tool for Unix platform diagnostic and debugging. Strace hooks a running process and intercepts the system calls done by the process and register them within a log. Strace can be configured in two different modes: "verbose", which collects all the system calls of the target process with all the metadata, and "summary", which collects aggregated data, such as the number of calls for each system call, the total time required for the system call, the number of errors, the percentage of user time. We used Strace in "verbose" mode. We automated the collection procedure by means of a Java program which we built for performing the following steps-being u the URL for which the system call trace has to be collected:

1. launch Strace, configured to hook the Firefox process; 2. launch Firefox with u as the only URL to visit; 3. wait 60 s; 4. kill Firefox and Strace; 5. truncate the system call trace to the calls performed during the first 20 s.

We executed the collection procedure for all the URLs in a row, running the Java program on a machine hosted in our campus, provided with good and stable connectivity to the Internet.

We ensured that no errors were generated while visiting URLs. We excluded all those traces for which one of the following abnormal situation occurred: HTTP response codes 302 and 404, "unable to resolve host address" error and "connection time out" error. We stopped the collection after visiting exactly 3000 malicious and 3000 trusted pages.

Analysis

We denote with N the length of a system call trace and by N c the number of occurrences of the system call c within a trace.

We observed 106 different system calls. The average number N of system calls we collected for each URL was 114 000 and 76 710, respectively for trusted and malicious pages. We think that the difference is justified mainly by the different connectivity and processing power of servers serving trusted and malicious pages. In particular, malicious pages are often served by improvised web serverpossibly compromised machines which were not meant to act as servers-and hence with bad connectivity and low processing power. Despite the number of system calls in the 20 s trace might appear a good indicator of a page being malicious, it cannot be actually used alone as a discriminant, since it strongly depends on the setting of the client: client connectivity and processing power were tightly controlled in our data collection settings, but are likely to be more variable in a real scenario.

Concerning the number of occurrences of system calls, Table 1 shows the absolute occurrences N c and relative occurrences Nc N of the 10 most occurring (considering all traces) system calls, for trusted and malicious pages: for example, the futex call occurs on the average 12 895 times in each trusted trace, which corresponds to 11.36% of calls per trace. As expected, the absolute number of occurrences is in general greater for trusted pages. In relative terms, figures are similar for trusted and malicious pages, with some exceptions. The call gettimeofday is by far the most occurring across malicious pages: on the average, more than 1 3 of system calls are gettimeofday; this system call could be invoked for time-based attacks and logic bombs. On the other hand, for trusted pages, the most occurring call is clock gettime. This is likely to happen because, for a time-based attack, a temporal grain at level of a day is enough as temporal line after which the attack must be launched. The call clock gettime can be used by many common functions in current trusted websites: for instance in forums and social networks, the local clock time is commonly used to tag the published posts. Moreover the local clock time is used for web page dynamic updates (for instance this is typical in news websites), or for JavaScript timers bound to UI activieties, and so on. The call open seems to occur more frequently while visiting malicious web pages than trusted ones: 4.20% vs. 2.88%. This could be due to the fact that many kinds of attacks performed through web pages, as previously observed, consist of gathering private information from the victim's machine, obtaining the machine control, changing machine settings (e.g., DNS poisoning, registry modifications, password cracking, cookies, browser settings, and chronology retrieving), causing a denial of service, and so on. Figure 1 shows the comparison between relative occurrences of the 10 most occurring system calls for trusted and malicious pages, by means of a boxplot. It can be seen that no one of the considered calls can be taken as a discriminant between trusted and malicious pages, because values for all the considered pages overlap for the two categories. For example, despite being the mean value for the open call significantly lower for trusted pages (see Table 1), several trusted pages (at most 25%) exceed the mean value of the open relative occurrence within malicious pages. This happens because nowadays many web applications must implement very complex business goals (e-health, e-government, e-banking, e-commerce) which require a complex architecture, rich of files (images, animations, CSS sheets, JavaScripts), and complex functions, which need to have access to cookies, Internet files (chronology), local folders (for updating files), web services. In this case the number of files which need to be opened can be remarkably higher than the ones opened by many web-based attacks.

Finally, we analyzed the 10 system calls for which the absolute difference ∆ Nc N between the average relative occurrences in trusted and malicious page was the greatest. The rationale was to find those system calls which were the best candidate to be a good discriminant between trusted and malicious pages, regardless of being the calls rare or frequent. Table 2 lists the 10 system calls, along with the value of the difference in relative occurrences. It can be seen that 9 on 10 of the calls chosen with this procedure were also included in the set of the 10 most occurring calls (i.e., those of Table 1 and Figure 1): the only exception was the llseek call which took the place of the write call.

Classification

We tried to exploit the difference in relative occurrences of system calls to build a classifier able to discriminate between trusted and malicious pages. To this end, we defined a method consisting of a training phase and a classification phase.

In the training phase, we proceed as follows. Let T be a set of labeled traces (t, l), where l ∈ {trusted, malicious} is the label and t is the trace, i.e., a sequence of system calls. We build, for each trace t, a feature vector f ∈ [0, 1] 106 composed of all the system call relative occurrences, sorted alphabetically on the calls themselves. Then, we train a Support Vector Machine (SVM) on the feature vectors using the labels in T . We use a third-degree polynomial kernel with cost parameter set to 1.

In the classification phase, we simply obtain the feature vector f from the trace under analysis and then applied the learned SVM.

We assessed the effectiveness of the proposed classification method on the dataset D collected as described in Section 3.1, with the following procedure:

1. built a training set T ⊂ D by picking 2400 trusted traces and 2400 malicious traces; 2. built a testing set T = D \ T ; 3. run the training phase on T ; 4. applied the learned classifier on each element of T .

We performed a 5-fold cross validation, i.e., we repeated the four steps 5 times varying the composition of T (and hence of T ).

We measured the performance in terms of accuracy, False Negative Rate (FNR) and False Positive Rate (FPR), i.e., respectively, the percentage of T pages which were correctly classified, the percentage of malicious pages in T which were wrongly classified as trusted and the percentage of trusted pages in T which were wrongly classified as malicious.

We obtained a classification accuracy of 97.18%, averaged across the 5 repetitions, with a standard deviation σ = 0.44%; FPR and FNR were respectively equal to 3.5% and 2.13%. Although such results are good, it is fair to note that a detector based on the number of invocations of a (set of) system calls could be evaded easily: if the number of malicious system calls is expected to be smaller than trusted ones, the attackers should write junk code which does not alter the payload effect but increases the number of those system calls. On the contrary, if the number of malicious system call is expected to be greater than trusted ones, as the value which we are considering is calculated in percentage, it is sufficient to increase the total number of all the system calls, with junk code, as well.

RQ2: system calls sequences

Classification

In order to answer RQ2, we considered a classification method for discriminating between trusted and malicious pages which bases on (short) system calls sequences, rather than occurrences. Similarly to the former case, we considered two phases: training and classification.

In the training phase, which operates on a set of labeled traces T , we proceed as follows. We first compute, for each trace, a feature vector f of n-gram occurrences (with n = 3). Each feature corresponds to ratio between the number of times a given subsequence of 3 system calls occurs in t and the number of 3-grams in t (which is |t| -2). For example, if t = {execve, brk, access, mmap2, access, open, stat64, open, stat64, open}, then f (execve,brk,access

) = 1 8 , f (brk,access,mmap2) = 1 8 , . . . , f (open,stat64,open) = 2 8
, and so on. The number |C| 3 of possible features is large, being C the set of system calls-recall that in our experimentation |C| = 106. For the sake of tractability, we consider only those features for which the corresponding 3-gram occurs at least once in T : this way, we reduce the number of features in our experimentation to ≈ 43 000.

Then, we perform a two-steps feature selection procedure. We first select the 5% of features with the greatest absolute difference between the average value computed only on trusted sequences and the average value computed only on malicious sequences. Second, among the remaining features, we select the k features with the highest mutual information with the label l.

Finally, we train a Support Vector Machine (SVM) on the selected features using the labels in T . We use a third-degree polynomial kernel with cost parameter set to 1.

In the classification phase, we simply extract the selected features from the trace under analysis and then apply the learned SVM. Note that the actual extraction of the features in this phase-including the collection of the trace itself-can be computationally cheaper, since only those k subsequences of system calls have to be counted.

Experimental evaluation

We assessed the effectiveness of the proposed method on the same dataset and with the same procedure described in Section 3.3.

Table 3 shows the results of the experimental evaluation in terms of average value of accuracy, FNR and FPR across the 5 repetitions. It can be seen that our method is able to discriminate between trusted and malicious pages with an accuracy of 95.83% (k = 25): FNR and FPR are balanced, i.e., the method does not tend to misclassify one class of pages more than the other.

Moreover, results show that the best accuracy can be obtained with k = 25, but the method itself appears to be quite robust with respect to the parameter k. Considering that an actual implementation of our approach will benefit from low k values-since less data had to be recorded-the fact that the best accuracy can be obtained with k = 25 is a plus.

Results of Table 3 suggest that (i) the chosen features (3-gram occurrencies) are indeed informative for malicious pages detection, (ii) a large number of them do not provide any additional information-or the SVM classifier is not able to exploit it-and (iii) the proposed feature selection procedure allows to select the small fraction of features which allow an accurate classification.

For completeness of analysis, in Table 4 we show the 10 3-grams chosen with the feature selection procedure described in Section 4.1 in one repetition of our experimental evaluation-we verified that the list composition was stable 1), nor by the criterion on difference in relative occurrences (see Table 2). This is the case of, e.g., fstat64 and set robust list. This happens because some system calls fall in several sequences, like write , and close, so they are more frequent than others which occur only in one or two sequences, like getdents and shutdown. This suggests that considering the occurrences of sequences of system calls allows to take into account behaviors-defined by short sequenceswhich characterize benign or malicious activities. In other words, the concept of system calls sequence encloses the concept of a program behavior at a very lowlevel grain and, at the same time, at a high level of abstraction with respect to the type of attacks and its implementation in the web application. Somehow, the sequences of system calls can be seen as fingerprints or signatures of malicious payload (at a very high level of abstraction). Conversely, occurrences of system calls are not as much clearly representative of an attack as the system calls sequences. In fact, occurrence counting is a too rough feature, as in the counting can be included system calls that are not used in the payload. Summing up, (i) features considered by RQ2 produce results not significantly worse than those considered by RQ1 (the accuracy is about 96% and 97%, respectively), but (ii) the former appear to be less prone to be circumvented by trivial evasion techniques. As previously explained, the occurrence of a system call can be altered by adding some junk code, which is a relatively straightforward technique. On the contrary, to camouflage a system calls sequence is much harder, because the system calls sequence is a direct image at operating system of the malicious behavior. To define an altered system calls sequence, without affecting the intended payload, could be feasible, but very hard to realize. In fact, being the actual maliciuos code in JavaScript, insertion of junk JavaScript code will likely not impact on short system call sequences. In other words, since the system calls sequence to be invoked depends on the effect which the code should produce, the insertion of junk code may add further system calls, but it cannot remove the sequence of system calls which represents the malicious behavior.

Conclusions and future work

With this paper we evaluate two methods for detecting malicious web pages based on the system calls which are invoked when the browser connects to the web application under analysis.

The first method consists of counting the occurrences of specific system calls, while the second method consists of retrieving specific sequences of system calls which are more frequent in malicious web applications than in trusted ones. Both the method produced a high classification accuracy, the first method exhibiting an accuracy slightly higher than the second one (97% vs. 96%). However, a detection method which only exploits the occurrences of specific system calls can be evaded easily, by adding junk code which alters the counting. On the contrary, altering a sequence of system calls is much harder, as it depends directly on the specific effect the attacker intends to realize. Adding junk code, in this case, may alter the number of system calls, but not a specific sequence, which may represent a malicious behavior.

As future work, we are planning to enlarge the experimentation by testing the proposed technique on a data with noise, i.e., with data collected by real clients during navigation-an in vivo experimentation. Additionally, we wish to investigate about methods for inferring a pattern for those specific sequences of system calls which correspond to malicious activities. In fact, the proposed method is capable to identify system calls sequences common to malicious web applications, but it is not able to map which ones correspond to which malicious effect.

Fig. 1 .

 1 Fig. 1. Boxplot of relative occurrences of the 10 most occurring system calls in our dataset. The top and bottom edges of each box represent third and first quartile, respectively; the line inside the box represents the mean value; the vertical lines above and below each box span to max and min values, respectively.

Table 1 .

 1 Most occurrent calls in our dataset.

		Trusted	Malicious
	System call c	Nc Nc N (%) Nc Nc N (%)
	1 clock gettime 35 444 29.97 17 869 21.81
	2 gettimeofday 30 675 27.53 25 622 34.54
	3 futex	12 895 11.36	9757 12.55
	4 recv	9325 8.25	5105 6.63
	5 poll	6919 6.13	4073 5.24
	6 open	3108 2.88	3052 4.20
	7 read	2336 2.07	1917 2.51
	8 writev	2183 1.97	1231 1.64
	9 write	1752 1.53	1206 1.57
	10 stat64	1348 1.22	1149 1.54

Table 2 .

 2 System calls with greatest difference in relative occurrences in our dataset.

	System call	∆ Nc N (%)
	1 clock gettime	8.16
	2 gettimeofday	7.01
	3 recv	1.62
	4 open	1.32
	5 futex	1.19
	6 poll	0.89
	7 read	0.44
	8 stat64	0.35
	9 writev	0.33
	10 llseek	0.31

Table 3 .

 3 Results in terms of accuracy, FNR and FPR. It can be seen that the table includes system calls which were not captured by the criterion on call relative occurrences (see Table

	k Accuracy (%) FNR (%) FPR (%)
	10	94.52	5.27	5.70
	25	95.83	4.23	4.10
	50	95.33	4.70	4.63
	100	94.55	5.50	5.40
	250	94.63	5.47	5.27
	across repetitions.

Table 4 .

 4 3-grams of system calls chosen by the feature selection procedure in one repetition of our experimental evaluation.

	3-gram of system calls
	1 clock gettime, getdents, recv
	2 write, send, getdents
	3 gettimeofday, ioctl, mkdir
	4 write, sendto, futex
	5 close, write, connect
	6 shutdown, recv, close
	7 close, fstat64, set robust list
	8 clock gettime, setsockopt, recvmsg
	9 open, getrusage, clock gettime
	10 mkdir, getsockname, setsockopt

http://www.malwaredomainlist.com

http://www.alexa.com/topsites

http://sourceforge.net/projects/strace/


Hellen Nanda
email: hellen.havinga@rws.nl

Janine Havinga

Olivier Diederik

Theobald Sessink
email: odt.sessink@mindef.nl

Risk Reduction Overview A visualization method for risk management

Keywords: Design, Security, Residual risk, Risk management, Security measure, Visualization

The Risk Reduction Overview (RRO) method presents a comprehensible overview of the coherence of risks, measures and residual risks. The method is designed to support communication between different stakeholders in complex risk management. Seven reasons are addressed why risk management in IT security has many uncertainties and fast changing factors, four for IT security in general and three for large organizations specifically. The RRO visualization has been proven valuable to discuss, optimize, evaluate, and audit a design or a change in a complex environment. The method has been used, evaluated, and improved over the last six years in large government and military organizations. Seven areas in design and decision making are identified in which a RRO is found to be beneficial. Despite the widely accepted need for risk management we believe this is the first practical method that delivers a comprehensive overview that improves communication between different stakeholders.

Introduction

Risk management in IT security is complex. Large numbers of security measures and many stakeholders make risk management in large organizations even more complex. Risk management involves the balance between the residual risks for the business and the costs of the measures that are taken to reduce the initial risks. In this article we define risk as the product of the chance that a threat causes damage to the business and the damage of that threat to the business. A 5% chance for $100 total damage, for example, will justify the costs for a $5 measure. The costs include not only the cost of the implementation of the measure itself, but also the costs of any loss of functionality.

There have been various approaches to quantify and model the security costs and benefits [START_REF] Gordon | The economics of information security investment[END_REF][START_REF] Hoo | How much is enough? A risk management approach to computer security[END_REF][START_REF] Longstaff | Are we forgetting the risk of information technology[END_REF], [START_REF] Neubauer | Business process-based valuation of IT-security[END_REF]. However, in large organizations both the chance and the damage are mostly unknown. Furthermore, the estimates of the effect of measures on chance and impact also have a high degree of uncertainty. Those approaches are therefore not practical for real-world risk management in situations with large numbers of security measures. There also have been several approaches to present risk management visually [START_REF] Roy | Attack countermeasure trees (ACT): Towards unifying the constructs of attack and defense trees[END_REF][START_REF] Schneier | Attack Trees[END_REF]. However, none of these methods present an intuitive overview of the coherence of all risks and measures required for risk management.

Challenges of Real World IT Risk Management

There are four main reasons why chance and damage are uncertain in IT security and thus why risk management is complex. First, the known vulnerabilities in IT systems change with a high rate. Every computer runs millions of lines of code, and thus the existence of bugs is almost a certainty [START_REF] Martin | Managing Vulnerabilities in Networked Systems[END_REF]. At a certain moment, for example, it may seem impossible to gain unauthorized access to a system, a week later there may be a zero-day exploit and an experienced hacker may gain access, one week later an exploit is released on the internet and access is possible for every "script kiddy", and again one week later the vulnerability is patched and unauthorized access seems impossible again. Second, the IT environment itself changes continuously, which changes both the chance and the potential damage to the business. For example the introduction of new software or a new network connection to an external system. New technology developments such as cloud computing and ubiquitous computing that introduce completely new security challenges extend this challenge even more. Third, the chance that a threat causes damage is influenced by unknown external factors. It is for example difficult to quantify how much effort an external entity is willing to take to gain access to your information, or to quantify the number of backdoors in the software you use, or to quantify the bypass rate of your security measures [START_REF] Arora | An ounce of prevention vs. a pound of cure: How can we measure the value of IT security solutions?[END_REF]. Last, the cost of the damage is hard to estimate. The damage incurred when IT systems are unavailable, interrupting business processes or critical infrastructure, or when sensitive information is disclosed, affecting competitiveness or causing reputation damage, is not easy to express in monetary terms [START_REF] Berinato | Finally, a real return on security spending[END_REF], [START_REF] Garg | Quantifying the financial impact of IT security breaches[END_REF], especially in the public sector where information if often sensitive for political, sovereignty, or privacy reasons [START_REF] Acquisti | Is there a cost to privacy breaches? An event study[END_REF]. Furthermore, the total cost of ownership of measures is difficult to express in monetary terms. Especially since most measures cause a decrease in productivity as a side effect.

Challenges of IT Risk Management in Large Organizations

Large organizations add three additional challenges to the complexity of IT risk management. First, where in a small organization a single administrator might be solely responsible for the overall security, in large organizations there are many different roles involved, such as business owner, information security officer, authorizing official, functional application manager, solution architect, and system administrator. This separation of roles causes few people to have the required overview and knowledge to link security measures to chance and impact on the business required for a good cost/benefit analysis. Second, large organizations have large numbers of information systems which are interconnected in many ways: sharing hardware, net-work infrastructure, storage, and data. Defining a strict boundary for a single information system is therefore almost impossible. A security breach on any level might affect many information systems. NIST 800-37 [START_REF]Joint Task Force Transformation Initiative: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach[END_REF] recommends segmentation of systems with guards in between, but this is not considered feasible for most networks except when dealing with very high classification levels. The chance that a security breach occurs is difficult to estimate because there are thousands of IT components and thousands of unique security measures that affect the chance. The damage is difficult to quantify because a security breach might affect many information systems. Last, the cost/benefit analysis becomes rapidly more complex due to the large number of business processes with different security requirements in large organizations. A new security measure may, for example, reduce the risk for one business unit, but may decrease productivity for another business unit.

Risk Management Methods and Standards Used in Large Organizations

To overcome the challenges of complexity, large organizations use generic risk management methods and security baseline standards for the generic infrastructure, such as NIST 800-37 [8], CRAMM, and ISO/IEC 27005 [10], to guarantee a minimum security level for all systems. In order to be sustainable over time these methods and standards use generic threats and describe only generic measures that allow for different implementations; only some common cases are described. The generic measures are not clearly linked to threats to the business [START_REF] Bornman | A comparative framework for evaluating information security risk management methods[END_REF]. When the threats change over time, the implementation might need to be re-assessed and updated. Furthermore, whether or not a specific implementation complies with the standard has to be justified by the IT security architect. Every implementation thus needs an argumentation why it meets the requirements of the generic measures and how it tailors or supplements baseline security controls. The IT security architect needs to provide insight into three aspects to justify his decisions. First, the different successive complementary and independent technical and procedural measures. Second, the risks which are reduced by each security measure. Last, the residual risks that have to be accepted.

So although these standards help larger organizations to improve the overall security, they do not eliminate the need for communication between those that design the measures and those that have to accept the residual risks.

Objectives

The challenges in IT risk management as described have led to the objectives for the RRO method. First, present the relation between risks, measures and residual risks in an intuitive way. Second, present the security design in a way that gives people with different skills and roles the opportunity to either discuss, evaluate or audit if a design meets the required security level. Third, present the security design in a way that people can evaluate the residual risks that a design imposes on the business. Last, the presentation should be applicable independent whether or not the design is already implemented or in design phase. Summarizing, the presentation should help the business to improve risk management: to improve communication and clarify the link between threats, security measures, and residual risk and make IT security designs more comprehensible and auditable.

The Risk Reduction Overview

The Risk Reduction Overview (RRO) consists of two parts: a flowchart representation and an appendix. The flowchart provides an intuitive overview of the coherence of all risks, measures, and residual risks. The position and relation of measures in the flowchart show if a measure is successive to another measure (which provides defense in depth), complementary to another measure (the measure reduces a different aspect of the risk), or independent from other measures (the measure acts on a different risk). The appendix provides the details on each risk, measure, and residual risk. The flowchart is based on two basic elements: risks and measures. There are three types of risks: the initial risks, the residual risks, and the final residual risks (Fig. 1). All paths in the RRO flowchart follow the same format: initial risks are identified and measures are applied to reduce these risks, which lead to residual risks. The flowchart starts with all the initial risks that are identified for the particular design. All initial risks are followed by one or more measures, which are followed by residual risks and more measures, and finally end with a final residual risk. Arrows depict the flow. The flow is not necessarily linear; multiple measures from different flows may lead to the same residual risk, and multiple residual risks may follow a single measure. Arrows are drawn from risk to the resulting residual risk. When the measure itself introduces a new risk, an arrow can be drawn from that measure to a new risk.

M# Measure I# Initial risk R# Residual risk F# Final residual risk M# Measure
All risks and measures in the flowchart have a unique identifier: Initial risks have the identifier I# (in which # is a unique number), residual risks have the identifier R#, measures have the identifier M#, and final residual risks have the identifier F#. In the flowchart the identifier is followed by a short description of the risk or measure. The appendix of the RRO contains the detailed description for each risk and measure in the flowchart.

Example

To illustrate the risk reduction flow we use a simplified example: email communication between a network with confidential data and the internet is enabled, and six security measures are proposed to reduce the risks (Fig. 2). This particular example describes a very common application for a risk reduction overview: a change on a secure environment is proposed, and the risk reduction overview is used to show the proposed measures and the residual risks of that change. Figure 2 does not describe a real-life design. Real risk reduction overviews [START_REF]Risk Reduction Overview example[END_REF] often have over ten initial risks and over twenty measures (Fig. 3).

Drawing Method

Before making a RRO, an initial set of risks and measures must have been identified already. The initial risks are the risks if one would take no security measures at all. The initial risks can be derived from the threats to the business combined with all possible vulnerabilities. The measures can be both technical and procedural. Initial risks can be derived from threat analysis and from the standards, but must be completed from expert and domain knowledge. The first step to set up the RRO flowchart is to lay out the set of initial risks horizontally on the top of the flow chart. Then start to lay out the measures below the initial risks and derive the residual risks from the measures. Complementary measures may be placed below to reduce the residual risks further. Place preventive measures, that reduce the chance that a threat occurs, above reactive measures, that reduce the damage when the threat occurs. Continue until all measures are positioned and only final residual risks are left. If two measures provide an identical risk reduction (for defense in depth) they should follow up on each other without residual risk, e.g. measure 3 and 4 in Figure 2. Similar measures and similar risks should be placed near each other, to ease steps two and three. In the second step similar measures are joined together to make the overview more compact and easier to comprehend, as can be seen in Figure 4. This step is greatly facilitated if similar measures have been positioned early in the flow during step one, because re-ordering measures changes all the residual risks. Once the generic measures are applied early in the flow, the residual risks become more specific, so eventually all the detail is still present in the overview.

In the third step similar risks are joined together, as can be seen in Figure 4. It is often possible to rewrite similar risks into a single more generic description, especially early in the flow. Late in the flow residual risks can be very specific and combining them would result in loss of essential detail.

If the number of risks and measures is still too large to give a single comprehensible overview, it is an option to create a summary RRO with less detail, with multiple underlying RRO's that give the required detail. The summary RRO still gives insight in the detailed final residual risks, but summarizes the upstream risks and measures in the risk reduction flow. For example: different measures like fire alarm, fire extinguisher, fire blankets and non smoking areas can be summarized as fire fighting measures. Reviewers can still find the details of fire fighting in the underlying detailed fire fighting RRO, while business owners might only be interested in the summary RRO, that present them the final residual risk of all fire fighting measures. Evaluation of the method has led to the finding that single RRO's with over 30 measures are generally considered not comprehensible anymore To support quick reading risks and measures should be described in a uniform sentence structure. Start the description of the risks with the vulnerable element. For example: Email attachments may contain malware. Start the description of the measures with the subject that causes the desired effect. For example: Anti virus software scans emails for malware.

The last step is to number and describe each risk and measure of the optimized flowchart in the appendix. The appendix has four sections. The first section describes all initial risks. The second section describes all measures. The level of detail should provide enough information for a reviewer to judge if this measure will indeed reduce the risk to the residual risk. The third section describes all residual risks. The fourth and last section describes all final residual risks. In order to give weight to each of the risks, the description in the appendix should give an indication of the chance that a risk might occur and the damage it may cause to the business. The description should provide a chief security officer or a business owner enough information in a clear and comprehensive way to assess if the final residual risk is acceptable. An indication of the cost of measures and the cost of possible damage could be added to help the decision maker.

Positioning the risks and measures manually can be time consuming, but this process could be automated.

Application

The RRO can be used in different stages of the IT security design and decision making process, and can be used to review the design of an already existing implementation. Seven areas are identified in which the RRO is beneficial. First, by creating the RRO, a security architect has to rethink design decisions of a new design or existing implementation and might find flaws or forgotten details. It forces the security architect to ask himself if the complete set of security measures does indeed cover all the risks it is supposed to. The flowchart provides a clear overview where defense in depth and diversity in defense are applied.

Second, the RRO can help a security architect to optimize a design. Duplicate measures, or measures that do not reduce a risk, are more easily identified. Furthermore, the order of the measures may have an impact on the overall costs of the design. A cheap measure as first layer of defense may, for example, reduce the required capacity for a more expensive second layer of defense.

Third, during review of the RRO, reviewers can check if all risks they expected themselves are present in the overview. A missing risk may be an indication of an insecure design or implementation. A missing risk will make the list of final residual risks incomplete.

Fourth, reviewers of the RRO can check if the suggested risk reduction of a measure is realistic. They are able to see if the assumptions about the effectiveness of technical and procedural measures are correct and if the residual risks are well quantified. Too high residual risk may be an indication of an underestimation of the effectiveness of a measure. Very low residual risks may be an indication of an overestimation. In both cases the corresponding final residual risks will be incorrect too.

Fifth, the chief security officer or business owner of the particular IT system gets an overview of the initial risks, the measures and most importantly the final residual risks. Too high residual risk may be an indication of an insecure design or implementation, very low residual risks may be an indication of too many or too expensive security measures. If the final residual risks in the RRO are not acceptable for the business, there is a clear gap between the business needs and the security implementation.

Sixth, risks can change over time. When the security infrastructure is in use, new vulnerabilities of systems or measures can occur or the chance that vulnerabilities will be exploited can increase or decrease. The RRO gives for example a computer emergency response team the opportunity to immediately see what effect these changes have on the residual risk. The chief security officer or business owner either accepts the new residual risk or requires new measures to be taken to get the residual risks to an acceptable level.

Last, an existing RRO can be used as a source of inspiration for the design of a new similar environment or to review a new design.

Conclusions, Limitations, and Lessons Learned

The RRO method has been used and evaluated in two large organizations over the last six years. The method has been applied to various complex problems in the fields of information security and cyber defense at the Joint IT Command of the Dutch Ministry of Defense, and for cyber defense of critical infrastructure at the Dutch Rijkswaterstaat. In the Joint IT Command the RRO is now a mandatory document for changes that affect residual risk. At Rijkswaterstaat the RRO is now a mandatory document when exceptions from baseline security requirements are requested for critical infrastructure objects and mission critical systems. In both organizations the RRO is used to clarify, discuss and evaluate the security design of innovative products and services, for which no baseline requirements exist. New baseline requirements are extracted from these RRO's.

The RRO method has been found to be beneficial in all seven application areas described in this article. The RRO is found to deliver a comprehensible overview of the coherence of risks, measures and residual risks. Even first time readers with no previous experience with a RRO have little trouble to identify why measures are taken and which residual risks are left. More experienced readers point out that they need less time to review measures and residual risk with a RRO. Especially if there is a large number of measures or risks involved, the RRO gives far more overview than a traditional technical design document does. The concept of risk reduction is understood by people with different skills and roles, and the use of a RRO does improve their understanding of the coherence of the measures and the residual risks. Business owners of information systems point out that the RRO enables them to discuss measures with IT specialists, something they found very difficult in the past.

The RRO method is, however, not a silver bullet for IT risk management. First, having a RRO does not guarantee that the measures are actually correct and that the real residual risks match the described residual risks. Risks change over time; a new vulnerability that was previously unheard of may introduce a completely new risk, and new threats may require new measures. The competence of the security architect is still one of the most important factors. Second, a RRO covering the security of a large and complex environment will result in a large and complex visualization. The RRO will not make a complex problem simple. Last, the creation of a RRO requires more time than a traditional technical design document that just lists the measures. We do believe, however, that the cost benefit ratio favors the RRO, which is strengthened by the fact that both organizations that have evaluated the RRO have decided to make it a mandatory document in the decision making process.

The most important observation while the method was evaluated was that adjusting the level of detail and the layout of the flowchart manually requires a significant amount of time. This discouraged some authors to improve a RRO after reviewers had sent their comments, especially since there was no obligation to deliver a RRO at the time. A tool to automate this process should therefore be developed and will be published in the future on the RRO website [START_REF]Risk Reduction Overview website[END_REF].

Application Outside IT Security

The RRO is believed to be applicable in any area in which risk management is an issue, such as public safety, fraud prevention, food safety, physical security, military operation planning and medical hygiene. There are three separate situations in which a RRO is beneficial for generic risk management. First, if there is a need for communication about risks, measures and residual risks. Second, if there are stakeholders in the design or decisions making process that do not have the adequate knowledge to derive the residual risk from the different measures taken. For example if stakeholders are not known with the technology of complementary measures from different knowledge domains. Last, if the number of risks or measures in a certain risk assessment is high and a better overview is required to discuss or evaluate the overall situation. If multiple situations are present, the case for a RRO is even stronger.

Fig. 1 .

 1 Fig. 1. Basic elements of a Risk Reduction Overview

Fig. 2 .Figure 3 .Fig. 3 .

 233 Fig. 2. Example RRO of email communication between a network with confidential data and the internet

Fig. 4 .

 4 Fig. 4. Before (left) and after (right) step 2 and step 3

Acknowledgements. The RRO method was initially developed at the Knowledge and Innovation branch of the Joint IT command of the Dutch Ministry of Defense, and has been further improved together with the CISO office of Rijkswaterstaat in the Netherlands.


Wolfgang Boehmer

Algorithm and a Crime Function

Keywords: Conditional probability, genetic algorithm, Bayes theorem, attack trees, threat actor, crime function, risk scenario technology

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The challenge of Homeland security has significantly changed during the last decade. One of the new challenges is so called advanced persistent threats (APT). APT's have a unique characteristic and current defense strategies have failed against this type of threat. The current main shortcomings of most common security technology are Network/-Host-based Intrusion Detection Systems and antivirus products. Antivirus products are excluded in this analysis. Intrusion detection Systems (IDS) are based on two typical items:

-Signature-based is still the most common technique and focuses on the identification of known patterns.

-Anomaly-based, which consists of monitoring system activity to determine whether an observed activity is normal or anomalous, according to a heuristic or statistical analysis.

Finally, a major challenge for current IDS is the limited window of time for which the connection state can be maintained, as all modern IDSs are focused on real-time detection. Only a few products, like ArcSight from Hewlett Packard, go beyond this limitation. Also the knowledge about sophisticated threats is very rare before a sophisticated attack is faced, but we can point out some typically properties, as Gartner and ISACA has published to name few as a representation. An APT can be characterized as a so called mission impossible.

1. APTs make frequent use of zero-day exploits or modify/obfuscate known ones and, thus, are able to evade the majority of signature-based end points and network intrusion detection solutions. Also, in general APTs are spread over a wide period of time and, as a result, are often outside the limited detection/correlation window of these systems. 2. APT attackers focus on a specific target and are willing to spend significant time and explore all possible attack paths until they manage to subvert its defense. 3. APTs are able to jump over an air-gap, like in the case of Stuxnet. 4. Based on the analysis of major APT attacks it is evident that some perpetrators are supported by nation-states that have significant enabling capabilities (intelligence collection, manufacturing, covert physical access) for this type of attacks. 5. APTs are highly selective. Only a small and carefully selected number of victims are targeted, usually in nontechnical departments of an organization, as they are less likely to identify and report an attack.

In this contribution we will deal with sophisticated attacks on a technical infrastructure. We will advance the typical attack tree development methodology with the conditional probability to go step by step from the leaf to root of target. The typical binary logic used on an attack tree is not sufficient for that analysis. Also the search phase of an attack is not represented on a normal attack tree. For this search phase we propose a genetic algorithm (GA) to find a solution to this complex search problem. A genetic algorithm is based on the process of evolution by natural selection, which has been observed in nature. With both of these advanced techniques we combine a threat actor with one possible path of an attack. The rest of the article is organized as follows. In the next section 2 the related work is discussed and the limitation of a normal attack tree. Afterwards, in section 3, the new type of attack tree, and the strengthes and the weaknesses of this new type of attack tree are discussed. The article concludes with a brief summary, continuing considerations and proposals for further studies.

Related work

The idea of attack trees goes back to the article by Weis in 1991 [START_REF] Weis | A system security engineering process[END_REF]. In this article he describes threat logical trees. Generally, attacks are modeled with graphical, mathematical, decision trees. A few years later, the idea of threat trees was taken up by B.

Schneier, among others, and developed [START_REF] Schneier | Attack trees[END_REF]. This work by B. Schneier led to extensive additions and improvements to this technology, such as those published by A.P. Moore et al. [START_REF] Moore | Attack modeling for information security and survivability[END_REF]. Several tools have been developed and published; representative of the work is [START_REF] Sheyner | Tools for Generating and Anaylzing Attack Graphs[END_REF][START_REF] Ingoldsby | Fundamentals of Capabilities-based Attack Tree Analysis[END_REF]; the authors provide an overview of the techniques and tools. The contribution of S. Mauw and M. Oostdijk [START_REF] Mauw | Foundations of attack trees[END_REF] in 2005 formalizes the concepts informally introduced by Schneier [START_REF] Schneier | Attack trees[END_REF]. This formalization clarifies which manipulations of attack trees are allowed under which conditions. The commonality of attack trees and game theory has been elaborated on in 2010 by Kordy et al. [START_REF] Kordy | Attack-defense trees and two-player binary zero-sum extensive form games are equivalent[END_REF]. Thus, a similar approach for the threat scenarios and threat agent are performed using the game theory.

But all the variations of an attack tree are unable to explain a sophisticated attack, as we explained for APTs in the section 1 (Introduction).

A new type of attack tree

We follow the formal definition from [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF] of attack graph for a given data structure used to represent all possible attacks. Definition 3.01 An attack graph in general, or AG, is a tuple G = (S , τ, S o , S s ), where S is a set of states, τ ⊆ S × S is a transition relation, S 0 ⊆ S is a set of initial states, and S s ⊆ S is a set of success states.

Based on this definition some automated attack graph generators were developed, to name few [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF], [START_REF] Sheyner | Tools for Generating and Anaylzing Attack Graphs[END_REF]. But all of these automated attack graphs are unable to explain the infection path e.g. from the Stuxnet Attack. The infection with Stuxnet Virus was of the internal network via a USB stick. The internal network itself was not connected to the internet. Furthermore we want to use an attack graph to prove the possibility of reaching the target (root) up from a leaf. This possibility is often named as the safety condition. In the following definition we follow [START_REF] Sheyner | Scenario graphs and attack graphs[END_REF] page 106. Definition 3.02 A probabilistic attack graph (scenario) graph or PAG is a tuple G = (S n , S p , s e , τ, π, S 0 , S a , S f , S , D) where S n is a set of nondeterministic states, S p is a set of probabilistic states, s e ∈ S n is a nondeterministic escape state (s e S a and s e S f ), S = S n ∪ S p is the set of all states, τ ⊆ S × A × S is a transition relation, π : S p → S → R are transition probabilities, S 0 ⊆ is a set of initial states, S a ⊆ S is a set of acceptance states, S f ⊆ S is a set of finial states, and D : S → 2 A (A = 2 AP ) is a labeling of states with sets of alphabet letters.

A probabilistic scenario graph (PSG) distinguishes between nondeterministic states (set S n ) and probabilistic states (set S p ). The sets of nondeterministic and probabilistic states are disjointed (S n ∩ S p = ). The function π specifies probabilities of transitions from probabilistic states, so that for all transitions (s 1 , s 2 ) such that s 1 ∈ S p , we have Prob (s 1 → s 2 ) = π(s 1 )(s 2 ) > 0. Thus, π(s) can be viewed as a probability distribution on next states. Intuitively, when the system is in a nondeterministic state s n , we have no information about the relative probabilities of the possible next transitions. When the system is in a probabilistic state s p , it will choose the next state according to probability distribution (s p ) [START_REF] Sheyner | Scenario graphs and attack graphs[END_REF][START_REF] Wang | An attack graph-based probabilistic security metric[END_REF] page 106.

In this work, we expand the idea of T. R. Ingoldsby [START_REF] Ingoldsby | Fundamentals of Capabilities-based Attack Tree Analysis[END_REF] with conditional probability π(s). Threat trees generally have a root or target. Different branches (nodes) can lead to this target, which are to be regarded as parts of goals and each start of a leaf. Each leaf is initiated by an attacker with different motives. The leaves and branches are weighted and equipped with an actor [START_REF] Poolsappasit | Towards an Efficient Vulnerability Analysis Methodology for better Security Risk Management[END_REF]. The weighting corresponds to the criminal energy (Criminal power, Cp), and contains three functions. The assessment of these three functions reflects the exogenous knowledge which is required in the Bayesian statistics. The function of the criminal energy (Cp), which in turn is composed of three additive functions, represents the expert knowledge for the Bayesian risk analysis. The criminal energy is represented by the cost function (cost of attack cf. Fig. 2), the technical feasibility function (technical function, cf. 3) and the noticeability function, cf. Fig. 4. The three functions are mentioned by T. R. Ingoldsby [START_REF] Ingoldsby | Fundamentals of Capabilities-based Attack Tree Analysis[END_REF] and have to be adjusted to the relevant inspection. The following Figures 234describe the exogenous knowledge that focuses on the objective of a system. Fig. 2 states that a threat agent (actor) for an attack is willing to spend money on tools. This willingness varies between 0 -1 (axis of ordinates) and decreases with increasing costs (axis of abscissae). This can be explained simply because, on the internet, there are a number of free tools that are all well-suited to threaten a system. Figure 3 indicates how the tools are used and the technical possibilities that exist. It is a statement about the complexity of the tools and the willingness to make use of this complexity. The curve indicates that the greater the technical possibilities and the complexity of the tools, the more the willingness drops. I.e. simple tools are preferred with simple operation. Figure 4 shows the noticeability function expressing how an actor wants to disguise his attack, so that he could not be discovered. From of these three functions, the threat of an attack is determined more precisely. This is called the criminal energy. These functions must be adapted to each situation and reflect the exogenous knowledge again, which is necessary for the conditional probability.

As an example, we can estimate the technical ability rating of 5 (out of 10), and expose the miscreant at a 0.3 noticeability. With this function of the criminal energy, we could estimate the threat profile in conjunction with a specific threat agent (actor). The three functions of Figures 234do not explain anything about the motivation and benefit of the threat agent, but the threat agent's motivation is correlated with attack benefits. These must also be taken into account in order to understand how desirable an attack appears to an adversary. The discussion of the motivation and benefits of a threat agent is not really covered in this article. The criminal function produces the population of the genetic algorithm.

The basic process for a genetic algorithm [START_REF] Whitley | A genetic algorithm tutorial[END_REF] is:

-Initialization -Create an initial population. This population is usually randomly generated and can be any desired size, from only a few individuals to thousands. -Evaluation -Each member of the population is then evaluated and we calculate a 'fitness' for that individual. The fitness value is calculated by how well it fits with our desired requirements. These requirements could be simple, 'faster algorithms are better', or more complex, 'stronger materials are better but they shouldn't be too heavy'. -Selection -We want to be constantly improving our populations overall fitness.

Selection helps us do this by discarding the bad designs and only keeping the best individuals in the population. There are a few different selection methods, but the basic idea is the same: make it more likely that fitter individuals will be selected for our next generation. -Crossover -During crossover we create new individuals by combining aspects of our selected individuals. We can think of this as mimicking how sex works in nature. The hope is that by combining certain traits from two or more individuals we will create an even 'fitter' offspring which will inherit the best traits from each of its parents. -Mutation -We need to add a little bit randomness into our populations' genetics otherwise every combination of solutions we can create would be in our initial population. Mutation typically works by making very small changes at random to an individuals genome. -Repeat all steps -Now we have our next generation we can start again from step two until we reach a termination condition.

But, typically the largest benefit of the threat agent is associated with achieving the tree's root node, or with side benefits occurring at the various intermediate nodes. Different threat scenarios run through different paths among leaf nodes and root node.

The threat agent's benefits may differ considerably depending on the threat scenario used. We will discuss different threat scenarios and different paths between leaf nodes and root in the next section.

Conclusion and further investigation

A comparison with real world attacks, like Stuxnet, shows that typical modeled attack graphs and their models in the literature are not able to create a real attack graph. In this paper we proposed a new methodology to use a genetic algorithm and the Bayes theorem to create an attack graph that could explain a real attack graph. The next step is to include not only a network into the model, but also the environment must be taken into account.

Fig. 1 :

 1 Fig. 1: Attack tree of a telecommunication provider on NTP protocol

Fig. 4 :

 4 Fig. 2: Cost function