In the first post in our Application Control series we discussed why it is hard to protect endpoints, and some of the emerging alternative technologies that promise to help us do better. Mostly because it is probably impossible do a worse job of protecting endpoints, right? We described Application Control (also known as Application Whitelisting), one of these alternatives, while being candid about the perception and reality of this technology after years of use.

Our conclusion was that Application Control makes a lot of sense in a variety of use cases, and can work in more general situations, if the organization is willing to make some tradeoffs. This post describes the “good fit” use cases and mentions some of the features & functions that can make a huge difference to security and usability.

Use Cases

Given the breadth of ways computing devices are used in a typical enterprise, trying to use a generic set of security controls for every device doesn’t make much sense. So first you spend some time profiling the main use models of these devices and defining some standard ‘profiles’, for which you can then design appropriate defenses. There are quite a few attributes you can use to define these use cases, but here are the main ones we usually see:

1. Operating System: You protect Windows devices differently than Macs than Linux servers, because each has a different security model and different available controls. When deciding how to protect a device, operating system is a fundamental factor.
2. Usage Model: Next look at how the device is used. Is it a desktop, kiosk, server, laptop, or mobile device? We protect personal desktops differently than kiosks, even if the hardware and operating system are the same.
3. Application variability: Consider what kind of applications run on the device, as well as how often they change and are updated.
4. Geographic distribution: Where is the device located? Do you have dedicated IT and/or security staff there? What is the culture and do you have the ability to monitor and lock it down? Some countries don’t allow device monitoring and some security controls require permission from government organizations, so this must be a consideration as well.
5. Access to sensitive data: Do the users of these devices have access to sensitive and/or protected data? If so you may need to protect them differently. Likewise, a public device in an open area, with no access to corporate networks, may be able to do with much looser security controls.

Using these types of attributes you should be able to define a handful (or two) of use cases, which you can use to determine the most appropriate means of protecting each device, trading off security against usability.

Let’s list a few of the key use cases where application control fits well.

OS Lockdown

When an operating system is at the end of its life and no longer receiving security updates, it is a sitting duck. Attackers have free rein to continue finding exploitable defects with no fear of patches to ruin their plans. Windows XP security updates officially end April 2014 – after that organizations still using XP are out of luck. (Like luck has anything to do with it…)

We know you wonder why on Earth any organization serious about security – or even not so serious – would still use XP. It is a legitimate question, with reasonable answers. For one, some legacy applications still only run on XP. It may not be worth the investment – or even possible, depending on legal/ownership issues – to migrate to a modern operating system, so on XP they stay. A similar situation arises with compliance requirements to have applications qualified by a government agency. We see this a lot in healthcare, where the OS cannot even be patched without going through a lengthy and painful qualification process. That doesn’t happen, so on XP it stays. Despite Microsoft’s best efforts, XP isn’t going away any time soon.

Unfortunately that means XP will still be a common target for attackers, and organizations will have little choice but to protect vulnerable devices somehow. Locking them down may be one of the few viable options. In this situation using application control in default-deny mode, allowing only authorized applications to run, works well.

Fixed Function Devices

Another use case we see frequently for application control is fixed function devices, such as kiosks running embedded operating systems. Think an ATM or payment station, where you don’t see the underlying operating system. These devices only run a select few applications, built specifically for the device. In this scenario there is no reason for any software besides authorized applications to run. Customers shouldn’t be browsing the Internet on an ATM machine. So application control works well to lock down kiosks.

Similarly, some desktop computers in places like call centers and factory floors only run very stable and small sets of applications. Locking them down to run provides protection both from malware and employees loading unauthorized software or stealing data.

In both this use case and OS lockdown you will get little to no pushback from employees about their inability to load software. Nothing in their job description indicates they should be loading software or accessing anything but the applications they need to do their jobs. In these scenarios application control is an excellent fit.

Servers

Another clear use case for application control is on server devices. Servers tend to be dedicated to a handful of functions, so they can be locked down to those specific applications. Servers don’t call the Help Desk to request access to iTunes, and admins can be expected to understand and navigate the validation process when they have a legitimate need for new software. Locking down servers can work very well – especially appealing because servers, as the repository of most sensitive data, are the ultimate target of most attacks.

General Purpose Devices

There has always been a desire to lock down general-purpose devices, which are among the most frequently compromised. Those employees keep clicking stuff, and are notoriously hard to control. Theoretically, if you could stop unauthorized code from running on these devices, you could protect employees from themselves. As our last post mentioned, end users push back against this because sometimes they legitimately need to install additional software. People get grumpy if they can’t do their jobs.

Application control does have a role on general-purpose desktops – so long as there is sufficient flexibility for allow knowledge workers to load legitimate software. In most cases the application control software allows a grace period of a few hours to a day or so to run new application before it needs to be explicitly authorized by a manager or IT person. There are other situations where application control’s trust model is more flexible – such as authorized software distributions, authorized publishers, and trusted users.

Of course flexible trust introduces a window of vulnerability for new malware. Reducing application control’s very strong security model can enable employees to load software to get their jobs done, but this is a tricky trade-off which requires careful consideration. A good balance can make application control viable in situations where it would be a non-starter, and we see many organizations deploying application control successfully. But be sure you have other controls in place – such as network security monitoring and malware callback detection – to identify compromised devices where application control isn’t enough.

Application Control Selection Criteria

Now that you have an idea of the key use cases for application control, let’s spend a little time highlighting some of the key features to look for in products implementing this security model.

1. Library of Executables: If the application control product doesn’t know about your applications it takes considerable work to get the system set up. So a large and current application library is critical to scaling the technology. You want the library updated in a timely fashion, especially for patches and updates. Keep in mind that application control won’t recognize an updated version of a program until it is explicitly added.
2. Flexible trust model: Speaking specifically of patches, you should be able to define certain software publishers whose code can run on your devices. That way, as long as code is properly signed by a trusted software vendor, it will run without explicit authorization. Similarly, you should be able to define trusted software distribution products that automatically install products, trusted directories where applications can be found, and perhaps even specific users who can install software. Each trust is a security trade-off, but they make the technology much more workable at scale.
3. Policy setup: The product should be able to monitor which applications are used on managed devices and build a baseline for the environment. This baseline can be used to quickly define which applications are legitimate and which are not, for a good first cut at your policy base.
4. Easy to manage policies: The most resource-intensive aspect of deploying application control is keeping policies up to date. So you want an easy-to-use system for defining what is authorized and what is blocked for groups of users.
5. Flexible enforcement: You should have flexible options to run the software with an alert to the IT group, allow users to run the application with a grace period before it needs to be authorized, and simply block execution. Policies should be able to take into account device type, user, and group, to support implement controls that support your organization’s requirements.

The good news is that application control technology has been on the market for quite a few years, and a number of offerings that can provide all these capabilities. One other aspect to consider is leveraging other technologies already in place. For instance if you add application control as part of an endpoint protection or management suite, you can leverage the agents already on devices to simplify management and policy maintenance.

To wrap up this short series: application control can be useful – particularly for stopping advanced attackers and when operating systems are no longer supported. There are trade-offs as with any security control, but with proper planning and selection of which use cases to address, application control resists device compromise and protects enterprise data.