Security Patches and Moral Hazard
Are vendors doing the right thing when they patch systems that are out of support? Or are they allowing customers to shirk their responsibilities?
The concept of moral hazard was unfamiliar to me before the 2008 financial crisis. Even if you are not familiar with that term, most people have experienced it or have seen it in action in some form. Moral hazard arises when an actor (a person or organization) takes on more risk when they are insured. In this situation the insurer, not the actor, bears the cost of any negative effects from the actor’s risky behaviour.
In the 2008 financial crisis, financial institutions took undue risks in the pursuit of profits thinking that the US government would ultimately bail them out if they got into serious trouble. The phrase “too big to fail” was often used in this context, justifying the cases where indeed the US government did step in to bear the cost of these institution’s risky behaviour. In this post I’m thinking about how the concept of moral hazard might apply to the realm of security patches. Are certain software packages too big to fail, or are vendors causing more harm than good in continuing to patch them?
This idea of moral hazard keeps coming to mind every time I read about an old software system that receives a rare patch in order to deal with some particularly bad vulnerability. I’ll refer to Microsoft in this post because they have such a large presence, but this is not meant to single them out and the same issues apply to any widely-deployed software that has been around for a while.
Microsoft issued a patch to Windows XP in May of 2019 to address a particularly bad vulnerability (CVE-2019-0708) in Remote Desktop Services. Windows XP’s extended support ended in 2014 and it hadn’t received any updates since then until this patch was released. In taking this exceptional step Microsoft’s Security Response Center described the actions as necessary given this was a “wormable” vulnerability, meaning it could move from computer to computer on its own, just as the WannaCry malware spread around the world in 2017.
Wired had a few articles about the patch, including this one: “Microsoft’s First Windows XP Patch in Years Is a Very Bad Sign”. That Microsoft was doing this meant there must be a really serious vulnerability and this was the reason this was a “very bad” sign. But I couldn’t help thinking there was another layer of badness here, whereby this was going to perpetuate people’s use of Windows XP. Microsoft had just issued insurance to these users and had in a way stated that XP was too big to fail. Despite what we’ve said, if something really bad comes along then we will bail you out.
It is easy to say that Microsoft should have just let these XP users suffer the consequences. Without consequences (and/or incentives) XP users are never going to change their behaviour. But those of us working in IT know that these people and organizations are (usually) not willfully refusing to update their XP boxes. They know they should be updating or retiring them. But they are resource-constrained, and these machines may be running software that is only supported on XP, and this software could be mitigating some other very important risks to the organization.
But even with those considerations, I think software vendors need to stick to their support schedules. Allowing organization to linger on these platforms without consequences ultimately creates more risk. At the same time, I can understand Microsoft’s decision in this case because of the potential impact to their customers and their image if there was a serious XP-based malware strain. The XP problem is too far gone to now take a stand on this issue, and Microsoft has to live with the cost of intervening in situations like this until the XP user base dwindles to the point where it is insignificant.
And this is okay in a situation, like Microsoft’s, where they are well into their transition to cloud-only offerings. In the cloud world a vendor can pull its clients along from version to version. Users get plenty of notice and support, but there isn’t an option where you remain on a particular version for a decade. This can be a bit painful but ultimately for the good of everyone.
And it is painful mostly in that you need to adjust your way of working, giving up a bit of control. As an example, I do a lot of the Office 365 administration at my company and for some time now I’ve been getting notifications about Office 365 ending support for TLS 1.0 and 1.1. This will happen in June of 2020, whether I like it or not, and this forces a routine and level of discipline. If you are planning the launch of a new product or service that relies on Azure or Office 365 then you need to watch for platform updates and plan your launch around them (and not the other way around).
So is Microsoft making a mistake in providing tacit insurance to XP users? I disagree with the practice on principle, and vendors that provide on-premise or customer-specific deployments should avoid it because of the long-term negative effects. But I think this is acceptable in Microsoft’s case given that they have taken steps to avoid being in this situation in the future. They may need to absorb similar costs for a few operating systems to come (e.g., Windows 7), but this will become less and less as they move to cloud-only offerings.
