To improve the efficiency of a forensic acquisition, you can optimally tune the examiner host and assess the bottlenecks.
A performance bottleneck always occurs; this is simply the slowest component in the system, which all other components must wait for. In a forensic setting, the bottleneck should ideally be the subject disk. This is the evidence source and is the only performance variable that you can’t (or shouldn’t) modify.
You can assess the performance of various system components by read-ing the vendor specifications, queryread-ing the system with various tools, or run-ning various benchmarking and measurement tests.
Useful tools to check the speed of various components include dmidecode, lshw, hdparm, and lsusb. Several command line examples are shown here.
To check the CPU family and model, current and maximum speed, number of cores and threads, and other flags and characteristics, use this command:
# dmidecode -t processor
Here is a command to view the CPU’s cache (L1, L2, and L3):
# dmidecode -t cache
To view the memory, including slots used, size, data width, speed, and other details, use this command:
# dmidecode -t memory
Here is a command to view the number of PCI slots, usage, designation, and type:
# dmidecode -t slot
A command to view the storage interfaces, type (SATA, NVME, SCSI, and so on), and speed:
# lshw -class storage
To view the speed, interface, cache, rotation, and other information about the attached disks (using device /dev/sda in this example), use this:
# hdparm -I /dev/sda
To view the speed of the external USB interfaces (and possibly an attached write blocker), use this command:
# lsusb -v
NOTE There are many different methods and commands to get this information. The com-mands shown here each present one example of getting the desired performance infor-mation. Providing an exhaustive list of all possible tools and techniques is beyond the scope of this book.
Reading the vendor documentation and querying a system will identify the speeds of various components. To get an accurate measurement, it’s best to use tools for hardware benchmarking and software profiling. Some tools for benchmarking include mbw for memory and bonnie++ for disk I/O.
The health and tuning of the OS is also a performance factor. Monitor-ing the logs (syslog, dmesg) of the examiner hardware can reveal error mes-sages, misconfiguration, and other inefficiency indicators. Tools to monitor the performance and load of the live state of an examiner machine include htop, iostat, vmstat, free, or nmon.
You can also optimize the OS by ensuring minimal processes are run-ning in the background (including scheduled processes via cron), turun-ning the kernel (sysctl -a), tuning the examiner host’s filesystems (tunefs), and managing disk swap and caching. In addition, ensure that the examiner OS is running on native hardware, not as a virtual machine.
When you’re looking for bottlenecks or optimizing, it’s helpful to imag-ine the flow of data from the subject disk to the examimag-iner host’s disk. Dur-ing an acquisition, the data flows through the followDur-ing hardware interfaces and components:
• Subject disk platters/media (rotation speed? latency?)
• Subject disk interface (SATA-X?)
• Write blocker logic (added latency?)
• Write blocker examiner host interface (USB3 with UASP?)
• Examiner host interface (USB3 sharing a bus with other devices?
bridged?)
• PCI bus (PCI Express? speed?)
• CPU/memory and OS kernel (speed? DMA? data width?)
These components will be traversed twice, once between the subject disk and the examiner host, and again between the host and the examiner disk where the acquired image is being saved.
Ensure that the data flow between the subject disk and the CPU/memory is not using the same path as for the data flow between the CPU/memory and the destination disk on the examiner host. For example, if a field imag-ing system has a write blocker and an external disk for the acquired image, and both are connected to local USB ports, it is possible they’re sharing a single bus. As a result, the available bandwidth will be split between the two disks, causing suboptimal performance.
For network performance tuning, the speed of the underlying network becomes a primary factor, and performance enhancements include the use of jumbo Ethernet frames and TCP checksum offloading with a high-performance network interface card. It is also beneficial to assess when var-ious programs are accessing the network and for what reason (automatic updates, network backups, and so on).
To summarize, have an overall plan or strategy for the acquisition actions you intend to take. Have well-tested processes and infrastructure in place. Ensure that the right capacity planning and optimizing has been done. Be able to monitor the activity while it’s in progress.
The most common bus speeds relevant for a forensic examination host (in bytes/second) are listed in Table 4-1 for comparison. You’ll find a good reference of the bit rates for various interfaces and buses at https:// en.wikipedia.org/ wiki/ List_of_device_bit_rates.
Table 4-1:Common Bus/Interface Speeds
Bus/interface Speed
Internal buses
PCI Express 3.0 x16 15750 MB/s PCI Express 3.0 x8 7880 MB/s PCI Express 3.0 x4 3934 MB/s
PCI 64-bit/133MHz 1067 MB/s
During a forensic disk acquisition, every accessible sector on the disk is being read, and the reading of the disk is sustained and uninterrupted, often for many hours. As a result, disk operating temperatures can increase and cause issues. When disks become too hot, the risk of failure increases, especially with older disks. Researchers at Google have produced an infor-mative paper on hard disk failure at http:// research.google.com/ archive/ disk_
failures.pdf .
To reduce the risk of read errors, bad blocks, or total disk failure, it’s worthwhile to monitor the disk temperature while a disk is being acquired.
Most disk vendors publish the normal operating temperatures for their drives, including the maximum acceptable operating temperature.
You can also use several tools to manually query the temperature of a drive. A simple tool that queries the SMART interface for a drive’s tempera-ture is hddtemp, as shown here:
# hddtemp /dev/sdb
/dev/sdb: SAMSUNG HD160JJ: 46C
The hddtemp tool can be run as a daemon and periodically log to sys-log, where you can monitor it for certain thresholds.
For more detailed output on a disk’s temperature, and in some cases a temperature history, use the smartctl tool. Here is an example:
# smartctl -x /dev/sdb ...