Computer security incidents (usually security breaches) are a fact of life that many systems administrators must deal with at some point. Whether threats originate from malicious intruders, self-propagating worms, or trusted insiders, the need to quickly assess and appropriately respond is vital. In addition, performing an in-depth analysis (i.e., computer forensics) of the compromised machine later is crucial. This series, which is broken into two parts, covers both types of analyses. Part 1 and Part 2 of "Building and Using an Incident Response Toolkit" discuss how to build and use an incident response toolkit so that you can quickly collect data about that incident. Then, in upcoming issues, Part 1 and Part 2 of "Performing Forensic Analyses" will discuss how to perform a thorough analysis of a compromised machine, with an emphasis on possibly bringing evidence to court.
Whether you're using an incident response tool or performing an in-depth analysis, you need to keep in mind two basic principles. First, if the incident ultimately results in criminal proceedings, demonstrating that you haven't changed the evidence in any way is important. Changing the system as little as possible and hashing acquired data is standard practice. In addition, you should document all your steps and preferably have at least one other set of eyes to vouch for the validity of your collected data. If you don't take these precautions, proving that the intruder caused the damage to the system is difficult. . . .
Register
