A well maintained sandbox system - capable of launching a dozen or more virtual systems running a vanilla Microsoft Windows installation - is sufficient enough to detect a high percentage of the mainstream malware in circulation, and is perfectly suited to detecting serial variants generated by popular malware construction kits (assuming that no anti-virtual machine evasion code has been included).
Organizations that have deployed the myriad of commercial malware sandboxing appliances have, after a year of observing their operation, increasingly come to ask two important questions. Are the malware I'm capturing really a threat to my business, and why haven't the number of infected devices I detect weekly gone down?
The answers to both questions are closely related.
Because the sandboxing appliances must operate multiple virtual machines, they are restricted to virtualizing specific operating system images. Some appliances come with a default set of ISO images (typically Windows XP SP3 with a suite of common business applications), while others allow you to run a 32-bit corporate "Gold Image". The latter ISO image type is much preferred, as it more adequately represents an organizations desktop environment.
If your organization has deployed Apple, Android, Linux or other non-Windows legacy devices, or is running 64-bit systems, then it's unlikely that your sandbox is doing anything meaningful against threats that target those operating systems. The same applies to the applications your organization installs (or allows to be installed) on corporate systems. If a malware sample exploits vulnerabilities in a specific piece of software and that software isn't included in the ISO image you're running in your sandbox, then of course it'll pass through undetected.
I'm reminded of Gartner's Hype Cycle and the "trough of disillusionment" after a much hyped technology is finally deployed and reaches an operational status. For years now anti-malware sandbox vendors have been touting the approach as a solution to targeted attacks and APT's yet, with even a basic understanding of how these various sandbox technologies operate, it should be obvious what their detection limits are likely to be.
The sandboxing appliances popularly deployed today are performing well against your average"0-day" malware threat, but capabilities decline dramatically the more targeted an adversary becomes. As such, organizations are much better at stopping the generic non-targeted "Internet threats", but becoming more vulnerable to marginally tuned malware. For example, any piece of malware that requires the user to perform an action at a specific time (before it acts maliciously) is sufficient to evade detection in most cases.
Incident response teams and others tasked with malware investigation within large corporations appreciate the fact that sandboxing approaches are helping to keep the mainstream malware "noise" out of their enterprise networks, but are struggling in their communications to upper management the fact that these recent protection investments have had little effect against espionage and other targeted malware attacks.
Until such time that sandboxing technology can virtualize every hardware platform or device used within an organization, emulate every programming or scripting language present on the desktops or BYOD gadgets that employees chose to bring to work, or execute every version of software application used within a particular business, then you're going to have to keep on investing in technologies and resources capable of detecting and mitigating non-generic Internet threats.
Even if that was possible, malware sandboxing approaches will only capture the threats that come in through the front-door -- not threats that get transported between networks via roaming devices. So, as business operations embrace the cloud, BYOD, VPN dual tunneling, and expand their home-office workforce, centralized sandboxing approaches will rapidly diminish in efficacy -- and malware authors continue to have the upper-hand.
Gunter Ollmann, CTO, IOActive Inc.