RSS
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.
12 Comments | Leave a Comment..
If you liked this post, you may also be interested in...
- DailyDirt: Autonomous Vehicles
- How Publishers Repeated The Same Mistake As Record Labels: DRM Obsession Gave Amazon Dominant Position
- Park Ranger Tases Guy Walking Dogs Without A Leash
- Brazilian Government Ordering Web Hosting Firms To Kill Domain Names They Don't Like
- Syrian President's Email Hacked... His Password Was 12345
Reader Comments (rss)
(Flattened / Threaded)
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.
[ reply to this | link to this | view in thread ]
Re: Reliability
[ reply to this | link to this | view in thread ]
wrong
[ reply to this | link to this | view in thread ]
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.
[ reply to this | link to this | view in thread ]
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.
[ reply to this | link to this | view in thread ]
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?
[ reply to this | link to this | view in thread ]
Re: wrong
[ reply to this | link to this | view in thread ]
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.)
[ reply to this | link to this | view in thread ]
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.
[ reply to this | link to this | view in thread ]
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.
[ reply to this | link to this | view in thread ]
Not only are they encrypted, but they are also delta (differencial) backups.
Cheers
[ reply to this | link to this | view in thread ]
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.
[ reply to this | link to this | view in thread ]
Add Your Comment