All Checksum

Ep. 13: 3 Reasons Ransomware is Hard

Garmin was recently hit by a ransomware outage that put numerous lines of business out of commission for several days. While Garmin is far from the only organization to struggle with ransomware, the question is, why? Ransomware has been around for years and is consistently identified as a priority concern for organizations. Yet we see that organizations still struggle to deal with it, even as the prioritize for it. We break down three reasons why ransomware is so hard for organizations to deal with.

Transcript of Checksum Episode 13: 3 Reasons Ransomware is Hard

Listen, 2020 is probably not going down as many people’s favorite year. Basically continuing to exist qualifies as the new “pretty good”. But even by that standard, Garmin had a pretty rough week in July. They suffered an outage that affected multiple business lines, from aviation databases to their Garmin Connect consumer service, and even shutting down manufacturing lines across several factories.

After everyone BUT Garmin reported this outage to be caused by ransomware, Garmin confirmed that it had some of its systems encrypted, leading to a five-day service outage.

But I’m not here to dunk on Garmin’s IT. Even after seismic IT events like Wannacry rocked the industry, ransomware remains incredibly hard to tackle. The question is, why?

So today, I wanted to talk about three things that make ransomware so challenging for IT. Essentially all of these get at the fact that ransomware seems to strike at the fault lines within organizations, leading to inefficiency, and an ultimate lack of ownership.

#1 is, when does ransomware become a disaster? This isn’t just a question exclusive to dealing with ransomware, it’s something that is imperative for any organization’s DR strategy. But it’s particularly acute for ransomware.

Often in disaster recovery, declaring a disaster is a fairly simple distinction. A backhoe dug up the powerlines to your datacenter? Disaster! Flash flood put your main office underwater? Disaster! Two Kryptonians who’ve gained superpowers thanks to the yellow sun of our solar system battling for dominion of the earth with a seemingly complete disregard for human life and property destruction rip through your corporate campus? Disaster!

But with ransomware, deciding on when to declare a disaster is critical. Because it’s probably not universally a disaster across the board. If a few endpoints get encrypted, it’s operationally not a great day, but assuming it doesn’t spread any farther, not a disaster. But if ransomware is spreading among your infrastructure, you need to be able to engage your DR plan asap, regardless of when you’re hit. Any delay will only deepen the problems you’re about to have, so it’s critical to have hard and fast criteria.

This leads to the second thing that makes ransomware tricky. It really does challenge the traditional siloed nature of IT. When we started seeing an uptick in ransomware attacks in the mid-2010s, there was basic disagreement over what kind of problem it even was. Depending on who you were asking, it was a security issue, a storage issue, a networking issue, a business continuity issue, a disaster recovery issue, or a data management issue. Someone probably even threw the cleaning staff under the bus at one point.

And the truth is, it was hard to agree on what kind of issue ransomware was because it did fall across all of those lines. Prevention required communication between the security and storage team to set up things like monitoring for a ton of sudden write requests on usually cold data. Business continuity is increasingly being seen as something that needs to work hand in hand with disaster recovery teams when it comes to ransomware recovery. And mitigation really does require a holistic view of your IT infrastructure that it’s often sorely lacking.

This is where I see Garmin having the biggest issues. We’ll probably never know what their IT staff went through during the attack, but we can clearly see that their business continuity plans were not connected with whatever ransomware strategy they had in place. Instead, we had a stone wall of silence that only made the situation seem worse for the company.

And the third thing that makes ransomware so challenging is related to that. It’s the stigma that’s attached to it. Let’s face it, in most other DR scenarios, organizations are more likely to be open to talking about what caused it, what they did while it was happening, and give a debrief after it’s over. That’s because if a tornado tears through the town, no one is blaming the organization for being there.

Because ransomware is a man-made attack, organizations are naturally a lot more cagey to talk about it. This isn’t to say that we shouldn’t be critical of those organizations that are blatantly unprepared to meet the challenges of ransomware. But given how quickly different strains and approaches to ransomware have cropped up, and given how tied they can be to social engineering to execute, it doesn’t always, or even often, mean that organizations hit by ransomware don’t have their house in order.

This silence only serves to benefit the attackers. And organizations would be in a much better position to deal with it if we all were much more open to discussing what happens and what they’ve learned from each attack.

About the author

Rich Stroffolino

Rich has been a tech enthusiast since he first used the speech simulator on a Magnavox Odyssey². Current areas of interest include ZFS, the false hopes of memristors, and the oral history of Transmeta.

Leave a Comment