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.
Hide this

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


  • identicon
    Michael Kohne, 2 Jun 2005 @ 5:34am

    Reliability

    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.

    link to this | view in chronology ]

    • identicon
      Wim, 2 Jun 2005 @ 7:52am

      Re: Reliability

      I was glad to see this comment. I wanted to put in something similar. For safe recovery, an encrypted backup would need to be stored with it's encryption method and key, thus negating the value of the encryption.

      link to this | view in chronology ]

  • identicon
    tim shea, 2 Jun 2005 @ 9:00am

    wrong

    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.

    link to this | view in chronology ]

    • identicon
      Anonymous Coward, 2 Jun 2005 @ 10:39am

      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.

      link to this | view in chronology ]

      • identicon
        Anonymous Coward, 2 Jun 2005 @ 2:46pm

        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?

        link to this | view in chronology ]

        • identicon
          Anonymous Coward, 2 Jun 2005 @ 7:33pm

          Re: wrong

          Tape bias. RAID anyone?

          link to this | view in chronology ]

        • identicon
          Ed, 3 Jun 2005 @ 1:18am

          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.)

          link to this | view in chronology ]

        • identicon
          Anonymous Coward, 7 Jun 2005 @ 6:44am

          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.

          link to this | view in chronology ]

  • identicon
    James, 2 Jun 2005 @ 10:15am

    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.

    link to this | view in chronology ]

  • identicon
    Ted, 3 Jun 2005 @ 12:45pm

    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.

    link to this | view in chronology ]

  • identicon
    pete delrey, 12 May 2006 @ 6:17am

    We've been using these kick-ass encrypted backups for VMware ESX called esXpress, www.esxpress.com.

    Not only are they encrypted, but they are also delta (differencial) backups.

    Cheers

    link to this | view in chronology ]

  • identicon
    RadiantMatrix, 19 May 2006 @ 6:36am

    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.

    link to this | view in chronology ]


Follow Techdirt
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Discord

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

Loading...
Recent Stories

This site, like most other sites on the web, uses cookies. For more information, see our privacy policy. Got it
Close

Email This

This feature is only available to registered users. Register or sign in to use it.