VESPA: Multi-Layered Self-Protection for Cloud Resources

Aurélien WaillyOrange Labs, France

aurelien.wailly@orange.com

Marc LacosteOrange Labs, France

marc.lacoste@orange.com

Hervé DebarTélécom SudParis, France

herve.debar@telecom-sudparis.eu

ABSTRACTSelf-protection has recently raised growing interest as possible ele-ment of answer to the cloud computing infrastructure protectionchallenge. Faced with multiple threats and heterogeneous defensemechanisms, the autonomic approach proposes simpler, stronger,and more efficient cloud security management. Yet, previous so-lutions fall at the last hurdle as they overlook key features of thecloud, by lack of flexible security policies, cross-layered defense,multiple control granularities, and open security architectures. Thispaper presents VESPA, a self-protection architecture for cloud in-frastructures overcoming such limitations. VESPA is policy-based,and regulates security at two levels, both within and across infra-structure layers. Flexible coordination between self-protection loopsallows enforcing a rich spectrum of security strategies such as cross-layer detection and reaction. A multi-plane extensible architecturealso enables simple integration of commodity detection and reac-tion components. Evaluation of a VESPA implementation showsthat the design is applicable for effective and flexible self-protectionof cloud infrastructures.

Categories and Subject DescriptorsD.4.7 [Operating Systems]: Organization and Design—DistributedSystems; D.4.6 [Operating Systems]: Security and Protection

KeywordsSelf-Protection, Autonomic Computing, Cloud Security, IaaS

1. INTRODUCTIONSecurity is currently viewed as one of the main adoption stoppersto cloud computing. Sheer system complexity leaves the door opento many types of threats coming both from the outside and fromthe inside [4]. Intrusions, malware and other rootkits, or securitypolicy-violations of curious or malicious administrators are just buta few. This problem is particularly acute at the very cloud founda-tion: the infrastructure-level cloud model, or IaaS (Infrastructure-as-a-Service).

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ICAC’12, September 18–20, 2012, San Jose, California, USA.Copyright 2012 ACM 978-1-4503-1520-3/12/09 ...$15.00.

To master mushrooming heterogeneity and vulnerabilities, self-protection is a promising next step for stronger security managementof such infrastructures, e.g., to fight intrusions [7]. Automatedcapabilities of detection and reaction to threats also bring well-known benefits such as lighter administration, lower incident res-ponse times, or reduced error-rates.

A self-protected IaaS infrastructure should take into account threemain features of cloud environments: (1) multi-layering; (2) multi-laterality; and (3) openness. This means that: (1) a cloud infra-structure is composed of many independent software layers withtheir specific security mechanisms, while attacks may target se-veral layers; (2) a cloud involves multiple organizations with theirown security objectives, calling for flexible policies and monitoringgranularities for security management; (3) clouds are increasinglyevolving towards interoperability with other clouds or third-partyIT systems, making a closed-world vision of security not adequate.From those features may in turn be derived a set of key design prin-ciples for a self-protection cloud architecture:

[P1] Policy-based self-protection: the architecture should be arefinement of a well-defined security adaptation model basedon policies. This approach has well-known benefits to in-crease self-management adaptability and extensibility [18].

[P2] Cross-layer defense: detection and reaction should not beperformed within a single software layer, but may also spanseveral layers. Benefits include greater accuracy of the secu-rity response by capturing the global picture of an attack.

[P3] Multiple self-protection loops: several control loops of vari-able level of granularity should be defined and coordinated.A single loop has insufficient flexibility for supervision peri-meter and does not enable trade-offs for response optimality.

[P4] Open architecture: multiple detection and reaction strate-gies and mechanisms – notably heterogeneous off-the-shelfsecurity components – should be easily integrated in the ar-chitecture, to mitigate both known and unknown threats.

Substantial prior work has attempted to build systems fulfillingone or several of those principles, in terms of policy managementframeworks, self-protecting distributed systems, protection mecha-nisms for virtual machines (VMs) and for the virtualization layer,or traditional Intrusion Detection and Prevention Systems (IDPS)and anti-malware tools. Yet, those solutions always seem to fallshort of addressing one principle or more. For instance, despitequite extensive models, generic policy frameworks usually little ad-dress security or cloud environments. Most of the time, policies arenot very granular, and multi-layered defense is not addressed. Exis-ting cloud protection mechanisms are either detection- or reaction-oriented, but rarely both. Similarly, they tackle cross-layering or

155

Systems Principle fulfilled?P1 P2 P3 P4

Policy frameworks yes no no yesSelf-protection frameworks no no no someProtecting VMs some yes no noHypervisor defense no a few no noIDPS/anti-malware techniques no no a few yes

Table 1: Principle coverage by some classes of existing systems.

have flexible policies, but not both. Integration with outside sys-tems also remains difficult. Legacy IDPS are more open, but of-ten without a well-formalized adaptation model. Overall, multipleloops are almost always ignored.

To overcome those limitations, this paper presents an architec-ture and framework based on the previous design principles forbuilding self-defending IaaS infrastructures. Our system calledVESPA (Virtual Environments Self-Protecting Architecture) regu-lates protection of IaaS resources through several coordinated au-tonomic security loops which monitor the different infrastructurelayers. The result is a very flexible approach for self-protection ofIaaS resources.

The main features of VESPA are the following: (1) policy-basedsecurity adaptation based on a self-protection model capturing sym-metrically and flexibly both detection and reaction phases; (2) two-level tuning of security policies according to security contexts bothinside a software layer and across layers; (3) flexible orchestrationof layer-level self-protection loops using system-wide knowledgeto allow a rich spectrum of overall infrastructure self-protectionstrategies; and (4) a layered, extensible architecture allowing sim-ple integration of commodity detection and reaction componentsthanks to an agent-based mediation plane abstracting away secu-rity component heterogeneity.

The VESPA framework was implemented over a KVM-basedIaaS infrastructure and applied to perform dynamic VM confine-ment. Experimental results show that VESPA enables to achieveeffective and yet flexible IaaS self-protection, with reasonable per-formance overheads.

The rest of this paper is organized as follows. After reviewingrelated work (Section 2), we present the VESPA self-protectionmodel and architecture (Section 3). Finally, we present a deploy-ment scenario and evaluation results (Section 4).

2. RELATED WORKSelf-protection has been addressed from several perspectives, witha large body of related work. Table 1 gives a coverage estimationof principles P1–P4 for the most relevant classes of systems.Policy frameworks. Several generic policy management frame-works [5, 19] have been proposed to automate context-aware sys-tem and network adaptations. They are generally built around well-documented, extensible information models. If some of them ad-dress security for traditional IT systems [5], overall policy-drivensecurity automation remains at an early stage for the cloud [9, 16].Few frameworks address multi-layered defense or multiple loops.A notable exception is the FOCALE architecture [19] that sharessimilarities with our work, e.g., the use of a mediation layer to ab-stract security component heterogeneity. Multiple loops are alsosupported, but with different adaptation models: FOCALE featuresan outer loop enabling context-aware adaptation of each compo-nent of a main control loop, while VESPA is based on a hierarchi-cal composition of autonomic managers. However, FOCALE doesnot seem easy to implement, nor to have been applied to the cloud.

Self-protection frameworks. A number of self-defending sys-tems [1, 6, 13] have also been explored. Principle coverage isbroadly similar to policy frameworks, although some projects likeRootSense [13] investigate cross-layer security, or support multiplesecurity algorithms. Like VESPA, RootSense defines a layered se-curity achitecture. However, the RootSense design is more orientedtowards detection (reaction being only the last stage), while VESPAis balanced between detection and reaction (performed symmetri-cally by dedicated agents). Similarly, the self-protection architec-ture of [6] defines a 2-level architecture. Introspection and con-trol interfaces directly derive from the use of a component-basedmodel. However, security mechanisms for detection and reactionremain implicit. By contrast, VESPA makes them appear as anexplicit security management plane, which increases flexibility toinclude third-party security components in the system.Protecting VMs. Virtual machine introspection [15] sparked awhole stream of research to use the capabilities of the hypervi-sor (Virtual Machine Monitor or VMM) to monitor VM behaviors.Different alternatives were proposed to place the monitoring com-ponent: embedded in the VM, in the VMM, or in an "out-of-VM"appliance. A few systems tackled the well-known "semantic" gapissue by comparing monitoring information gathered from differentlayers [10, 11]. These attempts, mostly focused on detection, onlyprovided very simple remediation policies [10], and architectureshardly compatible with legacy anti-malware software. Several re-action mechanisms were also investigated (mainly firewalls [17]),but with little self-protecting features or flexible security policies.Hypervisor defense. One layer below, a variety of techniques aimto protect the VMM from subversion, with special attention to ker-nel exploitation through poorly confined faulty device drivers. Onecan mention: trusted computing architectures [2] providing strongVMM code integrity guarantees; sandboxing [8] controlling com-munications between driver and device, kernel, or user space; vir-tualization [20] to strengthen isolation; or language techniques [23]to detect safety violations. Unfortunately: solutions remained lim-ited to pure integrity checking [2, 23] or containment [8, 20], with-out actions to sanitize the kernel; in general, security policies werenot well separated from interception mechanisms, and thus diffi-cult to manage; and security mechanisms required extensive coderewriting, and thus hard to apply to legacy hypervisors.Detecting intrusions and malware. Finally, generic IDPS andanti-malware tools [3, 22] may also be viewed as providing someform of self-protection, to detect both known and unknown attacks.Those systems are usually based on a single control loop, withsome attempts at cross-layering [22] to detect elusive malwares.Architectures are fairly open to allow selection and compositionof several detection algorithms to improve accuracy. However, inmost cases, they have been little applied to the cloud.

3. VESPA DESIGN

3.1 Design PrinciplesVESPA is built around four guiding principles:[P1] Policy-based self-protection. This principle addresses theheterogeneity, multi-layering, and multi-laterality cloud challenges.The policy-driven paradigm has successfully demonstrated its powerand generality to increase adaptability in self-management [18].For self-protection, this means defining and enforcing a richer setof security strategies [12].[P2] Cross-layer defense. This principle tackles the multi-layeringchallenge. This means that events detected in one layer may triggerreactions in other layers. Conversely, a reaction may be launchedbased on events aggregated from several layers. The cross-layer

156

Figure 1: VESPA Self-Protection Architecture.approach also improves security by helping to capture the overallextent of an attack, often not limited to a single layer, and to betterrespond to it.[P3] Multiple self-protection loops. This principle addresses themulti-laterality challenge by considering self-protection over multi-decisional and reaction paths. A simple decision can generate se-veral reactions, extending monitoring granularity. Multiple stagesof decision are also possible. Different scope levels for securitysupervision may thus be defined and coordinated, and degrees ofoptimality chosen for the response [14].[P4] Open architecture. This principle addresses the openness andheterogeneity challenges. Several types of detection and reactionstrategies should easily be integrated and flexibly composed in thesecurity architecture. The design should notably allow to integratesimply heterogeneous off-the-shelf security components, for strongmitigation of both known and unknown threats. This also increasesinteroperability between security components across clouds.

3.2 VESPA System Architecture OverviewIaaS infrastructures group resources into layers according to thevirtualization level. VESPA considers security management or-thogonally to layers. Self-protection is achieved through a set ofautonomic loops operating over a number of components organizedinto four distinct planes, as shown in Figure 1.

At the bottom, the Resource Plane contains the IaaS resources tobe monitored and protected, i.e., managed elements.

Above, the Security plane contains commodity detection and re-action components that deliver security services such as monito-ring of resource behavior and/or state (e.g., an IDS), or control ofresource behavior and/or state (e.g., a firewall). The APIs of thosecomponents are usually vendor-specific.

Still above, the Agent Plane abstracts away security componentheterogeneity by defining a mediation layer between security ser-vices and decision-making elements. This plane is built from twohierarchies of agents, one for detection, and another for reaction.

A leaf agent (LA) is an adapter between the VESPA frameworkand the security components to translate vendor-specific APIs intoa normalized format both for detection and reaction. It enablesto plug-in third-party security components within the framework.LAs cover directly design principle P4, by defining an open andgeneric interface for framework integration of and interoperabilitywith off-the-shelf security components. LA APIs are usually closeto the ones of security components, tending to make agents highlyspecific. The other extreme is to have generic agents abstractingaway widely used security libraries.

Higher-level agents are in charge either of alert correlation or ofreaction policy refinement. Thus agents enable a granular level ofsecurity supervision over underlying resources.

Finally, at the top, the Orchestration Plane contains the decision-making logic. It is composed of two types of autonomic managerscalled orchestrators: Horizontal Orchestrators (HOs) perform layer-level security adaptation; Vertical Orchestrator (VOs) are in chargeof cross-layer security management.

VESPA made the choice of a layered architecture for securitysupervision, while ad hoc cross-layer controls are also possible.The VESPA design allows simpler, more flexible integration of un-known security components. Indeed, in current cloud infrastruc-tures hand-crafted integration is usually required. A well-formalizedarchitecture may decrease such complexity.

3.3 VESPA ModelWe now present the design of each plane of the architecture.Resource Model. IaaS resources are categorized according to twoorthogonal criteria. A layer defines the location of the resource ina cloud stack. Three separate layers are identified: physical ma-chines running a hypervisor, in turn executing virtual machines(VMs). The view abstraction captures a broad class of resources:computing, networking or storage.

Figure 2: Security Model.

Security Model. Protected Resources (PR) are the critical assetsof the infrastructure to defend (see Figure 2). The main consideredthreats target the VM layer: a malicious VM may fool the IaaSVM placement strategy to become co-located on the same physi-cal server as the target VM. A side-channel attack breaking VMMisolation may then be used to steal or corrupt information from theinfiltrated VM. Attacks on the hypervisor layer are also relevant:a VM "escapes" from VMM isolation and takes full control of thehypervisor. Possible attack vectors include misconfigurations, ormalicious or poorly confined device drivers in the hypervisor. At-tacks against the physical layer such as DMA attacks on devices ortraditional physical network security threats are also considered.

157

Security supervision of PRs is performed by Security Managers(SM). This may mean: (1) monitoring resource behavior througha Detection Manager (DM), e.g., an Intrusion Detection System(IDS); (2) modifying resource behavior through a Reaction Ma-nager (RM), e.g., a firewall; or (3) monitoring and modifying theresource internal state with a Protection Manager (PM), e.g., a filesystem integrity checker. Those security components are typicallyoff-the shelf, accessible only via vendor-specific APIs. All SM be-haviors are governed by security policies.

Figure 3: Agent Model.

Agent Model. Agents perform security context aggregation fromlow-level security events gathered from detection mechanisms (DM/PM) to a high-level risk assessment able to guide the decision pro-cess (see Figure 3). They also realize reaction policy refinementfrom the high-level response chosen after the decision to low-levelpolicies which can be enforced by reaction mechanisms (RM/PM).

Detection works as follows: a DM or PM notifies its associatedDetection Agent (DA) of security-sensitive events. Each DA thenapplies an Alert Aggregation Policy to correlate collected informa-tion from sub-agents before sending them to its parent agent. Whenreaching the root detection agent, security context information istransmitted to the orchestration plane through the HO.

The reaction process is symmetrical: after choosing a layer-specificreaction policy, the HO sends it to the root Reaction Agent (RA).Each RA will apply a Policy Refinement Policy to fine-tune theselected response, before sending it to chosen sub-agents for en-forcement. When reaching a leaf reaction agent, reaction and/orprotection policies are pushed towards the corresponding managersin the security plane.

Figure 4: Orchestration Model.

Orchestration Model. Each IaaS layer contains a HO providing alayer view of security management. The HO is a simple autonomicsecurity manager performing a reflex, local response to threats onlayer resources. The HO gathers the overall layer security contextinformation from the root DA (see Figure 4). The HO Security Ma-nagement Strategy allows it to choose the best layer-level reactionpolicy, then dispatched to the root RA for enforcement.

The HO may also apply decisions coming from the VO. The lat-ter orchestrator realizes higher-level, wider spectrum security reac-tions. The VO coordinates layer-level decisions to provide a consis-tent, cross-layer response to detected threats. The VO Security Ma-nagement Strategy contains administrator-defined policies on alertfeedbacks to trigger or not a cross-layer response. It also allowsthe VO to choose the overall reaction policy, which is then pusheddown to the relevant layers for enforcement by their HOs.

Such loop composition may induce interferences between hete-rogeneous technologies in the security plane (e.g., resource con-tention, predictibility issues) – and thus requires careful componentorchestration. Security management strategies govern decision-making at each level, and may serve to address a particular type ofinterference. For instance, we plan to perform integration testingbetween security components to detect policy conflicts and definethe right resolution strategies. Learning and prediction schemesshould also help to build knowledge, but remain to be explored.4. EXPERIMENTS AND RESULTSA Case Study. We now illustrate how the VESPA framework maybe deployed in practice to automate and coordinate security ma-nagement between IaaS layers. We explore dynamic VM quaran-tine: several VMs suspected to be compromised are isolated tem-porarily, and migrated to a secured zone for cleaning. If reme-diation succeeds, VMs may be migrated back in their original en-vironment, and confinement lifted.

Figure 5 shows a simple VESPA instantiation on a typical IaaSinfrastructure. A specific host (not shown on the Figure), stronglyisolated and trusted, is dedicated to quarantine management. Oneach host, the hypervisor contains two reaction components: a fire-wall to control strictly inter-VM communications; and a migrationmanager to handle VM migration to the quarantine host. User VMs(UVMs) are VM instances protected by VESPA. A UVM containsan anti-virus to analyze and sanitize infections within the VM. AnAdministrative VM (AVM) realizes the VESPA orchestration plane.

Consider a user watching a movie streamed from an untrustedsource: a virus is detected a few seconds after the video started.The UVM anti-virus alerts the AVM, which selects a security res-ponse. Several types of reactions may be chosen and combined:(1) isolate the infected VM to prevent the virus from spreading bycutting its network connections through the firewall; (2) move theUVM to the quarantine host, anticipating virus propagation overunusual channels (e.g., hypercalls) through the migration manager;(3) analyze and clean possible infection vectors by invoking theanti-virus. Upon success, next steps are to migrate back the UVMto the original host, and restore network connections.

Figure 5 shows the different VESPA components to protect thevideo stream. Three levels of self-protection may be achieved: (1)within the VM layer, with only the anti-virus for VM analysis andcleaning; (2) cross-layer, with the hypervisor firewall to isolate theVM; and (3) cross-layer, including also the migration manager tomove the VM to the quarantine zone.Response Time. We analyzed the VESPA self-protection overheadin terms of overall loop latency for the different security adaptationsof the case study. Results are shown in Table 2. In reaction (1),walking the hierarchy of framework entities during detection is fast(0.15s) compared to the effective cleaning operation (5.53s), whichinvolves scanning memory and files. For reaction (2), adding layerinteraction increases response time by only 13% while providingnetwork isolation. Reaction (3) takes about 37 s, which is accep-table to contain infections that are not acute. The major part (90%)of this latency comes from migrating to and from the quarantinehost. Reaction (2) may be a good trade-off between strong securityand low latency, as response time falls to only 6s.

158

Figure 5: Realizing Flexible VM Quarantine with VESPA.

Phase (1) Intra-Layer (2) Cross-Layer (3) Cross-Layer(w/o Migration) (with Migration)

Detection 0.15 0.16 0.17Decision 0.14 0.32 0.37Disconnect - 0.20 0.20Migration - - 14.91Cleaning 5.53 5.72 5.98Migration - - 15.23Reconnect - 0.20 0.20Total 5.82 6.60 37.06

Table 2: End-to-End Self-Protection Latencies (in s).

Other Benchmarks. VESPA self-protection capabilities were alsoevaluated in terms intrusivity and resilience. Detailed results arenot presented here for lack of space. The idea is to disturb the sys-tem by an attack, and see how fast the system recovers to a steadystate, and with which performance impact (bandwidth). Measuredrecovery time is ∼ 60s, with a drop in bandwidth of ∼ 16%. Thus,VESPA enables effective self-protection of a cloud infrastructurewith reasonable performance overhead. VESPA openness shouldalso be assessed. To date, adequate quantitative benchmarks arestill under investigation. A first next step will be to implementagents for different classes of off-the-shelf security components(e.g., IDS, anti-virus, firewall) to evaluate qualitatively integrationeasiness of existing security technologies within VESPA.

5. NEXT STEPSFuture work includes clarifying the smarts needed in the agents bydefining a richer set of policies (e.g., detection, policy refinement,reaction) to extend currently implemented ECA rules.

VESPA is also being refined to address hypervisor-level self-protection [21]: automated monitoring and sanitization of devicedriver I/Os is a big step towards strengthening IaaS security, as suchdrivers are generally the weakest point of hypervisors.

VESPA will finally be extended to provide self-protection for theinter-cloud setting: as heterogeneous clouds become federated ina single multi-lateral infrastructure, placement of security mecha-nisms will no longer be only a vertical, layer-oriented issue. It willalso be a horizontal design challenge between multiple security do-mains in the network and system security architecture, challenge towhich self-protection may bring answers.

AcknowledgementsWe thank the anonymous reviewers for their insightful comments.This work was supported by the OpenCloudWare project, fundedby the French Fonds national pour la Société Numérique (FSN).

6. REFERENCES[1] Y. Al-Nashif, A. Kumar, S. Hariri, G. Qu, Y. Luo, and F. Szidarovsky.

Multi-Level Intrusion Detection System (ML-IDS). In International Conferenceon Autonomic Computing (ICAC), 2008.

[2] A. M. Azab et al. HyperSentry: Enabling Stealthy In-Context Measurement ofHypervisor Integrity. In ACM Conference on Computer and CommunicationsSecurity (CCS), 2010.

[3] A. Baliga, L. Iftode, and X. Chen. Automated Containment of Rootkits Attacks.Computers & Security, 27:323–334, 2008.

[4] Cloud Security Alliance. Top Threats To Cloud Computing, 2011.http://www.cloudsecurityalliance.org/topthreats.html.

[5] N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The Ponder PolicySpecification Language. In International Workshop on Policies for DistributedSystems and Networks (POLICY), 2001.

[6] N. De Palma, D. Hagimont, F. Boyer, and L. Broto. Self-Protection in aClustered Distributed System. Parallel and Distributed Systems, IEEETransactions on, 23(2):330 –336, 2012.

[7] D. Frincke, A. Wespi, and D. Zamboni. From Intrusion Detection toSelf-Protection. Comput. Netw., 51:1233–1238, April 2007.

[8] V. Ganapathy et al. The Design and Implementation of Microdrivers. InInternational Conference on Architectural Support for ProgrammingLanguages and Operating Systems (ASPLOS), 2008.

[9] R. He, M. Lacoste, and J. Leneutre. ASPF: A Policy Administration Frameworkfor Self-Protection of Large-Scale Systems. IARIA International Journal OnAdvances in Security, 3(3–4):104–122, 2010.

[10] A. Ibrahim, J. Hamlyn-Harris, J. Grundy, and M. Almorsy. CloudSec: ASecurity Monitoring Appliance for Virtual Machines in the IaaS Cloud Model.In International Conference on Network and Systems (NSS), 2011.

[11] X. Jiang, X. Wang, and D. Xu. Stealthy Malware Detection throughVMM-Based "Out-of-the-Box" Semantic View Reconstruction. ACM Trans.Inf. Syst. Secur., 13:1–28, 2010.

[12] J. Kephart and W. Walsh. An Artificial Intelligence Perspective on AutonomicComputing Policies. In Fifth IEEE International Workshop on Policies forDistributed Systems and Networks (POLICY), 2004.

[13] R. Koller et al. Anatomy of a Real-Time Intrusion Prevention System. InInternational Conference on Autonomic Computing (ICAC), 2008.

[14] O. Mola and M. Bauer. Towards Cloud Management by Autonomic ManagerCollaboration. International Journal of Communications, Network and SystemSciences, 4(12):790–802, 2011.

[15] K. Nance, M. Bishop, and B. Hay. Virtual Machine Introspection: Observationor Interference? IEEE Security and Privacy, 6:32–37, September 2008.

[16] ObjectSecurity. OpenPMF White Paper, 2011. www.openpmf.org.[17] R. Sailer et al. Building a MAC-Based Security Architecture for the Xen

Open-Source Hypervisor. In Annual Computer Security ApplicationsConference (ACSAC), 2005.

[18] J. Strassner. Policy-Based Network Management: Solutions for the NextGeneration. Morgan Kaufman, 2003.

[19] J. Strassner et al. The Design of a New Context-Aware Policy Model forAutonomic Networking. In International Conference on Autonomic Computing(ICAC), 2008.

[20] L. Tan et al. iKernel: Isolating Buggy and Malicious Device Drivers UsingHardware Virtualization Support. In International Symposium on Dependable,Autonomic and Secure Computing (DASC), 2007.

[21] A. Wailly, M. Lacoste, and H. Debar. KungFuVisor: Enabling HypervisorSelf-Defense. In EUROSYS Doctoral Workshop (EURODW), 2012.

[22] Y.-M. Wang, D. Beck, B. Vo, and C. Verbowski. Detecting Stealth Softwarewith Strider GhostBuster. In International Conference on Dependable Systemsand Networks (DSN), 2005.

[23] Z. Wang and X. Jiang. HyperSafe: A Lightweight Approach to ProvideLifetime Hypervisor Control-Flow Integrity. In IEEE Symposium on Securityand Privacy, 2010.

159