Business model implications of the NHS ransomware attack

Blame the Business Model

Still, even if the U.S. government is less to blame than Smith insists, nearly two decades of dealing with these security disasters suggests there is a systematic failure happening, and I think it comes back to business models. The fatal flaw of software, beyond the various technical and strategic considerations I outlined above, is that for the first several decades of the industry software was sold for an up-front price, whether that be for a package or a license.

This resulted in problematic incentives and poor decision-making by all sides:

Microsoft is forced to support multiple distinct code bases, which is expensive and difficult and not tied to any monetary incentives (thus, for example, the end of support for Windows XP).
3rd-party vendors are inclined to view a particular version of an operating system as a fixed object: after all, Windows 7 is distinct from Windows XP, which means it is possible to specify that only XP is supported. This is compounded by the fact that 3rd-party vendors have no ongoing monetary incentive to update their software; after all, they have already been paid.
The most problematic impact is on buyers: computers and their associated software are viewed as capital costs, which are paid for once and then depreciated over time as the value of the purchase is realized. In this view ongoing support and security are an additional cost divorced from ongoing value; the only reason to pay is to avoid a future attack, which is impossible to predict both in terms of timing and potential economic harm.

The truth is that software — and thus security — is never finished; it makes no sense, then, that payment is a one-time event.

Ben is on the right track when arguing that the lack of alignment of business models is at the heart of the problem. However, the problem itself is more complex than Ben perhaps realises since many of the "computers" affected by last week's attack are not "computers" in the traditional sense of the word, but medical devices where the software is embedded as part of the whole widget. As such, his proposed solution does not address the problem within the medical context.

Medical devices such as MRI scanners have a lifecycle that does not necessarily match that of the embedded software. For example, Microsoft sold Windows XP until 2008 and supported it until 2014. MRI scanners have a lifecycle of 10-12 years (and I have been on a few older ones myself...), so a scanner built in 2008 using Windows XP would only have its software supported for half of its lifecycle. Now you may ask why on earth a vendor would still be selling products with Windows XP in 2008 but that is due to the high certification costs of medical equipment (no one wants a repeat of the Therac-25 disaster) and the "shelf life" of those machines: new MRI scanners are not designed every year like an iPhone, so companies have the incentive to sell existing models for as long as possible to defray the development costs through a larger number of units sold. Plus, since software is embedded in the machine there is usually no competitive pressure applied to it itself (if you doubt me, check you car entertainment "software" and compare it with your smartphone).

The above is the main reason why Ben's proposed business model of Software As a Service would not work within the context of the NHS attack: Microsoft does not have a commercial relationship with the final acquirer of the machine, but with the vendor, therefore Microsoft's business model is irrelevant to change reality at the proverbial coal face. Even if Microsoft supplied its software under a SaaS model, there are currently no incentives for the device manufacturer to actually incur the certification costs of pushing it to the machines in use (another smartphone example: how many Android smartphone vendors actually update hardware that has already been sold to new versions of the OS?).

How do we align the business models then?

It is possible to align the business models in two different ways. First, by changing the way the way those devices are acquired by hospitals and NHS trusts. Second, by extending the liability of the manufacturer.

An easy way to look at aligning the incentives of different business models would be to lease instead of outright buying the medical devices where possible, thus transforming a capital expense into an operational one (as suggested by Ben). With the right contractual incentives in place (ie that the embedded software must be kept up to date at least in what concerns security patches) it would be possible to create in the device vendors the incentive to keep their machines secure.

A fancier approach is to follow the example I saw in Spain when doing my Ph.D research. At least one regional health board was doing public-private partnership (PPP) contracts with medical equipment providers. In practice this ends up being quite close to Ben's suggestion of SaaS but with hardware instead. For a period of up to say 12 years the public sector was "buying" the availability of imaging equipment in their premises from a vendor.

What made those contracts so interesting is that they included upgrade clauses, so that when a new machine was released, those in service needed to be replaced with the new model, creating in the vendor an obligation to cascade updates to the customer during the whole lifecycle of the contract. I am not aware that they covered software updates although maintenance and servicing were included. Even if they did not, it is conceivable to design future contracts as to include software updates for machines in service.

A different avenue would be to attack the problem from vendor liability perspective, which may also be valid under the current contracts or could spring from raised awareness of the potential liability implications from last week's ransomware attack.

Bottom line

It is possible to conceive contractual and legal solutions that solve (most) of the alignment issue between vendors of medical devices and their clients going forward. What remains to be seen however is what will happen with the existing machines. Surely vendors would be delighted to replace them all, but will the courts consider that they owe a duty of care of sorts towards the users to keep them updated during a certain period of time and to provide access to the source code once they reach "end of life" support? One may dream.