Plenty of things could explain why a ransomware attack that exploits a Windows vulnerability Microsoft patched in March spread across the globe late this week. IT staff refusing to install the patch, consumers failing to recognize its importance, and other things besides would help rationalize this problem. But in many cases, another problem might be to blame: software development. Or, to be more precise, how often critical apps stop receiving compatibility updates.
Ask someone who works in a hospital why they’re still running Windows XP or Windows 7. Many won’t know, but some are bound to explain that some critical software doesn’t work on newer versions of Windows. These apps simply don’t work on modern operating systems, and if an IT department breaks the software the first time it downloads a Windows update, chances are good that future updates are going to be passed over in favor of the status quo.
This problem extends beyond hospitals. Nonprofits, small businesses, and large enterprises all have software on which they rely. Sometimes this software is maintained, either in-house or by an outside developer, to at least keep pace with new operating systems. (This is to say nothing of keeping up with design trends; many of these apps look like they could’ve run on Windows ME.) Why spend the money to install an operating system only to spend even more money on new apps?
None of this is idle speculation. Citrix found in 2016 that many National Health Services (NHS) hospitals in the UK were still using Windows XP because they needed access to legacy apps. Avanade said in 2013 that 80% of businesses stuck with XP because they feared critical software would stop working if they used newer versions of Windows. Both sectors chose to help save lives or appease shareholders instead of upgrading their operating systems.
Patching an operating system can lead to unexpected problems even if organizations don’t rely on legacy software. Columbia University’s Steven Bellovin explained this problem recently:
Patching is hard? Yes—and every major tech player, no matter how sophisticated they are, has had catastrophic failures when they tried to change something. Google once bricked Chromebooks with an update. A Facebook configuration change took the site offline for 2.5 hours. Microsoft ruined network configuration and partially bricked some computers; even their newest patch isn’t trouble-free. An iOS update from Apple bricked some iPad Pros. Even Amazon knocked AWS off the air.
Combine these two problems–relying on legacy software and fearing that patches will break stuff–and it’s easier to understand why so many organizations fell victim to a problem that Microsoft solved months ago. It would be easy to blame these groups anyway–their negligence threatened people’s lives and, at the very least, put countless devices at risk. Yet demonizing these hospitals and companies undermines their legitimate concerns about installing patches.
One potential solution would be to develop critical apps in-house. That raises its own problems, though, not the least of which is how these groups will pay for that development. Another would be to test patches on all possible configurations, but that would probably delay patches for critical vulnerabilities. There are no easy answers, at least for some of the organizations affected by this week’s ransomware attack.
You, as an individual, probably don’t have those excuses. You just need to update your operating system; otherwise, you put yourself at risk of falling victim to this attack, even though it appears to have been stopped for now. Just don’t mistake your ability to address this problem for (total) incompetence on the victims’ parts. Legacy software is critical to some people, and patches don’t always work as intended, so it’s not hard to see why some organizations were caught between a rock and a hard place.