A LAYERED GRAPHICAL MODEL FOR CLOUD FORENSIC MISSION ATTACK IMPACT ANALYSIS

Cyber attacks on the systems that support an enterprise’s mission can signiﬁcantly impact its objectives. This chapter describes a layered graphical model designed to support forensic investigations by quantifying the mission impacts of cyber attacks. The model has three layers: (i) an upper layer that models operational tasks and their interdependencies that fulﬁll mission objectives; (ii) a middle layer that reconstructs attack scenarios based on the interrelationships of the available evidence; and (iii) a lower level that uses system calls executed in upper layer tasks in order to reconstruct missing attack steps when evidence is missing. The graphs constructed from the three layers are employed to compute the impacts of attacks on enterprise missions. The National Vulnerability Database – Common Vulnerability Scoring System scores and forensic investigator estimates are used to compute the mission impacts. A case study is presented to demonstrate the utility of the graphical model.


Introduction
Organizational missions that abstract activities envisioned by organizations are usually defined at the high-level as a collection of business processes.Cyber attacks on enterprise infrastructures that support such missions can cause significant impacts.Meanwhile, a growing number of business processes and services are being hosted by cloud operator data centers.Given that most network infrastructures, including cloud infrastructures, rely on hardware and software assets, attacks that target these assets could significantly impact the missions they support.
Therefore, analyzing and quantifying the mission impacts of cyber attacks are very important to infrastructure risk managers who seek to mitigate security threats and improve mission resilience.
NIST's National Vulnerability Database -Common Vulnerability Scoring System (NVD-CVSS) provides impact estimates of exploitable vulnerabilities in information technology systems [8].Several approaches use the Common Vulnerability Scoring System to predict the impacts of multi-step attacks on assets by considering all possible attack paths [7,9,15].However, evaluating all the attack paths is infeasible for a forensic investigator intending to assess the damage because of the large number of attack paths generated when all possible vulnerabilities are considered.Additionally, the scoring system only considers publicly-reported vulnerabilities, not zero-days.
Because post-attack artifacts obtained during forensic investigations provide information that can be used to analyze attacks, the proposed layered graphical model uses this information to quantify the impacts of attacks on organizational missions.The graphical model comprises three layers and two mapping algorithms.The upper layer models operational tasks and their interdependencies that constitute the final mission as a collection of choreographed tasks.The middle layer collects evidence from intrusion detection systems and event logs to reconstruct attack scenarios.The lower layer reconstructs potentially missing attack steps using system calls executed to fulfill the upper layer tasks; this is required when evidence needed to reconstruct the attack scenarios in the middle layer is not available.Finally, the two mapping algorithms integrate the information obtained from the three layers to ascertain how mission execution was impacted during the attacks.
The three layers of graph-like dependency information provide a means to compute attack impacts on organizational missions using the National Vulnerability Database -Common Vulnerability Scoring System or forensic investigator estimates.A case study is presented to demonstrate the utility of the graphical model, in particular, how it can be used to migrate attack risks in network infrastructures, including those supporting cloud services.The model is unique because it provides an integrated forensic analysis framework that quantifies the mission impacts of multi-step attacks in complex enterprise infrastructures.

Background and Related Work
This section briefly discusses cloud forensics and related research.

Cloud Forensics
Digital forensic investigators seek evidence of attack activities on computers and networks.Evidence on a computer typically resides in physical memory or on the hard disk; the evidence may be recovered using imaging and data analysis tools [13].Evidence from a network is typically obtained in the form of network traffic capture files.Some network forensic tools, such as Snort, are also used for intrusion detection.
In the case of cloud environments, NIST [6] has defined deployment models such as software-as-a-service (SaaS), platform-as-a-service (PaaS) and infrastructure-as-a-service.Software-as-a-service enables clients to use service provider applications running on a cloud infrastructure.Platform-as-a-service enables clients to deploy cloud client applications that use programming languages, libraries, services and tools supported by a cloud provider.Infrastructure-as-a-service provides clients with the ability to provision processing, storage, networks and other computing resources.
According to Ruan et al. [12], cloud forensics is a subset of network forensics because it follows the main phases of network forensics, albeit with techniques tailored to cloud computing environments.Evidence acquisition is different in a software-as-a-service deployment compared with an infrastructure-as-a-service deployment.In the case of a softwareas-a-service deployment, a forensic investigator depends entirely on the cloud service provider.In contrast, in an infrastructure-as-a-service deployment, an investigator can acquire evidence from virtual machine images that execute on client computer systems.

Related Work
Attackers tend to use multi-step, multi-stage attacks to bypass security countermeasures and impact important business services.Several researchers have proposed models for estimating the mission impacts of such attacks by considering all known vulnerabilities.Sun et al. [16] have proposed a multi-layer impact evaluation model for estimating mission impacts.At the bottom is a vulnerability layer that maps to an asset layer, then to a service layer and finally to the top mission layer.This layered design enables mission impacts to be computed using the National Vulnerability Database -Common Vulnerability Scoring System scores and the relationships between missions and lower-level vulnerabilities.However, the model does not incorporate a methodology for constructing attack paths.
Other researchers [15] have combined mission dependency graphs with attack paths generated by the MulVAL attack graph generation tool [11] to estimate the mission impacts of attacks on cloud infrastructures.Noel et al. [9] have designed a cyber mission impact assessment framework that analyzes all attack paths leading to attack goals to evaluate potential mission impacts; their framework leverages the Business Process Modeling Notation (BPMN) and a topological-vulnerability-analysisbased attack graph generation tool [2].However, these approaches depend on attack paths constructed from vulnerability information provided by the bug report community (including NIST's National Vulnerability Database -Common Vulnerability Scoring System) to assess the impacts of attacks.As a result, the approaches do not scale to large infrastructures and cannot handle zero-day attacks.
Digital forensic researchers have employed post-attack evidence and correlation rules to reconstruct attack scenarios in investigations of criminal activities and enterprise incidents [4,17].For example, Liu et al. [3] have integrated the MulVAL Prolog logic-based tool with a vulnerability database and an anti-forensics database to ascertain the admissibility of evidence and explain missing evidence caused by anti-forensic activities [3].Liu et al. [5] have also extended this work by using system calls to reconstruct attack scenarios in which certain attack steps cannot be determined due to missing evidence.However, no research in digital forensics has focused on assessing the mission impacts of attacks on enterprise infrastructures.

Graphical Model
Figure 1 shows the layered graphical model for mission impact evaluation.The lower layers reconstruct attack paths, enabling attacks to be mapped to tasks and missions in the upper layer in order to compute the mission impact.

Upper Layer
The upper layer of the model represents tasks and missions in terms of business processes and connects them to business process diagrams (BPDs) using the Business Process Modeling Notation.Components such as tasks, events, sequencing, exclusive choices, parallel gateways, message flows and pools [1] are used to construct business process diagrams.

Definition 1. (Business Process Diagram):
A business process diagram is a five-tuple (P ool, T, E, C, OP ) that satisfies the following conditions: T is a set of tasks and E is a set of events.Let E send , E rec be disjoint subsets of E and let e start , e end ∈ E be the start and end events, respectively.Then, the set of events E = {e start } ∪ {e end } ∪ E send ∪ E rec comprises the start, end, message sending and message receiving events, respectively.
The set of communicating tasks is T com = {(t, e send , c), (t, e rec , c)} where t ∈ T, e send ∈ E send , e rec ∈ E rec , c ∈ C.
The set of operations OP = {F, M, XOR, ; } comprises the parallel fork, parallel merge, exclusive choice and sequencing operations.
C is a set of channels.
Business processlets and a business process are defined as follows: If P and Q are processlets, then P ; Q, F (P, Q)M and P (XOR)Q are processlets.
If P ∈ T \ T com and e start , e end are the start and end events, then e start ; P ; e end is a business process.
Pools are business processes that satisfy the constraint: given pools P 1 and P 2 , there is a task (t 1 , e send , c) in P 1 if and only if there is another task (t 2 , e rec , c) in P 2 such that a message can be sent using a channel c.

Middle Layer
The middle layer of the graphical model constructs potential attacks from evidence provided by intrusion detection system alerts and system logs.The objective is to map attack scenarios to missions that are modeled as business process diagrams.Because only attack scenarios substantiated using the available evidence are considered, the attack paths that are created do not include all the possible vulnerabilities and attack paths.In some cases, all the evidence may not be available in intrusion detection alerts and system logs; these situations are addressed by the lower layer.
Attack scenarios are reconstructed using a forensic analysis tool developed in previous work [4].The tool uses rules to create directed graphs by correlating the available items of evidence.Because rules are used to create the graphs, they are referred to as logical evidence graphs (LEGs) [4].

Definition 2. (Logical Evidence Graph):
A logical evidence graph is a six-tuple (N r , N f , N c , E, L, G) where N f , N r and N c are disjoint sets of nodes comprising fact, rule and consequence fact nodes, respectively.
) is the evidence, L is a mapping from nodes to labels and G ⊆ N c is a set of observed attack events.Every rule node has one or more fact nodes or consequence fact nodes from prior attack steps as its parents and a consequence fact node as its only child.Node labels consist of instantiations of rules or sets of predicates specified as follows: 1.A node in N f is an instantiation of predicates that codifies system states, including access privileges, network topology and known vulnerabilities associated with host computers.
The rule head p is an instantiation of a predicate from N c , which is the child node of N r in the logical evidence graph.The rule body comprises p i (i = 1..n), which are predicate instantiations of N f from the current attack step and N c from one or more prior attack steps that comprise the parent nodes of N r .
3. A node in N c represents the predicate that codifies the post-attack state as the consequence of an attack step.The two predicates ex-ecCode( host, user) and netAccess( machine, protocol, port) are used to model the attacker's capability after an attack step.Valid instantiations of these predicates after an attack update valid instantiations of the three predicates listed in item 1 above.

Lower Layer
The lower layer of the model uses instances of interactions between services and the execution environment to obtain evidence that is not provided by intrusion detection system alerts and system logs.In such situations, the interaction instances are obtained from system call logs.This is done because it is assumed that the missing evidence is due to the use of anti-forensic techniques, the limitations of forensic tools and/or the execution of zero-day attacks.Because there are many system calls, only the calls highlighted in [14] are considered; these calls are listed in the third column of Table 1.The first column of the table presents abstractions of the system calls.A process that makes system calls creates dependencies between itself and other processes, files or sockets for network connections.The dependencies are modeled as object dependency graphs (ODGs).

Definition 3. (Object Dependency Graph):
The reflexive transitive closure of → defined in Table 1 is an object dependency graph.An object dependency graph is a three-tuple (V O , V E , D) where V O is the set of vertices comprising objects (processes P , files F and sockets S), V E is the set of textual descriptions of events (second column of Table 1) and D is the set of dependency edges listed in the first column of Table 1.

Mappings
The left-hand and right-hand portions of Figure 1 show the system resource mapping and graph mapping, respectively.The resource mapping obtained from the infrastructure configuration and software deployment is used to map graphs.This is accomplished by mapping the attacked services in the corresponding vertices of business process diagrams, logical evidence graphs and object dependency graphs so that the source graphs can be mapped to the destination graphs.A logical evidence graph is easily mapped to a business process diagram by matching the attacked services to the corresponding tasks supported by the services.An object dependency graph is mapped to a logical evidence graph using depth-first search as specified in Algorithm 1.
In Algorithm 1, all the object nodes in an object dependency graph are initially marked as not been checked by using the color WHITE as shown in the for-loop in Lines 1-3.Then, for each unchecked object node V O (Lines 4-5), the algorithm repeatedly calls function Find(V O ,LEG).The function call is on Line 10 and the function itself is located at Lines 28-41.
The function finds the matching post-attack status node in the logical evidence graph by checking if the attacked service in the logical evidence graph is the same as the attacked service in the object dependency graph.If such a post-attack status node (say N c1 ) is found (Line 12), then the algorithm checks if the attack step between node V O and its parent parent(V O ) in the object dependency graph has a mapping attack step between node N c1 and its parent parent(N c1 ) in the logical evidence graph (Line 15).If no matching attack step exists, then one is added to the logical evidence graph (Line 18).If no mapping post-attack status node N c1 exists in the logical evidence graph for node V O in the object dependency graph (Line 21), then one is added to the logical evidence graph (Line 23), and the search continues (Line 25) until all the nodes in the object dependency graph are checked (i.e., colored).

Computing Mission Impacts
The mission impact of an attack is quantified using the [0,1] interval.This section provides details about the mission impact computations.
Computing Attack Impact Scores.In a logical evidence graph, the term P (a) is used to denote the impact of an attack a on services deployed on a host computer.NIST's National Vulnerability Database -Common Vulnerability Scoring System lists vulnerabilities and assigns impact scores.If attack a is found in the database, then the corresponding score is used as the value for P (a).If attack a is not found in the database, then expert knowledge is used to assign the impact score P (a).
As proposed in [3], the cumulative impact score of attacks on the same service is computed using the equation: where a 1 and a 2 are two different attacks on the same service and: Assigning Weights to Tasks and Missions.The weight of the mission impact of an attack on a task is also quantified using the [0,1] interval.The higher the weight, the greater the importance of the task to the mission of a business process.
Computing Mission Attack Impacts.In this step, a logical evidence graph is mapped to the corresponding business process diagram and the mission impact of attacks I(T ) on a task T is computed using the following equation: where P (T ) is the impact of attacks on task T in the business process diagram.
Depending on the mapping relationship from the attacked service(s) (represented by a, a 1 , a 2 ) in a logical evidence graph to a task (represented by T ) in a business process diagram, P (T ) is computed using the following equations for a one-to-one mapping relationship and a manyto-one mapping relationship, respectively: Computing the Cumulative Mission Impact.In some cases, the cumulative impact of attacks on the final mission is required to estimate the overall damage.The cumulative impact of attacks on the final mission C is computed in the following ways depending on the relationships existing between the tasks comprising a business process: C(M ) is computed using Equation ( 6) when the tasks T 1 , T 2 , . . ., T n comprising the final mission M have sequential relationships with each other or only some tasks among all the sequential tasks (e.g., T 2 and T 3 ) have parallel fork relationships with the predecessor task (T 1 ) and parallel merge relationships with the successor task (T 4 ).
C(M ) is computed using Equations ( 7) or (8) when the tasks T 1 , T 2 , . . ., T n comprising the final mission M include tasks (e.g., T 2 and T 3 ) that have exclusive decision relationships with the predecessor task (T 1 ) and successor task (T 4 ), and all the other tasks (T 4 , . . ., T n ) have sequential relationships with each other.Specifically, depending on whether task T 2 or task T 3 is chosen by the business process, either Equation (7) or Equation ( 8) is used to compute C(M ). between a task (T 2 ) in the pool and another task (T 2 ) in a different pool.

Case Study
This section uses a case study to demonstrate the utility of the proposed graphical model.

Experimental Network and Attacks
Figure 2 shows the experimental network used in the case study.The network was configured to manage customer medical records and health insurance policy files.The medical records and files were stored on two virtual machines (VM1 and VM2) in a private cloud deployed using OpenStack (Juno 2014.2.3) with a Xen hypervisor.OpenStack is a collection of Python-based software projects that manage access to pooled storage, computing and network resources that reside on one or more machines in a cloud system [10].The projects include Neutron (networking), Nova (compute), Glance (image management), Swift (object storage), Cinder (block storage) and Keystone (authorization and authentication).OpenStack can be used to deploy a variety of cloud models, but is mostly deployed as an infrastructure-as-a-service.
In the experimental network, authenticated users were able to access the file server to retrieve policy files using ssh and to query the medical records stored on the database server using MySQL queries via a web application.
It was assumed that the attacker's objectives were to steal customer medical records, prevent medical record availability and modify health insurance policies.In the experiment, a simulated attacker probed the deployed web and cloud services, and launched four attacks: (i) SQL injection attack; (ii) denial-of-service (DoS) attack; (iii) cross-VM sidechannel attack; and (iv) social engineering attack.SQL Injection Attack.The web application did not sanitize user inputs.The attacker was able to exploit this vulnerability via a SQL injection attack (CWE-89) in order to access customer medical records.The following query was employed: Select * from profile where name = 'Alice' and (password = 'alice' or '1' = '1') where profile is the database name and '1'= '1' is the payload that enables the query to bypass the password check.The SQL injection query retrieved all the customer medical records.

Denial-of-Service Attack.
According to NIST's National Vulnerability Database, CVE-2015-3241 vulnerability in OpenStack Nova (compute) versions 2015.1 through 2015.1.1,2014.2.3 and earlier enables authenticated users to cause denial-of-service by resizing and deleting virtual machine instances; the process of resizing and deleting an instance is called instance migration.Because of CVE-2015-3241, the migration process does not terminate when an instance is deleted, enabling an authenticated user to bypass user quota enforcement and deplete the available disk space by repeatedly performing instance migration.
In the experiment, the attacker played the role of a malicious privileged infrastructure-as-a-service user and launched a denial-of-service attack on the database server by repeatedly resizing and deleting VM2 that resided in the same physical machine as the database server (VM1).
Cross-VM Side-Channel Attack.Side-channel attacks can be used to extract fine-grained information across virtual machines that reside in the same hypervisor [19].In the experimental network, the cache side-channel attack [18] shown in Figure 3 was launched against VM1 and VM2 that ran on the same multi-core processor (Intel quad-core i7).The cache side-channel attack leveraged the transparent page sharing feature implemented in hypervisors such as VMware ESXi and Xen.This feature automatically identifies identical pages of virtual memory and consolidates them in a single physical memory page.In the experiment, the attacker exploited transparent page sharing to evict a specific memory line (i.e., memory unit in cache containing a fixed number of bytes) from all levels of the processor cache hierarchy, waited for a period of time and measured the time taken to load the data from the corresponding memory line.Because retrieving data from memory takes more time than retrieving it from cache levels closer to the core, the attacker was able to use the timing information and the data in the corresponding memory lines to obtain confidential information about the victim.Since the attack leverages the implementation weakness in GnuPG 1.x before version 1.4.16 to obtain the information used to extract the private encryption key, GnuPG 1.4.12 was installed on VM1 (medical database server) while its copy and the spy program simultaneously ex-ecuted on VM2.The copy of the attacked program executable was required because the attacker used the transparent page sharing feature, which coalesced memory pages from the victim's virtual machine VM1 and the attacker's virtual machine VM2.
Social Engineering Attack.The attacker executed a social engineering attack on the file server to obtain the administrator's credentials (username and password).The attacker then logged into the file server as the administrator and modified insurance policy files on the file server.
Evidence Capture.In order to capture evidence of attacks, the experimental network employed Wireshark for monitoring network traffic and Snort for intrusion detection; moreover, all the servers were configured to log user access.Additionally, to obtain evidence of attacks missed by Snort and the service logs, system calls by user processes in the two virtual machines were recorded.

Three Levels of Graphs
The network configuration, service deployment information and captured evidence were used to construct the three levels of graphs, which included a business process diagram, two logical evidence graphs and two object dependency graphs.The business process in Pool 1 is the web interface for the clients (medical customers); it comprises the start and end events, two consecutive tasks (Enter Username/Password and Send Request) and an exclusive gateway for tasks (Review Policy File and Review Medical Records) depending on the client's request.

Business Process Diagram.
The business process in Pool 2 comprises the start and end events, one task (Check User Request) followed by an exclusive gateway that directs to two tasks (Request Policy Files and Request Customer Databases) depending on the message passed from task Send Request in Pool 1.In each decision task branch, there is an exclusive decision gateway (File Available and Data Available) followed by tasks that either send the requested data (Send Policy File or Send Customer Medical Records) via message passing back to the clients or reject the client request.can be asserted that the attacker used a typical SQL injection with payload '1' = '1' to attack the customer database in the database server.Snort failed to capture evidence of the denial-of-service attack that exploited the vulnerability CVE-2015-3241 in OpenStack Nova services.The OpenStack application programing interface (API) logs provide information about user operations of running instances; some of the log entries are shown in the screenshot in Figure 5, where the second line in each entry is the user operation.This information leads to the conclusion that the user in VM2 (i.e., attacker in the experiment) kept resizing and deleting instances in VM2, which resided in the same physical ma- /* initial attack status of being an iaas user and final attack status */ attackerLocated(iaas).attackGoal(execCode(nova,admin))./* cloud configuration, "_" represents any protocol and port */ hacl(iaas,nova,_,_). /* vulnerability in nova */ vulExists(nova,'CVE-2015-3241','REST').vulProperty('CVE-2015-3241',remoteExploit,privEscalation).networkServiceInfo(nova,'REST',http,_,admin).chine as the database server (VM1) that launched the denial-of-service attack on the database server.
In order to use the forensic analysis tool, system configurations and the evidence related to the SQL injection and denial-of-service attacks were converted to the Prolog predicates shown in Figures 6 and 7.
Figures 8(a) and 8(b) show the output logical evidence graphs produced by the tool; Tables 3 and 4 provide descriptions of the nodes in the two graphs.The two logical evidence graphs are not grouped together due to distinct locations and privileges of the attacker.
Consider the attack step 3, 7, 8 → 2 → 1 in Figure 8(b).Nodes 7 and 8 in the attack step model the pre-attack configurations and vulnerabilities.The consequence fact (Node 1) shows that post-attack evidence is derived by applying a rule (Node 2) to the existing system facts (Nodes 7 and 8) and the consequence fact from a prior step (Node 3).execve("/home/flush-reload/build_gpg/gnupg-1.4.12/bin/gpg", ["/home/flush-reload/buil"..., "--yes", "--sign", ''message.txt"],[/* 18 vars */]) = 0 ... Object Dependency Graph.Due to the lack of intrusion detection system alerts and system logs for the cross-VM side-channel and social engineering attacks, it was not possible to reconstruct the two attack scenarios in the form of logical evidence graphs.Therefore, the system calls captured during the attacks were examined and the method presented above was used to construct object dependency graphs for a forensic analysis.Figure 9 shows some system calls captured from VM1 (database server) and VM2 (attacker) during the cross-VM side-channel attack.The system calls show that file message.txt in VM1 was encrypted using GnuPG 1.4.12.
The system calls in Figure 10 show that a probe program bin/probe in VM2 used mmap2 to force the system to share memory addresses with the attacker's probing process.This enabled the probing process to read data from the shared memory addresses and write the data to an output file for malicious purposes.
The system calls and dependency rules listed in Table 1 were used to filter the important system calls.Two object dependency graphs were subsequently constructed.One object dependency graph showed that the attacker in VM2 read the shared cache between VM1 and VM2.The other graph showed that the attacker used the file server administrator's credentials from the Internet to modify an insurance policy file in the file server.The two object dependency graphs were then mapped to the logical evidence graphs in Figure 8.
The resulting integrated logical evidence graphs revealed that: The attacker launched two attacks from the Internet.One attack involved the use of the stolen credentials to modify an insurance policy file and the other, a SQL injection attack, involved the theft of customer medical records.

Computing Mission Impact
Table 5 lists the impact scores of the reconstructed attacks.The impact scores for CWE-89, CVE-2015-3241 and CVE-2013-4576 were obtained from NIST's National Vulnerability Database -Common Vulnerability Scoring System.The impact score for the social engineering attack was based on expert knowledge.The impact scores, which were originally specified on a [0,10] scale, were converted to the [0,1] scale.
All the reconstructed attacks were associated with the corresponding tasks by mapping object dependency graphs to logical evidence graphs and, eventually, to the business process diagram as shown in Figure 4. Table 6 shows the mission impact scores that were computed using the graph mappings.
Finally, using the attack impact scores for all tasks listed in Table 6 and the business process diagram shown in Figure 4, the cumulative attack impacts on the final missions were computed.Table 7 presents the results of the computations.

Reducing Attack Risk
In complex infrastructures, enterprise missions rely on combinations of and connections between multiple services.Because each service is supported by software and hardware assets, which are usually the targets of attackers, a tool that relates the infrastructure assets to the final missions can help determine the impacts of cyber attacks on enterprise missions.By correlating the attacks on lower-level assets to the higherlevel business process diagram and using mission impact scores of the attacks as listed in Table 5, the proposed graphical model enables the computation of the impacts of attacks on complex missions.This information is valuable to digital forensic investigators and infrastructure risk managers.
The experimental network can be used as an exemplar to demonstrate how the computed mission impacts can be used by managers to reduce the risks of attacks.The cumulative impact scores in Table 7 show that the attacks on the Review Medical Records mission have a higher impact because customer medical records could be stolen via a SQL injection attack.This suggests that input sanitization should be implemented to defeat SQL injection attacks.
Additionally, the attacks and their impact scores in Table 6 reveal that two attacks -the denial-of-service attack and the side-channel attackexploited cloud service vulnerabilities.Therefore, the services should be moved to a stable cloud that implements countermeasures for attacks launched from the shared hypervisor or physical machine.
Finally, Table 6 shows that, although the mission impact on the health insurance policies stored on the file server might not be as bad as the SQL injection attack on the database server, its score of 0.5 cannot be Table 6.Mission impact scores.7. Cumulative mission impact.

Conclusions
The three-layer graphical model presented in this chapter is designed to support forensic investigations of attacks on computing infrastructures.It helps reconstruct attack scenarios based on evidence from attack logs and leverages system call sequences when the logs do not have adequate evidence to reconstruct attack steps.NIST's National Vulnerability Database -Common Vulnerability Scoring System scores are used to compute the mission impacts of attacks; attacks that are not included in the NIST database are handled using estimates provided by human experts.The case study involving an experimental network with cloud services demonstrates the utility of the graphical model and its ability to support forensic investigations and risk mitigation efforts.
Future research will investigate applications of the graphical model in advanced networking and cloud infrastructures.Additionally, research will focus on determining how the model can be engaged in a framework that would enable enterprises to measure and manage the security risks to their infrastructures.This chapter is not subject to copyright in the United States.Commercial products are identified in order to adequately specify certain procedures.In no case does such an identification imply a recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the identified products are necessarily the best available for the purpose.

Figure 1 .
Figure 1.Layered graphical model for mission impact evaluation.

Algorithm 1 :
Mapping an OEG to a LEG.Input: ODG = (V, VE, D) and LEG = (Nr, N f , Nc, E, L, G).Output: LEG integrated with attack paths from the ODG.for each node VO in ODG do color[VO] ← WHITE end for each node VO in ODG do if VO == WHITE then for each node Nc in LEG do color[Nc] ← WHITE end //Search for the corresponding Nc1 in LEG Nc1 = Find(VO, LEG) //If there is a matching Nc1 if Nc1 = ∅ then color[VO ] ← BLACK //Check if object parent matches the corresponding Nc1 parent Nc2 = Find(parent(VO), LEG) //If there is no matching parent, add the missing attack step from ODG to LEG if Nc2 = parent(NC1) then LEG ← Flow(Nc1, VE); LEG ← Flow(VE , Nc2) end end else //If there is no matching parent, add the new object to LEG LEG ← VO; color[VO ] = GRAY end VO = child(VO) end end Function Find(VO, LEG) for each post-attack status Nc from LEG do //Check if there is a matching Nc for VO if (Nc.service == VO.service AND color[Nc] == WHITE then color[Nc] ← BLACK return Nc end else color[Nc] ← GRAY Nc ← child post-attack status node of Nc end end return ∅

Figure 3 .
Figure 3. Cross-VM side-channel attack using a shared last-level cache.

Figure 4
shows the business process diagram of the experimental network.The network incorporated three pools: (i) Pool 1 (web interface); (ii) Pool 2 (public cloud service); and (iii) Pool 3 (infrastructure-as-a-service).

Figure 6 .
Figure 6.Prolog predicates for the SQL injection attack.

Figure 7 .
Figure 7. Prolog predicates for the denial-of-service attack.
SQL injection attack on database.(b) DoS attack on database server.

Figure 8 .
Figure 8. SQL injection attack and DoS database attack LEGs.

Figure 9 .
Figure 9. Filtered system calls for the side-channel attack from VM1.

Figure 10 .
Figure 10.Filtered system calls for the side-channel attack from VM2.

Figure 11 .
Figure 11.Filtered system calls for the file modification from the file server.

Table 2 .
SQL injection attack Snort alerts and database server log.

Table 3 .
Descriptions of the nodes in Figure 8(a).

Table 4 .
Descriptions of the nodes in Figure 8(b).