Scott Conrad

Greg Dorn

Philip Craiger

Forensic Analysis of Plug Computers

Keywords: Plug computers, forensic analysis, SheevaPlug, Pogoplug

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Personal digital devices are becoming smaller and cheaper, an example of which is the plug computer. Plug computers are a cross between an embedded device (e.g., smart phone) and a traditional computer (e.g., laptop or desktop). Plug computers have the same general architecture as traditional computers (CPU, RAM, non-volatile memory, system bus, etc.), but are considerably smaller and less powerful. However, the forensic extraction and analysis of digital evidence from plug computers are neither as straightforward nor as simple as for typical desktops and laptops.

An example plug computer is the SheevaPlug [START_REF]SheevaPlug Development Kit Reference Design[END_REF] shown in Figure 1. It is roughly the size of a large A/C power supply adapter. SheevaPlug's low power consumption and cost (around $65) makes it ideal for use as a small-scale server, such as a home network attached storage (NAS) server.

Since their debut in early 2009, plug computers have generated considerable interest among developers and hobbyists, resulting in numerous applications ranging from file serving to cloud computing. Like desktops and laptops, plug computers have the potential to be used in nefarious ways, all the while maintaining a low profile because of their small size.

Despite the increasing popularity of plug computers, there is no published research on forensic procedures for extracting and analyzing digital evidence from these devices. This paper attempts to fill the void by discussing digital forensic procedures for two widely distributed plug computers, the SheevaPlug [START_REF]SheevaPlug Development Kit Reference Design[END_REF] by Marvell Semiconductor, and one of its commercial successors, the Pogoplug by Cloud Engines [START_REF]Pogoplugged.com[END_REF].

Plug Computer Overview

This section provides an overview of the SheevaPlug and Pogoplug plug computers, which are the focus of this paper.

The SheevaPlug uses a licensed version of ARMv5, an ARM architecture that is commonly found in cell phones. Its Marvell 88F6000 CPU is clocked at 1.2 GHz and has 16 KB of L1 cache and 265 KB of L2 cache, connected via a 64-bit MBus (system bus) clocked at 166 MHz. The SheevaPlug has 512 MB of DDR2 RAM and 512 MB of NAND flash memory, which serves as non-volatile memory (storage). It incorporates several external interfaces: a gigabit Ethernet port, a USB type A port, a mini USB port (used as its JTAG [8] and serial interface), and a secure digital input output (SDIO) flash card slot [START_REF]SheevaPlug Development Kit Reference Design[END_REF].

The Pogoplug has an almost identical architecture, except that it has no mini USB port and no SDIO flash card slot. The absence of a mini USB port makes it difficult to extract digital evidence from the Pogoplug's NAND flash memory.

A plug computer can be loaded with any operating system that supports the ARM architecture. However, Linux is the most commonly used operating system. Several pre-packaged Linux distributions are available, including Ubuntu, Gentoo, Debian, FreeBSD and Fedora [START_REF]Plug Wiki[END_REF].

The primary challenge in performing a forensic analysis of a plug computer is dealing with flash memory (non-volatile storage). Flash memory does not behave in the same manner as more common types of storage media such as a hard drive. For instance, writing to flash memory is done in complete blocks -changing even a single byte requires a complete block (typically 512 K) to be rewritten. This hinders the ability to recover deleted and unallocated data because of the likelihood that slack space will be overwritten; this also creates the need for a special file system that supports the writing of complete blocks.

The two most common file systems used with the SheevaPlug and Pogoplug are the Journaling Flash File System version 2 (JFFS2) and its successor, the Unsorted Block Image File System (UBIFS) [START_REF]UBIfs Wiki[END_REF][START_REF] Woodhouse | JFFS: The Journaling Flash File System[END_REF][START_REF] Woodhouse | UBI -Unsorted Block Images[END_REF]. These two file systems, as well as most other flash memory specific file systems, are log-structured systems that rely on the Memory Technology Device (MTD) subsystem [START_REF] Rosenbum | The design and implementation of a log-structured file system[END_REF]. Interested readers are referred to [START_REF] Woodhouse | JFFS: The Journaling Flash File System[END_REF] for additional details.

Interfacing with Plug Computers

The Joint Test Action Group (JTAG) [8] interface is an important mechanism for extracting the contents of plug computer memory. The JTAG interface is a debugging tool that allows users to directly control the circuits and chips on a memory board without accessing the operating system. In the case of plug computers, the JTAG interface is used primarily for reloading the boot loader (U-Boot, which is described below) and the operating system, although this can be accomplished over a serial connection using removable memory or a network protocol.

In a forensic investigation, the JTAG interface may be used to directly access and extract the memory contents. This is accomplished by directly controlling the CPU, having the CPU read the contents of a memory bank (RAM or NAND), and forwarding the bits back through the JTAG interface so that they can be captured and stored. The Open On-Chip Debugger (OpenOCD) software may be used for this purpose as it can control many different aspects of a plug computer through the JTAG interface as well as copy data to and from memory [START_REF] Amontec | Open On-Chip Debugger (OpenOCD), Vuippens, Switzerland[END_REF][START_REF] Rath | Open On-Chip Debugger[END_REF].

As mentioned above, the Pogoplug does not have a built-in JTAG interface like the SheevaPlug. However, the Pogoplug does have an 8-pin JTAG header on its motherboard, which makes it possible to use JTAG to acquire the memory contents. To accomplish this, a hardware JTAG adapter must be manually interfaced with the Pogoplug -since the 8-pin header has not been standardized -and then configured to work properly with the ARMv5 processor. Subsequently, OpenOCD or other similar software may be used to communicate with the processor. Although this can be accomplished in theory, we were unable to implement the JTAG interface during our research. Note that a serial interface can also be created by modifying a cable and then attaching the cable to a 4-pin header on the motherboard [START_REF]Pogoplugged.com, How to find mkfs, jffs and other tools on Pogoplug[END_REF][START_REF]Introduction to JTAG Scan[END_REF].

The boot loader U-Boot [START_REF] Brune | Lost of computer programming, Das U-Boot: The universal boot loader[END_REF][START_REF]Memory commands, DENX U-Boot and Linux Guide[END_REF]6] is used to initialize and load the operating system when a plug computer is powered on (assuming, of course, that an operating system is already installed). Note that U-Boot has a short timeout during which a user can manually abort the loading of the operating system via a serial connection. The U-Boot shell works much like the BASH shell in that it can run simple commands such as displaying or altering the current environmental variables; also, it supports simple shell scripts. In most cases, executing the printenv command to display environmental variables reveals what the boot loader will do when it attempts to boot the operating system. Interested readers are referred to [6] for additional details about U-Boot.

Imaging Non-Volatile Memory

Acquiring a bit-for-bit copy of the non-volatile memory is one of the first steps in a forensic investigation. This is a simple process in a typical desktop or laptop computer because the non-volatile memory (hard drive) can be removed and attached to a physical write blocker to obtain a forensic duplicate (image). However, this is difficult to do for a plug computer because the NAND flash memory is soldered to the motherboard. The most direct means of obtaining a copy of the memory is to desolder the chip from the motherboard and move it to a device that is capable of reading their contents. This is dangerous, however, because of the likelihood of losing or corrupting the data on the chip. Additionally, this method requires expensive, specialized equipment and training. For these reasons, we suggest that a desoldering method be employed only as a last resort.

Another method for creating an image is to boot the plug computer and use Linux utilities to create a forensic image. This task is easily accomplished using dd to read data directly from the flash device (/dev/mtd) and then stream the bits to a second target computer using the netcat utility (which reads and writes a stream of bits). Because there is no way to prevent writing to the NAND flash memory -for example, by inserting a write blocker -this is not a forensically-sound method for creating an image. Furthermore, the act of booting a plug computer (like any other computer) causes the data in memory to change in some way. There is also the possibility that a sophisticated user could use an anti-forensic measure or create daemons to automatically destroy the data if the plug computer is not booted in a specific way.

We have discovered that accessing memory through the JTAG interface is (arguably) forensically acceptable because it prevents nearly all types of writes to the memory. As described above, the JTAG interface allows for direct control over the plug computer via a USB port. This means that memory dumps of the NAND flash memory and RAM can be obtained directly from the plug computer without accessing the operating system or any other software running on the device. Thus, the only risk of unauthorized writes to plug computer memory comes from the JTAG software (OpenOCD) and the boot loader (U-Boot).

Note that the U-Boot environment can directly copy areas of memory to a target. Accordingly, we surmised that it should be possible to use a serial connection to copy data from the internal flash memory to external storage in order to obtain a forensic image, thus eliminating the need to use a JTAG scheme. Unfortunately, our attempts were unsuccessful because the copy command would not allow the target to serve as an external memory device [START_REF]Memory commands, DENX U-Boot and Linux Guide[END_REF].

Obtaining a Flash Memory Dump

This section describes the process we used to obtain a dump of the internal flash memory of the SheevaPlug. The acquisition computer was an Intel-based desktop computer running Ubuntu 9.10 (Linux kernel v2.6.31) and OpenOCD v0.2.0. We used a USB type A to mini USB data cable to connect the JTAG interface from the SheevaPlug to the acquisition computer.

Connecting to the SheevaPlug

Connecting the laboratory computer to the SheevaPlug plug computer using OpenOCD involves the following steps:

Connect the laboratory computer to the SheevaPlug using the JTAG interface (mini USB port).

Power on the SheevaPlug by plugging it into a power outlet.

Use a terminal emulator application (e.g., PuTTY) to connect to the SheevaPlug via the serial port (usually /dev/ttyUSB1 in Linux).

Stopping the operating system from booting.

This must be done quickly because the user only has a few seconds to stop the operating system from booting. Stop the operating system from booting by pressing any key at the prompt (Figure 2). Run OpenOCD on the laboratory computer (Figure 3). The Open-OCD manual [START_REF] Rath | OpenOCD User's Guide[END_REF] describes how to point the software to the correct SheevaPlug configuration file. Connect to OpenOCD telnet by issuing the command telnet localhost 4444.

Run the OpenOCD method sheevaplug init over the telnet connection. This will reset the plug computer, but immediately halt it and initialize the plug computer to allow control over the NAND flash memory and RAM.

Locate the flash devices by issuing the command NAND list and probe the devices using the command NAND probe num where num is a number given by NAND list (Figure 4).

Obtaining a Dump

The next step is to obtain a memory dump. The following steps are involved:

Execute the command NAND dump num filename beginning off set length to copy the memory contents from a flash device to a file on the laboratory computer. This action can take a considerable amount of time.

Execute the command dump image filename beginning offset length to copy the contents of RAM to a file on the laboratory computer, if desired.

Power off the plug computer when finished by pulling it out from the power outlet. This method does not allow the operating system to load, but it still achieves the goal of creating a forensic duplicate of the memory contents. Note, however, that a skilled programmer could alter U-Boot to corrupt the memory of a plug computer if the correct steps are not performed when powering on the device, but this is unlikely because the boot loader is a very small program and it may not be possible to reconfigure it to achieve such an effect.

In our experiments, it took more than a few hours to obtain a memory dump of the RAM and more than a month to obtain a dump of the NAND flash memory. The NAND flash memory dump has a transfer rate of roughly 1 MB per hour and all attempts to accelerate this process were unsuccessful. Writing to the NAND flash, on the other hand, is much faster; writing all 512 MB of memory only took a few hours.

Creating a Serial Connection to Pogoplug

Constructing a cable to establish a serial connection to the Pogoplug requires minimal soldering experience and inexpensive supplies. Infor-mation about the type of cable required available at [START_REF]Pogoplugged.com, How to find mkfs, jffs and other tools on Pogoplug[END_REF] and a description of wires in the cable is available at [START_REF]SheevaPlug Development Kit Reference Design[END_REF]. The resulting modified cable can be used to connect to the 4-pin header on the Pogoplug's motherboard and establish a serial connection to the device.

Forensic Analysis of Flash Memory

After the NAND flash memory contents are extracted, there are only a few options available for analysis. We know of no forensic tools, including the most popular forensic suites, that have been developed to specifically analyze the data. Research on the subject of recovering deleted data from NAND flash memory [START_REF] Breeuwsma | Forensic data recovery from flash memory[END_REF][START_REF] Regan | The Forensic Potential of Flash Memory[END_REF] focuses on the physical memory level rather than the logical file system level. Thus, the only reasonable option is physical analysis with a hex editor. The logical level could be replicated by using a laboratory computer to mount the image virtually or by writing the entire NAND flash memory image to another identical plug computer.

We attempted to use the OpenOCD software to write the NAND image to a second plug computer. The command NAND write num filename offset copies the NAND image filename to the NAND device num starting at offset in the NAND device. After the copy process is complete, the plug computer can be restarted and, in theory, should boot up normally as with any cloned device. Unfortunately, our attempts at using this method were unsuccessful.

The only successful method that we discovered for logical analysis is to mount an image as a read only device in a Linux environment using software tools that emulate NAND flash memory. The following steps are involved in mounting a JFFS2 file system: mknod /temp/mtdblock 0 b 31 0. modprobe loop (may not be necessary). losetup -f (returns a free loopback device, e.g., /dev/loop0). modprobe mtdblock. modprobe block2mtd. echo /dev/loop0,128KB /sys/module/block2mtd/parameters /block2mtd. modprobe jffs2. mount -t jffs2 /tmp/mtdblock0 (mount point).

Note that this technique works with the file system partition and not with the U-Boot partition or with the entire NAND flash memory image. If the entire NAND flash image is provided, the U-Boot partition, which usually constitutes the first few megabytes, must be carved out.

External Storage Considerations

Plug computers were originally designed to serve as network attached storage (NAS) servers, which require external storage media. The external storage could be an external hard drive, USB flash drive or, in the case of the SheevaPlug, a SDIO flash card. The external storage may be formatted with a common file system (e.g., FAT, EXT 2/3/4 or NTFS) or a less common file system (e.g., Minix, FUSE, HFS, HFS+, UFSD or VFAT) [START_REF]Cloud Engines, Pogoplug[END_REF]. Plug computers also have the ability to format the external storage with most of these file systems, although this is typical of any Linux operating system.

The SheevaPlug and Pogoplug handle external storage differently. The SheevaPlug handles its external storage in the same way as any Linux machine -storage devices are mounted for access and use. The Pogoplug, on the other hand, automatically modifies external storage connected to it by adding its own system files. The files created are /ceid and /.cedata/cedb and the folder created is .cedata. File .ceid is a text file that contains a 22-character diskid while file cedb is an SQLite database file [7]. The database cedb contains an entry for every non-hidden file on the external storage; each entry contains the name, path, creation time and data type of the file. The creation time is in the UNIX timestamp format with three additional digits appended to it. Thus, the timestamp corresponding to the date 10 Oct 2010 09:08:07 is 1286701687XXX with XXX as the three additional digits.

Figure 5 shows the cedb database as viewed using an SQLite manager. We observed that the cedb database contains entries for deleted files. When a file is removed using the Pogoplug software (e.g., via the website interface), the file entry is removed from the database. However, if the file is manually deleted from storage, regardless of whether or not the storage is connected to the Pogoplug or to another machine, the file entry remains in the database.

In general, the forensic analysis of external storage should require little or no special considerations because plug computers almost always use widely available Linux distributions (e.g., Debian or Redhat). However, investigators should be mindful of the circumstances under which external storage may be affected.

Conclusions

Extracting and analyzing digital evidence in a forensically sound manner are becoming significantly more difficult for low form factor computers. Extracting data from a plug computer to create a forensic image is challenging but, nevertheless, possible. However, analyzing the image is difficult because the lack of automated tools necessitates manual analysis.

Second generation versions of the SheevaPlug and Pogoplug have already been announced, and many new plug computer models are in development. Meanwhile, manufacturers such as Seagate and Iomega have integrated plug computer concepts in their own product lines (e.g., FreeAgent from Seagate [18] and iConnect from Iomega [START_REF]Iomega, Iomega iConnect wireless data station[END_REF]). The digital forensics research and vendor communities must intensify their efforts to keep up with this growing segment of low form factor computers, and develop forensically sound techniques and tools for extracting and analyzing digital evidence from these devices.

Figure 1 .

 1 Figure 1. SheevaPlug plug computer.

Figure 3 .

 3 Figure 3. Running OpenOCD.

Figure 4 .

 4 Figure 4. Locating and NAND flash memory.

Figure 5 .

 5 Figure 5. View of a cedb database.


Christian Winter

Markus Schneider

York Yannikos

Chapter 10 DETECTING FRAUD USING MODIFIED BENFORD ANALYSIS

Keywords: Auditing, fraud detection, Benford analysis

Large enterprises frequently enforce accounting limits to reduce the impact of fraud. As a complement to accounting limits, auditors use Benford analysis to detect traces of undesirable or illegal activities in accounting data. Unfortunately, the two fraud fighting measures often do not work well together. Accounting limits may significantly disturb the digit distribution examined by Benford analysis, leading to high false alarm rates, additional investigations and, ultimately, higher costs. To better handle accounting limits, this paper describes a modified Benford analysis technique where a cut-off log-normal distribution derived from the accounting limits and other properties of the data replaces the distribution used in Benford analysis. Experiments with simulated and real-world data demonstrate that the modified Benford analysis technique significantly reduces false positive errors.

Introduction

Financial fraud is a major risk for enterprises. Proactive access restrictions and post facto forensic accounting procedures are widely employed to protect enterprises from losses. Many practitioners assume that access restrictions do not impact the effectiveness of forensic methods -if they consider the interdependencies at all. However, this is not necessarily true.

Auditors often use Benford analysis [START_REF] Durtschi | The effective use of Benford's law to assist in detecting fraud in accounting data[END_REF] to identify irregularities in large data collections. Benford analysis is frequently applied to accounting and tax data to find traces of fraudulent activity [START_REF] Nigrini | Digital Analysis Using Benford's Law[END_REF]. Benford analysis is based on Benford's law [START_REF] Nigrini | The use of Benford's law as an aid in analytical procedures[END_REF], which states that the frequencies of leading digits in numbers follow a non-uniform distribution. This Benford distribution is a logarithmic distribution that decays as the digits increase. When using Benford analysis to check financial data for irregularities, auditors test the data for conformance with Benford's law.

If an enterprise enforces accounting limits for certain employees, for example, a limit of $5,000, the frequencies of leading digits in the data created by these employees deviate from the Benford distribution. Since this deviation is much larger than that produced by pure chance, Benford analysis of the data would generate more false positive alerts.

This paper respects the implications of access restrictions (e.g., payment and order limits) by using a log-normal reference distribution derived from the data. The resulting modified Benford analysis compares the frequencies of leading digits in the data to the reference distribution. Applying the modified Benford analysis to simulated and real-world data gives rise to lower false positive rates, which, in turn, reduces auditing costs.

Benford Analysis

Benford's law states that numbers in real-world data sets are more likely to start with small digits than large digits [START_REF] Benford | The law of anomalous numbers[END_REF][START_REF] Newcomb | Note on the frequency of use of the different digits in natural numbers[END_REF]. Specifically, the Benford distribution determines the probability of encountering a number in which the n most significant digits represent the integer d (n) . The probability of the associated random variable D (n) is given by:

Pr(D (n) = d (n) ) = log(d (n) + 1) -log(d (n) ) = log 1 + 1 d (n) (1)
Benford's law has been shown to hold for data in a variety of domains. Nigrini [START_REF] Nigrini | Digital Analysis Using Benford's Law[END_REF] was the first to apply Benford's law to detect tax and accounting fraud.

The Benford analysis methodology compares the distribution of first digits in data to a Benford distribution. Alerts are raised when there is a large deviation from the Benford distribution.

Benford analysis is typically an early step in a forensic audit as it helps locate starting points for deeper analysis and evidentiary search. In order to identify nonconforming data items (i.e., those needing further investigation), it is necessary to quantify the deviation of the data from the reference Benford distribution. This is accomplished using statistical tests or heuristic methods.

A statistical test quantifies the deviation between the data and the reference distribution using a test statistic. The p-value and significance level α are crucial quantities for assessing the selected test statistic. The p-value is the probability that the test statistic is at least as large as currently observed under the assumption that the data is generated according to the reference distribution. A statistical test yields a rejection if the p-value is small (i.e., the test statistic is large). The threshold for rejection is specified by the significance level α.

An example is the chi-square test, which uses the chi-square statistic to calculate the p-value. Comparison of the p-value with α may result in rejection. A rejection is either a true positive (i.e., fraud is indicated and fraud actually exists) or a false positive (i.e., fraud is indicated, but no fraud actually exists).

Other measures for determining the deviation include the "mean absolute deviation" and the "distortion factor" [START_REF] Nigrini | Digital Analysis Using Benford's Law[END_REF]. The thresholds for rejection are typically chosen in a heuristic manner for Benford analyses that use these measures.

A limitation of Benford analysis is that non-fraudulent data must be sufficiently close to the Benford distribution. Two techniques are available for determining if the data meets this condition: mathematical approaches [START_REF] Boyle | An application of Fourier series to the most significant digit problem[END_REF][START_REF] Dumbgen | Explicit bounds for the approximation error in Benford's law[END_REF][START_REF] Pinkham | On the distribution of first significant digits[END_REF][START_REF] Raimi | The first digit problem[END_REF] and rules of thumb [START_REF] Durtschi | The effective use of Benford's law to assist in detecting fraud in accounting data[END_REF][START_REF] Gauvrit | Scatter and regularity imply Benford's law[END_REF][START_REF] Lu | Detecting fraud in health insurance data: Learning to model incomplete Benford's law distributions[END_REF][START_REF] Nigrini | Digital Analysis Using Benford's Law[END_REF][START_REF] Nigrini | The use of Benford's law as an aid in analytical procedures[END_REF][START_REF] Scott | Benford's Law: An Empirical Investigation and a Novel Explanation[END_REF][START_REF] Watrin | Benford's law: An instrument for selecting tax audit targets[END_REF].

One rule of thumb is that data is likely close to the Benford distribution if it has a wide spread, i.e., it has relevant mass in multiple orders of magnitude. Because accounting data and other financial data usually have a wide spread, we can assume that this rule does not limit the application of Benford analysis in the accounting and financial domains.

Another rule of thumb is that non-fraudulent data must not artificially prefer specific digits in any position. This automatically holds for natural data with a wide spread. However, human-produced numbers (artificial data) such as prices can be based on psychologically-chosen patterns (e.g., prices ending with 99 cents). But such patterns are more common in consumer pricing than in business and accounting environments.

Another rule of thumb is that Benford analysis should not be performed when the data has an enforced maximum and/or minimum [START_REF] Durtschi | The effective use of Benford's law to assist in detecting fraud in accounting data[END_REF][START_REF] Nigrini | The use of Benford's law as an aid in analytical procedures[END_REF]. This is problematic because limits are imposed in many accounting environments. When accounting limits exist, it is only possible to apply Benford analysis to the global data, not to data pertaining to single individuals. This is because the global data does not have enforced limits.

Handling Accounting Limits

In order to determine how an accounting limit affects the distribution of leading digits, it is necessary to make an assumption about the overall distribution of data. The cut-off point at an accounting limit is just one property of the overall distribution and is, therefore, not sufficient to derive a reference digit distribution.

The first step in handling an accounting limit is to identify a reasonable distribution model for the accounting data without the cut-off. Unfortunately, a normal distribution does not match the Benford distribution. However, the logarithms of the data values can be assumed to have a normal distribution, i.e., the data has a log-normal distribution. A log-normal distribution is specified by the mean µ and standard deviation σ of the associated normal distribution.

Several researchers [START_REF] Gauvrit | Scatter and regularity imply Benford's law[END_REF][START_REF] Pinkham | On the distribution of first significant digits[END_REF][START_REF] Scott | Benford's Law: An Empirical Investigation and a Novel Explanation[END_REF] have considered log-normal distributions in the context of Benford's law. In general, they agree that conformance with the Benford distribution increases as σ increases. The multiplicative central-limit-theorem argument, which is used to explain the validity of Benford's law, also justifies the use of a log-normal data distribution. Bredl, et al. [START_REF] Bredl | A Statistical Approach to Detect Cheating Interviewers[END_REF] have confirmed that financial data can be assumed to have a log-normal distribution.

The next step in handling an accounting limit is to introduce a cut-off to the log-normal distribution corresponding to the limit. The resulting cut-off log-normal distribution may be used in the analysis.

Thus, the "modified Benford analysis" technique involves:

Identifying a suitable log-normal distribution.

Cutting-off the log-normal distribution at the accounting limit.

Deriving a reference digit distribution from the cut-off log-normal distribution.

Statistically testing the data against the derived distribution.

A suitable log-normal distribution can be identified by estimating the mean and standard deviation parameters from the data. Unfortunately, it is not known a priori if the data contains traces of fraud and where these traces are located. Consequently, the identified distribution is affected by fraudulent and non-fraudulent postings. In general, the influence of fraudulent postings on the estimated parameters is marginal and the distortion in the distribution due to these postings is large enough to be detected during testing.

Modified Benford Analysis

Two assumptions are made to simplify the determination of the cutoff log-normal distribution. First, the global data is assumed to have no enforced limits. Second, the distribution of data generated by a single employee is assumed to conform to the global distribution except for cutoffs. This may not be true if the employees have different accounting tasks that do not differ only in the accounting limits.

Based on the assumptions, the mean and standard deviation of the global log-normal distribution are estimated as the empirical mean and standard deviation of the logarithms of the global data values. These values are used to create the reference distribution for the overall data and to calculate a cut-off distribution for individual employees with accounting limits.

Log-Normal Distribution

The desired log-normal distribution is most conveniently obtained by starting with the normal distribution of logarithms, which has the probability density function g and cumulative distribution function G:

g(y) = 1 √ 2πσ exp - 1 2 y -µ σ 2 (2)
G(y) = y -∞ g(t)dt (3)
Note that the functions associated with the uncut distribution have a tilde (∼) above them to distinguish them from the functions associated with the cut-off log-normal distribution.

The distribution is then transformed to the log-normal distribution by calculating the cumulative distribution function F , followed by the probability density function f , which is the derivative of F :

F (x) = G log(x) for x > 0 (4) f (x) = g(log(x)) ln(10) • x for x > 0 (5)

Cut-Off Limits

Introducing a cut-off requires a rescaling of the distribution to obtain a probability mass of 1.0 over the desired range. Given an upper limit M ≤ ∞ and a lower limit m ≥ 0, the updated probability density function and cumulative distribution function are given by: Similarly, the probability density function g and cumulative distribution function G of the cut-off logarithms are computed using the bounds m ′ = log(m) and M ′ = log(M ).

f (x) = f (x) e F (M )-e F (m) for m ≤ x ≤ M 0 otherwise (6)
F (x) = ⎧ ⎨ ⎩ e F (x)-e F (m) e F (M )-e F (m) for m ≤ x ≤ M 0 otherwise (7) !!"" " #$##%# #$##&' #$##&# #$###' # # &### %### (### )### '### $####% # '### $##&* #%( ##&' # &## ##) g † (

Leading Digit Distribution

Computing the distribution of leading digits requires the collection of all numbers x > 0 with the same significand s ∈ [1; 10). These numbers are used to construct the set {s • 10 n : n ∈ Z}. The probability density function θ and cumulative distribution function Θ of the distribution of significands are given by:

θ(s) = n∈Z f (s • 10 n ) for s ∈ [1; 10) (8)
Θ(s) = n∈Z F (s • 10 n ) -F (10 n ) for s ∈ [1; 10) (9)
The computation of the distribution of D (n) uses the distribution of significands. In particular, for d ∈ {1, . . . , 9}, Pr(D (1)

= d) = Θ(d + 1) - Θ(d).
Our modified Benford analysis technique uses this distribution as the reference distribution in the chi-square test on the leading digits to test for fraud. Figure 1 shows an example with typical accounting parameters specified in U.S. dollars. A cut-off log-normal distribution with µ = log(350), σ = 0.6 and M = 5, 000 is compared with the Benford distribution. Although the distribution of first digits differs only slightly from the Benford distribution, the difference could be relevant when analyzing large data samples. Table 1 in the next section shows that Benford analysis yields results of moderate quality for this cut-off log-normal configuration.

Alternative Setup

If the data only has enforced limits or if the globally-estimated parameters are not suitable for the data generated by an individual employee, then the mean and standard deviation of the global set of logarithms are not suitable parameters. The maximum likelihood method must then be used to obtain suitable parameters. In our case, the maximum likelihood method uses the logarithms of the data values and the density of the cutoff normal distribution to define a likelihood function. An optimization algorithm is employed to determine a local optimum of the likelihood function that yields the parameters of the desired log-normal distribution. Note that this step must deal with cut-offs during the parameter identification step.

Results with Synthetic Data

Synthetic accounting data is used to compare the effectiveness of modified Benford analysis versus conventional Benford analysis for two reasons. First, it is difficult to obtain real-world accounting data. Second, it is not possible to control the type and amount of fraud present in real data.

The synthetic data used in the experiments was created by the 3LSPG framework [START_REF] Yannikos | 3LSPG: Forensic tool evaluation by three layer stochastic process based generation of data[END_REF]. The simulations produced data corresponding to nonfraudulent and fraudulent employees; the fraudulent employees occasionally made unjustified transactions to accomplices. The fraudsters attempted to conceal their activities by choosing amounts that would be checked less carefully. We assumed that amounts of $100 or more required secondary approval and, therefore, the fraudsters paid a little less than $100 (i.e., an amount with 9 as the leading digit) to their accomplices. The frequency of occurrence of fraud was set to 0.01.

Table 1 compares the results obtained using modified Benford analysis (MBA) and conventional Benford analysis (BA) for various distributions. Each analysis used the chi-square test on the first digits with significance α = 0.05. The table reports the number of times the tests made rejections over 100 simulations. The rejections correspond to true positive (TP) alerts for fraudsters and false positive (FP) alerts for non- fraudulent employees. The quality of an analysis technique depends on the disparity between the corresponding true and false positive counts.

The conventional Benford analysis results vary according to the limits imposed. The two analysis techniques produce comparable results when an accounting limit is not imposed (limit = ∞) because the underlying distribution of data is sufficiently close to the Benford distribution. However, the effectiveness of conventional Benford analysis diminishes when the accounting limit increases the deviation from the Benford distribution. The results show that conventional Benford analysis completely fails for an accounting limit of $5,000 and µ = log(1, 800). In the case where µ = log(350), conventional Benford analysis distinguishes between fraudulent and non-fraudulent employees. But if one considers the fact that most employees are not fraudsters, the rate of false positives is too high.

The results show that modified Benford analysis performs as well or better than conventional Benford analysis in every instance. The false positive rate from modified Benford analysis is always low, and the rate of detected cases of fraud grows with the sample size because the discriminatory power of statistical tests increases as the sample size increases.

Results with U.S. Census Data

The results of the previous section demonstrated that modified Benford analysis is effective regardless of the cut-off log-normal setting. However, while simulated data is guaranteed to match the chosen distribution, real-world data may not fit the log-normal assumption.

This section presents the results obtained with a real-world data set obtained from the U.S. Census Bureau [START_REF]Population Estimates -Counties[END_REF]. The data set provides the numbers of inhabitants in U.S. counties according to the 1990 census. The advantage of using census data over real-world accounting data is that it can be safely assumed that no fraud exists in the data. Therefore, a Benford analysis technique should result in acceptance; any rejection is a false alert. Indeed, the chi-square test on the first digits yielded p = 0.063 -and, thus, no rejection -when using the Benford distribution as reference.

As described earlier, modified Benford analysis requires the computation of the log-normal distribution parameters. The empirical mean and standard deviation of the logarithms of the census data were µ = 4.398 and σ = 0.598. Using these parameters, the chi-square test in a modified Benford analysis yielded p = 0.064. Note that both techniques are applicable to data without cut-offs.

The cut-offs in Table 2 were applied to test the ability of the modified Benford analysis technique to handle cut-offs. The upper and lower cut-off points were used to generate sufficient test cases to compare the accuracy of conventional and modified Benford analysis. The results are presented in Tables 3, 4 and 5. Note that p-values smaller than 2 -52 ≈ 2E-16 are set to zero in the tables.

As expected, conventional Benford analysis (Table 3) yields poor results, except for a few cases where the cut-off points introduce minor changes in the distribution. For α = 0.05, acceptance occurs in only three cases (bold values).

A quick fix to conventional Benford analysis that respects the limits is implemented by changing the Benford distribution of the first digits to only include the possible digits. The digits that were not possible were assigned probabilities of zero while the probabilities for the possible digits were scaled to sum to one. Table 4 shows that this technique yields a marginal improvement over conventional Benford analysis with four (as opposed to three) acceptance cases. The results in Table 5 show that modified Benford analysis yields much better results -the number of acceptances is thirteen. This result has to be qualified, however, because acceptance occurs in the cases where the cut-offs do not introduce much distortion and where there are relatively few samples left after the cut-offs are performed. The results show that the log-normal distribution is not ideally suited to the census data. Nevertheless, modified Benford analysis yields significantly better results than conventional Benford analysis for data with cut-offs.

Related Work

Several researchers have defined adaptive alternatives to the Benford distribution. One approach [START_REF] Lu | Detecting fraud in health insurance data: Learning to model incomplete Benford's law distributions[END_REF] addresses the issue of cut-offs by adjusting the digit probabilities in a manner similar to our quick fix. Other approaches [START_REF] Hurlimann | Generalizing Benford's law using power laws: Application to integer sequences[END_REF][START_REF] Rodriguez | First significant digit patterns from mixtures of uniform distributions[END_REF] employ parametric distributions of digits that are fitted to observed digit distributions by various methods. The latter approaches, however, are not designed to discover irregularities.

Other researchers, e.g., Pietronero, et al. [START_REF] Pietronero | Explaining the uneven distribution of numbers in nature: The laws of Benford and Zipf[END_REF], start with a suitable distribution model for the data, which they use to derive a reference distribution of digits. They use power laws that are relevant to their domains of application. Note however, that while the approach is similar to the modified Benford analysis technique presented in this paper, it does not address the issue of cut-off points.

Conclusions

The modified Benford analysis technique overcomes the limitation of conventional Benford analysis with regard to handling access restrictions. The technique reduces false positive alerts and, thereby, lowers the costs incurred in forensic accounting investigations. The false positive rate is independent of the accounting limits because the modified Benford analysis technique adapts to the limits.

The results obtained with synthetic and real-world data demonstrate that modified Benford analysis yields significant improvements over conventional Benford analysis. Our future research will conduct further assessments of the effectiveness of the modified Benford analysis technique using real-world accounting data and fraud cases. Additionally, it will compare the modified Benford analysis technique with other Benford analysis formulations, and identify improved distribution models that would replace the log-normal model.

Figure 1 .

 1 Figure 1. Comparison of cut-off log-normal and Benford distributions.

Table 1 .

 1 Comparison of modified and conventional Benford analysis.

	Distribution Parameters Sample	BA		MBA
	Limit	µ	σ	Size	TP FP TP FP
				1,000	11	8	11	8
	∞ log(1, 800)	0.6	3,000	25	1	25	1
				9,000	84	5	84	5
				1,000	100	99	13	4
	5,000 log(1, 800)	0.6	3,000	100 100	26	4
				9,000	100 100	91	4
				1,000	14	6	9	5
	5,000	log(350)	0.6	3,000	46	15	33	1
				9,000	93	34	80	1

Table 2 .

 2 U.S. counties with inhabitants within upper and lower limits.

	Lower	0	1K	5K	10K	20K 50K 200K 1M
	Upper
	1K	28
	5K	299	271
	10K	756	728	457
	20K 1,463 1,435 1,164	707
	50K 2,299 2,271 2,000 1,543	836
	200K 2,897 2,869 2,598 2,141 1,434	598
	1M 3,111 3,083 2,812 2,355 1,648	812	214
	∞ 3,141 3,113 2,842 2,385 1,678	842	244	30

Table 3 .

 3 Benford analysis (p-values).

	Lower	0	1K	5K	10K 20K 50K 200K	1M
	Upper
	1K 3E-06
	5K	0	0
	10K	0	0	0
	20K	0	0	0	0
	50K	0	0	2E-15	0	0
	200K 1E-04 9E-05 5E-15	0	0	0
	1M 0.097 0.072 1E-07	0	0	0	0
	∞ 0.063	0.041	3E-08	0	0	0	9E-16 1E-04

Table 4 .

 4 Benford analysis with digit cut-off rule (p-values).

	Lower	0	1K	5K	10K	20K	50K	200K	1M
	Upper
	1K 3E-06
	5K	0	0
	10K	0	0	0.019
	20K	0	0	1E-11 1.000
	50K	0	0	2E-15	0.008	0.032
	200K 1E-04 9E-05 5E-15	0	0	3E-09
	1M 0.097 0.072 1E-07	0	0	0	0.003
	∞ 0.063	0.041	3E-08	0	0	0	9E-16 1E-04

Table 5 .

 5 Modified Benford analysis (p-values).

	Lower	0K	1K	5K	10K	20K	50K	200K	1M
	Upper
	1K 0.575
	5K 0.691 0.549
	10K 6E-04 3E-04 0.510
	20K 7E-04 9E-04 0.275 1.000
	50K 8E-04 7E-04	0.001	4E-04	0.037
	200K	0.032	0.025	0.005	2E-05 1E-06 0.711
	1M 0.081 0.068	0.044	0.007	1E-04 0.302 7E-06
	∞ 0.064 0.054	0.033	0.005	0.001 0.588 1E-07 9E-05

Acknowledgements

This research was supported by the Center for Advanced Security Research Darmstadt (CASED), Darmstadt, Germany.


Clive Blackwell

AN INVESTIGATIVE FRAMEWORK FOR INCIDENT ANALYSIS

Keywords: Incident framework, security architecture, investigative questions

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Security incident ontologies often provide subjective and incomplete representations of incidents by focusing on the digital aspects and only considering the offensive or defensive viewpoints. They do not include the interactions between people and their external physical and digital environments. These interactions provide a wider investigative context for the examination of the progression and effects of incidents.

The utility of these models to digital forensics is also unclear because they do not elucidate the evidence available to the investigator after the event or map to investigative goals. It is necessary to model the investigator's methods, tools and techniques in evidence collection, analysis and response to meet the goals of incident discovery, attribution, recovery, fixing weaknesses and prosecution. This paper presents a digital forensic investigative framework that considers computer crime and incidents in their entirety rather than as logical incidents alone. The framework incorporates three layers that comprise the social, logical and physical levels of an incident; it extends and adapts the Zachman framework [START_REF] Zachman | A framework for information systems architecture[END_REF] and the Howard-Longstaff security incident taxonomy [START_REF] Howard | A Common Language for Computer Security Incidents[END_REF]. Each layer consists of several sublevels for more detailed analysis, two for the physical and social levels, and five for the logical level. The resulting framework presents a holistic and persuasive forensic analysis, which considers the entire incident context (including human and physical factors) to observe, analyze and prove incident causality.

The framework also facilitates the decomposition of complex incidents into their atomic stages along with their causes and effects. This is crucial because evidence about incident events and their timeline may be partial and indirect after the incident, requiring the investigator to infer the missing events from hypotheses about the incident. The utility of the investigative framework is demonstrated using a case study involving the insider threat.

Background

The Zachman framework [START_REF] Zachman | A framework for information systems architecture[END_REF] (Table 1) is a complex model for designing enterprise computing architectures. This framework attempts to capture and organize information about every aspect of an organization related to its computing requirements. It consists of five levels: contextual, conceptual, logical, physical and detailed. The Zachman framework also provides a second dimension where six questions are posed to describe the different aspects of the system; these questions are answered for each of the five levels.

Unlike the Zachman framework, the proposed forensic framework is intended to guide the investigative process and establish the completeness of incident analysis. Since the focus is on modeling processes and not on designing enterprise computing architectures, the investigative questions in the Zachman framework are adapted to operational concerns.

Ieong [START_REF] Ieong | FORZA: Digital forensics investigation framework that incorporates legal issues[END_REF] has adapted the Zachman framework for forensic analysis in the FORZA framework. The FORZA questions are analogous to the Zachman questions, except that they are applied to operational concerns. The investigative framework presented in this paper differs from FORZA by posing all six questions for each stage in an incident progression as well as for the entire incident. Interestingly, the U.S. Department of Justice's Digital Forensics Analysis Methodology [START_REF][END_REF] asks five of the six questions (omitting why) in the analysis phase. Pollitt [START_REF] Pollitt | Six blind men from Indostan[END_REF] has analyzed the investigative process, which is distinct from the incident process discussed in this work.

The Sherwood Applied Business Security Architecture (SABSA) [START_REF] Sherwood | Enterprise Security Architecture: A Business Driven Approach[END_REF] is an adaptation of the Zachman framework to security. SABSA considers each of Zachman's concepts from a security perspective, replacing each cell in the table with its security analog.

Howard and Longstaff [START_REF] Howard | A Common Language for Computer Security Incidents[END_REF] have proposed an alternative security incident taxonomy (Figure 1). The Howard-Longstaff taxonomy organizes incidents into stages with different purposes, actors, scopes and effects. The categories are attacker, tool, vulnerability, action, target, unauthorized result and objectives. The attacker uses a tool to perform an action that exploits a vulnerability on a target, causing an unauthorized result that meets the attacker's objectives.

Digital Forensic Framework

The proposed digital forensic investigative framework focuses on the social, physical and logical aspects of incidents. It extends the Zachman framework [START_REF] Zachman | A framework for information systems architecture[END_REF] and the Howard-Longstaff taxonomy [START_REF] Howard | A Common Language for Computer Security Incidents[END_REF]. The extension enables the investigative framework to support detailed and comprehensive analyses of incidents.

The proposed framework comprises three layers: social, logical and physical. Each layer is partitioned into sublevels to support more detailed analyses. The resulting partitioning follows the OSI seven-layer model [START_REF] Tanenbaum | Computer Networks[END_REF]; it has two sublevels for the social and physical layers, and five for the logical layer. The Zachman framework and the Howard-Longstaff taxonomy do not address the possibility that a perpetrator may use a third party to perform a stage of the incident. This can take the form of social engineering or using an intermediary computer or user account at the logical level. For this reason, we separate an incident into two components. The first component is the complete incident containing the perpetrator's objective or ultimate goal. The second is the stage, which contains the specific details of the event and contains most of the evidence.

Social Level

The social level of the investigative framework covers incident perpetrators and their intangible attributes such as motivation. It permits the differentiation between real-world actions and the resulting effects on people and organizations.

The social level consists of the reflective and activity sublevels, which contain intangible aspects such as motivation, and tangible concerns such as actions and their effects respectively (modeled in Figure 2). With regard to the investigative questions, the reflective sublevel includes the motivation (ultimate why) and abilities (latent aspect of the ultimate how) of the perpetrator. The involved people and organizations (ultimate who) occupy the entire social level, encompassing both sublevels to represent the duality of their thoughts at the reflective sublevel and actions at the activity sublevel.

The reflective sublevel contains the evidence relevant to the investigation that is lifted from information collected in the lower levels. The evidence seeks to answer the who, what, why, when, where and how questions about each individual stage of an incident as well as about the entire incident. The proposed framework assists by specifying where and when this evidence can be collected.

The activity sublevel, which occupies the remainder of the social level, relates to incident progression and investigative processes that involve action. It contains the abstraction of the resources and authority (remainder of the ultimate how) of the involved parties. The how is performed at the lower levels, but the progression of the entire incident and corresponding investigation can be modeled conceptually at the social level by abstracting its low-level execution. The objectives (ultimate what) are at the activity sublevel if their intent is to bring about a financial or functional gain. They are at the reflective sublevel if they are psychologically motivated (e.g., revenge by a disgruntled employee).

The ultimate when and ultimate where relate to the conceptual locations where the lower-level actions affect people and organizations at the social level. A victim of credit card fraud is affected if the card is declined (ultimate when) while making a purchase (ultimate where). The actual incident occurs at the lower levels, such as the logical level if the credit card details were stolen and used to make unauthorized purchases. The logical effects of reducing the available funds in the cardholder account database are latent in nature and do not directly affect the victim. The victim is only affected when he/she attempts to use the funds later, which occurs at the social level by reducing his/her ability to purchase goods.

Logical Level

The logical level has five sublevels: application, service, operating system, hardware and physical.

The application sublevel deals with logical services and the use of logical resources such as data. At this sublevel, an incident has a logical effect through undesirable events or changes in the logical state (logical what); this is because the application sublevel meets the social level objectives. The incident actions (logical how) occur at lower levels that are controlled by the operating system. For example, credit card use is at the application sublevel when purchases are made online while its computational operations are executed at lower levels. The investigator needs to establish the link to a person via the social-logical interface based on the logical activities carried out on the person's behalf. The user is the logical agent (logical who) that executes logical processes at the lower levels. The purpose of logical actions (logical why) is derived from their ultimate purpose at the social level.

The service sublevel provides methods (logical how) for obtaining the results required by an application (logical why) through some processing, communication, translation, storage or protection service. In general, the lower logical sublevels provide methods (logical how) for obtaining the results required by the higher levels (logical why); thus, the how at each upper level becomes a why when it is performed at a lower level.

Logical operations are executed in a low-level venue (logical where and when). The investigator may find potential evidence at the lower levels from residual data after its higher-level representation has been destroyed. However, specialized expertise and tools are often needed to recover the data because the lower levels are not intended to be directly accessible. In addition, the investigator may face significant challenges in interpreting the collected data as evidence because low-level events are far removed from the ultimate cause.

Physical Level

The physical level is also significant with regard to computer incidents. This is because many incidents combine the logical and physical aspects, and all computational activities are ultimately performed at the physical level.

The physical level contains two sublevels: the material sublevel of substantial objects and the wave sublevel of intangible phenomena (e.g., electromagnetic radiation) that are determined by the size of the object and the focus of the investigation. The material sublevel covers the physical aspects of a crime scene investigation that involves long-established techniques.

The physical level is significant for incidents that involve computational and physical actions, in which case there needs to be comprehensive collection and integration of evidence at all levels. An example is the Integrated Digital Investigation Process (IDIP) [START_REF] Carrier | Getting physical with the digital investigation process[END_REF], which unifies digital and physical crime scene investigations. All activities are ultimately executed physically, so the six investigative questions can be asked about the execution of any higher-level process at the physical level.

Operational Framework

The incorporation of the Zachman framework [START_REF] Zachman | A framework for information systems architecture[END_REF] and the Howard-Longstaff [START_REF] Howard | A Common Language for Computer Security Incidents[END_REF] taxonomy is an important aspect of the framework. The ultimate and stage components are decomposed into the six investigative questions from the Zachman framework (who, what, why, when, where and how). The ultimate and stage investigative questions map to the Howard-Longstaff model, where the who refers to the attackers, the how is the method/tool and the vulnerability, the why is the reasons/objectives, the where is the target, and the what is the effect and the unauthorized result. The when is included implicitly in the proposed framework table within the timeline of incident progression. Table 2 presents the framework for an insider threat involving sabotage. Table 3 shows the associated stage aspects.

The incident classification is linked with the six investigative questions to help organize the investigation. Tables 2 and3 have headings for the incident and stage entities, processes, purposes and outcomes, respectively, along with the investigative questions (five of the questions are subheadings of an incident column and a stage column). It is necessary to raise the information collected about incident events to the status of evidence at the social level, which requires reasoned, relevant and admissible arguments. The steps at the lower levels of the stage table may be annotated with vertical arrows to show how the investigation can transform collected information about the contents of each column to evidence at the social level by answering the corresponding investigative question. The responses to the stage questions help answer the incident questions, where the stage answers regarding low-level isolated events have to be connected to the incident answers about the overall incident causes and effects at the social level.

Insider Threat from Sabotage

A CERT survey [START_REF] Cappelli | Common Sense Guide to Prevention and Detection of Insider Threats, Version 3.1[END_REF] has identified that disgruntled employees cause a significant proportion of sabotage after they are terminated. Tables 2 and3 show some of the possible incidents of sabotage by a disgruntled employee. For example, the perpetrator's actions could be tricking a colleague (social ultimate how) into giving out his/her password (social stage how), which allows the colleague's account to be misused (logical ultimate how) to damage the file system (logical stage how) so that data is lost and services cannot be provided (logical stage what).

The main points of the proposed digital forensic investigative framework are:

The progressive nature of stages from system access to target use to incident outcome.

The ultimate effects of an incident are social, but the stage actions are performed at lower levels. This requires an adequate amount of reliable evidence to prove the connection between the actions and the perpetrator.

Different stage actors have different motivations (e.g., a system administrator and a colleague who has been tricked into giving unauthorized access).

The ultimate objective for the perpetrator may be psychological, but tangible damage is caused to the victim, showing the need for separate analysis of the effects on both parties and the relationship between them. Indirect evidence can be collected at different locations, levels or stages, occupying different cells in a table from the causative action.

The lower logical and physical levels may not be directly used by the perpetrator, but are important in investigating when the higher-level primary evidence was destroyed.

Investigative Process

The utility of many incident models to digital forensics is unclear because they do not elucidate the possible evidence available to an investigator after the event, nor do they map incident data to the investigative goals. The proposed investigative framework considers incidents within a wider context and from multiple perspectives to facilitate broader and deeper investigations. The focus extends beyond computer misuse to the wider social, organizational, legal and physical contexts.

Key advantages of the framework include the clarification of the spatial and temporal scope of the different investigative stages, the iteration of and feedback between stages, and the introduction of an additional stage involving remedial actions to improve the investigative process.

The proposed investigative framework also provides a metamodel for representing other digital forensic frameworks [START_REF] Beebe | A hierarchical, objectives-based framework for the digital investigations process[END_REF][START_REF] Carrier | Getting physical with the digital investigation process[END_REF][START_REF] Carrier | An event-based digital forensic investigation framework[END_REF][START_REF] Palmer | A Road Map for Digital Forensic Research[END_REF][START_REF] Pollitt | Computer forensics: An approach to evidence in cyberspace[END_REF][START_REF] Reith | An examination of digital forensic models[END_REF]. As an example, the mapping by Selamat, et al. [START_REF] Selamat | Mapping process of digital forensic investigation framework[END_REF] has five stages of incident investigation: preparation, collection and preservation, examination and analysis, presentation and reporting, and dissemination. The proposed incident model has three main active stages of access, use and outcome that map to the middle three stages of the model of Selamat and colleagues when considered from the point of view of the investigator. The incident access stage obtains greater system and resource control for the perpetrator, whereas the investigator's collection and preservation phase discovers and controls the evidence. The incident use stage performs activities on or with the target resource, analogous to the investigator's examination of the collected evidence. The incident outcome stage corresponds to the presenting and reporting stage. The incident may also have a preparatory stage that reconnoiters the target, which maps to the investigation preparation stage. Also, there are often further actions after the active incident (e.g., use or sale of the targeted resource) that correspond to the final investigation dissemination stage. Therefore, the investigative framework becomes similar to Selamat and colleagues' approach, when the investigative process is modeled analogously to incident progression.

The proposed dual investigative process is nearly symmetrical to the incident progression in terms of its structure. However, it is important to take into account the incomplete and possibly incorrect information available to the investigator, because of the discrepancy between the observation of offensive events and the information that is available later for their detection and remediation. Provision must also be made for secondary observations and inferences about past events when the primary evidence has been destroyed or has not been collected.

The investigative process is connected to incident events using an adaptation of the scientific method involving observation, hypothesis, decision and action [START_REF] Mccomas | The principal elements of the nature of science: Dispelling the myths in the nature of science[END_REF]. In the scientific method, the prediction of physical events is based on the fundamental assumption of the uniformity and pervasiveness of the laws of nature. The physical world is not malicious and does not deceive observers with fake measurements. However, the perpetrator could have altered the appearance of events so that they are undetectable, appear normal or have legitimate causes. These activities may be determined by secondary evidence from side effects of the incident or via system monitoring activities such as analyzing audit logs. It is important to note that any system that has been penetrated cannot be trusted. Unfortunately, dealing with this problem in a comprehensive manner appears to be intractable at this time.

Conclusions

The digital forensic investigative framework presented in this paper organizes incidents into the social, logical and physical levels, and applies Zachman's six investigative questions to the incident and its stages. The framework allows incident progression to be analyzed more completely and accurately to meet the investigative goals of recovery and accountability. The application of the framework to an insider threat case study demonstrates how information about incident events can be transformed into evidence at the social level using sound investigative processes.

Figure 2 .

 2 Figure 2. Duality of thoughts and actions in the investigative process.

Table 1 .

 1 Zachman framework.

		Why	How	What	Who	Where	When
	Contextual Goal	Process	Material	Org. unit	Geog.	Event
		list	list	list	and role	location	list
					list	list
	Conceptual Goal rela-	Process	ER model Org. unit	Location	Event
		tionship	model		and role	model	model
					model
	Logical	Rule	Process	Data	Role	Location	Event
		diagram	diagram	model	diagram	diagram	diagram
				diagram
	Physical	Rule	Process	Data	Role	Location	Event
		spec.	functional	entity	spec.	spec.	spec.
			spec.	spec.
	Detailed	Rule	Process	Data	Role	Location	Event
		details	details	details	details	details	details

Table 2 .

 2 Investigative framework for sabotage incidents by disgruntled employees.

	Incident	Perpetrator Method	Ultimate	Incident	Ultimate
	Entity			Effect	Objectives Target
	Investig.	Ultimate	Ultimate	Ultimate	Ultimate	Ultimate
	Questions Who	How	What	Why	Where
	Social	Disgruntled	Social	Revenue	Revenge	Employee's
	Level	employee	engineering;	loss;		organization
			Existing or	Customer
			illegal access	loss

Table 3 .

 3 Stage aspects for sabotage incidents by disgruntled employees.

	Stage	Actor or	Reason	Action	Target	Unauth.
	Entity	Agent				Result
	Investig.	Stage	Stage	Stage	Stage	Stage
	Questions Who	Why	How	Where	What
	Social	Perpetrator;	Persuade	Persuade,	Security	Increase
	Level	Employee	others to act;	trick, bribe,	guard;	access; Em-
		acting for	Avoid res-	threaten;	System ad-	ployee action
		perpetrator	ponsibility;	Exploit	ministrator;	on behalf of
			Gain access	trust	Colleague	perpetrator
			to resource
	Logical	Own account;	Gain privi-	Illegal	Business	Damage sys-
	Level	Compromised	leged access	access;	process; Ac-	tem integrity;
		account;	to interfere	Exploit	count data;	Deny re-
		Malware	with systems	weakness;	Application	sources and
			and avoid ac-	Install	program;	services
			countability	malware;	Operating
				Misuse	system;
				privilege	Computer;
					Network
	Physical	Physical per-	Gain phys-	Trick guard,	People;	Personal
	Level	petrator; Ma-	ical access to	steal or	Computer;	injury; Com-
		nipulated	facilities,	borrow	Network;	puter, net-
		employee	equipment,	keys; Theft;	Data;	work or data
			computers	Damage or	Equipment	theft or
			for theft or	destroy		damage
			to cause	equipment
			damage


Asadul Islam

Malcolm Corney

George Mohay

Andrew Clark

Shane Bracher

Tobias Raub

Ulrich Flegel

Chapter 11 DETECTING COLLUSIVE FRAUD IN ENTERPRISE RESOURCE PLANNING SYSTEMS

Keywords: Fraud detection, collusion, enterprise resource planning systems

As technology advances, fraud is becoming increasingly complicated and difficult to detect, especially when individuals collude. Surveys show that the median loss from collusive fraud is much greater than fraud perpetrated by individuals. Despite its prevalence and potentially devastating effects, internal auditors often fail to consider collusion in their fraud assessment and detection efforts. This paper describes a system designed to detect collusive fraud in enterprise resource planning (ERP) systems. The fraud detection system aggregates ERP, phone and email logs to detect collusive fraud enabled via phone and email communications. The performance of the system is evaluated by applying it to the detection of six fraudulent scenarios involving collusion.

Introduction

A 2010 survey conducted by the Association of Certified Fraud Examiners (ACFE) indicated that the annual median loss per company (in the Oceania region) from fraud exceeded $600,000 [START_REF]Report to the Nation on Occupational Fraud and Abuse[END_REF]. A typical organization loses 5% of its annual revenue to fraud and abuse. Fraud is more complicated and increasingly difficult to detect when mid-and uppermanagement, who are capable of concealing fraudulent activities, collude [START_REF] Wells | Corporate Fraud Handbook: Prevention and Detection[END_REF]. The 2006 ACFE national fraud survey [START_REF]ACFE Report to the Nation on Occupational Fraud and Abuse[END_REF] notes that, while 60.3% of fraud cases involved a single perpetrator, the median loss increased from $100,000 for single-perpetrator fraud to $485,000 when multiple perpetrators colluded. It is relatively easy to identify individual fraud-ulent transactions. However, fraud involving a combination of multiple legitimate transactions is extremely difficult to detect [START_REF] Coderre | Computer Aided Fraud Prevention and Detection: A Step by Step Guide[END_REF].

Enterprise resource planning (ERP) systems help prevent fraud by applying policy and internal controls. However, the effectiveness of controls is limited because they generally do not detect multi-transaction fraud. Also, controls that implement segregation of duties are often disabled in enterprises that have insufficient staff.

We have developed a system for detecting patterns of individual user fraudulent activity called "fraud scenarios" [START_REF] Islam | Fraud detection in ERP systems using scenario matching[END_REF]. Fraud scenarios are a set of user activities that indicate the possible occurrence of fraud. Fraud scenarios parallel computer intrusion scenarios, and the fraud detection system operates in a similar manner to a signature-based intrusion detection system. However, fraud scenarios differ from intrusion scenarios in that they focus on high-level user transactions on financial data rather than computer system states and events. There is a correspondingly greater degree of system independence in fraud detection, which can be exploited by separating the abstract or semantic aspects of fraud signatures from their configuration aspects [START_REF] Islam | Fraud detection in ERP systems using scenario matching[END_REF]. For this reason, we have designed a language specifically for defining fraud scenarios.

The signature language semantics have been tested using fraud scenarios in ERP systems. The scenarios reflect segregation of duty violations and instances of masquerade. Segregation of duty violations are detected by identifying multiple transactions conducted by a single individual. Masquerade scenarios are detected by identifying multiple transactions carried out by supposedly different individuals from the same terminal.

The fraud detection system performs post facto (non-real-time) analysis and investigation. The detection of a scenario does not confirm that fraud has occurred; rather, it identifies a possible occurrence of fraud that requires further investigation.

The extended fraud detection system described in this paper aggregates ERP, phone and email logs, and analyzes them to identify various forms of potentially collusive communications between individuals. Six scenarios that express possible collusion are considered: Redirected Payment (S01); False Invoice Payment (S02); Misappropriation (S03); Non-Purchase Payment (S04); Anonymous Vendor Payment (S05); and Anonymous Customer Payment (S06).

Related Work

Automated fraud detection significantly reduces the laborious manual aspects of screening and checking processes and transactions in order to control fraud [START_REF] Phua | A comprehensive survey of data mining based fraud detection research[END_REF]. Businesses are highly susceptible to internal fraud perpetrated by their employees. Internal fraud detection concentrates on detecting false financial reporting by management personnel [START_REF] Bell | A decision aid for assessing the likelihood of fraudulent financial reporting[END_REF][START_REF] Fanning | Neural network detection of management fraud using published financial data[END_REF][START_REF] Lin | A fuzzy neural network for assessing the risk of fraudulent financial reporting[END_REF][START_REF] Summers | Fraudulently misstated financial statements and insider trading: An empirical analysis[END_REF] and anomalous transactions by employees [START_REF] Khan | A role mining inspired approach to representing user behavior in ERP systems[END_REF][START_REF] Kim | Design of an artificial immune system as a novel anomaly detector for combating financial fraud in the retail sector[END_REF].

Data mining and statistical approaches are often used to detect suspicious user behavior and anomalies in user activity logs and transaction logs [START_REF] Phua | A comprehensive survey of data mining based fraud detection research[END_REF]. An alternative approach to anomaly detection is a process that creates fraud scenarios and identifies a means to detect each scenario [START_REF] Islam | Fraud detection in ERP systems using scenario matching[END_REF]. Although such signature matching approaches are not widely used in fraud detection, they are commonly used in intrusion detection systems [START_REF] Michel | ADeLe: An attack description language for knowledge-based intrusion detection[END_REF][START_REF] Porras | Penetration state transition analysis: A rule-based intrusion detection approach[END_REF][START_REF] Pouzol | From declarative signatures to misuse IDS[END_REF]. The fraud detection system described in this paper integrates and analyzes accounting transaction logs and user activity logs, and uses signature matching to detect collusive fraud.

Definition and Detection of Fraud Scenarios

A fraud scenario includes a scenario name, description, list of components, attributes and scenario rules. A component is a transaction (extracted from a transaction log) or another previously-defined scenario. Scenario attributes hold the values that define the behavior and characteristics of the scenario, in particular, the "inter-transaction" conditions that capture the essential nature of the fraud.

Scenario rules describe the order and timing of the occurrence of each component as it pertains to the fraud. The rules contain the minimum or maximum time intervals allowed between component occurrences. Each time constraint corresponds to one of three levels: default, scenario or component level. Default values are used by the fraud detection system when values are not specified in a scenario definition. Scenario level values apply over all components while component level values apply between two specific components in a scenario. Component level values override default and scenario level values.

Defining Fraud Scenarios

A scenario definition file (SDF) is an XML file that specifies and stores scenario definitions. For example, the Redirected Payment (S01) scenario shown in Figure 1 describes the behavior of making a payment in such a way that the payment goes to a redirected account instead of the vendor's actual account. The scenario involves making payments to a vendor account after changing the bank account details of the vendor to a different account. After the payment is made, the user changes the bank details back to the original values.

In the case of the Change Vendor Bank scenario, three transaction codes (FK02, FI01 and FI02) may appear in the transaction log. The scenario matches any of these three transaction codes. Similarly, the Pay Vendor scenario matches any of four transaction codes (F-40, F-44, F-48 and F-53) in the transaction log. Change Vendor Bank and Pay Vendor correspond to components. The components match individual transactions or events (not groups or sequences of transactions or events) in the source logs. The signature scenarios for detecting fraudulent activities consist of sequences of multiple transactions/components. This paper uses four fraud scenarios [START_REF] Islam | Fraud detection in ERP systems using scenario matching[END_REF] to describe the process of extending individual fraud scenarios to include collusion. The scenarios are: Redirected Payment (S01), False Invoice Payment (S02), Misappropriation (S03) and Non-Purchase Payment (S04). These scenarios are modified to include additional requirements for detecting communications between colluding individuals.

Defining Collusive Fraud Scenarios

The fraud detection system uses three source logs: ERP system logs, phone logs and email logs. The ERP system logs contain information about the day-to-day activities of users. The phone and email logs maintain information about the communications between users. Note that to preserve privacy, the content of the communications is not analyzed, only that direct communications have occurred between the parties of interest. Other potential sources of information are door logs, office layouts (to identify people working in the same location) and personal relationships.

Figure 2 presents an extension of S01 that includes collusion. The extension involves collaborators contacting each other between steps by phone or email (Phone or Email).

The False Invoice Payment with Collusion (S02 col) scenario involves the creation, approval and payment of a false invoice (Figure 3). The presence of any of the three transaction codes FB60, MIRO or F-43 in the transaction log indicates the creation of an invoice (Create Invoice). The second activity, which involves the approval of an invoice, is indicated by the MRBR transaction code. The third activity, making a payment, uses the already-defined component Pay Vendor from scenario S01. Figure 3 shows the sequence of components that occurs for the same purchase order with a Phone or Email component between them, which indicates communications between colluding users. The Misappropriation with Collusion (S03 col) scenario involves the misappropriation of company funds. The fraud involves the creation of a purchase order and the approval of the purchase. In particular, fraud may exist when a party who has the authority to make a purchase order colludes with another party who has the authority to approve it. Scenario S03 col is the sequence of two components, Create PO and PO Approval, for the same purchase order with a Phone or Email com- The Non-Purchase Payment with Collusion (S04 col) scenario involves the generation of a purchase record in the system and a payment being made without the purchase actually occurring. The fraud may potentially exist when one party creates a purchase order or a goods received transaction, another party creates an invoice on the same purchase order, and communications exist between the two parties. Scenario S04 col is the sequence of the Create PO or Good Receipt and Create Invoice components for the same purchase order with a Phone or Email component between them that indicates collusion.

Detecting Collusive Fraud Scenarios

Figure 4 presents the process for detecting fraud scenarios. The process uses the fraud scenario definitions in the SDF and searches for matches in the aggregated log data. The search process generates an SQL query based on the scenario definition and runs the query against the aggregated data file. Query matches are flagged as possible fraud events.

The first component is the data extraction and aggregation module, which extracts and aggregates log data from different sources. The module is located external to the main detection process to allow for extensibility and accommodate ERP system changes and additional system logs. The current implementation extracts transactions from an SAP R/3 ERP system.

The data profile contains the description of the data file, number of fields, field types, user-defined names for fields, column and line separa-tors, fields to be considered and fields to be ignored. The format and types of the individual fields in the aggregated data file are defined by the user. Several pre-defined data types are provided (e.g., date, time and event), and users can add or modify the list as needed. In the data profile, users can optionally define the information extraction process for each field from a specific position (e.g., a VendorID is a four-digit string in the second position of the fourth field).

The data upload module uploads data from the aggregated data file to a database. The data profile must be defined by the user at the time of upload. The data upload module creates a transaction table according to the data profile and uploads data to the table.

The SDF specifies the known fraud scenarios that are used in searches of the aggregated data file. Users may add new scenarios or edit existing scenarios by changing the data profile and list of data types. Interested readers are referred to [START_REF] Islam | Fraud detection in ERP systems using scenario matching[END_REF] for details about fraud scenario creation and specification.

Experimental Validation

The fraud detection system detects fraudulent activities by matching the scenarios against transactions or events recorded in the database. This section evaluates the ability of the implemented system to detect collusive fraud. The collusive fraud scenarios described involve phone and email communications. Thus, the data extraction module extracts phone and email logs as well as user transaction logs from an ERP system.

An SAP R/3 ERP version 4.0 system served as the source of transaction log data. Fraud detection requires at least three data columns in each transaction record: timestamp, user ID and event. Depending on the scenario, additional fields may be of interest. For example, detecting the Redirected Payment (S01) scenario in the Change Vendor Bank component requires matching the vendor identification number between components.

A major problem in fraud detection research is the lack of real-world data for testing. Additionally, real-world background data is unavailable, which makes it difficult to integrate synthetic fraudulent data with legitimate background data [START_REF] Barse | Synthesizing test data for fraud detection systems[END_REF]. Therefore, our testing used synthetic transaction data that was generated randomly.

The test data comprised 100,000 records corresponding to 100 users and 100 terminals. It was assumed that a user does not always use a specific terminal in order to model masquerade scenarios where users perform activities from multiple terminals or where multiple users perform activities from one terminal. The synthetic data incorporated vendor identification numbers, invoice numbers, purchase order numbers and customer identification numbers. Email and phone call log data were also generated randomly.

Each instance of fraud identified by the system was analyzed to verify its correctness. As a secondary check for each instance, records were added and deleted and the scenario detection process re-executed. This provided a means to verify that adding relevant transactions had the expected effect of producing a match where none existed previously, and that deleting records had the effect of producing no match where one previously existed.

Table 1 lists the numbers of activities or components present in the randomly-generated data. Note that the summation is greater than 100,000 because some transaction codes are present in multiple activities. For example, the Create Vendor activity includes all the transaction codes that indicate the creation of a new vendor and any editing of a vendor record; thus, the transaction codes for the Change Vendor Bank activity are also included in the Create Vendor activity.

The Change Vendor Bank component matches 2,730 records and the Pay Vendor component matches 10,820 records. Testing of the Redirected Payment (S01) scenario (without user collusion) involves locating sequences of Change Vendor Bank, Pay Vendor, Change Vendor Bank for the same vendor when the maximum interval between any two activities is two days and the overall scenario duration is less than three days. The search took 1.2 seconds on a Pentium 4 machine with 2 GB RAM running Microsoft Windows XP Professional. Two matches were identified (Table 2). One record was returned for each match; however, for clarity each match is displayed across three rows. Testing of the Redirected Payment with Collusion (S01 col) scenario yielded four matches in 92 seconds, one of which is shown in Table 3. The results demonstrate that considering collusion reveals additional instances of potential fraud. Table 4 presents the results corresponding to all six scenarios. The time taken by a query for a collusive scenario is greater than that for its non-collusive counterpart. There are two reasons. The first reason is that collusive scenarios involve more data than non-collusive scenarios. Second, queries for collusive scenarios involve cross-field database joins rather than same-field joins in the case of non-collusive scenarios. For example, in a collusive scenario, the query matches conditions between fields in which one individual's user name is matched to another via an email or phone call, and both are matched to vendor or purchase order activity.

Conclusions

Fraudulent activity involving collusion is a significant problem, but one that is often overlooked in fraud detection research. The fraud detection system described in this paper analyzes ERP transaction logs, and email and phone logs of user communications to detect collusion. The system permits the configuration of scenarios, supporting focused analyses that yield detailed results with fewer false positive errors.

Our future research will test the fraud detection system on real SAP system data. In addition, the detection methodology will be extended to enable the system to operate in real time.

Figure 1 .

 1 Figure 1. Redirected Payment (S01).

Figure 2 .Figure 3 .

 23 Figure 2. Redirect Payment with Collusion (S01 col).

Figure 4 .

 4 Figure 4. Detection process.

Table 1 .

 1 Activities in randomly-generated data.

	Scenario	Matches
	Change Vendor Bank	2,730
	PO Approval	5,140
	Pay Vendor	10,820
	Good Receipt	15,570
	Create Invoice	5,280
	Create Vendor	21,510
	Invoice Approval (MRBR)	2,430
	Create Customer	4,830
	Create PO	13,190
	Credit to Customer	5,260
	Phone or Mail	15,970

Table 2 .

 2 Results for the S01 scenario.

	Time	Trans. User Term. Vendor Invoice	P.O.
	10:17:53	FK02	U010	T04	V00020
	11:32:17	F-53	U010	T05	V00020	I00024	P00000010
	13:02:48	FK02	U010	T10	V00020
	01:03:34	FK02	U009	T02	V00001
	02:28:50	F-53	U009	T06	V00001	I00017	P00000004
	02:58:40	FK02	U009	T03	V00001

Table 3 .

 3 Results for the S01 col scenario.

	Time Trans.	User Term. Recip. Vendor Invoice	P.O.
	09:57:55 FK02	U007	T04	V00006
	10:59:44 PhoneTo U007	T09	U002
	11:39:39 F-48	U002	T06	V00006	I00039 P00000013
	12:15:07 MailTo	U002	T10	U007
	13:00:22 FK02	U007	T03	V00006

Table 4 .

 4 Results for all six scenarios.

		Without Collusion With Collusion
	Scenario	Matches	Time	Matches Time
	Redirected Payment (S01)	2	1.2s	4	92s
	False Invoice Payment (S02)	15	1.1s	5	18s
	Misappropriation (S03)	5	0.8s	6	17s
	Non-Purchase Payment (S04)	27	2.3s	9	5.6s
	Anonymous Vendor Payment (S05)	42	1.3s	21	3.6s
	Anonymous Customer Payment (S06)	0	0.3s	2	2.7s

Acknowledgements

This research was supported by the Australian Research Council and by SAP Research.