Applying the Logging Components to Mitigate

Although this thesis focuses on dealing with the CSA threats to IaaS, these threats aect the security of PaaS and SaaS as well [23]. PaaS can always be built up by adding extra layers on top of IaaS layers as discussed in the beginning of Section 2.2. Therefore, comprehension of our proposed logging components and of logging systems in IaaS could also assist the mitigation of the risks associated with the CSA threats applicable to the security of PaaS.

For example, it is possible that ones can add the extra layers on top of our proposed logging components to build up the logging components for PaaS such as in [22] an integration and middleware layer can be added on top of IaaS to build up PaaS. Then, they can consider the possible and appropriate locations of Px and Fy in this new PaaS logging components. These new locations of Px and Fy in the PaaS architecture could aect their security concerns the same as we discussed for our logging components for IaaS in this thesis.

3.5.2.8 A TCB size measurement of a logging system in the cloud based on the logging components

Figure 3.6: The biggest TCB size, the dot rectangle

software system) can be used to evaluate the trustworthiness of that system. We can dene the size of TCB of a logging system based on the logging components as the set of all hw, a hypervisor, dom0, and domU. TCB size of a logging system can be compared to the TCB size of another logging system. For example, the TCB size of a logging system, which includes all components (hw, a hypervisor, dom0, and domU) is bigger than the TCB size of another logging system, which includes only hw, a hypervisor, and dom0.

The biggest TCB size of a logging system is when this system deploys P3 in domU user level (Figure3.6). In this case, this TCB size includes hw0, hypervisor, dom0, and domU. The size includes domU because this deploys P3. Figure 3.7

is the smallest TCB size of a logging system, when the system deploys P5 in hypervisor. In this case this TCB size includes only hw0 and hypervisor. The size does not include dom0 and domU because there is no any logging process is deployed in dom0 and domU. Thus, if all logging processes are only in the hypervisor, the TCB size includes only the hw0 and hypervisor. This TCB size is the smallest one.

3.6 Conclusions

This chapter addressed Gap 1 (c) which is the lack of security analysis of the logging systems themselves before the deployment of the systems in to the IaaS real world productions, as discussed in Section1.2. The previous chapter provided a holistic representation of the environment of logging systems in the cloud. This representation is utilised as the basis for the design of a generic framework of logging solutions to mitigate the risks associated with CSA threats (Objective 2). We call this framework generic logging components for infrastructure as a service (IaaS) cloud.

Thus, the main contribution of this chapter was these generic logging compo- nents. To facilitate the systematic support for accountability in the cloud, these generic logging components provide ways to build logging systems. The value of the generic logging components is to encompass all possible instantiations of logging solutions for the 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 their deployment. Thus, the generic logging components enable logging systems to be appropriately designed or manipulated by participating cloud parties in- cluding a provider, customer, or auditor. As as result, this enhances systematic support for accountability in the could.

In the next chapter (Chapter4), the generic logging components are utilised as the basis for describing the related work in the form of patterns. These patterns can be made up of the logging components or can be associated to the logging component congurations. The advantages and disadvantages encountered when using dierent patterns can be used to clarify the fact that a number of patterns and logging system architectures based on these patterns are missing, for example, our proposed logging system in the spamming case study in Section 3.4.2. The proposed system is based on a pattern that is quit specically more easily to be deployed, but it is not very robust. Chapter 4 also discusses a "spectrum" of patterns for describing how to construct logging systems of varying quality. It also presents sophisticated examples or case studies to illustrate and evaluate the proposed patterns.

The generic logging components are also utilised (in Chapter 5) as the basis for an analysis of how real world threats, specically CSA threat 1, aect both the customer and provider simultaneously. It is also used as the basis for design of the proposed logging solutions in mitigating the risks associated with threat 1, in order to benet both the customer and provider sides.

Chapter 4

Logging System Architectures and

Patterns

This chapter mainly addresses research Gap 4, which is the lack of descriptions of logging systems in terms of design patterns of the systems' components. Its main contribution is three proposed design patterns in the context of logging in IaaS cloud. The proposed patterns facilitate analysis of logging systems.

The proposed patterns can also bring a number of benets as the same as benets from design patterns in object-oriented software design and development area. Thus, the proposed patterns could increase reusability of the design and development of logging systems. Moreover, designers should access the proposed patterns more easily. Additionally, the proposed patterns could assist a designer adopts design approaches which make a logging system reusable and not to choose approaches which do not concern reusability concepts. Lastly, they proposed patterns can also enhance the documentation and maintenance of existing logging systems.

We provide a spectrum of patterns for describing how to construct logging systems with varying characteristics. For developers, when building a logging system, the knowledge of characteristics of this system could assist 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.

Thus, this chapter intends to dene, identify, and draw conclusions on the advantages and disadvantages of logging system patterns. Then it analyses ex- isting works in relation to the patterns. These patterns can be made up of the generic logging components in Figure3.1or can be associated to the logging com- ponent congurations. This chapter also discusses a "spectrum" of patterns for describing how to construct logging systems of varying quality or characteristics. It also presents sophisticated examples or case studies to illustrate and evaluate the proposed patterns.

Section 4.1 investigates and introduces 93 possible architectures of a logging system in an IaaS. These architectures are divided into three categories. It also discusses the structure and example of architectures of each category in details. Associated with the possible architectures, Section 4.2 identies and gives con- clusions on the advantages and disadvantages of logging system patterns. First of all, the section discusses a denition of a pattern in general and in object-oriented software design and denes a pattern in logging system design and development. It then identies and discusses three patterns for logging systems. After that, it gives conclusions on the advantages and disadvantages of the patterns.

Then, Section 4.3 analyses existing logging and monitoring works and our proposed system in relation to the patterns. To do so, it discusses advantages and disadvantages or characteristics of ve existing systems, as well as our proposed system for spam. Lastly, the chapter is briey summarised and concluded in Section 4.4.

4.1 All possible architectures of a logging system

This section investigates and introduces 93 possible architectures of a logging system in an IaaS. These architectures are divided into three categories. It also discusses the structure and example of architectures of each category in details.

All these possible architectures are formed based on the critical components or Px and Fy in the generic logging components in Figure3.1. These components are in three domains: dom0, domU, and hypervisor. P1 and P2 are in dom0 user level and kernel level respectively. P3 and P4 are in domU user level and kernel

level, respectively. Lastly, P5 is inside a hypervisor. For Fy, it is assumed that if a logging system architecture deploys F1 in diskU or F3 in disk0, it then needs to eventually deploy F2 in memU or F4 in mem0 respectively. The deployment of Fy is already discussed in Section 3.3.1.

Any concrete logging system will be based on one of the 93 possible archi- tectures discussed in Section 4.1.1 to 4.1.3. Based on our investigation in the literature in this thesis, a few of the possible architectures exist. However, the non-existing ones can be interesting. For example, an architecture that deploys all nine Px and Fy, it is the most complicated architecture that is not existing and will be discussed in Section 4.1.3. One of the architecture's advantages is having many abilities to facilitate logging tasks including: to record the necessary logging data as log les across domU and dom0; and/or to assist in collaboration of Px and Fy with other components such as database components.

Reducing TCB size of a logging system is one of the three aspects of systematic support for accountability in IaaS, as discussed in Section 1.1, 2.13, and 3.5.2.8. One of disadvantages of the most complicated architecture is having a big TCB size of the system. This is because Px and Fy are deployed and distributed across all the three domains (domU, dom0, and hypervisor).

In contrast, for the most simple architecture as will discussed in Section4.1.1, the architecture may not be able to record the necessary logging data across domU and dom0 compared to the most complicated one. The system TCB size is smaller than the TCB size of the most complicated one.

To simplify the presentation of all the possible architectures, they are divided into three categories called: single domain, two domains, and three domains. A single domain category means that all Px of a logging system are deployed in either dom0, domU, or a hypervisor. A two domains category means that all Px of a logging system are deployed in two domains among dom0, domU, or a hypervisor. A three domains category means that Px are deployed in all three domains, thus at least one Px of a logging system is deployed in each domain.

The 93 possible architectures compose of: 21 architectures in the single domain category, 45 architectures in the two domains category, and 27 architectures in the three domains category. The following subsections will clarify how each category gets the number of architectures. Below are conditions of all categories:

1. Each logging system architecture from these three categories has to deploy Px based on its category's conditions which will be discussed in the following sections. Eventually, the system has to deploy Fy by choosing one from these three dierent approaches of deploying Fy: in disk0, in diskU, or in both disk0 and diskU which we call disk0U.

2. When a system is deployed in dom0, its Px can be in: dom0 user level as P1, dom0 kernel level as P2, or both of them

3. When a system is deployed in domU, its Px can be in: domU user level as P3, domU kernel level as P4, or both of them.

4. When a system is deployed in a hypervisor, its Px can be in only this hypervisor as P5.

5. The notation PaPb such as P1P2 means that when an architecture or a sys- tem deploys both Pa and Pb. Thus, P1P2 means that when an architecture or a system deploys both P1 and P2.

6. PbPa has the same meaning as the meaning of PaPb.

7. In forms such as Pa/Pb, Pa/disk0, PaPb/PcPd, or PaPb/Pc/Pd/diskU, '/' is a separator notation among the elements of the forms. For example, Pa/disk0 indicates that Pa is in a domain and disk0 is deployed by a system that deploys Pa.