Microsoft is going to end support for Windows XP SP3 April 8th 2014. A very well known fact, but with repercussions for XP systems still in use even now that are perhaps not appreciated.
The most obvious thing is that XP is not going to truly die; it is in more of a Zombie state and will continue as such long after Microsoft has stopped patching it. Despite comments from some, it is important to remember that Windows XP is a product from a kinder age and it is not possible to back-port the architectural changes seen first in Windows Vista (link), it has to go.
XP also comes with other problems, most obviously Internet Explorer (IE). For many going to IE6 was a significant jump in itself and has caused some development to enter an unfortunate technical cul-de-sac. Such dependence on historic browsers may not be as complete as some fear, but can be a default position from customer IT departments unwilling or unable to create a transition to something more defensible.
Weak XP systems are also likely to be running on old hardware, with their own problems, such as running out of disk space. It would not be unreasonable to expect that other security controls such as local antivirus are also at old versions. These systems are also likely to be running an old version of MS Office. I’ve seen examples going back to Office 97. These are end of life, or going out of life and will not run on later versions of Windows.
MS-Office also provides a very easily accessible attack surface, as good or better than the O/S itself as it is easier to exploit by Email. The threat from old systems must not stop at consideration of just the operating system but must also consider the browser and MS Office.
A recommended position
So, that’s easy, upgrade to Windows 7 and a new Office suite. Such an upgrade needs to integrate into patching, anti-malware, network security, reporting etc. This would bring the desktop O/S and Office under support but allow other security problems to be addressed in the rebuild such as local drive encryption etc.
So, what can we recommend if a customer can’t upgrade? Well, there are several direct technical issues and solutions discussed below. The problem of cost and upgrade disruption are largely beyond the discussion of this document but I hope looking at the major technical issues remains worth your time.
What to do about the browser problem?
One of the reasons given for not upgrading is the need to keep either IE6 or IE7 for some “internal reason.” So, what to do? First off, what is the extent of the problem, and how bad it is? For example, you might find yourself hearing an argument that an out of support browser is needed to connect to an out of support version of SharePoint, so an obvious if perhaps time consuming fix presents itself.
Assuming that the IE6/7 dependent systems can’t be removed immediately, the most interesting solution I have heard is to give users a second browser for Internet facing work and leave the deprecated version of IE as Intranet only. This means that the vulnerable browser is kept away from the big bad Internet, so reducing the attack surface to a much more manageable level and allows users to access online resources that are no longer interesting in supporting legacy browsers.
Probably the best browser for this purpose is Chrome, as Google have already stated they will keep updating the XP version into 2015 (link), and as such updates are automatic managing the second browser can be light touch proposition.
The difficult part is the browser isolation, but this can be managed by high quality proxy servers capable of distinguishing the browser version being used and preventing old versions of IE from accessing the Internet.
All the standard browser management techniques, such as IE settings in group policy, can also be set to make WWW access impractical via IE while allowing access to IE for local Intranet applications. There will be issues for users, and they will need to understand how to work with the “non default” browser correctly.
What to do about the browser plug-in problems
If the reason for not upgrading is legacy browser support we really need to consider legacy browser plugins. This is another problem that seems overstated by some IT functions but occasionally appears to be true. The free, make your browsing experience better – such as Adobe Flash, Shockwave, and MS-Silverlight are the most common cause of the pain. The second group are commercial and often expensive line of business applications that are more likely to cause real problems.
The free stuff needs to be challenged, sometimes line by line and item by item. Shockwave, Java, Air are all examples of items that weaken a system, often with little need to actually be installed at all. Where they have to stay, is it everywhere? Can modern versions or replacements be used to emulate the older version (Adobe reader for example.) Can the plugin be modified in some way to reduce the risk, for example unbind Java from the browser (certainly the Internet facing one.)
Where the problem are with high end commercial items that are not supported, and hard or impossible to replace a complex support issue results, but moving what is often a very small number of systems into a fully offline configuration is worth considering, leaving a user with two distinct compute instances.
Make sure that XP systems are not used as primary storage, even when in offline mode. The loss of these point solutions might have a very significant business impact.
What to do about the build image problem
As Zombie XP shuffles on it becomes more vulnerable, and more opportunistic infections will hit. So, in order to perform tasks like rebuild, VDI etc it becomes necessary to deploy the build fully hardened immediately, you won’t be able to have a base build of XPsp3 and then harden it later. This build image will probably need its applications, antivirus and system hardening settings updated often, and subjected to frequent testing.
What do we do about the anti-malware problem
For the time being there are many antivirus vendors who will supply and support high quality products to defend XP. My personal view is that this will continue as long as there is a large deployed base. We are just beginning to see the major manufacturers drop support for Window 2000 after all. So, this is one of the lesser problems. But, we are now relying on the antivirus to do much more work, so we need to include a full suite of technology including personal firewall, HIPS, download control etc. AV needs to be set more aggressively, and updates performed more rapidly. Engine updates become much more important; keep an eye for any vulnerabilities in the AV itself and make sure they are corrected quickly.
You may also consider something a bit more radical, for example using tools designed to oppose advanced persistent threat, or APT to further harden the system. Also monitor system, networks and traffic for evidence of malware (link.)
Beyond anti-malware is full on application control and application white listing. Though these will only work on well managed systems, and well managed systems probably wouldn’t have this problem in the first place.
What to do about the patching problem?
You can’t patch the XP any more, simple? But, you can patch many applications. It is also possible to reduce the attack surface by upgrading those applications. For example upgrade MS-Office which you can continue to patch. Also, Microsoft patch Tuesday needs to feed into your vulnerability lifecycle management as hackers are going to be reverse engineering patches for IE, Vista SP2 and Office 2007 to find exploitable vulnerabilities that appear in the common code bases.
What to do about old hardware
It has been a very long time since a general desktop hardware refresh has been necessary. Many systems purchased for Windows 2000 deployments are perfectly capable of running Windows XP. Though 15 year old PC’s are pretty rare, there will be many that are incapable of re-use. Even hardware only a few years old, and more so peripherals might not be expected to work beyond XP. It seems unlikely that anyone will find it helpful to make a case for staying on XP just because of the hardware costs, even for traditional desktop rollouts. The advantages in usability and performance are likely to be self evident. Perhaps more thought might go in the need for that hardware to support versions of Windows that will ultimately replace Windows 7.
There is so much written on general security practice but poor change management, local working practices and just general neglect weakens them over time, these can be restored and have very useful security outcomes, a few to start with:
- Shutdown anonymous shares, force credentialed connections
- Block LM authentication, many systems are still set to use weak authentication
- Check and enforce good password policies
- Remove unused accounts both locally and domain
- start logging properly, particularly at gateways, and read them occasionally
- Add robust device control, in particular block execute rights from removable media
- Stop using XP workstations for storage
- Control Internet access, inbound and outbound and make sure that the basic controls are mandatory
Remove the biggest threat, the Internet. If people really need to access internal applications then get them to do it from a different system than their general workstation. This can be either by creating a local virtual machine (Windows 7 can support its own) or perhaps VMware workstation. The XP physical machine can be ported to virtualisation. There are many possibilities where XP really has to stay for an extended period of time, just keep it away from the threats.
The best plan
The best plan is to have a plan, make sure risk, business impact, compliance and user acceptance are all part of the plan and allow XP to finally retire to the history books.