When a cloud storage data loss incident occurs in a financial institution, time is of the essence, and inaction only adds to the risk. It is not a nice-to-have but a must-have for compliance and regulatory requirements.
This guide is designed to provide CISOs with a clear idea of how to respond to data loss incidents in major cloud storage systems.
Understanding the Data Loss Landscape
Financial institutions are subject to unique risks in cloud storage systems. Among the most common data loss incidents in cloud storage systems are those caused by access control misconfiguration, accidental data deletion, ransomware attacks, and insider threats. Adding to these risks is the regulatory environment in which financial institutions operate. Those in the SEC, FINRA, and ECB regulatory domains not only have to prove that data was successfully restored but also that the process was carried out in accordance with documented procedures and protocols.
Immediate Response: Scope and Isolation
When a data loss incident is detected in a cloud storage system, the first step in responding to it should be to isolate the affected cloud storage system to prevent further data corruption and exfiltration. This involves revoking access and isolating the affected cloud storage system and documenting the scope and nature of data affected before initiating the data restoration process.
All actions taken from the time of detection should be logged and documented, and this is non-negotiable. This log of actions taken in response to a data loss incident in a cloud storage system is crucial in preparing a report to be submitted to regulatory authorities and in assessing the response process internally.
Platform-Specific Recovery Procedures
Recovery procedures in AWS, Azure, and Google Cloud differ from one another in significant ways.
On AWS, the process of recovery is usually done via S3 Versioning and Cross-Region Replication. IT teams should check whether versioning was already enabled before the incident. After that, they should start restoring the data from the corresponding versioning history.
On Azure, the process of recovery is done via Soft Delete and Azure Backup. IT teams should check whether the retention period corresponds to their institution’s data governance policy. After that, they can start the process of data recovery.
On Google Cloud, the process of recovery is done via Cloud Storage Object Versioning and Scheduled Snapshots. IT teams should check whether they are familiar with the process of data recovery. In the absence of information, consider how to restore a Google Drive backup, especially in the case of end users’ data, which is usually associated with Workspace environments and enterprise storage services.
Stakeholder and Regulatory Communication
After the process of recovery has started, it is necessary to activate the protocol of communication with stakeholders. This includes both internal stakeholders, especially from the legal, compliance, and executive teams, and also includes regulatory stakeholders, especially from the SEC or ECB, which should be notified in due time regarding the incident, depending on the severity of the incident.
The IT teams should prepare the necessary communication templates in due time and store them in locations that are not associated with the compromised cloud environment.
Post-Incident Hardening and Long-Term Resilience
The process of recovery closes the incident. However, it is the post-incident review that prevents the next incident. Therefore, it is necessary to conduct a root cause analysis, especially by the CISO, to identify the reasons behind the incident. After that, it is necessary to update the security controls, especially regarding IAM, immutable backups, and the process of data recovery, especially regarding backup restoration, which should be tested at least once per quarter!
