Several types of research have been published that relate the situation of the trust in the cloud infrastructure, justified through a technical mechanism. Susan F. Crowell says [30] regarding the VMs trust, for virtual machine trust isolation in an IaaS cloud environment, embodiments of the invention monitor level of suspicious activities on the particular virtual machine using embedded node agents. Crowell addresses the critical problems of VMs over the cloud, for example, to create a trustworthy cloud infrastructure by designing a security audit system: verify clients’ data confidentiality and integrity [32], measure virtual machines root-of-trust [31], enforce by a technical mechanism not only by Service Level Agreements (SLAs) contracts.
In this chapter, we present a model for network forensics to investigate security threats (malicious attacks) when machines communicate with each other in a cloud environment. The forensics process model (shown in Figure 2.1) depends on five process-layers that interact with the control manager, and the adaptation of the process-layers from the flow of the process of the NIST network forensics model [33]. The process-layers perform independent tasks regarding the incident investigation of cloud computing security issues. The investigational tasks execute a parallel and distributed manner in a multitenant environment. We already discussed the multitenancy in the above section 2.1.3.2.
In this section, we describe the purpose of an individual process-layer; the first process-layer is the collection of data or data collection layer, in which overall data is captured. The control manager interacts with the data collection and decides when to start or stop the data capturing process. The data collection coordinates with the migration of VM in the cloud environment and the control manager simultaneously collects data traffic of VM migration. On the next process-layer is the separation or filtration; the actual task of the process-layer is to filter captured data by cloud user. The main advantage is that each set of data maintains data accordingly to the single cloud users. Additionally, separation can compress user-specific collected data; reduce the size, and filtering forensically network data traffic.
Figure 2.1 Network forensics process model for cloud investigation.
In the third process-layer, the accumulator or aggregate layer deals with the adds data from multiple sources of a single cloud user. The cloud user utilizes resources from distinct physical locations such as load balancing then the accumulator collects all data from multiple source location. Furthermore, this layer helps to collaborate with all the network data into a single set. The fourth layer is data analysis, analysis of the preprocessed data set for the detailed investigation. The control manager configures the complete transmission from data capture to the accumulation layer, analysis process-layer is run as a cloud service in the cloud environment. The last process-layer is documentation, which presents the analysis results and consequence to tackle the entire security threats.
The proposed forensics network architecture for secure machine communication translates the conceptual blocks of separate services as described in Table 2.1.
Table 2.1 Network forensics architecture conceptual block of the model.
| Name of network forensics process-layer | Task description |
| The Control Manager | Manage cloud infrastructure;An interface configures and controls the forensics process;Authorize forensics request;Target cloud users VMs;Delegate to a third party. |
| Data Collection/Collection of Data | Execute on the local VM;Monitor physical host;Collect network traffic at the VMM level;For an update, dynamically reconfigure;Start/stop data collection. |
| Separation/Filtration | Filtering data individual cloud user;Investigate distinct nodes on the particular physical host;All forensics investigations independently investigated;Separate datasets to a single cloud user;Filtering and reduce the network traffic size;Monitor specifically cloud users;The proposed architecture uses VMs lookup table;Filtering ID, Mac addresses for further investigation. |
| Accumulator/Aggregation | Filtration process-layer provides data;Collect data;Capture from the several locations;Combine data. |
| Analyzation | Potentially support multiple possibilities;Transfer the accumulator layer output to the investigator;A user of the cloud deploy analysis as a cloud service;Run analysis on the cloud. |
| Documentation | Produce a report on the basis of analysis results;Presentation of analysis outcomes. |
2.3 Model Implementation
In this section, we have implemented the model of the prototype architecture described in section 2.2. In the implementation phase, we extend some crucial components that are usable for network forensics investigation on the cloud environment; the prototype implementation of the proposed architecture assumption are as follows:
An account of individual cloud user VMs managed by CSP;
Cloud users able to run/stop the process of data collection for forensics investigation;
Monitor the VMs for cloud security perspective and also ensure the M2M secure communication;
Inside the cloud, a web-based system created and used to analyze the collected data.
In this chapter, we clarify that the users are able to work with the VMs, to change their status individual and also monitor the overall activity parameters of VMs. Our proposed architecture slightly extends the software management for control of network forensics by adding some application programming interface. Using OpenNebula [34, 35], an open-source active community-based cloud management system, it supports more distinct and independent VMMs products. The main objective is to create an interface of analysis tool to capture malicious threats that run as a service in the users’ cloud VMs. In this scenario, NetworkMiner [36] an open-source network forensics analysis framework, helps to analyze collected forensics data within the cloud [38]. The next couple of sections briefly elaborate on the complete mechanism of the OpenNebula and NetworkMiner analysis tool.
2.3.1 OpenNebula (Hypervisor) Implementation Platform
In the model architecture, the control manager is the add-on extension of the OpenNebula application programming interface (shown in Figure 2.2) that we already discussed in section 2.3. The cloud user request to the control manager for accessing on-demand