The much-heralded XPocalypse—the end of extended support for Windows XP—is practically upon us. After thirteen years of service—beyond Microsoft’s normal service window by a good three years—Windows XP patching will finally stop. How will this affect those of us whose virtualized desktop infrastructures may still be tied, for various reasons, to the old OS?
It is clear that the “Internet bad guys” have been stockpiling XP vulnerabilities for this moment. These vulnerabilities will now be more valuable, whether used for sale or direct exploit. With 20% of the world’s PCs—possibly around 200 million endpoints—still running Windows XP, that is a vast army of zombies just waiting for activation.
Of course, you could pay for support from Microsoft, but the costs—$200 per device for the first year and increasing exponentially in the second and third years—don’t make sense to any but the largest customers. Smaller environments with applications that are tied to Windows XP, for a variety of reasons, are stuck between a rock and a hard place. Is there anything they can do to protect themselves against the security vulnerabilities if they are unable to migrate away from XP?
The first and foremost answer is to remove these systems from Internet access. Security vulnerabilities come from external sources, as a rule, so preventing the XP systems from getting on the Internet is a good first step.
Of course, there is always the chance that removable media are involved. Disallowing the use of USB flash drives, DVDs, and other removable media on these vulnerable systems is now paramount. Whilst there are GPOs and third-party software that can enforce this policy, if removable media are not required, perhaps the best idea is simply to physically disable the hardware that these devices use.
If you must connect XP to the Internet, then some sort of web filtering is absolutely necessary, but be warned that it is going to be very hard to keep an Internet-connected XP machine safe.
Whilst you can no longer patch the underlying OS, it makes sense to patch everything else you possibly can. The browser, Java, Adobe Reader, all other software—keeping these up-to-date will reduce your exposure as much as possible. Tools such as Secunia PSI can help greatly with ensuring that all other software is as up-to-date as humanly possible.
XP machines could be virtualized inside other clients (even nested inside virtual ones) and from there segmented into further virtual networks, protecting them from exposure. Windows 8 now offers client-side virtualization for free with Hyper-V (provided your hardware supports it). VMware Workstation and XenServer, amongst many others, can also provide these features.
Additionally, there are ways to make virtual or physical hard disks read-only; technology such as Citrix Provisioning Services can ensure that changes to the OS are dropped at logoff. Whilst possibly more expensive, these technologies can provide an extra layer of security for any high-risk XP systems.
It goes without saying that any remaining XP systems should have fully up-to-date security software. Antivirus, ingress/egress firewall, HIPS, rootkit detectors, and any other available security software should be installed and configured in as active a manner as possible.
All unneeded software should be removed from the vulnerable systems. Additionally, system services should be verified and unnecessary services disabled. Reducing the attack surface of the XP systems should be done to the extent possible without affecting the required applications.
No user on the remaining XP systems should run with administrative rights. If an administrator does need to perform any maintenance, they should do so using Run As Different User where possible. Additionally, check for Scheduled Tasks and Windows services running under administrative credentials and change them to a lower privilege level.
In case the machine does get compromised, make sure you’ve got multiple good backups of the data or, better still, the entire disk image. Also make sure you have a “cold” backup that isn’t connected to the internal network—you can never rule out the attack of a piece of malware like CryptoLocker.
Without a doubt, the #1 way to avoid exploitation of XP security vulnerabilities after the end of support is to implement a robust application management strategy. Any vulnerability typically leads to damage via the execution of untrusted code. If you’ve whitelisted the applications that you know are good to run—particularly if you’ve done this via signature, publisher, or certificate—then you can be pretty sure that you are going to be safe from exploitation.
There are many pieces of software that can do this—AppSense Application Manager is one of the more popular and more feature-rich examples—but you can get by simply by using AppLocker or Software Restriction Policies within Active Directory. They take time to set up, and application analysis is key, but if these policies are correctly implemented you have gone a very long way towards securing your vulnerable machines as much as is humanly possible.
Of course, these mitigations can’t cover every eventuality. Whatever the reasons for continuing to use Windows XP, you should always be looking for a way to overcome the problems and eventually move to a supported platform. But in the “window of opportunity” for the bad guys between the end of support and the solution of your migration issues, these few pointers might just give you a fighting chance.
Share this Article:
Latest posts by James Rankin (see all)
- With the Arrival of Version 10.1, Where Is AppSense DesktopNow Going Now? - January 20, 2017
- Whatever Happened to App Refactoring? - December 22, 2016
- Anatomy of a Desktop Virtualization Project #3: PoCs and Pilots - July 8, 2015