As part of a disaster-recovery plan, many companies regularly perform full backups of their network or server data and store the backups offsite. However, after spending the time and resources to secure the data, it's risky to simply store the backups offsite. You need to protect them as well.
As a systems analyst, I've found that many administrators back up to tapes, then protect those tapes with passwords. My primary experience is with Symantec's Backup Exec, so I'll talk specifically about using that product to back up to tapes. However, no matter what backup tool and what backup media you use, you need to make sure the backups are secured with passwords and the data is encrypted.
Backup Exec lets you protect tapes with passwords. The password-protected tapes work seamlessly on the local server, but you're prompted for the password when the tapes are imported on any other server. In Backup Exec versions earlier than 11d, you can't encrypt the backup data, so if the password request is bypassed, the entire backup becomes available.
Fortunately, Backup Exec 11d provides encryption capabilities. All data written to tapes is encrypted with a key you generate, which means that your tapes are much more secure in the event of loss or theft. (Note that if you back up to disks, Backup Exec 11d doesn't encrypt some types of data. However, there are workarounds.)
Encrypting backup data causes a performance hit on the backup job, but this hit can be kept to a minimum if you use software compression rather than hardware compression on your backup jobs. Software compression will compress the data before encryption, whereas hardware compression will compress the encrypted data. Because encrypted data is randomized, applying hardware compression can actually increase the size of the job.
With password-protected, encrypted backup tapes, the disaster-recovery plan must include the password and the encryption key so that the tapes can be restored if needed. The disaster-recovery plan and backup tapes should be kept separate to avoid compromise.
Gregory W. Smith
Editor's note: This Reader to Reader item was a winning entry in the Know Your IT Security contest sponsored by Microsoft Learning Paths for Security.
Share Your Security Experiences
Share your security discoveries, comments, solutions to problems, and experiences with products. Email your contributions to [email protected]. Please include your full name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you’ll get $100.
