Purchasing backup software-based encryption

Many organizations prefer the simpler option of implementing encryption in the backup software running on a backup server. You can probably enable encryption on your current backup software, or upgrade to a later version offering encryption, without overhauling your backup policies or processes. Encrypting at the backup software level is also "target-agnostic" -- you can send the encrypted data to any tape or disk target, such as a tape library or virtual tape library (VTL), even remote storage systems across a WAN.

But encryption is a mathematically intensive process, and software-based encryption demands substantial processing power, slowing the backup performance by as much as 40%. This results in far longer backup windows that may be unacceptable. As with other forms of encryption, software-based encryption schemes must also support key management to ensure that keys are preserved and properly secured.

Now that we've reviewed the essential issues involved in any encryption approach, we will focus on specific considerations for software-based encryption products. We'll also give you a series of specifications to help you compare products from vendors such as BakBone Software Inc., EMC Corp., Hewlett-Packard Corp. (HP), IBM, PGP Corp. and Symantec Corp.

((Content component not found.)) Consider the performance impact of encryption. All software-based encryption will impose a performance penalty on the backup server. Experts cite performance penalties as high as 40% depending on the server's processing power, the type and complexity of the encryption scheme and other overhead tasks taking place on the server. Before selecting encryption software, it's important to test the software's operation under real-world load conditions and determine the actual performance impact in your specific environment. Some server performance can often be restored through key server upgrades. Upgrading the processor can help, or replacing a single-CPU server with a dual- or quad-processor server may mitigate a portion of the performance penalty.

Consider the encryption targets. Since encryption is typically incorporated into backup software, it's important to select backup software that will deliver encrypted data successfully to your existing, and expected future, storage systems. Verify that the software will support your current tape drive, tape library, VTL, disk array or other storage systems. This is another area where comprehensive lab testing and evaluation will be instrumental in identifying potential problems early in the purchase cycle.

Set limitations on your encrypted content. Remember that encryption is rarely an all-or-nothing proposition, and only the most critical or sensitive backup data (e.g., data governed by compliance or privacy regulations) must actually be encrypted. By limiting the scope of encryption to certain data files or data types, you can reduce the amount of extra work needed from the backup server, and this will help to mitigate the performance impact of encryption. For example, if your current backup window is 12 hours and you encrypt the entire backup, a 40% penalty on the 12 hour backup window may add 4.8 hours to the entire backup cycle. That may be unacceptable. However, if you're only encrypting customer data for about one hour of that backup cycle, that performance penalty might only add about 23 minutes to the entire backup window, while meeting the required levels of regulatory compliance.

Consider the encryption types and strengths. While LTO-4 tape drives use AES encryption with 256-bit strength, software products typically offer a variety of encryption schemes, including AES, Triple DES and Blowfish. Each encryption scheme can also support several different key strengths -- more bits in the key provide stronger encryption. For example, Triple DES uses 168 bits, while AES often employs 256-bit keys, and Blowfish uses up to 448 bits. As keys get longer the security gets better, but the processing overhead needed to support the longer keys can worsen the performance impact on your backup software. Further, certain industries may set minimum standards of encryption type and key length, so be sure that the software meets any minimum encryption requirements -- even unofficial requirements.

Consider support for WORM media. Data that is recorded for long term archival and compliance/litigation purposes may require immutability, ensuring that the data cannot be deleted or altered once it's written. When selecting software-based encryption features, consider support for optical drives, such as CD-R, DVD-R and even emerging holographic media, as well as tape drive targets that can handle WORM media.

Consider how the key is stored and used. A key is needed to encrypt the data, but a key is also needed to recover the encrypted data. This usually involves storing the key where it is accessible to backup or storage administrators. In some cases, a single key is used to encrypt and decrypt the data, or a unique key is used for each process. In other cases, a series of keys can be deployed, allowing decryption with a majority (a quorum) of key holders. Consider how the key management system adds security to the organization, but also evaluate the level of complexity, cost and the effect that any future hardware changes or disasters might have on the key management process.

The software-based encryption product specifications page in this chapter covers the following products: