Fabian Böhm

Ludwig Englbrecht

Günther Pernul

Designing a Decision-Support Visualization for Live Digital Forensic Investigations

Keywords: Digital Forensics, Visual Analytics, Live Forensics, Visualization Design

Fileless Malware poses challenges for forensic analysts since the infected system often can't be shut down for a forensic analysis. Turning off the device would destroy forensic artifacts or evidence of the fileless malware. Therefore, a technique called Live Digital Forensics is applied to perform investigations on a running system. During these investigations, domain experts need to carefully decide what tools they want to deploy for their forensic analysis. In this paper we propose a visualization designed to support forensic experts in this decision-making process. Therefore, we follow a design methodology from the visualization domain to come up with a comprehensible design. Following this methodology, we start with identifying and defining the domain problem which the visualization should help to solve. We then translate this domain problem into an abstract description of the available data and user's tasks for the visualization. Finally, we transform these specifications into a visualization design for a Live Digital Forensics decision-support. A use case illustrates the benefits of the proposed method.

Introduction

Malware has been around since the early days of computers. While traditional malware relies on malicious executable files, there is one particularly evil type of malware: Fileless Malware (FM). This type is hard to detect as it hides itself in locations that are difficult to analyze [START_REF] Sudhakar | An emerging threat fileless malware: a survey and research challenges[END_REF]. It exists exclusively in memorybased areas like the RAM instead of being written directly on the target's hard drive. This complicates forensic investigations of FM as most traditional Digital Forensic analysis techniques are designed to work on computers after they got turned off [START_REF] Mansfield-Devine | Fileless attacks: compromising targets without malware[END_REF]. However, as FM solely exists in memory, turning off the target would lead to significant loss of evidence. Although some evidence of FM can be acquired through traditional DF analysis techniques, keeping the potentially infected system running allows the investigator to gather additional evidence occurring during an incident. Moreover, there are mission-critical systems that simply cannot be shut down in order to not disrupt business operations. Therefore, Live Digital Forensics (LDF) is necessary.

LDF allows domain experts to investigate a running system, identify artifacts and collect evidence. This helps to understand FM-based attacks but at the same time requires fast and careful decisions about the LDF tools used to carry out the analysis. A poor choice of the analysis tool could destroy or compromise important artifacts.

In order to support forensic analysts to make faster and better decisions upon which tools should be used during an LDF investigation or upon which indicators might need additional attention, we propose to apply Visual Security Analytics (VSA). VSA allows domain experts to interactively explore the data of the system under investigation. It supports the decision-making process by allowing the forensic investigators to assess the current situation with a tailormade visualization approach for a specific situation [START_REF] Sacha | Knowledge generation model for visual analytics[END_REF]. Therefore, they can lead the attention towards possible indicators for FM and deploy the respective LDF analysis tools like volatility1 or SysAnalyzer2 .

This paper shows our process of developing a visual representation aimed to help Digital Forensic experts with directing their attention throughout their analyses. We follow a methodological design approach to bridge the gap between domain (digital forensic) and visualization experts [START_REF] Marty | Applied Security Visualization[END_REF][START_REF] Simon | Bridging the gap of domain and visualization experts with a liaison[END_REF]. Our main contribution is the methodological design of a visual decision-support system aiding forensic experts to direct their further investigations during a live forensic analysis. We introduce the methodology, derive a design from the requirements and problems within the LDF domain, and evaluate our design by showcasing the identification of a fileless malware's artifacts within a live forensic analysis.

The remainder of this work is structured as follows: Section 2 identifies and summarizes related work within the digital forensic analysis domain and existing visualization approaches. We describe the applied methodology to design the visualization in Section 3. The first step of our methodology is a characterization of the domain problem in Section 4. Section 5 follows the remaining steps of the methodology to design a comprehensible visualization for the characterized domain problem. This design is afterwards evaluated in Section 6 by showcasing how artifacts of the fileless malware Poweliks can be identified and how this helps to guide further investigations. We conclude our work and point to further possible research in Section 7.

Related Work

A Live Digital Forensic analysis is performed on a running system during an ongoing incident. The data is collected and analyzed simultaneously. The focus is on the preservation and processing of semi-persistent or volatile traces. This could be the content of the RAM, active network connections or running processes and programs [START_REF] Adelstein | Live forensics: diagnosing your system without killing it first[END_REF]. Since these traces are no longer available after a system restart, they cannot be extracted from a disk image by post-mortem analysis [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF]. Live analysis is therefore useful if volatile data is essential for reconstructing an incident. This is the case if the system cannot be shut down for reasons of availability or dependency, or if encrypted data systems can no longer be accessed after a restart, for example when analyzing a fileless malware [START_REF] Hoelz | Case-based reasoning in live forensics[END_REF].

A disadvantage of live analysis is that the process can often not be repeated after leaving the location of the seizure [START_REF] Hoelz | Case-based reasoning in live forensics[END_REF]. In addition, the analysis takes place in a potentially compromised environment, so that relevant traces can be hidden, for example by using rootkits [START_REF] Adelstein | Live forensics: diagnosing your system without killing it first[END_REF]. Furthermore, in the context of live analysis, a modification of the system by the investigation activities is almost unavoidable [START_REF] Adelstein | Live forensics: diagnosing your system without killing it first[END_REF]. These modifications should be as limited as possible and all activities in the system must be precisely documented [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF].

It is challenging to prove in court that the data integrity of the digital evidence has been preserved throughout the entire digital investigation. This may lead to a reduction in the admissibility of the evidence or even to a prohibition of its use. However, there are methods for comprehensible documentation and differentiation between the actions of an Incident Response team and the activities of an active attacker [START_REF] Englbrecht | Enhancing credibility of digital evidence through provenance-based incident response handling[END_REF]. Providing a profound and tamper-proof documentation of analysis steps reduces the possible impact on the admissibility of volatile evidence and/or its modification. Nevertheless, these methods usually have to be implemented in advance as Digital Forensics Readiness measures.

Additionally, post-mortem and live analysis are not competing approaches, but rather complement each other. Live analysis enables the extraction and processing of additional traces, which can considerably support post-mortem analysis and the reconstruction of the course of events [START_REF] Adelstein | Live forensics: diagnosing your system without killing it first[END_REF].

We identify several related visualization approaches originating from both the Visual Analytics (VA) and the Digital Forensics research domains. Within the VA domain, the designs are often based on user-centered approaches to provide a solution for a specific, relevant task of forensic experts. These visualizations feature a broad variety of use-cases ranging from the forensic investigation of shadow volumes and directories [START_REF] Leschke | Change-link: A digital forensic tool for visualizing changes to directory trees[END_REF][START_REF] Leschke | Change-link 2.0: A digital forensic tool for visualizing changes to shadow volume data[END_REF] to live monitoring of network traffic [START_REF] Boschetti | Tvi: A visual querying system for network monitoring and anomaly detection[END_REF][START_REF] Arendt | Cyberpetri at cdx 2016: Real-time network situation awareness[END_REF]. Tools like EventPad [START_REF] Cappers | Eventpad: Rapid malware analysis and reverse engineering using visual analytics[END_REF] allow the interactive and explorative analysis of large, dynamic data sets to identify malware and its behavior. The KAMAS solution is a tool providing not only innovative automated malware analysis features but also the functionality for malware analysis experts to exchange domain knowledge with the automated analysis methods [START_REF] Rind | Task cube: A threedimensional conceptual space of user tasks in visualization design and evaluation[END_REF]. Although a variety of related visualization designs exists in the VA domain, none of these visual representations is specifically designed to support the decisions forensic investigators need to make during an ongoing live forensic investigation. The same applies to the VA approaches introduced in the DF research domain. Tools like Timelab [START_REF] Olsson | Computer forensic timeline visualization tool[END_REF], LogAnalysis [START_REF] Catanese | A visual tool for forensic analysis of mobile phone traffic[END_REF], MalViz [START_REF] Nguyen | Malviz: an interactive visualization tool for tracing malware[END_REF], Vera [START_REF] Quist | Visualizing compiled executables for malware analysis[END_REF], or Devise [START_REF] Read | Presenting devise: data exchange for visualizing security events[END_REF] allow a visual representation of different types of data for static forensic investigations but are by no means capable to support fast, dynamic decisions for live forensics.

None of the above-described visualization approaches pays special attention to the decision-support required throughout an LDF investigation. Additionally, to the best of our knowledge there is no existing work on bridging the gap between the domains of Live Digital Forensics and Visual Analytics by applying methodologies to develop comprehensive and reproducible visualization designs. Therefore, the knowledge from the Visual Analytics domain is beneficial as it pays attention to design aspects that are being neglected up to now in the LDF domain. We aim to contribute to a transfer of knowledge from the VSA towards the LDF domain in this research as it has been done in other security-related domains within the last years [START_REF] Puchta | Contributing to current challenges in identity and access management with visual analytics[END_REF].

Methodology

This section summarizes the methodology which we follow throughout this work. A methodological approach allows our design decisions to be reproducible and comprehensible. Especially in visualization design this is of utmost importance because even methodologically based decisions remain subjective [START_REF] Mccurdy | Action design research and visualization design[END_REF]. Therefore, we follow the Nested Blocks and Guidelines Model (NBGM) which is a wellestablished methodology for designing visualizations [START_REF] Meyer | The nested blocks and guidelines model[END_REF]. Another important aspect of the NBGM is that it is aimed to support the collaboration between domain and visualization experts and, therefore helps to close the aforementioned gap in LDF visualization designs [START_REF] Simon | Bridging the gap of domain and visualization experts with a liaison[END_REF]. The high-level layers of the NBGM are depicted in Figure 1 and described in the subsequent sections [START_REF] Meyer | The nested blocks and guidelines model[END_REF][START_REF] Munzner | A nested model for visualization design and validation[END_REF].

Domain problem characterization

Data/operation abstraction design Encoding/interaction technique design Algorithm design Fig. 1. Nested layers of the NBGM [START_REF] Meyer | The nested blocks and guidelines model[END_REF][START_REF] Munzner | A nested model for visualization design and validation[END_REF].

Domain problem characterization:

The main task in this first layer is the identification of the specific situation and problem for which the visualization should be designed. The tasks and data of the target group are identified including their workflows and processes. Each target domain has its own descriptive vocabulary and it is important within this phase to work with the target users using their familiar vocabulary. This layer of the nested model bridges the gap between visualization experts and domain experts as it allows designers to understand the world the domain experts work in and which problems they face [START_REF] Van Wijk | Bridging the gaps[END_REF]. Data/Operation Abstraction Design: The second level abstracts the domain problem characterization using the vocabulary of the visualization domain. Therefore, it describes visualization tasks and the data relevant to the design. Domain-specific tasks and data descriptions are translated into a visualization-specific vocabulary. This way, visualization designers identify what tasks (e.g. finding outliers, identifying trends) the domain experts have to solve from a visualization point of view. The tasks of the users in visualizations can be derived from a variety of existing task taxonomies [START_REF] Brehmer | A multi-level typology of abstract visualization tasks[END_REF][START_REF] Rind | Task cube: A threedimensional conceptual space of user tasks in visualization design and evaluation[END_REF]. Additionally, the data abstraction allows designers to describe data transformations of available data identified within the domain problem characterization into a different format if necessary, for subsequent encoding technique decisions. Encoding/Interaction Technique Design: This layer describes the visualization (encoding) techniques and the necessary interactions for users. Both, encoding and interactions must be aligned together and are derived from the visualization tasks in combination with the data at hand from the data / operation abstraction design-layer. Encoding and interaction techniques combine the first two nested layers with a design that instantiates the abstract visualization for the domain problem. Algorithm Design: The innermost layer of the NBGM requires to create appropriate algorithms carrying out the beforehand designed encodings and interactions. We do not consider this step in our current work and focus on the first three layers of the model. The final implementation of the design is part of our further research.

Decision-support for Live Forensics

In the case of an LDF investigation, decisions can be directly linked to the risks involved. Therefore, it is important to make well-considered decisions when choosing the right techniques, tools, and artifacts. In this section, we characterize the domain problem to enable a suitable visualization design helping domain experts facing this domain problem. We emphasize the supporting effect of the visualization for a digital forensic examiner. In particular, the tasks during a live digital forensic investigation are discussed. The goal is to apply the design methods of visualization experts to support better decision-making for a domain expert.

Live Digital Forensics Process

The collection and analysis of digital evidence should be based on a defined comprehensive process model. A common description of a forensic investigation process is represented by the model of Kent et al. [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF]. The investigation process is divided into four phases as depicted in Figure 2. We have extended the original approach to include an overarching decision-support by an interactive visualization at every stage. The following paragraphs describe the different original stages, which need a decision-support:

Collection: Data related to the criminal activity are identified, labeled, recorded, and secured from all potential sources of relevant data [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF]. Possibly relevant additional data sources might be identified, and respective data needs to be collected during an LDF analysis. Examination: The data collected in the previous phase is evaluated. The aim is to identify and extract relevant data [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF]. Since our approach is applied to a live investigation, a visual analysis of the data allows the decision to include additional data sources for the analysis. Consequently, the visual decision-support creates a return to a previous phase. Analysis: The results of the previous phases are analyzed in depth and interpreted to establish connections between persons, places, objects, and events and to obtain useful information regarding specific questions [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF]. Findings from the visual analysis are directly incorporated into the analysis process.

Malicious activities can be better understood through a visual representation of the data. Reporting: The results of the analysis are prepared and presented, including important information. The format and content of the report depend on the type of recipient [START_REF] Kent | Guide to integrating forensic techniques into incident response[END_REF]. Especially, visual representations can contribute considerably to the understanding of the incident. Particularly, if the attack is complex, spikes in network traffic or system performance can provide a good insight on the activities during the incident.

Collection Examination Analysis Reporting

Visual Decision-Support Fig. 2. A high-level process for Live Digital Forensics and Visual Decision-Support.

Tasks of Domain Experts in Live Digital Forensics

Mistry and Dahiya [START_REF] Mistry | Signature based volatile memory forensics: a detection based approach for analyzing sophisticated cyber attacks[END_REF] discuss the volatile memory forensics approach in detail. Using live forensics, real-time data is analyzed and stored based on the system activities. The analysis of the memory (RAM) is very important while considering live computer forensics. The approach of live forensics plays an important role in identifying Indicators of Compromise (IoCs) and recording volatile data, which would be lost after shutting down the system. The authors use memory forensics to run through various challenging scenarios and prove their approach based on previously extracted and identified data in real-time. Since their approach provides a good description of the domain experts' workflow and it has been used by the authors in several scenarios, this is further considered. We abstract and extend the original approach as a baseline (see Table 1) to identify the main tasks during an LDF analysis: is examined for suspicious features. In addition, the findings are put into context to reconstruct the course of events. By a supporting effect of VSA, outliers and correlations can be better found. -Documentation: The aforementioned tasks are documented during the whole digital forensic investigation to be used in the final report. This is an essential component to make the investigation comprehensible. During an analysis using VSA, findings based on a graphical preparation can be documented in the figures using markers (e.g. at peak values).

Available Data in Live Digital Forensics

Harichandran et al. [START_REF] Harichandran | Cufa: A more formal definition for digital forensic artifacts[END_REF] formed the term curated forensic artifact (CuFA) to specify the scope of forensic artifacts and their supervised attributes. The Arti-fact Genome Project (AGP), based on CuFA's principles, was launched in 2014 and has received 1099 forensic artifacts within the last few years [START_REF] Grajeda | Experience constructing the artifact genome project (agp): Managing the domain's knowledge one artifact at a time[END_REF]. It reached an acceptable level of maturity, as registered participants can contribute to this project by uploading artifacts along 19 categories. Crimes are committed in several ways, and the expedient evidence is accumulated by different forensic artifacts. Depending on the peculiarity of a case, digital evidence either adds more value to an investigation or is completely inappropriate. The ontology of crimes by Kahvedzic et al. [START_REF] Kahvedzic | Dialog: A framework for modeling, analysis and reuse of digital forensic knowledge[END_REF] provides a specification of past criminal cases and offers the possibility to specify almost every cyber case. We summarize the sub crime cases and focus only on cyber-crime cases.

The violation of the quality of forensic artifacts influences their admissibility at courts. Because of the fast-moving nature of digital evidence, we adopt the legal requirements by Antwi-Boasiako et al. [START_REF] Antwi-Boasiako | Implementing the harmonized model for digital evidence admissibility assessment[END_REF] due to their overall completeness and applicability. This framework is appropriate for forensic investigations and reduces the overall scope of common data quality dimensions. These legal requirements cannot be circumvented, as admissibility in court is indispensable.

AGP represents an open-source platform based on the CuFA principles. The following forensic artifacts categories have been extracted: Windows registry, memory, file, network packet, process, email message, address, code, disc partition, account, network socket, disk, user account, X509 certificate, user session, windows event log, volume, and Linux packages. These categories are further reduced since our concept focuses on LDF and not all categories are available in this type of investigation. To illustrate the possibilities of our approach, we will focus on the following categories of data sources that can be accessed during a live forensic analysis (without major interference due to the installation and execution of additional applications): file access, network packets, process-lists, event logs (including PowerShell) and system statistics.

VSA can support understanding and interpreting the context data in combination with stored data. Therefore, VSA allows experts to make better, contextbased decisions for further investigations.

A Design for Visual Decision-Support in Live Forensics

Based on the domain problem which arises for forensic experts during a live forensic investigation (see Section 4) we derive appropriate visualization tasks, visual encoding and necessary interaction functionalities for a visual decision-support system within this section. Figure 3 depicts an overview over the respective, fully defined NBGM model for this problem domain.

The central contribution of this part of our work is the innovative application of different encoding techniques combined as an interactive, coordinated view where interactions in one view influence the representation in others. This allows a lateral, visual movement in the data enabling forensic analysts to browse through the data and identify artifacts that need further investigation with specific forensic analysis methods. However, without the visual decision-support they might not even have spotted the artifact. Therefore, we strengthen the necessity of a visual design as proposed by us in the following sections.

Data/operation abstraction design

This section covers the abstraction of the domain problem characterization above. This step in the NBGM is carried out via designing and identifying data blocks and task blocks that describe the needs, requirements, and problems of the forensic experts. Defining these blocks, subsequently allows a comprehensible decision for specific visual encoding and interaction techniques.

Task blocks In Section 4.2 we identify several tasks that are important for forensic experts when they are performing an LDF investigation. A visual design for decision-support during these investigations needs to support the experts in these tasks. To be able to transfer the domain problems into a suitable visual design, we identify abstract visualization tasks from the Why? part of Brehmer and Munzner's task typology [START_REF] Brehmer | A multi-level typology of abstract visualization tasks[END_REF]. This typology describes why a specific task is performed in terms of which goal a user is pursuing.

The abstract, process-like overall task of forensic experts is to get an idea or indication where to further direct the ongoing LDF investigation and therefore, which tools they should deploy (see Section 4.1). We summarize this high-level task as "Decision-support for domain experts" in Figure 3. However, the processbased task of decision-support can be split into several abstract visualization tasks. The main goal for forensic experts from a visualization point of view is to Discover which is a task formed around the generation and verification of hypotheses. An exemplary hypothesis in this context might describe which malware is acting on a device or which forensic tools need to be deployed to continue the investigation.

The Discover task is further specified depending on whether the analyst has a hypothesis in mind when using the visualization or not. When the LDF investigation is carried out to find evidence for a specific malware with known indicators acting on the device, this corresponds with the Locate task. Browsing outlines actions to search through suspicious indications within the visualization to find out which investigative tool might help to continue the analysis. The remaining task at this level, Explore, represents an analyst exploring the displayed data to identify possible suspicious patterns in the data and therefore, to make decisions on possible malware types on the device or at least additional LDF tools to deploy on the device. Once a hypothesis about malware or LDF tools is made, the forensic expert continues to Identify additional characteristics of the malware or tries to further strengthen the need for the LDF tool. This is possible by using the visual representation of our design.

Data blocks

The available volatile data described in Section 4.3 is mostly defined as multi-dimensional data from a visualization point of view. However, there are some relevant subcategories of data types and formats which significantly influence the decision for corresponding visual encoding.

All available data that needs to be visualized within the decision-support for LDF is time-based data as it relates to some characteristics or actions of the system at a specific point on time, e.g. the network connections at a specific time or the respective CPU and RAM workload. Additional data categories can be categorical data like the different severity types of collected logs and network data.

Encoding/interaction technique design

This section connects the different aspects between the problems of the forensic experts and the abstract blocks derived in Section 5.1 by introducing the visual encoding and corresponding interaction techniques that are necessary to enable a visual decision-support for LDF investigations. The visual encodings described in the following section are mainly well-known and established visualization techniques. We decided to only use these to ensure easy and fast perception of the design for forensic investigators. The encoding techniques are derived from the available data blocks while the interactions are necessary for the forensic experts to follow their tasks using the visual encoding of the data. The design sketch for the decision-support visualization is shown in Figure 4. It comprises five interactive main components that are further detailed within this section. In terms of more abstract visualization tasks, the design allows Navigation, Selection, Filtering, and Annotation [START_REF] Brehmer | A multi-level typology of abstract visualization tasks[END_REF]. Investigation Timeline The first component is the overarching Investigation Timeline. This component is necessary since most of the data represented within the design is time series data (see Section 5.1). Therefore, a timeline allows navigating through different points in time of the collected data and analysts can select a specific time window for their analysis. The selected time window is indicated by the small white box-shaped overlay on the timeline and the timerange on the right side. In the design sketch of Figure 4 a window of two minutes between 12:00:00 and 12:02:00 is selected. However, the box overlay can be moved across the timeline and can also be resized to allow the selection of different time ranges. The other four components of the visualization design display only data from the selected time window. An additional functionality of the Investigation Timeline is the event annotation. Forensic analysts can mark and label specific points in time when they identified possible evidence or interesting artifacts. This allows to come back to these events in a later investigation or even the collaboration of multiple analysts where one can pick up the investigation on a mark added to the timeline by another analyst.

Network Activity

The next component displayed in the upper left corner of Figure 4 is the Network Activity. This view aims to give an overview over the device's external activities regarding the endpoints and IP addresses it communicated with. In the center of this view the device under investigation and process IDs (PIDs) is shown. To keep this representation clearly laid out only PIDs with active connections during the selected time frame are displayed. The connection partners are illustrated with ellipses labeled by IP addresses. The connection targets are clustered by IP address range allowing to distinguish different networks. In the exemplary design sketch, for example, the local network of the device is clustered on the left of the Network Activity clearly separated from external connection targets on the right. We include the connections between a process and its communication partner by adding directed links for both incoming and outgoing communication. The color coding of the links is dependent on the cumulative number of bytes sent through the connection with a scale from blue (i.e. few bytes or "cold connection") to red (i.e. many bytes or "hot connection"). The distinguishable and color-coded links for up-link and down-link connections allow to quickly detect large data flows and to identify the process responsible for this data flow. Examples for possible artifacts needing additional analysis with sophisticated LDF tools are the imaginary process with the PIDs 2345 and 3456. The first one is sending a lot of data to an external IP address while the other one is downloading numerous bytes from another address.

Clicking on a PID highlights the connections of the selected process in this view but also in the System Performance and the Read/Write Entropy views where the activities of the process are highlighted respectively. This allows a quick indication about a process's overall statistics including its network activity as well as its CPU and RAM activity. Hovering a connection opens a thumbnail with additional information on this specific network communication between a process and an external IP address. This additional information contains the exact number of bytes sent over the connection as well as the port and protocol used to open it. A similar hovering interaction is also provided for the nodes depicting the communication partners of the device under investigation. The thumbnail for these nodes contains the total amount of bytes sent from and to this node as well as ports that were used to connect to. Hovering a node simultaneously also highlights the processes that established a connection with the corresponding IP address.

Read/Write Entropy In the upper right corner the decision-support visualization design features a Read/Write Entropy display. The area charts of this view show the entropy of both read and write operations on mounted drives of the investigated device. The x-axis of the charts encodes the selected time frame from the Investigation Timeline while the positive y-axis displays the entropy of the data read from the specific drive at a point in time on a range from 0 to 1 (0% to 100%). Analogously, the negative y-axis represents the same indicators but for data written onto the drive. Therefore, the entropy for write operations is indicated as a negative value in our design. This only serves to clearly distinguish positive and negative y-axis values in the area charts. In addition to indicating the difference of read and write operations by indicating them with different vertical directions, they also are encoded with different colors. In the top right corner of this view, the drives for which the entropy values should be displayed can be selected via check-boxes.

This view allows a zooming interaction, preferably by mouse-wheel, where zooming in narrows down the displayed time window and zooming out analogously widens the time span. If experts zoom into this view, the time window is adjusted respectively for all other views. Possible artifacts that catching an expert's eye in this view are unusually high entropy scores for read or write operations. As an example, serves the increasing entropy scores in the design sketch towards the end of the selected time frame for both drives. This might indicate the writing of a lot of encrypted data on the two drives.

System Activity The left view in the bottom row of our design is a visual representation is also an area chart, but a stacked version. It provides a visual encoding of System Activity by displaying a count of system events (e.g. Windows Event Logs, Powershell Events, Syslogs). The events are colored depending on their type or severity allows experts to detect a rising number of errors or similar indications of artifacts. The check-boxes on the top right of the view allow enabling different event types to be displayed. The x-axes of the area chart are like a timeline while the y-axes indicate the cumulative count of currently displayed event types at a specific point in time. The stacked area chart allows identifying trends and changes in the logged activities of the system. This chart is also allowing a zoom interaction like the previous Read/Write Entropy views. Within this view, an unusually high number of error logs in the Windows Event Log that is constantly appearing throughout the whole two minutes currently under investigation could be an artifact for further analysis.

System Performance

The last view that is part of our visualization design located on the bottom right of Figure 4. It is split into two smaller views which in combination give an indication of the System Performance. The upper part of this view is occupied by a line chart with two different lines. The blue line depicts CPU performance while the second, orange line indicates memory or RAM activity. Both lines are on a relative scale, meaning that the y-axis ranges from 0 to 1. Both lines on the chart are again displayed for the selected window of time. The line chart allows a zoom interaction similar to the interaction described within the Read/Write Entropy and the System Activity views.

The lower part of the display contains a table with active processes during the time which is currently defined for analysis. The table has four columns for the process name, its PID, and a spark line visualization allowing a fast perception of this process's CPU and RAM activities. A spark line is a special, word-sized type of line chart. They are not displayed with any axes and serve a single purpose: to give an indication about the trend of a single indicator. The table might be longer than the five exemplary rows from our design sketch and therefore, needs to be scrollable. Rows can also be selected leading to a highlighting of the corresponding process in the table and in the Network Activity view. Selecting a process also changes the Read/Write Entropy view by now only showing the entropy of the read or write operations performed on behalf of this specific process. This enables forensic analysts to conclude on the influence of a process on the systems performance and possible correlations with network activities.

Use Case

To show how our visualization design can support forensic experts in their LDF investigations, we go through a short use case featuring a well-known and documented fileless malware attack. We describe how indicators of this malware become apparent within our visual decision-support and how we support the tasks of forensic experts during an LDF investigation identified in Section 4.2.

The use case features the fileless-malware Poweliks which attacks Windowsbased systems. This malware became known as a file-based piece of malicious code but in 2014 it moved to a file-less variant. After computers are infected they are part of a click-fraud botnet where bots request advertisement data from a central Command-and-Control (C&C) server, load the ads and click them to generate revenue [START_REF] O'murchu | The evolution of the fileless click-fraud malware poweliks[END_REF]. As a side effect, Poweliks often acts a door-opener for other malware as it clicks up to 3000 ads per day on a single computer and does not care about whether the ads are malicious or not. Although this malware attracted attention back in 2014, its design is special in two aspects. Poweliks acts without leaving a file on the computer's file system. It stores all the data it needs in the registry and memory by injecting code into legitimate processes currently running. Therefore, it is hard to detect once it gained a foothold on the system. The second interesting aspect of Poweliks is, that, despite being a fileless malware, restarting the infected device does not remove it as it reboots itself from altered registry keys. This makes Poweliks a very special and dangerous type of fileless malware [START_REF] Wueest | Internet security threat report: Living off the land and fileless attack techniques[END_REF]. Because of those characteristics, we choose to describe how indicators for the Poweliks malware are visible within our visualization design.

Based on publicly available details and threat hunting details about the adfraud variant of Poweliks, we describe indicators that can be detected within our design, helping forensic analysts to make decisions where to guide their attention for further analyses. We structure the indicators and their identification according to the different views of our visualization design (see Section 5.2).

Network Activity: Regarding the network activity of an infected system, there are several indicators becoming apparent within a visual display. First, Poweliks is known to download the Powershell as well as the .NET framework from official Microsoft download pages if not available on the computer. The respective connections might appear in the view as connections of processes to official Microsoft IP addresses and a high payload on the down-link transfer, i.e. the link between the Microsoft IP and the process turns red. Additionally, as the malware acts as a botnet, it regularly connects to its C&C server. These are only short connections with a very limited payload.

However, as they appear on a very regular basis, they can be identified as an indicator for further analysis why the system is connecting to the respective IPs.

Another suspicious activity to be spotted via the proposed design is the adclicking component of Poweliks. The behavior of requesting ad data from the C&C server, contacting a search page for the URL of the ad, and clicking the loaded advertisements becomes recognizable as the network activity would show many small-scale connections to a lot of different, external IP addresses. This is all more suspicious when the respective network connections are originating from a single process.

Read/Write Entropy: Overall, activities on the file system is less apparent as Poweliks is a file-less malware. However, as the malware can request up to 3000 ads per day on a single computer it is very likely that the malware also "clicks" other malicious ads. The entropy of read and write operations on different drives of a computer shall light on possible ransomware being active due to Poweliks' activities. Increasing entropy values in this view indicate the transfer of encrypted data. This highlights the necessity for domain experts to further investigate this malware since it could have features of a ransomware.

System Activity: Poweliks' special fileless persistence method uses a watchdog and PowerShell scripts when it is establishing its foothold. It also modifies many key registry entries trying to lower or disable browser security settings to be able to perform the ad-clicking behavior. Both of these actions produce log events (Windows Event Logs, PowerShell Events, etc.) with different severity. However, as the performed behavior is rather uncommon, the System Activity view shows several warnings and errors to the domain experts. Therefore, they might for example decide to analyze the changes made to the key registry in depth.

System Performance: Also, the system performance is not too bad during the execution of the Poweliks malware. This is because the malware does not want to significantly affect the performance of the infected computer. However, with our concept it can be seen that the CPU and RAM are used when a web page is accessed in the background for a few moments. This is due to the fact that the browser has to interpret and render the website. If the observed computer is not running other programs, this is also a possible indication of the malware. These findings by using a visual display during a live investigation help the forensic examiner to better assess the current situation and to make a well-considered decision for the use of certain tools. Also, the display of the processes and their RAM as well as CPU indicates possible further investigation needs. In the case of Poweliks which is hiding in different common processes (e.g. cmmon32.exe, dllhost.exe, logagent.exe), unusual activity of those processes indicates further investigation potential. Especially, when these processes are involved in anomalous network activity as well.

However, the malware Poweliks will be detected by current virus scanners but a coming back by a modification of the malicious code or behavior is very likely since file-less techniques evolved in the last few years. Nonetheless, they are relevant artifacts helping forensic experts to guide their further analyses.

Conclusion and future work

Within this work we made a contribution utilizing Visual Security Analytics as a decision-support approach for Live Digital Forensic investigations. We describe and abstract the problem of forensic investigators which have a wide variety of tools at hand for their analyses but need to decide quickly which of them need to be deployed in the current situation. To support them in this decision-making process we applied a methodology derived from the visualization research domain. Contributing to this domain problem with a tailor-made visualization approach enables forensic investigators to make faster and well informed decisions. We described the proposed visualization design and evaluated the visual representation with a simple use case. Summarizing, we showcased how Visual Security Analytics could help to solve an existing problem on the domain of LDF.

For future work we mainly see two different directions to follow. First of all, we want to apply our visual security analytic approach to a more sophisticated malware using Process Doppelgänging3 where current anti-virus software and forensic tools reach their limits. Process Doppelgänging refers to a file-less code injection that uses a Windows native function and an undocumented implementation of the Windows Process Loader. This technique leaves no traces and is very difficult to detect. Our approach can highlight malicious activities and assist the digital forensics examiner during a live forensics investigation. Furthermore, another path to pursue in future work is the generalization of our approach. This requires to identify inherent characteristics of FMs and their classification based on a subset of those characteristics. A more holistic and modular version of our design approach would allow to have a specific encoding for each malware characteristic. This would support the work of forensic investigators even further as they can define individual dashboards as subsets of the available designs fitting their need to identify known and unknown FM.

Fig. 3 .

 3 Fig. 3. NBGM applied for LDF covering the results Sections 4 and 5.

Fig. 4 .

 4 Fig. 4. Resulting design sketch of a decision-support visualization for Live Digital Forensics investigations.

Table 1 .

 1 Summarized expert tasks in LDF.

	Task	Details
		-Identify suspected devices and media
	Data Acquisition	-Dump RAM, cache, and network traffic
		-Acquire an image of system (if possible)
		-Parse memory structure
		-Identify relevant memory segments
	Establish Intelligence	-Identify loaded modules
		-Identify running processes and file accesses
		-Identify established network connections
		-Search outliers and irrelevant information
	Memory & Data Analysis	-Extract additional relevant data -Verify findings for further decisions
		-Decide the next analysis steps
	Documentation	-Document interesting findings -Document artifacts and evidence

-Data Acquisition: Within this task, investigators need to decide which data they export from the device under investigation. During an LDF analysis, only a limited amount of data can be extracted. An additional limitation for this task is often, that data only can be extracted with a-priori implemented functionalities. -Establish Intelligence: This step is very much based on the present situation and requires that the investigator has a good sense of the specific case. Usually this is due to the prior knowledge of the investigator. It is important that in this step no analysis in the actual sense is carried out, but rather the region for possible purposeful evidence is identified. A graphical processing by means of VSA can contribute significantly to this. Especially decisions about the inclusion of further areas are very time-critical and a visual representation can contribute to a fast identification. -Memory & Data Analysis: In this step, the previously identified data

https://www.volatilityfoundation.org/

http://sandsprite.com/iDef/SysAnalyzer/

https://www.blackhat.com/docs/eu-17/materials/ eu-17-Liberman-Lost-In-Transaction-Process-Doppelganging.pdf


Nawaf Alhebaishi

Lingyu Wang
email: wang@ciise.concordia.ca

Sushil Jajodia
email: jajodia@gmu.edu

Modeling and Mitigating Security Threats in Network Functions Virtualization (NFV)

By virtualizing proprietary hardware networking devices, Network Functions Virtualization (NFV) allows agile and cost-effective deployment of diverse network services for multiple tenants on top of the same physical infrastructure. As NFV relies on virtualization, and as an NFV stack typically involves several levels of abstraction and multiple co-resident tenants, this new technology also unavoidably leads to new security threats. In this paper, we take the first step toward modeling and mitigating security threats unique to NFV. Specifically, we model both cross-layer and co-residency attacks on the NFV stack. Additionally, we mitigate such threats through optimizing the virtual machine (VM) placement with respect to given constraints. The simulation results demonstrate the effectiveness of our solution.

Introduction

As a cornerstone of cloud computing, virtualization has enabled providers to deliver various cloud services to different tenants using shared resources in a cost-efficient way. The trend of virtualization has also led to many innovations in networking in and outside clouds. In particular, traditional networks heavily rely on vendor specific hardware devices with integrated software, such as routers, switches, firewalls, IDSs, etc., which lacks sufficient flexibility demanded by today's businesses. Consequently, the need for decoupling software from hardware in network devices has led to Network Functions Virtualization (NFV) [START_REF]ETSI-Welcome to the World of Standards[END_REF], which basically virtualizes proprietary hardware networking devices. As a key enabling technology of 5G, NFV has seen an increased adoption among cloud service providers, especially in the telecommunication industry [START_REF]Intel. Realising the benefits of network functions virtualisation in telecoms network[END_REF].

However, the reliance on virtualization and the increased complexity together imply that NFV may unavoidably introduce new security concerns. First, as an NFV stack involves several abstraction levels covering the physical and virtual infrastructures as well as the virtual network functions [START_REF]ETSI-Welcome to the World of Standards[END_REF], it naturally has a larger attack surface, opening doors to new security threats such as cross-layer attacks. Second, as one of the main advantages of NFV is to provide diverse network services to different tenants using the same hardware infrastructure, NFV would also share similar cross-tenant attacks as those seen in clouds (e.g., [START_REF] Zhang | Homealone: Co-residency detection in the cloud via side-channel analysis[END_REF]). Therefore, security threats introduced by the multi-layer and multi-tenant nature of NFV need to be better understood and mitigated.

Attack modeling and mitigation in NFV has only received limited attention (a more detailed review of related work will be given in Section 6). Existing works have focused on specific vulnerabilities caused by orchestration and management complexities [START_REF] Zhang | Generic and agile service function chain verification on cloud[END_REF] and vulnerabilities resulting from the lack of interoperability [START_REF] Fayazbakhsh | Verifiable network function outsourcing: Requirements, challenges, and roadmap[END_REF] or the lack of proper synchronization between different abstraction levels [START_REF] Thirunavukkarasu | Modeling nfv deployment to identify the cross-level inconsistency vulnerabilities[END_REF]. There also exist works on dynamically managing security functions in NFV [START_REF] Wang | Enabling automatic composition and verification of service function chain[END_REF] and verifying Service Function Chaining (SFC)-related properties [START_REF] Flittner | Chainguard: Controller-independent verification of service function chaining in cloud computing[END_REF][START_REF] Zhang | SLA-verifier: Stateful and quantitative verification for service chaining[END_REF][START_REF] Tschaen | SFC-Checker: Checking the correct forwarding behavior of service function chaining[END_REF][START_REF] Marchetto | Virtual network embedding with formal reachability assurance[END_REF]. Existing works on co-residency attacks mostly focus on clouds [START_REF] Bates | Detecting co-residency with active traffic analysis techniques[END_REF][START_REF] Atya | Catch me if you can: A closer look at malicious co-residency on the cloud[END_REF] instead of NFV. To the best of our knowledge, there lack a general approach to modeling and mitigating NFV attacks.

In this paper, we take the first step toward modeling and mitigating security attacks in NFV. Our key ideas are threefold. First, we propose a multi-layer resource graph model for NFV in order to capture the co-existence of network services, VMs, and physical resources at different abstraction levels inside an NFV stack, and how those could potentially be exploited by attackers. This model allows us to capture not only attacks that target each layer of the NFV stack, but also attacks that go across different layers by exploiting the inter-dependencies between corresponding resources at those layers. Second, we also model the insider threats posed by malicious or compromised users of co-resident tenants inside the same NFV stack. The model allows us to captures how a co-residency attack may allow insiders to satisfy certain initial security conditions, such as privileges or connectivity, which are normally not accessible to external attackers. Third, we propose a solution to mitigate security attacks in NFV through VM placement and migration, which is a low cost option already available in NFV. The aforementioned model allows us to formulate the attack mitigation in NFV as an optimization problem and solve it using standard optimization techniques. We evaluate our approach through simulations to demonstrate its effectiveness under various situations. In summary, the main contribution of this paper is twofold:

-To the best of our knowledge, this is the first study on the modeling of security threats in an NFV stack. Our multi-layer resource graph model demonstrates the possibility of novel security threats in NFV, such as cross-layer and co-residency attacks, and also provides a systematic way to capture and quantify such threats. -By formulating the optimization problem of mitigating attacks on NFV through optimal VM placement and migration, we provide an effective solution, as evidenced by our simulation results, for achieving a better tradeoff between security and other constraints using standard optimization techniques.

The remainder of this paper is organized as follows; Section 2 presents background information on NFV and co-residency in NFV, and provides a motivating example. In Section 3, we present our multi-layer resource graph and insider attack model, and describe the application of a security metric. Section 4 formulates the optimization problem and discusses several use cases. Section 5 gives the simulation results. Section 6 reviews related works. Section 7 concludes the paper.

Preliminaries

This section first provides background information on NFV and co-residency in NFV, and then gives a motivating example. Fig. 1: ETSI reference architecture [START_REF]ETSI-Welcome to the World of Standards[END_REF] (left) and multi-layer NFV model [START_REF] Thirunavukkarasu | Modeling nfv deployment to identify the cross-level inconsistency vulnerabilities[END_REF] (right)

Background on NFV

As a main technology pillar of network softwarization and 5G, NFV provides network functions through software running on standard hardware. NFV enables network service providers to deploy dynamic, agile and scalable Network Services (NS). Such benefits come from the fact that an NFV deployment stack is usually an integration of various virtualization technologies including cloud and SDN together with various network orchestration and automation tools. Specifically, the left side of Figure 1 shows the European Telecommunications Standards Institute (ETSI) NFV reference architecture [START_REF]ETSI-Welcome to the World of Standards[END_REF]. The architecture builds on three main blocks, i.e., virtual network function (VNF), NFV infrastructure (NFVI), and NFV management and orchestration (MANO). First, the VNF provides network functions, such as router, switch, firewall, and load balancer, running on top of VMs through software. Second, NFVI represents the cloud infrastructure that provides basic computations, network, and storage needs for the execution of VNFs. Lastly, MANO has three management components, virtual infrastructure manager (VIM), virtual Network function manager (VNFM), and network function virtualization orchestrator (NFVO), which together manage and orchestrate the lifecycle of physical and virtual resources.

In addition, the right side of Figure 1 shows a multi-layer NFV deployment model [START_REF] Thirunavukkarasu | Modeling nfv deployment to identify the cross-level inconsistency vulnerabilities[END_REF] which complements the aforementioned ETSI architecture with deployment details, and divides an NFV stack into four layers, i.e., service orchestration (layer 1), resource management (layer 2), virtual infrastructure (layer 3), and physical infrastructure (layer 4).

Co-Residency in NFV

As an NFV stack is multi-layer and multi-tenant in nature, placing and migrating a VM or VNF can be a challenging task for the provider due to the issue of co-residency. It is well known that co-residency may lead to various security issues, such as sidechannel attacks, and additionally the tenant may have specific requirements in terms of (the lack of) co-residency. Co-residency may occur in an NFV environment when a new VM or VNF is first placed, or when an existing VM or VNF is migrated. The tenant requirements may specify that certain VNFs are to be placed on a dedicated host, or a VM needs to have the auto-scaling feature such that its need for more space can be quickly fulfilled. In terms of security, co-resident VMs or VNFs may belong to tenants with conflicting interests, and the co-residency may enable an insider attack with increased privileges and connectivity not available to regular attackers.

A unique aspect of co-residency in NFV is that, in an NFV stack, co-residency can happen between more layers, such as between VNFs and physical hosts, between VNFs and VMs, or between VMs and physical hosts. The co-residency of VNFs or VMs on the same physical host can occur due to placement or migration, which is known to lead to side-channel or resource depletion attacks due to the shared physical resources such as CPU, memory, or cache. The co-residency of VNFs on the same VM can also occur when different tenants employ the same VM to run similar network functions, such as virtual firewall or virtual IDS [START_REF] Ixia | Network Function Virtualization (NFV): 5 Major Risks[END_REF][START_REF] Huang | Autovnf: An automatic resource sharing schema for VNF requests[END_REF][START_REF] Crippa | Resource sharing for a 5g multi-tenant and multi-service architecture[END_REF].

Motivating Example

In the following, we present a concrete example of NFV stack to demonstrate the challenges in modeling and mitigating security threats for NFV. First of all, as NFV is a relatively new concept, there lack public access to information regarding the detailed hardware and software configurations used in real NFV environments. As can be seen in Figure 1, both the ETSI architecture [START_REF]ETSI-Welcome to the World of Standards[END_REF] and the multi-layer deployment model [START_REF] Thirunavukkarasu | Modeling nfv deployment to identify the cross-level inconsistency vulnerabilities[END_REF] are quite high level, and lack such details. Most other existing works either focus on high-level frameworks and guidelines for risk and impact assessment [START_REF]Cloud Computing Service Metrics Description[END_REF][START_REF] Luna | A security metrics framework for the cloud[END_REF][START_REF] Saripalli | Quirc: A quantitative impact and risk assessment framework for cloud security[END_REF], or very specific vulnerabilities [START_REF] Lal | Nfv: Security threats and best practices[END_REF][START_REF] Pattaranantakul | Secmano: Towards network functions virtualization (nfv) based security management and orchestration[END_REF][START_REF] Pattaranantakul | Nfv security survey: From use case driven threat analysis to state-of-the-art countermeasures[END_REF], with a clear gap in between.

To address such limitations, we design a concrete example of NFV stack, as shown in Figure 2, based on both the ETSI architecture [START_REF]ETSI-Welcome to the World of Standards[END_REF] and the multi-layer deployment model [START_REF] Thirunavukkarasu | Modeling nfv deployment to identify the cross-level inconsistency vulnerabilities[END_REF], as well as other public available information gathered from various providers and vendors. As shown in Figure 2, the NFV stack is depicted on three layers where the VNF layer shows three service function chains (SFCs), and the VM and physical layers show the corresponding virtual and physical infrastructures used to implement those SFCs, respectively. The dashed lines between layers demonstrate the correspondence between the services and the virtual or physical resources. We assume there are three tenants, shown in Figure 2 through different colors, i.e., Alice (blue), Bob (green), and Mallory (red)), that are hosted on this NFV stack.

In such a scenario, both the NFV provider and each tenant may want to understand and mitigate potential security threats. While existing threat models such as various attack trees and attack graphs may be applied, there are some unique challenges and opportunities as follows.

-First, as can be seen in Figure 2, the NFV stack is composed of different layers, and the inter-dependencies between resources on those layers may lead to novel cross-layer attacks. The NFV tenant and provider need to consider all layers and the inter-dependencies between layers when analyzing potential security threats because of the possibility of such cross-layer attacks. Fig. 2: A concrete example of NFV stack (vFirewall: virtual firewall, LB: load balancer, DB: database, VM: virtual machine, VDU: virtual deployment unit) -Second, the fact that multiple tenants are sharing both virtual and physical resources in the same NFV stack poses another challenge, i.e., co-residency attacks. In contrast to clouds, NFV may have an increased attack surface in terms of co-residency attacks. As demonstrated in Figure 2, unlike in clouds, co-residency in NFV may occur in terms of both shared physical resources and shared virtual resources such as VMs, which must be considered in modeling the threat of co-residency attacks. -On the other hand, virtualization in NFV also provides an opportunity for mitigating security threats through a unique hardening option, i.e., through VM placement or migration. In contrast to other hardening options, such as patching vulnerabilities, disabling services, or stricter firewall and access control rules [START_REF] Borbor | Securing networks against unpatchable and unknown vulnerabilities using heterogeneous hardening options[END_REF], VM placement or migration provides a lower cost option as it is a built-in feature already employed by providers for other purposes such as maintenance or resource consolidation.

More specifically, we consider concrete problems of threat modeling and attack mitigation based on Figure 2 as follows.

-First, we would like to model potential multi-step attacks that could occur in this NFV stack (Figure 2), by assuming Mallory (whose resources are shown in red color) is a malicious tenant, and the database VM belonging to Alice (whose resources are shown in blue color) is the critical asset in question. The modeling process must consider the multi-layer and multi-tenant nature of NFV and its many security implications, e.g., an attacker's VM placed on the database server (node # 1) or on the http server (node # 3) would certainly incur very different security threats, and an attacker co-residing with the target tenant on the VM level could have a better chance of compromising the target than one co-residing on the physical host level. -Second, we would like to mitigate the modeled threats posed by Mallory to Alice's database VM, through optimal placement or migration of virtual resources in this NFV stack. The solution must quantify the security threats before and after the hardening process in order to show the amount of improvement in terms of security, and the solution should be able to accommodate other considerations or constraints, e.g., limiting the scope to one layer or multiple layers, supporting different VM placement policies (such as those used in CloudSim [START_REF] Cloudsim | CloudSim: A Framework For Modeling And Simulation Of Cloud Computing Infrastructures And Services[END_REF]), and limiting the cost of placement or migration (such as the maximum number of VM migrations).

To this end, we will present our threat modeling solution in Section 3 and our attack mitigation solution in Section 4.

Modeling Security Threats in NFV

This section presents our solutions for modeling potential multi-step attacks on an NFV stack (Section 3.1), for modeling insider attacks from co-residing tenants (Section 3.2), and for quantifying the threats using a security metric (Section 3.3).

Multi-layer Resource Graph

Threat Model: Our goal is to help the NFV provider or tenants to better understand and mitigate the security threats from an external attacker, a dishonest or compromised user or tenant, or a tenant administrator or cloud operator with limited privileges. We assume the NFV provider and its administrators are trusted and consequently the inputs to our threat modeling process are intact. Our in-scope threats are security attacks used to escalate privileges or gain remote accesses through exploiting known or zero day vulnerabilities in the physical or virtual entities inside an NFV stack. Out-of-scope threats include attacks which do not involve exploiting vulnerabilities (e.g., phishing or social engineering attacks) or do not propagate through networks (e.g., flash drivebased malware).

To model the security threats in an NFV stack, our key idea is to apply the resource graph concept [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF] (which is syntactically similar to attack graphs, but focuses on modeling zero day attacks exploiting unknown vulnerabilities) while considering the multi-layer nature of NFV (as explained in Section 2.1). Specifically, based on a model of the NFV stack with three layers, i.e., the VNF layer, VM layer, and physical layer, as previously demonstrated in Figure 2, we propose the concept of cross-layer resource graph to represent the causal relationships between different resources both inside each layer, and across different layers, in a given NFV stack.

We first illustrate the concept through an example, before giving the formal definitions. Figure 3 shows an example of a cross-layer resource graph for our running example (only a portion of the cross-layer resource graph is shown here due to space limitations). The VNF layer maps to layer 1 and layer 2 in the multi-layer NFV deployment model [START_REF] Thirunavukkarasu | Modeling nfv deployment to identify the cross-level inconsistency vulnerabilities[END_REF], which depicts exploits of various virtual network functions, such as virtual firewalls, load-balancers, switches, etc. The VM layer corresponds to layer 3 in the NFV deployment model, which includes exploits of the VMs that are used to implement the virtual network functions in the cloud layer. Finally, the physical layer includes exploits of the physical hosts. The left-hand side of Figure 3 shows the cross-layer resource graph for one tenant, whereas the right-hand side shows co-residency attacks from other tenants (which will be explained in next section).

Each triple inside an oval indicates a potential zero day exploit (in which case the unknown vulnerability is represented by the exploited service itself) or an exploit of known vulnerabilities, in the form of <service or vulnerability, source host, destination host>. For example, <Xen, 3, h3> indicates an exploit of Xen coming from a VM on physical host 3 to that physical host itself, and the plaintext pairs indicate the pre-or post-conditions of those exploits in the form of <condition, host>, where a condition can be a privilege on the host, e.g., <root,3> means that the root privilege on the VM runs on host 3, and <user,vFW> means the user privilege is on the VNF layer for the virtual firewall. Additionally, conditions may include the existence of a service on the host (e.g., <Xen,3>), or a connectivity (e.g., <0,3> means that attackers can connect to a VM on host 3 from host 0, and <2,h2> means a local exploit is occurring on host 2). The edges point from pre-conditions to an exploit and then to its post-conditions, which indicate that any exploit can be executed if and only if all of its pre-conditions are satisfied, whereas executing an exploit is enough to satisfy all of its post-conditions. The following provides formal definitions of those concepts.

Definition 1 (Same-layer Resource Graph). Given a collection of hosts (physical hosts or VMs) H and the set of resources HR (services or VNFs running on a physical host or a VM) with the resource mapping rm(.) : H → 2 HR , and also given a set of zero day exploits Definition 2 (Cross-layer Resource Graph). Given the same-layer resource graph for the three layers,

E = {< r, h s , h d > |h s ∈ H, h d ∈ H, h r ∈ rm(h d )}
G i (E i ∪ C i , pre i ∪ post i )(1 ≤ i ≤ 3)
, and given the cross-layer edges pre c ⊆

3 1 C i × 3 1 E i and post c ⊆ 3 1 E i × 3 1 C i , a cross-layer resource graph is a directed graph G( 3 1 (E i ∪ C i ), 3 1 (pre i ∪ post i ) ∪ pre c ∪ post c ).

Modeling Co-residency Attacks

In modeling co-residency attacks, our main idea is to capture the consequences of such attacks as satisfying certain conditions inside the cross-layer resource graph of the targeted tenant. For example, in Figure 3, the left-hand side shows the cross-layer resource graph of the targeted tenant, which depicts what an external attacker may do to compromise the critical asset <user, h1>. On the other hand, the right-hand side of the figure depicts the insider threat coming from potential co-residency attacks launched by other tenants. The (dashed) lines pointing from the right to the left side of the figure show that, as the consequence of the co-residency attacks (right), some conditions inside the targeted tenant's resource graph (left) may be satisfied, either within the same layer or across different layers. The co-residency could occur w.r.t. the physical layer, which is similar to the co-residency in clouds (when tenants share the same physical host). The co-residency could also occur w.r.t. the VMs when tenants employ the same VM to run their VNFs, which is unique to NFV.

For example, as shown on the right-hand side of Figure 3, a malicious co-resident tenant can potentially gain a user privilege on the vSwitch service of the targeted tenant through a local exploit <SCA,VNF,VNF>, or he/she can gain a root privilege on a VM on host 2 through a similar attack (<SCA,h3,h3>) (where <user,3'> means the privilege of the malicious tenant on a VM on host 3). A malicious tenant who shares VNFs running on the same VM may attack the virtual firewall VNF and subsequently the corresponding VM to eventually be able to control the firewall (<root,VM FW>) and modify its rules in order to gain access to the critical asset. A malicious tenant can also exploit an application running on VM 2 to gain control of that VM, and subsequently attack the co-residing host h2. These examples show how our model can capture co-residency attacks between different layers of the NFV stack.

Applying the Security Metric

Before we could mitigate the modeled security threats, we need to first quantify them such that we could evaluate the level of threats before and after we apply a hardening option. For this purpose, we apply the k-zero day safety security metric [START_REF] Wang | k-zero day safety: A network security metric for measuring the risk of unknown vulnerabilities[END_REF][START_REF] Wang | k-zero day safety: Measuring the security risk of networks against unknown attacks[END_REF] originally proposed for traditional networks. The metric basically counts how many distinct unknown vulnerabilities must be exploited in order to compromise a given critical asset. A larger k value will indicate a relatively more secure network because the possibility of having more unknown vulnerabilities occurring at the same time, inside the same network, and exploitable by the same attacker would be significantly lower. The metric can be evaluated on the resource graph of a network, which basically gives the length of the shortest path (in terms of the number of distinct zero day exploits). The exploits of known vulnerabilities can be either regarded as a shortcut (i.e., they do not count toward k) or assigned with a significantly lower weight in the calculation of k.

On the basis of the cross-layer resource graph model introduced in previous sections, the k-zero day safety metric (k0d) can be applied in several ways. First, we could evaluate the metric on the cross-layer resource graph of the targeted tenant, without considering others tenants, whose result provides an estimation for the threat coming from external attackers. Second, we could also evaluate the metric on the cross-layer resource graph including co-resident attacks from others tenants, and we could consider one particular malicious tenant, or multiple such tenants either separately (assuming they do not collude) or collectively (as one, assuming they may collude). Third, we could evaluate the metric before, and after applying a placement or migration-based hardening option, and the difference in the results will indicate the effectiveness of such a hardening option (which we will further investigate in next section).

For example, in Figure 3, by considering a malicious tenant sharing the same physical host with the targeted tenant (indicated by privilege <root,VM FW>) would yield a k0d value of 2 since two zero day exploits <Xen,vnfFW,NFV>, and <DB,VNF,1> are needed to reach the critical asset. Whereas considering a malicious tenant with privilege <user,2'> (here 2' indicates the privilege belongs to a tenant different from the targeted one) would yield a k value of 3 since three zero day exploits, <SCA,h2,h2>, <DB,2,1>, and <Xen,1,h1> are needed.

Attack Mitigation

In this section, we present the optimization-based mitigation through placement and migration of VNFs and VMs, and demonstrate its applicability through discussing several use cases.

Optimization-based Mitigation

Based on our previous definition of cross-layer resource graph model and the discussions on modeling co-residency and applying the k0d metric, we can define the problem of optimal placement and migration of VMs and VNFs. As shown in Definition 3, hosts and resources are defined in a way such that the placement and migration may apply to both VMs (on physical hosts) and VNFs (on VMs) through the resource mapping function. The objective function is the application of the k0d metric to the cross-layer resource graph (which can under a value assignment of the resource mapping function. Note that the application of the k0d metric could take several forms for different purposes, as discussed in Section 3.3), which gives different variations of the optimization problem. Although not specified in the definition, constraints may be given in terms of possible value assignments to the resource mapping function, e.g., which VM (or VNF) may be placed or migrated to which physical host (or VM), or a threshold for the maximum number of migrated VMs.

Definition 3 (The optimal NFV co-residency problem). Given a collection of hosts (physical hosts or VMs) H, the set of resources HR (services or VNFs running on a physical host or a VM), and the collection of tenants T with the tenant mapping function tm(.) : HR → T , the optimal NFV co-residency problem is to find a resource mapping function rm(.) : H → 2 HR to maximize k0d(G) where G is the cross-layer resource graph, and k0d(G) denotes the application of the k0d metric to G.

The optimal NFV co-residency problem we have defined is intractable, since it can be easily reduced to the NP-hard problem of network hardening through diversity in traditional networks [START_REF] Borbor | Diversifying network services under cost constraints for better resilience against unknown attacks[END_REF]. Specifically, the goal in the diversity problem is to maximize the k0d metric by changing the instance of services (e.g., from IIS to Apache for web service), assuming that different instances of the same service along the shortest path would both count toward the k value (conversely, two identical instances would only count as one). Our problem can be reduced to this since, for any given resource graph G under the diversity problem, we can construct a special case of our problem by regarding G as the VM-layer resource graph, and regarding the instance of a service as the physical host on which that service resides (such that identical instances of a service are always co-resident). By further assuming that the attacker can always trivially exploit all co-resident services as long as he/she can exploit one (i.e., co-resident services only count as one toward the k value), the two problems then become equivalent.

In our study, we use the genetic algorithm (GA) [START_REF] Golberg | Genetic algorithms in search, optimization, and machine learning[END_REF] to optimize the VM (VNF) placement and migration for maximizing k. Our choice of GA is inspired by [START_REF] Dewri | Optimal security hardening using multiobjective optimization on attack tree models of networks[END_REF] and based on the fact that GA provides a simple way to encode candidate solutions and requires little information to search effectively in a large search space [START_REF] Golberg | Genetic algorithms in search, optimization, and machine learning[END_REF]. Specifically, the cross-layer resource graph is taken as input to the optimization algorithm, with k (averaged between tenants) as the fitness function. We try to find the best VM placement within a reasonable number of generations. The constraints we have considered include defining the resource mapping function in the case that specific VMs can be assigned to each host (e.g., firewall only), enforcing a given placement policy (e.g., CloudSim [START_REF] Cloudsim | CloudSim: A Framework For Modeling And Simulation Of Cloud Computing Infrastructures And Services[END_REF] placement policy), or satisfying a maximum number of migrating VMs. In our simulations, we choose the probability of 0.8 for crossover and 0.2 for mutation based on our experiences.

Use Cases

We demonstrate the applicability of our solution through several use cases with different types of attackers and while considering different layers. The first use case contrasts an external attacker to an insider launching cross-tenant attacks. The second use case compares a same-layer attack versus a cross-layer attack. The last use case is based on the motivating example shown in Section 2.3. -Use Case A: In this case, we have an external attacker using a victim tenant's resources, and an insider malicious tenant co-residing with the victim tenant. Figure 4 shows the cross-layer resource graph for the external attacker (AE) and the insider attacker (AI). The figure shows the shortest path (dashed lines) for calculating the k0d metric, and the critical asset is represented as < user, h1 >. After optimization, the value of k for the external attacker (AE) is 4, and for the insider attacker (AI) is 3 (which means there is less room to mitigate the insider threat). -Use Case B: In this case, we compare a one-layer attack (BOL) to a cross-layer attack (BCL) for an insider malicious tenant. The BOL and BCL dashed lines shown in Figure 4 show the shortest paths for the malicious tenant using his/her coresidency with the victim tenant to reach the target < root, 1 >. After optimization, the value k = 3 for BOL and k = 2 for BCL show that there is less room to mitigate the insider threat when the attack may go across layers. -Use Case C: This case shows the optimal placement result for our motivating example discussed in Section 2.3. We consider three tenants (Alice (A), Bob (B), and Mallory (M)) and three servers each of which can host four VMs. We consider Mallory a malicious tenant and the database VM belonging to Alice a target. Table 1 shows three different placements. The upper left table shows the placement before applying our optimization solution and the value of k = 2. The right upper table and the bottom table show the optimal placement after we apply our solution by the victim tenant (where the migration is limited to the tenant's resource) and the provider (where the migration is applied to all resources), respectively. The value of k increases to k = 4 and k = 5 for mitigation by the tenant and provider, respectively. The result of mitigation by the provider is slightly better than by the tenant because more VMs may be migrated.

Simulations

This section shows the simulation results of applying our mitigation solution under various constraints. All VM placement in the simulations are based on CloudSim [START_REF] Cloudsim | CloudSim: A Framework For Modeling And Simulation Of Cloud Computing Infrastructures And Services[END_REF][START_REF] Calheiros | Cloudsim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms[END_REF][START_REF] Han | Virtual machine allocation policies against coresident attacks in cloud computing[END_REF]. We applied the three placement policies in CloudSim (i.e., the random, least, and most policies) to our NFV environment. We have 300 hosts and 7,000 VMs, and the following shows the default configurations for the host and VMs from CloudSim.

-For the physical machine, we specify the capacity of the hosts as having 16 GB of RAM, 1000 GB of storage space and a 10,000 MB/s bandwidth -The virtual machine's resource requirements are 512 MB of RAM, 10 GB of storage space and a 1,000 MB/s bandwidth Moreover, we use a virtual machine equipped with a 3.4 GHz CPU and 8 GB RAM in the Python 2.7.10 environment under Ubuntu 12.04 LTS and the MATLAB R2017b's GA toolbox. To generate a large number of resource graphs for simulations, we start with seed graphs with realistic configurations similar to Figure 2 and the cloud infrastructure configurations presented in [START_REF] Alhebaishi | Mitigating the insider threat of remote administrators in clouds through maintenance task assignments[END_REF][START_REF] Alhebaishi | Threat modeling for cloud infrastructures[END_REF], and then generate random resource graphs by injecting new nodes and edges into those seed graphs based on the VM placement results of CloudSim. Those resource graphs were used as the input to the optimization toolbox where the fitness function maximizes the average insider threat value k under various constraints. The parameters and constraints used in our simulations include the VMs placement policy, size of the network, type and number of attackers, and maximum number of VMs migrating to malicious users. We repeat each simulation on 400 different resource graphs to obtain the average result.

The objective of the first simulation is to study how cross-layer attacks may affect the security of the NFV stack. We compare the k0d metric on the original resource graph (without any cross-layer attacks), and cross-layer resource graphs. In Figure 5, the number of malicious users (external attackers or insider tenants) is between 5 and 15, while the size of the network varies between 50 and 1,500 along the X-axis. The Y -axis shows the average of k among all malicious users. The red line represents the results of the original resource graph without considering malicious tenants in this particular case. The green line represents the results of the original resource graph while considering malicious tenants. The blue line shows the result of cross-layer resource graph (with both malicious tenants and cross-layer attacks considered).

Results and Implications: From the results, we can make the following observations. First, the value of k decreases in all cases almost linearly; this is expected because, as the size of the network increases, there is a higher chance for the length of the shortest path to decrease, which means attackers may require less attack steps. Second, the value of k drops on the original resource graph (without considering cross-layer attacks) after considering the presence of malicious tenants (i.e., co-residency attacks), which is as expected. Third, the value of k drops by approximately 55% between the original resource graph without considering the malicious tenant, and the cross-layer resource graph, which shows the additional threat of cross-layer attacks. In Figure 6 the objective is to show how different placement policies can affect the value of k. In this simulation, we employ the cross-layer resource graph to measure the value of k for three types of attackers (external, malicious tenant, and lower-layer provider who has access to all the hosts) under three different placement policies used in CloudSim (i.e., the most, least, and random policies). The three figures show how the three placement policies can slightly affect the value of k. Each trend on the figure shows a different type of attackers, while the total number of attackers stays between 5 and 20. The X-axis depicts the size of the network and the Y -axis shows the average value of k among all attackers.

Results and Implications: From the three figures, we can make the following observations. First, similar as in previous results, the value of k in all trends decreases almost linearly as the size of the network increases. Second, the trends of external attackers and malicious tenants decrease faster than the lower-layer provider. This is expected because the lower-layer provider already has access to all the hosts, which enables him/her to either use his/her privileges to attack higher layers, which means much lower k values and hence less room for further decrease as the network size increases. Finally, the most placement policy has the highest value of k both external attackers and malicious tenants and the lowest k for lower layer provider. This is because, under the most policy, the target tenant's VMs tend to stay closer to each other, which renders them less vulnerable to external attackers or malicious tenants, but more so to a lower-layer provider managing the hosts of such VMs. The objective of the next three simulations is to study how the different types of attackers behave under our attack mitigation solution. Figure 7 shows the simulation of applying the mitigation solution on the least placement policy for external attackers and malicious tenants, and the placement policy for the lower-layer provider. The three simulations are based on similar X and Y axis as in previous simulations. The solid lines represent the results after applying our mitigation solution under the constraints of the maximum number of VMs migration. The dashed lines represent the results before applying the mitigation solution.

Results and Implications: From the simulation results, we can make the following observations. First, our solution is improving the value of k in all cases. Second, all three simulations follow the same trend and the value of k improves when we increase the maximum number of VMs that are allowed to migrate, i.e., the cost of migration. Finally, improving the result for the lower-layer provider is difficult to attain because the low-layer provider already is assumed to have the power to access more than one host (based on the privilege he/she has) so migration has less effect. The objective of the last simulation is to study how the number of malicious tenants can increase insider threat under different placement policies, and how the mitigation solution may improve the value of k in each case. In Figure 8, the size of the network is fixed at 700 nodes, while the number of malicious tenants is varied between 0 and 25 along the X-axis. The Y -axis shows the average value of k among all malicious tenants. The solid lines represent the results after applying the mitigation solution, and the dashed lines are for the corresponding results before applying the solution.

Results and Implications: From the results, we can make the following observations. First, the mitigation solution successfully reduces the insider threat (increasing the average of k values) in all cases. Second, the results before and after applying the solution start with a sharp decrease prior to following similar linear trends (meaning increased insider threat) as the number of malicious tenants increase from zero. Finally, the result of the random placement policy after applying the solution is slightly better than the result of the most placement policy before applying the solution, which means that the mitigation solution may improve the placement algorithm w.r.t. the co-residency attack. To the best of our knowledge, this is the first work proposing a threat model specifically for NFV environments. On the other hand, many exists works focus on clouds. In particular, our previous work applies different threat modeling techniques to cloud data center infrastructures for different types of attackers [START_REF] Alhebaishi | Threat modeling for cloud infrastructures[END_REF]. Gruschka and Jensen devise a high level attack surface framework to show from where the attack can start [START_REF] Gruschka | Attack surfaces: A taxonomy for attacks on cloud services[END_REF]. The NIST emphasizes the importance of security measuring and metrics for cloud providers in [START_REF]Cloud Computing Service Metrics Description[END_REF]. A framework is propose by Luna et al. for cloud security metrics using basic building blocks [START_REF] Luna | A security metrics framework for the cloud[END_REF]. There exist other works focusing on insider threats in clouds [START_REF] Chinchani | Towards a theory of insider threat assessment[END_REF][START_REF] Alhebaishi | Mitigating the insider threat of remote administrators in clouds through maintenance task assignments[END_REF]. Chinchani et al. proposed a graph-based model for insider attacks and measure the threat [START_REF] Chinchani | Towards a theory of insider threat assessment[END_REF]. There are many works that focus on the co-residency attacks by improving the placement policy. Unlike our work which focuses on the cross-layer and co-resident threats and the application of threat models and security metric, existing studies on NFV security [START_REF] Lal | NFV: Security threats and best practices[END_REF][START_REF] Pattaranantakul | NFV security survey: From use case driven threat analysis to State-of-the-art countermeasures[END_REF][START_REF] Yang | A survey on security in network functions virtualization[END_REF][START_REF] Firoozjaei | Security challenges with network functions virtualization[END_REF] mostly focus on issues related to virtualization. Lal et al. [START_REF] Lal | NFV: Security threats and best practices[END_REF] propose to adapt several well-known best practices like VM separation, hypervisor introspection, and remote attestation to NFV. Pattaranantakul et al. [START_REF] Pattaranantakul | NFV security survey: From use case driven threat analysis to State-of-the-art countermeasures[END_REF] adapt best practices like access control to address virtualization-related threats in NFV. Our cross-layer resource graph model is partially inspired by existing works [START_REF] Sun | Inferring the stealthy bridges between enterprise network islands in cloud using cross-layer bayesian networks[END_REF][START_REF] Sun | Towards actionable mission impact assessment in the context of cloud computing[END_REF] in which Sun et al. use a crosslayer Bayesian network to measure security threats for enterprise networks [START_REF] Sun | Inferring the stealthy bridges between enterprise network islands in cloud using cross-layer bayesian networks[END_REF] and additionally they employ a multi-layer attack graph to measure security in clouds [START_REF] Sun | Towards actionable mission impact assessment in the context of cloud computing[END_REF].

There also exist related works on other aspects of NFV security. Firoozjaei et al. [START_REF] Firoozjaei | Security challenges with network functions virtualization[END_REF] show how multi-tenancy and live migration can affect the security on NFV by using a side-channel and shared resource misuse attack. Alnaim et al. [START_REF] Alnaim | Threats against the virtual machine environment of nfv[END_REF] uses architectural modeling to analyze security threats and the possible mitigating solution for NFV; their model is relatively abstract and only considers a malicious tenant to exploit vulnerability when he/she co-resides with the target VM on the same physical machine. Tian et al. propose a framework that uses a hierarchical attack and defense model which divides the 5G network to four layers (physical layer, virtual layer, service layer, and application layer) [START_REF] Tian | Automated attack and defense framework for 5g security on physical and logical layers[END_REF]. Basile et al. [START_REF] Basile | A novel approach for integrating security policy enforcement with dynamic network virtualization[END_REF] propose to add a new policy manager component to enforce security policies during deployment and configuration of security functions. Coughlin et al. [START_REF] Coughlin | Trusted click: Overcoming security issues of NFV in the cloud[END_REF] integrate trusted computing solution based on Intel SGX to enforce privacy with secure packet processing.

Conclusion

In this paper, we have modeled cross-level and co-residency attacks in the NFV stack. We have also formulated the optimal VNF/VM placement problem to mitigate the security threats through standard optimization algorithm. Furthermore, we conducted simulations whose results showed that our solution could significantly reduce the level security threats in NFV. Our future work will focus on following directions. First, we will make our solution incremental and more efficient in order to handle more dynamics in terms of VM placement and immigration. Second, we will consider weighing different exploits and asset values to optimally choose among those different options for a given NFV application. Finally, we will study the integration of our solution with existing deployment policies based on an NFV testbed.

Fig. 3 :

 3 Fig.3: An example of cross-layer resource graph (FW: firewall, LB: load balancer, DB: database, MIMA: man in the middle attack, SCA: side-channel attack)

  and the set of their pre-and post-condition C, a same-layer resource graph is a directed graph G(E ∪ C, HR r ∪ HR i ) where pre ⊆ C × E and post ⊆ E × C are the pre-and post-condition relations, respectively.

Fig. 4 :

 4 Fig. 4: Use Cases A and B (FW: firewall, LB: load balancer, DB: database, MIMA: man in the middle attack, SCA: side-channel attack, AE: external attacker, AI: insider attacker, BCL: cross-layer attack, BOL: one-layer attack)

  resource grapgh VS Original resource grapgh Original Resource Grapgh without Malicious Tenant Original Resource Grapgh with Malicious Tenant Cross-layer Resource Grapgh

Fig. 5 :

 5 Fig. 5: Comparing the original resource graph and cross-layer resource graph

6 :

 6 Comparing the three placement policies in CloudSim

Fig. 7 :

 7 Fig. 7: Applying mitigation solution with the maximum number of VMs migrating

Fig. 8 :

 8 Fig. 8: The results of the mitigation solution under different placement policies

Table 1 :

 1 The optimal solution to the motivating example (Section 2.3)

	Host		VM / VDU				VM / VDU
	1	app A	app B	DB A DB B		app A	app B	DB A DB B
	2 LB A / Switch A Router A http B http A LB A / Switch A FW A / IDS A http B http A
	3	FW A / IDS A FW B / IDS B http M Router B	Router A	FW B / IDS B http M Router B
		Before mitigation k = 2		After mitigation by tenant k = 4
		Host		VM / VDU
		1	app A	app B	DB A FW A / IDS A
		2 LB A / Switch A Router A http B	http A
		3	DB B	FW B / IDS B http M Router B
			After mitigation by provider k = 5

  Han et al. introduces a new strategy to prevent attackers from achieving co-residency by modifying the placement policy on CloudSim[START_REF] Han | Virtual machine allocation policies against coresident attacks in cloud computing[END_REF].Madi et al. propose a quantitative model and security metric for multi-tenancy in the cloud at different layers[START_REF] Madi | Quantic: Distance metrics for evaluating multi-tenancy threats in public cloud[END_REF]. Atya et al. study co-residency in clouds and suggest solutions for the victim tenant to avoid co-residency with malicious users[START_REF] Atya | Catch me if you can: A closer look at malicious co-residency on the cloud[END_REF].

Acknowledgements. The authors thank the anonymous reviewers for their valuable comments. This work was partially supported by the National Science Foundation under grant number IIP-1266147, by the Army Research Office grant W911NF-13-1-042, and by the Natural Sciences and Engineering Research Council of Canada under Discovery Grant N01035.