Bromium Brings Hypervisor Security To Applications

When thinking about virtualization, people often jump to the consequences and benefits--better hardware utilization, workload scalability, and deployment flexibility--and gloss over the real reason the technology became so pervasive in the first place: It thoroughly and completely isolates multiple operating systems running on the same physical box.

Old-timers will recall the early days of client-server computing, when data centers quickly became clogged with underutilized, single-application servers. This happened not because IT was fond of buying new iron, but to provide the OS isolation and customization individual applications required. Then along came server virtualization--it suddenly became easy to give each application its own sandbox, and we saw profound ramifications.

But remember, it was really security that first made hypervisors so compelling. Bromium, a little startup with some serious virtualization street cred, is out to do for applications what traditional hypervisors did for operating systems.

[ Read about the role virtualization can play in your disaster recovery strategy. See Virtualization Makes DR Automation Possible. ]

Inner Workings of an Application Hypervisor

Bromium calls this extension of hypervisor isolation, control, and security into the application realm microvirtualization, and the task- or process-level controller a Microvisor. While early Type 2 hypervisors ran on top of an existing OS, virtualization didn't come into its own until the development of Type 1, bare-metal hypervisors like VMware ESX that run independently of any guest OS and use various virtualization features built into newer x86 processors. Hardware assistance allows the hypervisor to virtualize all server resources: CPU, memory, I/O, networks, even peripheral interfaces, providing a wall of trust between running guest OSs and the hypervisor kernel. Any attempt by the guest OS to access privileged resources triggers a hardware trap, turning execution control over to the hypervisor. Bromium uses this same hardware-assisted magic to isolate applications, yielding intra-OS software isolation.

If this concept seems simple and obvious, the technology and implementation are anything but. Unlike traditional hypervisors, the Microvisor doesn't take over the entire machine, but rather is installed like any other application--one that, much like other security software, lurks in the background intercepting other applications at run time, placing them into a new sandboxed micro-VM. Any time an application tries to execute a restricted function or access a protected resource, such as write or modify a file or access the network or a peripheral port, the hardware-assisted Microvisor takes over, acting as a policy-enforcing middleman.

Furthermore, each application sandbox has only a restricted view of the OS and filesystem and does not have unfettered visibility to any system file or directory. This means that malware trying to modify a DLL or leave behind a hidden trojan either can't do it or writes to a local sandboxed file container that, depending on the security policies established for a given application, can be destroyed once the application quits. It resembles a secure browser cache for applications that's emptied every time you exit.

But what about files you want to keep, like that that PowerPoint presentation for your boss? Persistent files are tagged with the same trust level--i.e., the set of security policies for a given application category--as the originating application. Any access to untrusted files must be made from within another micro-VM, so you can't modify them without creating a new virtualized sandbox.

To further safeguard attacks on the hypervisor system from within a micro-VM, the Microvisor doesn't even trust itself. Any system calls use of the CPU's hardware virtualization features and must comply with security policies set for the Microvisor. Bromium limits the attack surface by implementing this so-called hypercall API in less than 10K lines of security-vetted code.

What's It Good For?

Aside from the obvious benefit of offering much more robust protection against zero-day attacks and persistent threats, Bromium's technology can also be used for DLP. For example, key loggers or screen scrapers can't jailbreak the micro-VM to send data over the network since I/O calls are all mediated. Similarly, the Microvisor doesn't allow applications unrestricted access to the filesystem, so an untrusted application can't just go roaming through the system looking for interesting tidbits. Even when data access and transport is allowed by policy, the policy rules are sufficiently flexible that, according to an example from the company's documentation, "one could permit a user to attach a sensitive document to an untrusted web mail, only if the document is encrypted when presented to the micro-VM, and appropriate logging or alerting of the action occurs."

Simon Crosby, Bromium CTO and one of the original developers of the Xen hypervisor, sees Bromium's approach as a completely new form of client security, contrasting it not only with traditional endpoint A/V approaches, but Type 2 hypervisors and VDI. Even though the Microvisor runs within Windows, it can mediate access from any application to any system resource. Accordingly, it's more like an application-layer firewall with policies and controls that cover more than just network access.

Questions and Futures

Although Bromium has finally opened the kimono after a year of secrecy, there's still much we don't know, and one big limitation. Although its strategy is applicable to any OS, Bromium's initial Microvisor implementation is Windows-only for now--no Mac, Linux, iOS, or Android clients. And the product, entering beta, hasn't been publicly vetted. Although Bromium claims the user experience is completely transparent, without testing the integration with the Windows desktop (and various app starters) and running applications, it's impossible to verify.

Likewise, unknown is the performance hit on both the overall system and sandboxed apps. Crosby claims the Microvisor is very lean and that any degradation won't be noticeable, but leave it to some user with a bloated Windows system and some obscure application to find the worst-case scenario. Of greater concern to IT departments, which after all will be charged with deploying and administering this stuff, is the effort required to define, deploy, and enforce various micro-VM security policies. (Bromium is developing an SDK to allow application developers and software management platforms to automate micro-VM policy setup, so at least it recognizes the problem.)

What we do know is that Bromium is taking virtualization and application sandboxing to an entirely new level, at least for Windows systems. One could argue that such functionality belongs in the OS itself, as Apple has done with iOS and to a lesser extent, OS X, but the reality is that despite improvements in desktop OS security, neither Microsoft nor Apple has a bulletproof, trustworthy system, and Bromium promises to plug some gaping security holes. Here's hoping the implementation is as solid as the vision and that the Microvisor concept soon spreads to other platforms.

From thin provisioning to replication to federation, virtualization options let you reclaim idle disks, speed recovery, and avoid lock-in. Get the new, all-digital Storage Virtualization Guide issue of Network Computing. (Free registration required.)