Skip to content
April 7, 2014 / Simon Crosby

VMs – The New Infrastructure Anachronism


anaThe virtualization of resources has been fundamental at every stage of the development of computing.  Today, application developers don’t think about disk capacity, memory limits, or network bandwidth.  And they depend on resource virtualization for application isolation, privacy and security.  But as our appetite for computing has continued to grow, mapping virtualization onto point-in-time realities imposed by Moore’s Law and human abilities to provision and manage resources at scale has required the constant addition of new abstractions.

Ten years ago in enterprise IT the key constraint was human:  It was simpler to provision a single application per (relatively cheap) x86 server and to scale-out, than to deal with the administrative challenges of multi-application servers; moreover applications had a pesky habit of being OS version dependent.   Meanwhile Moore’s Law did its job, delivering vastly more capacity per device than the OS and a single application needed.   Result: lots of servers with low utilization.   The smart folk at VMware, followed by others (Xen, Microsoft Hyper-V, KVM) re-discovered hardware virtualization, using a hypervisor to permit a single server to host multiple Virtual Machines, each of which encapsulates and isolates an OS instance and its application(s) and enables it to execute unchanged against a virtualized hardware abstraction.

Fast-forward:  In today’s enterprise datacenters server (and storage and network) virtualization has delivered far more than utilization gains:  Computing resources can be dynamically delivered to application instances based on business needs; relocation of running VMs delivers high-availability; and IT can quickly respond to demands for new capacity.  Most importantly, hypervisor based virtualization laid the foundation for Infrastructure as a Service cloud computing – a transformation that eliminates the (human labor practice of) physical resource provisioning and enables consumption-based resource pricing and VM-based server multi-tenancy.

But the abstraction has once again broken, and this time VMs are part of the problem.   Moore’s Law never sleeps (why buy a server, or a router or switch?). Fast adoption of IaaS led to the DevOps movement, and mobile-fueled consumer SaaS (eg Netflix, Facebook), big-data, and the rise of Platform as a Service clouds that hide the very concept of an OS from the app developer increasingly make VMs an anachronism.   Applications adapt to infrastructure failures, and DevOps and PaaS frameworks can auto-scale application capacity across multiple servers – even in different data centers.  The (human) notion of running a VM on a server is irrelevant.  Moreover, public clouds increasingly thrive on OS homogeneity (eg: Ubuntu in AWS, or Windows Server in Azure) and having many copies of the OS on a single server (one in each VM) wastes memory, bloats storage and clogs the network.  Using a VM just to achieve the property of isolation, or to permit secure multi-tenancy is wasteful.  Applications can be better secured if the OS against which they run is minimized in size and optimized for the cloud – and only one copy of the OS is needed.

Crucially, the hardware-isolation technologies incorporated into CPUs to support server virtualization can now be used to deliver hardware-enforced multi-tenancy for applications, without the bulk of a full VM per application, using technologies such as micro-virtualization.   Today, the IaaS clouds rent you memory based on the size of your VM.   But how many copies of the OS do we really need on a server? Right: One.  The use of micro-virtualization in a cloud context will provide an extraordinarily light-weight capability for hardware multi-tenancy of applications – in micro-VMs.

Instead of booting a VM instance on a virtual server, micro-virtualization in the cloud will permit an application to just run, aganst a single bare-metal OS instance – in milliseconds – while benefiting from the hardware isolation offered by virtualization features in the server chipset.  In the Linux world, ZeroVM, built on NaCl offers a minimized bare-metal Linux that aims to offer secure isolation.  One could deliver a similar Windows capability fashioned on server core.

Instead of creating and managing VMs through their life-cycles (create the VM, patch the OS, install the app, boot, snapshot, suspend, resume, clone…) it will be easier to dynamically provision application instances into cloud-hosted micro-VMs using light-weight application containers such as Docker.  Why wait for a VM to boot when an app can instantly launch and run?  Docker application containers can also be moved on the fly – just as VMs before them – but there’s no need to lug around a whole OS with the app. Instead, the application container can be moved to a new micro-VM and the old one destroyed.  In the Azure world, expect an evolution of today’s application virtualization technologies, starting with an ability to move applications from Windows to Azure (FD). The recently announced .NET Foundation.could play a key role in future.

In both IaaS and PaaS clouds it is key to be able to efficiently run, relocate and automate application instances - for example to permit big-data queries to  execute mutually isolated on nodes that manage the data.  Hardware-isolation for application containers – using micro-virtualization – will do the rest.

There’s another good reason to use micro-virtualization in the cloud: Density.   For Bromium’s use case, micro-virtualization delivers about 100x density improvement by comparison with traditional fat VMs. On my Windows PC, hardware isolated applications in micro-VMs all share the Windows 7 OS, but execute copy-on-write.  I regularly have ~150 micro-VMs in under 4GB memory.   My guess is that if we were to re-price today’s IaaS cloud offerings at a penny on the dollar while continuing to deliver hardware-enforced multi-tenancy, enable apps to just “run”, and get IT out of OS and VM lifecycle management, adoption of cloud wouldn’t be an option, it would be an imperative.

When we look back on enterprise IT infrastructure in 10 years, VMs will still play an important role – in private/hosted-private clouds where humans manage traditional enterprise IT applications that are tied to legacy OS dependencies.  For as long as legacy infrastructure applications remain, VMs will remain a key infrastructure abstraction.     But real clouds, both public and private, will provide granular, agile, app-centric hardware-enforced multi-tenancy with vastly superior resource utilization and availability – without the explicit need to expose the concept of a “virtual machine”.

Next post: VMs are an anachronism in end-user computing too!

March 26, 2014 / Gaurav Banga

YouTube has fallen

Last year I wrote about our critical state of cyber-security: the barbarians are at the gates, and CISOs must take bold steps forward to adopt new practices to dramatically reduce enterprise insecurity.

Late last month, my colleagues at Bromium Labs and Google announced to the world that YouTube had been compromised and had been serving out bank-credential stealing malware to millions of visitors.

Let’s take a quick look at what Google’s safe browsing infrastructure says about on Mar 25, 2014.


Screen Shot 2014-03-25 at 6.58.57 PM


The Google Safe Browsing infrastructure is the same system that Google Chrome uses to help you avoid bad websites when surfing the web. Google is stating here that its own had very recently served malware.

This is stunning!

This type of “black mark of disapproval” used to be indicative of a poorly secured website, a site that users should avoid. This was not something you would expect for a very popular website run by an amazing and great company like Google.

How exactly did Google’s YouTube fall to the barbarians?

The details are over here. In short: when you visit a web site, your device actually executes computer code authored by the content provider of the website. Furthermore, some of the code on the web page may come from 3rd parties that are different from the main content provider: e.g., from social media sites that provide the various “Like” and “Follow” buttons, or ads from advertisers.  The YouTube intruders had managed to bypass Google’s strict security vetting processes, and were able to inject their malicious credential stealing code into ads served by

This method of attack is by no means novel. But the intruder used various steps of subterfuge to stay hidden on YouTube’s infrastructure for weeks, undetected.

What is more shocking is the scale and impact of the attack. YouTube is one of the world’s most popular website, with 100s of millions of monthly visitors – consumers and business users. From a CIO’s or CISO’s perspective, none of the traditional enterprise defenses, firewalls, IPS/IDS, whitelisting or anti-virus was able to detect the compromise or attribute the attack to YouTube for weeks.

Advanced network security is better than ever before, but we simply don’t consume information by directly tapping into a network. All information is consumed, stored and created at some endpoint. If the endpoint is compromised, your information is at risk and may be stolen. Laptops and mobile devices were particularly vulnerable to compromise by YouTube while the user was surfing the web from their home or a coffee shop, and could then easily bring malware back into the enterprise.

Now, the folks at Google are wicked smart, very responsible and extremely responsive – they banned this particular malicious advertiser from YouTube within hours of being alerted by Bromium folks.

What is still very troubling, is to think about the other malicious ads, not yet discovered, that are hiding on reputable sites such as YouTube. And, such attacks are clever about getting past advanced network based defenses– they might wait until you are 30 min into viewing a movie, before detonating.

Ads are the lifeblood of the Internet economy, and our Ad networks might be sick with malware.  This is a $100B+ problem.

Back to what to do about it: the CISO and the CIO must invest on new approaches that protect the endpoint directly, without the need to rely on detection algorithms for new malware. One example is Bromium’s micro-virtualization which uses hardware to protect applications, the operating system and data at runtime, to extract and analyze malware for incident response, and to make endpoints self-remediating.

March 14, 2014 / Simon Crosby

Don’t blame the victim of the hack, blame the security vendors!

It’s disappointing to see Business Week and others fault Target IT for the awful compromise it suffered last year, not the least because of the large number of pending lawsuits.   It’s even more disappointing  to see the security industry react with something just short of  glee.   After all, “If it could happen to Target, you could be next!“.

Whilst serious mistakes were made at Target – both architecturally and procedurally – it is  important  to ask how a company with  an established security practice, whose systems met regulatory standards, and that had just spent $1.6M on state-of-the-art network security appliances (that actually issued alerts for the malware used in the attack) – could be tipped over by relatively unsophisticated attackers.

Blaming Target is a bit like blaming you for getting the flu, even though you’ve had a flu shot.

It’s important to hold the vendor ecosystem accountable for its share of the failures.   Instead of “How Target Blew It” let’s try “How the security vendors blew it”  by not stopping the attack.   After all, that is what they promise to do.

The problem is this: Today’s detection-centric products – whether on the network or  an end point,   can’t help.   At best they bleat whenever they see something suspicious or that’s known to be bad, but that’s useless: 

  1. Security teams spend a lot of time chasing down alerts for ineffectual attacks – those for which an alarm is issued, but that wouldn’t execute given the current patch level of the end point.  There is a vast amount of known-bad out there.  Microsoft reported for 2012 & 2013 about 18% of end points (running Microsoft end point protection, so this statistic is probably consumer-biased) encountered malware of some sort, per quarter.   In a Target-sized enterprise  with 100,000 PCs, as many as 18,000 might encounter something scary each quarter. Even if IT detects all of these events, each one represents a potential attack that requires human investigation.
    Even if IT can keep up, it is difficult to know if malware actually executed, or how bad the attack might be,  so there’s no choice but to do open heart surgery on the end point, and (if it’s a desktop) the user spends the afternoon drinking tea instead of doing useful work. Ultimately, the security team wastes time that could have been better spent on actual threats – those to which the enterprise is actually vulnerable.
  2. The Target security team appears to have been worried about this and about the consequences of false alerts because they turned off the “automatic quarantine” feature of their network IDS, and ignored early evidence that an attack was under way.  A mistake for sure, but my guess is that we can’t blame them – if they had to sideline a user or close a store every time an alert was triggered nobody would get any work done and the business would grind to a halt.
  3. When a genuine, new attack occurs to which the enterprise is vulnerable,  it may well go undetected because.. detection can never be perfect.  But if it is a real attack and is detected, it can easily become lost in the sea of alerts.  Perhaps this is what happened at Target.  Looking again at the Microsoft data, although 18% of PCs encounter bad stuff each quarter, remediation was needed on less than  1%.   In other words,  detection-centric security tools probably generate 10x more alarms than they should.

Wouldn’t you rather know about actual attacks and vulnerabilities first?

I first started to think about this when interviewing sales folk from network security vendors.  Time after time I heard this: “All you have to do is plug in the device on a SPAN port and watch the bad stuff coming in, then hand over a purchase order for the customer to sign.”

It is crucial that we consider the entire security life-cycle cost, and not “react” out of fear when a vendor presents a scary looking  list of red alerts.  Their tools may actually increase your costs and increase your risk of compromise by wasting valuable SOC resources on false alarms.   The state of the art in network security will generate lots of alarms for known-bad.  It might even alert you about “suspicious” traffic. But alarms do not equate to security, and sophisticated malware will still breeze on through.  And, remember that all bets are off if your users are mobile, because they cannot be protected by your network perimeter.

There is a vastly better way forward

There is lots of malware, and apparently it’s getting worse.  Patching can never keep up.  Nor can detection.  Or humans for that matter.   We need to block attacks automatically – without signatures, and without doubt.  We need to eliminate false alarms and deliver accurate intelligence for attacks that would actually execute on the end point.  And we need to do this while empowering users to drive the business forward.   The Bromium architecture offers the first ever approach that turns the received wisdom of the security industry on its head:

  • Malware that hits an end point (the user clicks on a bad site, doc, or file) can at worst compromise a micro-VM, without affecting the end point itself.  The user is maximally empowered, fully protected, and need not even be aware of the attack.
  • If the attack does execute, that’s because the OS and its apps are actually vulnerable to it.  That’s useful to know.
  • If malware executes, it can do arbitrary damage to the micro-VM that isolates it, but it can’t persist, steal data or access the enterprise network.  .
  • In contrast to the traditional detection-centric approach that has to try to detect malware before it wreaks havoc, Bromium has the relative luxury of relying on the CPU for hardware isolation.  So we can wait till malware provably compromises the micro-VM in which it is isolated before even having to decide if it is bad or not.  Meanwhile Bromium LAVA will have quietly run the equivalent of a “task-centric black box flight recorder”, tracking every change made by the malware, capturing its payload C&C network, registry changes, privilege escalations and much more.
  • When malware provably compromises a micro-VM running the actual OS and software of the end point it cannot steal any data or access the corporate network.  The malware can’t even capture keystrokes or screen-scrape the end point.  LAVA issues real-time, accurate STIX threat reports, together with the captured malware, for actual attacks.    It gives you everything you need to know: effectively a signature to block malware that will affect specific end points given their current patch level.  This is definitely better than having your SOC team scurrying about chasing false alarms.
  • Finally, the end point will self-remediate, discarding all changes made by the task, automatically.  No need for $500/hr services that are sold knowing that vendors’ products can’t stop the attack.

It’s time to cut the CISO some slack, and to begin to ask security vendors some hard questions:  “Why can’t your product safely block only real attacks?” or,  “Given that it can’t reliably identify or block actual attacks, why should I buy your product?”

February 20, 2014 / Simon Crosby

Client SDNs will deliver Software Defined Enterprise Networks

Yesterday we announced the integration between Bromium LAVA and the Palo Alto Networks security platform.   This is a perfect example of how Client SDN can transform enterprise networks into an agile, responsive, secure environment – and as profoundly important as server-side SDN.  The enterprise will own only part of its cloud, but the vast majority of any enterprise network will remain end-user facing.

Thus far I have described how the Client SDN – a client-side analog of the cloud-side SDN that runs the network services used by micro-VMs on a micro-virtualized end point – dramatically enhances both protection and privacy by ensuring that every hardware-isolated task is entirely independent of all other tasks, and the desktop itself, in terms of its access to network(s) and sites.    Untrusted sites/docs/apps cannot gain access to the Intranet or to SaaS sites of value.    Tasks accessing high value sites can only communicate with those high value sites (and, if desired, a clique of their trusted partners) but have no access to the Internet at large, or to the Intranet.  Intranet applications can be restricted to only ever have access to the Intranet – preventing data leakage.  And no site/doc or detachable/mountable storage need ever be trusted.

In this post I want to show how Client SDN enables the whole enterprise network to become agile –automatically re-configuring the fabric in real-time to block C&C servers and interdict malware in response to new, targeted attacks – for which traditional signatures may never arrive.

Micro-virtualization is protection-centric.  It makes an end point vastly more secure by relying on the CPU to do the hard job of isolation.   This, in turn, transforms the enterprise’s ability to respond: Micro-VM Introspection permits the Microvisor wait until malware actually attacks the hardware isolated task, because the system is protected.  This eliminates false alarms.  Moreover the Microvisor maintains a hidden task “black box recorder” that records the entire kill chain and the malware itself, every DNS query, every IP flow between the task and 3rd party sites/servers, as well as the malware payload.   Every micro-virtualized end point therefore becomes a sensor that can deliver precise, real-time forensic detail for each attack that executes in a hardware isolated micro-VM.

Precise, real-time alerts from each attacked end point can be immediately delivered to the SOC.  Crucially, by adopting an open format such as STIX, these alerts can be immediately used to re-configure the network infrastructure to respond to an attack:  C&C IP addresses can be immediately blocked at the firewall.  In the presence of a next-gen network protection infrastructure, the malware fingerprint and origin site (IP or URL) can be used to prevent other users from falling prey to the same attack.    My point here is that it is possible to entirely automate the enterprise network’s response to malware that is directed at it – even malware uniquely fashioned for it, for which signatures may never be available.

The future of the enterprise network is agile – as agile for end users as it is for the data center.   Client SDN is a crucial building block for a defensible enterprise network.   It keeps bad stuff outside the network, and when an endpoint is attacked it contributes, in real time, precise detail that allows smart network infrastructure elements to dynamically react, to protect the enterprise as a whole.

February 13, 2014 / Simon Crosby

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

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 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 – 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  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)
    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 or
    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 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

  • Sandboxed: The DNS query from my PC for 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, 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.

February 12, 2014 / Simon Crosby

Client SDN: Securely Delivering the Client-Cloud Transformation (1 of 2)

You’re surely familiar with the infrastructure revolution promised by Software Defined Networking.   Of course, anyone who’s built a public cloud has been doing SDN since day one, because the network – like the virtualized server infrastructure – must enforce isolation, security and privacy per tenant or hosted app.  In the enterprise, VMware’s private cloud SDN aspirations (AKA: automate your CCIEs) face a longer journey, but the traditional big iron vendors are in trouble: Cisco’s Insieme (an oddly) hardware-based SDN play looks great – as long as you run an all Cisco network.

SDN is a consequence of Moore’s law, virtualization and a trend toward DevOps that together mandate that the network be “programmable”:

  • The legacy app-per-VM model needs the network (including the last hop vSwitch) to satisfy per-VM networking requirements (ACLs, bandwidth needs etc) wherever an instance happens to be dynamically (re-)located.
  • Web apps need the cloud fabric to dynamically adjust as application tiers scale and adapt to failures.

SDN extends virtualization to embrace and enforce the requirement for multi-tenancy in the (cloud) data center, dynamically delivering app/instance specific network isolation & resources.  This, together with the cost advantages of running the network stack on standard compute nodes with lots of I/O  are up-ending the business of legacy custom-silicon network vendors.  Software and commodity hardware are indeed eating the world.

You’re thinking: “Got it …what’s new?” Read on: Courtesy of micro-virtualization Client SDNs will turn the other half of the enterprise network on its head too.

The future of computing is about clouds & clients.   The enterprise will have a private cloud.   It will also consume SaaS and IaaS services from various providers.   Many users will be be mobile – needing application access from mobile devices and laptops/PCs, from untrusted non-enterprise networks, and perhaps even from untrusted BYO devices.   It is unavoidable that the enterprise will only control a small fraction of its network connectivity.   Client SDNs will transform the networks that serve end users in much the same way that cloud SDNs will transform the future of datacenters.

In the days of client-server computing PCs were directly attached to the enterprise network.   To “protect” them IT deployed all sorts of widgets – the Proxy, Firewall, IDS, IPS, and now network sandboxes.   Each promised some new ability to block attacks.  But attackers are agile, and enterprises are not.  Today this legacy is a bit like a Maginot Line that can be easily bypassed in unexpected ways.  These systems implement a mass of inflexible policy and configuration goop with as many holes punched through them as there are apps that users can’t do without.

Today’s enterprise “perimeter” is a myth. It’s indefensible and cannot be re-configured fast enough to detect/block attackers on a time scale that is relevant to the rate of attack evolution.   Moreover, it is becoming less relevant because many of today’s users are mobile, off-net and want direct client-cloud access – at the very least for personal use.

But the ultimate problem is not the enterprise network – it’s the end point:  Every end point runs hundreds, even thousands, of applications.  Sure IT approves enterprise apps, but each Internet site, each file you download and each attachment you open is a different app – a different trust domain with specific privacy, isolation & security needs.     Client devices are inherently multi-tenant: and a supply chain app co-exist in my browser.  They are different apps, with mutually exclusive needs for access to data, compute and networking on the device.    What’s needed is granular isolation and privacy on a per-app basis, for data, compute, memory and networking – on each device.

Inflexible, indefensible, single tenant networks fail in today’s cloud-client world as surely as does the notion that a single VM instance could enforce multi-tenancy between different customers / tenants of the cloud. Instead, we rely on the separation enforced by VMs and SDNs.   We need to do the same on clients: If I can fool the user in one context and break an OS abstraction, I gain access to everything on the device.

Micro-virtualization on a client device offers the device equivalent of cloud multi-tenancy – enforced by hardware.  It offers each application (eg: browser tab, or document) a defensible micro-perimeter by hardware-isolating its execution and by enforcing least-privilege access to the device, data and networks.  When a micro-VM communicates with its cloud-hosted back-end service, it requires app-specific, granular, secure isolation.  The client equivalent of a cloud SDN is granular, agile, app-specific network isolation per-micro-VM, at the heart of the client itself.   This is the heart of the Client-SDN.  In part 2: how the Client SDN will help the Maginot Line of legacy network bumps-in-the-wire to become agile and responsive to new attacks.

January 7, 2014 / Simon Crosby

FireEye and Mandiant: A Marriage Forged in Compromise

If you’re married you understand the need for compromise to build a successful relationship.   But in this case I’m talking about something different – a marriage forged around the very idea of compromise – the kind of compromise that has shaken consumer and investor confidence in Target.  The glittering marriage between FireEye and Mandiant is a pairing of two vendors with a common failing: Neither can protect customers from targeted malware. Instead, customers have to hope for the best, and when things go pear shaped, hire  expensive experts to clean up after a successful compromise.

The good news is that there is a better way forward.  We at Bromium know that it is possible to protect end points by design, that there is no need for a patient zero, that we can defeat attacks, eliminate remediation and deliver accurate forensic information, in real time, automatically and without spending a fortune.

Before I go any further, I want to state up-front that I have enormous respect for the team at Mandiant.  I have read Richard Bejtlich’s superb book, and the APT1 report is testimony to the incredible investigative capabilities of the Mandiant team.   Many Bromium customers have relied on Mandiant to get them back on their feet after an attack and there can be no doubt that they are in every respect a world-class outfit.   FireEye delivers useful forensic intelligence, but its technology has fundamental limitations.

Serious infosec pundits have written thoughtful analyses of the acquisition and Mandiant’s billion dollar valuation; moreover the press is gushing with enthusiasm, and Wall Street is in love with the match (here is a counter-point).  But every piece I have read fails to recognize that while the new FireEye has a powerful product and services portfolio it doesn’t solve the real problem:   It cannot prevent a determined attacker from successfully compromising the enterprise, but it has a powerful story for how it can get you back on your feet, and stop the attackers next time around.  I wonder if that’s good enough for Target?

Let’s dig into the portfolio of each company a bit, to illustrate my point:

  • FireEye (FEYE) delivers a network appliance (the FireEye Threat Prevention Platform) that uses virtual machine images running on a hypervisor to detect and report on malware entering the enterprise network:
    • The core of the FireEye platform is the patented MVX engine, which provides dynamic, signature-less, and virtualized analysis of advanced cyber attacks. The MVX engine can be deployed across attack vectors and detonates suspicious files, Web pages, and email attachments within instrumented virtual machine environments to confirm a cyber attack. After confirming an attack, the MVX engine also dynamically generates threat intelligence about the indicators of compromise … in a standards-based format, which enables the intelligence to be correlated and shared …”
  • Mandiant is primarily services based, selling consultants at rates as high as $500/hour to help enterprises investigate and remediate breaches and develop IR and SOC practices.   In addition Mandiant has a relatively new product portfolio (competitors: Crowdstrike, CarbonBlack, Cylance) that relies on end point agents to discover and report Indicators of Compromise (IOCs) to a centralized management system.
    • Mandiant for Security Operations: Uses IOCs to inform SOC teams about compromised end points: “… provides the complete picture required to find and scope attacks as they are unfolding. It searches for advanced attackers using Mandiant’s proprietary intelligence and also generates new Indicators from alerts triggered by network security solutions, log management solutions and SIEMs. These auto-generated Indicators analyze impacted endpoints, quickly find other devices affected by the incident and allow you to isolate and contain the compromised devices.”
    • Mandiant for Intelligent Response (MIR): “ an appliance-based solution that scales your experienced incident responders and forensics specialists to investigate thousands of endpoints and scope the impact of an incident. Are you compromised? How did the attacker get in? What systems are involved? Mandiant for Intelligent Response lets you answer these questions.”
    • Mandiant Managed Defense is an appliance based system that continually reports on security status, and
    • Mandiant Intelligence Center is a subscription based service that provides threat intelligence.

The acquisition makes a lot of sense to both companies:

  1. Revenue Growth: Mandiant is the industry’s premier brand in Incident Response, and it brings substantial revenue (about $100M / year) to newly public FireEye at a point when Wall Street will value revenue growth more than it will worry about the potential for weaker gross margins due to Mandiant’s historical dependence on services revenue.
  2. It addresses a FireEye product limitation by providing instrumentation, detection and response to end point attacks that elude detection by the FireEye network appliance.  The Mandiant product enables FireEye to extend its visibility – to help to identify compromised end points.
  3. Mandiant also brings to FireEye an ability to quickly scale a tiered services business around the combined product portfolio, in synergy with its primarily direct-sales based business.

So what’s the problem?

  • Neither FireEye nor its acquired Mandiant products prevent compromise of the end point.   The FireEye appliance informs the SOC about attacks that it detects entering the enterprise.   The Mandiant products inform the SOC about compromised end points, and assist with IR.   But neither stops the attack.  Many FireEye appliances that I have seen are configured to run legacy, unpatched end-point software, and report tons of false positives – a VM is successfully compromised, but the actual end points were not vulnerable to an attack because they were already patched (so I think of FireEye as selling a false sense of good security practice).
  • Lots of malware that I see nowadays is FireEye aware – it specifically waits for end user input before it conducts its attack, to make sure that it is running on an end point.  The Mandiant products don’t block attacks on the end point.  The image below is an example LAVA trace of FireEye aware malware:

    Malware that bypasses FireEye

    Malware that bypasses FireEye

  • To identify an attack, both the FireEye and Mandiant products rely on detection (and therefore some patient zero from which a signature can be created) to determine whether traffic entering the enterprise is malicious, or an end point has been compromised.
  • If an attack is identified, there is no automatic remediation. Fortunately the Mandiant consultants will be available to clean up the mess and get you going again, but that requires expensive, skilled humans.
  • If an end point is attacked and the attack is identified, neither FireEye nor Mandiant can automatically block the attack enterprise-wide.  More humans are needed to turn the IOC into rules for the firewall, IDS or IPS, or even AV.
  • From a sales perspective, the services-centric approach of Mandiant makes sense to the direct sales model of FireEye.  But the company has poor appeal to the channel, and the services business will compete directly with services-centric VARs.

An Alternative: Protect-first, and deliver accurate Threat Intellgence – on a Budget

We at Bromium believe that there is no need for patient zero, that end points can protect themselves by design without third party signatures or IOCs, and automatically remediate themselves when attacked.   We know that protected end points can deliver detailed, accurate forensic insights that would take a human expert days or weeks, in real-time.   We also know how to turn these insights into automatic responses that block attacks enterprise wide.  So the FireEye + Mandiant approach appears to be the polar opposite of the Bromium approach.   They focus on expensive IR and remediation assuming compromise.  Bromium takes a no compromise approach to security, and automates IR:

  1. Protect first, and protect always.   The solution is not dependent on network based or IOC detection on the endpoint.  It protects the end point by design, and because of that resiliency, prevents the customer from having to spend a lot of money on expensive remediation & Incident Response
  2. Automated forensics, not humans at $500/hr: Because there is no need for an “indication of compromise” (indeed no compromise, or patient zero) LAVA can rely on the resilient protection architecture of vSentry to automatically provide unrivalled detailed insight and forensic analysis of the attack, without expensive human-centric processes.  Only by ensuring that attacks execute in an isolated environment on a vSentry protected end-point, can the process of threat intelligence gathering and sharing be properly automated, eliminating the compromise and remediation, and saving time and money for analysis.
  3. Real-time insights, not post-hoc panic: vSentry micro-VMs not only “protect first” but also collectively create an enterprise-wide sensor network that generates real-time threat intelligence that is enterprise- and user- specific, giving real-time insights to actual attacks that have been defeated, rather than false positives or successful compromises.
  4. No false positives: By relying on robust protection, it is possible to wait until a hardware-isolated attack actually compromises the software on an end point (as opposed to whatever software happens to be on a sacrificial VM in the network) – without risk.  With proof of an actual attack, it is possible to eliminate the inevitable false positives that result from the FireEye approach – reducing the workload of the SOC team.
  5. Automated, enterprise-wide protection: When an attacker strikes, LAVA delivers accurate, complete forensic insights in real-time, in the open STIX/MAEC format, allowing automated enterprise-wide protection – blocking the attack at the perimeter, and updating signature based systems automatically, for example using System Center workflows, or integrations with leading vendors such as ForeScout.

Net, net, I think the bloom will come off this rose in the medium term, though I also think that the new FireEye is a powerful force to be reckoned with in the security ecosystem.


Get every new post delivered to your Inbox.

Join 9,516 other followers