Beyond SWGs (Part 3): What’s in the Sandbox?
Anti-malware sandboxes have emerged as a key defensive weapon in cybersecurity. But what are they? In general, they’re appliance- or cloud-based services that capture an executable document, file or script and “detonate” the object in a virtual machine or emulator. They conduct a much deeper level of analysis than typical anti-malware components on endpoints, firewalls or intrusion detection systems. This analysis takes time and can’t usually be done inline with user sessions because users would become impatient with the delay. Sandboxes have, however, proven effective in catching advanced malware, such as zero day exploits, that evade other detection methods.
Sandboxes Multiplying in Advanced Malware Protection Systems
Before I left Gartner a year and a half ago, I got halfway through a report on advanced malware protection systems (MPS), which include sandboxes as one of their core components. My then-colleague Mario De Boer took over the project and did a lot more research, culminating in his report “Malware Protection Systems for Detecting Malicious Code in the Network (client access required).” Even if you don’t have a Gartner account, it’s worth looking at the web page to see the outline. This outline has a surprisingly long list of vendors reviewed and reveals some good recommendations, such as “Do Not Deploy MPS Before Optimizing Existing Malware Controls” and “Be Careful Not to Swamp an MPS With ‘Trivial Malware.’”
SWG and Cloud-Based Sandboxes
In my Beyond SWGs (Part 2): Cloud Security Platforms post on Monday I speculated on what the secure web gateway (SWG) market should evolve to in the future, and reviewed Zscaler’s cloud security service as an example. In that post, I noted that SWGs have proven less than 100% effective against sophisticated malware, creating a market for MPSs, such as FireEye’s.
SWG vendors know that they can’t risk newcomers like FireEye encroaching much further. Trend Micro, Websense and Zscaler are three vendors I know of that have built their own sandboxes. I did a deep dive with Zscaler last week, so let’s take a look at their new sandbox technology, which is also fairly typical of what you’ll see from most vendors with this feature.
Recall from Part 2, Zscaler already scans ALL traffic from all web sites for malware. It decrypts and inspects all SSL traffic (unless precluded by a privacy policy). And with its Fall 2014 service now in limited availability it detonates all executable files and structured documents (e.g. Microsoft Office, or Adobe PDF) in its virtual machine sandbox.
Sandboxes Detect Malware By Its Acts
Like all sandboxes, Zscaler’s is heavily instrumented to detect malicious activity in the virtual machine. It watches for kernel hooking, suspicious entries in the registry, changes to interrupt dispatchers, process tables and even to entries deep in the hard drive where rootkits might go. Provided a sandbox can get the malicious bits of an executable to actually run, it will likely detect them.
After Detection, Mitigation or Analysis?
Once the sandbox detects malware in an object, it records the fact by putting a unique summary (hash or digest) of the contents on a blacklist. That same object with that same digest will henceforth get blocked and the solution should not devote any more sandbox cycles to it again. (Zscaler and other vendors probably also record more information to help them detect morphed instances of the previously-sandboxed malware in case the malware authors are smart enough to constantly change the object slightly each time content gets sent or downloaded. Otherwise, polymorphic “sheep’s clothing” could create some debilitating resource exhaustion attacks.)
Recall that the sandbox analysis can be too consuming to do in a way that’s transparent to the user. This may not be problem for content passing over store and forward email, but it is a problem for interactive web sessions. That’s why solutions like FireEye are almost always deployed out of band. But that means that “patient zero” (the first browser to encounter the malware) may get infected.
Zscaler does something interesting, however. If the analysis is taking too long for a web sessions, by default Zscaler’s sandbox will quarantine the executable content, sending a message to the browser suggesting the user try again after a few minutes. This only happens to the very first user or users that encounter that particular content since its hash value will be whitelisted once the analysis completes.
Zscaler, FireEye and many other sandbox solutions are primarily focused on virtual machine-based detection and then mitigation. There are, however, other variations.Vendors such as Mantech Cyber Solutions (formerly HBGary) in the incident response may also deploy sandboxes for the purposes of malware analysis and include honeypot features. They’ll try to keep the malware running, provide it false inputs and analyze what it does over a period time. Still others, such as Damballa, started out in the advanced malware protection space by analyzing network traffic and domain data. They added sandboxes later to compete with FireEye but may still primarily rely on the traffic analysis.
Zscaler, FireEye and many other sandbox solutions are primarily focused on virtual machine-based detection and then mitigation. There are, however, other variations.Vendors such as Mantech Cyber Solutions (formerly HBGary) in the incident response may also deploy sandboxes for the purposes of malware analysis and include honeypot features. They’ll try to keep the malware running, provide it false inputs and analyze what it does over a period time. Still others, such as Damballa, started out in the advanced malware protection space by analyzing network traffic and domain data. They added sandboxes later to compete with FireEye but may still primarily rely on the traffic analysis.
More on FireEye and Zscaler
FireEye’s sandbox has been on the market much longer than most and has some sophisticated features. Per FireEye’s web site “Objects are executed against a range of browsers, plug-ins, applications, and operating environments.” This multiplicity of VMs allows the software to detect malware even if it doesn’t activate on all versions of the target OS, and to have a greater chance of detecting targeted attacks that might not be fully de-cloaked until some stealthy bits of the malware sense the desired environment.
Zscaler’s sandboxing system is still young, and doesn’t have the same kind of multi-vector analysis. But Zscaler is still aggressively positioning it against FireEye. Zscaler’s literature notes that its cloud-based service is less expensive than FireEye and suggests that large organizations at least use its sandbox to reduce the number of FireEye boxes in deployment.
A Bold Claim
Finally, on Zscaler’s web site, the company cites a customer saying:
After four weeks with FireEye we were not able to detect a single piece of malicious code [now that we have Zscaler] – Large Publishing Company.
Not a lot of detail there, but it does point out an interesting idea actually recommended in one of my first SWG reports: get a FireEye box (or something else that you think has superior detection) and configure it to take the traffic behind the gateway. You could try it at just one site to minimize the risk of career-limiting availability brownouts. Please let me know in the comments if you’ve ever tried anything like this, or have other suggestions.
Conclusion
It’s great to see vendors zero in on sophisticated malware and drive down costs through competition. But remember, there’s no silver bullet. Faced with sandboxes, malware authors will adapt and evade. Sometimes they will still be successful. Mitigating sophisticated malware will continue requiring the full set of recommendations I offered in Beyond SWGs (Part 2).