This chapter is from the book
This chapter is from the book
This chapter is from the book
The Art of Documentation
Any individual who lacks organizational skills or who finds it difficult to keep accurate notes as he works is not a likely candidate for the position of digital investigator. The vast majority of work the investigator does is documentation. There are five levels of documentation that must be either maintained or created during the course of each case study:
- General case documentation
- Procedural documentation
- Process documentation
- Case timeline
- Evidence chain of custody
Every one of these is important to winning a case should it make its way to court. Faulty, incomplete, or missing documentation can destroy an otherwise meticulously prepared case. In addition to these items, there is also the final report, but that will be covered elsewhere in this book.
The Craft of Project Management
While this book is not intended to be a treatise on what makes a good project manager, it should be pointed out that good project management practices can facilitate the smooth completion of an investigation from beginning to end. Virtually all of the principles defined in the Project Management Institute’s (PMI) Project Management Book of Knowledge (PMBOK) apply directly to the investigatory process. Wysocki (2009) defines a project as “a sequence of unique, complex, and connected activities that have one goal or purpose and that must be completed by a specific time, within budget, and according to specification.”
Like all other projects, a digital forensics investigation involves multiple stakeholders and a defined scope, and has specific objectives that must be pursued. Multiple people will be involved, requiring the project leader to manage people’s time, to assure that tasks are assigned to the person most skilling in performing the work involved, and to keep everything in budget and on time.
General Case Documentation
Case documentation begins the moment you are asked to consider investigating an incident. Even if an investigator or agency chooses not to accept a case (assuming that possibility exists), it may later become necessary to explain why the case was turned away. Another thing the investigator needs to keep in mind is that anything recorded during the case is discoverable. To be discoverable means that opposing counsel has the right to examine and analyze data collected during the process. If an investigator takes written notes or uses a digital voice recorder to make verbal observations, copies of the notes and audio files must be made available to the opposition if requested. Therefore, great care should be taken in the creation of documentation.
A number of factors need to be addressed in the basic case documentation:
- What is the name and contact information for the organization involved in the incident? Record every individual contacted during the investigation, that person’s role in the process, and when, where, and how he or she was contacted.
- When was the investigative agency notified, and who initially took the information? Record exact dates and times.
- A description of the incident, both in technical terms and in lay terms.
- When was the incident discovered?
- When did the incident occur? This may be a best-guess scenario.
- Who discovered the incident?
- To whom was the incident reported? This means anyone who learned of it, regardless of rank and file.
- What systems, information, or resources were impacted by the event? This includes hardware, organizational entities, and people.
- Is there any preliminary information that suggests how the offending actions were accomplished?
- What is the impact of the incident on the individual or organization affected? This includes financial impact, impact on the systems involved, and any effect it may have had on the health or mental welfare of individuals involved.
- What actions were taken between discovery of the incident and reporting it to authorities? This means everything that was done, including simple files searches.
- Who are the stakeholders as they are identified?
- As soon as possible, provide a detailed inventory of all hardware (and possibly software) that is involved in the incident. If hardware is seized, provide a separate, itemized list of seized equipment.
- Have all copies of all pertinent documentation, such as warrants, summons, written correspondence, and so forth, been added to the case file?
Any other generic information that does not fit directly into one of the other reporting categories would be included in this section. This would include expense reports, timesheets, and any other general recordkeeping.
Procedural Documentation
During the course of the investigation, a number of tasks will be performed. The history of these tasks should be maintained as painstakingly as possible. The investigator should describe every step taken, the tools used to perform specific tasks, a description of the procedure, and a brief summary of the results. Detailed results can be included in the final report. When describing a technical process, process documentation should be provided whenever possible (as described in the next section).
Anytime the investigator chooses not to follow recommended best practice, it is essential to record the action being taken, what the recommended procedure would normally be, and what actual procedure is being used, and to explain precisely why the deviation is occurring. For the longest time, the best practice when coming upon a running suspect system was to pull the plug. The reasoning was that an orderly shutdown of the system overwrote a lot of data and drastically altered paging files. However, in a live network event that is still transpiring, it may be necessary to collect information from active memory, including current network connections, user connections, and possibly cached passwords. Shutting down the system would kill all that information. The proper course would then be to perform a live analysis and document precisely why the action was taken.
The following is a summary of events and tasks that should be meticulously reported. Some organizations performing investigations on a full-time basis have a template that the investigator follows, filling in the results as tasks are completed.
- Document the condition of the original scene, including a list of hardware found, status (on/off, logged on/logged off, etc.), along with photographs or a video tape.
- Record the names and contact information of all individuals interviewed during the investigations. A summary (or if possible, a transcript) of the interview should be provided as an attachment.
- If equipment is seized, document the make, model, and serial numbers of each device. Provide documentation authorizing the seizure as a separate attachment.
- Record the exact time materials were seized, the location it was taken from, and the name and contact information of the person performing the action.
- If equipment is transported, provide a detailed description of how the devices were packaged if antistatic or Faraday protection was provided. If not, why not?
- Describe the location where seized materials were taken, including the location and type of storage facilities used to house the materials. Record the name and contact information of the person transporting each item.
Whenever live data acquisition is deemed necessary, record the following:
- What type of date was acquired (memory dump, system files, paging files, etc.)?
- What tools and procedures were used to connect to the suspect machine?
- What tools and procedures were used to acquire the data?
- What was the time and date the data was imaged, and what was the time and date reported by the device from which the data was acquired? The two are not always the same.
- What are the type, make, model, and serial number of the target device to which the data was copied?
- What is the condition of the target device (new, forensically cleaned, data-wiped, or formatted)?
- What are the MD5 and SHA-2 hash calculations of the image?
When devices are imaged for later analysis, record the following:
- The type, make, model, and serial numbers of source devices
- The type, make, model, and serial numbers of target devices
- Precautions taken to avoid contamination or loss of data in evidence
For disk drives:
- Drive parameters of disk drives, both target and source
- Jumper settings
- Master/slave configuration if IDE
- Device ID if SCSI or SATA
For optical or flash drives:
- Make, model, and capacity
- Mounted or not mounted at time of seizure
- Inventory of blank or used media
For seized media:
- Form of disks (CD, DVD, Zip, etc.)
- Capacity of disks
- Number and type of seized disks
- Possible evidence that there are missing disks (empty jewel boxes, etc.)
- The date and time of each action taken.
- The process used for mounting the seized device, including mechanisms in place to assure write-protection
- The process and tools used to acquire the forensic image
- MD5 and SHA-2 hash calculations of the image before and after acquisition
- Photograph computer systems before and after disassembling for transport.
- During the examination and analysis of data, record each procedure in detail, identifying any tool used. Record beginning and ending hash calculations of source data, explaining any discrepancies that may occur.
- Above all: Maintain an unbroken chain of custody that includes each piece of evidence handled throughout the course of the investigation.
As is readily apparent, case documentation is not to be taken lightly. While individuals should be treated as innocent until proven guilty, sources of evidence by default get the opposite treatment. The astute investigator always assumes that any case he or she is working will eventually end up in court. Even the seemingly benign cases, such as uncovering evidence of employee misconduct, can end up in court as a civil (or even criminal) court case. Poor documentation can endanger what would otherwise be a sound case.
Process Documentation
Unless an investigator or an organization utilizes homegrown tools, most process documentation is likely to come from the vendors providing the hardware or software used. There are some pieces of documentation that must be generated by the agency. Process documentation includes
- User manuals
- Installation manuals
- Readme files stored on installation media
- Updates to manuals posted online by the vendor
- Logs showing updates, upgrades, or patch installations
This is the type of documentation that does not necessarily need to be provided with each investigation report. It must, however, be available if demanded by opposing counsel, a judge, or arbitrator. There are situations that occur where process documentation is used to support or refute claims that proper procedure was followed during specific steps in the investigation.
Building the Timeline
Key to virtually every investigation involving computer or network activity is the creation of an accurate history of events related to the incident under investigation. By creating an easily comprehensible report of the order of events that occurred, the investigator can more easily and more accurately show correlation between those events. For example, it is easier to associate a specific user to the origination of a particular file if the timeline shows that the file was created at a time when it can be shown unequivocally that the user was logged onto the computer or network.
The timeline (Figure 1.2) needs to start from a time just before the incident was known to begin or was initially discovered to the point when the evidentiary materials were acquired for analysis. This is why it is essential that the investigator do nothing that could alter the metadata of files stored on the computer. Metadata is information about files that can be either stored within the file itself or extracted from other repositories, such as the Windows master file tables or registry. Three critical pieces of information are the creation date, last accessed date, and last modified date. Together these form the file’s MAC (modified, accessed, and created) data. Simply viewing a file in a browser or application alters the accessed data. Copying a file from one location to another can modify both the creation and modified dates if forensically acceptable methods are not used. Metadata and ways of protecting and analyzing it will be covered in greater detail in Chapters 9 and 10.
)
Figure 1.2 A good timeline is essential in communicating the order of events to outside parties of interest.
Network and user logon activity are also critical to creating a timeline, as are Internet and e-mail usage. There are various tools that help the investigator validate times that certain events occurred. MACtime is a common forensic tool that can extract a history of user activity on a system. It creates an ASCII timeline of file activity. X-Ways Trace can be used to extract and analyze Internet history. In a network environment, event tracking in utilities such as Microsoft’s Event Viewer, the registry, or log files can reveal valuable information that can be used for assembling a credible timeline.
Timelines can be assembled in graphical form that makes it easy for laypeople such as lawyers and judges to understand. Some of the forensic suites (notably Encase) produce automated timelines. Others, such as the Forensic Tool Kit, do not. It is possible, but not necessarily pleasant, to create a timeline using commercial products such as Microsoft Visio, Excel, or OpenOffice. Excel is very cumbersome for this task and is not recommended. Microsoft Visio produces more polished timelines but is limited by the fact that each event must be entered into the timeline separately. A better use of the investigator’s time is to invest in a proprietary product such as Timeline Maker for Windows or Bee Docs for Macintosh computers.
Chain of Custody Reports
For every physical unit of evidence taken into possession by an investigator or agency, there must be a continuously maintained chain of custody report. Consider it the equivalent of a timeline for evidence. The chain of custody report must be able to verify several critical pieces of information:
- Identify the item precisely, listing type of evidence, make, model, and serial number (if relevant), and make a photograph of the item (if possible).
- Specify when was the item taken into possession.
- Identify where or from whom the item was seized.
- Record who acquired the item along with the time and date acquired.
- Document who transported the item and how was it transported.
- Document how was the item stored during transport.
- Regularly record how the item was stored during possession.
- Provide a continual log, showing the time and date of each time it was checked out for examination, the purpose for checking it out, and the time and date it was checked back in for storage, identifying who had possession of the item during that time.
While an item is in possession of an individual investigator, that person should document what steps were taken to preserve the integrity of the evidence while in possession. Such documentation needs to include a precise identification of the device in possession (as defined above) and what controls were in place to protect the device from electrostatic discharge, electromagnetic interference, and other potential sources of data corruption and other protections. Document what methods were used to prevent data from being inadvertently written to the device (write-blocker devices, software write-protection, etc.). Generate before and after hash values to confirm that the data source did not change while in possession. If it did change, document what process caused the change, along with how and why the change occurred.
Any deviation from standard documentation procedures in preparing the chain of custody can, and most likely will, lead to challenges from opposing counsel and can possibly cause the evidence to be thrown out. No breaks can exist in the timeline, because this indicates an opportunity for the data to be replaced, corrupted, or modified.