Who’s in charge of crypto backup?

At many firms, back-up policies and procedures are a hodgepodge of action, inaction and political infighting. Who’s in charge? Is it the disaster-recovery folks, because failed drives and erased tapes certainly could qualify as a disaster? Or is it the business continuity group, whose job it is to make sure . . . well, business continues? The IT department likes to control all aspects of IT stuff, so maybe it should run the back-up process. But wait! What about the information security people, well trained in backup and other such nuances of information protection?

This is a turf battle I’ve seen more times than I care to remember. And now, adding fuel to the fire is another back-up procedure: cryptography.

Who wants to lose a laptop on a subway or at the airport only for some competitive geek to gobble up sensitive corporate data? Because typical Windows passwords are “fred,” “sex,” “mommy” or some other simplistic choice, getting to the contents of the hard disk is a minor hacking job at best. So what’s the answer?

Crypto, of course. Encrypt the contents of the hard disk so prying eyes that crawl past the minor barriers Windows offers will find only gigs of gibberish. Pretty Good Privacy, Data Encryption Standard and Advanced Encryption Standard are just a few of the many choices for encrypting mission-critical files.

There is little point in wasting CPU time on encrypting programs – all that constant opening and closing of program-relevant files would put a 4-GHz Pentium on Quaaludes. All you really need to encrypt are important files.

My friend Stan was evaluating how to add security at the desktop with crypto, add crypto to his consultant’s laptops to protect data from subway hackers, and crypto-protect his servers. Smart move, or not?

I asked Stan whether he had ever had any trouble backing up files or servers. No, he replied, backing up is simple. Exactly. The tough part is restoring the data to a usable format. There’s a whole subindustry out there to recover data that was supposedly backed up, but people forgot to periodically test the system and see if it worked. Because backup is so important, let’s work on perfecting it to the best of our ability.

We all want privacy on our laptops and desktops. But are you willing to encrypt all the data on your machine of choice, knowing that a simple bit flip, glitch, bug or hard-disk error could render it unrecoverable? At least with data stored in plain text, you stand a chance of recovery after a crash.

Also, you have to manage the keys separately from the cryptography process. How many of us always remember all our passwords, access codes, PINs, user IDs, and the multitude of security do’s and don’ts we are expected to know? That’s why we back things up, right?

OK. Let’s assume you have a really reliable crypto program for your desktop and the key management problem is solved to your satisfaction. You also have an enterprisewide back-up procedure in place. What is actually happening here? You would be backing up the encrypted data from the desktops and servers onto some back-up media that is shipped off-site for safekeeping. What is wrong with this picture?

You are adding an additional fallible process (crypto) onto an already known-to-be-fallible process (backup) in the hopes of adding security to your networks. The risk is that you are combining two processes that should remain distinct from each other, because if either process fails or adds error, it also destroys the efficacy of the other process.

Large corporations want simplicity and efficiency with minimized risk. Before attempting to encrypt sensitive stored data that is part of an enterprise back-up process, you need to answer some important questions. Which group (or groups) would be responsible for crypto? Are additional fault tolerance and redundancy needed? How often do you test the system?

And finally, is the risk of encrypting data, where an error could make it unrecoverable for the eons, really worth the benefit? Just asking.