Thursday, May 1, 2014

Keeping XP secure as Microsoft's support slowly ceases

Today, Microsoft released a patch fixing a potentially serious (although some at Microsoft have called it "overblown") security bug that allowed for remote code execution through Internet Explorer 6 through 11. In their initial advisory for the issue, they listed affected Windows versions without mentioning XP. With this patch, they've apparently decided that it's important to patch XP too for this one. But rather than cause for celebration for XP users, this should be one last wake-up call; coming mere weeks after XP was dropped from support, Microsoft decided to patch through this time, but they're making no promises that there'll be a next time.

Here at GMCL, most of our physical XP machines have been retired, and we do most of our testing for it in hardware-accelerated virtual machines (which combines running a 'real' install with the ability to quickly snapshot and revert as desired). But a few machines still linger for one reason or another, so how do we approach maintaining them? Well, here's a few thoughts on the subject that I've arrived at, which I think apply generally:

  • Don't delay on upgrading: Obvious, but deserves stating first. Practical realities may make it seem too difficult, and one might imagine oneself to be secure, but even if XP was very amenable to being secured (and, in many folks' opions including mine, it really isn't), it's going to be an increasingly huge target. And even if you have an air gap in theory, in practice air gaps are nearly impossible to fully maintain; as Paul Ferguson of Trend Micro wrote in his white paper "Toward a More Secure Posture for Industrial Control System Networks", in "practical and operational terms...physically separating networks is not functionally nor operationally feasible in the real world." So for any systems still running XP, it should not be if you upgrade or replace them, but when.

  • Drop IE for Chrome or Firefox, wherever and whenever possible: Microsoft's policy for Internet Explorer updates is to tie them to support for the OS version in question, so while Internet Explorer versions for Server 2003 and 2003 R2 will continue to get updates until 2015-07-13, those that shipped with XP aren't officially guaranteed to recieve any more updates after April 8th---as Microsoft representatives have explicitly stated, today's update is "an exception". But Google's Chrome browser and the Mozilla Foundation's Firefox both will support Windows XP, and thus provide security updates on it, past the April 8th drop-dead date. Google is intending to update Chrome for Windows XP until at least April 2015, and Mozilla currently has no plans to discontinue support. Both browsers have proven in the past to be more secure out-of-the-box than Internet Explorer, and although contemporary versions of IE have significantly improved in this area (and many others), those versions won't run on XP anyways.

    You may well have internal sites or systems that rely on the older IE versions (especially if they involve ActiveX controls), but considering the web browser is perhaps the primary vector of infection, it is worth seriously evaluating the possibility of migration, and at very least using IE only in the specific instances you need to. In fact, for Google Chrome there is an official extension that can be installed on managed Chrome installations which allows you to specify automatic switching between IE and Chrome based on listed sites, thus allowing you to cordon off only specific internal sites to be browsed with IE.

  • Enabling Internet Explorer's Enhanced Security Configuration: To the degree that ditching Internet Explorer isn't an option (or that you truly prefer it as a browser), there's always the Enhanced Security Configuration. This is enabled by default on all versions of Windows Server, and can be enabled (piece by piece) on Windows XP. It beefs up security at the expense of some convenience--in fact, we've even run into some small bugs with the DBDOC Error Browser when ESC is enabled (relating to copy/paste). In this case, especially when XP is concerned, the convenience traded off seems potentially worth the added security, but that is indeed the classic dilemma.

  • Using the Enhanced Mitigation Experience Toolkit: Microsoft's EMET is a tool that hardens applications by preventing the kinds of behaviours and faults that are often exploited by malware. As such, it's quite useful for preventing unknown or unpatched vulnerabilities from being exploited. It's enabled per-application, so you can be granular and choosy with this one.

  • Uninstall anything you don't use: The converse of using the EMET to harden applications is to make sure any you don't actually need aren't there to be exploited. Alongside the news of the recent IE exploit, there's also an Adobe Flash exploit recently discovered in the wild. Many XP machines may have components like Flash and Java installed that they don't actually need for daily operations, and the machines in question will be safer without the additional attack surfaces lying in eager wait.

  • For anyone out there, what are your thoughts? Are you already working to upgrade? Is it out of your hands? Do you have any other suggestions for keeping XP as secure as possible as it sails well past its best-before date?

    2 comments:

    1. I live in the real world unfortunately. While it is not even remotely defense in depth we have physically separated our industrial controls networks and this is both functionally and operationally feasible for us at the moment. Our IT PCs have all migrated to Windows 7 but our control systems are sitting unpatched and in isolation with obsolete software and obsolete operating systems. Our only links out to the IT network is through our serial CIUs that connect to DBDOC Live Data PCs and PI ProcessBook API PCs. Our Industrial Control System is vulnerable primarily through our enabled USB ports on our servers and EWS PCs. Geoff has said many a time the there is no vulnerability with our serial connections out of the Bailey DCS. It would be nice to change our control systems to later software and hardware with supported OSs but that will only happen sporadically as total failure and hardware availability/reliability become significant factors. In the meantime we work with what we have and in the best way we know how.

      ReplyDelete
    2. Thanks, Andrew.

      For some, the watchwords will be “Eternal vigilance is the price of liberty”

      http://www.thisdayinquotes.com/2011/01/eternal-vigilance-is-price-of-liberty.html

      I have been impressed by the few sites I have encountered that had state of the art USB, CD and DVD checking, where the device had to be vetted by security software before even being read by a trusted computer. Then, only the client devices were allowed further into the system, but they could bring files in, hopefully securely.

      ReplyDelete