During the Virtualization Security Podcast on 5/13, IBM’s David Abercrombie joined us to discuss IBM’s Virtualization Security Protection for VMware (VSP) which contains several exciting uses of the VMsafe API for VMware vSphere. These being:
- Network: Network Monitoring, Firewall, Access Control, and a Protocol Analysis Module
- Memory: Rootkit Detection
This lead me to start to think of how the existing vendors are pushing the Introspection APIs such as VMsafe to their current limits. So what is being done with the Introspection APIs? Many of these technologies are listed within the End to End Virtualization Security Whitepaper. Yet, there are some new use cases to consider.Since the podcast was about IBM’s VSP, we should start with their use of the introspection API. First, we should discuss how VMsafe actually works. There are fast path (ESX or ESXi driver) and slow path modules (virtual appliance pinned to a ESX or ESXi host) that interact with the hypervisor at various points in the stack. Each of the core APIs, vMemory/vCompute, vNetwork, and vStorage all have differing interaction points and as such governs what the VMsafe Introspection API can do. There are also two other APIs that can help with virtualization security, MultiPath Plugin API and TXT/TPM integration for hardware root of trust.
- vNetwork VMsafe API interacts with the network just before the vNIC for incoming packets and just after the vNIC for outgoing packets. This interaction requires a VMsafe driver.
- vStorage APIs interact with the storage devices outside of the hypervisor scope using what was previously called the Virtual Disk Development Kit (vDDK). This allows for VMDK introspection, offline scanning, backup, etc. but does not require a driver to be present.
- vMemory VMsafe API interacts with the memory of the VM in two ways, one method allows you to see trigger when a specific address is modified and the other allows you to trigger when a page of memory is modified. This interaction requires a VMsafe driver.
- vCompute VMsafe API is the same as the vMemory API.
- TXT/TPM is technology that lives within the CPUs and provides a trusted platform. Currently there exists no API for this functionality outside of proof of concepts but one should exist as it will become increasingly important for cloud based virtual machine validation.
- MultiPath Plugin API interacts on outbound and inbound storage requests allowing you to implement full multipathing as the storage adapter level. This interaction sits just before the storage adapter in use and requires a driver to implement.
The driver required by many of the APIs allows for a fast decision on what to do with the data received, in the case of the vNetwork VMsafe API, firewall rules can be implemented completely within the fast path while other aspects such as deep packet inspection need to have the data received transferred to a specialized virtual appliance running on the host through an out of band mechanism. This is the slow path of the process. This does imply that the tool to secure a virtualization host runs on the host it is protecting, which is not ideal. This is why most of these virtual appliances are managed by another system that lives elsewhere. So at least part of the security tools are remote from the host being protected.
IBM’s VSP uses two of these technologies, the first is the vNetwork VMsafe API for their protocol access module, network access control, IDS/IPS, and firewall. The vCompute/vMemory VMsafe API is used to implement their rootkit detection by trapping access to critical tables within a VM.
Other tools make use of other components of the VMsafe APIs.
- Altor Networks makes use of the vNetwork VMsafe API to implement their firewall, IDS, and integration with Juniper IDS/IPS systems and switches. Furthermore, they make use of the vStorage APIs to implement policy based firewall rules by looking into the virtual disks of VMs to be protected for key applications such as Apache, IIS, Exchange, etc. Once these applications are found a predefined policy can be applied. In this way new VMs can be automatically protected.
- Reflex Systems makes use of the vNetwork VMsafe API to implement their firewall, VQL, and integration with Tipping Points IDS/IPS.
- TrendMicro makes use of the vNetwork VMsafe API to implement their firewall, IDS, IPS, and network access control for the Deep Security package. Their A/V solution makes use of the vStorage API to perform offline scanning of virtual disks.
What does not happen yet, is full memory scans for A/V purposes using an introspection API. The reason is that this is that the performance requirements of such an appliance is quite large. As the number of cores increase within CPUs and introspection APIs improve, this may become a real possibility. I believe the use of the introspection APIs will use more APIs in combination to achieve their ends. Each API has their use such as the following:
- vStorage API
- Inspect the VMDKs for known applications and unknown ones (Altor Networks)
- Inspect the VMDK for rootkits (IBM VSP)
- Inspect the VMDK for viruses, and malware (Offline through Trend, McAfee)
- Offline Patching
- vCompute/vMemory API
- Inspect running VMs for in use ports for the known applications and determine what ports are in use for unknown applications
- Inspect running VM for known rootkits signatures (IBM VSP)
- Inspect running VM for known virus and malware signatures
- Inspect vCPU Instructions for oddities or know attacks (not possible yet)
- vNetwork API
- Implement zone firewall (Altor Networks, IBM VSP, Reflex Systems, Trend Micro, CheckPoint, etc.)
- Implement Edge Firewall with NAT and Port Redirection (not possible yet)
- Implement Network Access Controls (Altor Networks, IBM VSP, Reflex Systems, Trend Micro, etc.)
- Integrate with switch providers (some of this coming soon)
- Implement IDS (Altor Networks via Juniper, IBM VSP, Reflex Systems via Tipping Point, Trend Micro)
- Implement IPS (IBM VSP, Reflex Systems via Tipping Point, Trend Micro)
- Implement Protocol Analysis/Deep Packet Inspection (Altor Networks, IBM VSP, Reflex Systems, Trend Micro)
- Network Discovery (uses Cisco Discovery Protocol)
- This list is pretty endless, whatever you can do within a physical network appliance.
- TPM/TXT Integration
- Verify Hypervisor boot volume has not changed
- Verify Hypervisor has not changed (not possible yet)
- Verify Hypervisor Management tools have not changed (not easy via Tripwire, but not via TXT/TPM)
- Verify VMX and Boot volume of a VMsafe VM has not changed (Tripwire, but not TXT/TPM)
- Verify runtime integrity of boot volumes (not possible yet)
- Data Integrity via Hardware signing (not possible yet)
- Data Confidentiality via Hardware encryption (not possible yet)
- MultiPath Plugin API
- Forensic Discovery and Acquisition (not possible yet)
- Encryption of data to and from storage devices (not possible yet)
What is interesting is that some vendors have chosen not to implement their products using the introspection APIs and as such perhaps limiting themselves to just vNetwork security. These tools do not learn from the network, but instead query vCenter for the requirements. vShield Zones is one such tool as is the current available implementations of tools from Catbird security. This actually allows their products to reach a broader audience as discussed in the post Growth of Citrix and Hyper-V EcoSystems.
As you can see there are many possible introspection capabilities and some of them are actually being used today. But there are more that are not. Virtualization Security is not just about the virtual network but all the other aspects of the virtual environment that need to be protected. In the end it is really about protecting the data and these tools and technologies can help do this with out the need for pesky agents. Review the End to End Virtualization Security Whitepaper for more information on each of the listed vendors and how they all fit into the virtualization security stack.