Page tree
Skip to end of metadata
Go to start of metadata
  1. Is the TSM software affected by the OpenSSL Heartbleed vulnerability?

    No.  See IBM's statement at http://www-01.ibm.com/support/docview.wss?uid=swg21670142
  2. Why does UCBackup require encryption?UC Berkeley policy requires encryption of notice-triggering data. [For other types of sensitive information, encryption is probably a Good Idea even if it is not an absolute requirement.] The owners of notice-triggering data should know where it is stored and take responsibility for its security, but UCBackup staff generally does not know whether a given server holds notice-triggering data and cannot easily tell whether that data has been encrypted either on disk or in the TSM client.

    Using TSM client encryption means that your data is always encrypted - on the network or at rest, on-site or off-site. Implementing server-enforced encryption for all clients is overkill, but it is the best way we can ensure that data which should be encrypted actually is encrypted. It also ensures that if sensitive data ends up somewhere unexpected, its backups will still be secure; it's better to encrypt a bunch of data that doesn't need it than to have a security incident.

  3. How did UCBackup transition to encrypted backups? Initially, we set two options on our servers that override client settings:
    • Generate encryption key - The encryption key is generated by the TSM software and stored on the TSM server. This allows encryption to be transparent to our customers, and ensures the encryption key will be available in a disaster recovery scenario.
    • Include all data in encryption - Note that this applies to new backups; existing backup data will not be retroactively encrypted.

    After encryption was enabled, we began forcing new full backups using encryption:

    1. We renamed existing "filespaces" (Windows drive, Unix/Linux/MacOS filesystem) with a __PRE-ENCRYPTION__ prefix.
    2. This caused a new full backup to be taken.
    3. After the longest retention period associated with the original filespace, data was purged. In cases where there was no new equivalent for an old filespace, we left the old data in place until one of the node contacts could confirm that it was okay to purge the old data.
  4. What if I want to use my own encryption keys? If you want to continue use your own encryption keys, you must contact us at ucbackup-ticket@berkeley.edu; we will set you up with a server-enforced policy that encrypts everything with your client-managed keys. Warning: If you lose your encryption keys, the UCBackup staff cannot recreate them, so your data will be unrecoverable; please ensure your business continuity/disaster recovery planning includes making your keys available if your server and key personnel are unavailable.
  5. Which type of encryption keys should I use? Generated and client-supplied keys meet different requirements. UCBackup recommends the use of generated keys for most customers and sets up new nodes this way.
    1. Generated encryption keys provide "transparent encryption" where backup and restore do not require any special configuration or management. Backup data is encrypted at all times in TSM - protecting against eavesdropping-type attacks - but there is no additional protection against TSM-based attacks beyond the node password.
    2. Client-managed encryption keys add protection against some TSM-based attacks by requiring you to provide additional information (the encryption key) to restore data; an attacker who hacks into the TSM server or guesses your node password cannot access your data. The downside of this is that if you lose your encryption keys, the UCBackup staff cannot recreate them, so your data will be unrecoverable; please ensure your business continuity/disaster recovery planning includes making your keys available if your server and key personnel are unavailable. Note: To simplify scheduled backups, the client-supplied password is normally stored in your TSM client, so someone hacking into your system could still access your TSM data.
  6. What if I don't want to encrypt my data? We're not sure why you wouldn't want to, but if you're sure you have no notice-triggering data, you can request to be excluded from the encryption. ISP can provide tools to scan your system for sensitive data, and annual re-certification will be required.
  7. How do I restore my old (unencrypted) data? To create new encrypted full backups, we renamed your existing backup data sets. Restoring the old data requires selecting backups from the old location, and choosing the correct restore location instead of using the original location.
    • Windows: Drives will show up with names like \\hostname\__PRE-ENCRYPTION__.c$\ For metadata filespaces (SystemState, ASR, SYSTEM OBJECT) please contact UCBackup - we will temporarily rename back to the original while you restore.
    • Unix/Linux/MacOS: Filesystems will have /__PRE-ENCRYPTION added as the top level. The old / (root) filesystem became /__PRE-ENCRYPTION__/__ROOT_FILESYSTEM

    When we prepared your system for new full backups, you received an e-mail listing the name changes.

    Note: If you need to restore unencrypted sensitive data, please contact us at ucbackup@berkeley.edu for assistance setting up SSL network encryption.

  8. Why was my node locked?  The MSSEI requirement to encrypt network data transfers went into effect 7/16/2013. UCBackup had been preparing for this for over a year, but there were still a handful of nodes which were not compliant. On 7/15, we locked out nodes running TSM versions older than 5.5.2.  Backup data will not be lost, but affected nodes will be unable to backup or restore until you coordinate with UCBackup to resolve the issue.

    Options:

    1. Upgrade to a newer version of TSM (best option) - see TSM Software and Manuals.
    2. If you do not have Protection Level 2 (or higher) data, let UCBackup know that encryption requirement does not apply to you. UCBackup does not know what kind of data you are backing up, so we have to assume it is covered by the policy.
  9. Will encryption affect the speed of my backups? We have seen encrypted backups run up to one-and-a-half times as long as unencrypted backups. We encourage compressing your backups, which can more than make up this time, as well as reducing your costs.
  10. Does encryption impact my monthly bill? There are several aspects:
    1. Encryption itself causes a slight increase in file size. In our testing, the largest we have seen is a 1% increase. If you think you have seen a significant increase, please contact us at ucbackup-ticket@berkeley.edu and we can investigate.
    2. We forced most of you to create a new full backup, and we feel it would be unfair to ask you to bear the added cost for this. For filespaces which have had a new backup, we do not charge you for the data in the original filespace. Note that you are still be charged for filespaces with existing (unencrypted) backup data but no new backups.
    3. Encrypted data does not compress well; the overall storage space used by UCBackup increased when we began encrypting all data since we were no longer seeing hardware compression benefits. There is no direct impact on your monthly bill, but the increased storage costs do affect our rates.  We are looking into several options to overcome this limitation.