A Hair-Raising Ransomware Story

Anyone interested in a sobering example of cybersecurity risk management and disaster recovery planning gone wrong? Because we have a doozie, courtesy of Washington’s top cybersecurity preparedness agency.

CISA, the Cybersecurity & Infrastructure Security Agency, released a bulletin last Friday warning corporate organizations about the threat of ransomware. The bulletin wasn’t much (two pages long) and contained all the usual recommendations one would expect. 

Then, on the second page, was this example of one recent ransomware victim:

A U.S. city’s systems were infected by Robbinhood with a ransom demand of 13 bitcoins ($76,000). The attackers entered the network through old, out-of-date hardware and software. The ransom was not paid, but service restoration was estimated to cost over $9 million. 

So we have weak cybersecurity controls, leading to a city’s IT systems held hostage; and the cost of doing the right thing was roughly 118 times larger than the cost doing the wrong thing: $9 million in repair costs, versus a $76,000 ransom. 

This is the stuff of a compliance officer’s nightmares.

The CISA bulletin doesn’t identify which city had this unfortunate encounter, but the circumstances bear a striking resemblance to what happend to Baltimore in May 2019. Attackers hit the city with a ransomware attack, which shut down everything from city council meetings to employee email to municipal billing systems. The attackers used Robbinhood malware and demanded 13 bitcoin, which at the time would have been worth $76,200. The city never paid the ransom. 

I do recall hearing news of the Baltimore attack when it happened, since paralyzing a city of more than 500,000 tends to make the news. I hadn’t known that Baltimore ended up spending so much on repair costs. (City officials actually estimated the attack cost them $18.2 million, including more than $8 million in lost revenue.)

A Refresher on Ransomware Risks

Ransomware is no longer anything new, and we shouldn’t pick on Baltimore too much because plenty of other cities, hospital systems, and school districts have fallen victim to ransomware over the years too. Still, let’s remember some basics here.

First, maintain a strong software patch management program. Plenty of attacks happen because a company doesn’t implement security patches to its ERP system promptly, and then attackers gain entrance through a vulnerability that should have been sealed up months or weeks ago. 

There’s no excuse for that. Businesses should assure that they have a system to implement software patches promptly. Even though it will typically be the IT department’s responsibility to do that work, the internal audit or risk team should assure that the work gets done promptly and properly. Allowing IT systems to run on outdated ERP software is an invitation to disaster. 

Second, train employees not to fall for phishing attacks and related stunts. Even if your software patch management is solid, there’s still the risk that employees will fall for a phishing attack and hand over access to IT systems unwittingly. So train employees to think critically and ask: Does this request to click on a link look legitimate? Does this person requesting that certain data be emailed to him or her really need it? 

Third, implement extra security measures proportionate to the systems at risk. I am a big fan of multi-factor authentication, where someone requesting access to confidential data (or that a password to be reset) needs to enter a one-time code sent to his or her phone. The more you implement security precautions like that — especially with confidential data, and especially with the ceaseless rise of cloud computing — the better. 

Fourth, have a strong IT disaster recovery plan. This is another one where the IT department should be responsible for running disaster recovery once disaster strikes, but internal audit and compliance teams should be very much involved in deciding what those plans should be. 

For example, which troves of data are indispensable, that they should be backed up and archived off-site daily or even hourly? Which IT systems are mission-critical, where fully operational backups should be maintained at all times? Which cloud-based vendors are mission-critical, where you want a list of emergency substitutes? How often will you vet those substitutes for security or compliance risks, so you can use them at a moment’s notice with no worries?

About Paying a Ransom

All of the above is predicated on the assumption that your organization won’t pay the ransom, which begs the question — should you ever just admit defeat and pay up? 

That might seem like a slippery ethical question, but I don’t believe it is. For reasons legal, moral, and practical, you shouldn’t pay. Rather than me blather on about those reasons, however, let’s quote Baltimore mayor Bernard Young from 2019:

I know a lot of residents have been saying we should’ve just paid the ransom, or why don’t we pay the ransom? Well, first, we’ve been advised by both the Secret Service and the FBI not to pay the ransom. Second, that’s just not the way we operate. We won’t reward criminal behavior. If we paid the ransom, there is no guarantee they can or will unlock our system.

There’s no way of tracking the payment or even being able to confirm who we are paying the money to. Because of the way they requested payment, there’s no way of knowing if they are leaving other malware on our system to hold us for ransom again in the future. Ultimately, we would still have to take all the steps we have taken to ensure a safe and secure environment. I’m confident we have taken the best course of action.

Those are all wise words, but the wisest might be that bit at the end: “We would still have to take all the steps we have taken to ensure a safe and secure environment.”

So take all those precautionary steps to avoid such an unfortunate predicament in the first place.