Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:30 AM
Todd Weller
Todd Weller

The Ransomware Dilemma: What if Your Local Government Is Next?

Baltimore has so far refused to comply with a ransom demand. It's being forced to make a decision all such victims face: to act morally or practically.

Although ransomware took a backseat to other attack vectors in 2018, the threat has regained momentum this year. The most recent high-profile ransomware attack occurred 20 miles from my home, on the city government of Baltimore, on May 7. Baltimore was attacked by a ransomware strain known as RobinHood, and attackers demanded approximately $100,000 in exchange for the digital keys that would restore the city's systems and access to data. To date, Baltimore has refused to pay the ransom. We are now three weeks into the attack; significant disruptions continue to occur and are costing the city dearly in financial and reputational damages.

Ransomware sets the stage for a great debate on moral versus practical dilemmas. This recent surge of ransomware attacks raises the question: Is your local government next? And if you are in a position of power, will you pay the ransom?

To Pay or Not to Pay — That Is the Question!
Whether a city pays ransomware demands depends on many factors. It's not an easy question to answer, and whatever side you are on will have a sharp opposing view. Before making a decision, however, it's vital to examine your response through both a moral and a practical lens.

Morally, the most common, quick, and easy answer is "no." Don't pay the ransom because it only serves to reinforce attacker behavior. I appreciate this angle. It generally has been the US view on ransom demands involving hostage captivity, though the government has paid a ransom to free hostages in some situations. OK, I know here we're talking humans and not computers, but there must be some parallels — and in today's world, computers affect humans on an extraordinary level. 

Practically, you'll find that many people believe that paying a ransom is the right move. This is because the costs of paying the ransom ultimately dwarf the costs associated with not paying it. It's hard to put an exact quantification on this, but the logic is clear.

For example, the government of Atlanta refused to pay $50,000 and ended up paying an estimated $17 million to recover from the attack. It's not easy to determine what costs would have been avoided if the city had paid the ransom, but a quicker recovery time would have resulted in less business disruption and reduced spending on third-party consultants. This alone would have indicated a positive return on investment for paying the ransom.

Unfortunately, Baltimore is three weeks into the attack, and it's still experiencing disruption. Email remains down. Real estate transactions have been disrupted. Online bill payment systems have not recovered, significantly affecting city revenue collection. These negative effects also result in the unavailability of services or the degradation of service delivery quality. For example, critical services such as emergency medical services, police, fire, and 311 have remained operational in the city. However, the quality of service and operations is being intensely affected — 911 alerts are now occurring via pagers rather than the normal manner of a computer-generated, automated alert.  

Of course, there is always risk of paying a ransom and the attackers don't restore the system. A Trend Micro report from a three years ago indicated one in five companies never got their data back. However, this data is dated and it would be interesting to see a current look at where this issue stands. But decision-makers must ask themselves: What is the cost of disruption? How much has been paid to third-party consultants to restore systems? And how do these costs compare with the costs had the city paid the ransom initially?

The moral reaction to ransomware says to not pay the ransom because it reinforces bad behavior. However, I think the practical aspect of ransomware is that the cost of not paying the ransom is materially greater than the cost of paying it. I had a conversation recently with a savvy CISO that led me to believe that it's more standard than not for organizations to pay the ransom. I suspect this is happening more frequently than we realize and that there are likely many ransomware attacks we don't hear about because significant disruption was mitigated by paying the ransom.

And while there may be honor among thieves, the value of holding an entire city government under ransom is a tempting and interesting dilemma given the amount adversaries will pay for information on the Dark Web. All in all, where do you stand on the spectrum of practicality versus morality when it comes to ransomware? Let us know by commenting below.

Related Content:

Todd Weller, Chief Strategy Officer at Bandura Cyber, works with organizations of all sizes to improve their ability to use, operationalize, and take action with threat intelligence.  He brings over 20 years of cybersecurity industry experience with a unique blend ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
User Rank: Apprentice
5/30/2019 | 12:52:22 PM
To pay, or not to pay?
Scary how many groups and organizations have silently paid to avoid the public humiliation that Baltimore is currently enduring.
User Rank: Strategist
5/30/2019 | 3:43:53 PM
What if you pay, then get hit again?
One of the things to consider when looking at the initial ransom cost vs cost of recovery is the cost of the next infection.  If you pay, the attackers now know youre willing to pay.  They ARE going to target you again.  So that 100,000 could quickly turn into much more over time because now youre seen as an easy target.  A city that doesnt pay, it doesnt make much sense for attackers to spend a lot of time and effort infecting them again when they get nothing out of it.  If we really want these types of attacks to stop, we need to make it cost more and profit less.  The only way to do that is for all businesses and governments to refuse to pay.  Without payment, the attackers will move on.  As long as even some vitims choose to pay, there will be more and more victims and the costs over the entire economy will keep going up.  
User Rank: Author
5/31/2019 | 8:17:49 AM
Re: What if you pay, then get hit again?
Totally agree.  Guess the conundrum is there are a healthy number of organizations that are paying and so how do you stop something like this that's already in motion.  On the cost side, Baltimore is now pointing to $8.1 million in lost revenue.  I think if we expand this analysis out the real issue is comparing all of these costs against the investment they should have made to ensure an up to date IT infrastructure and more importantly to apply a patch that's been available for two years. 
User Rank: Ninja
5/31/2019 | 3:12:02 PM
Re: What if you pay, then get hit again?
Agreed. The reason companies are typically told not to pay the ransom is because you are operating under the mechanism that you are expecting an unethical entity to act ethically and do what they say they are going to do. Nothing stopping them from going back on their promises and exposing either the data or secrets that you don't want exposed. 

On the flip side if they are extorting data and you don't have a viable backup program, then you may be at their mercy for getting back.

Its really a lose lose any way you look at it.
User Rank: Ninja
6/5/2019 | 1:09:49 PM
Re: What if you pay, then get hit again?
FOR A SMILE - Firms that lack a backup strategy (damn dumb) now have one - their encrypted data stored securely by thieves.  Negotiate a payment plan and if they backup but do not encrypt the data locally, then the firm has a viable and secure method of restoration and recovery.  Monthly fee service. See, it works if you think weird.
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-15
A XSS Vulnerability in /uploads/dede/action_search.php in DedeCMS V5.7 SP2 allows an authenticated user to execute remote arbitrary code via the keyword parameter.
PUBLISHED: 2021-05-15
DedeCMS V5.7 SP2 contains a CSRF vulnerability that allows a remote attacker to send a malicious request to to the web manager allowing remote code execution.
PUBLISHED: 2021-05-14
The Linux kernel before 5.11.14 has a use-after-free in cipso_v4_genopt in net/ipv4/cipso_ipv4.c because the CIPSO and CALIPSO refcounting for the DOI definitions is mishandled, aka CID-ad5d07f4a9cd. This leads to writing an arbitrary value.
PUBLISHED: 2021-05-14
In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value.
PUBLISHED: 2021-05-14
The block subsystem in the Linux kernel before 5.2 has a use-after-free that can lead to arbitrary code execution in the kernel context and privilege escalation, aka CID-c3e2219216c9. This is related to blk_mq_free_rqs and blk_cleanup_queue.