Forum Discussion

WYTham's avatar
WYTham
Level 2
7 years ago

Backup Exec PassPhrase Missing

Hi all,

I'm doing backup of a financial institution data. So im using BE encryption to keep the backup safer. I've been asked these questions.


Case 1 : my passphrase is compromised or stolen, tape drives still with me.

what would be the suggested things to do to prevent someone get hold of my backup tapes and able to decrypt my data. Do i need to decrypt all my previous backup and re-encrypt with a new passphrase and key?  if yes, do BE have an automated way to help change the encryption to new key?


Case 2 : my passphrase is safe, tape drives is stolen or missing.

Correct me if i'm wrong, If BE database is not together with the tape drives then the 'thief' will not be able to decrypt my data. But if the BE database is also together with the tape drives then the 'thief' is able to decrypt and get my data?


Any best practice of how often should we change a new passphrase to do our encryption?

  • Case 1:

    You can't re-encrypt data during a duplicate job and therefore resetting the current encryption on tapes would be a HUGE amount of work as to reset existing backup sets to a new encryption key you would basically have to restore every backup set redirected to a temp folder (one at a time) and back it up again - which would then also lose the original location / path details against future restores. Note: each tape might contain more than one backup set increasing the number of operations required to do this work.

    So best option here would be create a new encyption key with a different passphrase, and then change what the current backup jobs are using (before running full backups to restart any chains). Then make sure the tape cartridges that used the compromised key/passphrase are managed in a very secure way.  Do not delete the compromised key as you will still need it for restores.

    Case 2:

    There are really 4 elements to secure and they should really be secured in different places

    1) The documentation regarding keys/passphrases used (with jobs used by the specific keys, dates of use and encryption type) - typically this would be in a sealed container (or secure digital media) inside a fire safe and should not often be needed (although will needed to be updated if new keys are created). You need the dates of use so that if you do change keys you know when the change occured should you need to restore from older tapes. Note: the passphrases (With key names and encryption type) list is important to secure, the related jobs and dates of use could be in a less secure document, as long as you ONLY use the key names in that document and not the passphrases. This info is needed should you lose all copies of the BEDB (or lose the DEK) and then have a disaster.

    2) The Backup Exec Database (BEDB) - for your query this only needs to be more current than the last time any keys were created/edited - although if you want it to contain up to date job configs, job histories and/or media management information it needs to be copied away regularly.

    3) The Database Encryption Key (DEK) file - this stops the security content of the BEDB from being accessible and is not the same as the backup set encryption passphrases you are asking about. This key file is unique for a given instance of a BEDB and can be exported from within the Backup Exec Admin Console. As long as you do not completely reset the BEDB, you only need to export the DEK once. Note: this concept did not exist in older Backup Exec versions so make sure you are using a recent version.

    4) The tapes cartridges or disk storage devices being used.

    Apart from the fact that all of the above are of course on or linked to your Backup Exec Server (so protect access to your server room), best practice would not be to store any of the 4 items together.

     

    Finally we don't really have any best practices for how often to change keys however:

    - Remember that you will have to update your secure copies of the documentation and the BEDB after such a change.

    - You should probably start with full backups after such a change so that any incremental or differential chains only use 1 key/passphrase.

    - Some backup admins may elect to use different keys/passphrases for different jobs, instead of just one that all jobs use, this might reduce how often it could be worth changing passphrases as compromising one passphrase would not compromise all backup sets, but does increase the documentation/admin overheards.

    - while you do need to protect the DEK and BEDB, it is probably not a good idea to protect them within encrypted backup jobs, as then the metadata you need to decrypt would itself be encrypted. Probably best  to protect such data with methods outside of Backup Exec

  • Case 1:

    You can't re-encrypt data during a duplicate job and therefore resetting the current encryption on tapes would be a HUGE amount of work as to reset existing backup sets to a new encryption key you would basically have to restore every backup set redirected to a temp folder (one at a time) and back it up again - which would then also lose the original location / path details against future restores. Note: each tape might contain more than one backup set increasing the number of operations required to do this work.

    So best option here would be create a new encyption key with a different passphrase, and then change what the current backup jobs are using (before running full backups to restart any chains). Then make sure the tape cartridges that used the compromised key/passphrase are managed in a very secure way.  Do not delete the compromised key as you will still need it for restores.

    Case 2:

    There are really 4 elements to secure and they should really be secured in different places

    1) The documentation regarding keys/passphrases used (with jobs used by the specific keys, dates of use and encryption type) - typically this would be in a sealed container (or secure digital media) inside a fire safe and should not often be needed (although will needed to be updated if new keys are created). You need the dates of use so that if you do change keys you know when the change occured should you need to restore from older tapes. Note: the passphrases (With key names and encryption type) list is important to secure, the related jobs and dates of use could be in a less secure document, as long as you ONLY use the key names in that document and not the passphrases. This info is needed should you lose all copies of the BEDB (or lose the DEK) and then have a disaster.

    2) The Backup Exec Database (BEDB) - for your query this only needs to be more current than the last time any keys were created/edited - although if you want it to contain up to date job configs, job histories and/or media management information it needs to be copied away regularly.

    3) The Database Encryption Key (DEK) file - this stops the security content of the BEDB from being accessible and is not the same as the backup set encryption passphrases you are asking about. This key file is unique for a given instance of a BEDB and can be exported from within the Backup Exec Admin Console. As long as you do not completely reset the BEDB, you only need to export the DEK once. Note: this concept did not exist in older Backup Exec versions so make sure you are using a recent version.

    4) The tapes cartridges or disk storage devices being used.

    Apart from the fact that all of the above are of course on or linked to your Backup Exec Server (so protect access to your server room), best practice would not be to store any of the 4 items together.

     

    Finally we don't really have any best practices for how often to change keys however:

    - Remember that you will have to update your secure copies of the documentation and the BEDB after such a change.

    - You should probably start with full backups after such a change so that any incremental or differential chains only use 1 key/passphrase.

    - Some backup admins may elect to use different keys/passphrases for different jobs, instead of just one that all jobs use, this might reduce how often it could be worth changing passphrases as compromising one passphrase would not compromise all backup sets, but does increase the documentation/admin overheards.

    - while you do need to protect the DEK and BEDB, it is probably not a good idea to protect them within encrypted backup jobs, as then the metadata you need to decrypt would itself be encrypted. Probably best  to protect such data with methods outside of Backup Exec

    • WYTham's avatar
      WYTham
      Level 2

      Thanks Colin for the detail explanation.