This thesis provides a number of key contributions to address the research gaps, and to satisfy the aims and the objectives stated above:
1. An in-depth background and literature review of CSA threats and systematic support for accountability
This contribution addresses research Gap 1. The background and litera- ture review summarises the key concepts: IaaS, CSA threats to IaaS, ac- countability/logging approaches to mitigate risks and the problems of the approaches, and systematic support for accountability in the cloud.
This summary diers from previous work which focus on dealing with cloud problems without full consideration of the main involved/systematic aspects to provide logging systems. For example, previous work does not fully discuss the security analysis of logging systems themselves before deploying them into the real world IaaS productions. Without the consideration of the systematic aspects, it is di cult to e ciently and eectively enable logging systems.
The value of the systematic approach is to provide clear visions of logging systems, development in the cloud, such as the security analysis of the sys- tems. Then, the systematic approach can e ciently and eectively enable accountability in the cloud. This is because accountability in the cloud is the most important concept to assist in mitigating the risks associated with CSA threats.
2. Generic logging components for IaaS cloud
This contribution addresses research Gap 1 (c). To facilitate systematic support for accountability in the cloud, generic logging components provide
ways to build logging systems. The value of theses components is to en- compass all possible instantiations of logging solutions for IaaS cloud, and to provide a clear view of all components that relate to logging systems in IaaS. This view provides a basis for the analysis of logging systems, security before deployment.
Thus, the generic logging components enable logging systems to be appro- priately designed or manipulated by participating cloud parties such as a provider, customer, or auditor. As result, this enhances systematic support for accountability in the could.
3. Analysis of how CSA threat 1 aects both the customer and provider side simultaneously; and the proposed logging solutions to assist in mitigating risks associated with the threat for both sides
This contribution addresses research Gap 1 (a). The analysis illustrates how CSA threat 1 (mis-usage of customer VMs) can aect both sides. This analysis diers from previous work which usually focuses on the eects of the threats to only either the customer side or provider side, providing solutions for either side, but not for both.
The value of the combined analysis is to provide a basis to understand what the contents are that logging solutions need to collect to be used as evidence to deal with threat 1 for both customers and providers.
4. The design of our proposed logging system yields a smaller trusted computing base or TCB size compared to previous work
This contribution is that the size of the TCB for the design of our proposed logging system is smaller than TCB sizes of the proposed logging systems of previous works. This contribution addresses research Gap 1 (b).
All logging related components, for example an introspection tool and logger application, deployed in building the proposed logging system are inside dom0. Thus, the proposed system in our prototype implementation yields a smaller TCB while obtaining the history of critical les. This is because
the TCB of our architecture includes only a hypervisor1 and dom0, not a
customer VM. In contrast, previous work have placed some of their logging related components in customer VMs. Other previous works that deploy the same introspection tool as we used yield the same TCB as ours. However, they are not designed to obtain the history of critical les.
5. Collecting le-centric logs rather than system-centric logs
This contribution is that our proposed logging solutions focus on collecting le-centric logs rather than system-centric logs. This is because research Gap 2 states that current logging research in the cloud focuses on system- centric logs, while neglecting le-centric logs.
There are some logging solutions that emphasise le-centric logs with an interception approach. However, the prototype implementation of the pro- posed logging system can be an alternative approach to collecting le-centric logs to enhance accountability in IaaS. This approach facilitates introspec- tion of customer VM's memory from dom0. The introspection traverses the kernel data structures in the memory.
The prototype implementation of the proposed logging solutions can collect a le-centric log history of customers' critical les. The history information is of le-centric logs rather than system-centric logs. The le-centric logs can present the associations between a process and les in a customer's VM, for example, a record of a process P reads le F. The proposed log les dier from previous works which focus only on system-centric logs including the connection topology, bus speeds, and processor loads.
6. Presentation of how the results from the proposed logging system assist in mitigating the risks associated with threat 1
This contribution is that we provide many scenarios to present how the results from the prototype implementation can be used to form log les to assist in mitigating the risks associated with threat 1 for the bene t of both customers and providers. This contribution addresses research Gap 3. 1software running on a physical machine and allows the machine to run multiple OSs at the
To assist in mitigating the risks associated with threat 1 to bene t cus- tomers, we discuss formation of a history of critical les from the results of the prototype implementation. This includes analysing nine scenarios of malicious incidents in a customer VM when, for example, a customer shares her VM with other users.
To assist in mitigating risks associated with threat 1 (e.g., when criminals use VMs to conduct spamming activities) to bene t providers, we discuss the formation of process behaviour log les. This shows that our proposed solutions can assist in mitigating the risks associated with real world IaaS issues and many scenarios, and can bene t both customers and providers. 7. Three proposed design patterns in the context of logging in IaaS
cloud
This contribution addresses research Gap 4. The proposed patterns facil- itate analysis of logging systems in terms of their quality. These patterns could increase reusability of the design and development of logging sys- tems. Designers should access these patterns more easily. The patterns could assist a designer adopts design approaches which make a logging sys- tem reusable and not to choose approaches which do not concern reusability concepts. The patterns can also enhance the documentation and mainte- nance of existing logging systems.
We provide a spectrum of patterns for describing how to construct log- ging systems with varying characteristics. For developers, when building a logging system, the knowledge of characteristics of this system could as- sist them to get the right design of the system with minimal eort and time commitments. We also clarify why a number of patterns and logging system architectures based on these patterns are missing. To the best of our knowledge, these three logging patterns are not yet described in the literature.