Windows XP Sunset and the Great ATM BCP Debacle
Recently in the news there has been a brouhaha about ATM machines that may soon (as in 6 months from now!) stop working due to Microsoft’s decision to end support for its XP operating system. Now, rather than just pointing the finger at Redmond, as some are wont to do, I believe it is more reasonable and responsible to instead understand how this situation boils down to some fairly elementary risk management best practices, particularly related to Business Continuity Planning (BCP).
Most people confuse BCP as being the twin to Disaster Recovery (DR) when in fact nothing could be further from the truth. Disaster Recovery has to do with how systems, equipment, and facilities can be salvaged, reclaimed, or recovered after a natural or man-made disaster. BCP has to do with a broader set of principles and problems that touch on can-the-business-keep-operating sorts of questions. These typically include supply chain concerns, employee health issues (e.g. in the case of a pandemic), etc. In short, Disaster Recovery is a specialty and sub-category within the broader category of Business Continuity Planning.
OK, so now back to those ATM machines! So while the issue here is not about ATM machines “going down” due to a breach, internally deployed virus, or foreign nation-state penetration of some sort or another, it does have to do with the same end results of those situations unfortunately. If the ATM machines cannot operate (for whatever reason), then we have a Business Continuity problem on our hands that needs to be addressed. And typically in large organizations, a Business Impact Analysis (BIA) is performed – and regularly updated – in order to collect, prioritize, and assess the potential problems. And I suspect that technology-soon-becoming-outdated would have been included in most BIA programs, if they were actually conducted (yes, I know it is naïve to assume they are always performed). It’s no secret that technologies get end-of-life’d all the time; planning for such situations is essential, especially when remote systems such as ATMs require hands-on maintenance and upgrading.
This ATMs-with-XP situation is further complicated by the fact that EMV adoption in the US is about to soar based on some looming deadlines. A proper BIA would have connected these two seemingly unrelated issues and enabled businesses to combine their efforts in planning accordingly. I couldn’t agree more with the comment in this article from Sam M. Ditzion, chief executive of ATM consulting firm Tremont Capital Group about thinking several moves ahead in the chess game. All that being said, BIAs are essential for these types of situations as they represent an opportunity for the business to account for regulatory and policy changes, technology advancement, internal training needs, business pressures, and more.
Moreover, this “chess game” does not appear to have entirely snuck up on people! Microsoft’s formal 1-year Support Lifecycle Policy is well-documented and available for each of their operating systems. They explicitly indicate in a big red section of their XP Migration site that “the average enterprise deployment can take 18 to 32 months from business case through full deployment” and that “you should begin your planning and application testing immediately to ensure you deploy before end of support.” And the 10-year policy is already way beyond 10 years if we recall that Bill Gates announced XP on February 13, 2001. Finally, back in 2008 and in 2010, Microsoft was sending clear and loud signals that it intended to end XP.
So the bottom line is this … this is not Microsoft’s fault! Financial services organizations should – like all other large and essential organizations – conduct appropriate BIA procedures from time to time as their internal risk determines. Mitigating things as straightforward as software updates in ATM machines shouldn’t be so complicated, especially when the software vendor is in the public eye almost every day, the financial services folks have themselves used XP at home and at work, and Microsoft’s policies have been discussed ad nauseam for many years already.