everythingpossible - Fotolia
How Google's cloud data deletion process can influence security policies
Understanding the process behind Google's cloud data deletion can help influence stronger enterprise security policies. Expert Ed Moyle explains the process and how to use it.
In September 2018, Google published a white paper detailing its technical process of customer cloud data deletion in the Google Cloud Platform.
On the surface, the lifecycle details of individual bits and bytes in someone else's data center may not sound very interesting. However, to cybersecurity practitioners, managers and executives, these details are significant for two reasons: first because understanding the implementation details of the cloud environments an organization uses is paramount to due diligence for cloud environments, and second because the information contained in those documents about cloud data deletion can inform additional actions -- such as authoring policies or implementing controls -- that practitioners might use to ensure that security requirements and expectations are met.
A full understanding of the technical details of how a cloud provider operates is table stakes for secure cloud usage. Consider, for example, how many breaches stem from misconfigured cloud storage buckets, failure to set appropriate security policy for cloud objects, or other similar situations.
In fact, everything from voter records to defense geospatial intelligence has gone missing or has leaked as a result of individuals not understanding the APIs, administrative details, security models or various other important parameters associated with the environments they employ. This means that understanding how security services work is part and parcel of making sure your data is protected.
Public cloud services are designed to be available to a large swath of the customer population. This means cloud providers need to create a generic security model that will work for most customers. Because no two organizations share the exact same risk profile, the risks for one organization might not be risks for another, and vice versa.
This, in turn, means that the security model a given provider employs may not meet every organization's goals, risk tolerances or assumptions, and will therefore require additional action by the IT department to bring security in line with expectations. Understanding the specifics can help security teams make an informed decision about what those steps might be.
How does Google Cloud data deletion work?
With these facts in mind, let's look at what Google's document, "Data deletion on Google Cloud Platform," actually says.
Google is not alone in making the implementation details of its cloud data deletion available to customers. Amazon, for example, includes some details about data deletion in its "Amazon Web Services: Overview of Security Processes" white paper, while Microsoft spells its out in its "Protecting Data in Microsoft Azure" document. These documents and others like them should be required reading for those that want to take cloud security seriously.
In the white paper, Google describes its deletion process as having four phases. The first phase is the deletion request, in which the user employs either the UI or an API to delete a particular resource, project or account.
The second phase is soft deletion, a 30-day grace period during which the deletion request is recorded. However, during this phase, objects and data can still be recovered if a resource is deleted in error or if the user decides later that he still needs it.
Next is the logical deletion phase, in which the resources are removed from active use. It typically takes about two months for the data to be fully removed.
The last phase, expiration from backup systems, is when the data is removed from backup systems, which typically occurs over about six months. Media is tracked throughout its lifecycle until it is decommissioned and sanitation occurs via overwriting or physical destruction.
One important thing to note is that data is deleted according to two different mechanisms: for example, under "Compute, Storage & Databases, and Big Data except Google Cloud Storage," data is deleted in piecemeal fashion using garbage collection to overwrite data over time.
For cloud storage, data is encrypted using cryptographic erasure. Sometimes referred to as crypto-shredding, this term refers to the deliberate destruction of a key that has been used to encrypt data. Without the key, the data is still there but inaccessible in its encrypted form.
Taking this information forward
This process is fairly straightforward, but reading the white paper will be time well-spent. Informative as it is, though, this information only becomes actionable and truly relevant when evaluated in the context of your individual security program, goals and risk tolerances.
The white paper is particularly helpful when evaluating where there might be differing requirements from those that are provided by default from Google. It can help the security team decide where to take additional measures over and above those provided natively.
For example, the security team might decide that for high-security applications or high-sensitivity workloads, a two-month deletion timeline -- or six months for backups -- is too long based on risk tolerances. Based on this, the enterprise could implement additional controls to take more direct control.
The company might choose to implement encryption measures within an application for PaaS services or at the OS level for compute workloads. If these aren't options, it's possible to move those applications and workloads to a different environment that offers more specialized security functionality or that provides direct control over data deletion.
These decisions should be based on two factors: understanding how cloud data deletion occurs and the processes you should follow -- which Google provides in the white paper -- and understanding information more specific to your organization. Specifically, you must understand the risk assessment, risk mitigation and risk tolerance decisions that your organization makes for cloud usage.
This information, along with other security-relevant information from Google and other cloud providers, can serve as one more proof point for using these measures.