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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
Reliability
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.
[ link to this | view in chronology ]
Re: Reliability
[ link to this | view in chronology ]
wrong
[ link to this | view in chronology ]
Re: wrong
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.
[ link to this | view in chronology ]
Re: wrong
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?
[ link to this | view in chronology ]
Re: wrong
[ link to this | view in chronology ]
Re: wrong
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.)
[ link to this | view in chronology ]
Re: wrong
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.
[ link to this | view in chronology ]
No Subject Given
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.
[ link to this | view in chronology ]
No Subject Given
- 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.
[ link to this | view in chronology ]
Not only are they encrypted, but they are also delta (differencial) backups.
Cheers
[ link to this | view in chronology ]
Protect the transport mechanism, not the storage
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.
[ link to this | view in chronology ]