Problem solve Get help with specific problems with your technologies, process and projects.

To encrypt or not to encrypt? That is the question

A manager searches for answers to his encrypting quandary.

TechTarget's IT Knowledge Exchange is a forum specifically for IT professionals. Members ask--and answer--questions, making it a valuable resource for anyone working in the IT world. Here's a question about encrypting backups that a member recently asked.

An IT Knowledge Exchange member asked:

"I have been asked by my CIO to perform an risk analysis of encrypting our backup takes. Our off-site vendor is urging us to consider encrypting sensitive data backups.

I want to follow up with operations team performing this operation to review the impact on backup window. Has anyone created a matrix to compare the time differences in performing encrypted backups versus unencrypted?"

Here's what other members suggested.

  • An IT Architect wrote:

    "There are probably a couple of approaches to be considered for time impact. For most wintel platforms, encryption in software has improved to be of minimal impact. For large bulk encryption, consider your hardware to accelerate.

    But first, a few more questions:
    -Do you really, really want to encrypt backups?
    -Is this being done to reduce *your* risk, or the offsite storage vendor's? (Contracts, SLA's and so on should be reviewed.)
    -What about key management for backups? Will keys be sent to the same vendor, same location?
    -If off-site data - or the media it is on - is lost, damaged/destroyed or stolen, will the decryption keys be lost also?
    -Is your offsite storage local or distant?
    -Is the physical risk loss of your facility, or larger?

    In the past, some organizations have sent encrypted information off-site to one location/vendor, and keys to another site/vendor.

    Also, consider what if the *decryption keys* (or the media they are on) are lost (the encrypted data is OK). Do you have a key recovery process?

    Also, loss of keys could introduce risk due to an inability to provide data to law enforcement, client, patient and so on, if encrypted data in unrecoverable.

    Are you encrypting your organization's on-site data NOW? Online data? Nearline data? Offline data? Despite what is in the news, the bigger risk is probably still to the data in your facility. If your facility has current experience with bulk encryption of online, nearline and/or offline data, then you might be better equipped (organizational processes) to engage encrypting for offsite.

    A subsequent question is: are you going to encrypt as part of the backup process, or separately? You could check some of the backup system vendors for encryption specs and recomendations. Depending on the size of your backups, you might do a disk-to-disk backup first, then encrypt. Then, backup the encrypted data.

    You also want to consider how long you're going to be storing information for (e.g. will there still be DAT drives or DLT drives in five or 10 years).

    Be sure you do a full, detailed and thorough risk analysis."

  • A Consultant/Systems Integrator wrote:

    "Consider where the encryption will be done to make sure you have adequate processor resources. Typically, software encryption (e.g. Veritas) happens on the client rather than the backup server. The overhead can be significant enough to impact the client's application processing. If an upgrade is needed, it's probably not to the backup server, but rather (multiple) user machines.

    Consider who will need to know the keys. If the users are able to do their own adhoc backups/restore, (e.g. database tables and so on,) then the risk of key exposure may be significant.

    Consider adding the caveat in the SLA if the user encrypts their backups and loses the key, to ensure they accept the risk of having unusable backups.

    Make sure your key management process is rock solid. Once you have a library of encrypted files, changing keys is impossible."

  • Another IT Architect added:

    "All good advice above, (i.e. it's not just the technical issues your company will need to address). Thought I'd add something as well, as I have just been looking at this issue.

    Veritas adds something like 15%-20% extra CPU load on the client during encryption, which has been seen in our testing (not done with Veritas). Not sure of other vendors though.

    I like the fact that Veritas does the encryption on the client as it is then the only component affected. True, you may have multiple clients that this needs to be installed on, but you would need to ask yourself, "Do I really need to have this enabled on all of them?"

    The list price for this for Veritas was about $300, and $60 per year for maintenance. This is per client server.

    The funniest thing about this is in the Encryption Admin Guide I found the following quote:

    This is the most secure method for protecting your key file pass phrases.

    • When you add a pass phrase via the bpkeyutil command, write the phrase down on paper, seal it in an envelope, and put the envelope into a safe.

    The reality of this rings true. At some point you have to look at your combination of technology, people, and processes, and not rely entirely on technology to help you."

  • Finally, an IT Staff member wrote:

    "I've seen about 15%-20% impact in my tests depending on what I was backing up. I would also include the impact on restores in the matrix, so that there are no suprises when it's time to restore. If you are tight on meeting your SLA's for backup or recovery, this may require updating the SLA's. If you are going to selectively encrypt at the sub-server level, (directory, file, tablespace, and so on) it will require much more coordination on restores if that authority has been de-centralized. As already mentioned, the management of those keys is crucial along with knowing what is or isn't encrypted."

Have some questions of your own? Sign up for ITKE today, and access knowledge from members situated around the world.

More on encryption:

Privacy breaches: How to avoid making headlines ( | May 11, 2005) EXCLUSIVE!
Wave of privacy breaches demands integrated approach to physical and IT security. What can your organization do to avoid being the next headline?

California screaming: Companies must disclose security breaches ( | Mar. 30, 2005) EXCLUSIVE!
California's Security Breach Information Act (SB 1386) becomes official Tuesday and mandates for the first time that businesses must inform customers when electronic data is compromised by a hacker. SB 1386 requires companies that own or maintain th...

Credit union takes no chances with data security ( | Mar. 21, 2005)
Boeing Employees' Credit Union is encrypting all its data written to tape to avoid security breaches like the one Bank of America recently experienced.

Privacy experts vexed over bank's missing data mishap ( | Mar. 02, 2005) EXCLUSIVE!
In the aftermath of a rash of personal information leaks over the past weeks, privacy advocates ask why some backup data isn't being encrypted.

Dig Deeper on Enterprise data storage strategies

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.