A Case Study of an Identication of the Appropriate Log-

to Mitigate the Risks Associated with CSA Threat 1

This subsection is another case study to demonstrate how to use the logging components. This case study is an identication of the appropriate logging system based on the logging components to mitigate the risks associated with CSA threat 1. This subsection includes (for this case study): design and implementation of

the logging system, how to run the experiment, the result, and the analysis of security of the logging system.

In order to satisfy the goals of the logging components, this case study demon- strates how to use the logging components to instantiate the logging system ar- chitecture, and how to analyse the security of this new built architecture.

3.4.2.1 Design and Implementation of the Logging System

This logging system architecture is designed and based on the logging compo- nents. Thus, we can choose some components from the logging components (Fig- ure 3.1 and Section 3.2-3.3) to build up the logging system. At the time of the experiment, we found libVMI [79] as the only available tool that can achieve the goal of the case study. This is an introspection library to read memory of VMs or domUs from dom0. We deployed libVMI as P1 in dom0 user level to read the memU of this spamming domU.

Therefore, we reuse libVMI as P1, then we choose F3 as log les to build the logging system architecture. As a result, Figure 3.3 shows the overview of the

Figure 3.3: The logging system architecture to mitigate the risks associated with threat 1.

newly designed logging system architecture according to this case study's goal. It is quite clear that the new architecture is composed of only P1 or libVMI, F3

or log les, F4 or temporary log data, and app0 or a logging application.

This case study simulates spam activities by assuming that spammers rent a Linux VM or domU from an IaaS provider. They then use appU (the mail command, see Figure 3.4 in the dot-line box) to send a spam email to a vic-

Figure 3.4: Spam activities performed by appU (mail command) in domU.

tim. The command (we call c1 ) used as simulation of spam activities is: mail -s spamSubj [email protected]. The mail command in c1 has three ar- guments. They are ag1 which is -s, ag2 which is spamSubj, and ag3 which is [email protected]. It sends string 'spamSubj' as an e-mail subject to the email address [email protected]. In order to capture ag2 and ag3, we assume that the logger application knows the name of the mail command in c1. The case study's goal is to enable a logging application to capture the arguments of c1 including ag2 and ag3, and then writes the captured ag2 and ag3 to a database as the log les as F3. These log les can be used by an auditor, a trusted third party, or a provider as the evidence to afterwards identify spam activities in this rented domU later. We assume that ag2 and ag3 are sucient to identify these spam activities.

3.4.2.2 Running the Experiment in this Case Study

We run the logging application inside the dom0 user level, see process-list com- mand line in the dot-line box in Figure 3.5. It keeps checking memU until c1 is performed. When c1 is performed as shown in Figure 3.4, then the logging application extracts the arguments of c1, which are ag2 and ag3 or the second and third lines from the bottom in Figure 3.5. The application then writes both extracted arguments to F3.

Figure 3.5: The logging application in dom0 extracts arguments of c1 (ag2 and ag3 ) as evidence for identifying spam activities.

3.4.2.3 The Result of This Case Study

The results in Figure3.4and3.5shows that we can use an application such as the logging application in dom0 to capture information in memU or in the memory space of any process, or commands of appU such as c1 in domU.

We now have an appropriate logging system to mitigate the risks associated with CSA threat 1. However, this system is in the IaaS which involves at least two parties including a provider and customer. Hence, the system's security needs to be analysed before deployment as described in Section 3.4.2.4.

3.4.2.4 Analysing the Security of our Logging System

The proposed logging system architecture in the implementation is systematically designed based on the logging components. Therefore, it inherits the advantages of the logging components. For example, one of the advantages is an architec- ture that is based on the logging components can be used as a tool to analyse the security of logging processes and log les, which are distributed across the IaaS visualisation environment. Thus, one can analyse the security of the logging system architecture in the implementation. We provide an approach to systemat- ically analyse the security of logging systems before deploying them in the IaaS real world productions.

Ideally, these analyses needs to be completed before deploying our logging system. We can directly use the logging system architecture, Figure3.3, as a tool for our analyses, as discussed in the lists below.

• Analysis of the integrity issues of the logging system

From the architecture of the logging system in Figure 3.3, our system de- ploys P1 in the dom0 user level, this may lead to integrity issues of this logging system. This is because malicious insiders may modify P1's code to produce contents of log les which benet themselves, as discussed in Section 3.3.3.1.

• Analysis of the privacy issues with our logging system

The question is where F3 be located. From the architecture in Figure 3.3, it will be located in disk0. Again, malicious insiders may learn about, or alter F3, which is a privacy violation to a customer, as discussed in Sec- tion 3.3.3.2.