However, with the move toward hybrid cloud architecture, many are questioning whether the hypervisor is still the proper place to focus security controls. Can the hypervisor fulfill future needs, or is it time to consider additional options, such as a host-based approach?
While the hypervisor is responsible for allocating resources to each virtual machine (VM), it has limited visibility into the VM itself. This is where introspection comes in, as it is a set of APIs and drivers that open up each VM for inspection from the hypervisor. With introspection, the hypervisor gains the ability to analyze the file system, programs executing in memory and even network packets entering and leaving the system.
To see how powerful this functionality can be, consider what happens when a kernel-level rootkit is installed on a system.
A kernel-level rootkit effectively turns the operating system itself into malware. This makes the rootkit difficult to detect, let alone remove. With introspection, the hypervisor maintains visibility of the rootkit’s activity. This provides mitigation techniques to an attack vector that is arguably one of the most difficult to resolve.
Introspection also brings with it some security concerns. Good coding practices dictate that we should minimize the amount of code being used and interactions with untrusted input sources. By introducing introspection into the hypervisor, we’ve increased both the size of the code, as well as the interaction with untrusted sources (the VMs themselves).
Another problem is that introspection is tied to the local hypervisor. Move the VM to a different hypervisor, and all security benefits are lost. If you leverage public infrastructure-as-a-service (IaaS), or want to be able to move VMs among private and public IaaS clouds as cost and bandwidth needs require, introspection security is lost as soon as the VM is moved.
Arguably one of the biggest concerns is that introspection can break segregation of duties. Segregation of duties is the implementation of checks and balances that are required by many compliance specifications.
For example, there may be a group of administrators responsible for adding and deleting user accounts. There may also be a separate auditing group responsible for reviewing the first group’s activity. So, while the administrators have high-level system access, the auditing function helps to ensure suspicious activity is detected.
Now, apply introspection to a public IaaS cloud, and you can see why things break down. Unless your provider grants you access to their logging functions, there’s no way to audit introspection activity within your VM. If one of the provider’s employees goes rogue, or if an attacker compromises its infrastructure, introspection access to your data can go undetected.
In contrast, host-based security is deployed within the VM itself, and can move with the VM as it migrates among IaaS solutions. Since there are no hooks into the hypervisor, you can choose which virtualization architecture best fits your needs.
Within a public cloud, host-based security remains fully controlled by the tenant. This means a host-based solution is also provider-agnostic, allowing you to focus on other requirements when selecting your provider. Further, segregation of duties is a lesser issue, as the provider should no longer have backdoor access to your data.
Introspection was introduced to resolve many of the performance issues encountered when first trying to apply host-based security to a virtualized environment.
If I had a dozen virtualized servers running on a single hardware platform, and they all decided it was time for a full disk scan to simultaneously check for viruses, performance on the platform would be brought to its knees. This has serious financial implications because it means I’m buying more hardware to support my private cloud, or receiving a higher monthly bill from my public cloud provider.
Luckily, we are starting to see new host-based solutions that are specifically designed for cloud deployments.
For example, management, computational work and reporting may be offloaded from the protected system to resources maintained by the security provider. This reduces the CPU load and memory footprint on the system being protected.
To improve security, the agent may call home to the security provider for management tasks, rather than opening up a local listening port. This helps reduce the attack surface of the agent. It also lets the security provider validate the agent’s integrity to ensure the agent has not been compromised.
So…which to choose?
It should be clear that each solution has its strengths and weaknesses. A layered approach may provide the best of both worlds.
But I’d suggest to implement introspection when:
- You need to secure a private cloud,
- The focus is on infrastructure security, not data security,
- You do not plan to change hypervisor vendors for at least three to five years, and
- There is no regulation requiring segregation of duties.
Implement host-based when:
- You need to support both public and private cloud,
- You want a cloud agnostic single point of management,
- Segregation of duties is a requirement,
- The solution is engineered to minimize impact on cloud performance.