Client SDN: Least-Privilege App Networking for Privacy and Security (2 of n) [feedly]

Client SDN: Least-Privilege App Networking for Privacy and Security (2 of n)
// A Collection of Bromides on Infrastructure

In my previous post I drew an analogy between the requirement for hardware-enforced multi-tenancy (for compute, storage and networking) in the cloud, and the need for granular, hardware enforced multi-tenancy on the client to enforce least-privilege, ensure privacy, and to guarantee end-to-end isolation  and security between the client-executed component of an application (eg: each client-rendered page of salesforce.com) and the SaaS back-end of Salesforce itself.   The Microvisor hardware-isolates each task (site, app, doc) in a micro-VM, and the Client SDN virtualizes and isolates all network services for each micro-VM.

In this post I want to dig more deeply into the functional components of the Client SDN,  with the goal of highlighting a fundamental difference between  micro-virtualization and any other isolation technology such as a sandbox (sometimes misleadingly called a "virtual container"):

The Client SDN isolates, virtualizes and controls all network services for each micro-VM.  By contrast, in a sandboxed application environment (eg: Chrome) there can be no Client SDN, because the network stack runs in the OS kernel – over which the application sandbox has limited or no control.

Why is this important?  Imagine I plug my PC into the physical LAN in the enterprise data center, and browse to facebook.com – first using a micro-virtualized PC, and second, using a PC with only a sandboxed browser.

• Micro-virtualized: The browser tab for Facebook will be instantly and invisibly hardware isolated in a micro-VM, and by the rules of least-privilege it will be granted access to only a single file – the cookie for facebook.com.  It has no access to any device hardware (NICs, disks, webcam, USB, detachable storage etc) or any other files.   What of its network stack?   Least privilege demands that (the browser tab in the micro-VM for) facebook.com

1. Never be allowed to find or query the enterprise DNS, or access any Intranet sites,
2. Never be allowed to resolve or access any high-value enterprise cloud sites, such as salesforce.com or aws.amazon.com
3. Never be able to resolve or access my (the user's) high value sites – such as my bank
4. Never be able to find or communicate with any other application or micro-VM on my PC, any devices on my LAN (including printers), or any other enterprise application or infrastructure service or component – for example the proxy, routers, switches or security widgets, networked file-shares etc.
5. The entire run-time of the micro-VM must be discarded the moment I browse to a different site or close the tab – discarding all network state.

These networking requirements of least privilege mean that the browser tab for facebook.com effectively needs to run "outside" the enterprise network – logically in the DMZ – even though it is in fact on my PC in the data center.  The Client SDN has the job of ensuring that this logical isolation is implemented in practice.   If a bad actor compromises the micro-VM, he cannot access the enterprise network or any high value SaaS sites.  All that is available is the untrusted Internet (and the only file that could be stolen is the cookie for facebook.com).

• Sandboxed: The DNS query from my PC for www.facebook.com is resolved by the corporate DNS, and the HTTP query runs over the corporate LAN, via the proxy, to the Internet.   All's well until a bad actor shows up, compromising the browser, and perhaps even escaping the sandbox.
  1. If malware compromises the browser, but is contained within the sandbox, it can still gain control over other browser-hosted applications – tabs logged on to salesforce.com, to my bank, or an Intranet application.  It can see keystrokes and steal credentials as I log into sites, and access any web service on the Intranet – including dropping malware in a Sharepoint site.  It can steal cookies for all sites, enabling the bad actor to impersonate me on any site. It has access to any browser-cached DNS entries – potentially for valuable sites. Finally, it could probably steal information from the clipboard, and deliver malicious content to other enterprise services such as (web accessible) printers.
  2. If malware escapes from the sandbox (via an OS or sandbox flaw) it can arbitrarily query the enterprise DNS, discover networked devices on the LAN, access printers and any other networked infrastructure services (eg: printers, shares) and any applications on the Intranet or the Internet.  It can use enterprise network resources to its heart's content because they are offered by the OS abstractions.

The Client SDN isolates and virtualizes all network services for each micro-VM.  The example above highlights its value for micro-VMs that isolate  untrusted Internet sites, such as Facebook.  For sites that I value, its role is to enforce privacy, isolation and security end-to-end from the client to the cloud.

In my next post, I'll show how the Client SDN isolates, secures and protects network services for high value tasks: Intranet sites,  enterprise SaaS sites, or user-valued SaaS applications.

You may have guessed that I'm laying the foundation for what Bromium will show at the RSA Conference.   If you'd like to meet Bromium at RSAC, please drop me a note.

----
Shared via my feedly reader

Sent from my iPhone