The problem with using averages to project the damage caused by ransomware is that they tend to make us forget about the sizable number that fall outside this band.
Downtime—how long it takes to recover from an attack—is an interesting case in point. Data company Statista estimates the average downtime after a ransomware attack against U.S. organizations in the final quarter of 2021 was 20 days, a slight fall from a year peak of 23 days that summer.
Gathered from a variety of sources, three weeks is probably an accurate reflection of what most organizations experience after a ransomware attack. But this still begs the question of what is meant by “downtime.” Clearly, getting an organization back in business isn’t the same as restoring all systems that might have been disrupted, which could take weeks longer.
And, of course, there are always cases where the downtime is far longer. Take the case of SEC Info, a small data business run by owner Fran Finnegan that found itself struggling for a lot longer than mere weeks.
According to the Los Angeles Times, the company’s systems were hit by an unidentified ransomware attack in June 2021. Finnegan expected to take a few weeks to reinstate full operations.
In reality, it took more than a year to bring the company back up. But what makes this story worth recounting is why it took so long to recover, and what made the attack possible in the first place.
It started with the infamous Yahoo data breach of 2013, not disclosed until 2016. This gave attackers lots of Yahoo accounts to aim at with password crackers, including Finnegan’s. Wisely, he changed his password after the attack—but forgot he’d used the same password to secure access to an admin account for SEC Info.
Heading to vacation in 2021, he activated this account for remote access, opening a window of opportunity:
“Beginning last June 26, hackers pinged his system 2.5 million times with stolen Yahoo passwords, finally hitting on the right one.”
Naturally, Finnegan had backed up the company’s data, but recovering that data in its entirety turned out to be more complex than he’d assumed.
First, a small but important amount of recent data hadn’t been backed up. But the bigger problem was the software he’d written for the company going back a quarter of a century. Reconstituting this proved complex, because in some cases he’d forgotten how it had been configured.
This was on top of trying to keep the attackers that were inside his systems from continuing their wrecking spree.
The first lesson is not to assume that weaknesses are current. Some might go back years or even decades, making them much harder to detect.
Second, no matter how secure a password is, without authentication it’s vulnerable.
Third, legacy software is a recovery issue. It’s old, it’s vulnerable, and it might also be hard to put back together again within that Statista average of a three-week recovery. You might think your company is average—but don’t assume you’ll be that lucky.