The problems of protecting endpoints are pretty well understood. As we described in The 2014 Guide to Endpoint Security, you have stuff (private data and/or intellectual property) that others want. On the other hand, you have employees who need to do their jobs and require access to said private data and/or intellectual property. Those employees have sensitive data on their devices, so you need to protect their endpoints. It’s not like this is anything new. Protecting endpoints has been a focus of security professionals since, well, always – with decidedly unimpressive results.

Why is protecting endpoints so hard? It can’t be a matter of effort, right? Billions have been spent on research to identify better ways to protect these devices. Organizations have spent tens of billions on endpoint security products and services. Yet, every minute more devices are compromised, more data is stolen, and security folks keep having to answer senior management, regulators, and ultimately customers as to why this keeps happening.

The lack of demonstrable progress comes down to two intertwined causes. First, devices are built using software that has defects attackers can exploit. Nothing is perfect, especially not software, so every line of code presents attack surface. Second, employees can be fooled into taking action (such as installing software or clicking a link) that results in a successful attack.

These two causes can’t really be separated. If the device isn’t vulnerable, then nothing an employee does should result in a successful attack. And likewise, if the employee doesn’t allow delivery of the attack/exploit code by clicking things, having vulnerable software is less of an issue. So if you can disrupt either causes your endpoints will be far better protected. Of course this is much easier said than done.

In this new series, “Reducing Attack Surface with Application Control,” we will dig into the good and bad of application control (also known as application white listing) technology, talking about how AppControl can stop malware in its tracks and mitigate the risks of both vulnerable software and gullible users. We won’t shy away from addressing head-on the perception issues of endpoint lockdown, which cause many organizations to disregard the technology as infeasible in their environments. Finally, we will discuss use cases where AppControl makes a lot of sense and how it can favorably impact security posture, both reducing the attack surface of vulnerable devices and protecting users from themselves.

Accelerating Attacker Innovation

We mentioned the billions of dollars being spent on research to protect endpoint devices more effectively. It is legitimate to ask why these efforts haven’t really worked. It comes back to attackers innovating faster than defenders. And even if technology emerges to protect devices more effectively, it takes years for new technologies to become pervasive enough to blunt the impact of attackers across a broad market.

The reactive nature of traditional malware defenses – in terms of finding an attack, profiling it, and developing a signature to block it on the device – makes existing mitigations too little too late. Attackers now randomly change what attacks look like using polymorphic malware, so looking for malware files cannot solve the problem. Additionally, attackers have new and increasingly sophisticated means to contact their command and control (C&C) systems and obscure data during exfiltration, making detection all the harder.

Attackers also do a lot more testing now to make sure their attacks work before they use them. Endpoint security technologies can be bought for a very small investment, so attackers refine their malware to ensure it works against a majority of the defenses in use. This causes security professionals to look at different ways of breaking the kill chain, as we described in The CISO’s Guide to Advanced Attackers. You can do this a couple different ways:

1. Impede Delivery: If the attacker cannot deliver the attack to a vulnerable device, the chain is broken. This involves effectively stopping tactics like phishing, either by blocking the email before it gets to an employee or training employees not to click things that would result in malware delivery.
2. Stop Compromise: Even if the attack does reach a device, if it cannot execute and exploit the device, the chain is broken. This involves a different approach to protecting endpoints, and will be the main focus of this series.
3. Block C&C: If the device is compromised, but cannot contact the command and control infrastructure to receive instructions and additional attack code, the impact of the attack is reduced. This requires the ability to analyze all outbound network traffic for C&C patterns, as well as watching for contact with networks with bad reputations. We discussed many of these tactics in our Network-based Threat Intelligence research.
4. Block Exfiltration: The last defense is to stop the exfiltration of data from your environment. Whether via data leak prevention technology or some other means of content or egress filtering to detect protected content, if you can stop data from leaving your environment there is no loss.

The earlier you break the kill chain, the better. But in the real world, you are best served by a multi-faceted approach encompassing all the options listed above. Now let’s dig into the Stop Compromise strategy for breaking the kill chain, which is really where application control fits into the security control hierarchy.

Stop Code Execution. Stop Malware.

The main focus of anti-virus and anti-malware technology since the beginning has been to stop malicious code from executing on a device, thus stopping compromise. What has been evolving is how the malware is detected, and what parts of devices software can access. There are currently a handful of approaches.

1. Block the Bad: This is the traditional AV approach of matching malware signatures against code executing on the device. The problem is scale because there is so much bad that you cannot possible expect an endpoint to check for every attack since the beginning of time.
2. Improve Heuristics: It is impossible to block all malware because it is constantly changing, so you need to focus on what malware does. By improving the recognition of attack patterns and blocking activity that makes no sense for a specific application, you can greatly improve attack detection, and maybe even block. Of course, you need to know what the application should be doing at a very granular level so you can identify patterns that aren’t “authorized application behavior” and likely indicate malware.
3. Isolation: An emerging technique for protecting endpoints is to run vulnerable applications – including browsers, Java, and Adobe Reader – in a restricted sandbox to isolate them from the rest of the device, in case they execute malicious code. This assumes applications will be attacked, but impedes attackers’ ability to get anything else off the device. An alternative is to descend into the innards of the operating system and isolate actual processes. This emerging technology is promising for making the base operating system resilient to attack.
4. Allow the Good: Finally, let’s cover default deny: defining a set of authorized code that can execute on devices and blocking everything else. This provides true device lockdown because no code (either malicious or legitimate) can execute unless authorized. This approach underlies Application Control technology and will be the focus of this series.

As you see, there are a number of ways to stop device compromise. Which approach is most appropriate depends on the situation. Before we get into specific use cases in the next post, let’s dig into some perceptions of application control.

The Perception

There is no way to skirt the subject. Many organizations have had less than stellar experiences with application control technologies in the decade the technology has been available. The complaints tend to center around a few issues:

1. Employees can’t do their jobs: This one is obvious. Employees want to do what they want, when they want. Application Control defines a set of applications they can run and blocks everything else. Some of the criticism is unwarranted – there may not be a business requirement to run iTunes or Gears of War on a corporate device. But the inability of a knowledge worker to install a new application when they need it is a legitimate concern. With the integration of more plug-ins and code execution within browsers, application control can also break the user experience of web browsing if it blocks these plug-ins.
2. It requires another agent: This is another legitimate gripe. In order to enforce application control policies on a device, you need software of some sort to run on it. No way around that one. The best case is that the AppControl product can leverage another agent already resident on the device (for endpoint management, for instance).
3. It’s hard to manage: In any organization of scale employees want to do things and install code on their devices, all day, every day. Someone needs to approve all these software programs and determine their appropriateness. That takes time, and it’s not like security folks have a ton of extra time for new responsibilities. Don’t forget about the need to authorize every patch or update for every application in use.
4. It doesn’t work: This criticism is a bit squishy, but there have been examples of Microsoft’s patching process being exploited, as well as code running within authorized applications (such as browsers and Adobe Reader) that is malicious, evading application control defenses. As with every other security control, nothing provides 100% security. Organizations need to understand the compromises involved in establishing the trust model for application control.

The Reality

These criticisms are all reasonable. Every organization needs to weigh the trade-offs of security against usability to allow employees to do their jobs. If security controls seriously impede the flow of business, that is a failure. It is a question of balancing the risk of doing something against the impact of not allowing it via security controls.

Application Control does impact user experience. It needs to. It’s as simple as that. If the employee can run whatever code they want on their devices you aren’t really protecting anything. You always need to manage the trade-off between allowing employees to make decisions and protecting devices. But if employees can load software onto their machines and execute code in their browsers and other applications, devices will be compromised.

Approaches focusing on isolation or detection during (or after) compromise have less impact on user experience, but depend on being right and catching every attack. Historically, this has proven to be an unsuccessful approach. That doesn’t mean none of the isolation and advanced heuristics approaches appearing right now hold promise. But at this point we do not know whether these new techniques sufficiently address the malware problem. We will address this in greater depth in our Advanced Endpoint and Server Protection series.

Our next post will dig into use cases where application control can be a good choice, and key features you should look for when selecting application control to address them.