Some organizations completely ignore important aspects of the backup recovery and validation process. This creates a significant ongoing data security vulnerability.
I have never seen a backup label that identified the owner of the data when the backup was created, nor one that indicated whose authorization is needed before the backup is actually recovered. Making the problem worse, many backups are created across entire file systems, where there may be many owners of data, both from the aspect of who created it, and an organizational-owner aspect such as engineering or finance. The lack of such clarity in labeling could prove to be a significant enabler of breaches of data by insiders. If Joe Suspicious (username joes) in engineering asks for Joe Secreporter’s (username joesr) backup tapes, which had been created in accounting, who would stop him?
PCI DSS v 3.2 clause 9.6.3 states, “Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals)”. This says, rather obliquely, that there must be controls around who can authorize restores of data from secured areas. There must also be processes to validate who can authorize recovery from off-site storage of backup media, and another to specify who will receive those off-site media when they are returned. For those controls to be as comprehensive as possible, the backup label needs to contain information on any of the constraints that are to be placed on the media at the recovery destination.
Consider including backup label instructions for:How the intended destination should be locked down to prevent unauthorized access
- Who is to be informed when the backup is recovered and addressing who has authority and control of the data if the original person is no longer with the company
- What extra validation steps to perform if the data to be recovered contains PII, PHI or PCI information
- What to do if the recovery brings back information that had been declared destroyed, or is beyond any declared retention policy
- Whether there are geographic or other constraints on where, or what kind of file system, the restored data can be saved on and/or recovered to
We all need a far better process for all aspects of data backup and recovery.
- My ideal backup label would include the following:
- Tracking number of the backup
- Data classification that indicates whether there are any HR, Financial, PII, PHI, or other sensitive data included in the backup
- Original creator, department, city, and any other relevant contact information
- Date of backup creation
- Indication of data content
- Original storage name from which the backup was created
- Geographic or legal jurisdiction in which it was created
- Retention period and data destruction date
- Organizational owner/ the kind of authorization needed to recover from near-term storage
- Type of authorization required to recover from long-term storage
- Type of authorization required to change the destination of the recovery if different from where it originated
Note that this is not an exhaustive list. Specific organizations may need other critical data on their labels, such as whether it is encrypted and who holds the encryption keys. Some organizations may decide that the label only needs the tracking number and the authorizations needed for recovery, with everything else obscured in a database. Best practice would be to make a risk assessment on the content of the label and the value of the data and to make an appropriate choice on how much to record visibly and how much to make available only to authorized staff through databases or other trackers.
Leaving everything up to chance, as many organizations do today, is NOT an appropriate choice.
The help desk (or whoever is responsible for retrieving backups) needs a complete process around (i) how to validate both the authority and the need for data retrieval, and perhaps (ii) a validation that the stated need is what the retrieval actually accomplishes (rather than being used for a secondary unstated (nefarious) purpose), especially if it is very sensitive data. Just because someone has the authority, keep in mind that he or she must also have a legitimate need. This may be handled by requiring sign-off by a manager one level above the level of the original requester, or by mandating dual control of the retrieved assets (two people required to perform any action) until they are sent back to storage, or destroyed, for instance.
Anyone involved with sensitive data should always remember that it is better to delay a legitimate request for access while seeking the appropriate validation, than to allow an unauthorized request with no validation.