Advance Directives for Windows XP: Are you betting your HIPAA and PCI compliance if you aren’t off XP by April 8th?


By now anyone in IT has been bombarded ad nauseam for the last 18 months with news of the impending Windows XP End of Life date of April 8, 2014.  One would think that with all of this recent hype that most organizations have heeded the warnings and those who had would be a lot farther along than many of them are in addressing the issue.  Perhaps it’s desensitization from the constant barrage of marketing campaigns from vendors trying to sell “migration solutions”, a cost/complexity issue for internal development, or even just apathy (the “What do I care, I have in-house guys who will support XP and we haven’t logged a ticket with Microsoft in years for desktop support – it will just run until we are ready to switch to Win7/Windows 8.1/Mobile/DaaS” mentality).  Whatever the reason, as of December 2013, it is estimated that fully 20-30% of all Windows desktops in business are still running Windows XP (a shocking percentage of those may even still be running the well out-of-support SP2, from my own personal experience).  For those who have already migrated from Windows XP, or at least have begun to execute their strategy in that direction, you’re on the right track, but doesn’t mean that you won’t be affected by the many who have not.

Who’s Still Running XP?

If it were just a handful of home PC’s or even SMB users that were still lingering on XP, the situation wouldn’t be nearly as dire as what we may be facing now.  XP is still very prevalent in many enterprises, in nearly every vertical.  Where it is continuing to linger as a matter of necessity, due to the cost, complexity, and effort to migrate from it is significant – particularly in highly regulated, high-uptime installations such as healthcare, financial, retail, and manufacturing/supply chain.  I was at a major big box retailer last week and noticed that a couple of the self-service check-out kiosks that were closed were in service mode and were boldly emblazoned with the Windows XP splash screen and desktop as they were being rebooted.  Many ATM’s around the country are also still Windows XP-based.  I know of a couple major banks and credit unions that still run XP on their branch PC’s.  Healthcare is no different.  Notoriously risk averse and often slower to make major changes in technology, many healthcare practices/providers and hospitals still manage a significant number of XP desktops – some estimates put the percentage of XP’s install share in healthcare between 35-55%, obviously with some outliers running much higher.  In the case of both finance/retail/commercial and healthcare verticals, there are the two major compliance frameworks that govern how organizations must secure and certify their computing resources:  PCI (PCI-DSS v2.0), and HIPAA.

What are the Real Risks to PCI and HIPAA Governed Organizations?

Let’s clarify exactly what the Windows XP EOL event means.  April 8th, 2014 signifies the end of life milestone in the Windows XP product life cycle, what that officially translates to is the end of extended support.  Windows XP SP3 has been out of mainstream (standard) support for five years already – having ended mainstream support on April 14, 2009.  Organizations have since had the option to buy extended support contracts with Microsoft which included security support entitlements, bug fixes, and the ability to pay for support per incident with Microsoft Technical Support.  The April 8th date signifies the end of the extended support phase, literally the “end of life” of the product.  After that date, Microsoft effectively ends all formal engineering and development of the product – no more patches, hotfixes, service releases, or security fixes, which is the crux of the concern for both PCI and HIPAA.  Let’s look at how the EOL event affects these:

PCI:  The PCI DSS 2.0 standard which is now in effect for the payment card industry is going to challenge retailers, ATM providers, anyone who deals with point-of-sale systems or software that manages PCI transactions (customer service, eCommerce vendors, financial institutions, etc.).  Technically, merchants should not continue to use payment applications based on an end-of-life operating system, per PCI-DSS Requirement 6.1.  XP systems will no longer receive security updates, which leaves them potentially vulnerable to attack.  Given the relative lull in major OS breaches lately, I wonder if hackers are holding their latest warez for a post-April 8th field day on unpatched, unsupported XP systems.  Unfortunately, for the large base of installed XP-based integrated POS retail systems that consumers run their cards through on a daily basis, those systems are much harder to just do a rip and replace upgrade.  Self serve check-out kiosks, ATM’s, gas pumps, etc. all are examples of PCI-governed devices that could cause huge headaches if they’re still running XP today without a plan to upgrade or replace them after the end-of-life deadline.  Many of these units are standalone (not centrally managed), making the upgrade process a high-touch difficult, disruptive, and time-consuming one even when there is a plan to migrate the systems to Windows 7 or another PCI compliant OS.


HIPAA covered entities (which include the vast group of healthcare providers, their partners and vendors that have signed BAA’s, and anyone else that’s potentially culpable if patient data is insecure) are similarly on the hook, and at risk with the XP end-of-life date in less than two months.  There is debate on whether the mere presence of a HIPAA covered PC running XP after April 8th is out of compliance – I’m no lawyer, and I’m certainly not going to attempt to make a definitive legal statement on the interpretation of HIPAA law and the various rules.  By definition of the Security Rule section 164.308(a)(5)(ii)(B) which has the mandate for systems to be guarded from malicious software, it could be interpreted that, because of the cessation of any security patches, hotfixes, or updates from the vendor (Microsoft), the operating system itself could be considered to be impossible to be in compliance after April 8th.  That has been proven to be enough of an argument for many healthcare software vendors, who have pulled support for their products running on XP after the EOL date.  Whether it’s actually a violation or not, seems like an increasing amount of covered entities don’t want to assume the risk of HIPAA non-compliance or worse, an real breach or incident should there be a post-EOL vulnerability that is exploited. There are many security journals and analysts who have noted that many hackers may be holding zero-day exploits for after April 8th.  Like I’ve mentioned, it’s no secret to anyone who’s read an IT journal or who has seen an out-of-service ATM, kiosk, exam room workstation, or retail POS system in the last year that’s clearly running on XP – the bad guys know that these targets, as well as the vast number of home and office PC’s that still run XP give a large, ripe, attack surface after Microsoft is under no obligation to publish fixes for them.  This affects Meaningful Use attestations as well.  Even if an entity has already achieved MU Stage 1, they still have to do all the security reviews for again for MU Stage 2.  Without being able to attest to HIPAA compliance with XP still on the network after April 8th, there is the very real risk of delaying or even denying attestation (and thus forgoing reimbursements) of Meaningful Use Stage 2.  So now we’re talking financial impacts of delayed Stage 2 compliance.  In the same vein, the last risk I’ll mention is the obvious one of the financial losses that could potentially occur due to HIPAA violations if (God forbid) there is a breach due to continuing to run non-compliant systems.  It’s well-known that the penalties could potentially run well into the millions of dollars – that should elevate this issue to a high priority for any entity who’s still needing to get vulnerable machines off of XP.

The Fix…

Luckily, this is a problem with many known solutions.  As I said however, they’re not free nor without significant effort and complexity.  Keep in mind that with a good number of these solutions, unless you’ve got deep pockets you’re already way behind, and probably will be almost impossible to get them implemented prior to the April 8 deadline.  What we’re talking about at this point is getting a strategy down for those who haven’t got one yet, and what it takes to execute them and mitigate the risk as soon as possible after April 8th.   Let’s take a look at what’s on the table for mitigation as Windows XP utters its death rattle in the few remaining weeks of its product life cycle.

  1. Migration to Windows 7:  This may seem like the easiest option, but often organizations find that it is anything but easy when it comes to execution of this strategy even in smaller environments.  Remember that even home users have trouble moving from XP to Windows 7 (or 8.x) – there are considerations for personalization and user profile content and settings, application compatibility, hardware/peripheral compatibility, migration of endpoint local data, etc.  These issues magnify and compound at scale.  Keep in mind also that some XP based machines may not have adequate hardware to run Windows 7.  Some machines won’t meet the requirements at all, others may be able to install it but will run much slower with Win7.  Some organizations have opted to accelerate PC refreshes to solve for the hardware compatibility problems, buying new workstations or laptops with Windows 7 or better pre-installed (or building custom Win7 images and installing on new hardware). All of these are important considerations for those thinking they may want to migrate existing systems to Windows 7 as their Windows XP exit strategy.
  2. Application and/or Desktop Virtualization:  Where some may find it too impractical or not financially feasible to do full-scale hardware/OS refreshes, application and/or desktop virtualization may be an easier mitigation strategy.  Separating applications from the underlying operating system (XP or Windows Server 2003 in this instance) using application virtualization technologies such as App-V or ThinApp can be a practical option, allowing these apps to continue on either running locally or from a server-based compute solution like Citrix XenApp, as the endpoint is uplifted to Windows 7.  There are many caveats, specific expertise and significant effort required, and not every application can be virtualized, so this approach must be used with caution and careful evaluation of the application and desktop environment.  The other side of the coin would be virtualizing the desktop computing environment itself – delivering Windows 7 desktops to users that they can access remotely, that are in compliance, and that are more secure as they are running in the datacenter.  On paper it’s a very viable method for getting off of Windows XP, but there are likewise many challenges and complexities that must be evaluated and planned for to use this as a solution.   It also comes at a cost, due to the complexity and planning that must be done to take an in-house desktop virtualization effort on at scale.  At this stage in the game, I’d say that anyone considering this is about a year too late and many dollars short to pull that off as a short-term fix.  Unless you consider a Desktop-as-a-Service solution (hosted virtual desktops from a cloud service provider).  This option of outsourcing your whole desktop solution can present other problems with HIPAA compliance unless you plan for it properly (or use one of the providers that is already HIPAA certified and will sign a BAA) – keep in mind this doesn’t absolve you of any planning around how users will connect, how applications will be maintained and delivered, how it will integrate with other data services (such as HL7, billing/insurance, etc.) and how you will continue to manage, monitor, and maintain the entire solution if you move it all out of your own datacenters.  But it is a means by which some HIPAA and PCI problems are being solved by some organizations.
  3. Managing Other Software:  The move off of Windows XP alone as I’ve suggested isn’t without cost or it’s own set of problems and challenges.  The other component that must be considered is the applications themselves that run on top of XP or whatever OS you decide to migrate to.  I’ve talked a lot about XP, but there’s another Microsoft product going EOL this year that could put organizations in the same boat – Office 2003.  I have this version on a couple of older PC’s in my own lab (intentionally, for application compatibility testing and mitigation solution development) and have observed issues with older versions of Office and other 3rd party software as new versions come out.  Bear in mind that large software vendors (such as those who sold you the ERP, Financial, or EHR/HIS systems that we’re focusing on in this post) build their software using a lot of these 3rd party components and integration points (Crystal Reports, Java, .NET, PowerBuilder, etc.).  If you are running versions of this that were built for Windows XP, there is no guarantee that it will continue to work in Windows 7, which is a completely different code base than Windows XP.  The importance of cataloging all of your applications and their versions, identifying which of them are either known to be incompatible or their compatibility unknown with the operating system you plan to migrate to (Windows 7 – x86 or x64 version), and how you plan to triage and mitigate any incompatibility you find is of tantamount importance.  One other option would be to also consider getting those applications off of the desktops and into the datacenter, a la Citrix XenApp.  There may be a decent chance that the software you have running on an XP desktop could be run on a Windows 2008 server (32-bit version, if need be), and then delivered to end users via XenApp, which is secure and proven to help with PCI and HIPAA compliance (as well as MU for healthcare).  You also position yourself better for future situations like this by centralizing the management and maintenance of those applications so that mitigation isn’t a desktop-to-desktop hands-on technical effort.  The gains in flexibility and centralized management can reduce overall cost, and has other benefits as well such as remote access, easier software update and distribution, and better software license management/compliance).  Finally, as was suggested for desktops, perhaps replacing incompatible software could better be done through a web or SaaS version.  Where possible to do so, that can be an even better, cheaper, and easier option in some cases than procuring the traditional shrink-wrap version while providing the same benefits as deploying centrally via XenApp or virtual desktop images.

Fortunately, there are many experts and companies out there with the expertise to help make any or all of the above happen, for a fee.  The question now is not can you afford to do it all, but can you afford NOT to?  At this stage, I’d say getting it done in time if you haven’t started will be nearly impossible if you have more than 50 PC’s and a dozen applications to manage (unless you have a lot of disposable income and/or a large IT budget that can be allocated towards professional services and hardware/software).  But doing nothing isn’t an option for those bound to PCI and HIPAA/HITECH compliance.  After XP goes end of life, if you are one of these organizations that still has XP nodes running on your network, you could be quite literally betting it all.  IF you’re not done by now, you’re definitely going to incur significant risk, but it is still best to double down on getting a strategy in place, or if you already have one, working hard towards getting it finished.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s