Digital Evidence Handling
Last updated
Last updated
Principles by EU-OLAF recommendation.
The actions triggered by the first responders should not alter the data maintained on a computer or in a storage device that may be submitted to a court as evidence;
In exceptional circumstances, if it is considered necessary to access the original data stored on a computer or in a storage device, those who do so must have skills to be able to provide evidence, explaining the relevance and implications of his actions;
A chain of custody, or other record of all processes applied to digital evidence must be created and preserved. An independent third party should be able to examine these processes and obtain the same result;
The person responsible for the investigation must assume overall responsibility for compliance with the law and the present principles.
Data states
stored – data permanently stored in a storage device, e. g. an hard drive;
in transit – data being sent through a local network, or Internet, to a reception device;
in reception – data being received in a device, but not yet available to the user;
in creation – data being locally produced and only partially available to the user;
Data sources
storage devices – hard drives, SSD, USB drive, tapes, ...
temporary location – RAM, page files, swap partitions, cache files, ...
peripheral devices – printers, plotters, memory card readers, ...
active network devices – switches, routers, modems, print servers, ...
Logical and physical location of the data
local or remote devices.
dedicated storage systems (usually on data centers).
computational systems (e. g. PC, laptop) has at least one storage device.
Main data types
simple and human readable, e. g. photos, text documents, spread sheets.
complex and/or structured data, e. g. data bases, file system.
raw data, streams of data.
Do not modify any data that could have been evidence.
Copy important data, put the original in a safe place, and analyze the copy so that you can restore the original if the data is modified;
Calculate hash values of important data so that you can later prove that the data has not changed – better yet if you do a digital signature;
Use a write-blocking device during procedures that could write to the suspect data;
Minimize the number of files created during a live analysis because they could overwrite evidence in unallocated space;
Be careful when opening files on a live analysis because you could be modifying data, such as the last access time;
Order of volatility:
CPU, cache, and register content;
routing table, ARP cache, process table, kernel statistics.
RAM.
temporary file system, swap space.
data on local storage media.
remotely logged data.
data contained on archival media (backups).
Some times it is not possible to bring all devices due to several constrains: legal, time, technically unfeasible, ...
In those situations a pre-analysis is required, but can only be performed if authorized accordingly to the country’s laws.
Isolate yourself from the suspect data because you do not know what it might do.
an executable from the suspect system could delete all files on your computer, or it could communicate with a remote system;
opening an HTML file from the suspect system could cause your Web browser to execute scripts and download files from a remote server;
Create an isolated environment.
use virtual machines (VMware, VirtualBox, Xen, . . . ).
use an analysis network that is not connected to the outside world, or that is connected using a firewall that allows only limited connectivity.
isolation is very difficult, or impossible, with live analysis.
Correlate data with other independent sources.
helps reduce the risk of forged data.
timestamps can be easily changed in most systems.
find log entries, network traffic, or other events that can confirm the file activity times.
This task is time consuming, specially if done without the help of software.
Log and document all of your actions.
helps identify what you have already done and what your results.
helps identify what searches you have not done yet.
in a live analysis, or performing techniques that will modify data, it is important to document what you do so that you can later document what changes in the system were made because of your actions.
Create tags to uniquely identify devices e. g. PC01, PC01.1, PC01.2, ...
Take photographs.
After placing tags.
Should be easy to read any relevant information, if needed take an overview photo and then a close up shot.
Computer brand, model, serial number, ...
Network cable connections, etc
Create templates with the required info to identify devices and services.
Verify the list of devices delivered for analysis.
Tag the devices, taking into account that one process may have:
one suspect with several devices,
or several suspects and many devices.
There are processes with 30+ suspects and 200+ devices.
Letters to identify the owners of the devices in a given process.
A, B, C, ...
Set of acronyms for each device type, followed by a 2 digits number.
FPHxx, SPHxx, SIMxx, MCxx, GPSxx, CAMxx, PCxx, LAPxx, HDDxx, SSDxx, PENxx, ...
A tag is composed by
ownerID.deviceID[.inside deviceID]
Example of a smartphone with 2 SIM cards and a memory card:
A.SPH01 - the handset from the owner A
A.SPH01.SIM01 - first SIM card.
A.SPH01.SIM02 - second SIM card.
A.SPH01.MC01 - memory card.
Include the scale of a ruler in the photo.
photograph all the important views.
there are mandatory views by device type and some optional attention to details, like serial numbers, IMEI, etc.
Apply the view names accordingly to the 3D box.
The position of the device is important for some devices that might be ambiguous such is the front, e.g. SIM card.
Photos filenames: tagID-view name[-detail].jpg examples:
A.SPH01-front.jpg,
A.SPH01-back-serial.jpg,
A.SPH01.MC01-front.jpg,
tag ID device type
brand and model number
serial number, IMEI, UICCID, ...
type of intervention (logical or physical acquisition)
device’s condition (working/ non-working)
contents, e. g. has SIM or memory card
worthy observations
etc
