attacks in TVD. Keywords â Trusted Computing, Virtual machine monitor, Trusted. Virtual Domains, Cloud Computing, Zero Day Attacks. I. INTRODUCTION.
2011 Fourth IEEE International Conference on Utility and Cloud Computing
TVDSEC: Trusted Virtual Domain Security Udaya Tupakula
Vijay Varadharajan
Information & Networked Systems Security Research, Department of Computing Faculty of Science, Macquarie University, Sydney, Australia {udaya.tupakula, vijay.varadharajan}@mq.edu.au
machines on a single VMM. For example, consider the case where two different customers are hosting three virtual machines on the cloud service provider infrastructure. As shown in the Figure 1, the cloud service provider can host the customer virtual machines on three physical servers. Although the VMM1 and VMM3 are hosting virtual machines that belong to single customer, VMM2 is hosting virtual machines that belong to different customers. In such cases, there are specific requirements. The customers want to ensure that information can be shared among their virtual machines and at the same time ensure that their virtual machines are secure from other hosts or virtual machines. Also, the customers may want to easily manage their virtual machines and enforce domain wide security policies on their virtual machines. This is analogous to traditional LAN environments protected by security gateways such as firewalls. Hence TVD can be used to address some of the above issues. A trusted virtual domain enables grouping of related virtual machines running on separate physical machine into a single network domain with a unified security policy. Since TVD provides an environment similar to the traditional LAN they are also vulnerable to the attacks that are possible in LAN. However, the attacks can be more severe in the case of TVD since the virtual machines can be implemented on geographically separated machines and since virtual machines that belong to different customers can be running on each physical server. Our analysis confirms that there is need for additional techniques for securing virtual machines in TVD. The current Internet environment is vulnerable to a range of different types of attacks [4-7] such as malware, phishing, spam, and denial of service. The size and complexity of the current operating systems and applications is continuously increasing and it is not an easy task to ensure the secure operation of such systems. Although there are several tools [8] such as intrusion detection systems, honey pots, antivirus and anti malware, the dynamic nature of the attacks makes it difficult to detect and prevent attacks. On the other hand, it is simple task for the attacker to compromise such systems and generate different types of attacks. As a result we are witnessing an increasing number of zero day attacks on a daily basis. Zero day attacks are the attacks which are previously not known. Hence if the attacker can compromise a single virtual machine within a TVD, then attacks are possible on all the virtual machines in the TVD. Hence there is need for security techniques to deal with the attacks in the TVD. Currently there is considerable research interest to develop security tools that are based on virtualisation technology. Since Virtual Machine Monitors have complete control on the physical resources and are isolated from the virtual machines,
Abstract — Virtualisation is one of the important technologies for the realisation of cloud computing. A Virtual Machine Monitor (VMM) is an additional software layer which has complete control on the physical resources and enables to run multiple operating systems on a scalable computer. Recently some of the techniques have been proposed to develop Trusted Virtual domains. A trusted virtual domain (TVD) enables grouping of related virtual machines running on separate physical machine into a single network domain with a unified security policy. In this paper we analyze the security issues related to TVD and propose security techniques to deal with the attacks in TVD. Keywords – Trusted Computing, Virtual machine monitor, Trusted Virtual Domains, Cloud Computing, Zero Day Attacks.
I.
INTRODUCTION
Virtualisation is one of the important technologies for the realisation of cloud computing. A Virtual Machine Monitor (VMM) [1, 2] is an additional software layer which has complete control on the physical resources and enables to run multiple operating systems on a scalable computer. The current virtual monitors can be classified into two types. In Type 1, the VMM runs as an application on the host operating system. In type 2, the VMM directly runs on top of the hardware. Customer 1 VM11
VM12
Customer 2 VM13
VM21
VM22
VM23
VMM1
VMM2
VMM3
Hardware
Hardware
Hardware
Figure 1: TVD Scenario
Recently some of the techniques have been proposed [3] for the development of Trusted Virtual Domains (TVD). TVD [3] can be used to address some of the needs for the cloud computing. In some cases, virtual machines that belong to single customer/organisation can be hosted on different hypervisors. In some cases, for efficient usage of resources, the cloud service provider can host different customer virtual The authors would like to thank Departments of the Prime Minister and Cabinet (PM&C) and Defence Signals Directorate (DSD), Australia, for their financial support of the research project on Secure Virtualization Systems. The PM&C and DSD funding should not be taken to imply endorsement of the content or conclusions of the research project.
978-0-7695-4592-9/11 $26.00 © 2011 IEEE DOI 10.1109/UCC.2011.18
57
the security tools implemented in VMM can efficiently detect and prevent the attacks. Although some of the VMM based security techniques have been proposed, there is need to consider the specific features of the TVD to deal with the attacks efficiently. Hence this is the main focus of our work. In this paper we first consider the challenges to deal with the attacks in the trusted virtual domains. Then we propose techniques to deal with the attacks by taking into account the specific characteristics of the TVD. Our model can efficiently prevent the attacks at the virtual machine monitor that is hosting the compromised virtual machine. The paper is organized as follows. In Section II we first present an overview of the TVD architecture and analysis of attacks in the TVD. Then we propose TVDSEC model to deal with the attacks in TVD. We will describe the components of our architecture and the operation of our model in detail. In Section III we present the implementation of our model on XEN VMM and analysis of our model for different attack case scenarios. Section IV presents some of the important related works that are relevant to this paper. Section V concludes. II.
Before a physical machine can join the TVD, the TVD master validates whether the physical platform has the capabilities to enforce domain wide security policies. TPM validation techniques [9-13] are used to determine if a platform is capable of enforcing TVD security policies. If the physical platform is capable of enforcing the TVD policies then a TVD proxy is implemented on each physical platform. As shown in Figure 2, VMM1 has two TVD proxies since it is hosting virtual machines that belong to different TVDs and VMM2 has only a single proxy since it is hosting only one virtual machine that belongs to a TVD. The TVD proxies enforce TVD policies on each platform. Whenever a virtual machine has to be instantiated on the VMM, the TVD proxy validates the VM before allowing the VM to join the TVD. The TPM is used to provide core root of trust to ensure that the state of the VMM, VM and its components are in secure state during boot time. However since there is possibility for the virtual machines to be compromised during runtime, the TVDSEC will be used to monitor all the interactions of virtual machine and deal with the zero day attacks in case of compromise of the system. Figure 4 shows the sub components of the TVDSEC which can be integrated into the TVD proxy. Since the VMM has complete control of the resources, good visibility of the internal state of the virtual machines, while being isolated from the virtual machines themselves, the security tools placed in VMM have the capabilities of performing both host based and network based intrusion detection. Also note that we are using TVDSEC as a secondary layer of defence for securing virtual machines.
TVDSEC
In this section we will first consider techniques for the deployment of the TVD on Xen virtual machine monitor and discuss the challenges to deal with the attacks on the virtual machines in the TVD environment. Then we propose techniques to enhance security in TVD. A. Architecture Overview As shown in Figure 2, our architecture involves interconnected virtual machines that are hosted on different physical machines, put together to form trusted virtual domain (TVD) under a security policy. The TVD master or TVD administrator develops a unified security policy for the virtual machines in the TVD. Often there is free communication between the virtual machines in the TVD. As shown in the Figure 2, virtual machines are equipped with the host based security tools such as antivirus, and host based intrusion detection system as a primary layer of defence for securing virtual machines. Any communication between the virtual machines of different TVD is permitted according to the security policies defined by the TVD master. There can be a range of security policies in the TVDs. For instance, assume there are 3 TVDs: TVD1, TVD2 and TVD3. The information flow security policy specifies the flows that are allowed from and to which virtual machines in which TVDs. For instance, flows between TVD1 and TVD2 are governed by Policy12, and flows between TVD2 and TVD3 are governed by Policy23. For example, as shown in Figure 3, the Policy12 will say that all flows from virtual machines in TVD1 to virtual machines in TVD2 need to be protected for both confidentiality and integrity. Note that in general Policy12 consists of two subpolicies dealing with inbound and outbound flows. Inbound flows are enforced by the recipient TVD2 and the outbound flows are enforced by the sending TVD1. If the communication does not satisfy the TVD security policies, then the packets are dropped.
Blue TVD Master
Red TVD Master
Dom 0
VM12
VM11
TVD proxy TVD proxy
HBST
HBST
VMM1 Physical Devices TPM
Dom 0 TVD proxy
VM21
VM22
HBST
HBST
VMM2 Physical Devices TPM
Figure 2. TVD Deployment on Xen
Figure 2 shows the TVD deployment on Xen virtual machine monitor. Xen is a type 2 hypervisor which directly runs on top of the hardware and there is a privileged VM (Domain 0) which is used for hosting and the management of the customer virtual machines which are known as the guest virtual machines. As shown in Figure 2, virtual machines that belong to different TVD can be implemented on each VMM. Techniques such as VLAN, Ethernet encapsulation and VPN are used for the implementation of the TVD. A detail discussion on the implementation of TVD can be found in [3].
58
B. Attack Scenario If free communication is permitted between the virtual machines within the TVD, then the attacker can generate attacks on all the virtual machines by compromising a single virtual machine in a TVD. The traditional security tools have several challenges to deal with the attacks in TVD environment. Although there are several tools such as intrusion detection systems, honey pots, antivirus and anti malware, the dynamic nature of the attacks makes it difficult to detect and prevent attacks. The host based tools have good visibility of internal state of the monitored system and can detect the attacks more efficiently. However since the tools are implemented on the monitored system itself, they are vulnerable to attacks by the attacker. The network based tools detect the attacks by monitoring the incoming and outgoing traffic from the monitored machines. They have less visibility into the state of monitored machines but offer high attack resistance. For efficient detection of attacks, it is desirable for the tools to have good visibility of the monitored system while at the same time offering high resistance to attacks. Let us analyse the TVD attacks in detail by considering an attack scenario.
VM11
VM12
VM13
HBST VMM1
HBST VMM2
HBST
Hardware
Hardware TPM
TPM
Policy12
VM21
VM22
VM23
HBST VMM2
HBST
HBST
the virtual machines that belong to single administrative domain. Any communication of virtual machines between the TVD is permitted according to the policies defined by the TVD Master. The security policies are enforced by the TVD proxies. Consider the case where the attacker has compromised VM12 by exploiting zero day vulnerability. Now the attacker can generate attacks on all the virtual machines (VM11, VM13) within the TVD. Consider the case where VM12 which belongs to TVD-LAN1 is generating attack on VM23 which belongs to TVD-LAN2. Such attacks are successful only if the communication is permitted by the security policies of TVD12. Hence there is need for techniques to detect and prevent such attacks. One of the main goals of work is to develop techniques to detect attacks on the virtual machines within a TVD. As shown in Figure 3, a single compromised virtual machine (VM12) client can flood the TVD-LAN medium with different types of malicious messages and severely degrade the services in the TVD-LAN environment. One of the common behaviour with any of the attacks such as slammer, conficker, torpig, storm is that they result in congestion of the traditional LAN medium. For example, slammer worm floods the network with malicious UDP traffic, conficker and torpig perform brute force attack to obtain administrative access to other machines and storm worm will result in bulk email messages. Also, it has to be noted that the hosts in the TVDLAN are the primary target for the attacker to spread the malware since the hit rate is considerably higher with a rare chance of detection. Hit rate is used as a measure of finding vulnerable hosts for the spread of malware. In case of TVDLAN, there is more possibility for the hosts to have similar applications and operating systems since they belong to single administrative domain. The detection chances are rare since free communication is permitted between the hosts in the TVD-LAN. In case of zero day attack, often it is manual task for the administrator to determine the malicious host that is generating the attack traffic. The detection process becomes more complicated if the compromised host floods the TVDLAN medium with spoofed source address. Although there are some security tools on each virtual machine there are several challenges for the traditional security tools to deal with the emerging attacks. The emerging attacks such as conficker, torpig have the capabilities to disable the security tools and any security features such as auto updates that are running in the vulnerable machines.
TVD-LAN1 Master 1
TVD12
VMM3
Hardware
Hardware
TPM
TPM
TVD-LAN2 Master 2
Figure 3. Attack Scenario
Let us consider a simple scenario with virtual machines that are running on different hypervisors are grouped together into a single administrative domain. Figure 3 shows the TVD architecture for the Figure 1 case scenario. In this case, there is free communication of virtual machines within the TVD. For easy presentation, we use the term TVD-LAN to represent
C. Operation As shown in Figure 4, TVDSEC uses different components to deal with the attacks in the TVD-LAN. All the Virtual Machine communication is monitored by the TVDSEC. Let us consider the operation of the sub components of the TVDSEC.
59
Virtual Machines
VM1
important to maintain a log of the traffic generated and received by each virtual machine. In case of attack, the logs can be analysed to determine the virtual machine that is generating the attack traffic. However the time interval for storage of logs is dependent on the resources available at the VMM. Now let us consider how the Sec_Pol and Trans_Str components can be used to prevent attacks by malicious VM. In some cases, the malicious VM can flood the TVD-LAN medium with different types of messages such as ARP request, DNS requests or junk traffic. Since the source address is validated, only the traffic with correct source address is placed on the TVD-LAN medium. Although it is possible to flood the network with correct MAC address, the Sec-Pol will ensure that duplicate messages can be forwarded only if the VM did not receive any response for its previous request. As shown in Figure 5, the Sec_Pol can determine from the Trans_Str log that the virtual machine has already received response for its previous request. Since the VM is generating duplicate requests even after receiving response, this is considered as suspicious and dropped. The Trans_Ctrl has details of the VMM that are hosting other virtual machines within the TVD. It is used for the dynamic controlling of the VM transactions. The security policies are dependent on the resources available at the destination end. For example, if the destination virtual machine is experiencing congestion, the destination Trans_Ctrl can send a request to the source Trans_Ctrl to reduce the sending rate from the hosted VM. In some cases, if the virtual machine is being restarted, it may not be able to respond to the client requests. With our model, the destination Trans_Ctrl can inform the source Trans_Ctrl or the client that the virtual machine is being restarted. Similarly in some cases, the transactions may have to be suspended during the migration of the virtual machine. The Dom_Sec enforces the domain wide security policies. If the communication of the virtual machine is destined to virtual machines in different TVD, then inter TVD security policies are enforced by this component. Hence we can see that the operation of our model is simple. Also, since the current VMM’s are capable of running the Virtual Machines at native speeds, our model has minimal overhead since it only requires validation of the traffic before placing the traffic on the TVD-LAN medium. However, our model can simplify the tasks of network and security administrators when some attacks are detected in the TVDLAN.
VMn
TVDSEC VMM/ Host OS
TPM
Sec_Pol
Trans_Str Trans_Ctrl
Dom_Sec
Physical Devices Figure 4. Security Architecture for TVD-LAN
The Sec_Pol enforces the security policies for the secure operation of the TVD-LAN. For example, this module can prevent if the virtual machine is trying to dominate the usage of resources within the TVD-LAN or if there are any suspicious processes running in the virtual machine. This component also validates the traffic that is originating from the virtual machine. Only the traffic that is considered as legitimate is placed on the TVD-LAN medium. If the traffic is found to be suspicious, then the traffic is dropped and in some cases the virtual machine can be isolated from other virtual machines in the TVD-LAN. The virtual machines can be connected only after validation by the security administrator. Let us consider some of the sample policies that can be used to validate the traffic generated by the virtual machine. The Sec_Pol ensures that any traffic originating from VM has correct Mac address and IP address. If the source IP address or MAC address of the VM traffic is spoofed then the Sec_Pol and the virtual machine is isolated from other virtual machines. Hence attacks can be detected at the source VMM that is hosting the compromised VM. Note that since the source address of all the packets is validated by the Sec_Pol component, it is not possible for the virtual machines to generate attack traffic with spoofed source address. However at this stage, it is still possible to generate attack traffic with correct source address and we will see later how this is detected and prevented in our architecture. Request Reply Duplicate Requests
III.
IMPLEMENTATION
We have implemented our model shown in Figure 4 on XEN VMM. In principle, the implementation can be extended to other VMMs such as VMware. Xen supports two operating modes paravirtualisation which is supported on any of the hardware and HVM mode which requires some hardware support. We have used [14] to provide TPM based attestation. Xen provides different mechanisms for communication between domains such as event channel, grant table, ring buffer and xen store. There is a privileged VM which is known as
Figure 5. Flooding Scenario
The Sec_Pol logs the traffic in the Trans_Str component before placing it on the TVD-LAN medium. Trans_Str maintains details of the VM transactions. It is important to maintain such logs both at the source VMM and destination VMM since the current VMM’s support live migration of virtual machines between different servers. Hence it is
60
Domain 0 which is used for hosting and the management of the guest virtual machines.
and MAC address, the traffic is placed on the TVD-LAN medium for forwarding to the DNS server. The TVDSEC module which was hosting the DNS server received the traffic. Since no suspicious behaviour was detected, the traffic was forwarded to the DNS server. Similarly, the corresponding response that was generated by the DNS server was found to be legitimate and hence forwarded to the client that has sent the original request.
Dom 0
Dom 0 Sec Pol GVM11 Trans Str Attack GVM12 Tran Ctrl host
Dom Sec
Sec Pol Trans Str
GVM21 DNS Server
Tran Ctrl Dom Sec
VMM1
VMM2
Hardware
Hardware
GVM22
Figure 6: Implementation on Xen VMM
As shown in the Figure 6, we have implemented the TVDSEC components in Dom 0 and analyzed different types of attacks with varying number of guest virtual machines hosted on each physical server. The device drivers in Xen have a front end module which are implemented in the virtual machine and a back end module in the Dom 0. The guest VM sends the packets using the front end drivers and the host machine sends the packets to the guest virtual machines using the back end drivers. The policy engine is placed between the front end and back end drivers. The guest virtual can be running several types of client or server applications on different operating system platforms such as Windows, UNIX//Linux. We have configured the Dom 0 to ensure that the VM traffic is passed though the TVDSEC component. Now the TVDSEC component enforces the security policies on the guest virtual machine traffic and only forwards the traffic that is considered as legitimate. Let us consider some of the case scenarios of how our model deals with different types of attacks.
Figure 8. Flooding with Malicious Traffic
Now consider the case scenario as shown in Figure 8 where a compromised virtual machine started flooding the TVD-LAN with malicious traffic. In this case, we have disabled the security tool that was running in the VM and used this VM to flood the TVD-LAN with malicious traffic. The Sec_Pol could easily determine that the traffic is malicious since the source and destination MAC address of the traffic was not having a valid address. As shown in the Figure 8, the source and destination address has null values in the MAC header. If such traffic is placed in the TVD-LAN environment, it becomes extremely difficult to deal with such attacks. Also, in some cases, multiple hosts can be generating such attack traffic with each host contributing to only little amount of attack traffic. Hence in such cases the administrator will not even notice severe degradation of a single system in the traditional LAN environment. On the other hand our model can efficiently deal with such attacks even if multiple compromised hosts are generating such attack traffic at slow rate. Since all the traffic with invalid source addresses are dropped, the attack traffic will not even be placed on the TVDLAN medium. Furthermore, the attack traffic is prevented at the VMM that is hosting the compromised VM. In addition to this, it is an automated task for the administrator to detect the compromised systems.
A. TVD Flooding In this section we will demonstrate how our model can detect the attacks when a compromised host starts flooding the LAN.
B. Conficker Analysis Now let us consider analysis of Win32/Conficker [7] worm which uses state of the art for the spread of malware. Several versions of Conficker such as Win32/Conficker.A, Win32/Conficker.B, Win32/Conficker.C, Win32/Conficker.D, and Win32/Conficker.E have appeared during the period Nov 2008 to Apr 2009. Conficker targets the unpatched windows machine which allows remote code executing of the code by
Figure 7. Legitimate Scenario
Figure 7 shows a case scenario for communication between a legitimate client virtual machine and DNS server virtual machine that are hosted on different virtual machine monitors as shown in Figure 6. In this case, the TVDSEC module first intercepts the communication generated by the client virtual machine. Since the traffic has correct IP address
61
sending a malicious request. All the versions of windows operating systems from 2000 are vulnerable to this attack. The vulnerability is rated as critical and the attack uses multiple attack vectors for the spread of the worm. The worm also has self protection techniques with several interesting features such as: usage of advanced encryption algorithms such as MD6 for protection of payload and validation of the worm code using digital signatures form the attacker. The earlier versions of the worm generates 250 random domains addresses every day and checks for the updates to the worm and some of the recent versions of the worms check for updates from 500 domain addresses which are randomly selected from the 50000 domain addresses generated every day. It also performs a brute force attack on neighbouring machines to obtain administrative access. It spreads using network connections and removable media such as USB memory sticks. It disables all the security services in the infected systems, disables auto updates to the operating system. Although, Conficker uses the state of the art for infecting and spreading malware, one of its features prevents the attacks in virtual environments. Since virtual machine monitors are currently used for the analysis of malware, the authors of the Conficker malware have used different techniques to determine if the vulnerable host is running in a virtual environment. For example, Conficker uses different techniques such as running sidt, str, sgdt, VMXh to determine it is running in virtual machine environment. If the malicious code detects that it is running in virtual machine environment, then it invokes the sleep API with infinite time interval. Hence, virtual machines in the TVD are not vulnerable to such attacks. However it has to be noted that the attacks will be successful if the attacker alters the malicious code to generate attacks in virtual environment. This is because the current VMMs lack security features to deal with such attacks. Now let us consider how our model can deal with the attacks by considering that Conficker exhibits its malicious behaviour in virtual environment. Note that we are using host based security tools as a primary layer of defence for securing virtual machines. With our model the attacks can be detected when the compromised virtual machine performs brute force attacks on other virtual machines. Even if the host based security tools in the virtual machine are disabled by the malicious code, all the interactions of the infected host are logged in the Trans_Str component. Furthermore attacks are possible with correct source address only. This enables traceback of the malicious virtual machine. IV.
Registers (PCRs). Then, it passes control to the second program’s measurement agent. A bootstrapping process follows where all agents measure the platform components they are responsible for and store the measured values inside the PCRs. The sequence of measurements and hashing by which the PCR values are obtained are also saved as measurement log outside the TPM. When a challenger wishes to learn the state of a trusted platform, he initiates a process known as ‘attestation’. During attestation, the challenger requests the trusted platform for all its measured values and the corresponding Validation Certificates (VCs) provided by their respective manufacturers. If the measured values and the actual values match, the challenger has a good reason to believe that the system environment of the attester is acceptable. The TCG attestation mechanism is based on matching binary hash values of code and for this reason is termed as binary based attestation. However binary attestation techniques reveal too much information to an attester in order to prove that the system state is acceptable. This can potentially lead to other security and privacy issues such as making finger printing attacks on the platform easier. Another significant problem is that binary values of components change every time a component is updated or when a patch is applied. This would require a new component validity certificate to be issued by the manufacturer which includes the new measurement of the component with the patch or the update applied to it. Property based attestation [12] has been proposed to address some of these issues associated with binary attestation. Property based attestation is founded on binary attestation but attests not the binary values but the associated security properties of systems. The main idea is that if a system can somehow prove that it is in a binary configuration that satisfies one or more security properties, then this information is more useful to a challenger compared to hash values. In general, any form of abstraction above the binary value is referred to as a property. Berger et al [15] proposed techniques for the virtualisation of the TPM. The architecture of the TPM virtualisation consists of a vTPM manager and several vTPM instances. The manager runs in the host OS and the TPM functionality to this machine is provided by the hardware TPM. The vTPM manager provides vTPM platform instance for each virtual machine. The manger assigns unique vTPM instance to each virtual machine and each vTPM instance is the complete TPM specified by the TCG. Any of the TPM based attestation techniques can be used in our model. However, it has to be noted that the TPM based attestation techniques cannot guarantee attack free operation and there is need for addition techniques to deal with the attacks. Let us consider some of the VMM based security techniques. Several techniques [16-22] have been proposed to enhance the security tools to detect and prevent security attacks. Dunlap et al [16] proposed ReVirt architecture for secure logging by placing the logging tool inside the VMM. ReVirt claims to log enough information such as real time clock, keyboard, mouse events, user inputs and system calls, which enables the administrator to replay the execution of virtual machine. Since the logs are isolated from the virtual
RELATED WORK
In this section, we present some of the important techniques that are related to our proposed architecture. Most of the servers, desktops and laptops are being shipped with Trusted Platform Module (TPM) chip. TPM enables hardware attestation [9-13] where a host can prove to another host that its operating system, programs, application image, memory content and executables are in a valid state. Every time the platform is booted, the first program to be executed measures itself and the second program, and stores the measured value in registers called Platform Configuration
62
machine, they can be used to replay the logged information and analyse the attacks in case of compromise of the virtual machines. We use techniques similar to the ones in ReVirt in the Trans_Str component of our architecture for secure logging and replay of attacks. Garfinkel [17] proposed a Livewire intrusion detection system which makes use of the virtual machine monitor to analyse the state of virtual machines and detect attacks. Livewire has additional commands for inspection, monitoring and administration of virtual machines. The policy engine queries the OS library to interpret virtual machine system state and events from the VMM interface and decide whether or not the system is compromised. Lares [18] considers techniques for active monitoring by placing hooks in the virtual machine that needs to be monitored. When a program that needs to be monitored reaches the hook, the control is passed to the security tool to ensure the safety of the system. The main advantage of this technique is that since the hooks are placed in the virtual machine that needs to be monitored, it has more clear view of the state and hence the semantic gap is reduced. Lycosid [19] detects hidden process in the virtual machines by comparing the implicit guest view with the VMM image. The idea is to obtain the process running in the guest virtual machine and then obtain the process from the VMM. If the number of processes listed in the guest VM and the VMM are different then there is a hidden process. However attacks can be generated by non hidden processes. Vigilante [20] is a collaborative approach where each host runs specific software to capture the information regarding the exploit of the worm. In case of attack, Self Certifying Alerts (SCA) are distributed to warn other hosts regarding the spread of the worm. The end hosts can use the information in the SCA to identify if it is vulnerable to the worm and apply a host based filter to prevent the worm. Egele et al [21] proposed dynamic spyware analysis tool which monitors the flow of the sensitive data when it is proposed by the web browser and the browser help objects. The tool can analyze the behaviour of the browser help objects and generates a detail report on what data is being sent and to which location it is sent. Blade architecture [22] deals with the drive by download malware by capturing the user interactions and permits only the executables that are authorised by the user. Any download that are not authorised by the user or not supported by the browsers are considered as suspicious and isolated into the security zone.
[1] [2] [3]
[4]
[5]
[6]
[7]
[8] [9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Although, several VMM based security techniques [16-22] have been proposed, none of the techniques take into consideration the specific features of the TVD to deal with the attacks. V.
[17] [18]
CONCLUSION
Today we are witnessing an increasing amount of zero day attacks in the Internet. In this paper we have analysed attacks that are possible in trusted virtual domains and proposed TVDSEC model to deal with the attacks. We have also shown that our model can efficiently deal with the attacks in the TVD.
[19]
63
REFERENCES G. Popek and R. Goldberg. “Formal Requirements for Virtualizable 3rd Generation Architectures”, Communications of the ACM., 17(7):412– 421, 1974. J.E. Smith, Ravi Nair, “The Architecture of Virtual Machines”, IEEE Internet Computing May 2005. Serdar Cabuk, Chris I. Dalton, HariGovind Ramasamy, and Matthias Schunter, “Towards automated provisioning of secure virtualised networks”, Proceedings of ACM CCS 2007. Moore, D., Paxson, V., Savage, S., Shannon, C., Staniford, S., and Weaver, N. “Inside the Slammer worm”, IEEE Security and Privacy 1, 4, Jul. 2003. Wei Yan, Zheng Zhang, Nirwan Answari, “Revealing Packed Malware”, IEEE Security & Privacy, pp. 65-69, Sept 2008. Brett Stone-Gross, Marco Cova, Bob Gilbert, Richard Kemmerer, Christopher Kruegel, Giovanni Vigna, “ Analysis of a Botnet Takeover”, IEEE Security & Privacy, Sept. 2010. Seungwon Shin, Guofei Gu, "Conficker and Beyond: A Large-Scale Empirical Study", Proceedings of ACSAC 2010, Texas, USA, Dec 2010. The Open Source Network Intrusion Detection System: Snort. http://www.snort.org/docs/iss-placement.pdf Trusted Computing Platform Alliance (TCPA), "Main Specification Version 1.1b." Place, Published: Trusted Computing Group, 2003. Trusted Computing Group, "TCG Specification, Architecture Overview, Specification Revision 1.2," www.trustedcomputinggroup.org April 2004. R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn, “Design and implementation of a TCG-based integrity measurement architecture”, Proceedings of the 13th USENIX Security Symposium. Aug. 2004. A. R. Sadeghi and C. Stuble, “Property-Based Attestation for Computing Platforms: Caring about Properties, not Mechanisms”, Proceedings of the ACM Workshop on New Security Paradigms, pp. 67–77, 2004. Chongkyung Kil, Emre Can Sezer, Ahmed Azab, Peng Ning, Xiaolan Zhang, "Remote Attestation to Dynamic System Properties: Towards Providing Complete System Integrity Evidence," Proceedings of the 39th annual IEEE/IFIP International Conference on Dependable Systems and Networks DSN 2009. Integrity Measurement Architecture, Availlable at: http://domino.research.ibm.com/comm/research_people.n sf/pages/sailer.ima.html S.Berger, R. Caceres, K. A. Goldman, R. Perez, R. Sailer, and L. Van Doorn, "vTPM: Virtualizing the trusted platform module", In Proceedings of the 15th USENIX Security Symposium, pages 21–21, Berkeley, CA, USA, 2006. USENIX Association. George W. Dunlap, Samuel T. King, Sukru Cinar, Murtaza A. Basrai, Peter M. Chen, “ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay”, Proceedings of OSDI, 2002. T. Garfinkel and M. Rosenblum, “A virtual machine introspection based architecture for intrusion detection”, Proceedings of NDSS, February 2003. Bryan D. Payne, Martim Carbone, Monirul Sharif, Wenke Lee “Lares: An Architecture for Secure Active Monitoring Using Virtualization”, Proceedings of the IEEE Symposium on Security and Privacy, 2008. Stephen T. Jones, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau,“VMM-based hidden process detection and identification using Lycosid”, Proc. of ACM VEE, March 2008.
Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang and Paul Barham, “Vigilante: End-to-End containment of Internet Worms”, Proceedings of the 20th ACM SOSP, Oct 2005. [21] M. Egele, C. Kruegel, E.Kirda, H.Yin, and D.Song, “Dynamic Spyware Analysis”, Proceedings of Usenix, 2007. [22] Long Lu, Vinod Yegneswaran, Phillip Porras, Wenke Lee, “BLADE: An Attack-Agnostic Approach for Preventing Drive-By Malware Infections”, Proceedings of ACM CCS, Oct 2010. [20]
64
