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 cramp their style.
In this post, we’ll look at how application control is one of the best defenses against security threats on XP and more.
Windows XP security updates officially ended April 2014, at which point, organizations still using XP were out of luck (as if 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. That is a legitimate question with two very reasonable answers.
1. Legacy applications
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.
2. Compliance requirements
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.
The solution: application control
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.
- Kiosks, ATMs, and other fixed-function devices
Another use case we see frequently is fixed function devices, such as kiosks running embedded operating systems. Think ATM or payment station, where you never see the underlying operating system. These devices only run a select few applications built specifically for them.
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 is appropriate on kiosks.
- Computer labs, libraries, call centers, etc.
Similarly, some desktop computers in places like call centers and factory floors only run very stable and small sets of applications. Locking them down provides protection both from malware and employees loading unauthorized software or stealing data.
In both these use cases, you will get little to no pushback from employees about their inability to install and run arbitrary software. Nothing in their job description indicates they should be loading software or accessing anything but the applications they need to do their jobs.
So in these scenarios, application control is an excellent fit.
- Server devices
Another clear use case for application control is 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 since 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. 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 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 a 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 needs to be more flexible to meet the realities of enterprise use — such as permitting authorized software distribution products, authorized publishers, and trusted users to install and run software.
Loosening application control’s trust model introduces a window of vulnerability for new malware to compromise devices. This enables employees to run new software to get their jobs done, but presents a tricky trade-off which requires careful balancing. Many organizations deploy application control successfully this way, but be sure you have other controls in place — such as network security monitoring and malware callback detection — to identify compromised devices when application control isn’t tight enough.