Secure Evidence Collection and Storage for Cloud Accountability Audits

Thomas Ruebsamen

, Tobias Pulls

and Christoph Reich

Cloud Research Lab, Furtwangen University, Furtwangen, Germany

Department of Mathematics and Computer Science, Karlstad University, Karlstad, Sweden

Keywords:

Cloud Computing, Security, Accountability, Digital Evidence.

Abstract:

Cloud accountability audits can be used to strengthen trust of cloud service customers in cloud computing by

providing reassurance regarding the correct processing of personal or conﬁdential data in the cloud. However,

such audits require various information to be collected. The types of information range from authentication and

data access logging to location information, information on security controls and incident detection. Correct

data processing has to be proven, which immediately shows the need for secure evidence record storage that

also scales with the huge number of data sources as well as cloud customers. In this paper, we introduce

Insynd as a suitable cryptographic mechanism for storing evidence for accountability audits in our previously

proposed cloud accountability audits architecture. We present our reasoning for choosing Insynd by showing

a comparison of Insynd properties with requirements imposed by accountability evidence collection as well

as an analysis how security threats are being mitigated by Insynd. Additionally, we describe an agent-based

evidence collection process with a special focus on security and privacy protection.

1 INTRODUCTION

Cloud Computing is known for its on demand com-

puting resource provisioning and has now become

mainstream. Many businesses as well as private in-

dividuals are using cloud services on a daily basis.

The nature of these services varies heavily in terms

of what kind of information is being out-sourced to

the cloud provider. More often than not that data

is sensitive, for instance when Personal Identiﬁable

Information (PII) is being shared by an individual.

Also, businesses that move (parts of) their processes

to the cloud, for instance by using a Customer Rela-

tionship Management Software as a Service provider,

are actively participating in a major paradigm shift

from having all data on-premise to moving data to the

cloud.

New challenges come along with this trend. Two

of the most important issues are customer trust

and compliance (Jansen and Grance, 2011; Pearson,

2011). These issues are closely tied to the loss of con-

trol over data. When moving to the cloud, direct con-

trol over i) where data is stored, ii) who has access to

it and iii) how it is shared and processed is given up.

Because of this loss of control, cloud customers

have to trust cloud providers that they treat their

data in an appropriate and responsible way. This in-

cludes providing information about data locality, iso-

lation, privacy controls and data processing in gen-

eral. One way to enable that trust is by strengthening

transparency and accountability (Haeberlen, 2009;

Weitzner et al., 2008) of the cloud provider and ser-

vices.

To regain information on the kind of data process-

ing, cloud audits can be used to check how it has been

done. An important part of cloud audits is evidence

collection. Depending on the data processing policies

in place, various sources of evidence need to be con-

sidered. Logs are a very important source of evidence,

when it comes to auditing the cloud operation (e.g.,

access logs and error logs). However, other sources of

information are also important, such as ﬁles or events

registered in the cloud management system. To cap-

ture evidence from this variety of sources, centralized

logging mechanisms are not enough. We therefore

propose a system for accountability evidence collec-

tion and audit. With this system, cloud providers are

enabled to demonstrate their compliance with data

handling policies to their customer’s and third-party

auditors in an automated way.

In our previous work, we introduced a sys-

tem (Ruebsamen and Reich, 2013) for cloud account-

ability audits, that enables automated collection of ev-

idential data in the cloud ecosystem with the goal of

321

Ruebsamen T., Pulls T. and Reich C..

Secure Evidence Collection and Storage for Cloud Accountability Audits.

DOI: 10.5220/0005408403210330

In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 321-330

ISBN: 978-989-758-104-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

performing accountability audits. A key mechanism

of this system is the secure and privacy-friendly col-

lection and storage of evidence. In our previous work

we also explored the use of a somewhat homomorphic

encryption scheme to secure evidence collected in the

evidence store (Lopez et al., 2014). In this paper, we

present a more practical alternative that imposes less

restrictions on evidence collection. The contributions

of this paper are:

• An architecture for automated evidence collection

for the purpose of cloud accountability audits

• A process for secure and privacy-protecting evi-

dence collection and storage

The remainder of this follow-up paper is struc-

tured as follows: in Section 2 we present related work

in the area of secure evidence collection and cloud au-

diting. The core principles of Insynd are introduced

in Section 3. Following that, we present in Section 4 a

mapping of typical characteristics of digital evidence

and secure evidence collection in the cloud to how

these are addressed by integrating Insynd in our audit

agent system. In Section 5 we describe the architec-

tural details of the Insynd integration. We present a

scenario-based informal evaluation of our system in

Section 6 and conclude this paper in Section 7.

2 RELATED WORK

Redﬁeld and Date propose a system called

Gringotts (Redﬁeld and Date, 2014) that en-

ables secure evidence collection, where evidence

data is signed at the system that produces it, before

it is sent to a central server for archival using the

Evidence Record Syntax. It is similar to our system

with respect to the automatic collection of evidential

data from multiple sources. However, their focus

is on the archival of evidence, whereas we propose

a system that also enables automated evidence

processing for audits. Additionally, our system also

addresses privacy concerns of evidence collection

in a multi-tenant environment such as the cloud by

introducing evidence encryption, whereas Redﬁeld

and Date focus on archival and preservation of

evidence integrity.

Zhang et al. (Zhang et al., 2013) identify potential

problems when storing massive amounts of evidential

data. They speciﬁcally address possible information

leaks. To solve these issues, they propose an efﬁcient

encrypted database model that is supposed to mini-

mize potential data leaks as well as data redundancy.

However, they focus solely on the storage backend

and do not provide a workﬂow that addresses secure

evidence collection as a whole.

Gupta (Gupta, 2013) identiﬁes privacy issues in

the digital forensics process, when it comes to data

storage devices that typically do not only contain in-

vestigation related data, but may also hold sensitive

information that may breach privacy. He also identi-

ﬁes a lack of automation in the digital investigation

process. To address these issues, Gupta proposes the

Privacy Preserving Efﬁcient Digital Forensic Investi-

gation (PPEDFI) framework. PPEDFI automates the

investigation process by including knowledge about

previous investigation cases, and which kinds of ﬁles

were relevant then. With that additional informa-

tion, evidence search on data storage devices is faster.

However, while Gupta acknowledges privacy issues,

the PPEDFI framework is focused on classic digital

forensics and may not be applicable to a cloud ecosys-

tem, where there is typically no way of mapping spe-

ciﬁc data objects to storage devices, in full.

The Security Audit as a Service (SAaaS) system

proposed by Doelitzscher et al. (Doelitzscher et al.,

2012; Doelitzscher et al., 2013) is used to monitor

cloud environments and to detect security incidents.

SAaaS is speciﬁcally designed to detect incidents in

the cloud and thereby consider the dynamic nature

of such ecosystems, where resources are rapidly pro-

visioned and removed. However, the main focus of

SAaaS is not to provide auditors with a comprehen-

sive way of auditing the cloud provider’s compli-

ance with accountability policies, which requires ad-

ditional security and privacy measures to be consid-

ered in the data collection process.

3 INSYND

Insynd is a cryptographic scheme where a forward-

secure author sends messages intended for clients

through an untrusted server (Pulls and Peeters, 2015b;

Pulls and Peeters, 2015a; Pulls et al., 2013). The

author is forward-secure in the sense that the author

is initially trusted but assumed to turn into an active

adversary at some point in time (Bellare and Yee,

2003). Insynd protects messages sent prior to au-

thor compromise. The server is completely untrusted,

which is possible thanks to the use of Balloon, a

forward-secure append-only persistent authenticated

data structure (Pulls and Peeters, 2015a). This means

that the server storing all messages can safely be out-

sourced, e.g., to traditional cloud services. Clients

are assumed trusted to read messages sent to them by

authors. Insynd contains support for clients to also

be in the forward-security model, by discarding key-

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

322

material as messages are read.

Insynd provides the following properties:

Forward Integrity and Deletion Detection. No-

body can modify or delete messages sent prior

to author compromise, as deﬁned by Pulls et

al. (Pulls et al., 2013). This property holds

independently for Balloon (the data structure)

and the Insynd scheme. For Balloon, anyone can

verify the consistency of the data structure, i.e., it

is publicly veriﬁable (Pulls and Peeters, 2015a).

Secrecy. Insynd provides public-key authenticated

encryption (An, 2001) thanks to the use of

NaCl (Bernstein et al., 2012).

Forward Unlinkability of Events. For each run by

the author of the protocol to send new messages,

all the events sent in that run are unlinkable. This

implies that, e.g., an attacker (or the server) can-

not tell which events belong to which client (Pulls

and Peeters, 2015b). When clients receive their

events by querying the server, if they take ap-

propriate actions including but not limited to ac-

cessing the server over an anonymity network like

Tor (Dingledine et al., 2004), their events remain

unlinkable.

Publicly Veriﬁable Proofs. Both the author and

client receiving a message can create publicly

veriﬁable proofs of the message sender (the au-

thor), the receiving client (by registered identity),

and the time the message was sent relative to

e.g. a time-stamping authority (Pulls and Peeters,

2015b). The proof-of-concept implementation

of Insynd uses Bitcoin transactions (Nakamoto,

2008) as a distributed time-stamping server.

Distributed Settings. Insynd supports distributed

authors, where one author can enable other au-

thors to send messages to clients it knows of with-

out requiring any interaction with clients. Client

identiﬁers (public keys) are blinded in the pro-

tocol, ensuring forward-unlinkable client identi-

ﬁers between different authors (Pulls and Peeters,

2015b).

Pulls and Peters show that Insynd provides for-

ward integrity and deletion detection, secrecy, pub-

licly veriﬁable proofs, and forward-unlinkability of

client identiﬁers in the standard model under the as-

sumptions of the decisional Difﬁe-Hellman (DDH)

assumption on Curve25519, an unforgeable signa-

ture algorithm, an unforgeable MAC, a collision

and pre-image resistant hash function, and the secu-

rity of the time-stamping mechanism (in our case,

the Bitcoin block-chain) (Pulls and Peeters, 2015b).

Forward unlinkability of events is provided in the

random oracle model under the DDH assumption

on Curve25519 (Pulls and Peeters, 2015b). The

prototype implementation of Insynd shows perfor-

mance comparable to state-of-the-art secure logging

schemes, like PillarBox (Bowers et al., 2014), secur-

ing syslog-sized messages (max 1KiB) in the order of

hundreds of microseconds on average on a commod-

ity laptop. We stress that Insynd is subject to its own

review and evaluation; in this paper, we use Insynd as

a building block to facilitate secure evidence collec-

tion and storage for cloud accountability audits.

4 AUDIT EVIDENCE STORAGE

REQUIREMENTS

In this Section, we present a comparison of general

evidence attributes, how they apply in the context

of evidence collection for cloud accountability audits

and how the integration of Insynd solves key issues in

evidence storage.

4.1 Requirements of Digital Evidence

In (Mohay et al., 2003) the core principles of any ev-

idence are described as:

Admissibility. Evidence must conform to certain le-

gal rules, before it can be put before a jury.

Authenticity. Evidence must be tieable to the inci-

dent and may not be manipulated.

Completeness. Evidence must be viewpoint agnostic

and tell the whole story.

Reliability. There cannot be any doubts about the ev-

idence collection process and its correctness.

Believability. Evidence must be understandable by a

jury.

These principles apply to common evidence as

well as digital evidence. Therefore, the evidence col-

lection process for audits has to consider special re-

quirements, which help in addressing these attributes

and ensure best possible validity in audits and appli-

cability in court.

In Table 1 we present a mapping of the previously

described evidence attributes and how they are sup-

ported by the integration of Insynd as a means of stor-

ing evidence records. We thereby focus on the key

properties of Insynd as described in Section 3.

Admissibility of digital evidence is inﬂuenced by

the transparency of the collection process and data

protection regulation. Digital evidence can be any

kind of data (e.g., e-mail messages, social network

messages, ﬁles, logs etc.). Insynd does not have any

SecureEvidenceCollectionandStorageforCloudAccountabilityAudits

323

direct inﬂuence on the admissibility of the evidence

stored in it.

Authenticity of digital evidence before court is

closely related to the integrity requirement put on ev-

idence records. Evidence may not be manipulated in

any way and must be protected against any kind of

tampering (willingly and accidentally). Insynd en-

sures that data cannot be tampered with once it is

stored.

Completeness is not directly ensured by Insynd,

but rather needs to be ensured by the evidence collec-

tion process as a whole. Especially important are the

deﬁnition of which evidence sources provide relevant

evidence that need to be considered during the col-

lection phase. Insynd can complement the evidence

collection process by providing assurance of that all

data stored in the evidence store are made available

as evidence, and not cherry-picked.

Reliability is indirectly supported by integrating

necessary mechanisms into the evidence collection

process, such as Insynd.

Believability of the collected evidence is not inﬂu-

enced by implemented mechanisms, but rather by the

interpretation and presentation by an expert in court.

This is due to judges and juries usually being non-

technical, which requires an abstracted presentation

of evidence. Insynd does not inﬂuence the believabil-

ity in that sense.

Table 1: Mapping the Impact of Insynd Properties to Evi-

dence Attributes.

Insynd

Forward

Integrity

and

Deletion

Detection

Publicly

Veriﬁable

Proofs

Admissibility

Authenticity

Completeness

Reliability

Believability

4.2 Privacy Requirements

Not all requirements that a secure evidence storage

has to fulﬁll can be captured by analyzing the at-

tributes of digital evidence. Other aspects have to be

taken into account to address privacy concerns. Pro-

tecting privacy in the process of evidence collection is

utmost importance, since the collected data is likely to

contain personal data. For cloud computing, one lim-

iting factor may be whether or not the cloud provider

is willing to provide deep insight into its infrastruc-

ture. Table 2 presents a mapping of privacy principles

and properties of our evidence process.

Below we summarise some key privacy principles:

Conﬁdentiality. of data evolves around mechanisms

for the protection from unwanted and unautho-

rized access. Typically, cryptographic concepts,

such as encryption, are use to ensure conﬁdential-

ity of data.

Data Minimization. states that the collection of per-

sonal data should be minimized and limited to

only what is strictly necessary.

Purpose Binding. of personal data entails that per-

sonal data should only be used for the purposes it

was collected for.

Retention Time. is concerned with how long per-

sonal data may be stored and used, before it needs

to be deleted. These periods are usually deﬁned

by legal and business requirements.

Insynd and our evidence process provides various

mechanisms that support these privacy principles.

Conﬁdentiality A central property of Insynd is that

it is always encrypting data using public-key cryp-

tography. By encrypting the evidence store, compro-

mising the privacy of cloud customer data that has

been collected in the evidence collection processes

becomes almost impossible by attacking the evidence

store directly. This goes as far as being able to safely

outsource the evidence store to an untrusted third-

party, a key property of Insynd (Pulls and Peeters,

2015b).

Data Minimisation Furthermore, Insynd provides

forward unlinkability of events and client identiﬁers,

as described in Section 3, which helps prevent several

types of information leaks related to storing and ac-

cessing data. Collection agents are always conﬁgured

for a speciﬁc audit task, which is very limited in scope

of what needs to be collected. Agents are never con-

ﬁgured to arbitrarily collect data, but are alway lim-

ited to a speciﬁc source (e.g., a server log) and data

objects (e.g., a type of log events).

Purpose Binding Neither Insynd nor our evidence

process can directly inﬂuence the purpose for which

collected data is used. Indirectly, the use of an ev-

idence process like ours, incorporating secure evi-

dence collection and storage, may serve to differen-

tiate data collected for auditing purposes with other

data collected e.g., for marketing purposes.

Retention time poses a real challenge. In cloud

computing, the precise location of a data object is

usually not directly available, i.e., the actual storage

medium used to store a particular block is unknown,

making data deletion hard. However, if data has been

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

324

encrypted before storage, a reasonably safe way to

ensure “deletion” is to discarding the key material

required for decryption. Insynd supports forward-

secure clients, where key material to decrypt mes-

sages are discarded as messages are read.

Table 2: Mapping of Insynd properties to Evidence Collec-

tion Requirements.

Insynd

Secrecy Forward

Unlink-

ability

Events

Forward

Unlink-

ability

of Re-

cipients

Con-

ﬁden-

tiality

Data

Minimi-

sation

Purpose

Binding

Data

Reten-

tion

In Section 6, we also describe the threat model for

the system described in this paper and present an eval-

uation of how Insynd is used to mitigate these threats.

5 SECURE EVIDENCE STORAGE

ARCHITECTURE

In this Section, we provide an architectural overview

of the integration of Insynd into a secure evidence col-

lection and storage process. We describe the overall

architecture and its components, how the components

of Insynd are mapped into the audit agent system and

which setup process is required to use Insynd for se-

curing evidence collection and storage.

5.1 Architecture

In this Section we discuss the architectural integra-

tion of Insynd as an evidence store in our audit sys-

tem. There are basically three different components

required to perform secure evidence collection. Fig-

ure 1 shows an overview of these components - Evi-

dence Source, Evidence Store and Evidence Process-

ing - as well as the ﬂow of data between them. From

the various sources of evidence in the cloud, evidence

records are collected that will be stored in the evi-

dence store on a per-tenant basis. The evidence store

is thereby located on a separate server. As previously

mentioned, the server may be an untrusted third-party

cloud storage provider. This is important to ensure so

that this approach scales well with a growing number

of tenants, evidence sources and evidence records.

Our architecture is built around using software

agents for evidence collection, evidence evaluation

and controlling the overall system. Agent technology

helps with extensibility by allowing us to easily intro-

duce new evidence sources and processors by build-

ing new agents. On top of that, it allows the audit sys-

tem to address rapid infrastructure changes, which are

very common in cloud infrastructures by easily de-

ploying and destroying agents when needed. We base

our system on the Java Agent DEvelopment Frame-

work (JADE, 2015). This effectively means that any-

where, where a Java runtime environment is available,

a collection agent can be deployed.

5.1.1 Evidence Collection

There are various evidence sources to be considered,

such as logs, cryptographical proofs, documentation

and many more. For each, there needs to be a suit-

able collection mechanism. For instance, a log parser

for logs, a tool for cryptographical proofs or a ﬁle re-

triever for documentation. This is done by a software

agent called Evidence Collection Agent that is speciﬁ-

cally developed for the data collection from the corre-

sponding evidence source. The collection agent acts

as an Insynd Author meaning it uses the Sender API to

store evidence into the Evidence Store. The encryp-

tion happens in the Sender API. Typically, this agent

incorporates or interfaces with a tool to collect evi-

dential data, for instance forensic tools, such as ﬁle

carvers, log parsers or simple search tools. Another

type of collection agent have client APIs implemented

to interface with more complex tools, such as Cloud

Management Systems (CMS). Generally, these agents

receive or collect information as input and translate

that information into an evidence record, before stor-

ing it in the Evidence Store.

5.1.2 Evidence Storage

From the Evidence Collection Agent, evidence

records are sent to the Evidence Store. The Evidence

Store is implemented by the Insynd Server. Since In-

synd functions as a key-value store for storing ev-

idence records (encrypted messages identiﬁed by a

key) NoSQL or RDBMS-based backend for persist-

ing evidence records can be used. All data contained

in the Evidence Store is encrypted. Each record is ad-

dressed to a speciﬁc receiver (e.g., an Evidence Pro-

cessing Agent). The receiver’s public key is used in

SecureEvidenceCollectionandStorageforCloudAccountabilityAudits

325

Figure 1: Evidence Collection, Storage and Processing Workﬂow.

the Sender API to encrypt the record on the Evidence

Store. This means that only the receiver is able to ac-

cess the evidence data from the Evidence Store. Iso-

lation between tenants in a single Evidence Store is

achieved by providing one container for each tenant

where his evidence records are stored. However, even

stronger isolation is also possible by providing a sep-

arate Evidence Store hosted on a separate VM. Addi-

tionally, Evidence records require a unique identiﬁer

in the Evidence Store to enable selective retrieval of

records. In our implementation, we use a combination

of a policy identiﬁer and a rule identiﬁer (where a rule

is part of a policy) to enable the receiver to reduce the

amount of records to receive to a manageable size.

5.1.3 Evidence Processing

Evidence Processing components are located at the

receiving end of this workﬂow. The Receiver API is

used by the processing agent (Insynd Client) to re-

trieve evidence records from the Evidence Store. The

receiver can request multiple records from a period

of time at once. The Client is also in possession

of the corresponding private key to decrypt evidence

records, which means records can only be decrypted

at the Client.

5.2 Identity Management and Key

Distribution

Since asymmetric encryption is such an important

part of our system, we describe the encryption key

distribution sequence next. In this software agent-

based system, the automated setup of key material

and registration with Insynd is particularly important.

Figure 2 depicts the initialization sequence of collec-

tion and processing agents with a focus on key distri-

bution.

In Figure 2 we introduce an additional component

beyond those already described in the general archi-

tecture: the Controller. The Controller serves as an

entry point that controls the agent setup and distribu-

tion process in the audit system. It is an important part

of the lifecycle management of the system’s agents

(e.g., creating and destroying of agents or migration

between platforms).

In Figure 2 we describe the initialization sequence

for a simple scenario, where a particular tenant wishes

to audit compliance with a policy and one rule in-

cluded in that policy in particular. The following steps

have to be performed to setup the evidence collection

and storage process for that particular rule:

1. In the ﬁrst step, a Processing Agent is created and

conﬁgured according to the input policy and rule

respectively for the tenant.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

326

Figure 2: Evidence Collection Setup Sequence.

2. During the setup phase, the Processing Agent

sets up a keypair at the Receiver API. The Re-

ceiver API is a RESTful service that holds pri-

vate key material and is therefore located at the

same servers hosting the Processing Agents (i.e.,

a trusted environment).

3. After the key material has been generated, the

Processing Agent registers itself as a recipient at

the Sender API. For this, it uses a unique identiﬁer

generated from the policy ID and the rule ID (i.e.,

policyID.ruleID).

4. In the last step, the Controller sets up the re-

quired Collection Agents and connects them with

the corresponding Processing Agents by using the

unique recipient identiﬁer.

Now, it is possible for the Collection Agents to

send evidence records to their corresponding Process-

ing Agents. The messages will be encrypted at the

Sender API service before storage, using the provided

recipient’s public key. The Processing Agent then

pulls the evidence records from the Evidence Store

using the Receiver API the records are decrypted us-

ing the receiver’s private key.

6 EVALUATION

In this Section we present an informal security eval-

uation of the system we have implemented for secure

evidence collection. We describe the evidence collec-

tion work ﬂow using a ﬁctitious scenario. By applying

the evidence collection and storage process to the set-

ting described in this scenario, we demonstrate how

the requirements stated in Section 4 are addressed.

Additionally, we provide a model that states threats

and adversaries to the process as well as the mitiga-

tion functions introduced by Insynd.

In this scenario, the CCOMP company is a cus-

tomer of the Infrastructure as a Service provider

CloudIA. In particular, we analyze the security prop-

erties of the evidence collection process by looking at

the data at rest as well as the data in transit protection

at any time during the ﬂow from the evidence source

to its processor. We thereby assume that CloudIA is

using OpenStack (OpenStack, 2015) as a its Cloud

Management System (CMS), since this a widely pop-

ular open source CMS, which we use for developing

our audit agent system. However, any other CMS

could be used as well as long as it provides the needed

monitoring interfaces.

6.1 Scenario

CloudIA is specialized in providing its customers

with virtualized resources in the form of virtual ma-

chines, networks and storage. CCOMP has out-

sourced most of its IT services to CloudIA. Among

them is a service that processes data of CCOMP’s cus-

tomers. For that data, CCOMP has to guarantee data

retention. CCOMP has identiﬁed snapshots to be one

major problem with respect to the data retention pol-

icy, since the virtual machine’s storage is duplicated

in the process. This means for CCOMP that in order

to be compliant with the data retention policy, a snap-

shot of that virtual machine may have a maximum

lifetime of one day, which limits its usefulness to e.g.,

backing up before patching. Now, we assume a trust-

worthy but sloppy administrator at CCOMP who cre-

ates a snapshot before patching software on the virtual

machine, but then omits deleting the snapshot after

he is done. However, an automated daily audit of its

cloud resources was put in place by CCOMP to detect

such compliance violations.

6.2 Implementation

The collection agent required for the above scenario

communicates with our OpenStack CMS to gather

evidence of the CMS behavior regarding virtual ma-

SecureEvidenceCollectionandStorageforCloudAccountabilityAudits

327

chine snapshots. The processing agent contains the

logic for detecting snapshot violations (i.e., base vir-

tual machine and a maximum age of the snapshot de-

rived from the retention policy). The collection agent

is deployed at the CMS controller node and has access

to OpenStack’s RESTful API. The processing agent

is located on the same trusted host as the controller

agent (see Figure 1 for reference). The evidence store

is located on a separate, untrusted virtual machine.

Now, the following steps are performed:

1. The collection agent opens a connection to the

OpenStack RESTful API on the same host and re-

quests a history of snapshot events for CCOMP’s

virtual machine. Despite there being no commu-

nication over the network, HTTPS is used to se-

cure the communication between the collection

agent and the CMS. Since the policy only requires

information about snapshots to be collected, the

CMS agent limits evidence record generation to

exactly that information, nothing more.

2. The collection agent sets up the receiver of the ev-

idence according to the process depicted in Fig-

ure 2 and sends the collected records to the evi-

dence store (Insynd). The communication chan-

nel is encrypted using HTTPS and the payload

(evidence records) is encrypted with the receiving

agent’s public key.

3. The processing agent pulls records from the ev-

idence store in regular intervals (e.g., every 24

hours), analyses them and triggers a notiﬁcation

of a detected violation. The communication be-

tween the processing agent and the evidence store

is secured using HTTPS.

4. In the last step, evidence records are deleted be-

cause their retention limit has been reached. This

is done by discarding the keys required for de-

cryption.

6.3 Threat Model

To demonstrate which security threats exist for the ev-

idence collection process and Insynd is used to miti-

gate them, we describe the threat model for this sys-

tem categorized according to the STRIDE(Microsoft

Developer Network, 2015) threat categorization:

• Spooﬁng Identity

• Tampering with Data

• Repudiation

• Information disclosure

• Denial of Service

• Elevation of Privilege

We have identiﬁed the following major threats to

the evidence collection and storage process:

• Unauthorized access to evidence (S,I): the protec-

tion of evidence from being accessed by unautho-

rized persons. Possible adversaries are a mali-

cious third-party evidence storage provider (cloud

service provider), another tenant (isolation fail-

ure) or an external attacker. Using Insynd for ev-

idence collection and storage addresses this threat

since recipients of messages are authenticated us-

ing appropriate mechanisms such as user creden-

tials for API authentication and public keys for en-

cryption.

• Data leakage (S,I): the protection from uninten-

tional data leakage. This could be caused by mis-

conﬁguration (e.g., unencrypted evidence being

publicly available). Using Insynd for evidence

collection and storage addresses this threat by en-

crypting data by default.

• Eavesdropping, (T,I): the protection of evidence

during the collection phase, especially in transit.

Possibly adversaries are another tenant (isolation

failure) or external attackers in case evidence is

transported to an external storage provider or au-

ditor. Using Insynd for evidence collection and

storage addresses this threat by using transport

layer as well as message encryption.

• Denial of Service (D): the protection of the ev-

idence collection and storage process from be-

ing attacked directly with the goal of disabling or

shutting it down completely (e.g., to cover-up si-

multaneous attacks on another service). Possible

adversaries are external attackers. This is a very

generic threat that cannot be addressed by a single

tool or control but rather requires a set a measures

(on the network and application layer) to enhance

denial of service resilience.

• Evidence manipulation (T,R,I): the protection

of evidence from intentional manipulation (e.g.,

deletion of records, changing of contents, manip-

ulation of timestamps). Possible adversaries are

malicious insiders and external attackers. Using

Insynd for evidence collection and storage ad-

dresses this threat, since Insynd provides tamper-

ing and deletion detection.

Some of these threats can be mitigated by imple-

menting appropriate security controls (i.e., using In-

synd for evidence transport and storage). It provides

effective protection by employing security techniques

described in Section 3.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

328

6.4 Requirements Evaluation

In this section, we evaluate the integration of Insynd

against the requirements described in Section 4. In

step 1 of the ﬁctitious scenario, the data minimiza-

tion principle is being followed because the special-

ized agent only collects evidence on the existence of

snapshots.

This workﬂow is secure as soon as the collection

agent inserts data into the evidence store in step 2.

More precisely, evidence records are tamper-evident

and encrypted. This is true, even though the evi-

dence is actually stored on an untrusted virtual ma-

chine. The only way to compromise evidence now,

is to attack the availability of the server hosting the

Insynd server.

When the processing agent in step 3 retrieves

records for evaluation, it can be assured of the au-

thenticity of the data and that it has been provably col-

lected by a collection agent. Since evidence records

may be subject to maximum data retention regulation,

records that are not needed anymore are deleted.

As previously mentioned in Section 5 we use

JADE as an agent runtime. To secure our system

against non-authorized agents, we use the TrustedA-

gents add-on for the JADE platform. This ensures that

only validated agents are able to join our runtime en-

vironment. This effectively prevents agent injection

attacks, where malicious agents could be inserted at

either the collection or processing side to compromise

our system.

As can be seen, the evidence records are protected

all the way from the evidence source to the processing

agent using only encrypted communication channels

and having an additional layer of security (message

encryption) provided by Insynd. Additionally, while

the evidence is being stored, it remains encrypted.

6.5 Scalability

Obviously, since there is a vast amount of evidence

sources and therefore a potentially equal number of

collection agents, ensuring the scalability of the pro-

cess and the implementation is very important. This

has been considered very early in the design process

by choosing an software agent-based approach for the

system architecture. Software agents are inherently

distributable and allow for complex message ﬂow

modeling in an infrastructure. Therefore, the core

components evidence collection, storage and process-

ing become distributable as well. In our future work,

we’ll focus on the scalability aspects. We will fol-

low a methodology where we focus on the following

technical key scalability indicators:

• Data transfer volume: amount of evidence data

being transferred over the network

• Message volume: amount of evidence message

transmissions over the network

• Storage volume: amount of storage required for

evidence

• Encryption overhead: performance impact intro-

duced by encryption and decryption

Based on the identiﬁed performance impact of

each of these indicators, in the second step, we model

different message ﬂow optimization strategies to alle-

viate their impact and ensure scalability.

7 CONCLUSIONS

In this paper, we presented our system design and im-

plementation for secure evidence collection in cloud

computing. The evidence provides the general basis

for performing cloud accountability audits. Account-

ability audits take a large variety of evidence sources

and data processing requirements into account.

We showed what the requirements for a secure

evidence collection process are and demonstrated

how these issues are addressed by incorporating In-

synd into our system. We described how the core prin-

ciples of digital evidence are addressed by our system.

Additionally, we considered data protection princi-

ples for the evidence collection process, how they in-

ﬂuence our approach and how they are addressed in

our system by integrating Insynd. For this, we pre-

sented the relevant architectural parts of our proto-

type.

In our future work, we will focus on the scalabil-

ity of our audit system in general and the scalability

of the components involved in evidence collection in

particular. For that reason, we will focus on the dis-

tribution of the audit system and evidence collection

not only in the same domain (i.e., in the same infras-

tructure), but also taking into account outsourcing and

multi-provider collection scenarios.

ACKNOWLEDGEMENTS

This work has been partly funded from the Euro-

pean Commissions Seventh Framework Programme

(FP7/2007-2013), grant agreement 317550, Cloud

Accountability Project - http://www.a4cloud.eu/ -

(A4CLOUD).

SecureEvidenceCollectionandStorageforCloudAccountabilityAudits

329

REFERENCES

An, J. H. (2001). Authenticated encryption in the public-key

setting: Security notions and analyses. IACR Cryptol-

ogy ePrint Archive, 2001:79.

Bellare, M. and Yee, B. (2003). Forward-security in private-

key cryptography. In Topics in Cryptology—CT-RSA

2003, pages 1–18. Springer.

Bernstein, D. J., Lange, T., and Schwabe, P. (2012). The

security impact of a new cryptographic library. In

Hevia, A. and Neven, G., editors, Progress in Cryptol-

ogy - LATINCRYPT 2012 - 2nd International Confer-

ence on Cryptology and Information Security in Latin

America, Santiago, Chile, October 7-10, 2012. Pro-

ceedings, volume 7533 of Lecture Notes in Computer

Science, pages 159–176. Springer.

Bowers, K. D., Hart, C., Juels, A., and Triandopoulos, N.

(2014). PillarBox: Combating Next-Generation Mal-

ware with Fast Forward-Secure Logging. In Research

in Attacks, Intrusions and Defenses Symposium, vol-

ume 8688, pages 46–67. Springer.

Dingledine, R., Mathewson, N., and Syverson, P. F. (2004).

Tor: The second-generation onion router. In Blaze,

M., editor, Proceedings of the 13th USENIX Security

Symposium, August 9-13, 2004, San Diego, CA, USA,

pages 303–320. USENIX.

Doelitzscher, F., Reich, C., Knahl, M., Passfall, A., and

Clarke, N. (2012). An Agent Based Business Aware

Incident Detection System for Cloud Environments.

Journal of Cloud Computing: Advances, Systems and

Applications, 1(1):9.

Doelitzscher, F., Ruebsamen, T., Karbe, T., Reich, C., and

Clarke, N. (2013). Sun behind clouds - on automatic

cloud security audits and a cloud audit policy lan-

guage. International Journal On Advances in Net-

works and Services, 6(1 & 2).

Gupta, A. (2013). Privacy preserving efﬁcient digital foren-

sic investigation framework. In Contemporary Com-

puting (IC3), 2013 Sixth International Conference on,

pages 387–392.

Haeberlen, A. (2009). A case for the accountable cloud.

In Proceedings of the 3rd ACM SIGOPS International

Workshop on Large-Scale Distributed Systems and

Middleware (LADIS’09).

JADE (2015). Java Agent DEvelopement framework.

http://jade.tilab.com.

Jansen, W. and Grance, T. (2011). Sp 800-144. guidelines

on security and privacy in public cloud computing.

Technical report, Gaithersburg, MD, United States.

Lopez, J., Ruebsamen, T., and Westhoff, D. (2014).

Privacy-friendly cloud audits with somewhat homo-

morphic and searchable encryption. In Innovations for

Community Services (I4CS), 2014 14th International

Conference on, pages 95–103.

Microsoft Developer Network (2015). The Stride

Threat Model. https://msdn.microsoft.com/en-

US/library/ee823878(v=cs.20).aspx.

Mohay, G. M., Anderson, A. M., Collie, B., de Vel, O., and

McKemmish, R. D. (2003). Computer and Intrusion

Forensics. Artech House, Boston, MA, USA. For

more information about this book please refer to the

publisher’s website (see link) or contact the authors.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic

cash system. Consulted, 1(2012):28.

OpenStack (2015). Openstack. http://www.openstack.org/.

Pearson, S. (2011). Toward accountability in the cloud. In-

ternet Computing, IEEE, 15(4):64–69.

Pulls, T. and Peeters, R. (2015a). Balloon: A

forward-secure append-only persistent authenticated

data structure. Cryptology ePrint Archive, Report

2015/007.

Pulls, T. and Peeters, R. (2015b). Insynd: Secure one-

way messaging through Balloons. Cryptology ePrint

Archive, Report 2015/150.

Pulls, T., Peeters, R., and Wouters, K. (2013). Distributed

privacy-preserving transparency logging. In Sadeghi,

A.-R. and Foresti, S., editors, WPES, pages 83–94.

ACM.

Redﬁeld, C. M. and Date, H. (2014). Gringotts: Secur-

ing data for digital evidence. In Security and Privacy

Workshops (SPW), 2014 IEEE, pages 10–17.

Ruebsamen, T. and Reich, C. (2013). Supporting cloud ac-

countability by collecting evidence using audit agents.

In Cloud Computing Technology and Science (Cloud-

Com), 2013 IEEE 5th International Conference on,

volume 1, pages 185–190.

Weitzner, D. J., Abelson, H., Berners-Lee, T., Feigenbaum,

J., Hendler, J., and Sussman, G. J. (2008). Information

accountability. Commun. ACM, 51(6):82–87.

Zhang, R., Li, Z., Yang, Y., and Li, Z. (2013). An efﬁcient

massive evidence storage and retrieval scheme in en-

crypted database. In Information and Network Secu-

rity (ICINS 2013), 2013 International Conference on,

pages 1–6.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

330