Why Task Isolation Changes Everything…

Why Task Isolation Changes Everything…:
We’ve had a lot of questions about our use of hardware isolation for tasks – and why it this represents such a major step forward in securing  computer systems.  This blog contrasts the different approaches to protection, to shed more light on this topic.
There are three ways to protect an endpoint under attack:

1. Detect and then block the attack within the OS, by foiling its attempts to access system resources, the moment the attack is detected.  This is the approach taken by the current state-of-the art of endpoint security software.   It presumes successful detection, which is problematic in the context of today’s advanced polymorphic malware – for which detection rates are extremely low.   It also necessitates post-attack remediation: even if the attack is blocked, the system must be cleaned of malware – perhaps even to the extent of re-imaging the system.
2. Sandbox the attack using an application-specific or more general software sandbox.   Here is a full description of the approach and its limitations.  In summary, sandboxes attempt to limit the ability of an untrusted user space process to enter the kernel using a software replacement for all system calls and other access methods for the kernel.  Sandboxes have a huge interface to cover, introduce millions of lines of new vulnerable code to the system, and tend to be application specific or interfere with the user experience.   They are also typically poorly instrumented – focused on blocking, and not delivering insight to security teams about new tasks.
   Both (1) and (2) above are vulnerable to human frailties, with catastrophic consequences:  When the detector fails to detect, or when malware finds a way to escape from the sandbox and enters the kernel, perhaps through a zero day, the system will be completely compromised.
3. The third, and only viable approach for defeating advanced malware, is micro-virtualization.  The Microvisor isolates an entire task within a micro-VM, using Intel VT to hardware isolate the execution of the task, protecting the OS, the network infrastructure, and all valuable data from malware.  This of course raises the question “What is a task in the Bromium architecture, and why is it a superior isolation construct?”

vSentry defines a task to be the most granular unit of computation, initiated on behalf of a user, that can completely and successfully execute with the least possible resource access.  Resources here mean files, network services, sharing mechanisms, interaction with the user, or any devices.  In vSentry today, user tasks are either:

• Document centric:  The task involves all processing related to the document, both user space and kernel.   In general for documents, communication with other systems is not permitted unless specific policies override this (for example a spreadsheet might need data from an Intranet based Sharepoint site, but a PDF doc doesn’t need access to an external site).
• Web centric: The TLD of the URL uniquely identifies the task.   If a micro-VM for the TLD already exists, then the new task will be executed within the existing micro-VM, otherwise a new micro-VM is created.  (There is an exception: DOMs with a Meta NOFRAMES tag are injected into a new micro-VM.)

A micro-VM isolates all computation for a single task – both kernel and user space.   All execution within a micro-VM is copy-on-write against the IT-provisioned system image – both the in-memory image of Windows and the “golden file system” containing windows and applications provisioned for the user.
Since our goal is to protect first, and also to deliver insights into live attacks, isolating user and kernel space activity is crucial.   It protects the system from any changes made by malware – whether or not it is detected, preventing access to valuable data or networks.  And it permits us to see all kernel activity for each task. For example

• A DNS query by a PDF document seeking to resolve the address of a remote botnet C&C, or even the attempted transmission of a datagram that is directly addressed to some Internet site.
• Every process spawned by the task
• Every file opened, saved or read by the task and any attempt to access raw storage devices
• Every attempt to access the clipboard
• Every system call and process creation
• Every registry access

Moreover, since the micro-VM executes CoW, if it modifies kernel memory or overwrites a file in the golden image, these changes are specifically and separately saved within the micro-VM.  In short, every change made to any system state from the moment a task starts until it ends, is recorded, with a timeline of changes.
The bottom line: Unless it has a microvisor and  two key ingredients, any proposed protection architecture is just more hot air:

• Hardware isolation: massively reduces the code base required for isolation.  To break the isolation container, you need to break Intel VT.
• Task isolation in micro-VMs: Protects the kernel and user space execution resulting from any initiated user activity, guaranteeing that even if malware gets into the kernel, it will be defeated.