Context versus isolation: solving one of security’s trickiest problems

Securing endpoints has always required balancing context and isolation. Context is about knowing what is happening within an endpoint, while isolation is about the security mechanism being separated from the endpoint that it is protection.

Network security, such as firewalls or network intrusion prevention, are well isolated. While an endpoint may be compromised, the network devices are unaffected. The results that they produce, detecting unusual traffic to and/or from a particular endpoint, can be trusted. However, they are limited in the richness of the security they can provide. While knowing that and endpoint is exfiltrating data, originating SMTP traffic (email) when it should not be, or generating or being targeted by unusual traffic, is good information to have. It does not tell you what is happening with the endpoint, though. Was new, potentially malicious, software installed? Was a legitimate application compromised by a remote exploit of a vulnerability?

At the other end of the spectrum, security tools – such as antimalware – that run within a protected endpoint can take advantage of rich contextual information, but lack isolation. Consider a scenario where network security detects unusual traffic from an endpoint, suggesting that it has been compromised. If, indeed, it has been, the security tools running within that system cannot be trusted. Security tools running in a compromised endpoint may, by definition, also be compromised.

Isolation is important because the endpoint security tools that run within an operating system often rely on the same kernel features as malicious software. For example, a rootkit may manipulate results by shimming system call tables. Security software may ask the kernel to provide a list of files in a given directory, which happens to contain malicious objects. Since the part of the kernel responsible for answering the query are compromised, the kernel will return a list of files without including the malicious objects.

To solve this problem, one must look to the architecture of virtualization. Traditionally, the supervisor is the part of an operating system that mediates access to hardware. For example, if a user-mode application needs to read or write memory, it calls on kernel-mode functionality to facilitate the operation. When virtualized, the supervisor no longer has direct access to hardware. In the most common x86 virtualization scenarios, the supervisor communicates with virtual hardware, while the hypervisor, in-turn, mediates interaction with the underlying hardware.
The hypervisor, then, provides an ideal level in the stack for security. Focusing on memory, the hypervisor can “see” all read/writes from the virtualized operating systems that sit above it. Security operating at the hypervisor, then, has rich context, but is isolated from the virtualized operating systems it hosts.

While intuitive, there is a tremendous amount of complexity involved in applying security at the hypervisor level. Access to raw memory is one thing, being able to make sense of it (tease context out of it) is difficult. It difficult enough that, in the past, some people believed it to be all-but impossible.

Fortunately, Bitdefender has made security at the hypervisor level a reality. Called, “Hypervisor-based Memory Introspection”, the technology takes advantage of the architecture of virtualization to move security ahead of attackers. The technology secures both kernel and user space of virtualized endpoints, and includes an optional ability to inject Clean-up Tools into a live virtual instance. While the Introspection Engine behind the technology is proprietary, the APIs that facilitate inspection with the Xen hypervisor are open-source, so other vendors can take advantage of them.

To see how Bitdefender accomplished this, check-out the presentation below.