14
Digital Evidence Management, Presentation, and Court Preparation in the Cloud: A Forensic Readiness Approach

Lucia De Marco, Nhien‐An Le‐Khac, and M‐Tahar Kechadi

University College Dublin, Dublin, Ireland

14.1 Introduction

In the modern IT era, computation capability is delivered through computing services. This name became popular with the public when the Service Oriented Architecture and Web Services (SOA‐WS) spread in the 1990s (Alonso et al. 2004). The concept of delivering IT and computation capabilities through a network dates back to the late 1960s. In 1969, J.C.R. Licklider, who contributed to the development of the Advanced Research Projects Agency Network (ARPANET), promoted the concept of an intergalactic computer network (Lee et al. 1992). Such a scientist had a vision and a hope that in the future every individual would have access to data and applications from anywhere. In 1961, the computer pioneer John McCarthy predicted that computation may someday be organized as a public utility (Foster et al. 2008).

Cloud computing service architecture is designed to provide a computing environment that utilizes virtual resources that dynamically allocate the underlying physical resources. The result is to balance the load and to scale resource provisioning up and down in order to guarantee some services execution that satisfy the needs of the end users. Cloud services can be seen as an evolution of SOA‐WS services; the Cloud is taking their advantages to build its service architecture.

However, the ease of access to such resources is exploited by criminals who design more sophisticated and targeted methods to hack any type of digital device, or to exploit existing computing platforms for illegal activities. Hence, cloud forensics (CF) (Ruan et al. 2011a) deals with the management of crimes committed on cloud platforms or that used the Cloud as means to commit crimes. Cloud architecture novelties lead forensic practitioners to deal with a computing infrastructure that cannot be investigated with traditional forensic tools and procedures. Nevertheless, practitioners are required to manage cloud evidence respecting the admissibility and reliability principles of digital evidence (Casey 2011). Some cloud features have been used to build a cube model for CF (Ruan et al. 2011a), which is composed of technical, organizational, and legal dimensions. The technical dimension deals with tools and procedures for performing forensic investigations; the organizational dimension is concerned with the manner of establishing a forensic capability; e.g., the roles and the responsibilities to assign to a cloud organization. Finally, the legal dimension covers issues of multi‐jurisdiction, multitenancy, and service‐level agreement (SLA) policies.

Recently, cloud architectures have generated some challenges for law enforcement (Birk and Wegener 2011; Plunkett et al. 2015) due to the lack of aforementioned and efficient models and processes in terms of digital evidence management, presentation, and court preparation. Research scientists have proposed the idea of providing a computing infrastructure with a capability to make it ready and prepared for forensic investigations and procedures, called digital forensic readiness (DFR) (Tan 2001). The principal aim of a dedicated system is identifying, collecting, and storing critical data coming from the underlying computing infrastructure, which is the potential evidence. Hence, in this chapter, we present the capability of using forensics readiness for cloud computing.

14.2 Cloud Forensics and Challenges

14.2.1 Technical

Cloud services are elastic, meaning they are provisioned and released based on users' scaling demands. The services run on a cloud infrastructure composed of multiple machines located potentially in different geographical zones without precise routing information; the resources are virtualized by using virtual machine managers (VMMs) (Mell and Grance 2011). From a forensic perspective, these features result in a reduced access to data, because providers intentionally hide data locations to facilitate ubiquitous access and replicas. Furthermore, physical control of the architecture components is lacking; it varies for the three services models, becoming larger when a customer moves to the bottom of the architecture. Another issue of cloud architectures concerns the heterogeneity of log files: because there is no standard format; each provider can customize their own log type. There is no timestamp synchronization among data centers and servers under a single provider scope or among different providers' components.

14.2.2 Organizational

Conducting a forensic investigation in the Cloud might involve data and service information belonging to both providers and customers. There might also be situations where cloud providers outsource some services from third parties, and thus the scope of an investigation becomes wider. Moreover, such outsourced services can be based on a cloud architecture; hence all the issues related to the replication of data on multiple data centers located potentially under different physical jurisdictions escalates. The lack of legal expertise specific to these features determines that there is considerable uncertainty about the measures to undertake in case of cross‐providers or third‐party suppliers of resources.

14.2.3 Legal

Cloud physical resources are virtualized to be used by multiple consumers via a multitenant model; they are also dynamically assigned according to demand. The principal issue is the trade‐off between multitenancy and tenants' data privacy, i.e. what the correct trade‐off is to guarantee multitenancy and at the same time preserve tenants' data privacy. Another side effect of on‐demand elasticity is the spread of customers' and providers' data under different jurisdictions; in most cases, the SLAs also do not include information about the manner for determining data ownership or what jurisdiction to consider: the one related to the physical location of the customer, or to providers' machines, and which provider; in this case, contracts might be tailored to include proper constraints. Few proposals exist in the literature discussing and addressing this issue (Orton et al. 2012; Ryder and Le‐Khac 2016).

14.3 Digital Forensics Readiness

In digital forensics, some scientists proposed the idea of providing a computing infrastructure with a capability to make it ready and prepared for forensic investigations when required. Such a capability is called digital forensic readiness (DFR), and it was introduced by (Tan 2001). The author defined DFR as “the ability of an organization to maximize its potential to collect digital evidence and minimizing the costs of an investigation.” In order to prepare computing architectures for forensics, a readiness capability must be imagined as the provisioning of an information system communicating with such architectures.

A crime may happen; thus, the pure sense of such a capability is to render a digital context proactively for something that can theoretically never take place. This consideration may lead the reader to doubt about the effectiveness of DFR: specifically, if such a capability is dedicated to performing activities whose output might never be utilized. What the incentive is for spending effort to design and implement a dedicated system is a legitimate question. Positive side effects of DFR are to provide an approach for addressing some issues of digital forensics and enhancing some security and privacy issues of a computing environment. In 2004, a few years after DFR was introduced, (Rowlingson 2004) proposed a 10‐step process designed for organizations willing to implement DFR. The process includes some key activities necessary for gathering potential digital evidence complying with the admissibility and reliability principles for court cases. It places emphasis on the features that a forensics readiness system needs to be effective.

An interesting approach for managing forensics readiness is discussed in (Reddy and Venter 2013). The examined issues deal with human, technical, and departmental management problems for implementing a DFRS in large organizations. The examination leads the authors to propose a solution composed of frameworks rather than ad hoc systems. Such a novel architecture is provided for assisting the realization of an optimal level for managing DFR. It is composed of detailed functional requirements determined by a literature survey, and it is also supported by an early proof‐of‐concept prototype system to demonstrate that it is feasible. Other work stressed the importance of a DFR capability in order to enhance the internal security of an organization. (Grobler and Louwrens 2007) examined the overlap between the DF and some information security (IS) best practices. The consideration made is that some DF aspects can be considered as IS best practices missing event‐prosecution procedures. These best practices excluded the requirements for the preservation of digital evidence necessary for investigations. Organizations adopting the actual best practices cannot prosecute events and information related to security controls. In the authors' opinion, DFR is the solution for implementing and respecting the legal admissibility guidelines of evidence gathered during investigation procedures. A dedicated system can enrich the security strategies of an organization; this is justified by the main feature of providing a way to prepare the existing computing infrastructure for incident handling by collecting potential digital evidence. Thus, DFR is a good candidate to become a component of the IS best practices, demonstrating that protecting valuable company information resources is critical. (Endicott‐Povsky and Frinckle 2007) discussed several network forensics aspects. The authors analyzed some situations when cyber targets are powerless with respect to attackers and intruders exploiting and disrupting networks. The authors affirmed that forensics readiness for network infrastructures can be a valuable solution in order to decrease the power of such attacks. Thus, a theoretical framework to implement network forensics readiness in enterprise contexts is proposed. (Danielsson and Tjostheim 2004) discussed the availability of digital evidence. It must be collected in a proper and proactive manner in order to make the investigations effective and successful. For this purpose, a DFR capability must be implemented in an organization, and it must follow a structured approach. Its implementation includes several features regarding national and international legislation, together with their constraints and requirements about data collection and preservation, and user data privacy protection. Such an approach aims to proactively seek the sources of digital evidence and to configure the existing computing infrastructure for collecting and preserving potential evidence. The proposal takes into account relevant and established standards and best practices; nevertheless, it considers some existing organizational routines, such as data‐collection operations performed for purposes different from forensics, which can record events related to potential crimes. Finally, it provides guidance for reporting incidents to law enforcement, including the content, the format, the criteria for the report, and the manner in which the interaction between law enforcement and the affected parties is regulated. Again, the impact of DFR on a corporate context was analyzed by (Pangalos et al. 2010), where some positive aspects were highlighted, e.g. the enhancement of the security strategy of an organization, the reduction of security incidents, the availability of evidence, and the derived effectiveness of an investigation. (Mouton and Venter 2011) discussed another proposal for implementing forensics readiness capability that concerns wireless sensor networks. A dedicated prototype was designed as an additional layer to the existing infrastructure in order to avoid modifying the original architecture of an existing IEEE 802.15.4 network. The prototype was designed according to a list of requirements that have not been tested in real wireless sensor network scenarios. Thus, the requirements' usability has been tested through a prototype implemented as an additional layer of the network architecture. A DFR capability is considered crucial and necessary to be provided also to cloud computing architectures through a dedicated system (Ruan et al. 2013). It is responsible to perform proactive forensic investigations activities; doing so offers positive side effects, such as increased security and control over data access.

(Valjarevic and Venter 2011) discussed a forensics readiness capability for Public Key Infrastructure (PKI). A PKI system is a set of hardware, software, people, policies, and procedures necessary to create, manage, store, distribute, and revoke digital certificates. These systems are used to implement information system security services such as authentication and confidentiality. The authors investigated a set of policies, guidelines, and procedures, together with a model for implementing a forensics readiness framework for such systems. Some requirements for either preserving or improving information security and at the same time not altering the existing business processes of such PKI systems is the analyzed and addressed issue.

A DFR capability is shaped as an information system communicating with a computing architecture. The main aim is collecting and monitoring sensitive and critical information potentially related to digital crimes before they happen, leading to savings of time and money for the investigations. Data is closely related to the system artifacts and logging tools available. The collected data should be encrypted in order to guarantee more protection and stored in a place accessible by appropriate subjects.

The reason to shape a capability with an information system is driven by the necessity to represent something abstract, as a capability is, with something else that can be seen, as an information system is (Sommerville and Sawyer 1997). Nevertheless, with the execution of a process, some output can be generated; they are related to proactive forensic tasks aimed to prepare an infrastructure for possible investigations.

Such outputs are the mere operations of the capability: they compute input data collected from the monitored infrastructure. This information is composed of log files and additional system artifacts related to them, because they can hide facts related to digital crimes, or close to their happening. The relation of this data to crimes will be defined in the following. The reason data must be encrypted and stored in a place different from where it is gathered relies on forensic best practices described in (ACPO 2012), which provides details about evidence‐admissibility principles, among other procedures. Finally, as mentioned in (De Marco et al. 2013), the provided definition for DFR is considered general and adaptable to every computing infrastructure; hence it is valid for both the past and the future, as well as for the mentioned cloud infrastructures.

14.4 Cloud Forensics Readiness

A forensics readiness capability must be provided to cloud computing architectures because, due to their escalating popularity, they can be the object of several attacks; thus, a way to conduct forensic investigations effectively, e.g. saving time, money, and resources, must be designed. A result of a recent survey conducted by (Ruan et al. 2011b) can corroborate these needs; indeed, almost 90% of the interviewees familiar with digital forensics stated that “a procedure and a set of tool‐kits to proactively collect forensic‐relevant data in the cloud is important.” (Dykstra and Sherman 2012) analyzed some existing forensic tools such as EnCase in a cloud context; the result confirmed that the data collected by those tools is unreliable, because some cloud features require more effort for performing forensics than simply tailoring existing tools and procedures. The reason for this need is that new technical requirements must be managed for complying with the legal principles required for digital evidence. The same authors proposed a proper remote forensic acquisition suite of tools for an open source cloud environment (Dykstra and Sherman 2013). This suite, named FROST, provides a forensic capability for the Internet‐as‐a‐Service (IaaS) level of OpenStack, an open source cloud computing platform. FROST performs data collection from provider machines and from the host operating system, and makes the data available to users, because it is assumed that customers are cooperative during investigations. The data collected in FROST include VM images, logs coming from application programming interface (API) requests, and OpenStack firewall logs. This suite is considered by the authors as a way to enhance forensics readiness in the Cloud because it performs the necessary investigation‐preparation activities, such as data collection. Also, in (Trenwith and Venter 2013), a means of achieving DFR in the Cloud is described. It is composed of a remote and central logging facility for accelerating the acquisition of data; the model was also prototyped for Windows platforms.

14.4.1 Reference Architecture for a Cloud Forensics Readiness System: An Attempt

A reference architecture provides a general approach and understanding about the necessary operations that a cloud forensics readiness system (CFRS) must perform at a higher level of abstraction. Its main advantage resides in its design, which is not constrained by any specific and/or technical configuration; rather, it is flexible and customizable, and it can be considered a template for most organizations and cloud service providers that will implement a forensics readiness capability. The forensics readiness system is designed to communicate with an existing cloud infrastructure without altering the original components. It includes two main subsystems; the first is a forensic database, dedicated to the collection of cloud services information (the potential evidence). Such data is classified depending on the type; the possible types are monitored data, services' artifacts, and forensic logs; dedicated subsystems are included in the architecture design. The monitored data subsystem refers to information coming from cloud facilities dedicated to data monitoring and control (https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf.); e.g. database‐ and file‐activity monitoring, URL filtering, data‐loss prevention, digital rights management system, and content discovery system. The database‐ and file‐activity monitoring tools are capable of recognizing whenever a huge amount of data is pushed into the Cloud or replicated, thus indicating a data migration. The data‐loss prevention facility is used for monitoring data in motion; it also manages policies and rights. URL filtering controls customers' connections to cloud services, thus it can be used during the reconstruction of a case timeline. The digital rights management system implements and monitors customers' rights and restrictions with regard to data, as stated by the SLAs and terms‐of‐use contractual clauses cosigned by providers and customers; the content‐discovery system includes tools and processes aimed to identify sensitive information in storage components of a cloud architecture, and hence their output can allow the identification of some data violations or misuses. The forensics artifacts subsystem is dedicated to the storage of a significant quantity of artifacts gathered from the provider side, i.e. from Software‐as‐a‐Service (SaaS), VM images, and single sign‐on logs; from Platform‐as‐a‐Service (PaaS), system states, and application logs; and from IaaS, snapshots, and the running system memory. Cloud auditor and error logs coming from VM hypervisors are instead collected by the forensic log; both of them are relevant for incident‐response procedures and crime investigations. Also, some information from the cloud carrier has to be considered in the forensic log module. A cloud carrier is an intermediate between customers and providers, responsible for providing connectivity and transport of services to customers through the network and other access devices (Ruan and Carthy 2012). Therefore, some information suitable for forensic investigations includes network logs, activity logs, access record facility logs, hypervisor event logs, and virtual images. The second main component of the cloud forensics readiness system is the readiness core module, which performs different activities on the gathered data, executed by dedicated subsystems. The collected data is encrypted and stored by dedicated subcomponents, i.e. data encryption and data storage, respectively. The data‐management module performs forensic analysis and knowledge extraction with the purpose of reconstructing a correct and reliable event timeline about the recorded information. Finally, the chain‐of‐custody report necessary for case resolution is performed by the chain‐of‐custody subsystem. A communication and data‐exchange channel is necessary between the cloud infrastructure and the forensics readiness system, and also among the several subsystems. For this purpose, the Open Virtualization Format (OVF) standard language (http://www.dmtf.org/standards/ovf) is considered suitable for the design and the distribution of the system. This standard language is capable of creating and distributing software applications to be executed on different VMs, independently from the hypervisors and from the CPU architectures. Moreover, it exploits the XML standard to establish the configuration and installation parameters; it can be extended for future VM hypervisor developments and is thus considered extremely flexible and adaptable for future versions of a forensics readiness system. In the reference architecture, the OVF communication channel between the Cloud and the system can be used to convert data formats into a specific target one, in order to render the necessary information readable and usable by the system.

14.4.2 Operations in a CFRS

The initial activity of a cloud forensics readiness system is data collection. The valuable forensic data includes cloud service artifacts and output from some existing cloud monitoring tools (Cloud Security Alliance 2011). Data is gathered from the Cloud and manipulated outside the architecture. In order to accomplish the UK (ACPO 2012) guideline, for example, concerning the preservation of potential digital evidence, the collected data has to be copied and secured to avoid tampering. This is performed by dedicated data‐storage and ‐encryption subsystems, where proper digital signature and data‐securing routines are implemented. This step is necessary for preserving the original copies when forensic activities are performed. The entire system's activities and modules are constantly running and collecting the most up‐to‐date data. All this information is fed into the intrusion detection subsystem, which is responsible for relating the available information, in order to detect suspicious behaviors. This subsystem has to consider the cosigned SLAs clauses (Mell and Grance 2011) necessary for correctly detecting contractual violations. The intrusion detection system component communicates with the event‐alerting subsystem, as it generates alarms as soon as suspicious behaviors and contractual violations are detected. Such alarms might be different depending on the type of events, but this is out of the scope of a forensics readiness capability. The data‐mining module is responsible for extracting hidden knowledge necessary to generate the incident‐related evidence, and to relate the data and the sequence of events that have happened and are happening, leading to the construction of a correct and reliable timeline. The evidence must be treated considering guidelines, best practices, and laws used in court admissibility for case prosecutions. For this purpose, proper and dedicated policies and routines are implemented in the preservation‐of‐digital‐evidence module. Some information related to them, e.g. location, treatment, date, time, time zone, and system component, must be recorded (Boucher and Le‐Khac 2018) in order to maintain a reliable chain of custody necessary for prosecution purposes, which is performed by the chain of custody subsystem. The CFRS has to be communicative with the possible competent bodies involved in criminal case management, which can mean transmitting necessary information related to the detected case, such as a contractual violation. The competent bodies can be private or public incident responses; thus, dedicated communication interfaces with their information systems become necessary where the competent bodies are incident responses and law enforcement.

14.4.3 Forensics Readiness System Constraints

In order to benefit the most from the presented FR system, some constraints must be verified. Initially, the cloud infrastructure to be furnished with such a capability must provide the necessary monitoring tools to gather the data, considered common components to most cloud providers (Cloud Security Alliance 2011), and therefore, their presence should be verified. These are as follows:

  • Components dedicated to the monitoring of both databases and files, necessary for detecting data migrations.
  • Tools for filtering URLs, aimed to verify the connections made by different IP addresses.
  • Tools with the purpose of controlling policies and rights established by the cosigned contracts.

High importance is also assigned to potential evidence data sources. This encompasses several logs generated by appropriate logging facilities present in cloud architectures, as well as system images gathered through dedicated tools. Another requirement concerns the capability of installing the necessary OVF communication channels, responsible for data transmission. From both an organizational and legal perspective, these communication channels should require authorization for data exchange. In this manner, the involved cloud actors will be warned, and eventual privacy violation threats can be managed.

14.4.4 CFRS Advantages

The implementation and use of a forensics readiness system for cloud computing architectures are very important for multiple purposes. Implicitly, the first aim is making a cloud infrastructure ready for digital forensics by executing the operations described. One of the system side effects is the enhancement of cloud customers' data privacy, together with major internal security; this can happen because wider control and monitoring will be performed by the system to protect critical and sensitive information (De Marco et al. 2013). Nevertheless, the reconstruction of a case's timeline accompanied by a related chain‐of‐custody document is the biggest contribution of such added value. A cloud organization or provider might realize that being prepared to manage crimes or incidents can be vital for both the reliability and the reputation of the offered services; indeed, a proactive gathering of digital evidence minimizes the impact of a forensic investigation on a cloud organization's routines and performance (Rowlingson 2004). The detection of SLA clause violations can be managed by a CFRS. The subsystem dedicated to event reconstruction should be capable of determining a source of attack or the exact time when a customer data violation happened, relating them to specific service levels described in an SLA. The implementation of a CFRS can also be helpful to address cloud challenges for forensics as described earlier. A means of aligning multiple log file formats and synchronizing several machines' timestamps should be implemented; such a solution can lead to a correct, reliable reconstruction of event timelines, not necessarily related to crimes, but also to process executions. From a cloud forensics organizational perspective, the use of such a system can be the means to assign roles and responsibilities necessary for managing cloud incidents, such as investigator or incident handler; the people trained for the system can be responsible of some system modules and the manner in which data is managed in the cloud organization. Finally, from a legal point of view, a CFRS can highlight the main issues regarding jurisdiction borders; it can become the instrument for alerting proper governmental institutions, helping to address a more general problem.

14.5 Forensics Readiness in Evidence Management, Presentation, and Court Preparation

A digital forensics investigation (DFI) is defined as a process of collecting, identifying, preserving, analyzing, and presenting digital evidence in a manner that is legally acceptable (McKemmish 1999). The best‐known and most‐used DFI definitions have been proposed by the National Institute of Standards (NIST) (Kent et al. 2006). The main phases of such DFI processes are collection, examination, analysis, and reporting of media and digital evidence. Since a standard for DFI processes does not exist, several models have been proposed in the literature during the last few years (Agarwal et al. 2011; Alharbi et al. 2011; Baryamureeba and Tushabe 2004; Pollitt 2007; Yusoff et al. 2011). Each of them consists of a number of phases and subphases.

From the analysis viewpoint, few characteristics can be derived from the proposed DFI models. First, the computer architecture is not a mandatory feature for designing a new DFI, but it would be preferable for this to be expressed, in order to have a reliable basis for specific computing environments. Moreover, it would be more complete to also include the actors/stakeholders in order to assign responsibilities and to schedule the investigation phases in the most appropriate way and without overlapping. The common features discussed in the previous section should be considered in future models. The manner in which forensics readiness is conceived is very close to a preparation activity, present in 13 process models, by including preventive data‐collection operations from the target computing architectures.

14.5.1 SLA in Cloud Forensics Readiness

14.5.1.1 Service Level Agreements

Information systems and computing capabilities are delivered through the Internet in the form of services; they are regulated by a SLA contract (Ford 1996) cosigned by a generic application service provider (ASP) and the end user(s), as happens for instance in the Cloud (Mell and Grance 2011). In such a contract, several clauses are established; they concern the level of services guaranteed, also known as quality of service (QoS) parameters, and the penalties to apply in case the requirements are not met during the SLA validity time, among others. SLA contracts are written in natural language and may be personalized by idioms, so that a different lingual version may exist for each of them. An SLA's validity begins when a customer is looking for a particular (set of) service(s), and it finishes when such provisioning is terminated. During this time period, both parties are responsible for respecting the clauses, due to the legal value of the document (Baset 2012). Therefore, a dedicated contract‐management facility should be part of the service provisioning because of the contractual importance and contents (Cloud Security Alliance 2013). Some effort has been made in the literature to address this challenge, as discussed in the following sections. In particular, different metrics are exploited to measure specific contractual constraints concerning nonfunctional requirements of services, such as availability or performance indicators included in the contracts.

14.5.1.2 Service Level Agreement Interaction

In the Cloud, SLAs are cosigned between a provider and a customer that subscribes to a service. Additional SLAs can exist in other circumstances: for example, SLAs cosigned among different providers for hardware and software outsourcing, or SLAs involving third parties. Usually, customers are unaware of the complete data flow among different subproviders; this is because the chain of subservices necessary to accomplish an activity and the related SLAs are not disclosed to unconcerned parties.

An SLA is composed of a set of clauses, which describe all the constraints, behaviors, and duties of the cosigner parties in order to guarantee the level of the predefined services. For instance, some clauses concern the metrics necessary for measuring the described service‐level attributes, such as latency or average transmission error rate. In this chapter, an analysis of the SLA's contents is discussed, together with a classification of some contractual contents in a cloud forensics readiness context.

14.5.1.3 Contractual Constraints

The structure of an SLA may differ from one cloud service provider to another. However, such a contract is composed of several sections. Among these sections, an SLA can be structured as a set of service‐level objectives (SLOs). In a European Union guideline document (European Commission 2014), SLOs are catalogued based on the following factors:

  • Performance
  • Security
  • Data management
  • Personal data management

The focus of this section is to outline the SLOs necessary for DFR. The approach undertaken is composed of a number of steps. Initially, the presence of the SLOs mentioned in (European Commission 2014) has been verified in most public cloud service providers that have accessible SLAs. The annual list of the 100 most important cloud providers published by the top news source CRN has been utilized for this purpose. After the selection has been made, as described later, the resulting SLOs are matched with the cloud threats discussed in a CSA report (https://cloudsecurityalliance.org/group/top‐threats/#_overview).

14.5.1.4 SLO Selection

The annual list of the 100 most important cloud providers (CRN 2015) is composed of providers in every cloud service model. The model categorization utilized in this document includes IaaS, PaaS, SaaS, storage, and security. Moreover, there are 20 providers for each model. After an initial screening of the document, some included providers are still open projects and are therefore excluded from the SLO selection study because they did not provide the necessary information. The whole set of analyzed providers is composed of 76 elements. Unfortunately, only half of the selected elements provide a public SLA, mostly as providers of infrastructure model services. All the analyzed SLOs are described in (De Marco et al. 2013), depending on what category they belong to: the description is composed of their name, together with a definition and the percentage of their presence in the analyzed 38 SLAs.

14.5.1.5 SLO and Security Threats

According to the CSA document mentioned previously, the main threats for cloud service security are the following:

  • Data breach/loss: A customer can lose control of their data; there can be several causes, such as multitenancy, provider vulnerabilities, and network misuse.
  • Hijacking: Attackers can gain access to customer credentials to manipulate data, return false information, or redirect navigation to illegitimate sites. In addition, the power of a cloud provider can be used to launch subsequent attacks. Cloud vulnerabilities permitting hijacking attacks include mash‐up authorization, the transitive nature of the Cloud, and authentication and authorization vulnerabilities.
  • Insecure APIs: Attackers can be aware of the service architecture and design details; providers should select what to make publicly available through encryption, abstraction, or encapsulation mechanisms.
  • DoS and DDoS: Denial of service (DoS) and distributed denial of service (DDoS) attacks prevent users from accessing their data or applications.

Not much effort has been expended do defend service platforms from such threats:

  • Malicious insiders: An attacker can have access to sensitive information. Even with the use of encryption techniques, the system is still vulnerable to malicious insiders.
  • Abuse of services: Attackers use cloud platforms to address their attacks and to host illegal materials. Nevertheless, providers allow quick and easy service subscriptions; this makes it harder to detect an offender's identity.
  • Lack of transparency: Cloud organizations promise cost reduction together with operational and security improvements; several risks and issues can then arise, which are not disclosed to enterprises and organizations moving to cloud services.
  • Shared technology: Multitenancy architectures and shared resources represent key points of elastic scalability guaranteed by cloud organizations; unfortunately, these features introduce vulnerabilities. A compromised component shared in the architecture can represent a threat for the entire system.

In order to prevent security threats with a forensics readiness capability, some cloud parameters need to be measured. The measurement constraints to be guaranteed are identified in the SLOs, but not in all of them; thus, according to their relation to the main cloud threats, they can be classified as primary, optional, or unnecessary SLOs.

14.5.1.6 Court Presentation

Evidence to be collected during a forensic investigation has to fulfill court‐admissibility guidelines (ACPO 2012). In some cases, such guidelines can be in contrast with SLA constraints expressing jurisdictional principles. For instance, let us assume that SaaS cloud service provider X is responding to the European Jurisdiction. It can outsource additional services from storage cloud service provider Y, which responds to Asian or Middle Eastern laws. The SLA regulating the relationships between X and Y includes clauses that do not allow the collection of evidence, such as network logs or database transaction logs, and that regulate data access depending on other jurisdictions. Let us also assume that a customer of X accessing the service from the US is victim of a data‐breach crime, and law enforcement has to conduct an investigation. Very likely, depending on both the SLAs regulating the relationships between the customer and X, and X and Y, respectively, such an investigation cannot be finalized due to the presence of the clauses denying access to the potential evidence. The hypothetical investigation can collect evidence‐related data belonging to communications between the customer and service provider X; moreover, the logs from both the customer and provider sides can be utilized, as well as performance indicators and the values of the used metrics to evaluate the resource parameters. However, once the investigation has to deal with the infrastructure of service provider Y, depending on the expressed constraints, access to the necessary information can be denied to law enforcement.

14.5.2 Formal Model

Introducing a formal model representing the forensics readiness capability for cloud computing is of high priority. Such a model utilizes such formalisms as set theory, tuples, and functions in order to represent and relate the concept abstractions involved in it, such as SLAs and cloud logs. Moreover, some constraints among these concepts are represented in the form of theorems, and some specific definitions are designed.

A forensics readiness system for the Cloud is meant to observe and record information from the underlying computing architecture to make it forensically ready. Such information concerns operations happening in the Cloud to be related to SLA constraints. The capability output includes important investigative details about the recorded information and the detection of contractual clause violations.

Contractual monitoring is a topic actively investigated in the recent past in different contexts. Moreover, researchers provide customized ways to structure and represent SLA contents. The most effective representation is the adoption of formalisms. Natural‐language‐based SLA clauses have been structured via formal specification methods.

For instance, (Czajkowski et al. 2002) focus on the design of a protocol for negotiating SLAs among several actors. Different types of SLAs are defined, and some formalisms are utilized, such as tuples for describing an SLA. Also, some definitions concerning the metrics to use for services are provided. (Skene et al. 2007) formalize SLAs by using set theory for defining the concepts of actions, actors, events, parties, actions, and requirements. The purpose is to determine the possible SLA degree of monitoring in the context of service provisioning through the Internet. In (Paschke and Bichler 2008), a framework called Contract Log for monitoring SLAs is presented, which uses several formalisms. The SLAs are categorized depending on the purpose they are written for. Their contractual contents are formalized with different kinds of rules, such as derivation rules, reaction rules, integrity rules, and deontic rules; all of them are included in a homogeneous syntax and knowledge base. Finally, the conceptual framework is evaluated by a tool running specific test suites. In (Unger et al. 2008), the concepts of parties, SLA parameters, and SLOs are used to formalize SLAs in order to provide a way to aggregate more SLAs in a single business process. In this formal model, several formalisms are utilized, such as tuples, logic predicates, Boolean algebra, and normal forms. In (Ghosh and Ghosh 2012) the contracts are decomposed into the concepts of services parameters, SLOs, and key performance indicators; all these entities are formalized via tuples. The SLAs concern a storage‐as‐a‐service facility where a design model for a dedicated monitoring system is provided. Formal specifications are used by (Ishakian et al. 2011) to represent and transform SLAs in order to address the issue of verifying efficient workload colocation of real‐time applications. The approach allows transforming the SLAs whenever they do not meet the workload efficiency requirements, into an equivalent SLA that respects the same QoS. The proposal includes a reasoning tool used by the transformation process that comprehends inference rules based on a database of concepts, propositions, and syntactic idioms.

A cloud forensic readiness for SLA management (SLACFR) formal model is aimed to provide a theoretical approach to structure the management of SLA contracts for cloud computing services in the context of a forensics readiness capability. Its principal purpose is to record information about cloud behavior with respect to SLAs. This information is structured as a set of comparisons between an attribute of a cloud entity and a (set of) constraint(s) on that attribute at a specific time.

The capability recognizes suspicious information in real time: it represents a violation of a contractual constraint, such that preinvestigative activities are executed. The input of forensics readiness is composed of both information about cloud attributes and SLA constraints, all represented with formal rules. The execution begins on the availability of the contract(s) to monitor. The text is properly parsed via information‐extraction techniques (Grishman 1997) and transformed into a set of formal rules. The approach used to build this formal model follows a bottom‐up strategy: the contents of the SLAs are decomposed and structured to represent a constraint on a cloud entity. The cloud information is gathered from service logs; they represent resource information and are used to compute the actual value of a specific entity. For information coming from the cloud logs, a bottom‐up approach is followed: the contents of the logs are decomposed and structured to represent individual cloud entities and the operations changing their values.

14.6 Conclusion

The adaptation of existing forensic procedures to computing novelties is a constant and challenging task; moreover, the provisioning of a forensics readiness capability to computing infrastructure is becoming more and more complicated. FR is conceived as the provisioning of an information system communicating with an underlying computing architecture with the purpose of identifying, collecting, and storing critical data coming from them, representing potential evidence. This FR capability must be provided to cloud computing architectures due to their escalating popularity, because they can be the object of several attacks. Thus, a way to conduct forensic investigations effectively, saving time, money, and resources, must be designed. A DFR capability for the Cloud is meant to observe and record changes concerning the operations happening in the Cloud with respect to SLA constraints related to potential crimes. The capability output includes important investigative details about the recorded information and the detection of contractual clause violations. Moreover, a reference architecture for the implementation of an FR system for the Cloud is designed and illustrated, together with constraints and advantages. A means for implementing such a DFR capability in the Cloud includes a representation of the information to monitor. The most effective representation is the adoption of formalisms. Then, natural‐language‐based SLA clauses, cloud logs, and several entities necessary to output a comparison between them, have been structured via formal specifications. The formal model utilizes tuples, set theory, and functions to represent the necessary entities.

The formal model can be enriched with information from a forensics readiness capability. For instance, some principle formal representations can be added to the existing ones, paying attention to not altering the relations among them. Case studies involving conflicting SLAs can be the drivers for this extension. Moreover, the SLACFR formal model and its prototype actually increase some security aspects of a cloud provider. Finally, a very important extension of this capability can be driven by the availability of historical data: cloud log files. Such a large dataset can allow reasoning, knowledge extraction, and prediction information useful to foresee SLA violations. Also, the design of a cyber‐attack prediction metric can be a possible application of this data availability. We are also looking at applying this model for mobile cloud forensics (Faheem et al. 2015).

References

  1. ACPO. (2012). Good practice guide for computer based electronic evidence. http://www.digital‐detective.net/digital‐forensics‐documents/ACPO_Good_Practice_Guide_for_Digital_Evidence_v5.pdf.
  2. Agarwal, A. et al. (2011). Systematic digital forensic investigation model. International Journal of Computer Science and Security 5 (1): 118–131.
  3. Alharbi, S., Weber‐Jahnke, J., Traore, I. et al. (2011). The proactive and reactive digital forensics investigation process: a systematic literature review. Communications in Computer and Information Science 200: 87–100.
  4. Alonso, G., Casati, F., Kuno, H. et al. (2004). Web Services, 123–149. Berlin Heidelberg: Springer.
  5. Baryamureeba, V. and Tushabe, F. (2004). The enhanced digital investigation process model. In: Proceedings of the DFRWS Workshop, 1–9.
  6. Baset, S.A. (2012). Cloud SLAs: present and future. ACM SIGOPS Operating Systems Review 46 (2): 57–66.
  7. Birk, D. and Wegener, C. (2011). Technical issues of forensic investigations in cloud computing environments. In: Proceedings of the IEEE 6th International Workshop on Systematic Approaches to DF Engineering, 110. IEEE.
  8. Boucher, J. and Le‐Khac, N.‐A. (2018). Forensic framework to identify local vs synced artefacts. Digital Investigation 24 (1): 2018.
  9. Casey, E. (2011). Digital Evidence and Computer Crime, 3e. Academic Press, Elsevier Science.
  10. Cloud Security Alliance. (2011). Security guidance for critical areas of focus in cloud computing v 3.0. https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf.
  11. Cloud Security Alliance. (2013). Mapping the forensic standard ISO IEC 27037 to cloud computing.
  12. CRN. (2015). The 100 coolest cloud computing vendors of 2015. http://www.crn.com/news/cloud/300075525/the‐100‐coolest‐cloud‐computing‐vendors‐of‐2015.htm.
  13. Czajkowski, K., Foster, I., Kesselman, C. et al. (2002). SNAP: A protocol for negotiating service level agreements and coordinating resource management in distributed systems. In: Workshop on Job Scheduling Strategies for Parallel Processing, 153–183. Springer.
  14. Danielsson, J. and Tjostheim, I. (2004). The need for a structured approach to digital forensic readiness. In: Proceedings of the International Conference on Digital Forensic Readiness and E‐commerce (IADIS), 417–421.
  15. De Marco, L., Kechadi, M‐T., Ferrucci, F. et al. (2013). Cloud forensic readiness: foundations. In: Proceedings of the 5th International Conference on DF & Cyber Crime (ICDF2C), LNICST series, 132: 237–244. Springer International Publishing.
  16. Dykstra, J. and Sherman, A.T. (2012). Acquiring forensic evidence from Infrastructure‐as‐a‐Service cloud computing: exploring and evaluating tools, trust, and techniques. In: Proceedings of the 12th Annual DF Research Conference, DFRWS, Digital Investigation, 9: 9098.
  17. Dykstra, J., Sherman, A.T. (2013). Design and Implementation of FROST: Digital Forensic Tools for the OpenStack Cloud Computing Platform, preprint submitted to the 13th Annual DFRWS Conference, 2013.
  18. Endicott‐Povsky, B. and Frinckle, D.A. (2007). A theoretical framework for organizational network forensic readiness. Journal of Computers 2 (3): 111.
  19. European Commission. (2014). Cloud service level agreement standardisation guidelines. https://ec.europa.eu/digital‐agenda/en/news/cloud‐service‐level‐agreement‐standardisation‐guidelines.
  20. Faheem, M., Kechadi, M.‐T., and Le‐Khac, N.‐A. (2015). The state of the art forensic techniques in mobile cloud environment: a survey, challenges and current trend. International Journal of Digital Crime and Forensics 7 (2): 1–19.
  21. Ford, G. (1996). Service level agreements. New Review of Academic Librarianship 2 (1): 49–58.
  22. Foster, I., Zhao, Y., Raicu, I. et al. (2008). Cloud computing and grid computing 360‐degree compared. In: Grid Computing Environments Workshops, 1–10. IEEE.
  23. Ghosh, N. and Ghosh, S.K. (2012). An approach to identify and monitor SLA parameters for Storage‐as‐a‐Service cloud delivery model. In: Grid Computing Environments Workshops, 724–729. IEEE.
  24. Grishman, R. (1997). Information extraction: techniques and challenges. In: Information Extraction: A Multidisciplinary Approach to an Emerging Information Technology (ed. M.T. Pazienza), 10–27. Springer.
  25. Grobler, T. and Louwrens, B. (2007). Digital forensic readiness as a component of information security best practice. In: Proceedings of New Approaches for Security, Privacy and Trust in Complex Environments, IFIP TC‐ 11, 22nd International Information Security Conference, 232: 13–24.
  26. Ishakian, V., Lapets, A., Bestavros, A. et al. (2011). A formal verification of SLA transformations. In: Proceedings of the IEEE World Congress on Services, 540–547. IEEE.
  27. Kent, K., Grance, T., Chevalier, S. et al. (2006). Guide to Integrating Forensic Techniques into Incident Response, Special Publication 800‐86. Gaithersburg, Maryland: National Institute of Standards and Technology (NIST).
  28. Lee, J., NcCarthy, J., Licklider, J.C.R. et al. (1992). The beginnings at MIT. IEEE Annuals of the History of Computing 14 (1): 18–30.
  29. McKemmish, R. (1999). What Is Forensic Computing? Trends and issues in crime and criminal justice. Canberra: Australian Institute of Criminology.
  30. Mell, P. and Grance, T. (2011). The NIST definition of cloud computing. http://csrc.nist.gov/publications/nistpubs/800‐145/SP800‐145.pdf.
  31. Mouton, F. and Venter, H.S. (2011). A Prototype for Achieving Digital Forensic Readiness on Wireless Sensor Networks, 16. AFRICON.
  32. Orton, I., Alva, A., Endicott‐Popovsky, B. et al. (2012). Legal process and requirements for cloud forensic investigations. In: Cybercrime and Cloud Forensics: Applications for Investigation Processes (ed. K. Ruan), 332–375. IGI Global.
  33. Pangalos, G., IIioudis, C., Pagkalos, I. et al. (2010). The importance of corporate forensic readiness in the information security framework. In: 19th IEEE International Workshop on Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE), 1216.
  34. Paschke, A. and Bichler, M. (2008). Knowledge representation concepts for automated SLA management. Decision Support Systems 46 (1): 187–205.
  35. Plunkett, J., Le‐Khac, N‐A., and Kechadi, M‐T. (2015). Digital forensic investigations in the Cloud: a proposed approach for Irish law enforcement. 11th Annual IFIP WG 11.9 International Conference on Digital Forensics (IFIP119 2015), Orlando, Florida, United States, 26–28, January 2015.
  36. Pollitt, M. (2007). An ad hoc review of digital forensic models. In: Second International Workshop on Systematic Approaches to Digital Forensic Engineering, 43–54.
  37. Reddy, K. and Venter, H.S. (2013). The architecture of a digital forensic readiness management system. Computers & Security 32: 73–89.
  38. Rowlingson, R. (2004). A ten step process for forensic readiness. International Journal of Digital Evidence 2 (3): 1–28.
  39. Ruan K., Baggili, I., Carthy, J. et al. (2011b). Survey on cloud forensics and critical criteria for cloud forensic capability: a preliminary analysis. In: Proceedings of the 6th Annual Conference on Digital Forensics, Security and Law.
  40. Ruan, K. and Carthy, J. (2012). Cloud computing reference architecture and its forensic implications: a preliminary analysis. In: Proceedings of the 4th International Conference on Digital Forensics & Cyber Crime (ICDF2C), 114: 1–21.
  41. Ruan K., Carthy, J., Kechadi, M‐T. et al. (2011a). Cloud forensics: an overview. Advances in Digital Forensics VII.
  42. Ruan, K., Carthy, J., Kechadi, M.‐T. et al. (2013). Cloud forensics definitions and critical criteria for cloud forensic capability: an overview of survey results. Digital Investigation 10 (1): 34–43.
  43. Ryder, Steven and Le‐Khac N‐A. (2016). The end of effective law enforcement in the Cloud? To encrypt, or not to encrypt. The 9th IEEE International Conference on Cloud Computing, San Francisco, CA USA, June 2016.
  44. Skene, J., Skene, A., Crampton, J. et al. (2007). The monitorability of service‐level agreements for application‐service provision. In: Proceedings of the International Workshop on Software and Performance, 3–14.
  45. Sommerville, I. and Sawyer, P. (1997). Requirements Engineering: A Good Practice Guide. John Wiley and Sons, Inc.
  46. Tan, J. (2001). Forensic readiness, Technical report. @Stake Organization. http://isis.poly.edu/kulesh/forensics/forensicreadiness.pdf.
  47. Trenwith, P. M. and Venter, H.S. (2013). Digital forensic readiness in the Cloud. In: Proceedings of Information Security for South Africa, 1–5.
  48. Unger, T., Leymann, F., Mauchart, S. et al. (2008). Aggregation of service level agreements in the context of business processes. In: Proceedings of the ICEDOC Conference, 43–52.
  49. Valjarevic, A. and Venter, H.S. (2011). Towards a digital forensic readiness framework for Public Key Infrastructure systems. In: Proceedings of Information Security South Africa (ISSA), 1–10.
  50. Yusoff, Y., Ismail, R., Hassan, Z. et al. (2011). Common phases of computer forensics investigation models. International Journal of Computer Science & Information Technology 3 (3): 17–31.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset