Chrome Perfected (2/2): Protect Users and Sites on the Web [feedly]

----
Chrome Perfected (2/2): Protect Users and Sites on the Web
// A Collection of Bromides on Infrastructure

In a previous post I described how Bromium makes Chrome fast and massively secure.   vSentry will always protect the endpoint from an attack via the browser – and the attack will be automatically remediated.

But the browser itself manages valuable personal and enterprise data that could be stolen if a hardware-isolated browser task is compromised.   In this post I show how vSentry mitigates these risks to protect enterprises and their users as they browse the web, effectively extending protection from the client to high value applications on the Intranet and the web, and enhancing privacy.

There are two ways micro-virtualization can help:

1. Stop malware that seeks to use a compromised browser to penetrate deeper into the enterprise from accessing the Intranet and SaaS sites of value to the enterprise or the user (such as their bank).
2. Stop an attack that compromises the browser (including man-in-the-browser (MIB) and cross-site scripting (XSS)) from stealing cookies, hijacking sessions for sites to which the user is currently logged on, and persisting unwanted cookies.

We rely on the "default deny" architecture of micro-virtualization: Granular, task-centric hardware-isolated micro-VMs and their virtual file-systems and virtual networks.

• A micro-VM renders a site in an anonymized Windows environment with a random username, a minimal Registry, an empty Windows SAM and no hash to pass, ensuring that an attacker in a micro-VM cannot steal the user's identity or enterprise credentials.
• The virtual file system of a micro-VM allows us to precisely control what cookies and DOM storage are accessible to any site.
• The virtual network of a micro-VM can only access IP services and networks that are permitted given the value of the isolated site {untrusted web, high-value SaaS, Intranet}.

To address the first problem, namely to protect enterprise networks and SaaS sites (and the user's high value sites), vSentry applies a simple value-centric network policy: A micro-VM can never access a network/site of higher value than itself (cnn.com can never access my bank site, salesforce.com, or the Bromium Intranet).  Thus, if the user clicks on a malicious link that causes malware to execute in a browser micro-VM, there is no way for the malware to reach the corporate DNS, sites on the Intranet, any enterprise SaaS sites or (say) the user's bank.  The virtual network in the micro-VM is completely unable to reach them.

To solve the second problem, namely an attack that attempts to hijack sessions or otherwise leverage a compromised browser in a micro-VM we need a more subtle approach.  Ideally we'd always create a new micro-VM for each site, and only allow it to access its own cookies – but the web doesn't work like that:

• Sites may need to share information via the browser.  For example, LinkedIn might allow me to log in using Facebook, and sites offering single sign-on need to pass credentials from the authenticating domain to be available to a second site.  If we prevent this, we risk "breaking the web".
• Sites may use 3^rd party cookies to deliver legitimate content tailored to the user.  For example, the page "http://www.NBC.com" contains code from as many as 30 other domains including advertisers, content providers and social networks.  To correctly render NBC.com the browser must let those domains access their cookies stored on the endpoint.  Not doing so also risks "breaking the web".

We want to protect the user without "breaking" the web.  To achieve this, vSentry automatically manages two kinds of trust relationships:

• Between sites: By default vSentry implements a restricted sharing policy – only allowing sites that explicitly trust each other to be isolated together and share browser state.   For example when I log into salesforce.com, my login is also valid for a small clique of sites that salesforce explicitly trusts, including heroku.com and force.com.  (You can also use policies to force each site into its own micro-VM, or to behave as Chrome does – allowing many sites to share a single micro-VM.)
• Between the user and each site: vSentry controls what cookies are available (in the context of the micro-VM for) for each site the user visits.
  • A micro-VM rendering a specific site has no access to session cookies for other sites. This ensures that if the browser is compromised, the attacker cannot hijack logins to other sites.
  •  You can also prevent a site from accessing persistent cookies for other sites – only the cookies for the specific site being rendered are accessible in the micro-VM.  Content on the page that is provided by a 3^rd party will be unable to access its cookies – effectively ensuring that the 3^rd party site believes that it has never seen the user before.
  • Finally, you can decide whether or not persistent cookies dropped by a site are saved when the micro-VM that renders the site is destroyed.   If they are not saved, when the user next visits that site or a page with content from that site, there will be no record of the user's previous interaction with the site.

Two capabilities –micro-VM virtual networking, and controlled access to cookies and shared browser state – allow us to extend protection beyond the endpoint.   Even if an isolated browser task is compromised vSentry protects networks and applications of value to users and the enterprise.

 

----

Shared via my feedly reader

Sent from my iPad