Can You Collect the Data Yourself?
Once you suspect an incident has occurred and decide to collect data, you must decide why the data are being collected (e.g., for remediation, court, or some other reason) and, thus, what data need to be collected. If you can easily collect the necessary data in the normal course of business via the company’s access to the cloud, you should revert to standard digital forensic techniques following well-established procedures and ensuring a clean chain of custody.
On the other hand, if you have to ask for assistance from the cloud providers, you must identify the provider. Doing so may not initially be obvious, since your company may have changed providers over time, the person who initiated the cloud usage may no longer be with the company, or many other reasons.[1] Once the provider is identified, determine where its headquarters and state of incorporation are located. This is necessary so you can determine the applicable jurisdiction and law, as you may have to send legal documents, preservation letters, or litigation holds and subpoenas in order to preserve the data and compel collection.
At this point, a quick note on data ownership is necessary. When you put your data in the cloud, you assume you still own that data. In most cases that is true, but just in case, check the contract, service-level agreement (SLA), and terms of service (ToS). Remember, there are two types of data: content, which in most cases you still do own, and meta data or data about data, which in many cases the provider owns and controls. You may be able to easily collect content, but it is the meta data you may need, and it is the meta data that is likely the toughest to obtain for many reasons.
Which Jurisdiction Applies?
In most instances the corporate structure of the cloud provider can be complicated. The headquarters may be located in one state and the servers may be located in one or more separate jurisdictions. One or more of its servers may even be located overseas. Therefore, the question, “Where’s my data?” may not be an easy one to answer. If your data is truly scattered across numerous servers, how do you determine which jurisdiction applies (e.g. which state court do you rely on to issue subpoenas, file a civil suit, etc.)?[2] Your initial thought may be to determine where your data is stored and utilize that
jurisdiction. However, this may be a daunting task since your data could be scattered across multiple servers across multiple jurisdictions at any given time.[3]
The simplest answer to the jurisdiction question is to look to the state of incorporation or headquarters for the cloud provider. Currently, there is no right answer, but this is probably the best, and the alternative(s) may be too cumbersome. For many providers—at least the big ones—an address and sometimes procedures for serving a subpoena are on its web site, although this may still leave the question of jurisdiction unanswered.
Can You Compel the Disclosure of Data?
If necessary, how do you compel your provider to gather and turn over data to you? If you believe the provider is going to give you access to its servers to dig around and figure out what you need to collect, you will be sadly mistaken. If your SLA or contract allowed for access, it would be relatively easy, and making this happen will be discussed later. In most cases, you will not have access to the provider’s server(s), and it’s a pretty good bet your provider will not simply say, “Tell us what you need, and we will provide it immediately.”
This leaves you with at least two options: negotiating for what you want in the event of an incident prior to signing a contract with a provider, and, if that’s not an option, attempting to compel the provider, via legal wrangling, subpoenas, and other tools, to give you what you need. Negotiating contracts and SLAs, which will be covered at the end of this paper, is still possible at this stage, although remotely. Once the provider is notified about the incident and provided a preservation letter or litigation hold, attempt to negotiate for the data needed. Depending on how big the provider is and how big your company is, you may have some leverage if you threaten to move all your business elsewhere.
[1] You might wonder why a company may not know who is holding its data. If your company is very large, there may have been personnel turnovers in the IT department, you may have been using the cloud for a while and don’t remember who the provider is, or at some point changed providers over the years. Additionally, the cloud provider company could have changed hands. There are numerous scenarios that could all contribute to a lack of knowledge of your company’s current computing architecture.
[2] The Privacy Commissioner of Canada has noted, “By its very nature, cloud computing has the possibility of sending, storing, and processing data in multiple jurisdictions….” Office of the Privacy Commissioner of Canada, Reaching for the Cloud(s): Privacy Issues related to Cloud Computing (March 2010), http://priv.gc.ca/information/pub/cc_201003_e.cfm.
[3] For some of the smaller companies, location may be easy, e.g., a handful of servers in one location. For the larger companies, there are likely servers located in multiple jurisdictions and your data may not be on just one of those servers but scattered over many in order to create redundancy, protection, backup, and economy of scale. See, Dexter Duncan, Xingchen Chu, Christian Vecchiola, and Rajkumar Buyya, “The Structure of the New IT Frontier: Cloud Computing – Part I,” Cloud Computing and Distributed Systems (CLOUDS) Laboratory Department of Computer Science and Software Engineering, The University of Melbourne, Australia, accessed Feb. 15, 2013, at http://www.buyya.com/papers/AnekaMagazineArticle1.pdf.
Reproduced from Global Knowledge White Paper: Legal Issues of Cloud Forensics
Legal Issues of Cloud Forensics Series
- Legal Issues of Cloud Forensics — Part 2