Micro-virtualization is a powerful construct that allows us to defend an endpoint “by design” – by hardware-isolating individual untrustworthy OS tasks using Intel® VT. (If you are unfamiliar with our technology, here is a whitepaper.) The approach is intuitively appealing, but beyond the cool factor, it’s important to be able to explain it in terms useful to a security architect whose goal is to reason about security properties of the system in a more formal way.
As a first step, it is important to place micro-virtualization in the context of existing, well understood isolation technologies.
- Classical OS design implements isolation through separation of untrustworthy user processes from the system kernel, and recent research has focused on improving OS design,
- Sandboxes attempt to retrofit software-based isolation between user space application processes and existing vulnerable operating system kernels, using software.
- Multiple independent operating system instances in VMs can be mutually isolated by a hypervisor, and
- Micro-virtualization isolates individual untrustworthy tasks within a single OS.
Are all Isolation technologies equal? In answer to this question, Neil McDonald of Gartner recently published an analysis and reference architecture that allows security teams to understand and trade off different isolation technologies. This is an important first step in providing a framework for understanding the protection afforded by isolation technologies in general. For example, though sandboxing is well established (it’s just a free feature of many applications), it is also assuredly inadequate against a determined attacker. A hypervisor offers robust inter-VM (inter-OS) isolation on a single device, but can’t protect the VM itself (eg: a virtual desktop) from attack. Moreover interacting with multiple VMs (independent OS instances) is impractical for end-users since it negatively impacts the user experience.
Neil’s analysis enables an architect to understand the security capabilities of each kind of isolation technology and the granularity at which it is applied (for example: process, application, VM, or user task / micro-VM).
Our goal at Bromium is to embrace the ease of use of today’s OSes and applications (and their massive installed base) whilst adding the robustness of hardware isolation to user initiated tasks (delivering granular protection and an unchanged UX).
Crucially, “granular protection” is different from “granular isolation”: Imagine we isolated execution down to the granularity of each individual application thread. If one thread were compromised and elevated its privileges, would the fine-grained isolation help to protect the application, or the system as a whole? It would not: The thread would have access to all resources available to the application. Moreover, it would have access to any files in the file-system and the full set of services offered by the kernel, including privileged enterprise networks and storage. It could modify the SAM, and all sorts of program and system configuration data.
The overall security of the system therefore depends on both the granularity of execution isolation (in micro-virtualization – a task) and the granularity of (the task’s) access to security-critical system resources and data. The architectural construct that we use to reason about security of the latter is the Principle of Least Privilege.
It is a fundamental principle of our design that the granular, hardware-enforced execution isolation afforded by the Microvisor is independent from, and orthogonal to granular application of the Principle of Least Privilege. Without a rigorous, independent design and implementation of each, the security properties of the resulting system would be impossible to understand. Since we have covered micro-virtualization in some detail before, my next post will focus on the application of least-privilege in the Bromium architecture.
- Tags: Isolation