Our Thinking

Will the (XP) World End on April 8?

Posted by Steve Levinson on Mar 19, 2014 3:50:33 PM

As most folks know, Microsoft’s flagship operating system, Windows XP, is going end-of-life as of April 8. Given the fact that about one out of every three computers runs this OS, there may be some strong ramifications for those who opt for the “do nothing” alternative. If you are running this operating system, you may not be vulnerable the day that it goes end-of-life, but as soon as there is a known vulnerability and if you HAVEN’T done anything to address it, most people (and most likely a jury if you were to find yourself trying to explain your inactions to one) would find you negligent in exercising your due diligence to adequately address these issues.

Now, while keeping current Microsoft patches of any flavor of Windows is not going to prevent Bad Things from happening to your organization, they at least contribute to defense in-depth; and any prudent organization ought to be exercising a vigorous vulnerability management program.

Home users: If you are an individual who happens to have XP running on your home system or your laptop, and IF you happen to use the Internet, then you ought to upgrade or replace your system or expect to put your computer and data at tremendous risk.

Companies: If you are running XP at your organization, and you haven’t already migrated to a currently supported Windows operating system (Windows 7 or 8), you better have a good 11th hour plan to address this huge issue. The viable mitigation strategies are:

  • Upgrade your operating system on your computer: Microsoft provides guidance pertaining to the ideal upgrade path. In addition to spending the money, time, and effort to perform the upgrade, you will need to verify that all of your applications work on the new platform. Depending on the number of applications and how interwoven they are to XP, you may have your hands full with regression testing. And don’t forget, you will also need to create a secure build standard for whichever operating system you’ve selected. This means that you will need to change default settings (which of course you are doing, right?); you will need to determine which services need to be enabled (while all others are disabled); and you will need to ensure that other settings such as logging, file integrity monitoring, anti-malware, etc. are documented to the extent that they are applicable. Of course, this option will most likely take you much longer than the three weeks you have before XP goes end-of-life, so if you have not already started down this path, it’s one that you should strategically consider, but look at other options to buy you time.
  • There IS life after end-of-life: At a cost, that is. Microsoft will be happy to provide premier support to your existing XP installation. This may be a viable option to buy you some time while you are working on a longer-term solution for your organization. If you are not going to have upgraded all of your critical systems by April 8, you may want to consider exploring this option sooner than later. Be prepared to shell out some drachmas for this.
  • Host-based intrusion prevention/whitelisting: I’ve often said that given a choice between a hardened system with current patches and a system that has strong HIPS/whitelisting implemented, I would select the latter as my secure computing platform. There are many off-the-shelf products that provide this functionality (such as Bit9, McAfee/Solidcore, and Symantec SEP), but it is rare to find an organization that has really ratcheted down the whitelisting capabilities. This may be a viable option for your organization if you already have a strong practice in place for using this technology. In the PCI world, this solution could be considered a compensating control (check PCI knowledgebase article #1130) for DSS requirements 6.1 and 6.2 – “lack of patching,” but ultimately, it will be … (drumroll please)… up to the QSA. If you opt to take this path, you need to:
    • Start with a good baseline configuration for the system, ensure all hardening is applied and, if possible, do not permit service and application accounts full administrative access to the operating system.
    • Ensure systems are locked down where an attacker cannot disable the HIPS and whitelisting application.
    • Ensure you have strong account management practices for the application (typically not integrated into the operating system).
    • Ensure you have strong central monitoring to provide alerts for suspicious activity. This should include real-time alerts if a box is up and if the HIPS/whitelisting agent is not running.
    • Keep in mind that a new baseline will need to be established and set when patching of applications, other than the operating system, is performed; this will cause additional administrative overhead.
    • Perform penetration testing to ensure that the HIPS solution is effective in preventing or alerting.

Where does your organization stand as it pertains to addressing this issue? Do you have any unnecessary exposure? Do you have a plan in place to mitigate these risks? Will your plan include the right amount of ongoing care and feeding to ensure that it remains viable over time? Even though it’s the 11th hour, it’s not too late to start.

 

Topics: Security

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates