Very cool, indeed.  But what does that really mean?

Gartner’s criteria for selection is very clear, and it comes down to 3 specific requirements.  Let’s take a quick look at each one and see how Bromium stacks up.

1) Is it Innovative, enabling users to do things they couldn’t do before?

Absolutely. Simply stated, Bromium enables users to enjoy complete Internet freedom, regardless of where they are working.  Users can now visit any website, download any document, and open any email attachment without fear of being the victim of a cyber attack.

This unprecedented level of user freedom might cause a bit of discomfort to IT organizations.  After all, IT normally applies stringent security controls that tend to restrict or limit user freedom on untrusted networks like the Internet. But Bromium’s innovations eliminate the need for any restrictions, while also strengthening endpoint security.  How is that possible? It’s because vSentry automatically creates hardware-isolated containers for each and every task performed on untrusted networks, without any impact on user experience or performance.  As a result, vSentry delivers 100% protection against all known and unknown malware, APTs, and zero-day attacks – all without relying on outdated detection technologies.

2) Is it Impactful, enabling greater value to the performance of the business?

As noted above, the ability to effectively – and safely – leverage the power of the Internet is critical to the productivity, growth, and success of every business in today’s global economy.  In that context, Bromium’s impact on the business is significant, here’s why. The new generation of users entering the workforce has grown up with the Internet and represents an incredibly valuable corporate asset in today’s Internet-powered enterprise.  These users are the innovators of the new enterprise.  They understand very well how to leverage every possible application, tool and resource to save time, reduce costs, and deliver maximum value to the business. Bromium empowers these users with the freedom to improve business performance.

In addition, Bromium has a positive impact on IT staff in a couple ways.  First, there is less urgency to resolve critical endpoint security concerns – such as Windows vulnerabilities, Java exploits, PDF infections, email attachments, or malicious web content.  To be clear, these are all still important challenges that need to be addressed, but they will not impact the security of endpoints where vSentry is deployed.  In addition, IT no longer has to deal with desktop remediation simply because vSentry prevents these resources from being infected.  Eliminating the need for remediation – which Gartner estimates at about $650 per laptop – can save significant time and tens of thousands of dollars each year in IT operations costs.  This obviously has a significant impact on the performance of IT and the bottom-line of the business.

3) Is it Intriguing, has it caught our interest or curiosity over the last several months?

Obviously, we did catch the interest of Gartner, which is why we were selected as a Cool Vendor.  But why Bromium?  I don’t want to speak for Gartner, but I do know that they do a great job tracking requirements, issues, and pain points among their enterprise clients, while also tracking strategies, products, and innovations from the vendor community.  On the enterprise client side, I’m guessing Gartner has been hearing what we have been hearing – endpoint security is fundamentally broken and detection-based security technologies simply don’t work well.  Bromium’s approach to endpoint security is not evolutionary; it is truly revolutionary.  No other vendor is doing what we are doing and, to the best of our knowledge, no other endpoint security solution provides 100% protection against all known and unknown malware attacks.  I can see why Gartner considers that “intriguing.”   And it might be why they included this comment in their Cool Vendor report:

“Consider Bromium if your organization is looking for innovative ways to protect against advanced targeted attacks.”

We are grateful to Gartner for recognizing Bromium as a Cool Vendor that is innovative, impactful, and intriguing.  Now we’d like to demonstrate these same qualities in your enterprise.  If you have not yet experienced the power of Bromium, let’s get started!

Any VDI security discussion should be two pronged:

1. Protecting the VDI desktop
2. Protecting the endpoint connected to the VDI desktop

Protecting the VDI desktop

Both non-persistent and persistent VDI desktops are susceptible to zero-day attacks that users unwittingly allow in through e-mail attachments and web browsing.  Some may believe that non-persistent desktop infections are easier to remediate in the event of a virus outbreak or security breach because the desktop can be refreshed or rebooted to resume its original state, but there is already evidence that advanced malware is targeting user profiles, which persist even after the desktop has been refreshed or rebooted.

Security-conscious organizations have long used screen scraping as a mechanism to abstract sensitive applications using RDS or XenApp to publish those applications to physical desktops. Those of you who recall the IE6 quandary will remember that publishing an IE6 browser from Windows Server 2003 onto Windows 7 VDI desktops for the sake of legacy web application compatibility was not an uncommon practice. More recently, while developing our product strategy, I encountered several VDI shops that continue to publish an RDS-delivered browser (albeit a current one these days) to their VDI desktops. Why?

In the context of defense-in-depth, there are interesting benefits to publishing a browser running on Windows Server onto a Windows 7 Desktop:

First, most malware is not designed to target Windows Server, or more specifically most malware is written to attack 32 bit Windows. That’s not to say you can count on this as a defense mechanism, especially if the attack is targeted,

Second, if the published browser is compromised, the attack does not propagate to the client. However, it creates a sticky situation: Depending on the malware, it could mean that while connecting endpoints aren’t compromised, their browsing sessions may be.

When I asked these enterprises why they would publish a browser given that it is already a built-in component of the desktop, I received mixed answers:

In the case of persistent virtual desktops, doing so was a nearly universal practice in my admittedly small sample set (three large financial companies, a healthcare provider, and a state agency), because it was easier to abstract the browser away from the desktop image. Simply enough: the browser package needed to be refreshed more often than the desktop image.

If we add non-persistent desktops to the mix, the answer often came back that the published browser was pre-configured with optimal settings to access enterprise web applications.

In any case, short of disabling user access to the internet from a VDI desktop (see “Protecting the endpoint connecting to the VDI desktop” below) , even a perfectly patched and configured browser remains susceptible to zero-day exploits, just as a perfectly patched and configured image of Windows cannot protect itself from zero-days.

vSentry for RDS is designed to protect both VDI desktops and published browsers from APTs and  zero-day attacks. It’s the only solution that can protect a published browser not only from malware, but also from cross-site-scripting and man-in-the-browser attacks. Our architecture decouples each browsing activity not only from the desktop, but also from every other browsing activity, such that no site can persist or propagate an attack onto another site. The same goes for document-based attacks: One bad apple cannot spoil the bunch.

Protecting the endpoint connected to the VDI desktop

If it is the case that less than 100% of your users are accessing their VDI desktops from thin clients, then this section is for you. If your users are accessing their VDI desktops exclusively from laptops, then this section is especially for you.

The employee laptop is the primary attack vector into your enterprise infrastructure. A compromised laptop puts an attacker within easy range of your virtual desktop infrastructure. Again, referring back to my days at Citrix – nearly all VDI implementations consisted of at least some (and in many cases mostly) employee laptop access to virtual desktops. If the attacker has compromised the employee desktop accessing the employee virtual desktop, then it is safe to assume that a compromise of the virtual desktop is within reach.

By ensuring that malware cannot ever persist to either local or virtual desktops, vSentry is also protecting the rest of your sensitive information and infrastructure.

Thus it is our position that vSentry and vSentry for RDS together are a comprehensive defense-in-depth security solution for VDI.

But… what about nesting?

While not a new concept, VT nesting is still very much in its infancy. I recently recorded a webinar with Steve Poitras from Nutanix about why VT nesting was an inevitable component of desktop computing. While we currently have vSentry running on vSphere (ESXi 5.1) desktops through VMware’s Virtual Hardware-Assisted Virtualization as a POC – hardware support for nesting is imminent, and so is installed deployment of vSentry directly on VDI desktops.

A core issue, highlighted by Neil MacDonald, is that different technologies afford different granularity of execution isolation.  At opposite ends of the hardware-isolation spectrum are traditional VMs (each with an OS and its apps), and micro-VMs (each of which contains only a single user task).  Neil also highlights sandboxing, which uses software to isolate an executing application, to protect the OS kernel from attack.

In this post I aim to provide the rationale for our choice of a user-task (an activity initiated by the user) as the  execution construct that should be isolated, both to maximize security and to deliver a compelling end-user experience.

If you’re a security geek and want the cliff notes: The Microvisor implements a Least Privilege Separation Kernel (LPSK) between untrusted tasks and the desktop OS.  It is the only Separation Kernel of which I’m aware that takes advantage of the tiny code-base of a security-specialized hypervisor to dynamically apply Least Privilege [versus statically] at a granular level between tasks within a single running OS instance.  It relies principally on hardware-isolation for tasks because this offers the most robust barrier to any attack.  Finally, it is the first general purpose Separation Kernel that can protect existing, widely deployed OSes and their applications, and that can be deployed and managed using today’s management tools (SCCM, AD or a security console like McAfee ePO).

Our goal is to identify what execution construct to isolate (OS, application, or perhaps even a thread) in order to maximize security and deliver an optimal end-user experience.

Unfortunately neither hypervisor-based OS virtualization nor application sandboxing can adequately secure an endpoint during execution: (Note: it is not my intention to criticize vendors, their products or their legitimate use cases.  This classification is solely from the perspective of their ability to offer run-time protection through isolation, in response to Neil MacDonald’s research note)

• Hypervisor-managed isolation of one or more desktops in VMs on a single PC (eg: VMware Fusion, Workstation, or Player; Windows 8 Hyper-V; Citrix XenClient; Parallels; Moka5) certainly has many valid uses, but each VM is no more secure than a native PC because a hypervisor cannot isolate execution within a VM; moreover virtualization pervades the user experience – the user is conscious of which desktop OS they are using for any activity.
• An alternative approach is to run each vulnerable application in its own VM, and use graphical “tricks” to make the VM appear to be a normal application (eg: Microsoft MED-V (used for app compatibility), Qubes OS, and early versions of Invincea).  This approach is complex to manage, and also doesn’t solve the security problem: If my browser VM  is compromised when I click on a bad site, then when I navigate to my bank, my session is vulnerable to attack.
• Application isolation is another approach.  Sandboxing is frequently used to protect the OS kernel from a malicious or compromised application– for example a browser.   Of course in this case the isolation is software based, but let’s assume that it, in combination with other software protection mechanisms are as robust as hardware isolation  (One can conceive of application isolation approaches that use VT.
  
  For example, see Microsoft Research Drawbridge which may be relevant in future OSes.  But using today’s technology, let’s assume we use every process isolation technique at once:  IE and its sandbox on top of an OS improvement sandbox such as Sandboxie, further strengthened by Microsoft EMET (a powerful free ASLR tool) and running on a system with the full complement of legacy endpoint protection).Unfortunately, as my colleagues Rahul Kashyap and Rafal Wojtczuk demonstrated this year at Black Hat Europe and this week at InfoSec Europe,  if a malicious application compromises the kernel directly (without needing to jump from user space into the kernel) it can compromise the entire system – bypassing all protection.  For example on an unpatched Windows desktop, navigating to a web site that causes the kernel to parse a poisoned font file on behalf of the browser is sufficient.  And there is a long and growing list of kernel CVEs.

This is a huge “gotcha” – neither application sandboxes (eg: Adobe, Microsoft, Google) nor OS improvement sandboxes (Invincea, Sandboxie, Trustware Bufferzone, ZeroVulnerabilityLabs) can block such attacks.  Once again, this is not a criticism: These are powerful technologies that substantially improve system security, but this attack completely bypasses them, and so  they are unable to meet our requirement for rigorous isolation of untrusted tasks.

What can we conclude from this?  Well, we must assume that the OS  kernel will be compromised by a malicious task, so if we are to isolate its computation, we must also isolate all of its kernel activity.  Sandboxing is a non-starter.   But VM’s can’t solve this problem either.

In the Bromium architecture, the Microvisor hardware-isolates both user-space and kernel activity of each untrusted task.   But note that  the moment we start to talk about kernel activity, we need to recognize that a kernel compromise will expose all system resources controlled by the kernel, so somehow we need to extend the isolation to include all task-relevant, kernel controlled resources.

Remember that we need to assume that an attack will occur, and that any part of the system, including the kernel, will be compromised.  When this occurs the set of system resources available (visible to, and accessible by) the task must be minimal – and indeed must not permit the attacker to succeed in any way – stealing valuable  information, or penetrating into an enterprise network.

We identify the boundaries of a task and the minimal set of resources it needs based on the well understood concept of “Need to Know“, (also called the Principle of Least Privilege). Least Privilege dictates the minimum set of system resources (network, file system, desktop) that any task requires to work correctly: For example, in the context of the browser, a task is an application context defined by a site (its TLD), so each browser tab is a different task.

What resources does facebook.com really need?  It needs its cookie, and access to the untrusted web.  If the browser tab for facebook.com is compromised (say the user clicks on a poisoned advertisement), we can tolerate loss of the cookie.  We can live with the fact that malware will have access to the untrusted Internet.  The system will still be safe if:

• The malware cannot see any user keystrokes, mouse input or gain access to the screen (to steal pixels from the display, or display content to the user).
• The malware cannot access any files other than the Facebook cookie
• The malware cannot gain access to any valuable networks or sites (eg: SaaS sites, or the Intranet).
• The malware cannot gain access to any devices (for example – it cannot turn on the webcam)

But what about a user who wants to upload a photograph to Facebook? Dynamic application of Least Privilege is the key to delivering an unchanged, compelling user experience whilst maintaining security.  As an untrusted application,  facebook.com must only have access to its cookie and the web.  But if the application logic of Facebook dynamically  requests access to additional resources (eg: user clicks on “upload a file”),  the Microvisor can  decide to grant access to an additional resource, in a granular fashion- but  only under precise policy control (Dynamic LP), and with the explicit involvement of the user, and only for the minimum duration necessary. For example (there are many more, but the key take-away is that we can deliver an unchanged user experience whilst dynamically enforcing LP):

• If the user wants to upload a photo to Facebook, she can select the photo (in the usual way) on the desktop, and then (only) the selected file will be injected into the hardware-isolated task  for the facebook.com browser tab.
• If the user wants to download a file, it can be allowed to persist outside the confines of the isolated task, but only if we remember the fact that it is untrusted, so that it can only ever be accessed in another hardware-isolated task.

The Solution: Micro-virtualization and the Microvisor

The Microvisor implements a dynamic, hardware-backed Least Privilege Separation Kernel between untrusted tasks and the user desktop:

• It uses Intel VT to hardware-isolate task execution of both user-space and kernel activity, but unlike hypervisor-based virtualization, it does not need to virtualize device hardware, which is controlled by the desktop kernel.
• Instead, it virtualizes access to all shared system resources in such a way as to enforce mutual isolation of all tasks and the desktop, using interfaces and primitives that are task-relevant.   They include the file system, registry, network services, and desktop services such as the clipboard, display, and user input.  The isolation is achieved using light-weight “task-level enlightenments” that build on standard OS APIs.
• Execution is non-persistent: all changes (to any system resource) made by a task during execution are saved in an ephemeral, throw-away cache that is discarded as soon as the user terminates the task.

Summary

• Micro-virtualization is the only technology that can dynamically isolate all untrusted activity of an application at a granular level, protecting the system even when the kernel is attacked.
• Its incredible robustness results from hardware-isolated execution, the “throw-away cache” of all changes, and granular, dynamic application of the principle of least privilege to ensure that no data, networks, devices or user activity of value is exposed in the context of untrusted execution.
• Micro-virtualization can be straightforwardly applied to today’s deployed OSes and applications on any modern PC or server.

Bromium Researchers working out of our Geneva, Switzerland office – have found an incredible way to prevent earthquakes. This ground breaking technology will be demonstrated live in the next CERN (Center for Emergency Response Now) meeting. The technology has been labeled – the ‘earth-o-visor’. Below are some details of the technology and excerpts that I managed to get out of one of the discoverers.

                                                                   Fig1 `

The core technology leverages VT-x (Very Tough) plates that go all the way till the orange color into the center of the earth.  Per prior research and several failures on this topic, it practically needed an ARM and a leg to get to the real core. There have been reports of people using AV (Audio Video) tools and some even underwent HIPS surgery in the quest.  This technology simply isolates the various earthquake prone components of the earth and ensures that earthlings are protected by preventing the earthquake by isolation. Yes, this breakthrough could mean no more earthquake drills for mankind.

The other great benefits of this technology are that now LAVA eruptions can be controlled just by isolating the threat of earthquakes using the ‘earth-o-visor’. One of the most interesting tools used in this experiment was IDA Pro (Interactive Digger & Analyzer). As per the scientists, this helped them to reach all the way till the most important orange part (as illustrated in fig 1).

Rough illustration of IDA Pro is below (we’re still trying to get the exact specs)

Source: http://www.fatdragongames.com/fdgfiles/sci-fi/hollow-earth-expedition-earth-drill-fdg0034

I had a brief chat with Dr Xbee to congratulate him on this major breakthrough. He simply said: ‘This time it wasn’t the Apple fall that motivated me…. rather I would thank Java for this stunning discovery. I was looking at my Windows, sipping my old cup of Java and that’s when it all happened”

We talked to several experts in the industry and asked what would they call this groundbreaking technology? The most truthful answer so far has been ‘Zen’.

More details are expected to be released on April 1^st 2013.

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.

Superficially, BYOD seems like a win-win: The enterprise saves money on device procurement and support, and users get to choose their device. But in my view the idea is over-sold and all too often organizations fail to understand the true financial implications.  Citrix, an avid fan of BYOD, acknowledges that the real win is employee satisfaction.  But all too often the BYOD discussion omits the real challenge – security and risk:

“For companies that allow personal devices, most surveyed permit employee access to email (70%) and websites (53%), while few allow access to more sensitive data such as file servers (16%) financial records (13%). Even so, if a cyber-criminal gains access to employee email, this can expose corporate information and cause significant damage… ”

Seeking a practical way forward, many CIOs give the user Hobson’s choice: You’re “Always in or always out”.  Unfortunately both models are a sort of three-fifths compromise between empowerment and security, and upon closer examination underwhelm both the CISO and users.   In this post I will narrow the discussion to “primary productivity devices” – PCs.  (Unsurprisingly, PC management could benefit from models adopted in MDM, MAM, and MIM – but even these are inadequate.)

“Always in” devices are owned, managed, secured and patched by the enterprise, are on-domain, and have Intranet access.  They can roam, but only under tight control: Access to enterprise applications is only possible over the VPN. The user does not have admin privileges, data at rest is encrypted, the device has endpoint protection, and web browsing is permitted via the enterprise proxy.  When in the office, these devices are NAC-ed and put onto an “inside” VLAN.

An employee owned device is “always out”:  The owner has full admin rights, and can use the device for any purpose.     She is responsible for support (eg: AppleCare) and keeping the device patched.   The enterprise has little say over its presence on the device, which is ideally ephemeral, but rarely so in practice.   When the employee brings the device to work, it is NAC-ed and dynamically assigned to an “outside” VLAN: The Intranet, enterprise applications and other critical infrastructure are not accessible except via some form of remote access, such as RDS or VDI.  The device is effectively in the DMZ and (from any location) the user can only access enterprise web applications or a virtual desktop/app via an SSL VPN and two-factor authentication.  Windows desktops and applications run within the enterprise data center, and are “securely delivered” to the BYO device.

Neither model satisfies the needs of the enterprise or the employee.

“Always in” offers the CISO the most control, but no matter what IT does, the user can easily allow an attacker to compromise the device – for example from a poisoned email attachment or inserting a malicious USB key, or unwittingly checking the news on NBC.com.  Attacks on roaming devices using hotel networks are also a significant concern.  The device’s privileged access to enterprise infrastructure permits an attacker to quickly penetrate deeper.    Rigorous IT controls and device lock-down also make life miserable for the user.  Most useful consumer web-apps are off-limits, and there are substantial privacy concerns when accessing personal sites. Personalization is taboo:  iTunes and Angry Birds are out of the question.

The “always out” user has to be connected in order to work, and endures a user experience dominated by network latency.  And not all applications can be remotely delivered.  This approach also fails to adequately protect the user or the enterprise:  The user can unwittingly install malware that steals log-in credentials and data (personal and corporate).  And remotely accessed virtual desktops are just as vulnerable to a bad click – which invites an attacker into the data center.

Is there a better way? Yes.  The Bromium endpoint architecture satisfies stringent security requirements of the CISO and delights the user – whether she is in the office or on the road.  I will cover the various aspects of this in a series of future posts.

This week my colleague Rafal and I had fun presenting our latest research on sandboxing, @BlackHat EU, in Amsterdam.  We showed how to bypass popular application sandboxes on Windows viz: Sandboxie, BufferZone Pro, Google Chrome and Adobe ReaderX. This is a fun game in general, but we played it a bit differently: We did not spend any time trying to find vulnerabilities in the sandbox implementation. That’s the usual approach, with a different attack surface, and a lot of our fellow security researchers play it regularly (mostly for fun and sometimes for profit). Our approach was focused on leveraging Windows OS kernel vulnerabilities to bypass the sandbox to gain complete control of the system, including the sandbox.  We argue that we can compromise any sandboxed application,  no matter how good the sandbox architecture or implementation. Several of the sandbox vendors that we notified about the vulnerabilities we discovered were a bit smug, offering us “good luck for the talk” (perhaps implying that we would fail or that they didn’t care, and one did not even bother to respond).

In case you missed the talk (yeah just to avoid the Dutch winter), the summary of the talk is:

- Application sandboxes have a fundamental architectural limitation, they cannot reliably protect against vulnerabilities in the underlying Operating System. So your application sandbox is as secure as the next upcoming kernel advisory from Microsoft.

- Attackers are getting sophisticated; kernel vulns are getting more prevalent. Just last month there were 30 kernel mode vulns patched, ok ok… it might be a slight deviation in the curve, but in 2012 itself there were 25 kernel patches from Microsoft. Kernel interfaces are a huge attack surface and it’s getting interesting there.

Sandboxing is not bad, it’s definitely useful. But, as we just demonstrated, it’s not a useful enough approach to be able to tackle the emerging threat vectors. Last week’s pwn2own contest at Cansecwest conference seems to have used a kernel OS exploit to bypass the sandbox, we don’t have full details yet, but it looks like a neat escape.

Recommendation: Run an application sandbox inside a VM environment – especially if you are a malware pro or an enterprise that cares about its IP. You don’t want be the innocent victim of next Duqu equivalent kernel zero day malware.

The Whitepaper is available here and the slides are available here.

P.S: Although “Sandbox Roulette” was fun (and yes we like winning!); our next stop is launching a ‘Sandstorm’ @InfoSec London next month. Hope to see you there! (nope I won’t comment on the English weather!!)

Upon visiting the site we received a LAVA alert that informed us that we were being attacked. This made us excited, not concerned. You see, with vSentry our browsing tasks were totally isolated in hardware-enforced micro-VM’s.

We got on the phone with Brian and our Chief Security Architect, Rahul Kashyap, and started dissecting the long tail of the attack.

At this point there are countless of places that will tell you what the attack consisted of, so we won’t brag about how early and deeply we were able to analyze it.. What I’d like to note is that we were able to do this not in a lab, but using our day to day laptops – without ever fearing a compromise.

Imagine doing that; Browsing the web without fear of compromise. What a novel concept!

One of the coolest things about working at Bromium is that many of us spend our free time cruising the web looking for interesting malware, and then detonating it on our laptops with LAVA. When we find something really interesting, like the NBC.com hack, rather than an “oh no, I’ve been hacked”, you’ll hear a, “woohoo I got a good one!” and then the crew will gather around someone’s desk and examine the full lifespan of the attack; how many binaries it dropped, where the c&c servers are, what registry entries it manipulated, etc.

Just a fun fact about life as a Bromide.

Everyone’s needs are met.  Except yours, that is.  Your infrastructure is actually getting plundered.

Something is wrong here.  After all, you paid good money to your security vendors.  What you get in response is a convenient smokescreenthat obscures the real issue at hand: The undeniable fact that the “detect to protect” paradigm of the security industry has passed its sell-by date.  If the products worked, we’d be secure.  But they don’t.   So instead of pointing out our own shortcomings, we point to the massive efforts of a foreign power and its “cyber army” that no vendor could ever be expected to protect against.   This is a collective lie by the security vendors.

To make things worse, I’ve been peppered all week with emails from K-Street Lobbyists looking to extract dollars from Bromium so that we can ensure that our products are mandated by future Cyber Laws.  The security industry is in crisis – technologically bankrupt, and is attempting to influence lawmakers to mandate that we spend tax dollars on outmoded, useless technology at a time when we already know how to profoundly improve the security of our enterprise infrastructures, while empowering users and embracing the “Internet of Everything”.

What if you didn’t have to worry about being attacked?  What if your devices simply shrugged off APTs and continued unchanged?  Micro-virtualization makes this possible today.

Thanks to the relentless progress of Moore’s Law, we already have in every Intel PC (and soon, every mobile device) the key capabilities required to achieve practical, hardware-enforced protection that makes an endpoint hundreds of thousands of times harder to compromise than today.    Bromium micro-virtualization uses Intel platform features for virtualization and security to dynamically, instantly and invisibly hardware-isolate each untrustworthy user-initiated task.  Every time you open a document, access a web site, click on a link or a movie, that task is invisibly and instantly isolated by the CPU from the rest of your PC, limiting its access to information (files, networks and devices) and preventing it from modifying the system in any way.  For example the browser tab for Facebook.com can only access the browser cookie for Facebook, and the untrusted web, but cannot access any other files, or reach deeper into the enterprise network or access USB devices.  As soon as you close the document or navigate to another site the entire hardware-isolated task is discarded – automatically discarding all malware.  The device remains gold, can be patched when convenient, and discards all malware – enabling IT to empower users to freely access the web and untrusted content.

In September of 2012 Bromium announced its first product, vSentry, for Windows 7.  Since then, we have extended our support to cover Windows Server, and using Microsoft RDS, virtual desktops, legacy Windows XP PCs, non-Windows PCs and tablets.   We are working hard on a Mac product, and  Windows 8 and Android are in the works.   Bromium has chalked up impressive engagements after only four months.  It is encouraging to see the most valued brands in the US acknowledge that they  need an entirely new approach to security and to employee empowerment.

This week NSS Labs completed the first public 3^rd party evaluation of Bromium vSentry.  We defeated every attack.  But we expected nothing less, and we aren’t done yet – we have many more features to add beyond those that have been tested, which will in turn require validation. The NSS results vindicate our architecture and the incredible resilence of Intel hardware-based protection, but they do not give Bromium bragging rights.  Instead, they establish a new bar for security vendor performance and offer you an opportunity to demand demand 100% protection from your current endpoint security vendors.  If they don’t provide it, my suggestion is that you demand a 100% discount or a money-back guarantee if they fail to stop an attack.

It’s time for us to get very serious about cyber-crime.   The future involves an immersive on-line existence for all of us.  Getting serious has nothing to do with Cyber-rattling, and everything to do with transforming the trustworthiness of  our infrastructure, starting with endpoints -relying on hardware-enforced security and an architecture that protects by design.

Let’s get back to IT.  Application Whitelisting (Gartner calls it Application Control -Neil McDonald provides a great overview of vendors) aims to stop any code that is not white-listed from running on an endpoint.   I will dig into the tech a bit later, but first let’s acknowledge that, like apartheid, it is founded on a need to centrally control and classify applications that are known-good.   Is this possible?  Perhaps:  There may be thousands of apps within an enterprise, but even with all of their versions they ought to be enumerable and sign-able.   But are they actually known-good, or known non-malicious, or even known-safe?  That’s a much harder problem – in fact it’s the same problem that the AV vendors face in trying to decide if code is malicious.   Ultimately it is un-decidable – for the same reasons – and the proof reaches as far back as Gödel.

• Every program has bugs, and many of these are exploited by malware.  It’s currently fashionable to pound on Java for its recent vulnerabilities, and many are calling for its removal from the client.   But the JVM isn’t malware, it’s just … shoddy software – like all the other software you use.    I can easily white-list a massively vulnerable JVM.  Would that help to protect me?  No, a binary blob of java that arrives at the client from a web page will run, cannot be white-listed, and can trivially compromise the client, including connecting a C&C site to other computers inside the enterprise to permit exfiltration.
• There are many examples of so-called “easter eggs” –embedded functionality or even complete programs hidden in traditional software packages.  For example the complete FlightSimulator embedded in Excel ’97, “Elvis is not dead” in Lotus Notes 4.0, and many more.     A malicious easter egg is obviously easy to create – and impossible to detect.
• And of course if I were to target your organization, do you think I’d send you an empty email with an attachment titled “virus.exe”?  No, I’d attempt to subvert your mechanisms of trust, delivering malware that is white-listed, at which point all bets are off.
• The absolute failure of the idea of whitelisting is the need to deal with “the outside world”.  Every URL points to a different program, perhaps a different program every time it is invoked.  Site reputation (white-listing) is useless: Reputable sites are used more often and more successfully to distribute malware.

Ultimately white-listing is no different from or better than black-listing because it is impossible for either humans or computer systems to distinguish good software from bad software.

We at Bromium believe that computer systems can only be relied on to ruthlessly implement only simple boundaries of trust – holding the line on the principle of least privilege.   This is possible using micro-virtualization and hardware backed isolation, in concert with attested boot.  In other words, the future of security will be founded on hardware protection, eliminating the need to try to decide the un-decidable.