Identifying and Analyzing Security Threats to Virtualized Cloud Computing Infrastructures

Identifying and Analyzing Security Threats to Virtualized Cloud Computing Infrastructures rrz z ro er  m ners enoo s s nsrrz@eumm mer@eumm

Ab-  A multi-tenant Cloud Computing Infrastructure (CCI) consists of several Virtual Machines (VMs) running on same physical platform by using virtualization techniques. The  VMs are monitored and managed managed by kernel kernel based based soware soware i.e.  Virtual  Virtual Machine Machine Monitor Monitor (VMM) or hypervisor which is main component of Virtualized Cloud Computing Infrastructure (VCCI). Due to soware based vulnerabilities, VMMs are compromised to security attacks that may take place from inside or outside attackers. In order to formulate a secure VCCI, VMM must be protected by implementing strong security tools and techniques such as Encryption and Key Management (EKM),  Access Control Mechanisms (ACMs), Intrusion Detection Tools (IDTs), Virtual Trusted Platform Module (vTPM), Virtual Firewalls (VFs) and Trusted Virtual Domains (TVDs). In this research paper we describe the techniques of virtualizing a CCI, types of attacks on VCCI, vulnerabilities of VMMs and we critically describe the signicance of security tools and techniques for securing a VCCI. Kwd-  Virtualization Virtual Machine Monitor Attacks and Vulnerabilities, Security Tools and Techniques

I.

Introduction

Considerng the reduction n global warmg cloud computng is is movng towards the the platform of vrtualzation [1]. Under this tecique hadware or sowe resoces such as memor, CPU, storage, network are logically porioned and  provided to multiple tenants. However vrtualzation vrtualzation is complex and has a considerable attack sface. It is prone to bugs and unerabilities [2]. The applications of clients are rung on VMs residg on VCCI. Snce the VMs are not  permitted to access the underlyng physical hardware drectly, hypervisor or VMM is used to manage, monitor and isolate VMs om each other and the host OS [3]. One of the prmary benets that vrtualization brgs is isolation. This benet, if not carelly deployed will become a teat to the operatng envroment [4]. However, Cloud Service Providers (CSPs) unerae a susania eor o secure er ssems n orer o mnmize the teats to nastructe but still hypervisors has aws of weak security isolation [5]. If an attacker is able to gan access over the hpervisor, whole service could be at risk and all the VMs rug over the hypervisor would be compromised [6-7]. Due to appropriate securit standards used for hpervisors at nastructure level, there are security gaps that can be exploited by the side or outside malicious attackers to misuse the astructure [8]. Sce public cloud  provides open global accesses to heterogeneous clients,

umm z ro usn mrn reson ners mn  ruks.facultypreston.ae

condentiality, ntegrity, security, availability, authenticity and  privacy are essential ess ential conces for both CSP and clients c lients as well. Security and privacy ae the most signicant challenges that may mpede the cloud computng adoption. Violatng the security of any component will impact the other components consequently the security of the entre system will collapse [3]. CCI must be secure at each layer such as physical, network, vrtualzation and application layers. However, the focus of this research paper is to identi and analyze the security issues and  teats only on VCCI. VCCI . II.

Vrtualzng Vrtualzng The Cloud Computng Inastructe

The adoption of vrtualization n cloud computng brought up several advantages compared to traditional computg nastructure where one resource was allocated to a sngle VM at a tme [9]. The clients are eractng with the physical nastructure by accessng ther applications on ther personal VMs rung on a hervisor as shown n Fig. [9].  

 

 g 

  fuu Fi  g  ure   ure I CloudVirtalization CloudVirtalization[9]

Snce a VCCI consists of numerous clients VMs that, e controlled by VMM to ensure far schedulng, memory and resoce allocation etc. The VMM itself is runng on the  physical nastructure by utilizng the host OS [ 0]. The VCCI is similar to the OS envronment, where multiple processes are rug on a sgle OS which is responsible for monitorg and managng the processes. There are two main tpes of hypervisors used on a VCCI i.e. Type- ad Type-2. A Type-

Poceedin  g s of 2012 Intenational ofCloudComputin  g   Technolo  g  Applications Mana  g   g , Technolo   g ies, Applications   g ement  978-1-4673-4416-6/12/$  978-1-4673-4416-6/12/$ 31.00 © 2012EEE

151

 154741228: Identifyin   Identifyin andAnalyin andAnalyin Secuity Theats to Vitualied Vitualied Cloud Computin Computin Inastuctues

hypervisor runs drectly upon the hardwe with a sepated layer om the host OS. Tpe-2 hpervisor runs together with  the host OS. Due to the isolation om the host OS, the security, performance and scalability features n Tpe- are eanced tha Type-2 [11]. The highly used ndustry based  tpe- and tpe-2 hpervisor nclude Xen and KVM respectivey.

Enl

A. Xen Hypervisor

Xen resides between the VMs and underlyng physical hardware. In order to create a secure operatg envroment, Xen hypervisor divides the VMs nto two domas i.e. Doman (Dom) and Doma (DomU) accordg to the accessibility privileges. The Dom VM has higher privileges and it can access the hadwe whereas DomU VMs have lower privileges and caot drectly access the hardware. hen Xen hypervisor sts, for the rst tme it loads Dom VM. Normally the user of Dom is a system admistrator who has privilege to use the hypervisor nterface to create, delete or manage any DomU VMs. Each DomU VM contans a modied Lnux keel that cludes ont-end ivers that comunicates with the Xen hypervisor, stead of comnicatng drectly with hardware. For each DomU VM, CPU and memory access operations are hadled dectly by the Xen hpervisor. However, 10 is drected to Dom snce Xen hypervisor itself is not able to perform any I/O operation [12]. B Kernel Virtual Machine (K Hypervisor

KVM is developed by mplementng Lx keel module with enhanced hypervisor nctionalities. Each Lnux process has two modes of execution, user and kernel mode. The user mode is considered as unprivileged while keel mode is considered as privileged process. The default mode for a  process is user mode. It changes to the keel mode when it requres some sor of services om keel such as request for writng to hard disk. hile implementng the KVM, the developers added a thrd mode for process, called as guest mode. The guest mode itself has two normal modes user and keel, can be called as guest-user and guest-keel mode. hen a guest process is executng non-I/O guest code, it will run  guest-user mode. In guest-keel mode, the process handles exits om guest-user mode due to I/O or other special strctions. In user mode, the Lux process performs I/O on behalf of a guest. In the KVM model each guest VM is plemented as a smple Lux process and that process itself is able to rn multiple applications concurrently because it is actng as a vrtual OS [13]. Each VM is scheduled by standard Lx scheduler. III.

Fiue 2.Inside 2.Inside andOutside andOutsideAttack Attack [8]

Attack on any component of VCCI may affect the others. In order to overcome this issue, the astructure needs to be secured by implementng security tools and teciques that isolates the VMM, guest/ host OS and physical hardwe om  the side-effects of each other. [2] Identied two major attacks on VCCI (VM to VM and VM to Hpervisor) as shown n Fig. 3 [2].

. End \. U

  1    · ···

Clou Poi

Clud

Hype· isor tVM atak

Servers

TTACKSON VCCI AND ULN U LNERAB ERABILITIES IE SOF

VMM Due to nappropriate secity standards used for hpervisors at nastructure level, there are several security gaps that can be exploited by the side or outside malicious attackers to misuse the nastructure as shown n Fig. 2 [8].

Fiue 3.Attack 3.Attack Suface [2]

The attacks visualized  Fig.3 can take place due to tee major uerabilities (VM hoppg, VM escape and VM mobility) identied  hpervisors [7] [4].

Poceedins of 2012nteational 2012nteational of CloudComputin, Technoloies,   Technoloies, Applications  Applications  Manaement

152

 Saa Nawa Bohi,  MevatAdib  MevatAdib Bamiah, Muhammad  Muhammad Naw Bohi, Ruk shanda shanda Kama Kamann

A, VM Hopping

hen several VMs are rug on the same host OS, a malicious attacker such as remote un-trsted cloud user on one VM can obtan the access of other VM just by knowng its IP address. Once a VM is attacked, the attacker can monitor the  trac gong over the VM ad change the ow of trac or manipulate it. This attack can can create a major issue of Denial of Service (DOS) that is actually an attempt to make a computer resource unavailable to its tended users [4]. If VM is rung sce a long te, an attacker can modi the conguration le such that VM goes o state. Therefore the ongong comnication to that VM could be stopped. hen  the coection is resumed, the VM needs to star the entre comnication agan [7]. B VM Escape

This unerability allows a guest-level VM to attack its host. Under this an attacker such as a un-trsted user of cloud services can run a code on a VM that allows an OS rung withn it to bre out and teract drectly with the hypervisor. Such an exploit could give the attacker access to the host OS and all other VMs rng on that host [4]. If an attacker gans access to the host rung multiple VMs, he/she can access the resoces which are shared by the other VMs. The host can monitor the memory beng allocated and the CPU utilization. If necessary an attacker can brng down these resoces and turn off the hypervisor and if the hypervisor fails, all the other VMs  o eventually [7]. C VM Mobili

Under a VCCI VMs can move om one physical host to another is called as VM mobility. However, VM mobility can be risky for security attacks, VM les can be stolen without  physical the t he of the host mache [3]. VMs can be moved over  the Network or copied tough a USB. Snce VM are not essentially present on the physical mache, the teat for an attack ncreases. The contents of the VM ae stored  a le on  the hpervisor. If the VM is moved to another location, then  the vrtual disk is also recreated and an attacker can then modi the source conguration le and alter the VMs activities. VM can also be compromised if the VM is one. An attacker can modi the conguration le of the VM. Gang access acce ss to the vrtual v rtual disk, attacker has sufcient  te to break n all the security measure such as  passwords, orant credentials, etc. Sce S ce this VM is a copy of the actual VM, it is difcult to trace the attacker with  this teat [7]. This attack is normally caused by a malicious cloud admnistrator. IV.

ECURITY OOLS OOLSAN ANDD ECH ECHIQU IQUES ESFOR FORE  ECUR CU RING THE TH E IRTUALIZED IZ ED LOUD OMPUTING IN G NFRASTRUCTURE

There are numerous security tools and teciques available  to overcome the malicious teats on VCCI ad hypervisor unerabilities. Durng our analysis, we have identied some major approaches for securng a VCCI by reviewng the past and present literature. These nclude EM, ACMs, Ts,

vTPM, VFs ad TVDs. The signicances of these teciques  to secure a VCCI are described as follows: A.

Encption and Key Management (E

The protection of data aganst the loss and the is a shaed responsibility of cloud customer and CSP. Nowadays, encryption is one of the strongly recomended teciques  cloud Service Level Agreements (SLAs) [26]. The condential data of customer must be encrpted at tee different stages i.e. encryptio encryptionn of data- at- rest (encrptng (encrptng the customer customer's 's data on disk storage as cipher tex that will protect the data om malicious CSP and illegal use), encryption of data-at-trasit (encrptg the condential nformation such as credit cards while transmittng over a network) and encrption of data on backup media such as external or nternal storages, this can  protect aganst misuse of lost or stolen media [14]. However, encryption only is not enough to keep the data secure, there must be proper key management practices to ensure the safe and legal access of encryption keys. For-nstance encryption keys must be protected same as sensitive data itself and these keys should be accessed only by lmited ad authorzed  personalities and proper procedes must be followed if encrption keys are lost or stolen [14]. It is the customer's responsibility to enforce the use of encryption and key management  ther SLAs. However, tpe of encrption  tecique used depends upon the requrements and objectives. The common encrption methods that can be used on VCCI nclude symmetric and asymmetric algoritms. From symmetric crptography family, Triple Data Encrption Algorithm (TEA) also known as Triple-DES or (3DES) and Advanced Encryption Standad (AES) e most comon types of encrption teciques. These tpes of encrption and decrption process use a secret key. From asymetric crptography, RSA and Elliptic Curve Crptography (ECC) are mostly used encryption teciques, unlke symmetric these methods uses two different keys, a public key for encrption and a private key for decrption [24]. If data encrption  practices are followed accately, the data will be saved om  the illegal accesses or the of a malicious CSP's admnistrator and remote hackers. B

Intrusion Detection Tools Ts)

The multi-tenant and distributed nate of the cloud makes it a attractive target for potential intruders. Appropriate IDTs should be used at VCCI which contnuously collects and analyzes data om a computng system, ag to detect ntrusive actions. There e two ma approaches for IDTs i.e. Network-based Ts (NIDTs) and Host-based Ts (HITs), NIDTs are based on monitorng the network trac owg  tough the systems and examnng events as packets of nformation exchange between computers. hile, HITs are based on monitorng local activity on a host lke processes, network coections, system calls, logs, etc and examng events lke what les were accessed and what applications were executed [16]. Both Ts tools should be used at VCCI to ensure safe and secure operatng envronment n order to block  the ruders.

Poceedins of 2012nteational 2012nteational of CloudComputin, Computin,  Technoloies,  Applications  Manaement

153

 154741228: Identifyin   Identifyin andAnalyin andAnalyin Secuity Theats to Vitualied Vitualied Cloud Computin Computin Inastuctues

C

Virtual Firewall (VF)

It is a rewall service runng n a vrtualized envronment which provides usual packet lterg and monitorng services  that a physical rewall provides [18]. VFs can execute n various modes tpically hypervisor-mode (hpervisor resident) and bride-mode. In order to protect the VMs and VMM, hypervisor-resident VFs must be implemented on the VMM where it is responsible to capture malicious VM activities ncludng packet njections. These VFs requre a modication to the physical host hpervisor keel to nstall  process hooks or modules allowng the VF system access to VM nformation and drect access to the vrtual network switches as well as vrtualized network erfaces movng  packet trac between VMs. The hypervisor-resident VF can use the same hooks to then perform all rewall nctions lke  packet nspection, droppg, and forwadng but without actually touchng the vrtual network at any po. Hpervisor resident VFs can be faster as compaed to bridge-mode VFs because they are not performg packet spection n VFs, but rather om with the kernel at native hardwae speeds [19]. D. Trusted Virtual Domains (TVDs)

A TVD is security technique formed at VCCI by groupg  the related VMs runng on separate physical mache o a sngle network doman with a unied security policy. The multiple nstances of TVDs co-exist on a sgle platform under a shaed resource policy. The use of TVD provides strong isolation among un-related VMs as the communication among TVDs takes places only accordg to the security  policies deed by admistrator congured n the VMM. A malicious VM canot jon any TVD because  order to jo TVD, a VM should ll the requrements of the policy so no malicious VM can affect the VMs of trusted users on cloud [20]. Normally the VMs residg n a TVD are labeled with a unique identier. For-stance the VMs of one customer will be labeled differently om the other customer. The labelng is used to identi the assigned VMs to a paricular customer and  to allow the same s ame labeled VMs to run on side the same TVD  that must be designed by followg a proper security guidelnes and policies that doesn't ehibit any loop holes. E.

Access Control Mechanisms (ACMs)

ACMs are responsible responsible of protectng protectng of a VCCI by limitg, denyng or restrictng access to a system or an entity such as  processes, VM and VMMs accordng to the well dened dene d security policies [15]. Most comon ACMs used n VCCI clude Mandator Access Control (MAC), Discretionary Access Control (DAC) and Role Based Access Control (BAC). All these techniques are known as identity based ACMs as user subjects and resources objects are identied by unique names. Identication may be done drectly or tough roles assigned to the subjects [25]. ACMs guarantees egrity and condentiality of the resources. Access control must be  performed by a trusted pary which can be also the CSP or  thrd party n association with the cloud customer. Moreover,  the collaboration and the expression of access control at each layer e.g. hypervisor or OS must be achieved  a dedicated

and neutral language to allow a unication policy regardless of the layer layer.. F

Virtual Trusted Plaorm Module (vTP

IBM reseachers proposed TPM vrtualization that is based on certicate chan lkng vTPMs to the physical TPM n order to provide its capabilities and make it available to all VMs runng on a platform. vTPMs can be located n a specic layer over the hypervisor. A vTPM nstance is created for each VM by vTPM Manager which is built in a specic VM and may nvoke its own vTPM tough the hypervisor [17]. Each VM has its associated vTPM stance that emulates  the TPM nctionality to extend the cha of trust om the  physical TPM to each vTPM via carel management of signng keys and certicates. A vTPM has its own vrtual Endorsement Key (EK) and vrtual Storage Root Key (SRK) beside some sowae on the host. In multi-tenant VCCI  the system s ystem of vTPM vrtualizes vrtual izes a physical TPM to be used by a number of VM on a sngle hardwae hardwae platform [23]. V. MPLE PL EMENTATION OF ECURITY OOLS AND AN D ECIQUES ECIQU ES FORORMUL MU LATING IN G AE  ECURE CU RE VCCI The security tools and tecniques discussed  previous section have been implemented by various researchers to design and develop secure VCCI. This section describes some of the valuable valuable contributions by the researchers. [21] designed Trusted Vrtual Datacenter (TVDc). The am of TVDc is to  provide a safety net that reduces the risk ris k of security s ecurity issues that  take place by misusg the VMs with the help of malicious soware. [22] Proposed a trusted VMM with the use of encryption methods This tecnique is referred as CloudVisor It is implemented as a security monitor that runs in the highest  privileged mode even more than the hypervisor. Once the CloudVisor runs then it stas the hypervisor that executes n  the least privileges mode. In order to enforce protection and isolation, CloudVisor monitors the use hardware by VMM and VMs. CloudVisor uses security authentication TPM for secure boot-up and encrption of VMs data. [8] Proposed the TVMM by usng TPM as root of trust by implementg it on Xen hypervisor. The vTPM provides the isolation iso lation security between VMs so no ay VMs can access the resources of others. [8] Also proposed a page-based encryption method. This method uses the secret key managed by the hypervisor to encrypt all  pages. Encrption Encrpti on uses AES-128 n CBC mode, and hashg uses SHA-256 before the pages are handed over to Dom. These are few of the valuable contributions however there is  tremendous amount of research beng carried out by several researchers for securng the VCCI. VI.

ONCLUSION AND AN D UTURE WOR WORK K

Multi-tenancy is one of the signicant chaacteristics of cloud computng that refers to the mechanism of sharng a cloud platform ad resoces to the several clients. In order to achieve the benets of this tecique, cloud computg has moved towards vrtualzation, where each clients is assigned with one or multiple VMs. Beside the benets, multi-tenant cloud envroents is also unerable to attacks that have mpede the trust on adoptng cloud computng. Attacks have

Poceedins of 2012nteational 2012nteational of Cloud Cloud Computin, Computin,  Technoloies, Applications   Applications  Manaement

154

 Saa Nawa Bohi,  MevatAdib  MevatAdib Bamiah, Muhammad  Muhammad Naw Bohi, Ruk shanda shanda Kama Kamann

been identied om outsiders and nsiders The major targeted  po for attack on  ncludes the VMM. V MM. In order to secure  the VMM, several teciques have been ntroduced that ae plemented by various researchers om academia and dustry to sece the I. The adoption of cloud computng is an un-stoppng task so the challenge is to formulate a secure . In order to contribute n the eld of cloud computg we analyzed the security issues on VI, however security is not only limited to vrtualzation components. A  must be secure at various layers physical, network, application, management and organzational layers by considerng the govemental policies and SLAs etc. However, the ture drection of o resech is to conduct an analysis identig and overcomng the security issues on cloud computg om goveance and operational perspectives.

[9] [10]

[] [12]

[13]

COLE COLEDD GMENT GMENT

[14]

We are thal to God Aighty for gvg us the knowledge and wisdom to complete this work. We are also  thl to o parents for ther encouragng suppor.

[15]

EFERENCES

[16]

[]

Y amini, amini, B.   Selvi,  D .V., V.,  2010.Cloud 2010.Cloud vitualiation: A  A potential way to   educe lob al wamin. wamin.  In Recent Advances Advances in Space Technolo  Services and Climate Change (RSTSCC), 2010   Recent Advces in  Space Technoloy Sevices and Climate Chane (RSTS (RSTSCC),  2010. pp.  5557. [2] Sefe, 1  et al. 2011. Eliminatin the hypeviso attack suface fo a   moe secue cloud. Proceedings of the 18th ACM coerence on Computer and communications securi Chicago, linois, USA, ACM:

[3]

[4]

[5] [5] [6]

[7]

 401-412 .   D awoud, .,  Tak Tak ouna, .  . Meinel, C., 2010. Inastuctue as a seice seice  secuity: Challenes and solutions.In Informatics and Systems (INFOS). 2010 e 7th International Conference on Infomatics and Systems  (FOS), 2010. pp. 18. Shenmei, L., et a., 2011. Vitualiation Vitualiation secuity fo cloud computin  sevice. In Cloud and Service Computing (CSC), 2011 International Se vice Computin (CSC), CSC), 2011 Intenational Coerence on Cloud and Sevice Confeence on. pp. 174179. Tak Tak ab i, H.,  Joshi,  J.B.D J.B.D .  Ahn, G ., 2010. Secuity and Pivacy Challenes in Cloud Computin Envionments.  Securi & Privacy IEEE,  8(6),  pp.24-31. an, Z.    Ji, x  2010. HypeSafe: A Lihteiht Appoach to Povide Lifetime Lifeti me Hypeviso Hype viso Contol-Flow Contol-Flow Inteity.  In Securi and Privacy (SP), 2010 IEEE Symposium on  Secuity  Secuity and Pivacy (SP),  2010 IEEE Symposium on. pp. 380395. Jasti, A., et al. 2010. Secuity in multi-tenancy cloud. In  Securi

[17] [18] [18] [19] [0]

[21] [22]

[23] [24]

Technolo (ICCS, 2010 IEEE International Carnahan Conference on  Secuity Technoloy (CCST) CST),, 2010 IEEE Intenational Canahan

[8]

Confeence on. pp. 3541. Jinhu Kon, 2010. Potectin the Condentiality of Vitual Machines Aainst Untusted Host. In Intellience Infomation Pocessin and Tusted Tus ted Computi Comp utin n (P (PTC), 2010 Inteational Symposium Symposium on. Intellience Intell ience Infomation Infom ation Pocessin Pocessin  and Tusted Computin Comp utin (IPTC),  20  0International Smposium Smposium on. pp. 36 4368.

[25] [26]

Fu en    Li Xian, 2011. The study on data secuity in Cloud Computin b ased on Vitualiation. In I. In Medicine and Education  (T  (TME), 2011 Intenational Intenational Symposium on. pp. 257261. Suyanayana, v   Jasti, A.  Pendse, R., 2010. Cedit schedulin and   pefetchin in hypevisos usin Hidden Mak ov Models. In Local Compute Netwok s (LCN), (LCN), 2010 IEEE 35th Confeence on. Local Compute Netwok s (LCN), (LCN), 2010 IEEE 35th Confeence on. pp. 224  227. Nauhton, ., et al. 2010. Loadab Loadab le Hypeviso Hypeviso Modules,  System  Sciences (HI (HICSS), 2010 43d HawaiiIntenational Confeence on,  vol.,   no.,  pp.-8. Peijie Y u. et a., 2010. Real-time Enhancement fo Xen Hypeviso. In   Emb edded and Ub iquitous Computin (EUC), 2010 201 0 IEEE/IFIP 8th Intenational Confeence on. Emb edded and Ub iquitous Computin  (EUC), 2010 20 10 IEEE/ IEEE /IFIP 8th 8t hIntenationalConfeence on. pp. 23-3 0. Pham, c.,  et al. 2011. CloudVal:  A amewok  validation validation of   vitualiation envionment in cloud inastuctue. In D ependab le  Systems  Systems    Netwok s (D SN), 2011 IEEE/IFIP 41st Inteational Inteati onal Confeenc Confeencee on. D ependab ependab le Systems Systems    Netwok s (D SN), on. pp. 189 196. CSA,  2010, D omain omain 12: G uidance uidance foIdentity foIdentity AccessManaement V2..Cloud SecuityAlliance. SecuityAlliance.Availa Availabb le at: at:   http: //www.cloudsecuityalliance. //www.cloudsecuityalliance.o/uidance/csaui o/uidance/csauidede- dom 12.pdf Afoulk Afoulk i, Z., et al. 2012. MAC potection potection of the Open Neb ula Cloud  envionment, Hih Pemance Computin and Simulatio S imulationn (HP (HPCS),  2012 IntenationalConfeence on,  vol.,  no.,  pp.85. Haley Haley Koushk o,  Intusion Intusion D etection: Host-Based and Netwok -Based Intusion D etection Systems, Availab   Availab le om   http: //infohost.nmt.edu/sfs/Students/HaleyKous //infohost.nmt.edu/sfs/Students/HaleyKoushk hk o/Papes Papesntusion ntusion   D etecti onPape.  onPape.  pd    pd  Achemlal, M., et.al. 2011. Tusted Platfom Module as an Enab le fo  Secuity in Cloud Computin, Netwok and Infomation Systems  Secuity (SAR-SSI), 2011 Confeence Confeence on  , vol.,  no.,  pp.-6. ik i, VitualFiewall, Availab   Availab le om   http: //en.wik ipedia.o/wik iVitual_ewall. Vitual_ewall. Clement Bethelot, Evaluation of a VitualFiewall in aCloud   Envioent, Availab   Availab le om om   http: //b uchananweb .co.uk /09014406_MSc_ /09014406_MSc_VituaFiewall.pd Fiewall.pd Luii, C., et al.TustedVi TustedVitua tuall D omains omains  D esin, esin, Implementation  Implementation and   Lessons Leaed, Availab   Availab le om om   http: //infohost.nmt.edu/sfs/Students/HaleyKous //infohost.nmt.edu/sfs/Students/HaleyKoushk hk o/Papes Papesntusion ntusion   D etectionPape.  pd Bee, S., R. Cacees, et al. 2009. Secuity  the the cloud inastuctue: inastuctue: Tusted vitual vi tual data cente cen te implementation implem entation.. IBM Jounal of Reseach  and D evelopment 53(4):  6: 1-6: 1-6: 12. Zhan, F., et al. 201 1. CloudViso: CloudViso: etoin potection potection of vitual   machines in multi-tenant cloud with nested vitualiation. Poceedins  of the Twenty-Thid Thid ACM Symposium on Opeatin Systems Pinciples.Cascais, Potual,   Potual, AC   ACM : 203-216. D onxi, onxi, L., et al. 201 0. A Cloud Achitectue of Vitual Tusted Tusted Platfom Modules, Emb edded and Ub Ub iquitous Computin (EUC), (EUC),  2010 IEEE/ IE EE/I IFIP 8th 8t hInteationalConfeence on,  vol.,  no.,  pp.804-811. Jin-Jan h., et al. 2011. A BusinessModel BusinessModel foCloud foCloudComputin Computin Based  on a Sepaate Encyption and D ecyption Sevice, Infomation   Infomation Science  andApplications (C (CISA), 2011 Intenational Confeence on  , vol.,  no.,   pp.-7, 26-29. Khan, A., 2012. Access Access Contol in Cloud Computin Envioent, In ARPN ARPN Joual of Enineein Enine ein and Applied Appl ied Sciences, Sciences  , vol-7,  no-5.,   pp.613-615. Jansen, .,  and G ance, ance, .,  2011, G uidelines onSecuity and Pivacy in Pub lic Cloud Computin. Computin. ational Institute of Standards and Technolo Special Publication 800-144   NIST IST SpecialPub lication 800 144.

Poceedins of 2012ntenational 2012ntenational of Cloud Cloud Computin, Computin, Technoloies,   Technoloies, Applications  Applications  Manaement

155