It looks like Melbourne-based hosting company and ICANN-accredited domain name registrar Distribute.IT is fighting for its very survival.

The company has posted this depressing notice on what's left of its Web-site.

It might seem crazy, but Distribute.IT is facing nothing short of an existential crisis because, absurdly, it didn't take offline backups. As the company itself put it:

"Our Data Recovery teams have been working around the clock in an attempt to recover data from the affected servers shared Servers [sic]. At this time, we regret to inform that the data, sites and emails that were hosted on Drought, Hurricane, Blizzard and Cyclone can be considered by all the experts to be unrecoverable... our greatest fears have been confirmed that not only was the production data erased during the attack, but also key backups, snapshots and other information that would allow us to reconstruct these Servers from the remaining data."

This is exactly the scenario I discussed with the host of the PaulDotCom Security Weekly podcast Paul Asadoorian during an interview in Risky Business back in episode 188 [42:05].

During that discussion I suggested to Paul that the current information security risk models were ineffective in dealing with high-impact, low likelihood events. You know, like some really determined and destructive attackers burning down a business. Paul's summed it up thusly:

"We can tell management about the risk all day long and they're not going to believe us until it happens to them. If you told an executive at any one of these companies... 'with our current defences in place and the risk management tactic that we're taking now, there's a probability that this could still happen and it would be really, really bad. They're probably just going to say 'yeah, well we think the business can just recover from that,' and what you're saying, Patrick, is that's not always the case, and our current risk management thinking is allowing for these cases to happen where, are you really going to be able to recover?"

From the Distribute.IT page again:

"This leaves us little choice but to assist you in any way possible to transfer your hosting and email needs to other hosting providers."

Distribute.IT has not been able to recover. Furthermore, it seemed the company did not think this type of attack was a serious enough risk to warrant implementing a strict offline backup regimen.

This is just one example of a poor risk decision. But there are plenty of other examples of these sorts of decisions being made in large information technology environments.

Some manager, somewhere, just decides to "wear the risk" because the assumption has always been that the organisation will recover if its risk controls fail.

It's not their fault; often it's the information security "experts" from outside the organisation who actually encourage these sorts of decisions. "Risk management methodologies" are the information security industry's attempt to pretend everything's under control.

It's not, and the Distribute.IT case proves it's not always possible to recover.

Distribute.IT might be a small business in the grand scheme of things, but do we really think we couldn't see similar sorts of existential threats to larger, IT dependent businesses that might not be as risk savvy as, say, a bank?

What about a shipping company? What about a taxi service? A manufacturer? An online retailer?

To what extent are businesses and government departments vulnerable to total annihilation from external attackers?

If anyone's interested in diving a bit deeper into flaws in risk-based information security practices, check out this interview with former NSA Technical Director, Information Assurance, Brian Snow. The interview with him kicks in at around 25:21 and I thoroughly recommend it. Brian is an extremely sharp guy and makes some very salient points.

The Distribute.IT story is a sad one. But it's a great example of what happens when people ignore risks they shouldn't. Sure, you might have tape/offline backups, but are there other risks you're wearing that you shouldn't?

What do you think? Tell us in our forum thread on this topic here.