Are Anti-Malware's Days Numbered?
Anti-malware software can't spot all malicious code. Is isolating end-user tasks through virtualization a better approach to security?
Target CEO Gregg Steinhafel lost his job after a malware attack on the retailer in which the credit card and personal information of millions of customers was stolen in a huge data breach. The malware, which hackers loaded on to company cash registers, apparently flew under the radar of software designed to spot this type of attack.
This highlights a problem with security software designed to recognize malicious code: It can spot some malicious software - most malicious software even - but it can't catch it all. All it takes is one undetected attack to cause massive damage to a company like Target, and for heads to roll at the very top.
It's probably not reasonable to expect anti-malware systems to spot everything because, according to McAfee, over 100,000 malware variants appear every day. And zero day exploits can't be recognized because they are by definition brand new, so anti-malware systems have to rely on things like heuristics and behavioral analysis to try to determine if previously unseen code is malicious. In a survey published last summer 62 percent of respondents said their endpoint security software was not effective for detecting zero-day and/or polymorphic malware.
Security through Isolation
A better solution is to give up relying on malware detection, and instead isolate end user tasks so that they can't do any harm even if they do become infected. That's the view of Ian Pratt, co-founder of security company Bromium, which markets virtualization-based isolation software called vSentry. Pratt is also chairman of Xen.org, the organization that leads the creation of the open source Xen virtualization hypervisor.
An alternative Linux-based operating system called Qubes also uses Xen technology and offers security through isolation.
"If you isolate rather than detect, you don't have to worry about whether software is malicious or not," said Pratt, speaking at the InfoSecurity Europe 2014 conference in London earlier this month.
Xen-based virtualization, using servers equipped with modern, virtualization-enabled microprocessors, is used by public cloud providers like Amazon and Google to enable secure multi-tenancy in their clouds. This means customers' virtual machines are isolated from each other, even though they run on the same underlying physical server.
The same principle can be used to provide a form of multi-tenancy on end-user machines, Pratt said. The difference is that in this case the end-user machine hosts "micro virtual machines" (mVMs), each of which runs a separate user task. But just like the virtual machines in public clouds, each mVM is isolated from the others and the underlying operating system on the end user machine.
How Xen-based Virtualization Isolates Tasks
Why the talk of a "user task?" Pratt said that instead of isolating applications, microVMs isolate individual Web pages that a user browses to or individual documents that a user may open. This granularity provides better protection than application-level isolation as an infection can't pass from one Web page or document to another, he said.
"And don't forget we are talking about hardware enforced isolation rather than software sandboxing," Pratt added. That's important because software sandbox isolation has often proven to be ineffective - notably in the Java runtime.
Of course this all depends on the hypervisor in charge of virtualizing these user tasks being secure. To do this Bromium uses a cut-down "microvisor."
"You have millions of lines of code in an operating system kernel, in libraries and utilities, and in the applications themselves. So there are always going to be vulnerabilities," Pratt said. "So let's put a microvisor on the hardware and concentrate on securing that."
It's certainly the case that securing a smaller amount of code is more practical than securing millions of lines of code, but securing a microvisor is still a task that shouldn't be underestimated. And let's not forget the lesson that the recent Heartbleed fiasco brought home recently: Even open source code that is open to the scrutiny of millions of eyeballs can harbor bugs that go undetected for a very long time.
Once the microvisor is in place, the idea is that when a user visits a Web page, a mVM is created in a matter of milliseconds, the browser is fired up and it then renders the page. The underlying user experience is the same, but from a security point of view you don't care if the Web page injects malware into the mVM. The same is true if the user does any other "untrusted" task such as opening a document received by email.
That's because behind the scenes the task is isolated in the microVM. As the mVM runs, changes to Windows or memory are cached locally; no changes are made to the underlying Windows installation or file system, although to the task in the mVM the changes are real.
If malware attempts to modify the Windows kernel or DLLs in the file system, it only makes changes within the microVM. When the user task is finished (for example when the user browses to another Web page) all the cached changes are deleted, and the underlying system is unaffected.
What's important is that the mVM is also only presented with the resources it needs to carry out its task. So a task that is rendering an untrusted PDF email attachment is only presented with the PDF itself in its file system.
As they are not required, the mVM is not given access to the rest of the computer's files system, network access or access to other devices. That means that if malware is present, it can't access other data or use local area network access to move on to more valuable servers on the network - because these resources are simply not present.
Xen-based Isolation and Legacy Tech
This type of technology can be particularly useful for organizations that need to continue using Windows XP even though support for the operating system has finished, or that need to use older insecure versions of software such as Java for compatibility with legacy applications.
"If you use a micro VM then you don't have to care about zero days like the recent one discovered in Windows Explorer," Pratt said.
He added that over 1,200 security vulnerabilities were discovered in the top 50 applications in 2013 which needed emergency security patches. "But if you are using microVMs then there is actually no rush to apply security patches. You can get into your own once a month patching cycle."
Will this containment approach to security catch on? If it does it's a tacit admission that prevention doesn't work, and that containment is the only remaining option. After Target's experience, the company's former CEO may now agree.
Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.
By Jeff Goldman
May 15, 2014
The most active, according to Damballa, see around 150,000 security events each day.