A Function Oriented Methodology to Validate and Verify Forensic Copy Function of Digital Forensic Tools

Transcription

1 2010 International Conference on Availability, Reliability and Security A Function Oriented Methodology to Validate and Verify Forensic Copy Function of Digital Forensic Tools Yinghua Guo Defence and Systems Institute University of South Australia Adelaide, Australia yinghua.guo@unisa.edu.au Jill Slay Defence and Systems Institute University of South Australia Adelaide, Australia jill.slay@unisa.edu.au Abstract The growth in the computer forensic field has created a demand for new software (or increased functionality to existing software) and a means to verify that this software is truly forensic i.e. capable of meeting the requirements of the trier of fact. In this work, we present a function oriented testing framework for validation and verification of computer forensic tools. This framework consists of three parts: function mapping, requirements specification and reference set development. Through function mapping, we give a scientific and systemical description of the fundamentals of computer forensic practice, i.e. what functions are needed in the computer forensic investigation process. We focus this paper on the forensic copy function. We specify the requirements and develop and a corresponding reference set to test any tools that possess the forensic copy function. Keywords-digital forensics; electronic evidence; forensic copy; acquisition; validation; verification; I. INTRODUCTION Computer forensics, as a multi-domain practice, has become an important part of legal system throughout the world. While the definitions of computer forensic and its interacting elements vary and depend on the authors and their background, the core connotation of computer forensics can be concisely described as the process of identifying, preserving, analyzing and presenting digital evidence in a manner that is legally acceptable [1]. In this work, we exchangeably use the terms Electronic Evidence (EE), computer forensics, digital forensics and forensic computing. As identified in [2], [3], one of challenges in the EE practice is to ensure that digital evidence acquired and analyzed by EE investigation tools is forensically sound. Hence, the request of validating and verifying EE tools is raised by law enforcements and agencies. In our previous work [2], we proposed a function orientated framework for EE tool validation and verification. In this framework, we identify fundamental functions required in EE investigations, such as search, data recovery, forensic copy and so on. For each function, we further identify its details, e.g. subcategories, components and etc. We call this process function mapping. Based on the function mapping, we specify each function s requirements and then develop a reference set against which EE tools can be tested. If we image the job of building the validation and verification (VV) framework by completing such functions one by one as a puzzle game, our work [2], [4] addressed the first two pieces, that are search and data recovery functions. This work comes straight to the point: filling the third piece, that is complete the function mapping, requirements specification and reference set development of forensic copy function. All background details of this work, such as motivations behind our work and literature review can be found in [2]. The rest of this paper is organized as follows. We review our function orientated VV framework in Section II. Section III presents detailed forensic copy function mapping. The requirements of forensic copy function are identified in Section IV. At last, we develop a focused pilot reference set for testing the forensic copy function in Section V. This paper is finally concluded by Section VI. II. A FUNCTION ORIENTATED VV METHODOLOGY In this section, we review our proposed validation and verification paradigm. Our methodology starts with a scientific and systematical description of the EE field through a model and the function mapping. Components and processes of the EE practice are defined in this model and fundamental functions in EE investigation process are specified (mapped), i.e. search, data recovery, file identification, etc. Based on the comprehensive and clear understanding of EE practice, we then actually perform the validation and verification of EE tools as follows. First, for each mapped function, we specify its requirements. Then, we develop a reference set in which each test case (or scenario) is designed corresponding to one function requirement. With the reference set, a EE tool or its functions can be validated and verified independently. In this work, we use the CFSAP (computer forensicsecure, analyze, present) model [5] to describe the basic procedures of EE investigation. In this model, four fundamental procedures are identified: identification, preservation, analysis and presentation. Given the likelihood of judicial scrutiny in a court of law, it is imperative that any examination of the electronically /10 $ IEEE DOI /ARES

2 Figure 2. Top level mapping of forensic copy Figure 1. Validation and verification top level mapping stored data be carried out in the least intrusive manner [1]. Therefore, once the evidence sources are identified (in identification phase), it is preferred that the original source of evidence be preserved. However, it is not realistic to seizing and reserving the original sources in some cases, such as a computer system that is critical to the ongoing operations of a business, or a geographically remote computer. In such instances, it is desirable to duplicate the source evidence data by making exact copies through the use of forensically sound duplication techniques and tools. Apart from forensic copy, other issues, i.e. write protection, media sanitation and verification, need to be considered in the phase of preservation. In the phase of analysis, there are a number of functions that may be required, such as search, file rendering, data recovery, decryption, file identification, processing, temporal data and process automation. An ontology of such functions in the phase of preservation and analysis is shown in Figure 1. In this work, we aim to complete the mapping of the functional categories of the field to a level of abstraction that would serve the purposes of a specification for a software developer, a technical trainer or educator, or for tool validation or verification. Specifically, we detail the specification of functional categories and its sub-categories. We focus this work on the forensic copy function, i.e. mapping its function, specifying its requirements and developing the reference set to validate and verify EE tools that possess the forensic copy function. Our function orientated VV methodology can be presented as the following. If the domain of computer forensic functions is known and the domain of expected results (i.e. requirements of each function) are known, that is, the range and specification of the results, then the process of validating any tool can be as simple as providing a set of references with known results. When a tool is tested, a set of metrics can also be derived to determine the fundamental scientific measurements of accuracy and precision. In summary, if the practice can be mapped in terms of functions (and their specifications) and, for each function, the expected results are identified and mapped as a reference set, then any tool, regardless of its original design intention, can be validated against known elements. III. FUNCTION MAPPING OF FORENSIC COPY In this work, we use the term forensic copy, exchangeable with acquisition, to refer to the process of duplicating the original evidence data. The forensic copy can be as simple as a file copy or as complex as a bit stream copy. A general and intuitive procedure for forensic copy is to copy one byte (or in chunks of data) from the original storage media (the source) to a destination media and repeat the process. Following this thought, we dissect the forensic copy function from two angles: (evidence) data source and data destination. While the former is about what needs to be copied, the latter is about where and in what form the copy of original data is saved. Figure 2 shows a top level extraction of forensic copy function. A. Data sources of forensic copy In today s digital computing environment, EE practitioners are facing a large number of different data sources that could act digital evidence in computer forensic investigation. According to RFC 3227 [6], 7 groups of data sources are ordered in terms of their volatility as follows: (1) Registers, cache; (2) Routing table, ARP cache, process table, kernel statistics, memory; (3) Temporary file systems; (4) Disk; (5) Remote logging and monitoring data; (6) Physical configuration, network topology; (7) Archival media. In this work, we adopt a broader classification, that is static data and dynamic data. 1) Static data: Static data is the data that is persistently stored on a local storage medium, such as hard drive, CD/DVD, and is preserved when the computer is turned off. The general theory of static data acquisition is to save every byte that we think may contain evidence. Data can be interpreted at different layers; for example, the disk, partition, file and application files. At each layer of abstraction, data are lost. Therefore, the rule of thumb is to acquire data 666

3 at the lowest layer that we think there will be evidence. For most cases, an investigator will acquire every bit of a storage medium, that is reading data from the storage medium in a bit stream manner. We call forensic copy at this level as the physical copy. To perform physical copy properly, investigators need understand the storage medium on which data resides. Broadly speaking, there are three common types of storage medium currently being used to store static data: magnetic medium, optical medium and semi-conductor medium. In the magnetic medium category, the hard drive and tapes are typical storage devices. CD, DVD and BluRay are being widely used in the optical medium category. USB flash drive, memory cards and media players are semiconductor based storage devices. For each storage device, there are many different implementations. For example, hard drive could be IDE, SATA and SCSI, and memory cards could be Compact Flash (CF)card, Smart media (SM) card and etc. More importantly, as technology advances, new storage medium will be discovered and new storage devices will be produced. Hence, we are aware that this part of function mapping is not exhaustive and needs to be upgraded frequently. Although physical copy might be the most reliable way to acquire data evidence, reducing the risk of missing data to the lowest level, it may be infeasible or impropriate in some circumstances due to the factors of resources constraints, privacy and privilege. These give rise to the emerging practice of logical copy, which seizes selected evidences stored on electronic storage media by creating a forensically acceptable image (or copy) of specified parts of evident sources. A detailed mapping of static data forensic copy can be found in Figure 3. 2) Dynamic data: Dynamic data is any data that is stored in memory, or exists in transit, that will be lost when the computer loses power or is turned off. Dynamic data may take the form of data residing in registries, cache, and random access memory (RAM), data collected from live remote services or network traffic transiting in the network. Traditionally, live remote and network traffic, as data sources, belong to remote forensic and network forensic discipline, and are beyond this paper s scope. A detailed review of live remote data and network traffic can be found in [7], [8] The dynamic data residing in memory may contain lots of useful information, such as data from running processes (e.g. passwords, unencrypted data and the state of user activity), network connections, command history and loaded libraries. However, due to the transient nature of dynamic data, its reliable acquisition is difficult. This is because dynamic data is lost when power is removed, and hence its acquisition must be a live acquisition where the suspect operating system is still running and being used to copy data. In the live acquisition, malicious programs (e.g. Rootkits and Trojan horse) and inevitable overwriting caused by Figure 3. Static data source of forensic copy acquisition process make dynamic data acquisition very challenging [9]. In terms of function mapping, we further parse the subcategory of memory data acquisition from two perspectives: storage memory and acquisition approaches. Physical memory, also called RAM, is the main place where dynamic data resides. Besides, parts of hard disk can also be allocated for storing dynamic data. This technique is known as virtual memory that is used by multitasking computer operating systems wherein non-contiguous memory is presented to software as contiguous memory. Physical memory provides the main storage while virtual memory optimizes the use of physical memory. For both physical memory and virtual memory, dynamic data acquisition can be performed at two granularities: system granularity and process granularity. While the former dumps all data stored in entire RAM, the latter aims to only acquire certain running process s data in the RAM. There are three approaches for memory data acquisition: hardware based, software based and firmware based. The main idea behind hardware based approach is to bypass the operating system by means of a physical device. The dedicated hardware will open a dedicated communication port to copy the contents of the physical memory. This would allow an investigator to retrieve the volatile memory from 667

4 Figure 5. Data destination of forensic copy Figure 4. Dynamic data in memory of forensic copy the system without introducing any new code or relying on potentially untrustworthy code to perform the extraction. Tribble [9] and FireWire (also known as IEEE1394 bus) are two examples of hardware based approaches. Current software based approaches for memory acquisition typically take advantage of operating system services providing user space access to physical memory as a device file. For example Unix flavors have the /dev/mem device, which corresponds to the physical memory, and the /dev/kmem device, which corresponds to the virtual memory of the kernel. At the moment, there are various of software tools available for memory forensic copy, such as pcat (TCT) [10], VmWare, Winhex, BodySnatcher [11], Data Dumper (DD), Windows crash dump utility, hibernation functionality of operating systems and etc. The OpenBoot firmware [12] in a Sun system is a firmware based approach and uses a Sparc architecture can dump the contents of physical memory to a storage device. Figure 4 gives an detailed mapping of acquiring dynamic data in memory. B. Data destinations of forensic copy After evidence data is copied from the data source, people need save it for later usage. This section addresses two issues of forensic copy function: where to save and how to save (in what format) the acquired data. In the early time of computer forensics when there are no specialized analysis tools, investigators either booted the suspect system or mounted the disks in their analysis systems. They read the data from the sources (hard drives in most cases) and save the data directly to another disk. Known as clone, the duplicated copy serves the objective on which further forensic analysis is carried out. As defined by NIST [13], a clone could be the cylinder-aligned clone or unaligned clone. The cylinder-aligned clone is a bit-stream duplicate restored to physical media of the data acquired from a digital source except for minor changes as required to align partitions on cylinder boundaries. The unaligned clone is the bit-stream duplicate restored to physical media of the data acquired from the digital source from both visible and hidden data sectors. As specialized computer forensic tools (software and hardware) advance, investigators gradually have abandoned the way saving acquired data, clone. Instead, they save the acquired data to a file (or files) that is stored on storage devices (e.g. hard disk or CD-ROM) by using those acquisition softwares. With a file, it is easy to know the boundaries of the data, and operating systems will not try to mount it automatically. The file is called an image. If we save the data to a file, we have a choice of in what format the image will be. Broadly speaking, acquired image file can be categorized into raw image file and structured one. The raw image contains nothing but data as the same as contents of the source. The majority of forensic applications can create and read the raw format image, making it the de facto standard. Apart from evidence data itself, additional descriptive information about the acquisition has been proven useful and/or mandatory in some cases. These information, also called meta data, may include hash value, dates, times, level of data compression applied in the imaging and etc. Currently, there are two common ways to provide such descriptive information. The first way is to embed the additional descriptive information in the raw data, and the resulting image is called embedded image. The second way is to create a raw image and save the additional descriptive data to a separate file. Figure 5 gives a detailed mapping of forensic copy in terms of data destination. IV. REQUIREMENTS SPECIFICATION As the second step of our validation and verification framework, we specify the requirements of forensic copy function in this section. A few of efforts have been conducted on the requirement specification of forensic copy function. For example, NIST CFTT project [13] has done extensive work on this area. however, their work mainly focuses on the acquisition of hard disk data, which is equivalent to the static data category in our work. Another example is Brian s work [9] that specified requirements 668

5 of memory data acquisition. In this work, we provide a complete specification framework of forensic copy function requirements by integrating previous works. Similar to our previous work [2], we perform the requirement specification in an extendable and custom-made way. In the function mapping section, we can see that there are a variety of diversifications we need to take into consideration when we specify the requirements. For example, the data source could be static data stored on magnetic medium, optical medium and semiconductor medium, the data collected from live remote services, and network traffic. The network traffic capture mode could be passive capture and active capture. Hence, we use variables (in boldfaced and italic) to reflect these diversifications, and multifarious requirements can be refined to the following statements. When one requirement needs change, what people need to do is just tailor (add, deleted, or modify) these variables. This method of requirements specification is highly abstract and generalized. When it is needed for developing a specific test scenario in reference set, each of these requirements can be unwrapped. For example, the requirement of The tool shall acquire a data source through each acquisition interface visible to the tool can be unwrapped and instantiated as The tool shall be able to acquire data on hard disk at the logical level through IDE interface. The detailed description of these variables can be found in Figure 3, 4, and 5. Due to the space limitation, we hereby just present some pilot samples of the requirements specification of forensic copy function. A more detailed requirements specification can be found in [14]. A. Mandatory requirements 1) The tool shall acquire a data source through each acquisition interface visible to the tool 2) The tool shall operate in at least one execution environment and shall be able to acquire data sources in each execution environment 3) All data acquired by the tool from the data source shall be accurately acquired 4) The tool shall completely acquire all visible data from the data source 5) The tool shall completely acquire all hidden data from the data source 6) The tool shall not alter the original data source 7) The tool shall write the acquired data to at least one data destination object 8) The tool shall write the acquired data to a data destination object accurately and completely B. Optional requirements 1) Generic optional requirements: 1) If the tool offers acquisition of a subset of the data source, then the tool shall create a destination object of the specified subset of the data source 2) The tool shall compute a hash value of the complete destination object of the data source, compare the computed hash value to the hash value of the data source computed at the time the destination object was created, and log the results of the comparison 3) The tool shall divide the destination object blocks, compute a hash value for each block, compare the computed hash value to the hash value of the original block of the data source computed at the time the destination object was created, and log the results of the comparison 2) Specific optional requirements: Image related requirements 1) The tool shall be able to read various image formats, including the raw image 2) If the tool offers image splitting, then the tool shall create a multi-file image with files of the requested size such that the resulting multi-file image contains the same data as acquired by the tool 3) If there is insufficient space on the image destination device to contain the image file, then the tool shall notify the user of the condition Clone related requirements 1) The tool shall create a clone from a image file 2) The tool shall create a partial clone of a subset of an image file 3) If the tool offers unaligned clone creation, then the tool shall create an unaligned clone 4) If the tool offers cylinder-aligned clone creation, then the tool shall create a cylinder-aligned clone Static data related requirements 1) If a source file contains metadata and the data is requested to be copied, then the tool shall copy the metadata with the source file Memory related requirements 1) If there is excess space on the destination device, then the tool shall identify the start and end locations of the source data within the destination 2) If there is insufficient space on the destination device to contain all the data acquired from the data source, then the tool shall notify the user and either abort or copy as much data as possible into the destination 3) The tool should halt the target system during the acquisition process so that memory will not change and the page table will remain consistent V. REFERENCE SET DEVELOPMENT AND TEST Essentially, a reference set consists of test scenarios (cases) against which a EE tool or its individual function is validated. The development of test scenarios is based on the specification of function requirements. With the 669

6 requirements of forensic copy function specified in section IV, we are able to establish a reference set to test the forensic copy function of various EE tools. Since the function requirements are specified in a extensible way in our work, the corresponding reference set is also extensible. This will enable practitioners, tool developers, and researchers to identify critical needs and target deterministic reference sets. Since each requirement has several variables that lead to variations, we need to design multiple test scenarios for each requirement. Each scenario represents a requirement variation. Taking into account that NIST CFTT project has already done extensive work on static data forensic copy, we focus our work on dynamic data acquisition. The following are some pilot samples of the reference set for the forensic copy function. 1) Process granularity memory data acquisition in physical memory. 2) Process granularity memory data acquisition in vitual memory 3) Physical copy of IDE hard disk on live remote ftp server 4) A file copy of SATA hard disk on a remote web server 5) Passive network traffic capture in a LAN 6)... So far, we have completed the function mapping, requirements specification and reference set development. We now know what need to be tested and what are the expectations. Hence, validating a EE tool that professes to have the forensic copy function can be as simple as testing this tool against the reference set and applying metrics (accuracy and precision) to determine the accuracy and precision of the results. VI. CONCLUSION In this work, we present a scientific and systemical description of the EE practice through mapping fundamental functions required in the EE investigation process. With the function mapping, we propose a new function orientated validation and verification paradigm of EE tools. Focusing on the forensic copy function, we specify its requirements and develop a corresponding reference set. In the end, validating a EE tool can be as simple as testing this tool against the reference set. Compared to the traditional testing methods, our testing paradigm is extensible, tool and tool version neutral and transparent. To complete the entire validation paradigm, more work need to be carried out in the future. First, although the proposed methodology holds promise, we realize that it needs to be tested at least using one tool in order to evaluate the methodology and work out any potential weakness or shortcomings. Hence, some tests will be implemented against some real tools, such as EnCase and FTK. Secondly, a quantitative model is required to evaluate the results of validation and verification. For example, specific metrics are needed to measure the accuracy and precision of testing results. Then, we need to design judgement rules of validity of EE tools. How to judge if a tool is validated or not? Is a tool validated only when it passes all the test cases, or a tool validated in certain scenarios where it pass these test cases. REFERENCES [1] R. McKemmish, What is forensic computing? Australian Institute of Criminology, Trends and Issues, paper No. 118, Tech. Rep., June [2] Y. Guo, J. Slay, and J. Beckett, Validation and verification of computer forensic software tools searching function, Digital Investigation, vol. 6, no. Supplement 1, pp. S12 S22, [3] J. Beckett and J. Slay, Digital forensics: Validation and verification in a dynamic work environment, in System Sciences, HICSS th Annual Hawaii International Conference on, Jan. 2007, pp. 266a 266a. [4] Y. Guo and J. Slay, Data recovery function testing for computer forensics investigation tools, Accepted by Advances in Digital Forensics VI, will be published by Springer [5] G. M. Mohay, A. Anderson, B. Collie, R. D. McKemmish, and O. de Vel, Computer and Intrusion Forensics. Norwood, MA, USA: Artech House, Inc., [6] D. Brezinski and T. Killalea, Guidelines for Evidence Collection and Archiving, RFC 3227, Feb [7] E. Casey, Network traffic as a source of evidence: tool strengths, weaknesses, and future needs, Digital Investigation, vol. 1, no. 1, pp , [8] B. J. Nikkel, Generalizing sources of live network evidence, Digital Investigation, vol. 2, no. 3, pp , [9] B. D. Carrier and J. Grand, A hardware-based memory acquisition procedure for digital investigations, Digital Investigation, vol. 1, no. 1, pp , [10] D. Farmer and W. Venema, the Coroners Toolkit (TCT). Available at: [11] B. Schatz, Bodysnatcher: Towards reliable volatile memory acquisition by software, Digital Investigation, vol. 4, no. Supplement 1, pp , [12] C. Drake and K. Brown, Panic! unix system crash dump analysis handbook, [13] NIST(2004), Digital data acquisition tool specification (draft 1 of version 4.0, october 4, 2004), National Institute of Standards and Technology US Department of Commerce. Available from Tech. Rep. [14] Y. Guo and J. Slay, Testing forensic copy function of computer forensics investigation tools, Accepted by Journal of digital forensic practice, will be published in