A Virtual Machine Introspection Based Architecture for Intrusion ...

NIDSes [33]. VMI IDSes also realize these benefitswith a high-level policy language. Additionally,high-level policy languages also reduce the possibilityof a total compromise due to memory safety problems.A high-level language like Python is especiallywell suited for doing pattern matching, manipulatingcomplex data types, and other operations that are frequentlyuseful for introspection. This expressivenessand ease of use allows policies to be written in a conciseand easy-to-understand manner that minimizeserrors.• Failing Closed: In Livewire, the VMM can suspendon the last synchronous event that occurred and willnot continue until explicitly instructed by the IDS.This means that even if the policy engine crashes,protected hardware interfaces will still not be exposed.This type of fail-closed behavior is alwaysrecommended when a VMI IDS is also being used asa reference monitor.• Event Flow Control: In the case when Livewirecannot keep up with queued asynchronous events, theVMM can suspend until Livewire can catch up. Unlikean NIDS which cannot necessarily stem the flowof traffic [33], it is easy to stem the flow of events tothe VMI IDS.• Avoiding Wedging with Timers: In Livewire, thepolling module are run serially by a single thread ofcontrol. This introduces the risk that a bug in one policymodule could cause the entire IDS to hang. Wehave tried to address this problem in two ways. First,all of our policy modules are written defensively, attemptingto avoid operations that could hang indefinitely,and using timers to break out of these operationswhen necessary. Second, each policy module isonly given a set amount of time to complete its task,and will be interrupted if it exceeds that limit, so thatthe next module can run.9 Related WorkClassical operating system security issues such as confinementand protection have been studied extensivelyin traditional VMMs. In previous years thorough studiesof these problems have been presented for VM/370[39, 14, 13, 12] and the Vax Security Kernel [21]. Themost recent implementation study of a security kernel canbe found in work on the Denali isolation kernel[53]. A recentapplication of VMMs for pure isolation can be foundin the NSA’s nettop [29] architecture.VMMs have also become a popular platform for buildinghoney pots [41]. Often a network of virtual machineson a single platform will be built to form a honey net, providinga low-cost laboratory for studying the behavior ofattackers.The idea of collocating security services with the hostthat they are monitoring, as we study in this work, has alsoseen attention in the ReVirt [10] system, which facilitatessecure logging and replay by having the guest operatingsystem (the OS running inside the VM) instrumented towork in conjunction with the VMM.Chen et al. [6] proposed running code in a VM in orderto discover if it is malicious before proceeding withits normal execution. This idea is similar to the applicationof VMs to fault tolerance explored by Bressoud andSchneider in their Hypervisor [4] work.Goldberg’s work on architectural requirements forVMMs [15] and his survey of VMM research up to 1974[16] are the standard classic works on VMMs. More recentnoteworthy work on VMM architectural issues canbe found in Disco [5], and in work on virtualizing I/O [45]and resource management [51] in VMware.Also relevant to the topic of VM introspection is workon whole-machine simulation in SimOS [38], which alsolooked at the issues involved in instrumenting virtual hardwareand extrapolating guest operating system state fromhardware state.10 Future WorkThere are still many significant questions to be addressedabout how VMI-based intrusion detection systemscan best be implemented and used.Livewire has taken an extremely conservative approachto introspection by primarily engaging in passive checksthat incur no visible impact on system performance. Thisdecision allowed Livewire to be implemented with onlyminimal changes to the virtual machine monitor. However,the cost of this was that monitoring frequent asynchronousevents, e.g. all system calls, may be quite performanceintensive. Our current architecture could supportfrequent asynchronous checks, such as monitoringand processing system call, and supporting lightweightdata watchpoints with relative efficiency via. hard codingthe functionality to log these events directly into the monitor,then offloading the processing of these logs to thepolicy engine. However, this approach seems somewhatinflexible. We believe a more promising approach wouldinvolve support for providing a small, safe and extensiblemechanism for efficiently filtering architecture eventsin the VMM, in much the same fashion that current OSesprovides this functionality for filtering packets via BPF.In Livewire we made the choice to leverage the crashprogram in order to provide us with an OS interface library.This provided the functionality to experiment witha wide range of policies while minimizing implementation