In a previous post we discussed the impact of cyber and data privacy considerations on recovery operations and time to production. We promised further discussion on mitigation strategies. In this post, we will focus on public cloud infrastructure, although many of these strategies apply additionally to hybrid and on-premises systems. Two factors impact the ability …
In a previous post we discussed the impact of cyber and data privacy considerations on recovery operations and time to production. We promised further discussion on mitigation strategies. In this post, we will focus on public cloud infrastructure, although many of these strategies apply additionally to hybrid and on-premises systems.
Two factors impact the ability to quickly restore backup snapshots together with a rapid data return to production. First of these is related to cyber security risks since new malware and ransomware updates may have arrived after the systems were backed up. The second is related to data privacy since new Data Subject Access Requests (DSARs) may have been processed after the systems were originally backed up. In both scenarios, before cut-over to restored systems can occur, both cyber security and DSAR scans should be executed, which typically mean a delay in recovery time to production.
One solution is to automatically pre-scan backup snapshots on a scheduled basis, to eliminate the need to scan on the actual time of restore. During these scans, malware, ransomware and DSARs can be equally addressed. This process requires that backup snapshots be mounted, scanned and then a decision made based on the result. One challenge is that compliance requires that the original backup be retained. Since the new backup will have a completely different time stamp, the ability to link the two backups is critical. In the event compliance auditors require the ability to review the original backup snapshot, it will still exist. If the backup is found to be compromised with malware, ransomware or data privacy issues, then you can either mark this backup as infected or a new backup could be created, linked with the original and marked as clean. If on the other hand the backup is found to be clean, then you would only need to mark it as clean for reporting purposes.
In the example of public cloud infrastructure, not only the backup application service, but the backup reporting tool will also need to provide proof of an available and intact original backup snapshot. The report would also indicate if a new related pre-scanned backup snapshot exists and is available for restoration. Typical 3rd party backup solutions for public cloud infrastructure do not specifically address this issue or may require expensive add-ons to accomplish the task.
Moving your on-premises backups to the public cloud, such as Amazon Web Services (AWS) that have cloud native backup tools and low-cost storage, can make this process efficient and affordable. Since snapshots and backups done in the AWS cloud simply charge for snapshot storage capacity and not the backup tool and service itself, coupled with the AWS tiered and metered storage model for low-cost backup snapshot retention, an add-on to AWS that addresses both the mount/scan/write, along with reporting needs, would be ideal.
All brands, images and names are property of their respective owners.
The ComplyTrust Team.