Don’t Pay the Ransom Unless You Really Have To

How hospitals can protect themselves against ransomware.

A doctor worrying with update logo swirling.
Animation by Slate. Photo by Thinkstock.

This article is part of Update or Die, a series from Future Tense about how businesses and other organizations keep up with technological change—and the cost of falling behind.

Very early on the morning of Palm Sunday last year, the Erie County Medical Center in Buffalo, New York, was infected by the SamSam ransomware. Hospital staff members first noticed the ransom demand for 24 bitcoins (worth roughly $44,000 at the time) locking up their devices at 2 a.m. on April 9, 2017, and they promptly called the hospital help desk.

By the time administrators made the decision to shut down all of the hospital’s IT systems at 3:30 a.m., more than 6,000 computers at the hospital had been infected by the ransomware virus. With its email, electronic health records, and website all shut down, ECMC went back to its pre-computer processes, relying on paper patient charts, telephone calls, and faxes for several hours until they could set up web-based access to a regional database called HEALTHeLINK that provided ECMC clinicians with crucial health records and patient information during the slow and painful process of cleaning and rebooting the hospital’s entire network.

By the time ECMC was hit with SamSam, ransomware in hospitals was already on the rise. A year earlier, in February 2016, when Hollywood Presbyterian Medical Center faced a similar ransomware attack, it had also reverted to relying on paper records before paying roughly $17,000 worth of bitcoins to regain control of its network. It’s a problem that has continued to crop up: In May 2017, the British National Health Service would be crippled by the WannaCry ransomware attacks. More recently, in January, Hancock Health, a hospital in Greenfield, Indiana, shut down all of its computer systems when they were infected with SamSam ransomware. It ultimately made a cryptocurrency payment worth roughly $55,000 to its attackers.

So ECMC’s ordeal was by no means unique or unprecedented, but it was notable for the hospital’s refusal to pay the demanded ransom—and for the uncertainty that still lingers around the question of whether (and when) that is, in fact, the right response for hospitals dealing with ransomware. From a pure cost-benefit perspective, it is almost always cheaper—at least in the short term—for the victim of a reasonably sophisticated, large-scale ransomware attack to pay a ransom than it is to embark on the kind of drawn-out multistage reboot that ECMC undertook, which, by its own estimates, cost millions of dollars.

There are, of course, several caveats to that analysis: For one thing, it assumes that the person or people behind the ransomware are on the up and up (honest criminals, if you will). What if the attackers don’t decrypt the compromised files and data upon receiving the ransom payment? And even if they do decrypt the infected systems as promised, there’s still the larger systemic problem of hospitals providing incentives for criminals to continue conducting these crimes—and also the greater risk that they may be targeted again now that the criminals know they’re willing to pay.

I’ve argued before that we should be much less willing to encourage or allow victims of ransomware to make ransom payments for this exact reason: Those payments only serve to engender more ransomware in the future. But that’s an easier argument to make when it’s not a matter of life and death to keep computer systems up and running—and in a hospital setting, perhaps more than just about anywhere else, the people making decisions about how to deal with ransomware are facing incredibly difficult trade-offs that weigh much more than just money.

I’m still inclined to think that ECMC’s approach is best, when possible—and that the most important lessons of the past 2½ years’ worth of hospital ransomware incidents are: first, lay in enough paper supplies and hard-copy backups that you can function for weeks without your computer systems, and second, have enough completely disconnected, un-networked backups that you can reboot your systems even if all your automatic, online backups are compromised.

This second lesson is especially important. The common wisdom around preparing for ransomware is that it’s just a matter of keeping regular backups, but many strains of ransomware actually look for and corrupt those backup files if possible. ECMC’s most recent, automated backups at the time of its SamSam attack, for instance, were stored online—and were subsequently deleted by the attackers because they could be accessed through the compromised network. So instead, ECMC had to rely on older, offline backup files, further slowing its rebooting process. Hancock Health also had online backups that were destroyed during the ransomware attack, forcing it to instead pay the demanded ransom to regain access to its files.

A recent study by researchers at MIT also indicated that part of the challenge hospitals face in defending themselves against cyberattacks stems from a lack of buy-in and understanding on the part of the staff. Arguably, no one has a lower opinion of computer security controls—and perhaps computers in general—than health care professionals. Ask any doctor about the technological hoops she has to jump through to check her work email accounts or access patient records or view lab results, and prepare yourself for a lengthy rant about how extensive and worthless security controls at her hospitals and clinics are. Recently, I asked a hospital administrator whether his hospital had a plan in place for what to do if all its computer systems were infected with ransomware, and he told me, only half joking, that they would go back to doing everything on paper—and probably provide better patient care.

Hospitals trying to protect themselves against ransomware attacks and their fallout would do well to screen incoming emails and attachments closely, segment their networks, and restrict the types of software that can be downloaded on their devices. (Of course, these are also the kind of onerous restrictions that physicians are most apt to complain about.) But perhaps even more importantly, they should have a plan in place for what to do in response to the first signs of ransomware in their networks—a plan to quarantine infected devices, revert to offline backups, and even rely on paper charts and communication for a period of time. There may still be circumstances in which they feel they have to pay a ransom in order to get their systems back up and running and take care of their patients, but in the long term, those decisions only lead to more ransomware and interrupted patient care further down the road.

Data security efforts in hospitals have long been dictated by the 1996 Health Insurance Portability and Accountability Act, which focuses on protecting the confidentiality of patients’ health information. That’s still an important security goal for hospitals, which also face the threat of large-scale breaches of medical records. But HIPAA’s restrictions on copying and sharing patient data can also make it harder to create the kinds of backup copies and shared repositories of critical information needed to restore systems in the aftermath of a ransomware attack. In some ways, these two security goals are fundamentally at odds: making sure patient information is replicated and shared as minimally as possible, while also ensuring that a hospital can recover quickly from a ransomware incident without caving to the attacker’s demands. Hospitals have tended to emphasize the former goal over the latter, but that balance will have to shift if hospitals want to make ransomware less profitable for attackers.