After going over the challenges of protecting those pesky endpoints in the introductory post of the Endpoint Security Buyer’s Guide, it is now time to turn our attention to the anchor feature of any endpoint security offering: anti-malware. Anti-malware technologies have been much maligned. In light of the ongoing (and frequently successful) attacks on devices ‘protected’ by anti-malware tools, we need some perspective – not only on where anti-malware has been, but where the technology is going, and how that impacts endpoint security buying decisions.
History Lesson: Reacting No Bueno
Historically, anti-malware technologies have utilized virus signatures to detect known bad files – a blacklist. It’s ancient history at this point, but as new malware samples accelerated to tens of thousands per day, this model broke. Vendors could neither keep pace with the number of files to analyze nor update their hundreds of millions of deployed AV agents with gigabytes of signatures every couple minutes. So anti-malware vendors started looking at new technologies to address the limitations of the blacklist, including heuristics to identify attack behavior within endpoints, and various reputation services to identify malicious IP addresses and malware characteristics.
But the technology is still inherently reactive. Anti-malware vendors cannot protect against any attack until they see and analyze it – either the specific file or recognizable and identifiable tactics or indicators to watch for. They need to profile the attack and push updated rules down to each protected endpoint. “Big data” signature repositories in the cloud, cataloging known files both safe and malicious, have helped to address the issues around distributing billions of file hashes to each AV agent. If an agent sees a file it doesn’t recognize, it asks the cloud for a verdict. But that’s still a short-term workaround for a fundamental issue with blacklists.
In light of modern randomly mutating polymorphic malware, expecting to reliably match identifiable patterns would be unrealistic – no matter how big an signature repository you build in the cloud. Blacklists can block simple attacks using common techniques, but are completely ineffective against advanced malware attacks from sophisticated adversaries. Anti-malware technology needs to evolve, and it cannot rely purely on file hashes. We described the early stages of this evolution in Evolving Endpoint Malware Detection, so we will summarize here.
Better Heuristics
You cannot depend on reliably matching what a file looks like – you need to pay much more attention to what it does. This is the concept behind the heuristics that anti-malware offerings have been built on in recent years. The issue with those early heuristic offerings was having enough context to know whether an executable was taking a legitimate action. Malicious actions were defined generically for a device, generally based on operating system characteristics, so false positives (blocking a legitimate action) and false negatives (failing to block an attack) were both common: lose/lose.
The heuristics have evolved to factor in authorized application behavior. This advancement has dramatically improved heuristic accuracy, because rules are built and maintained for each application. Okay, not every application, but at least the 7 applications targeted most often by attackers (browsers, Java, Adobe Reader, Word, Excel, PowerPoint, and Outlook). These applications have been profiled to identify authorized behavior. And anything unauthorized is blocked. Sound familiar? Yes, this is a type of whitelisting: only authorized activities are allowed.
By understanding all the legitimate functions within a constrained universe of frequently targeted applications, a significant chunk of attack surface can be eliminated. To use a simple example, there really aren’t any good reasons for a keylogger to capturing keystrokes while filling out a form on a banking website. And it is decidedly fishy to take a screen grab of a form with PII on it. These activities would have been missed previously – both screen grabs and reading keyboard input are legitimate functions – but context enables us to recognize and stop them.
That doesn’t mean attackers won’t continue targeting operating system vulnerabilities, other applications (outside the big 7), or employees with social engineering. But this approach has made a big difference in the efficacy of anti-malware technology.
Better Isolation
The next area of innovation on endpoints is the sandbox. We have talked about sandboxing malware within a Network-based Malware Detection Device, which also enables you to focus on what the file does before it is executed on a vulnerable system. But isolation zones for testing potentially malicious code are appearing on endpoints as well. The idea is to spin up a walled garden for a limited set of applications (the big 7, for example) that shields the rest of the device from those applications.
Many of us security-aware individuals have been using virtual machines on our endpoints to run these risky applications for years. But this approach only suited the technically savvy, and never saw broad usage within enterprises. To find any market success, isolation products must maintain a consistent user experience. It is still pretty early for isolation technologies, but the approach – even down to virtualizing different processes within the OS – shows promise. It is definitely one to keep an eye on.
Of course it is important to keep in mind that sandboxes are not a panacea. If the isolation technology utilizes any base operating system services (network stacks, printer drivers, etc.), the device is still vulnerable to attacks on those services – even running in an isolated environment. So an isolation technology doesn’t mean you don’t have to manage the hygiene (patching & configuration) on the device, as we will discuss in the next post.
Total Lockdown
Finally, there is the total lockdown option: defining an authorized set of applications/executables that can run on the device and blocking everything else. This Application Whitelisting (AWL) approach has been around for 10+ years, and still remains a niche use case for endpoint protection. But it is not mainstream and unlikely ever to be, because it breaks the end-user experience, and end users don’t like it much. If an application an employee wants to run isn’t authorized, they are out of business – unless either IT manages a very quick authorization process (rare) or they get a “grace period” where the application can run for 24 or 48 hours until the administrators approve or reject it. Obviously the grace period opens a hole in the security model, but some organizations are willing to make this compromise in order to lock down endpoints otherwise.
The user impact is why this technology is more common on servers. It is fortunately rare for a server call the help desk to ask why it can’t install iTunes, so AWL can very effectively protect fixed-function devices (including kiosks) from malware. Users also tend to accept AWL on very high-value endpoints which need stronger protection from targeted malware.
The Future: Endpoint Activity Monitoring
The techniques we described above are all designed to stop malware from executing on a device or to block malicious activities during execution. But that is not enough. What may look like a harmless file today might be detected as malware tomorrow. Given the seemingly endless supply of 0-day attacks and the level of variation in attack kits, you need to be prepared for the inevitability that you will miss something. Then you will need to respond as quickly as possible, and it will be helpful to know which devices the bad file was downloaded to, and on which it ran.
So you will want to keep track of what’s happening on each endpoint at all times. We call that Endpoint Activity Monitoring – at least until the industry comes up with a better term. Yes, it imposes a heavy compute burden, and it can generate a large amount of data, but fortunately we have all those fancy big data and cloud analytics technologies. For this approach to work you need to know what files were downloaded onto each device, which were executed, and what changes were made on each device – with fine granularity. So if you can profile the malware as described in Malware Analysis Quant, you can query your endpoint activity monitoring platform for devices which show indications of infections – regardless of when they were infected.
Earlier we said reaction no bueno, but success actually still depends on reacting faster and better. By shortening the window between infection and detection you can remediate faster and contain damage more effectively. With the ability to search all devices for indicators, you can move beyond the whack-a-mole approach of fixing one device at a time, to identify all devices impacted by a specific attack and then remediate in one fell swoop. That is where we expect endpoint anti-malware technology to go over the next few years.
But endpoint security isn’t just about blocking malware – it is also about ensuring unpatched vulnerabilities or faulty configurations don’t result in device compromise. So in the next post we will go though the key endpoint hygiene technologies, including patch and configuration management, as well as device control.
Reader interactions
2 Replies to “Endpoint Security Buyer’s Guide: Anti-Malware, Protecting Endpoints from Attacks”
This is a solid analysis of the current state of anti-malware or advanced endpoint protection controls. Detection based mechanisms are fundamentally flawed (visit your nearest airport for evidence), so isolation is the next frontier. Looking forward to the rest of the series.
SO, in your view even strictly IR-focused vendors would be “Endpoint Activity Monitoring”?