1. Chapter 7 Live Data Collection Spring 2016 - Incident Response & Computer Forensics

2. The Goal  Preserving volatile evidence  Risks involved  The data collection process may change system state  It may even cause the system to crash  One must make effort to minimize the change to suspect’s computer

3. When to Perform A Live Response  If you think volatile data contains critical information not found anywhere else  Forensic duplication is difficult (e.g., too many systems to collect data from)  Forensic duplication may fail  Reasons exist to preserve as much data as possible  Risk  Any interaction with a system makes changes to system state

4. Selecting a Live Response Tool  Factors evaluating live response tools  Is the tool accepted in the forensic community?  Does it work in common OS environment?  Does it collect data that is helpful?  How much time does it take to collect data?  Can the tool be configured?  Can the output be easily reviewed and understood? Always use trusted tools/files Always use trusted tools/files

5. What to Collect?  Two types of data can be collected  Data that describe the current state of the system  Data that is less volatile and shows what has happened in the past Live Re sponse data  System date, time, time zone  OS version information  General system information: memory, hard-disk, etc.  Local user account information  Network interface information  Network connections and associated processes  Files and other open handles …… (See pages 140 – 141 in the textbook for a suggested list)

6. Collection Best Practices  Before running live response on a suspect system, practice on a test system  Run the tests multiple times and on more than one system  Minimize the time spent on system during data collection  The suspect system may have been infected with malware. So,  Document what you do and when you do it  Do not interact with the suspect system unless there is a plan  Use tools that minimize the impact on the target system

7. Collection Best Practices  The suspect system may have been infected with malware (continued)  Use tools that keep a log and compute checksums of output  Automate the collection process  Try to collect data in terms of volatility  Treat the data collected as evidence  Do not keep any important files etc. on the media that you connect to suspect’s system  Do not do anything that will result in unnecessary modifications to suspect’s system – unless it is absolutely necessary  Do not perform analysis on suspect’s system