Migrating from XP to 7 offers organizations a good moment to re-assess their security setup. But where to start?
After nearly 13 years, Tuesday 8 April is the day Windows XP reaches the end of the road as Microsoft pulls extended support. Anyone still running XP after that day will be on their own and left exposed to an inevitable wave of malware attacks lured by the pickings to be had from millions of PCs running an unpatched operating system.
It’s unprecedented for an operating system to remain mainstream for so long and painful for its maker to leave customers to sink or swim, but it happened because too many hung on to XP for a mixture of cost and application compatibility reasons.
Older applications worked well enough but needed admin privileges that were more strictly regulated by the later Windows 7 using User Account Control (UAC). Pragmatically, many organizations decided to upgrade departments to newer versions over time, leaving a few users here and there using the less secure XP simply to keep legacy systems ticking over.
But set aside the initial migration hassle and XP’s demise is actually fantastically good news for every organization. Windows XP was hugely insecure and getting rid of it is a necessary rationalization but it shouldn’t stop there; its demise is a golden opportunity to carry out a more fundamental review of the way their desktop environment impacts on security.
Where should organizations start?
The first stage is to grasp that the remaining PCs and their users represent an unquantifiable security risk that can and should be managed using the principle of least privilege. The easiest way to do this is to impose a regime of privilege management rather than simply relying on Windows' own UAC. Migrating from XP makes this easier but doesn't, of course, remove all of the complexity.
It is important therefore that such a regime is planned carefully after a management-level discussion of the concrete benefits for security, compliance, improved user management and productivity and, ultimately, lower costs.
1. Stage one is to conduct an audit of the current state of admin rights in an organization, modelling not only who has admin privileges but what they are used for. Privilege management software, such as that provided by Avecto’s Defendpoint, comes with tools to help with this but time must be taken to ensure the application and departmental dependencies have been understood.
2. Because the security team will find itself managing requests for privilege elevation during the bedding-in period, a consistent policy must be developed on how they should be applied. Best practice is to keep the number and scope of privileges to an absolute minimum – maximum security in other words - but this can be complex in some organizations.
3. The effect of removing privileges on the applications themselves should also be assessed with changes to their design recommended from in-house developers or application vendors. Some won’t prove easy to accommodate and their life expectancy should be considered.
4. Avecto recommends that the next stage should be one of communication and education; explain to a workforce how privileges will be managed in future and how and why high-level admin privileges will be granted on a time-limited and need-to-have basis. It is worth emphasizing that this principle will apply to everyone (including the admins themselves) as well as itemizing user-installed applications that will and won’t be allowed.
5. Depending on the extent to which least privilege and privilege management is already being used by an organization, it is worth considering a pilot phase to test out the policies and technical model. This might allow for fine-tuning of UAC messages that users will encounter so they can be understood by the workforce, as well as the creation of application whitelists.
6. Least privilege and privilege management can be a strain for an organization in ways that go far beyond the technical demands involved in its implementation. These tensions can too easily become invisible and potentially corrosive. For this reason, both during the pilot and later roll-out, a feedback process must be put in place. This isn’t simply a way for users to vent but must be taken seriously. Without the buy-in of users a lot of time will be wasted or productivity lost.
7. Following on from this, an audit should be implemented using a reporting mechanism that records how users have been interacting with the new regime. How much detail this shows and which detail is relevant is down to the individual organization. Without an assessment stage, fine tweaks will be difficult.
What about organizations still in mid-migration from XP or that find themselves consciously hanging on to it after the end of life deadline? There are a number of options, none of which actually rules out a more general migration to a least privilege setup happening at the same time.
The simplest solution is isolation, putting XP systems in a more secure part of the network, and although this isn’t easy it might prove necessary for a period of time. A second option is to exploit the XP mode of Windows 7 to run XP applications from inside a more secure system, though because this doesn’t scale well, organizations might also need to fully virtualize XP.
