15.1.1 Cloud Forensics as a Reactive Technology

Since our discussion is primarily focused on the technical aspects of analyzing cloud evidence (and not on legal concerns), we adopt the following technical definition of digital forensics (Roussev 2016):

Digital forensics is the process of reconstructing the relevant sequence of events that have led to the currently observable state of a target IT system or (digital) artifacts.

The notion of relevance is inherently case‐specific, and a big part of a forensic analyst's expertise is the ability to identify case‐relevant evidence. Frequently, a critical component of the forensic analysis is the causal attribution of an event sequence to specific human actors of the system (such as users and administrators). When used in legal proceedings, the provenance, reliability, and integrity of the data used as evidence are of primary importance. In other words, we view all efforts to perform system or artifact analysis after the fact as a form of forensics. This includes common activities such as incident response and internal investigations, which almost never result in any legal actions. On balance, only a tiny fraction of forensic analyses make it to the courtroom as formal evidence.

Digital forensics is fundamentally reactive in nature – we cannot investigate systems and artifacts that do not exist; we cannot have best practices before an experimental period during which different technical approaches are tried, (court‐)tested, and validated. This means there is always a lag between the introduction of a piece of information technology and the time an adequate corresponding forensic capability is in place. The evolution of the IT infrastructure is driven by economics and technology; forensics merely identifies and follows the digital breadcrumbs left behind.

It follows that forensic research is also inherently reactive and should focus primarily on understanding and adapting to the predominant IT landscape, as opposed to trying to shape it in any significant fashion. Throughout the rest of this chapter, we will make the case that the Cloud presents a new type of challenge for digital forensics and that it requires an entirely different toolset, as the existing one becomes quickly and increasingly inadequate.

Twelve years have elapsed since the introduction in 2006 of public cloud services by Amazon under the Amazon Web Services (AWS) brand. As of 2015, according to RightScale's State of the Cloud Report (RightScale 2015), cloud adoption has become ubiquitous: 93% of businesses are at least experimenting with cloud deployments, with 82% adopting a hybrid strategy, which combines the use of multiple providers (usually in a public‐private configuration). However, much of the technology transition is still ahead as 68% of enterprises have less than 20% of their application portfolio running in a cloud setup. Similarly, (Gartner 2014) predicts another two to five years will be needed before cloud computing reaches the “plateau of productivity,” which marks mass mainstream adoption and widespread productivity gains.

Unsurprisingly, cloud forensics is still in its infancy despite dozens of articles in the literature over the last five years; there is a notable dearth of practical technical solutions on the analysis of cloud evidence. Thus, much of our discussion will necessarily tilt toward identifying new challenges and general approaches as opposed to summarizing existing experiences, of which there are few.

15.1.2 The New Forensics Landscape

Most cloud forensics discussions start with the false premise that, unless the current model of digital forensic processing is directly and faithfully reconstructed with respect to the Cloud, then we are bound to lose all notions of completeness and integrity. The root of this misunderstanding is the use of traditional desktop‐centric computational model that emerged in the 1990s as the point of reference. (This approach has been subsequently tweaked to work for successive generations of ever‐more‐mobile client devices.)

The key attribute of this model is that practically all computations take place on the device itself. Applications are monolithic, self‐contained pieces of code that have immediate access to user input and consume it instantly with (almost) no trace left behind; periodically, the current state is saved to stable storage. Since a big part of forensics is attributing the observed state of the system to user‐triggered events, we (forensic researchers and tool developers) have obsessively focused on two driving problems: discover every little piece of log/timestamp information, and extract every last bit of discarded data that applications and the operating system (OS) leave behind, either for performance reasons, or just plain sloppiness. Courtesy of countless hours spent on painstaking reverse engineering, we have become quite good at these tasks.

Indeed, our existing toolset is almost exclusively built to feast upon the leftovers of computations – an approach that is becoming more challenging even in traditional (non‐cloud) cases. For example, file carving of acquired media (Richard and Roussev 2005) only exists because it is highly inefficient for the OS to sanitize the media. However, for solid state disk (SSD) devices, the opposite is true – they need to be prepared before reuse. The result: deleted data is sanitized, and there is little left to carve (King and Vidas 2011).

The very notion of low‐level physical acquisition is reaching its expiration date even from a purely technological perspective – the current generation of high‐capacity hard disk drives (HDDs) (8 TB+) use a track‐shingling technique and have their very own Acorn RISC Machine (ARM) based processor, which is tasked with identifying hot and cold data, and choosing appropriate physical representation for it. The HDD device exposes an object store interface (not unlike key‐value databases) that effectively makes physical acquisition, in a traditional sense, impossible – legacy block‐level access is still supported, but the block identifiers and physical layout are no longer coupled as they were in prior generations of devices. By extension, the feasibility of most current data‐recovery efforts, such as file carving, will rapidly diminish.

Mass hardware disk encryption is another problem worth mentioning, as it is becoming increasingly necessary and routine in IT procedures. This is driven both by the fact that there is no observable performance penalty, and by the need to effectively sanitize ever‐larger and ‐slower HDDs. The only practical solution to the latter is to always encrypt and dispose of the key when the disk needs to be reclaimed.

In sum, the whole concept of acquiring a physical image of the storage medium is increasingly technically infeasible and is progressively less relevant because interpreting the physical image requires understanding of the (proprietary) internals of the device's data structures and algorithms. The inevitable conclusion is that forensic tools will have to increasingly rely on the logical view of the data presented by the device.

Logical evidence acquisition and processing will also be the norm in most cloud investigations, and it will be performed at an even higher level of abstraction via software‐defined interfaces. Conceptually, the main difference between cloud computing and client‐side computing is that most of the computation and, more importantly, the application logic executes on the server, with the client effectively becoming a remote terminal for collecting user input (and environment information) and for displaying the results of the computation.

Another consequential trend is the way cloud‐based software is developed and organized. Instead of one monolithic piece of code, the application logic is almost always decomposed into several layers and modules that interact with each other over well‐defined service interfaces. Once the software components and their communication are formalized, it becomes quite easy to organize extensive logging of all aspects of the system. Indeed, it becomes necessary to have this information just to be able to test, debug, and monitor cloud‐based applications and services. Eventually, this will end up helping forensics tremendously as important stages of computation are routinely logged, with user input being both the single most important source of events and the least demanding to store and process.

Returning to our driving problem of analyzing cloud artifacts, it should be clear that – in principle – our task of forensically reconstructing prior events should be becoming easier over time as a growing fraction of the relevant information is being explicitly recorded. As an example, consider that with a modest reverse‐protocol engineering effort, (Somers 2014), later expanded by (Roussev and McCulley 2016), was able to demonstrate that Google Docs timestamps and logs every single user keystroke. The entire history of a document can be replayed with a simple piece of JavaScript code; in fact, the log is the primary representation of the document, and the current (or prior) state of the document is computed on the fly by replaying (part of) the history. From a forensics perspective, this is a time‐travel machine and is practically everything we could ask for in terms of evidence collection, with every user event recorded with microsecond accuracy.

15.1.3 Adapting to the New Landscape

According to (Ruan et al. 2013), more forensic examiners see cloud computing as making forensics harder (46%) than easier (37%). However, the more revealing answers come from analyzing the reasoning behind these responses. The most frequent justifications for the harder answer fall into two categories: (i) restricted access to data (due to lack of jurisdiction and/or cooperation from the cloud provider), and (ii) inability to physically control the process of evidence acquisition/recovery, and to apply currently standard processing techniques. While data access is primarily a nontechnical issue – to be solved by appropriate legal and contractual means – the natural inclination to attempt to apply legacy techniques will take some time and new tools to resolve.

All of these concerns merely emphasize that we are in a transitional period during which requirements, procedures, and tools are still being fleshed out. From a technical perspective, the simplest way to appreciate why forensics professionals lack any cloud‐specific tools is to consider the current dearth of tools that support the investigation of server deployments. Practically all integrated forensic environments, both commercial and open source, focus on the client and the local execution model discussed earlier. However, a server‐side inquiry is an exercise in tracking down and correlating the available logs – a task that, today, is accomplished largely in an ad hoc manner using custom scripts and other “homegrown” solutions. Investigating a cloud application is not unlike performing a server‐side investigation, with a lot more log data and more complex data relationships.

From a research perspective, it may appear that log analysis does not present a very exciting prospect for the future. However, the real challenge will come from the sheer volume and variety of logs and the need to develop ever‐more‐intelligent tools to process and understand them. The long‐term upside – and, likely, necessity – is that we can, for the first time, see a plausible path toward substantially higher levels of automation in forensics. At present, the process of extracting bits and pieces of artifacts and putting them together in a coherent story is too circuitous and vaguely defined for it to be further automated to a meaningful degree. Once log data becomes the primary source of evidence, it is conceivable that a substantial number of forensic questions could be formalized as data queries to be automatically answered, complete with formal statistical error estimates.

The transition from artifact‐centric to log‐centric forensics will take some time – artifact‐analysis methods will always be needed, but they will be applied much more selectively. Nevertheless, it is a relatively safe prediction that, within a decade, this transition will fundamentally change forensic computing and the nature of investigative work.

15.1.4 Summary

Cloud computing presents a qualitatively new challenge for the existing set of forensic tools, which are focused on analyzing leftover artifacts on local client devices. Cloud services are inherently distributed and server‐centric, which renders ineffective large parts of our present acquisition and analysis toolchain. In this transitional period, forensic analysts are struggling to bridge the gap using excess manual technical and legal effort to fit the new data sources into the existing pipeline.

Over the medium‐to‐long term, the field requires an entirely new set of cloud‐native forensic capabilities that work in unison with cloud services. Once such tools are developed and established, this will open up the opportunity to define more formally legal and contractual requirements that providers can satisfy at a reasonable cost. As soon as technical and legal issues are worked out, we will face the unprecedented opportunity of automating and scaling up forensic analysis to a degree that is currently not possible.

The rest of this chapter is organized as follows: Section 15.1 presents necessary background of cloud computing service models, followed by Section 15.2 discussing the current approaches for each model. Section 15.3 presents potential approaches and solutions as a way forward to address forensics in cloud computing. Sections 15.4 and 15.6 present a detailed discussion and conclusion, respectively.

15.2.1 Software‐as‐a‐Service (SaaS)

In this model, cloud service providers (CSPs) own all the layers including the application layer that runs the software offered as a service to customers. In other words, the customer has only indirect and incomplete control (if any) over the underlying operating infrastructure and applications (in the form of policies). However, since the CSP manages the infrastructure (including the application), maintenance costs on the customer side are substantially reduced. Google Gmail/Docs, Microsoft 365, Salesforce, Citrix GoToMeeting, and Cisco WebEx are popular examples of SaaS, which run directly from the web browser without downloading and installing any software. Their desktop and smartphone versions are also available to run on the client machine. The applications have a varying but limited presence on the client machine, making the client an incomplete source of evidence; therefore, investigators need access to server‐side logs to paint a complete picture.

SaaS applications log extensively, especially when it comes to user‐initiated events. For instance, Google Docs records every insert, update, and delete operation of characters performed by the user along with timestamps, which makes it possible to identify specific changes made by different users in a document (Somers 2014). Clearly, such information is a treasure trove for a forensic analyst and is a much more detailed and direct account of prior events than is typically recoverable from a client device.

15.2.2 Platform‐as‐a‐Service (PaaS)

In the PaaS service model, customers develop their applications using software components built into middleware. Apprenda (https://apprenda.com) and Google App Engine (https://cloud.google.com/appengine/pricing) are popular examples of PaaS, offering quick and cost‐effective solutions for developing, testing, and deploying customer applications. In this case, the cloud infrastructure hosts customer‐developed applications and provides high‐level services that simplify the development process. PaaS provides full control to customers on the application layer including interaction of applications with dependencies (such as databases, storage, etc.) and enabling customers to perform extensive logging for forensics and security purposes.

15.2.3 Infrastructure‐as‐a‐Service (IaaS)

In IaaS, the CSP is the party managing the VMs; however, this is done in direct response to customer requests. Customers then install the OS and applications within the machine without any interference from the service providers. AWS, Microsoft Azure, and Google Compute Engine (GCE) are popular examples of IaaS. IaaS provides capabilities to take snapshots of the disk and physical memory of VMs, which has significant forensic value for quick acquisition of disk and memory. Since VMs support the same data interfaces as physical machines, the traditional forensic tools for data acquisition and analysis can also be used inside the VMs as remote investigation of a physical machine is performed. Furthermore, VM introspection provided by a hypervisor enables CSPs to examine live memory and disk data, and perform instant data acquisition and analysis. However, since the functionality is supported at the hypervisor level, customers cannot take advantage of this functionality.

In summary, we can expect SaaS and PaaS investigations to have a high dependency on logs, since disk and memory image acquisition is difficult to perform due to lack of control on middleware, OSs, and lower layers. In IaaS, the costumer has control over the OS and upper layers, which makes it possible to acquire disk and memory images, and perform traditional forensic investigations.

15.3.1 SaaS Forensics

Cloud customers access SaaS applications such as Google Gmail, Google Docs, and Microsoft 365 through a web interface or desktop application from their personal computing devices such as laptop/desktop computers and smartphones. The applications maintain a detailed history/log of user inputs that is accessible to customers and has forensic value. Since applications are accessed from a client machine, remnants of digital artifacts pertaining to user activities in the applications are usually present and can be forensically retrieved and analyzed from the hard disk of the machine.

15.3.1.1 Cloud‐Native Application Forensics

Perhaps the very first cloud‐native tool with forensics applications is Draftback (https://draftback.com): a browser extension created by the writer and programmer James Somers, which can replay the complete history of a Google Docs document (Somers 2014). The primary intent of the code is to give writers the ability to look over their own shoulder and analyze how they write. Coincidentally, this is precisely what a forensic investigator would like to be able to do – rewind to any point in the life of a document, right to the very beginning.

In addition to providing in‐browser playback of all the editing actions – in either fast‐forward or real‐time mode – Draftback provides an analytical interface that maps the time of editing sessions to locations in the document (Figure 15.2). This can be used to narrow down the scope of inquiry for long‐lived documents.

Somers's work, although not motivated by forensics, is probably the single best example of SaaS analysis that does not rely on trace data resident on the client – all results are produced solely by reverse engineering the web application's simple data protocol. Assuming that an investigator is in possession of valid user credentials (or such are provided by Google under legal order), the examination can be performed on the spot: any spot with a browser and an Internet connection.

The most profound forensic development here is that, as far as Google Docs is concerned, there is no such thing as deletion of data; every user editing action is recorded and timestamped. Indeed, even the investigator cannot spoil the evidence because any actions on the document will simply be added to the editing history with the appropriate timestamp. This setup is likely to be sufficient for most informal/internal scenarios, however, in order to make it to the courtroom, some additional tooling and procedures will need to be developed.

Clearly, the acquisition and long‐term preservation of the evidence is yet to be addressed. The data component is the low‐hanging fruit because the existing replay code can be modified to produce a log of the desired format. The challenging part is preserving the application logic that interprets the log; unlike client‐side applications, a web app's code is split between the client and the server, and there is no practical way to acquire an archival copy of the execution environment as of a particular date. Since the data protocol is internal, there is no guarantee that a log acquired now could be replayed years later.

One possible solution is to produce a screencast video of the entire replayed user session. The downside here is that most documents are bigger than a single screen, so the video would have to be accompanied by periodic snapshots of the actual document (e.g. in PDF). Another approach would be to create a reference text‐editor playback application in which the logs could be replayed. This would require extra effort and faces questions of how closely the investigated application can be emulated by the reference one.

The next logical question is, how common is fine‐grain user logging among cloud applications? As one would expect, a number of other editing applications from Google's Apps for Work suite – such as Sheets, Slides, and Sites – use a very similar model and provide scrupulously detailed history (Slides advertises “unlimited revision history”; https://www.google.com/work/apps/business/products/slides). A deeper look reveals that the particular history available for a document depends on the age of the file and/or the size of the revisions, as revisions may be merged to save storage space (https://support.google.com/docs/answer/95902). In other words, Google starts out with a detailed version of the history; over time, an active document's history may be trimmed and partially replaced with snapshots of its state. It appears that the process is primarily driven by technical and usability considerations, not policy.

Microsoft's Office 365 service also maintains detailed revisions based on edits in part because, like Google, it supports real‐time collaboration. Zoho is another business suite of online apps that supports detailed history via a shared track‐changes feature similar to Microsoft Word's feature. Most cloud drive services offer generic file‐revision history; however, the available data is more limited because it is stored as simple snapshots.

15.3.2 PaaS/IaaS Forensics

PaaS packages middleware platforms on top of the OS. Commercial products on PaaS are available, such as Google App Engine. However, the forensic research community did not pay much attention to PaaS, which is evident from the lack of research papers on this topic. On the other hand, IaaS has received attention because of the close resemblance among service models to traditional computing infrastructure. It has VMs running contemporary OSs and software, similar to physical machines. The conventional forensic tools for data acquisition and analysis, such as WinDD, Forensic Toolkit (FTK), and EnCase, can be used on VMs. Furthermore, IaaS offers unique features such as VM snapshotting for quick physical memory and HDD acquisition.

(Dykstra and Sherman 2012) evaluated the effectiveness of EnCase, FTK, and three physical‐memory acquisition tools (i.e. HBGary's FastDump, Mandiant's Memoryze, and FTK Imager) in a cloud computing environment. They remotely acquired geographically dispersed forensic evidence over the Internet and tested their success at gathering evidence, the time to do so, and the trust required. They used a public cloud (Elastic Compute Cloud [EC2] from AWS) for their experiments and concluded that forensic tools are technically capable of remote data acquisition. They illustrated IaaS in six layers (from lowest to highest): network, physical hardware, host OS, virtualization, guest OS, and guest application/data. Each layer (except the last) has to trust all the lower layers. Given the trust requirements, the authors mention that technology alone is insufficient to produce trustworthy data and solve the cloud forensics acquisition problem. They recommend a management plane enabling consumers to manage and control virtual assets through an out‐of‐band channel interfacing with the cloud infrastructure, such as that provided by AWS: AWS Management Console. The management plane interfaces with the provider's underlying file system and hypervisor, and is used to provision, start, and stop VMs.

(Dykstra and Sherman 2013) developed a tool called FROST, which integrates forensic capabilities with OpenStack. FROST uses a management plane through a website and APIs, and collects data from the host OS level outside the guest VMs, assuming that the hardware, host OS, hypervisor, and cloud employees are trusted. OpenStack creates a directory on the host OS containing the virtual disk, RAMdisk, and other host‐specific files. FROST retrieves the files from the host and transforms the virtual disk format to raw using the available utilities. For instance, QEMU provides utilities to convert QEMU QCOW2 images to raw format.

15.4.1 Procedural Expansion of Existing Forensic Practices

(Martini and Choo 2012) is a representative example of the approach embraced in the digital forensics literature – it seeks to identify the problems but has little in the way of technical detail. The focus is on minor refinements of the accepted procedural models of forensics, such as (McKemmish 1999) and (Kent et al. 2006). Further, the authors prescribe a six‐step process to get the final version of the new framework: conceptual framework, explication interviews, technical experiments, framework refinement, validation interviews, finalized framework.

It is entirely possible that digital forensics researchers and practitioners, as a community, will adopt such a deliberate, time‐consuming process to solve the problem; however, looking at the history of digital forensics, this seems highly unlikely. Experience tells us that the way new practices get established is much more improvised during disruptive technological transitions. Once enough experience, understanding, and acceptance of the new forensic techniques are gained, practices and procedures undergo revisions to account for the new development.

An instructive example in that regard is main‐memory forensics. As recently as 10 years ago, best practices widely prescribed pulling the plug (literally) on any computer found running during search and seizure operations. This was not entirely unreasonable, because dedicated memory forensics tools did not exist, so there was no extra evidence to be gained. Today, we have highly sophisticated tools to acquire and analyze memory images (Ligh et al. 2014), and they are the only key to solving many investigative scenarios. Accordingly, training and field manuals have been rewritten to point to the new state of knowledge.

To summarize, by their very nature, standards lag technical development and merely incorporate the successful innovations into the canon of best practices. In our view, it is critically important to understand that we need new technical solutions, and no amount of procedural framework enhancement will bring them about. Technical advances are achieved by extensive and deliberate research and experimentation and often borrow and adapt methods from other fields.

15.4.2 API‐Centric Acquisition and Processing

In traditional forensic models, the investigator works with physical evidence carriers, such as storage media or integrated computing devices. Thus, it is possible to identify the computer performing the computations and the media that store (traces of) processing, and to physically collect, preserve, and analyze information content. Because of this, research has focused on discovering and acquiring every little piece of log and timestamp information, and extracting every last bit of discarded data that applications and the OS have left behind.

Conceptually, cloud computing breaks this model in two major ways. First, resources – CPU cycles, RAM, storage, etc. – are first pooled (e.g. Redundant Array of Independent Disks [RAID] storage) and then allocated at a fine granularity. This results in physical media potentially containing data owned by many users, and to data relevant to a single case being spread among numerous providers. Applying the conventional model creates a long list of procedural, legal, and technical problems that are unlikely to have an efficient solution in the general case. Second, both computations and storage contain a much more ephemeral record because VM instances are created and destroyed with regularity and working storage is sanitized.

As we discussed in the prior section, current work on cloud storage forensics has treated the problem as just another instance of application forensics. It applies basic differential analysis techniques to gain a basic understanding of the artifacts left on client devices by taking before and after snapshots of the target compute system, and deducing relevant cause‐and‐effect relationships. During an actual investigation, the analyst would be interpreting the state of the system based on these known relationships.

Unfortunately, there are several serious problems with this extension of existing client‐side methods:

• Completeness: The reliance on client‐side data can leave out critical case data. One example is older versions of files, which most services provide; another is cloud‐only data, such as a Google Docs document, which literally has no serialized local representation other than a link. Some services, such as a variety of personal information management apps, live only in the browser, so a flush of the cache would make them go away.
• Reproducibility: Because cloud storage apps are updated on a regular basis and versions have a relatively short life‐span, it becomes harder to maintain the reproducibility of the analysis and may require frequent repetition of the original procedure.
• Scalability: As a continuation of the prior point, manual client‐side analysis is burdensome and simply does not scale with the rapid growth of the variety of services and their versions.

We have performed some initial work using an alternative approach for the acquisition of evidence data from cloud storage providers: one that uses the official APIs provided by the services. Such an approach addresses most of the shortcomings just described:

• Correctness: APIs are well‐documented, official interfaces through which cloud apps on the client communicate with the service. They tend to change slowly, and changes are clearly marked – only new features need to be incrementally incorporated into the acquisition tool.
• Completeness/reproducibility: It is easy to demonstrate completeness (based on the API specification), and reproducibility becomes straightforward.
• Scalability: There is no need to reverse‐engineer the application logic. Web APIs tend to follow patterns, which makes it possible to adapt existing code to a new (similar) service with modest effort. It is often feasible to write an acquisition tool for a completely new service from scratch in a short time.

We have developed a proof‐of‐concept prototype called kumodd (Roussev et al. 2016) that can perform complete (or partial) acquisition of a cloud storage account's data. It works with four popular services – Dropbox, Box, Google Drive, and Microsoft's OneDrive – and supports the acquisition of revisions and cloud‐only documents. The prototype is written in Python and offers both command‐line and web‐based user interfaces.

15.4.3 Audit‐Centric Forensic Services

The move to cloud computing raises a number of security, privacy, and audit problems among the parties involved – tenants, (multiple) cloud providers, and cloud brokers. The only practical means to address them is for all to have a trustworthy history – a log – of all the relevant events in the computation. Such logs are created on the boundary between clients and servers, as well as during the normal operation of services, typically in response to client requests.

For example, a tenant providing SaaS for medical professionals will need to convince itself and its auditors that it is complying with all relevant privacy and audit regulations. Since the computation executes on the provider's platform, the tenant needs the assurances of a third party, such as a trusted logging service.

In many cases, the same log information collected for other purposes can directly answer forensic queries, such as the history of user input over time. It is also likely to provide much greater detail than is currently unavailable on the client. For example, Google Cloud Storage (https://cloud.google.com/storage/docs/access‐logs) maintains access logs in comma‐separated values (CSV) format containing information about the access requests made on the cloud storage area allocated to the user. Tables 15.2 and 15.3 present the list of fields and their descriptions maintained in the log files on Google Cloud Storage and AWS.

(Zavou et al. 2013) developed Cloudopsy: a visualization tool to address privacy concerns of a cloud customer about the third‐party service/infrastructure providers handling customer data properly. The tool offers a user‐friendly interface to the customers of cloud‐hosted services to independently monitor the handling of sensitive data by third party. Cloudopsy's mechanism is divided into three main components: (i) the generation of audit trails, (ii) the transformation of the audit logs for efficient processing, and (iii) the visualization of the resulting audit trails. Cloudopsy uses the Circos visualization tool to generate graphs that enable users with no technical background to get a better understanding of the management of their data by third‐party cloud services.

(Pappas et al. 2013) proposed CloudFence, which is a data flow‐tracking framework for cloud‐based applications. CloudFence provides APIs for integrating data‐flow tracking in cloud services, marking sensitive user data to monitor data propagation for protection. The authors implemented a prototype of CloudFence using Intel’s Pin (Luk et al. 2005), a dynamic binary instrumentation toolkit without modifying applications. CloudFence can protect against information‐disclosure attacks with modest performance overhead.