Wuqiong Pan
email: wqpan@lois.cn

Yulong Zhang
email: zhangy44@vcu.edu

Jiwu Jing
email: jing@lois.cn

Improving Virtualization Security by Splitting Hypervisor into Smaller Components

Keywords: VMM, Hypervisor, Cloud computing, TCB

In cloud computing, the security of infrastructure is determined by hypervisor (or Virtual Machine Monitor, VMM) designs. Unfortunately, in recent years, many attacks have been developed to compromise the hypervisor, taking over all virtual machines running above the hypervisor. Due to the functions a hypervisor provides, it is very hard to reduce its size. Including a big hypervisor in the Trusted Computing Base (TCB) is not acceptable for a secure system design. Several secure, small, and innovative hypervisor designs, e.g., TrustVisor, CloudVisor, etc., have been proposed to solve the problem. However, these designs either have reduced functionalities or pose strong restrictions to the virtual machines. In this paper, we propose an innovative hypervisor design that splits hypervisor's functions into a small enough component in the TCB, and other components to provide full functionalities. Our design can significantly reduce the TCB size without sacrificing functionalities. Our experiments also show acceptable costs of our design.

Introduction

Virtualization techniques allow multiple operating systems (OSs) to run concurrently on a host computer. By sharing hardware, resource utilization can greatly be improved. Virtualization is also the key technology of cloud computing. Some software, such as Xen [START_REF]Xen hypervisor project[END_REF], can provide hardware virtualization by adding a new software layer called hypervisor beneath all Virtual Machines (VMs). A hypervisor emulates independent hardware resources for every VM. Both Intel and AMD have developed new extensions [START_REF] Neiger | Intel virtualization technology: Hardware support for efficient processor virtualization[END_REF][START_REF] Amd | Secure virtual machine architecture reference manual[END_REF] for hardware based virtualization, which can simplify hypervisor designs.

In cloud computing, legal users and attackers may share the same physical server. Thus, it is important to isolate VMs from each other. In a virtualization architecture, the hypervisor is responsible for isolation. In current hypervisor designs, it also emulates the hardware and provides other security functions for VMs. Many researchers argued that the current hypervisor designs include too many functions [START_REF] Keller | Nohype: virtualized cloud infrastructure without the virtualization[END_REF][START_REF] Szefer | Eliminating the hypervisor attack surface for a more secure cloud[END_REF]. For an example, Xen has about 270k lines of codes (LOC), which is difficulty to implement without bugs. Unfortunately, many vulnerabilities in hypervisor have already been discovered [START_REF] Kortchinsky | Hacking 3d (and breaking out of vmware)[END_REF][START_REF]Cve-2007-4993: Xen guest root can escape to domain 0 through pygrub[END_REF][START_REF]Vulnerability in xenserver could result in privilege escalation and arbitrary code executionr[END_REF][START_REF] Wojtczuk | Subverting the xen hypervisor[END_REF][START_REF]Cve-2008-2100: Vmware buffer overflows in vix api let local users execute arbitrary code in host os[END_REF][START_REF] Ristenpart | hey, you, get off of my cloud! exploring information leakage in third-party compute clouds[END_REF].

To address the problem, a lot of efforts [START_REF] Keller | Nohype: virtualized cloud infrastructure without the virtualization[END_REF][START_REF] Szefer | Eliminating the hypervisor attack surface for a more secure cloud[END_REF][START_REF] Chen | Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems[END_REF][START_REF] Chhabra | Secureme: a hardware-software approach to full system security[END_REF][START_REF] Ahmed Azab | Sice: A hardware-level strongly isolated computing environment for x86 multi-core platforms[END_REF][START_REF] Champagne | Scalable architectural support for trusted software[END_REF][START_REF] Zhang | Cloudvisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization[END_REF] have been made to improve the isolation. Among these work, Overshadow [START_REF] Chen | Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems[END_REF] provides fine-grained isolation which protects applications from a compromised OS. SecureME [START_REF] Chhabra | Secureme: a hardware-software approach to full system security[END_REF] has the same function and can defend against hardware attacks by using a secure processor substrate. Bastion [START_REF] Champagne | Scalable architectural support for trusted software[END_REF] defines a struct of module and protects it from hardware attacks. Overshadow, SecureME and Briston can provide fine-gained isolation for applications or modules. These work add new functions to the hypervisor. As a result, the size of the hypervisor is increased. Therefore, the added codes increase the size of TCB and they may introduce new vulnerabilities as well.

In contrast, some efforts try to reduce the number of functions provided by a hypervisor to make the hypervisor, thus TCB, smaller. For examples, SICE [START_REF] Ahmed Azab | Sice: A hardware-level strongly isolated computing environment for x86 multi-core platforms[END_REF] provides hardware isolation for one workload on a core by using the System Management Mode (SMM) of x86 processors. NoHype [START_REF] Keller | Nohype: virtualized cloud infrastructure without the virtualization[END_REF][START_REF] Szefer | Eliminating the hypervisor attack surface for a more secure cloud[END_REF] eliminates the hypervisor attack surface by removing the hypervisor after booting the guest VMs. NoHype pre-allocate resources for a VM before the boot procedure. CloudVisor [START_REF] Zhang | Cloudvisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization[END_REF] can protect VMs from a compromised hypervisor by adding an additional hypervisor layer. These new designs also introduce some restrictions. For examples, both SICE and Nohype have the limit of one protected workload, or VM per core on multi-core processors. Also, NoHype does not support dynamic resources allocation. CloudVisor does not allow hypervisor to access VM pages and it becomes a big burden for CloudVisor to determine which pages of the guest VMs can be accessed by the master hypervisor.

Moreover, the security problem of shared management domain (or hypervisor in CloudVisor) are not completely eliminated in afore mentioned designs. For examples, in NoHype design, the attackers can attack the management VM. Although the management OS may be well configured by cloud provider, an OS is usually considered more vulnerable to attacks than a hypervisor. In CloudVisor design, a new hypervisor is used to intercept all communications between the master hypervisor and VMs. Even though the attack surface is smaller, once the master hypervisor is compromised, all VMs can still be affected.

In this paper, we propose a split hypervisor architecture, called SplitVisor, which has a small TCB and does not limit the functions of a hypervisor. Our architecture leverages nested virtualization [START_REF] Ben-Yehuda | The turtles project: Design and implementation of nested virtualization[END_REF][START_REF] Goldberg | Architecture of virtual machines[END_REF]. In our design, every VM has its own hypervisor, called GuestVisor. Users can customize the GuestVisor. A SplitVisor is underneath all GuestVisors and VMs. The SplitVisor is responsible for isolation, which is the only part in TCB.

Table 1 shows the comparison of the proposed architecture and existing ones. SplitVisor, CloudVisor and SICE are the only ones which have a small TCB. All of them sacrifice some of hypervisor functions except SplitVisor. SplitVisor is the only one which has a stable TCB, which means that the TCB need little or even none of change when adding new functions to hypervisor. All others need to modify the TCB if they add new functions to the hypervisor. A stable TCB can greatly reduce the verification costs when upgrading secure software. SplitVisor, CloudVisor, and SICE can defend against attacks from a compromised hypervisor. The security of SICE is ensured by the SMM mode of x86 processors while the security of SplitVisor and CloudVisor are ensured by a nested architecture. CloudVisor can block a hypervisor from accessing its VMs' data. The protected units of these work are also different. Only SplitVisor, CloudVisor, and Nohype have a VM as the unit of protection. Other work either have applications [START_REF] Chen | Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems[END_REF][START_REF] Chhabra | Secureme: a hardware-software approach to full system security[END_REF], or hardware [START_REF] Lie | Architectural support for copy and tamper resistant software[END_REF][START_REF] Lie | Implementing an untrusted operating system on trusted hardware[END_REF][START_REF] Suh | Aegis: architecture for tamper-evident and tamper-resistant processing[END_REF][START_REF] Chhabra | Making secure processors os-and performance-friendly[END_REF], as the unit of protection, which are out of the scope of this paper. These protections are still compatible with SplitVisor design. The main contributions of our work include:

-A small and stable TCB. Both GuestVisors and the management OS are not in the TCB. They cannot access other VMs. Most of functions can be added to GuestVisors without modifying the TCB. -Supporting full-functions. Unlike other architectures which have a small TCB, SplitVisor does not eliminate any functions from hypervisors. -Allowing users to verify the execution environment. Users can get the assertion of the environment.

The rest of this paper is organized as follows. Section 2 discusses our goals and shows the whole architecture of SplitVisor. Section 3 describes SplitVisor in booting, memory management, scheduling and some other details. Section 4 compares SplitVisor with other recent work. Section 5 shows the related work in isolation. Section 6 gives an conclusion of the paper.

Overview

Design principles

Cloud services are usually provided using virtualization techniques. The examples are Amazon EC2 [START_REF]Amazon elastic compute cloud[END_REF], Eucalyptus [START_REF]Eucalyptus cloud computing software[END_REF], FlexiScale [START_REF]Flexiscale cloud computing services[END_REF], Nimbus [START_REF]Nimbus platform[END_REF], and RackSpace [START_REF]Rackspace hosting[END_REF]. In order to attract more cloud users, they continuously improve their products by adding more and more functions to the platform. As the result, the size of TCB, the hypervisor, also increases prominently. Table 2 shows the TCB size of Xen from version 2.0 to version 4.0 [START_REF]Xen hypervisor project[END_REF]. In the table, the size of Xen 4.0 hypervisor is six times as large as that of Xen 2.0. Although Xen 2.0 is more secure in term of hypervisor size, Xen 4.0 is more attractive to users because of the new features, such as Xen access control, I/O optimization, and Memory page sharing. Domain 0 and tools are also parts of the TCB in Xen in addition to the hypervisor, because they can access the data of all VMs. For an example, the xm tool can dump the memory of a VM.

A possible way to reduce the size of TCB is to remove Domain 0 and Xen tools from the TCB, which requires disabling some functions, or encrypting data to prevent accesses from Domain 0. However, this will limit the functionalities of Xen. Cloud providers usually try to provide as many functions as them can. But for a particular user, he may only need a small set of the functions. In SplitVisor, every user can choose a GuestVisor which serves as the current hypervisor. The user can choose a hypervisor with the necessary functions, then he will not suffer vulnerabilities of the unneeded functions. Although the GuestVisor still can be attacked by its own VM, the attack will not affect other GuestVisors and VMs. The isolation is ensured by the SplitVisor. Thus, the SplitVisor should have a small code base to ensure its security.

Assumptions

Our assumptions are described as follows.

Adversaries: We assume that the attackers can easily control a VM. For an example, the attackers can buy a VM. The attackers can invade a management OS and a rich-functions hypervisor. They can send any instructions in the name of the hypervisor. The attackers can also sniff I/O and steal users' OS images. We assume that the attackers cannot physically access the machines. The data centers are usually protected by well-trained guards. The cloud providers have no motivation to use malicious hardware. Using malicious hardware easily leaves evidence, which definitely ruins cloud providers' reputation. The cloud providers are usually famous companies, while cloud clients are usually small companies. They are not competitors in most cases.

Security Guarantees: The main goal of SplitVisor is to provide isolated environments for VMs. SplitVisor directly provides CPU isolation and memory isolation for VMs. Other security attributes can be achieved based on these two attributes. SplitVisor allows users to verify its TCB. Users can get evidence that their OSs run in the expected environment.

Non-Guaranteed goals: SplitVisor cannot guarantee the availability of a particular VM. If a VM cannot get CPU time slices from the management software, the VM will be blocked, but this is easily discovered by outside.

SplitVisor is not designed to defend against side-channel attacks. Xen provides Chinese Wall (CHWALL) policy, which can control the set of VMs on the same machine. Well-defined CHWALL policy can reduce side-channel attacks [START_REF]Xen users' manual v3.3[END_REF]. Besides hypervisor level policies, some applications also have built-in mechanisms to reduce side-channel attacks [START_REF] Witteman | Secure application programming in the presence of side channel attacks[END_REF].

Architecture

Both Intel and AMD have added new extensions to support the hypervisor layer, like Intel's Virtualization Technology for x86 (VT-x) and AMD's Secure Virtual Machine (SVM). With the new extensions, the Intel processors have two operation modes: virtual-machine extension (VMX) root mode and VMX non-root mode. In general, a hypervisor will run in VMX root mode and a guest OS will run in VMX non-root mode. The control information of VMX transition is stored in a data structure called virtual-machine structure (VMCS). A VMCS includes almost all environment parameters of a guest OS, such as registers.

SplitVisor has two types of components that belong to one hypervisor before: GuestVisors and a SplitVisor, as shown in Fig 1 . The SplitVisor runs in VMX root mode, while both the GuestVisors and VMs run in VMX non-root mode. Both GuestVisors and VMs have VMCSs. A GuestVisor's VMCS is controlled by the SplitVisor, and a VM's VMCS is controlled by a GuestVisor. Most requests from a guest OS are handled by the GuestVisor under it. A GuestVisor is responsible for the execution environment of a guest OS. If a user wants to add some functions into the current hypervisor layer, he can add them into the GuestVisor. The isolation among all GuestVisors and VMs is ensured by the SplitVisor. All VMX transition instructions are executed in the SplitVisor. The SplitVisor is also responsible for memory isolation.

The features of the SplitVisor, a GuestVisor and a VM are shown in Table 3. The SplitVisor does not provide a complete virtualized running environment to a GuestVisor. A GuestVisor knows that it is not running on the bare hardware. A VM runs in a virtualized environment emulated by a GuestVisor. A VM can be para-virtualized or full-virtualized. Security Analysis: If a GuestVisor is compromised, the SplitVisor will ensure other GuestVisors and VMs are not affected. In other words, the isolation is ensured. But the VM of the compromised GuestVisor is not protected.

Design details

Secure boot

The boot process of a computer is the first step to set up a secure environment for guest OS. In our design, the only trusted component is the SplitVisor. The secure boot process is described as follows.

First, verify the SplitVisor. Users can verify the SplitVisor, which is supported by a Trusted Platform Module (TPM) [START_REF]Tpm main specification[END_REF]. A TPM is an secure chip which can help to protect the integrity of the boot process and the SplitVisor. Users can also obtain the SplitVisor's public key with the help of the TPM.

Second, make a new image. The binary codes of both user's VM and GuestVisor should be provided by users. Users must encrypt all or part of the codes with a symmetric key. The symmetric key should be encrypted by the SplitVisor's public key, so the SplitVisor can decrypt it. All the plain text should be signed to protect against unauthorized modification. The total data sent to cloud server includes the following: encrypted image, encrypted symmetric key, plain data, signature over everything, and the public key certificate of the user (signer).

Third, prepare the environment of a GuestVisor. When the SplitVisor receives the above data from users. It will decrypt all data and verify the signature. If the verification goes through, the SplitVisor will set up the running environment for a GuestVisor. The allocation of memory and CPU is decided by the management software. The boot process of VM is controlled by the GuestVisor.

Fourth, authentication between the user and the guest OS. In traditional login, only OS verifies users. In cloud computing, we need two-way authentication, because attackers can run a malicious system, and try to trick user to login. Users can put the key in guest OS before sending it to cloud providers. When guest OS boots up in remote server, they can authenticate each other based on the key. All communication after that also should be protected by the key.

Boot process of the management VM: The management VM is the one we should boot first. The boot process is a little different at the first step and the second step. Cloud providers should get the public key of the TPM through some public channels. The making of the management VM's image is the same as that of others. However, the image must be stored in a disk, or other storage devices which can be easily read by a SplitVisor. All the memory except the SplitVisor's, CPUs and devices are belonged to the management VM at first. It will assign the resources to other VMs in the future execution.

Security analysis: Without the authentication key, a malicious OS cannot cheat users. Attackers cannot get the key which is encrypted in the second step. If attackers do not crack the key but modify the image, it will be detected when verifying signatures in the third step.

Memory management

Both Intel and AMD have extended two layer address translation to three layer address translation, called Extended Page- The SplitVisor will set up a default EPT for a GuestVisor. The SplitVisor assigns all allowed memory page to the GuestVisor at the beginning. The range of PFN is fixed, for an example, it always starts from 0. For further processing, SplitVisor will allow GuestVisor to read its own EPT.

After a GuestVisor is booted, it will prepare the environment for a VM. Firstly, GuestVisor sets up an EPT for the VM. The GuestVisor can get the addresses of its MFNs by reading its own EPT. It can keep some MFNs for its own use, and assign others to VM. Finally, GuestVisor write the address of VM's EPT to VM's VMCS.

When a VM is booted, SplitVisor will check its EPT to see if all the MFNs are from the GuestVisor. So a user cannot access others' MFN by booting VM. After the checking, the SplitVisor marks the EPT page as read-only.

A GuestVisor has two means to manipulate the address translation of a VM. One is to modify the VM's EPT, another is to modify the VM's PT. Modifying the PT is the same as shadow paging. Modifying the EPT is the same as that we support EPT functions between a GuestVisor and a VM. The only difference is that a VM's EPT is marked as read-only by the SplitVisor. Any modification of The SplitVisor allows a GuestVisor to transfer its memory to other GuestVisors, but the request must be originated by the GuestVisor who owns the memory. The SplitVisor un-maps the pages from the GuestVisor's and VM's EPT, and maps them to another GuestVisor. Then the SplitVisor adds all the pages to the EPT of the second GuestVisor, and the second GuestVisor can decide how to use it. Memory sharing is similar to memory transferring except some flags of the memory pages are different.

There is a trade off about whether the management software should be allowed to forcibly receive other VMs' memory. If it is allowed, the SplitVisor can reset the received pages to zero when they are remapped. But the management software can still observe the action of a GuestVisor when different pages are received. It will introduce a way to attack the GuestVisor and VMs. Therefore, our SplitVisor design does not allow it. In this situation, the GuestVisor may do not want to give up its memory even if it does not need it. We can charge more to the GuestVisor's owner, it is fair since the user pays more when using more resources. A problem of this strategy is that we cannot receive GuestVisor's memory when it is crashed. It is difficulty to know the crash for the SplitVisor. The SplitVisor can try to migrate the GuestVisor. If the GuestVisor does not respond , it is crashed. Then SplitVisor can reallocate its memory.

Table 4 shows the comparison of memory management in different designs. In CloudVisor design, VM management is implemented in a modified hypervisor above the bottom layer called CloudVisor. In SplitVisor design, VM manage-ment, memory transferring and memory sharing are controlled by GuestVisors. Thus, the GuestVisors have corresponding privileges to manage VMs. The only work of the SplitVisor is to check the page access permissions. Xen implements all functions in the hypervisor. If Xen wants to add new functions, it has to modify the hypervisor.

Scheduling and VMCS

The transition from the root mode to the non-root mode is called VM entry, while the opposite is called VM exit. The transitions are controlled by a VMCS. The SplitVisor creates a default VMCS for a GuestVisor and controls the scheduling of GuestVisors. A GuestVisor controls the scheduling of the VM running above it. For an example, A GuestVisor may provide many VCPUs to the VM for special purpose. All the VCPUs are managed by the GuestVisor.

Every time a GuestVisor gets a time slice, the SplitVisor will switch into the GuestVisor first. The GuestVisor decides on which VCPU to start and switches back to the SplitVisor, then the SplitVisor switches into the VM. Before switching into the VM, the SplitVisor must modify the VM' VMCS. Some fields in the VMCS should be rewritten by the SplitVisor, such as host registers, which determine the CPU status when returning from the VM. The rewriting should be done every time entering the VM, because the GuestVisor may modify the VMCS.

The SplitVisor does not handle VM exits of a VM. It transfers all VM exits to the GuestVisor except timer and some I/O interrupts. Operations causing VM exits are specified by a VMCS. A GuestVisor can configure VM exits by modifying a VM's VMCS. For an example, if a GuestVisor wants to intercept VM's system calls, it just modifies control filed of the 80h interrupt.

Table 5 shows the comparison of different scheduling designs. VCPU management is implemented in the hypervisor of CloudVisor, which gives the hypervisor opportunities to attack VMs. Xen implements all functions in the hypervisor. A problem of scheduling is who can get the next time slice. If a scheduling algorithm is implemented in the management software, the attackers can deny the service of a VM if they controls the management software. If the scheduling algorithm is implemented in the SplitVisor, its parameters cannot be changed dynamically. Xen implements the algorithm in the hypervisor, but the parameters can be modified in the management software. The security level is the same as the one implemented in the management software. The implementation in SplitVisor can be determined case by case. For an example, in Amazon EC2 the time sharing of VMs is predefined. For such situations, the scheduling algorithm can be implemented in the SplitVisor. Otherwise, it can be implemented in management software.

Interrupt and Device management

In order to meet the needs of cloud computing, some device manufactures added virtualization support to their products, as mentioned in [START_REF] Keller | Nohype: virtualized cloud infrastructure without the virtualization[END_REF]. If a device can support virtualization by itself, every VM can get its own devices. For such situations, the SplitVisor can simply distribute the interrupts and I/O ports to each GuestVisor. If devices do not support virtualization, all VMs have to share the devices. It can be implemented by front-backend drivers. The SplitVisor assign the devices to one GuestVisor. All request are handled by the special GuestVisor. From the SplitVisor's perspective, some GuestVisors have shared memory with the special GuestVisor, and the SplitVisor does not need to emulate the devices.

Functions of a GuestVisor

Most functions of the current hypervisors are implemented in the GuestVisor. The GuestVisor is the key to reduce the size of TCB. We list the possible functions of GuestVisor in this section. Different versions of GuestVisors, from light weight ones to the ones with full functionalities, can be provided to the user as options.

I/O encryption

The GuestVisor that controls devices may be controlled by attackers. The attackers can sniff the I/O data which pass through the devices. Some applications already have built-in mechanisms to protected I/O, such as Bitlocker and SSL. It is hard to decide whether I/O protection should be implemented in the hypervisor. It is more secure to be implemented in the hypervisor, while more flexible in the application. The SplitVisor leaves the decisions to users. If users want to implement I/O protection in the hypervisor, they can add the new function in the GuestVisor.

VM life-cycle Management Some VM life-cycle functions, such as shutting down a VM, should be implemented in the GuestVisor. When a VM is shutting down, the GuestVisor needs to follow the boot preparation procedure as described in Section 3.1. Also, the GuestVisor writes all data to disk or send them to the management software. The same thing should be done when taking a snapshot of a VM. The management of snapshots is also the GuestVisor's responsibility.

Another important work of the GuestVisor is VM migration. The GuestVisor verifies the new server and creates a new VM image on the target server. All the steps described in secure boot in Section 3.1 should be done again.

Privileged Instructions Privileged instructions cannot be executed in a VM. In SplitVisor, they are handled by the GuestVisor. If an instruction, e.g., a hyper call, has some arguments in the VM's memory, the GuestVisor can directly read it. In CloudVisor, things are more complex. CloudVisor must fetches page table entries and the arguments for the hypervisor, in the meanwhile the CloudVisor must make sure that no sensitive information is leaked to the hypervisor. The CloudVisor must know the exactly meaning of the instructions. Some work [START_REF] Chhabra | Secureme: a hardware-software approach to full system security[END_REF] may add new instructions, so it is a big burden to the CloudVisor.

Fine-gained Isolation Some architectures [START_REF] Chen | Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems[END_REF][START_REF] Chhabra | Secureme: a hardware-software approach to full system security[END_REF] provide fine-gained isolation. They can provide a secure environment for applications even in a malicious OS. The function is implemented in the hypervisor, which intercepts the communication between applications and OS. In SplitVisor, it can be implemented in the GuestVisor.

Monitoring and virus detection

It is much more secure to implement monitoring and virus detection in the hypervisor. When an OS is under the attackers' control, all traditional virus detections are useless. The virus detection must be reliable, because it can access VMs' memory. But virus detection software are usually large, it is not suitable to be added to the TCB. In SplitVisor, it can be implemented in the GuestVisor. It is not possible to be added in other architecture without increasing the size of TCB. The monitoring software is the same as virus detection software.

Virtual TPM A GuestVisor can emulate some devices for VMs, such as a virtual TPM. The TPM is an important device for software protection.

Table 6 summarizes the functions of the GuestVisors. All the functions are implemented in the hypervisor of Xen, as a part of TCB. It is more secure that SplitVisor can implement them out of the TCB. Other functions can be implemented in the GuestVisor as long as they do not violate the isolation restriction. The memory overhead of SplitVisor is mainly caused by the GuestVisor. In general, users only need a small part of all functions. The GuestVisor is in users' memory space. If a users wants to save memory space, the user can choose a simple GuestVisor with less functions. Xen occupies 64 MB memory. The GuestVisor has similar size. The memory of a typical VM is shown in Table 7, which is from Amazon EC2 [START_REF]Amazon elastic compute cloud[END_REF]. The memory overhead is from 0.4% -3.8%.

CPU and I/O overhead

When running a VM, some privileged instructions and interrupts will cause VM exits, which introduces the major CPU and I/O overhead of SplitVisor when comparing with other approaches. In current hypervisor design, VM exits are delivered to and handled by the hypervisor. In SplitVisor, VM exits are transferred twice, from the SplitVisor to a GuestVisor. We firstly compare SplitVisor with other two-layer-hypervisor architectures: CloudVisor and nested hypervisor [START_REF] Ben-Yehuda | The turtles project: Design and implementation of nested virtualization[END_REF]. The upper part of Fig. 3 shows the process of VM exits in SplitVisor and CloudVisor. The labels in the figure indicate what messages are delivered. In CloudVisor, the hypervisor cannot access the memory of a VM. CloudVisor encrypts all the data from a VM to the hypervisor. In SplitVisor, all the memory of a VM are mapped in a GuestVisor, so the GuestVisor can easily deal with the VM's memory. The nested hypervisor provides full virtual environment for every level, where the L1 hypervisor does not know that it is in a virtual machine. So the L1 hypervisor may execute some privileged instructions which traps to the L0 hypervisor. The L0 hypervisor emulates hardware for L1 the hypervisor. The SplitVisor does not aim at providing a virtual environment for GuestVisors. A GuestVisor is aware of virtualization. The lower part of Fig. 3 shows the process of VM exits in SplitVisor and nested hypervisor. When a VM exit occurs in a VM (L2), it is delivered to a GuestVisor (L1). A GuestVisor usually handles the VM exit by itself, while an L1 hypervisor may cause many new VM exits. A GuestVisor can control what can be intercepted by modifying a VM's VMCS. In our experiments, we assume that a GuestVisor intercepts the same VM exits as Xen. Then SplitVisor needs twice as many VM exits as Xen does. We choose SPECjbb2005 [START_REF]Specjbb2005[END_REF] as the benchmark program. We run SPECjbb2005 in Xen HVM with different numbers of JVMs. Then we count the number of VM exits and estimate the running time in SplitVisor. The results are shown in Fig 4 . The average overhead is about 4.3%.

Related Work

Research similar to ours can be classified into several categories.

Hardware level protection: Some work, such as XOM [START_REF] Lie | Architectural support for copy and tamper resistant software[END_REF][START_REF] Lie | Implementing an untrusted operating system on trusted hardware[END_REF], AEGIS [START_REF] Suh | Aegis: architecture for tamper-evident and tamper-resistant processing[END_REF] and AISE [START_REF] Chhabra | Making secure processors os-and performance-friendly[END_REF], can defend against hardware attacks. They use a specially designed CPU to defend against memory tampering. In these architecture, CPU encrypts all data that goes out of the CPU, and decrypts what are loaded into CPU. CPU maintains a hash tree that ensures data integrity. These work can protect all software from hardware based attacks, but do not address security problems inside the software.

Application protection: Many vulnerabilities have been discovered in OSs. Many techniques, such as Overshadow [START_REF] Chen | Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems[END_REF][START_REF] Yang | Using hypervisor to provide data secrecy for user applications on a per-page basis[END_REF] and SecureME [START_REF] Chhabra | Secureme: a hardware-software approach to full system security[END_REF], protect applications from a malicious OS. These work leverage the hypervisor to prevent the OS from directly accessing applications' memory and intercept the communication between the OS and applications. Bastion [START_REF] Champagne | Scalable architectural support for trusted software[END_REF] provides module-level protection. Similar to application-level protection, entering into a module and going out of a module are intercepted by the hypervisor.

Hypervisor protection: Hypervisor is the most important part in a virtualization architecture. TPM and other hardware protections [START_REF] Lie | Architectural support for copy and tamper resistant software[END_REF][START_REF] Lie | Implementing an untrusted operating system on trusted hardware[END_REF][START_REF] Suh | Aegis: architecture for tamper-evident and tamper-resistant processing[END_REF][START_REF] Chhabra | Making secure processors os-and performance-friendly[END_REF] can verify the integrity of software when a hypervisor is loaded. HyperSentry [START_REF] Azab | Hypersentry: Enabling stealthy in-context measurement of hypervisor integrity[END_REF] can verify the integrity dynamically. HyperSafe [START_REF] Wang | Hypersafe: A lightweight approach to provide lifetime hypervisor control-flow integrity[END_REF] can verify the integrity of control-flow of hypervisor execution. These work mainly focus on detecting attacks, instead of building a secure hypervisor. NoHype [START_REF] Keller | Nohype: virtualized cloud infrastructure without the virtualization[END_REF][START_REF] Szefer | Eliminating the hypervisor attack surface for a more secure cloud[END_REF] cuts off the communication between hypervisor and VM after VM is booted. However, it cannot defend against the attacks from the management VM. So NoHype still has a large TCB.

VM protection: The best way to protect a VM is to protect the hypervisor. If a hypervisor works correctly, the VM can be well protected by the hypervisor. Some work can provide protection without the help of a hypervisor. SICE [START_REF] Ahmed Azab | Sice: A hardware-level strongly isolated computing environment for x86 multi-core platforms[END_REF] implements the protection mechanism in the SMM. Even if a hypervisor is malicious, a VM can be protected by SICE. Currently, SICE has a limit of protecting at most one VM on each core.

The turtles project [START_REF] Ben-Yehuda | The turtles project: Design and implementation of nested virtualization[END_REF] shows the architecture of nested hypervisors, which allows running hypervisors above a hypervisor. CloudVisor [START_REF] Zhang | Cloudvisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization[END_REF] leverages this architecture to protect VMs. In these designs, the orignial hypervisor is not at the highest level. All communications between a hypervisor and VMs must be verified by the CloudVisor, and the hypervisor cannot directly access VMs' memory. CloudVisor does not provide the protection of the hypervisor, because all requests from VM are forwarded to the hypervisor.

Conclusion

Existing virtualization architectures usually have either rich functions or a small TCB, but not both. In this paper, we propose an innovative virtualization ar-chitecture, SplitVisor, to support both. SplitVisor has a two-layer-virtualization structure: a SplitVisor and GuestVisors. The SplitVisor is responsible for isolation between different users' VMs. A GuestVisor is responsible for emulating hardware for VMs. A GuestVisor is not required to reside in the TCB, so the TCB of SplitVisor is small. SplitVisor allows users to choose their own hypervisors. It cannot be achieved in single hypervisor designs where all VMs share the same hypervisor. The TCB of SplitVisor is stable because we do not add new functions to the SplitVisor, but to the GuestVisors. This also offers the opportunity to store the TCB in firmware or to optimize it with hardware.

Acknowledgement

This work was supported in part by NSF Grants CNS-1100221 and CNS-0905153.

Fig. 1 .

 1 Fig. 1. SplitVisor architecture

Fig. 2 .

 2 Fig. 2. Comparison of the current hypervisor design (top) and SplitVisor design (bottom) in terms of address translation

Fig. 3 .

 3 Fig. 3. Process of VM exit

Fig. 4 .

 4 Fig. 4. CPU and I/O Overhead

Table 1 .

 1 Comparison of different designsTCB Stability 1 Functions Hypervisor 2 VM 3 Protection Assertion HD4

	SplitVisor CloudVisor [16] small small SICE [14] small	√	full partial partial	√ √ √	√ √	VM VM region	√ √ √
	NoHype [4, 5]	large		partial			VM
	Overshadow [12] large Bastion [15] large SecureME [13] large XOM [19, 20] large AEGIS [21] large AISE [22] large		full full full full full full			application module application region region region	√ √ √ √ √

Table 2 .

 2 Xen TCB size (by Lines of Code)

	Hypervisor Kernel of Domain 0 Tools TCB
	Xen 2.0 45k	4,136k	26k 4,027k
	Xen 3.0 121k	4,807k	143k 5,071k
	Xen 4.0 270k	7,560k	647k 8,477k

Table 3 .

 3 Units in SplitVisor

	Unit	Functions	Transparency
	SplitVisor VMX transition, memory isolation	-
	GuestVisor OS execution environment, extra functions Not support
	VM	Running OS	Both para-and full-virtualization

  Table (EPT) and nested paging. The page table (PT) specified by CR3 is still responsible for translating virtual frame number (VFN) to physical frame number (PFN). A new table called EPT for Intel is responsible for translating PFN to machine frame number (MFN). The address of EPT is specified by EPTP, a VMCS field. The three layer model is shown in Fig 2 to compare our SplitVisor design and the current hypervisor design.

Table 4 .

 4 Comparison of Memory Designs -Where The Functions Are Implemented

	Function	SplitVisor CloudVisor Xen
	Memory isolation	SplitVisor CloudVisor Hypervisor
	VM management	GuestVisor Hypervisor Hypervisor
	Memory transferring, sharing GuestVisor CloudVisor Hypervisor

Table 5 .

 5 Comparison of Scheduling Designs -Where The Functions Are Implemented

	Function	SplitVisor CloudVisor Xen
	VCPUs management	GuestVisor Hypervisor Hypervisor
	(GuestVisor) hypervisor's VMCS SplitVisor CloudVisor -
	VM's VMCS	GuestVisor Hypervisor Hypervisor

Table 6 .

 6 Comparison of different designs -Where The Functions Are Implemented

	Functions	SplitVisor CloudVisor	Xen
	I/O encryption	GuestVisor CloudVisor	Hypervisor
	VM life cycle	GuestVisor CloudVisor	Hypervisor
	Privileged instructions	GuestVisor CloudVisor, hypervisor Hypervisor
	Fine-gained Isolation	GuestVisor None	Hypervisor
	Monitor and virus detection GuestVisor None	Hypervisor
	Virtual TPM	GuestVisor None	Hypervisor
	4 Performance Evaluation
	4.1 Memory Overhead

Table 7 .

 7 Memory Overhead

	VM type	VM GuestVisor Overhead
	Small Instance	1.7 GB 64 MB	3.8%
	Large Instance	7.5 GB 64 MB	0.9%
	Extra Large Instance 15 GB 64 MB	0.4%

This work was done while the first author worked at Virginia Commonwealth University.

A TCB design is stable if the TCB needs little or even none of changes when adding new functions to the hypervisor.

Attacks can be confined to the hypervisor when the hypervisor is compromised.

VMs are protected when the hypervisor is compromised.

Hardware level attacks, such as memory tapping[START_REF] Huang | Hacking the Xbox: an introduction to reverse engineering[END_REF], can be handled.


Hamed Saljooghinejad
email: hamed.saljooghinejad@gmail.com

Wilson Naik Bhukya

Layered Security Architecture for Masquerade Attack Detection

Keywords: Masquerade Detection, Intrusion Detection System, Anomaly Detection, User Profiling

Masquerade attack refers to an attack that uses a fake identity, to gain unauthorized access to personal computer information through legitimate access identification. Automatic discovery of masqueraders is sometimes undertaken by detecting significant departures from normal user behavior. If a user's normal profile deviates from their original behavior, it could potentially signal an ongoing masquerade attack. In this paper we proposed a new framework to capture data in a comprehensive manner by collecting data in different layers across multiple applications. Our approach generates feature vectors which contain the output gained from analysis across multiple layers such as Window Data, Mouse Data, Keyboard Data, Command Line Data, File Access Data and Authentication Data. We evaluated our approach by several experiments with a significant number of participants. Our experimental results show better detection rates with acceptable false positives which none of the earlier approaches has achieved this level of accuracy so far.

Introduction

Masquerade attacks are ranked second on the top five lists of electronic crimes perpetrated after viruses, worms or other malicious code attacks. The most common information, which can be used to detect masquerade attacks, is contained within the actions a masquerader performs. This set of actions is known as a behavioral profile. Behavior is not something that can be easily stolen. Masquerade detection techniques are based on the premise that when a masquerader attacks the system he will sufficiently deviate from the user's behavior and thus can be recognized using machine learning techniques [START_REF] Lane | An Application of Machine Learning to Anomaly Detection[END_REF]. In this paper we demonstrate an approach for detecting masqueraders in an efficient manner. We show how multiple layers of user data records together can construct a meaningful behavioral profile in order to have better detection results. The paper is organized as follows: next section introduces the related works on masquerade detection. Then, we describe architecture for the layered approach, which is followed by the experimental designs including data collection, feature extraction, learning and classification phases. Results of several experiments and conclusion are presented in last sections.

Background and Related Work

Masquerade detection was done by observing the command line data and watching a user"s behavior and then finding anomalies in their usage. In the category of the command line approaches, the initial activity was done by Schonlau et al. [START_REF] Schonlau | Computer Intrusion: Detecting Masquerades[END_REF] which collected a dataset of Unix command line data from 50 users called the SEA dataset for testing and comparing and was used with different intrusion detection techniques. This research utilized different statistical techniques on the dataset and then compared the results. The NaïveBayes classifier was first applied on Schonlau"s dataset by Roy A. Maxion [START_REF] Maxion | Masquerade Detection Using Truncated Command Lines[END_REF]. They extended their previous work by applying the NaïveBayes classifier on Greenberg"s enriched command line data [START_REF] Maxion | Masquerade Detection Using Enriched Command Lines[END_REF]. Kim [START_REF] Kim | Empirical evaluation of svm-based masquerade detection using Unix commands[END_REF] applied SVM with a voting engine on SEA, 1v49 and Greenberg datasets.

However command line data detection mechanisms could not truly detect masquerade attacks in the modern graphical user interface (GUI) systems like windows and variants of Unix like Linux or Mac OSx. Today working with GUI systems is more common and the study of their different aspects is crucial. GUI based data is mostly related to data which comes from the interaction between the user and their mouse and keyboard. Poursa [START_REF] Pusara | User Re-authentication via mouse movements[END_REF] considered Analysis of mouse data which was taken from users who worked with browsers. This approach has its disadvantages mainly because their work focused on the browser data, even though users may be working with applications other than browsers. Later works then focused on comprehensive GUI behavior. For this purpose, [START_REF] Garg | Upadhyaya: Profiling Users in GUI Based Systems for Masquerade Detection[END_REF] developed an active system logger by using C# on a Windows XP System. This logger examined GUI event data captured from users and then useful parameters are extracted to construct the feature vectors. This profiling method, while good, comes with the disadvantage that they only implemented it for Microsoft GUI systems with much of the focus set only on mouse usage. Moreover, their detection rate was not impressive. [START_REF] Bhukya | Masquerade detection based upon GUI user profiling in Linux systems[END_REF] designed a logger in the KDE environment. The disadvantages of their work were that they collected data only from a single window and did not consider the complexity of profiling multi applications. It was [START_REF] Saljooghinejad | Multi Application User Profiling for Masquerade Attack Detection[END_REF] who later showed the advantages of user profiling across multiple applications. Other activity regarding GUI based detections can be found in [START_REF] Imsand | GUI Usage Analysis for Masquerade Detection[END_REF] which does not use mouse movements or keystroke dynamics but rather profiles how the user manipulates the windows, icons and menus. They do not appear to consider time as a factor, which is crucial for intrusion analysis.

Our Layered Approach

We propose a new approach for detecting a masquerader in a system. A layered approach is introduced to collect comprehensive data across multiple applications. Fig. 1 shows an overview of the architecture which will be discussed in this paper. As it is shown, the training phase is based on collecting the genuine user data from which a behavioral profile will be created for each user and started with an event logger tool which is designed and implemented to collects all events during a session. Then a feature extraction tool is designed to generate the useful features. It constructs feature vectors which are generated from different layers; namely layer-1 as GUI data contains window data, mouse data, keyboard data, layer-2 as command line data, layer-3 as file access data and layer-4 as authentication data. This will then be used in the detection phase. In the detection phase the new user profile will be generated from the new user records and compared to the genuine profile. Any significant deviation between them can be recognized as an attack. This task can be possible with the help of a binary classifier which we can call the detection engine. We took the help of two well known classifiers for this task namely SVM and NaïveBayes. More details regarding the experiment will be addressed in later sections.

Data Collection & Calculation of Features

In the absence of a real-world data set for the study of masquerade attacks, we developed our own data collection project. In this section we described the data collection and feature extraction phases. For collecting the data our own logger was developed to collect the information from system. Since we needed data passing through Window Manager, we chose C as the programming language using X library which helped us communicate with Window Manager for capturing the events. The details of each event were logged to a file for processing in the next phase. The collected event details include identification of the window, the name of that window and time of occurrence along with different attributes of that particular event. At the preprocessing phase, by analyzing and observing the impact of each feature on detection rate and false positive rates, it was concluded that the following features were to be considered in the training phase. The features are generated from 6 categories including window data, keyboard data, mouse data as GUI data, command line data, file access data and authentication data as below:

4.1

Window Data(9features)

Users in the GUI environment try to interact with a particular window such as Maximizing, Minimizing, Opening, Closing and switching between windows. In total 9 features were extracted. Here is a window event sample:

Event Occurred at: Tue Feb 8 10:03:13 2011 WID=65011715-WName=Openoffice msg:The active window changed from previous WID=69206091-Wname=Firefox Window coordination and size (4). The average number of times that the user changes the x, y coordinates of a window or width or height of it per user session. Window Maximize, Minimize (4). The average number of times that the user minimizes, maximizes, restores from the minimized or maximized position of a window per user session. Window Switching (1). The average number of times that a user switches between different windows per user session.

4.2

Mouse Data(6featurs)

In this category mouse-related user activities like mouse click, mouse right click, mouse movement, etc. were captured for every application. In total 6 features were extracted. Here is a mouse event sample: Event Occurred at: Tue Feb 8 09:58:22 2011 WID=650117-WName=Firefox--msg:Mouse left button clicked Mouse Enter and Exit (2). The average number of times that the mouse enters to a window or exit from a window for each application per user session. Mouse Clicks (2). The average number of left and right mouse clicks for each application per user session. Mouse Scroll Up and Down (2). The average number of times that the mouse scrolls up or scroll down for each application per user session.

4.3

Keyboard Data(5features)

All the keyboard events are logged and stored separately for each application. The different keyboard events are key press, key release, and shortcut key (Ctrl, Alt, shift modifiers). In total 5 features were extracted. Here is a keyboard event sample: Event Occurred at: Tue Feb 8 10:00:33 2011 WID=692060--WName=Firefox--msg:Shortcut key Pressed-Ctrl+z Key Pressed (1). The average number of keys pressed in each application per user session. Shortcut key Pressed (1). The average number of shortcut keys pressed in each application per user session.

Ctrl, Alt, Shift Modifier (3). The average number of times that Ctrl, Alt or Shift modifiers pressed for each application per user session.

4.4

Command Line Data(2features)

All the commands which are entered in command prompt are logged. They are divided into 2 major categories, Normal and Critical. Normal commands are those which are harmless and can be used with normal user privileges such as ls, clear, cd, etc. Critical commands are those used by administrators and contain any commands that critical for the system and need root privileges such as su, sudo, etc. Normal and Critical Commands (1). Number of normal and critical commands that the user enters to the command prompt.

4.5

File Access Data(38 features)

In this layer, users' accesses to crucial files were logged. Attackers usually try to access the victim's data. Analyzing this pattern of behavior can be helpful in order to determine when such an act is being conducted by a masquerader within the system. For example attackers try to access password files to obtain the users' password. Another example can be seen by the attempt to access log files by the attacker in order to delete any evidence they may have left behind. We used the Auditd tool to log the user access to specific files or folders. It is part of the Linux kernel auditing toolkit and captures auditing trails created by the kernel auditing facility from /proc/audit. Using the feature extraction tool, data was preprocessed and a total of 38 features are created. The first 19 features are successful attempts to access specific files or folders and the rest of them are features regarding failed access. Successful and Unsuccessful access (38). Number of successful attempts to access particular files and folders include password file, log folder, etc folder, var folder, home directory, proc and bin folder as well as the number of unsuccessful attempts.

4.6

Authentication Data(2features)

Normal users rarely perform actions of administrative domain, so when unusual numbers of authentication occur, it can be suspected as malicious activity. From this 2 features are extracted, the first one is the total number of authentication request and the second one is the total number of failed authentication request. Successful and Unsuccessful Authentication (2). Number of successful and unsuccessful authentications.

Learning and Classification

We collected the data from 16 distinct users who were the students of a particular course in our department. For each user an account was created on a shared computer in our lab and they were given an individual choice of operating conditions and appli-cations. The data collection phase took about two months and the data was collected for multiple sessions, each lasting about 10 minutes. Roughly 3140 minutes of user data was collected and profiled which was significant due to the considerable number of users.

The dataset contains the different number of sessions for different users 2 users with 21 sessions, 10 users with 20 sessions, 3 users with 19 sessions, and 1 user with 15 sessions as it is shown in table 1. This data was fed into the parsing engine to sanitize and extract features for each application per session. The methodology to train and test the data is explained below. -The Collected feature vectors were then divided into different training and test sets. From these, the training sessions were used for the learning phase and for the test phase due to the lack of real masquerade records the other user"s records were treated as non genuine or as masquerade records. Obviously if the real masquerade data was available, the anomaly detection would be easier due to the fact that masqueraders tend to put more effort into changing the system state than a normal user would.

-We started with the proportion of 50 percent for the training set vs. 50 percent of the testing set. To show the effect that the number of training sets has in relation to accuracy we repeated the experiments, increasing the proportion of the training set by 5 percent for each case. In total 8 different cases were constructed and it ended up with proportion of 85 percent for the training set and 15 percent for the testing set. Results show a better performance, with an increase in the number of training sets.

-The Collected feature vectors were divided into different training and test sessions per user. We defined a binary classification problem for our data due to the fact that users should be tagged as positive (genuine) or negative (masquerader). SVM [10] [11] and NaïveBayes [START_REF] Mccallum | A comparison of event models for naivebayes text classification[END_REF] classifiers are used to classify the data and measure the detection rate, false positive and false negative rates. We used the Weka tool [13] to perform the classification. For improving the performance of classifiers we used the SMOTE filter [START_REF] Chawla | SMOTE: Synthetic Minority Oversampling Technique[END_REF].

Results and Discussion

We evaluated the performance of our approach with different experimentations as explained in previous section. Our best result was the detection rate of 97.5% with a false positive rate of 10.18% and false negative rate of 1.5% for SVM. Following sections explain more about the results and comparison between different approaches.

Detection Rate Evaluation by Different Number of Training and Test Sets

Table 2 shows the average detection rate for different numbers of training sets and test sets using different classifiers. In all cases the detection accuracy of SVM is far better than the other classifier. We can see an improvement in detection rate by increasing the number of training sets. A receiver operating characteristic (ROC), or simply ROC curve, is a graphical plot of the sensitivity, or true positive rate vs. false positive rate with equivalent value between 0 and 1. 1 means we have 100% detection rate with 0 false positive and 0 false negative. ROC analysis provides tools to select the optimal classifier. We calculated the average ROC scores for different numbers of training and test sets. For each user the ROC score is calculated and we then computed the average ROC for each classifier. Table 3 shows the better performance of SVM for our approach. Concretely SVM is famous for its use in this type of problem because it is a maximal-margin classifier as compared to NaïveBayes which is probabilistic and it has been known to be highly effective in text classification and providing better classification results with less training data.

Conclusion

In this paper, we described and developed a new framework for constructing comprehensive feature vectors in different layers for the improvement of masquerade detection accuracy. After capturing the events of a user we went through preprocessing and then extracted relevant features for each application to then construct the relevant feature vectors. We considered six different layers to collect the data, consisting of window data, mouse data, keyboard data, command line data, file access data and authentication data. These feature vectors are classified for masquerade detection using two classifiers namely SVM and NaïveBayes. Our experiments show that this layered approach is well classified using SVM and thus provides better masquerade detection capabilities than single layer approaches. Moreover we observed the impact of increasing the number of training sets which led to an improvement of the detection rate.

Fig. 1 .

 1 Fig. 1. Architecture of the Layered Approach

Table 1 .

 1 Data Sets Description

	Users	No of Sessions (each 10minutes)
	A,B	2*21
	C,D,E,F,G,H,I,J,K,L	10*20
	M,N,O	3*19
	P	1*15
	Sum	314 (3140 minutes)

Table 2 .

 2 Average Detection Rate with Different Training and Test sets Size

	Classifiers	50%Train 50%Test	55%Train 45%Test	60%Train 40%Test	65%Train 35%Test	70%Train 30%Test	75%Train 25%Test	80%Train 20%Test	85%Train 15%Test
	SVM		95.83	96.02	96.59	96.55	96.92	96.89	97.05	97.55
	NaïveBayes		91.06	91.2	91.51	91.65	91.61	91.83	91.28	91.34
		6.2	ROC

score Evaluation by Different Number of Training and Test Sets

Table 3 .

 3 Average ROC Score with Different Number of Train and Test sets SizeTo show the advantages of the layered approach, a brief comparison between the detection rate of our approach vs. the previous research works is been shown. As indicted in table 4, layered approach shows better detection rate than other methods either GUI[START_REF] Garg | Upadhyaya: Profiling Users in GUI Based Systems for Masquerade Detection[END_REF] [2][START_REF] Saljooghinejad | Multi Application User Profiling for Masquerade Attack Detection[END_REF] or Command line[START_REF] Kim | Empirical evaluation of svm-based masquerade detection using Unix commands[END_REF] [7][START_REF] Maxion | Masquerade Detection Using Enriched Command Lines[END_REF] approaches.

	Classifiers	50%Train 50%Test	55%Train 45%Test	60%Train 40%Test	65%Train 35%Test	70%Train 30%Test	75%Train 25%Test	80%Train 20%Test	85%Train 15%Test
	SVM		0.894	0.905	0.914	0.914	0.919	0.924	0.932	0.941
	NaïveBayes		0.848	0.851	0.861	0.863	0.868	0.883	0.895	0.902
		6.3	Comparison With Other Approaches

Table 4 .

 4 Comparison of detection rate results achieved by different approaches

	Metrics	Layered Approach	[1]	GUI Data [2]	[4]	Command Line Data [7]/[8] [5]	[5]
	Number of Users or Database Used	16	3	8	3	Greenburg Greenburg SEA/1vs49
	Detection Rate	97.55	91.41	94.88	91.7	70.9/82.1	87.3	80.1/94.8