Bromium Protected App: Bromium is finding additional use cases for their micro-VM technology

Previously, Bromium’s goal was to keep an entire laptop protected. Their new product is now targeting other forms of isolation.

Earlier this year, we heard about a new product from Bromium, called Bromium Protected App. We’ve been following Bromium from the beginning, so naturally we were compelled to delve deeper.

With staggering data breaches from Marriott / Starwood and Quora revealed over the last week, and with Bromium developing a new genre of security solution, we felt it was one our readers should know about.

What is Bromium?

Bromium is a company that specializes in the microvisor/hypervisor space, with a focus on security—basically things that often involve putting a hypervisor on a laptop to offer a security layer beneath your OS (e.g., Windows 10) or to keep things separate. A lot of their technology and staff are from Citrix’s Research and Development site in Cambridge, U.K.; particularly from the Xen/XenServer and XenClient groups.

Bromium Protected App was announced at the end of July 2018; I should stress that this product is not GA, but I believe a private alpha may be imminent. Given the pedigree of their stable, Bromium is always a vendor to watch in this space, and Adrian Taylor, their dynamic CTO and PM for the new product, agreed to talk to me. Prior to talking to Adrian, I had a good look at the public information, as well.

Nothing is 100% secure

Bromium Protected App works on the principle that you can never be overconfident with security and that any solution will eventually be compromised by some yet unknown technology or vulnerability.

Many security products focus on keeping the bad guys out, whereas this product assumes everything is breached: e.g., the network, infrastructure, and endpoints are already compromised and hostile.

We’ve seen an increasing number of security products appear that rely on trusted environments separated from the untrusted. The concept is simply two worlds: one is trusted, where you only put stuff you really trust, test, and is critical to keep safe; and the untrusted world is where all the rest goes.

So where does Bromium Protected App fit in?

First, note that this is different than existing Bromium products we’ve talked about. In Bromium Secure Platform, micro virtualization is used to keep processes separate, so that potential malware only has a limited impact and is isolated to the micro VM. The overall goal is that barring any malware infestation, the user experience would be the same as it would be with a normal PC, and the entire PC is protected.

With Protected App, however, Bromium is targeting use cases where you assume that the host may already be compromised (or might be compromised in the future) as well as where you want separation between trusted and untrusted apps (which we’ll talk about later).

How it works at a high level

An end user is sent the app by the company that owns the data and network they will access. It is installed using the Microsoft .msi standard explorer; this results in Bromium Protected App inserting a plug-in into UEFI (Unified Extensible Firmware Interface, a specification that replaces BIOS), which has the effect that after a reboot, the protected app appears in the user’s Windows start menu. Rather than installing and using an RDP/VDI client like Citrix Receiver, etc., the user opens the protected app, which is running locally. Keystrokes, the pixels the user sees in the protected app are all “invisible” to a hacker.

Today, Bromium is using the Protected App environment to isolate RDP/ICA clients. Future releases will address web apps and potentially rich client applications.

The result is explained in this slide from Bromium:

Bromium Protect App

The result of the install is that after booting, the end user’s own machine is running a “hypervisor;” one VM has their regular OS and all their other apps, but there is a second VM in which the protected app is running.

The Start menu item in the regular OS VM is actually a client to the hidden VM running the protected app. This means that the protected VM uses segregated memory and resources. Because of the way the Start menu client is inserted (more on that later), the hypervisor layers mean that the screen pixels and keystrokes in the client are also reserved from access by the OS or any virus/malicious agents or applications also in the regular OS. The VM the protected app runs in is disposable and non-persistent.

Bromium has actually done a very good job explaining and marketing this product and there are a good number of blogs that go beyond marketing fluff and have substantial product management/engineering input (the type of content our readers love—actual use cases and customer case studies, etc.). In particular, there is a really good webinar explaining the threat model (including rogue employees); alternative approaches; weaknesses in traditional RDP/VPN clients; and an overview and demo of Protected App. I’d highly recommend the webinar to everyone interested in security, and while there, read the detailed answers to the FAQs.

Basically, Bromium Protected App offers a way to access secure trusted networks from less secure ones, minimizing the risks. Having seen the overview, I had a fair few questions, so I spoke to Adrian to find out more and ask him a number of questions.

Who would this be useful for?

Bromium’s own marketing covers case studies of customers in the federal/legal/financial services sectors where organizations have employees using numerous separate PCs/laptops to ensure client data is secured to their respective industry’s regulatory standards. They also mention those commodity homogenous apps you often see in healthcare or retail for patient records and call centers—apps where you aren’t expected to transfer data to other applications, rather work inside the apps and usually a single specific app.

The webinar also covered the scenario of a large organization using a large number of contractors on BYO devices reviewing material or needing access to information to do their jobs. My first thoughts on this were skeptical, because as a contractor, the idea of being asked by a client to install a hypervisor under my OS fills me with horror and all sorts of contractual liability issues. Discussing this with Jack, he agreed and pointed out the parallels which have meant that in practice, the enterprise mobility management market has faced challenges in some BYOD scenarios, where oftentimes users or IT decide to avoid BYOD and just have separate phones for work and personal purposes.

Bromium’s existing solution and how this differs

Adrian and I talked about Bromium’s existing product Secure Platform, which evolved out of vSentry, which Gabe reviewed enthusiastically last year. Secure Platform is designed for secure corporate or federal networks where it is assumed that things entering the network from outside may be compromised and shouldn’t be trusted, and so applications are spun up within small VMs on the client endpoint, isolating the potential bad stuff. For example, when a Word file arrives by email, Word is opened within a VM. (This is the same paradigm that I saw when I reviewed Garrison’s hardware-based Secure Remote Browsing solution a while back—a trusted device accessing untrusted content.)

Adrian explained that Bromium Protected App has been developed owing to a shift in mindset from their customers, who often now adopt zero-trust concepts and work from the assumption that their networks have been compromised. This approach is also ideal when an employee needs to run applications on untrusted insecure Wi-Fi (coffee shop/conference center/business hotels scenarios).

One significant difference between Bromium’s products and many others that we’ve talked about before is that the applications are run within VM’s on the client and, as such, are an offline solution. (Though, as mentioned, for now, the application in Protected App happens to be an RDP/ICA client.)

Who is Bromium Protect App aimed at and what problems could it solve?

It became apparent during my conversation with Adrian that this is a product still in development with a very astute customer engagement program in place. Adrian talked me through a few scenarios of what customers are doing at the moment.

  • One potential client is a federal/government customer with numerous secure networks where employees have up to 10 PCs/laptops that each provide a dedicated secure end client to access each separate secure network. Protected App would allow the employee to have one endpoint/laptop with multiple secure apps to access each network. (At this point I was also wondering how big is everyone’s desks and laptop bags?)
  • Many of Bromium’s corporate/federal customers run dedicated server admin consoles that an employee (sys admin) has to physically use to access; Protected App could offer a way for those guys to access the admin functionality of a secured network.
  • There is also interest from financial institutions and enterprises handling payment details where PCI DSS (Payment Card Industry Data Security Standard) type regulation (credit card / bank details) mean that data is often handled on dedicated networks to avoid the need for the entire organization to comply to the same standards and costly compliance auditing.
Bromium Protected App multi-screen view
Visual demo of an actual attack.

Adrian was a wealth of information on the scenarios where companies face the challenges of needing to allow third-party access to their networks, but also needing to protect other data on secured networks; and also the risks and costs associated with failing to do due diligence. In 2013, 40 million customer credit card and bank details were hacked from U.S. retailer Target, a breach that many estimate cost Target an eye-watering $300 million to date. It is widely mooted that the network was breached using the login credentials of a tiny HVAC (a Scooby-Doo-like scenario where it was the aircon repair guy!) contractor. This is a scenario where it’s obvious how Bromium Protected App would have helped.

We also discussed how some employers (particularly airlines) face the fascinating yet bizarre challenge that union agreements protect the rights of ex-employees to access the corporate network.   

The BYOD use case

Adrian was refreshingly honest and admitted that he too was unsure of the true practicality of this in a scenario where a contractor may have multiple clients asking them to install and use multiple similar bits of software. We did, however, both agree that the remote call-center operator use case certainly does make a lot of sense, where the application in question is a single application used heavily day in and day out and the corporation doesn’t really care about the security or content on the rest of the worker’s day-to-day machine.

Apparently, Bromium has seen some interest for this use case, but I did get the feeling that, for now though, they are focused on optimizing and hardening the solution for that secure server admin use cases. We also discussed how this could be very useful for those single application terminal use cases such as Epic/Cerner deployments in healthcare where hospitals are filled with terminals that access patient records in which the general public can literally walk up to and add physical keyloggers, etc.

We then moved on to delve into some of the tech and questions I had around implementation, performance, and the hypervisor model.

Bromium Protected App performance

Bromium’s existing solution has been optimized to support 30 to 40 VMs on a fairly mid-range laptop. The Protected App is being envisaged in the first instance as a remote client where the user is likely to be only running a few (and often only one) VMs, meaning that performance looks unlikely to be a significant issue.

UEFI Security

One question was whether at install time other security agents would challenge the insertion of something so invasive into UEFI. Apparently, this hasn’t proved to be a significant issue in early trials, although there are some nuances around suspending BitLocker, but these are handled automatically by Bromium’s installer.

How does Bromium comply with industry regulations?

Given that many of their initial target customers are in the most highly regulated industries (that PCI DSS stuff again), I asked Adrian how a customer would go about complying today; Adrian said he simply couldn’t give an opinion on how, if, or when that would change. At the moment, the regulations cover physical network segregation, which is the same issue faced by PACS certification for remote graphics (all the legislation is related to hardware—monitors, etc.). In hypervisor land, lagging government regulation on Linux kernels demanded the installation of Tripwire, which caused grief for years. I took Adrian’s reserved answer (and this is a personal opinion) as a very good product manager working on the issue in the background but with enough integrity not to make false promises or get into revenue recognition territory; integrity is always a good sign in a security vendor.

Protect App limitations

As Garrison found with remote browsing, the lack of cut/paste and other functionality can be too much restriction for many use cases and Adrian said that they are open to adding more functionality and administrator configuration around it, dependent on the feedback from their initial customer alphas.


On that configurability—there has clearly been a lot of thought around this and the product contains a high degree of granularity in control for the level of security, particularly in a fall-back scenario dependent on the root of trust. For example, if certain hardware security is unavailable or certain security settings reduce security; the administrator settings can decide if access should be allowed regardless, limited access to only certain resources, or complete denial.  

Smart folk

The conversation ended with some technical discussions on future possibilities for auditing traceability; nested virtualization; Ring -1, -2, and -3; and Adrian suggesting a further conversation with Ian Pratt, the Xen godfather (now Bromium) and brain behind Protected App would be enlightening. I highly recommend you track either Adrian or Ian down over the next few months if this tech is of any sort of interest. Technologies have moved on and the sheer technical challenges faced in the (sometime tragic) history of XenClient have been removed by advances in hardware and software. If anyone is likely to break this sector in 2019, these guys with their experience and thorough product management are probably the ones to do it.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.