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:
- 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.
- 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.
- Application variability: Consider what kind of applications run on the device, as well as how often they change and are updated.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Reader interactions
One Reply to “Reducing Attack Surface with Application Control: Use Cases and Selection Criteria”
Hi
Read your article with great interest. As the Product Manager for AppSense Application Manager, this is an area close to my heart. Your blog is excellent at highlighting a number of the techniques in use in this space, but I would like to add a few others, if I may.
Flexible Trust Models can also revolve around the concept of Trusted Ownership- that is leveraging base capabilities in the NTFS file system that distinguish the Owner from the Permissions on a file. For example, when you cleanly install Windows, all critical system files are owned by the TrustedInstaller account. IF I were to copy a file- let’s say Notepad.exe to my Desktop- the copy of Notepad.exe would have a different owner (my user account) to the original Notepad.exe (owned by TrustedInstaller). Software that can flex on that inherent security mechanism, of which AppSense Application Manager is unique in doing so, can allow files based on who owns them- so in the scenario above, I could allow any file owned by TrustedInstaller, but block any executable owned by a standard user- so my rogue copy of Notepad.exe would fail to run. This is a particularly powerful tool because once you fundamentally alter a file- rename the file, etc. – you automatically change the Ownership, so malware can’t masquerade as file that looks like it should be there, and is therefore blocked.
So this allows the power of a whitelist, with the low maintenance overhead of a blacklist. I can create Gold Images, deliver applications to those desktops, and keep a tight circle of trust over who are Trusted Owners, For example, applications installed by SCCM would be owned by the Agent or SYSTEM account, which can be added to the list of Trusted Owners. This means I do not have to build a huge library of executables to retain control. It also has the marked advantage over Crowdsourcing for Trust in that it cannot be ‘gamed’- the Trusted Owners are unique to your corporation, and no amount of ballot stuffing to a Cloud platform by those with more malicious motives will circumvent the mechanism.
This mechanism is highly effective against malicious payloads on the endpoint. In fact, as we recently showed, entities like Cryptolocker that do not exploit 0-day holes or require Administrative elevation to cause systemic damage are blocked outright with this system. This is particularly useful for our customers who are having to extend XP lifecycles. It provides an additional security layer of prevention, rather than solely relying on anti-virus and security updates to ensure these devices do not pose a risk to the larger corporate environment.
Additionally, for those who want further protection- especially of their Server assets providing Edge access- you can resort to file signatures: literally creating the gold image and getting a Hash of every file on the box. If the file is altered in any way, the Hash no longer matches- breaking the hash doesn’t achieve anything other than giving you file telemetry, so it allows absolute whitelist authority, while eliminating the problem of users introducing software not approved by the corporation onto the endpoint.
Mike, you know this area very well and I would also reiterate caution around isolation and sandboxing technologies. We are quite experienced at building them at AppSense, and while sandboxes can help spread risk by isolating applications from each other, it is a false tautology to believe that all applications run in an environment carry the same risk if penetrated.
For example, I am much more concerned if my Internet Explorer session to Salesforce.com is compromised than if Calc.exe is. It’s heartening to know that a penetration of Calc.exe will not leave my Salesforce session open, but the reality is that web browsers are the most commonly attacked applications because they have the highest attack surface area. To compound that problem, more and more critical applications are moving into web browsers, so compartmentalizing my applications and not providing prevention of attack actually does not reduce the risk I face.
The exploitation of the base OS bugs is certainly negated by the emergence of the next generation isolation technologies,- but the majority of the daily damage done does not exploit these areas. Instead it exploits the humans behind the keyboard, and the applications they use because they are easier to target and deliver a payload onto.