16.3.1.1 XML Information Retrieval Approach to Digital Forensics (XIRAF)

(Alink et al. 2006) propose XIRAF, a prototype system for forensic analysis that is an Extensible Markup Language (XML) based implementation aimed at managing and querying forensic traces extracted from digital evidence. XIRAF systematically applies forensic analysis tools to evidence files. Each forensic analysis tool that is used produces an output consisting of structured XML annotations capable of referring to regions in the corresponding evidence file. Furthermore, such annotations are stored in a persistent back end such as an XML database (DB) that can be queried at a later time. To query XIRAF's XML database, the authors have developed XQuery, which is a custom query tool.

XIRAF's XML‐based forensic analysis platform provides the forensic investigator with a powerful, feature‐rich query environment in which browsing, searching, and predefined query templates are all expressed as XQuery queries – XML DB queries. The authors address two key data‐processing problems that occur during the feature‐extraction and analysis phases of a computer system investigation:

• Evidence quantity: Modern computer systems are routinely equipped with hundreds of gigabytes of storage, and a large investigation will often involve multiple systems, so the amount of data to process can run into terabytes. The amount of time available for processing this data is often limited (e.g. because of legal limitations). Also, the probability that a forensic investigator will miss important traces increases every day because there are simply too many objects to keep track of.
• Evidence diversity: A disk image contains a plethora of programs and file formats. This complicates processing and analysis and has led to a large number of special‐purpose forensic analysis tools such as browser history analyzers, file carvers, file‐system analyzers, Internet relay chat (IRC) analysis tools, registry analysis tools, etc. While it is clear that the output of different tools can and should be combined in meaningful ways, it is difficult today to obtain an integrated view of the output from different tools. Furthermore, even if proprietary and commercial tools are approved and acceptable, it is highly unlikely that any forensic investigator would have the time and the knowledge to apply the relevant tools to the case and evidence at hand. Hence the authors propose their XIRAF framework, which has the following key properties: (i) clean separation between feature extraction and analysis; (ii) single, XML‐based output format for all forensic analysis tools; (iii) XML DB for storing the XML annotations; and (iv) custom query tool XQuery for querying analysis tools' XML output.

Since December 2010, the Netherlands Forensic Institute has been using XIRAF – a service‐based approach for processing and investigating high volumes of seized digital material. Service‐based XIRAF has over the years evolved significantly and become a standard for hundreds of criminal cases and over a thousand investigators, both in the Netherlands and in other parts of the world. The authors note the impact of the XIRAF system and the paradigm shift it is causing, having processed over a petabyte of data with the XIRAF system.

XIRAF was originally primarily aimed at identifying and developing techniques for automating (parts of) the data analysis process for forensics investigations. It was never meant to be an operational system for processing large volumes of data, and most definitely not data volumes in petabytes. Consequently, design considerations made during the development of XIRAF leave significant room for improvement.

16.3.1.2 Hansken: Digital Forensics as a Service (DFaaS) Successor to XIRAF

Hansken was well defined and designed from its inception and has a proof of concept (PoC) based on the new principles and ideas and a production version to replace XIRAF (Alink et al. 2006). The forensic drivers behind the design and development of Hansken have been to provide a service that processes high volumes of digital material in a forensic context. In addition, it provides easy and secure access to the processed results. The Hansken forensics framework is designed to focus on the following three drivers: (i) minimization of case lead time, (ii) maximization of trace coverage, and (iii) specialization of people involved (Van Beek et al. 2015).

Processing seized material must be automated to provide the investigations team access to critical data. This impacts the way digital material is handled (Van Baar et al. 2014). Furthermore, the results of this automated process must be made available to the investigation team directly, not to specialized digital investigators. To further speed up the investigation, analysts should be able to annotate or tag interesting traces such as those that need further analysis, or those that are not clear to the investigator who tagged them. Such annotation/tagging should be available to other analysts so that the case can be solved through collaborative analysis.

The design of Hansken (Figure 16.2) supports distributed extraction of traces from images. XIRAF, the precursor to Hansken, applies multiple tools to a forensic image on a single machine. This is iterative in nature and hence does not scale well. Most importantly, the design of XIRAF means taking data to the tools, since tools are applied sequentially, with each tool having dedicated access to the image. To overcome this limitation of sequential processing, Hansken's design was driven toward taking the tools to the data. Hansken uses distributed technology, making it possible to process one forensic image using multiple machines. Consequently, as soon as the data is read from the image, it is kept in memory, and all tools are applied. Once a trace is fully processed, the results are stored in a database so it can be queried while other traces are still being extracted. This makes the first trace available in minutes, with more traces available for querying, mitigating idle time.

Another key feature of Hansken is its data‐driven acquisition, such that analysts can start the process of extracting traces from a forensic image as soon as the first bits of a device are uploaded to the central system. To support this feature, the authors have designed an image format that splits the image data into encrypted blocks. Such a format supports processing unordered blocks, which makes it possible to implement dynamic pipelining where the extraction process influences the imaging process by asking for certain blocks of data to become available with priority.

16.3.1.3 MPI MapReduce (MMR)

(Roussev et al. 2009) present three possible alternative approaches for augmenting forensics data processing in a fixed amount of time. The first is through the development of improved algorithms and tools for better and more efficient use of available machine resources. The second approach is the use of additional hardware resources to deploy additional machine resources. The third alternative is to facilitate human collaboration, taking advantage of human expertise in problem solving. All three approaches are mutually independent and support large‐scale forensics in complementary ways.

The authors propose an open implementation of the MapReduce processing model that they call MPI MapReduce (MMR). The proposed MMR falls under the second category since it supports the use of additional hardware in the form of commodity distributed computational resources to speed up forensic investigations.

MMR's performance has been evaluated through a proof‐of‐concept implementation using two key technologies. The first is the Phoenix shared‐memory implementation of MapReduce. The second is the Message Passing Interface (MPI) distributed communication standard. In summary, MMR provides linear scaling for CPU‐intensive processing and super‐linear scaling for indexing‐related workloads.

16.3.1.4 GRR Rapid Response Framework

(Cohen et al. 2011) present GRR Rapid Response Framework (GRR), a new multiplatform, open source tool for enterprise forensic investigations. A key feature of GRR is its ability to support remote raw disk and memory access. GRR is designed to be scalable and is a distributed approach for remote live access. However, it is not a cloud‐based solution; instead, it is a live forensics tool geared toward preserving volatile evidence. Yet another remote‐access technique utilized is presented in (Cohen 2005). The advantage of this technique is that the client side is very simple, while the server side performs the complex forensic analysis.

A key challenge to automating analysis is that it may require executing many sequential steps. Current solutions create a dedicated console process that waits for the client to complete each step before issuing the next step. This limits scalability because the server needs to allocate resources for each client and wait until the entire analysis is complete. In GRR, the authors use state serialization to suspend execution for analysis processes for each client. These serialized forms are then stored dormant on disk until the client responds. Consequently, this approach resolves the problem of a resource drain imposed on servers. In GRR, such constructions are referred to as flows. A flow is simply a state machine with well‐defined serialization points where it is possible to suspend its execution.

The architecture of GRR addresses auditing and privacy issues by allowing for nonintrusive automated analysis with audited access to retrieved data. However, it strives to achieve a balance between protecting access to user data and warranted forensically sound analysis. It also provides a secure and scalable platform to facilitate employing a variety of forensic analysis solutions. The authors support the usefulness and practicality of their proposed GRR through the following four case studies: (i) Investigation of intellectual property leaks, (ii) Isolation of a targeted malware attack, (iii) discovery request compliance, and iv) periodic snapshots of system states.

16.3.1.5 A Scalable File‐Based Data Store for Forensic Analysis

(Cruz et al. 2015) present a specific implementation of the GRR Rapid Response (GRR) framework (Cohen et al. 2011). (Cruz et al. 2015) present a new data store back end (Figure 16.3) that can be used as a storage layer for the AFF4 Resolver. GRR's AFF4 Resolver stores AFF4 objects permanently in a NoSQL data store, enabling the application to only deal with high‐level objects. The proposed GRR's distributed data store partitions data into database files that can be accessed independently, enabling scalable distributed forensic analysis. Furthermore, the authors discuss utilizing the software reference database National Software Reference Library (NSRL) in tandem with their distributed data store to avoid wasting resources when collecting/processing benign files. The following two functionalities must be implemented by the data store in order to support an AFF4 Resolver.

• Single‐object access: Simplifies the partitioning of data because operations never deal with multiple objects. GRR systems require synchronous operations to guarantee globally deterministic ordering.
• Support for synchronous and asynchronous operations: Synchronous operations will block until the data store returns the results, while asynchronous operations will be scheduled to be performed at some point in the future. Asynchronous operations improve program concurrency and provide a huge performance advantage, and hence are heavily used by GRR systems.

Originally, the SQLite data store provided by GRR exhibits two limitations: (i) the capacity of each individual worker degrades as new workers are added to the GRR system due to contention at the data store, which limits its horizontal scaling; and (ii) since existing data stores rely on a central database server, increasing storage demands on a single server are only possible to a certain extent, which limits storage scaling.

(Cruz et al. 2015) reason that these limitations are due to file‐lock contention at the central server. Therefore, they work to resolve this problem by completely dividing the AFF4 namespace into independent storage files. This helps mitigate the file‐lock contention problems. The benefits of their approach can be witnessed in their validation results.

16.3.1.6 Forensics‐as‐a‐Service

(Wen et al. 2013) propose a domain‐specific cloud environment that can use the emerging trends of service‐based computing for supporting forensic applications. The proposed cloud‐based forensics framework (Figure 16.4) is specifically designed for dealing with large volumes of forensic data. Furthermore, their approach has the ability to enable the sharing of interoperable forensic software and provides tools for forensic investigators to create and customize forensic data‐processing workflows. The authors have conducted experiments using their forensic cloud framework with Amazon's Elastic Compute Cloud (EC2) service.

The experimental infrastructure is based on Hadoop 0.20 and HBase 0.20 and is managed by Cloudera (www.cloudera.com). For evaluations, the workloads are parallelized, and the results show that their approach can reduce forensic data analysis time considerably. They also argue that the overhead for investigators to design and configure complex forensic workflows is greatly minimized. Finally, they claim their proposed workflow management solution can save up to 87% of analysis time in the tested scenarios.

16.3.1.7 Data Deduplication Driven Acceleration of Forensic Analysis

(Scanlon 2016; Wolahan et al. 2016) present a unique perspective to combat the digital forensic backlog. The proposed method explores a data deduplication framework to eliminate redundancy in reacquisition, storage, and analysis of previously processed data. The primary objective of the authors in this case is to design a system that can alleviate some of the backlog by minimizing duplicated effort, while providing a number of enhancements to the functionality available with the traditional alternative. (Wolahan et al. 2016) explore alternatives to the traditional evidence‐acquisition model by using a forensic data deduplication system. This work also presents the advantages of a deduplicated approach along with some preliminary results of a prototype implementation.

16.3.3.1 Security and Privacy Requirements

FaaS service providers must assure all stakeholders – suspects, victims, judge, and jury – that their implementation and the operations of FaaS meet the regulatory standards for security and privacy of data and the integrity requirements of the forensics processes. A FaaS service provider is expected to assure its stakeholders of the three core security requirements – confidentiality, integrity, and availability – with regard to case and evidence data security and privacy. The service provider must ensure that resource pooling in a multitenant environment does not risk the fundamental requirements of the security triad.

Confidentiality of case‐relevant information and evidence data is a key requirement. The service provider must ensure that appropriate control mechanisms (Figure 16.5) are in place to prevent accidental or intentional data disclosure, unauthorized access, or accidental/intentional data leaks either during or after the case analysis is complete. Furthermore, any potential user confidentiality violations can potentially have a domino effect, resulting in secondary violations of the Health Insurance Portability and Accountability Act (HIPAA), Family Educational Rights and Privacy Act (FERPA), etc. Similarly, third‐party tools must be thoroughly vetted to detect any potential data leaks.

The integrity of case‐relevant data is of even greater significance in the realm of computer forensic analysis. The FaaS provider mush have well‐established and tested integrity controls enforced to counter any potential risk of accidental or intentional alterations to case information and, more importantly, evidence data. Failure to implement strong integrity‐preserving security mechanisms can be catastrophic to digital investigations, with the potential of rendering all evidence data inadmissible.

Finally, case information and evidence data should be available whenever authorized users need access. Though non‐availability is not a critical security concern to the investigation, it can impact the investigation indirectly due to downtime resulting in delayed analysis. This can cascade to the discovery of information that could warrant additional seizures, which may already have been destroyed irreversibly. Also, at the completion of the analysis, there must be proper procedures for backup and archiving to ensure the availability of case‐relevant data in the future for (re)appeals or other legal purposes.

16.3.3.2 Regulatory and Legal Requirements

Compliance in the realm of information security is a fundamental requirement. A majority of enterprise forensics investigations include noncompliant matters involving employees or the employer. Forensics investigations can span the whole spectrum of possibilities – from enterprise policy violations to insider threats, harassing e‐mails to cyberstalking, robbery to vandalism, and suicide to homicide. Digital forensics investigations should comply with key regulations:

• There must be strict control over the cloud infrastructure and resources, ensuring consistency in jurisdiction and applicable laws of the FaaS platform.
• The FaaS platform and the entire process of analysis are monitored and logged at appropriate granularity, enabling audits by a neutral, trusted third party. The logs are themselves secured such that the neutral, trusted third party’s auditing will not have access to any sensitive information such as personally identifiable information (PII) during the course of the audit.
• All methods, tools, and techniques must be validated and approved by appropriate government authorities. One of the key approvals often comes from the National Institute of Standards and Technology (NIST) Computer Forensics Tool Testing (CFTT) program. Failure to prove the integrity and reproducibility of the process would render all efforts futile in a court of law.

16.3.3.3 Design Requirements

Some of the key requirements for designing a parallel, distributed digital forensics toolkit framework are delineated next:

• Modular: Since the entire forensic analysis is a complex process, a modular design facilitates a systematic breakdown of the complex process. Subsequently, tools and techniques can be developed for smaller tasks at a level of granularity and abstraction that supports the case hypothesis. A modular design enables flexibility and extensibility, two key requirements to cope with an evolving technology and threat landscape. It also enables rapid development of newer tools and their easy integration into the master tool framework.
• Scalable: The architecture of the FaaS should be capable of scaling well with increasing numbers and sizes of cases and associated evidence. An increasing workload should not compromise resource allocation and execution capabilities. A digital forensic analysis process is scalable if it can keep the average time per investigation constant in the face of growing target sizes and diversity (Roussev and Quates 2012).
• Platform independent: FaaS should be able to handle forensics tools independent of the tools' needs for a specific hardware/software platform. Furthermore, for the FaaS framework, it should be possible to pool the machine resources of a group of investigators working on the same case, to speed up the processing of critical evidence (Roussev and Richard 2004).
• Extensible: Cloud‐based FaaS frameworks should be devoid of vendor‐locked functionality and capability expansions. This is a critical requirement for enhancing FaaS relevance and capabilities so they are current with evolving technology needs and caseloads. Note that this is a standard software engineering requirement and mandates that it should be easy to add new or replace existing functions (Roussev and Richard 2004).

16.3.3.4 Benefits of Provisioning Cloud‐Based Forensics‐as‐a‐Service

By migrating the computer forensic analysis process to the cloud, the digital forensic science discipline will experience a broad spectrum of benefits. The first and foremost benefit will be more efficient utilization of limited manpower with required skills. This would also mean improved consistency in results from forensic analysis. Since the Cloud already offers metered services, migrating the forensic analysis process to the cloud will result in improved resource utilization while minimizing costs. Since the Cloud as a computing platform is ubiquitous and widely accessible, it enables better interagency and intra‐agency information and resource sharing. Furthermore, FaaS will offer consistent analysis platforms and resource allocation through an established baseline. Finally, the most important benefit of FaaS will be provisioning accreditation and certification bodies with convenient access to tools and processes for validation and certification.