How Come So Few Backups Were Encrypted?

from the good-question dept

While there have been a variety of ways that companies and institutions “lost” sensitive data over the past few months, one of the more common ones were situations where backup data “went missing.” This is worrisome for a variety of reasons, but some people are finally asking how come this sensitive data wasn’t encrypted? It’s bad enough that the data wasn’t protected and watched over to make theft or loss more difficult, but to then leave the data unencrypted just seems to make the problem worse. Seems like yet another case where companies that had our data just didn’t think it was worth the extra money to really protect it.

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “How Come So Few Backups Were Encrypted?”

Subscribe: RSS Leave a comment
Michael Kohne says:


The reason many don’t encrypt their backups is that the IT guys responsible for creating the backup strategy was attempting to optimize recoverability of the data.

In the event of a massive failure such as losing your original system in a fire and then finding out that your tape drive was doing something odd to the tapes, extreme methods may have to be used to try to recover data from the backups. If encryption were used, it makes such recovery MUCH more difficult, if not impossible.

tim shea says:


Both comments are flat wrong.. The state in which the data is stored (be it encrypted or not) is not a basis in the backup or recovering process of said data. Secondly – any proper backup strategy would store the keys and encryption method is a separate location. Not encrypting data and following basic common sense in a backup strategy is not an excuse.

Anonymous Coward says:

Re: wrong

Man, you couldn’t be more wrong. Encryption does make a huge difference in data recovery. During the recovery process, many bits will be misread. You’d be lucky to acurrately restore 99% of the data. Some data will be damaged so much that it’s a guess whether it was a zero or one. For any significant data recovery effort there WILL BE some errors.

For unencrypted data, this is usually no big deal. If you misread a bit of unencrypted data, you lose just that one bit. Maybe that screws up a whole byte, a 16 or 32 bit integer. Usually it’s no big deal because the humans using the data can figure out that the word “humagized” is a mispelling of “humanized” in that Word document recovered.

For encrypted data using real (i.e. effective) encryption algorithms, if you misread one bit of data the whole rest of the stream is F’d up. That’s how encryption blocks data recovery efforts. Oh, and knowing the key doesn’t help with this problem.

The only way to effectively combine encryption and backups is to make multiple copies of the encrypted data, store them in different buildings (preferibly far apart), and keep them synchronized. Guess what… That’s more expensive. Few people will pay for that.

Anonymous Coward says:

Re: Re: wrong

So a hardware recovery of encrypted data, with or without the key, will fail because the hardware recovery will be imperfect, and the encrypted data will be rendered totally unreadable.
You therefore need to have multiple encrypted backups, stored separately and synchronized, so that recovering from data loss is done using an encrypted backup that is undamaged, and so does not require using hardware data-recovery methods to read it.

Makes sense. Are there any encryption mechanisms, even theoretical ones, that forgive byte-size read errors during data-recovery, when you have the decryption key?

Ed says:

Re: Re: Re: wrong

A couple of points…

There are different encryption mechanisms that limit the damage caused by dropped bits; perhaps a single block (of some determined size) gets lost, but not the rest of the stream. I think there’s some tradeoff between security and recoverability there. I don’t recall all the details, but it’s all in Bruce Schneier’s book should anybody really care to learn more.

If encrypted backups become more widespread, I expect in a few years to read all about the problems people are having because somebody lost the key to their backups.

But the main point which seems to be lost in this discussion is that data encryption is only one part of the overall picture. For on-site backups, it makes little sense — just keep the backups in a location that is as physically secure as the original servers. For off-site backups, I thought that the whole value proposition of companies like Iron Mountain was that they were physically secure. (Certainly they try to imply that with their name!) If they really live up to that, then encryption should not be necessary. (It might still be an option if you are paranoid, but you assume additional risk of having an unusable backup if the keys are lost.)

Anonymous Coward says:

Re: Re: Re: wrong

There are block-based encryption protocols, but cryptoanalysis is much easier on them then stream-based protocols. The code breaker needs only to know one block in both it’s encrypted and decrypted form to derive the key. He can’t do that with stream-based encryption protocols.

Guess what. If it’s easier to recover from errors in an encrypted file, then for the same reason it’s easier to break the encryption on that file. If you want secure encryption, you can’t get easy recovery. Just imagine that the code breaker acts like someone trying to recover data, which is exactly what a code breaker does, and it’s obvious why this is true.

James says:

No Subject Given

Backups aren’t a sexy subject for any IT manager. The only sexy thing about it is the $20,000 tape library when it shows up and you uncrate it. Even then, the afterglow diminishes within a few months.
My point is, most admins don’t consider backups to be as important as they really are. Most want to get them done, and done quickly. Then make sure there’s time to run a verify cycle. Better do that quick, too.
Encryption? That will take time, and add to processor overhead (like the processor is really all that busy at 11pm). Other admins may be wondering where that ‘encrypt’ checkbox is within Backup Exec. Ah, thats right. It’s not there.
Encrypting backups is a ‘new thing’. There was never much of a market demand for backup encryption technology. You just ‘kept them locked up’ in a firesafe or otherwise. Doesn’t help much when you hand your tapes to the guy in the shorts from Iron Mountain in it’s little locked box. Shouldn’t THEY assume financial liability for lost media? I’m sure there’s a disclaimer in their contract, somewhere.
Here’s a tip to the backup software industry..Offer encryption in your mainstream packages…and market the H-E-double hockey sticks out of it.

Ted (profile) says:

No Subject Given

Wow. There are a lot of people who are completely clueless on the topic of encrypted backups.

– Any reasonable excrypting backup system encrypts blocks, not using feedback for the rest of the stream. Blocksize depends on a variety of factors (tape type, software, speed considerations, the hardware, sometimes user preferences)
– As someone else said, only a moron would store the key with the tapes.
– High end libraries have hardware encryption accelerators that work with high end backup software.

Backup is tedious, but isn’t rocket science. Encryption doesn’t change the process much, if at all, and if your admin can’t handle it, the problem is either with the admin or, perhaps, the budget.

RadiantMatrix (user link) says:

Protect the transport mechanism, not the storage

Encrypting backup media is a risky behavior, both from a security standpoint and a business standpoint. As others have pointed out, very small backup errors can render the backup media useless — there goes your DR plan! Not to mention, it’s expensive to use the extra disk space, run the key management, properly protect the backup/restore keyrings, etc, etc. The risk of loss just isn’t great enough to justify the expense.

The issue isn’t that data isn’t encrypted on backup media, it’s that the data is transported over an insecure medium (often something like FedEx). Using private couriers is a good step, and placing your media in transport containers that are difficult to break into can significantly lower risk.

For data that’s so important that thieves might go to the trouble of breaking those physical controls, backup over a network (WAN, Internet, whatever) to an off-site location and encrypt on the wire. No need to encrypt the backup set.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...