Procedures

Procedures will vary to some extent based on the IT environment, the type of case, the status of the system at the time the examiner confronts it (is it live

and functioning, on a network, or is it shutdown) and what resources they have to safely acquire and analyze the evidence. Procedures will also be dictated to some extent by what evidence is actually being sought and the context surrounding it. Due to the amount of information that is contained on a modern disk drive, the more information the computer forensic examiner has about the context of the case, the easier it is to provide the analysis in a timely manner.

A computer forensic examiner should seek to obtain the following information prior to conducting the analysis:

1. What is suspected or needs to be proven?;

2. Any specific information about times and dates to support time-line analysis of activities;

3. Any specific keywords and text strings;

4. Access to any other supporting computer evidence already in possession of the investigator to support evidence correlation, such as proxy logs (logs of Internet browser activity from firewalls and proxy servers), and pen register logs (records of incoming and outgoing phone calls from a suspect’s phone line);

5. A description of the computer skill level of the suspect;

6. If the system is used for business rather than a personal computer, as detailed a description as is available about the network environment in which the system was located and what the system’s primary function was.

Searching without this information can be like looking for a needle in a haystack.

Live System Processing

Many computer forensic examiners are used to dealing only with static magnetic media (hard drives and floppy disks) from a computer system that has been seized in a shut down state. Intrusion forensics (a focus of Chapter 6) conducted on a live, compromised system in a computer security incident response scenario is much more demanding of the forensic examiner. Many transitory system events occurring on the system, such as which network connections are open and what processes are running, may constitute critical evidence about the compromise that needs to be appropriately preserved and acquired. Every forensic examiner should

therefore have an understanding of the protocols for safely acquiring volatile data from live systems, not just analyzing static file system structures from magnetic media.

Any system being examined live should be considered to behostileuntil proven otherwise. There are circumstances that need to be considered in these cases such as the ‘‘continued presence of [the] intruder on the system, possible ‘booby traps’, impact of system compromise on continued operations [and] involvement of law enforcement’’ [14].

Data acquisition in these cases requires that processes followed need to address the order of volatility of information resident on a system. The order of volatility for system events, and therefore the order in which they need to be acquired during forensic processing, is as follows:

1. Registers, peripheral memory, caches; 2. Memory (virtual, physical);

3. Network state;

4. Running processes, open files, media mount points; 5. Logical file system;

6. Physical hard drive, floppies and backup tapes; 7. CD-ROMs and printouts [14].

It should be noted in all cases that protection of the system, and therefore evidence, is paramount so the computer forensic examiner should always err on the side of caution if anything appears to be amiss. That is, always have the power plug nearby just in case you need to pull it because the disk drive light starts whirring unexpectedly.

Prior to carrying out forensic examinations, the following should be considered:

w _{On live systems avoid tools that use a graphical user interface.Command-} line utilities, and in particular, statically linked binary files, are best utilized as they are more likely to leave little or no footprint on the evidence system if they are properly utilized. Command line tools are also much easier to use if you have run your own known, trusted command shell.

w _{Validate your tools. Only utilize tools from trusted sources and} personally verify their actions and that they work as advertized. This supports not only the evidence acquired during the examination

of the system but also supports your credibility, should you be called upon in court to validate the processes followed and tools used. Generate checksums for all of the tools and store the list of checksums with the toolkit.

w _{Keep copies of the tools on removable media. Create a CD-ROM or a} number of floppy disks that contain the trusted operating system kernel(s) and the data acquisition tools. Write-protect the media as necessary.

w _{Document, document, document.Documentation of exactly what is done} and when it is done during every facet of an investigation cannot be overemphasized. Testimony may take place as much as a year or more later and the more comprehensive your notes, the easier it is to provide accurate and less refutable testimony.

The following evidence processing guidelines should not be considered to be definitive, proscriptive process but as the best practice. The process has been derived from the U.S. Secret ServiceBest Practices for Seizing Electronic Evidence[21], New Technologies Inc.Computer Evidence Processing Steps[22], IACIS1Forensic Examination Procedures[17], RFC 3227Guidelines for Evidence Collecting and Archiving [23], and Foundstone’s forensically sound initial response processes [24]. The guidelines implement the three phases of the CFSAP model (secure, analyze, present) with each phase comprising several steps.

3.5.1.1 Securing evidence

1. Establishing forensically sterile conditions:All media utilized during the data acquisition and analysis process are to be freshly prepared, completely wiped of nonessential data using an appropriate sanitization program, scanned for viruses and verified before use. 2. Following a complete, documented, logical process in acquiring evidence

from the system: While each forensic case is unique, all examiners should develop documented SOPs and follow them. SOPs help ensure consistency in the manner that all data collected is preserved, acquired, analyzed, and presented. Documentation should describe exactly what was observed on the system when it was examined, what actions were carried out and at what time. Litigation may be a lengthy process and accurately describing the situation will be difficult if appropriate notes are not kept. Accurate

documentation differentiates a professional, scientific approach to an examination from an ad hoc, unprofessional one. Such documentation should include photographs and video where possible.

3. Using a known trusted command shell and tools for acquiring data from a system: The operating system and applications on a machine potentially containing evidence should never be trusted. Informa- tion gathered in the examination cannot be trusted if the tools cannot be trusted. The computer forensic examiner, should, if possible, carry out all actions using a known, trusted kernel and applications that he/she can be sure has not been compromised or modified. Except in dire circumstances where no other option is available, no information from the examination should be written to the system being examined. Where this does occur, accurate notes of the actions required and the reasons for them should be kept to justify any alterations made to the system. The objective is to preserve the state of the system as far as possible at the time the acquisition and examination take place.

4. Data acquisition—volatiles: Where appropriate, acquire evidence using the order of volatility listed earlier to ensure that resulting output is written to the sanitized media previously prepared. Prosise and Mandia [24], and Romig [14] describe in-depth acquisition processes for volatile data in Microsoft Windows–based and UNIX environments.

5. Copying system files for analysis:In system compromise cases, it may be necessary to copy system log files or binaries for further analysis. Where this is necessary, the copy process should be authenticated. All efforts must be made to ensure that these processes are as noninvasive as possible.

6. Logical volume imaging on live systems:In some cases, it may not be possible to shutdown a system in order to image it. This may particularly be the case with business systems where the system is critical to the functioning of the company, and/or the system is a server running a redundant array of inexpensive disks (RAID) array where multiple physical disks appear as one logical volume. In these cases, the most reasonable option is probably to carry out a logical image of the volume either to plug-and-play removable storage media, such as a tape drive or over a network connection to another system. More and more systems like these will be encountered, so

the computer forensic examiner must have procedures developed, should this scenario be encountered. Another circumstance where logical volume imaging may be employed is where a cryptographi- cally secured filesystem is encountered on a live system. Unless keys and passwords are provided then the encrypted data may be irretrievable once the system is shutdown. The alternative here is to logically image the encrypted filesystem while it is open to ensure that no potential evidence is lost or later unavailable.

7. Shutting down the computer: There is much discussion about whether or not to carry out a normal system shutdown due to flushing of caches, overwriting of swap files and such. The determination of whether a system should be normally shutdown or a hard shutdown with power removed will be a case dependent judgment call for the examiner at the time. If it appears all appropriate volatile information has been acquired, and if there are no booby traps or malicious programs apparent, the system should be shut down to allow imaging of the hard disk drives and seizure of the system. The system should be observed closely during this process with the ability to ‘‘pull the plug’’ on system power in case of emergency. 8. Documenting the hardware configuration of the system: This step should

take place on site if the system is not being seized, so that an accurate record of the system hardware configuration, BIOS settings including boot order, and drive translation settings are maintained. Serial numbers for all components should be noted before any removal of the hard drive or the system itself. Where possible, photographs or video should be taken of the systems surrounding environment, cabling, and configuration. Network environmental information, if appropriate, should describe network type, topology, and relevant physical or media access control (MAC) addresses. Reviewing the BIOS configuration of a hard drive and comparing it to the manufacturer’s physical parameter details listed on the label is important to ensure that no concealed data areas are being maintained on the disk through BIOS manipulation.

9. Documenting the system date and time:Time is one of the single most important attributes used in computer forensics. Establishing the dates and times associated with the modification, access, and creation (commonly referred to as MACtimes) of computer files is extremely important in reconstructing the sequence of events on a system. The accuracy of the dates and times may be critically

important and the system BIOS date and time settings and its variation from the true date and time need to be accurately recorded at the time the computer is seized or examined.

10. Continuity of evidence (chain of custody): If the computer is being seized, it should not be left unattended unless it can be secured from unauthorized access. For transport, it should also be appropriately protected with bubble-wrap or other protective packaging. In vehicles, computer evidence should be kept as far away as possible from magnetic fields caused by stereo speakers and two-way radio equipment.

It is a common practice in some circumstances to seize only the hard drive and if this is the case it should be protected using an antistatic bag and appropriate padded packaging for transport.

In all cases documentation should be prepared which has an adequate description of the item including any serial numbers, the sequence of handling and control of the hardware until any potential legal proceedings are finalized. All potential and actual evidence should be secured in a limited access filing cabinet or locker with one person identified as the custodian controlling access to it. Any time access is made to the evidence, it should be appropriately noted with time, date, person, reason, and a signature.

11. Data acquisition—magnetic media:Noninvasive sector image backups should be made of all hard disk drives and floppy disks. Where possible, a hardware write blocking system, such as Intelligent Computer Solutions Inc.’s Drive Lock [25] or Digital Intelligence Inc’sFireChief[26] should be used to ensure no inadvertent writes are made to the evidence drive. Drive Lock, shown in Figure 3.2, is commercially available and employs an IDE-to-IDE interface unlike other tools which employ IDE-to-SCSI or IDE-to-IEEE 1394

Figure 3.2 Drive Lock. (Reprinted with permission, 2002.)

controller translation. Where this type of hardware is not available, a controlled boot disk specially modified to ensure the operating system on the disk makes no probes to drives attached to the system, should be used [24].

12. Authentication of copied and imaged media:If the imaging utilities used to make the bit stream backup do not do so automatically, manual authentication of the imaging should be carried out to validate the duplication process. Tools used should employ an accepted one-way hash function—see Chapter 2 (OWHF) algorithm over 128 bits, such as MD5 or SHA-1.

13. Malicious code protection: All reasonable precautions must be taken during any copying or imaging process to ensure that there is adequate protection from malicious code including viruses, destruc- tive programs or other programs that could potentially corrupt or compromise the original evidence media.

14. Archiving media images: Once imaging has been completed, two archive copies, a master copy and a working copy should be made to preserve the image files before analysis. As with all other copying and imaging processes, the archive copies are compared to the original image files to ensure the integrity of the archive process. All analysis should then be conducted on the working copy of the image rather than on the original, seized media or the master copy.

3.5.1.2 Analyzing secured data

1. Logical analysis of the media structure:An examination of the volumes, partitions, and file systems located on the image is conducted to identify the data structure of the original media. The characteristics and configuration should be noted in detail.

2. Operating system configuration information: Details from the boot record and information on the operating system configuration, user- defined system configuration such asCONFIG.SYS, AUTOEXEC.BAT, WIN.INI, SYSTEM.INI, and registry are examined and findings are noted.

3. Document file names, dates, and times:From an evidence standpoint, file names, ownership, and MACtimes can be extremely important [27]. Therefore, it is important to fully catalog all active and deleted files. Some forensic analysis programs, such as Access Data’sForensic

Toolkit (FTK), will do this automatically and allow export of the results into a spreadsheet [28].

4. File signature recognition:Many systems these days have upwards of 20,000 active files located on them so any technique that reduces the amount of data needed to be examined is very useful. Comparative analysis of existing operating system and application files using signatures generated by OWHFs can significantly reduce the number of active files that need further examination. Some forensic analysis tools such as Guidance Software’s EnCase (see Chapter 2) and FTK, can do this automatically as file signatures are prepared as part of the evidence processing.

Tools such as theHashkeeperdatabase [29] discussed later and the National Software Reference Library [30] discussed later and in Chapter 2 can also assist the computer forensic examiner by providing specialized signature databases to identify child porno- graphy images and hacking related software.

5. Identifying file content and type anomalies: Some file types including encrypted, compressed, and graphic files may be stored in a binary format that a standard string/text search program will not search. Suspects may also purposely alter file extensions or employ steganographic techniques to conceal incriminating information. Evaluation of the file headers, the leading bytes of a file, may also identify files with inappropriate file extensions.

6. Evaluating program functionality: Depending on the application software involved, running captured programs to learn their purpose may be necessary. Appropriate backup and isolation measures should be employed to ensure disconnection of the system from a network to prevent potential dissemination of malicious software. Use of an operating system emulator such as VMWarefrom VMWare Inc. can allow safe analysis of the suspect software. For programs of uncertain function, employment of debugging programs that intercept system calls, and decompilation programs, which extract the original high level programming code from executable binary code, may be required.

7. Text string and key word searching: Normally an investigation will require some searching for the presence of information in a textual form and there are many tools available to assist in the search for text-based evidence. Prior to conducting this search, the informa- tion described previously should be collected to assist the analysis

process. FTK, a forensic analysis suite, incorporates a complete text indexing capability that allows almost instantaneous searches for most text strings [28].

8. Evaluating virtual memory:Virtual memory, in the case of Windows, the swap or page file, and in the case of UNIX, the swap partition, is a potential source of evidence and investigative information. Some forensic analysis tools, such as FTK, automatically extract swap file information and process it for textual information in the same manner as any other file.

9. Evaluating ambient data: Ambient data (file slack and unallocated space) is described in Chapter 2. Forensic acquisition and analysis tools can extract deleted files and relevant fragments from these areas on disk to support the investigation process. Deleted files may be particularly important and MACtime attributes should be obtained for recovered files to support the time-line analysis (Section 3.5.2.3).

3.5.1.3 Presenting the results of analysis

1. Document, document, document: The importance of comprehensive and accurate documentation cannot be stressed enough. As indicated previously, documentation should be contemporaneous, that is, notes should be taken at the time, not prepared from memory, hours or days later. Documentation should include chain of custodial information, dates, times, forensic software details including version numbers and details of evidence located. Some forensic analysis tools also maintain detailed electronic reports in HTML or document format and these should be treated as the same as other forms of digital evidence and secured appropriately. Documentation should be printed and physically signed where