Deciding how to maintain the integrity of a system for use in a forensic examination can be a little like deciding which club to use to get out of the rough on the last hole of a golf tournament, i.e. the . . .
Deciding how to maintain the integrity of a system for use in a forensic examination can be a little like deciding which club to use to get out of the rough on the last hole of a golf tournament, i.e. the stakes are high and you never know if you've made the right choice until it's too late to change your mind (note: this analogy only works if you play golf as badly as I do. If you're a good golfer, or if you don't play golf at all, you'll have to come up with one of your own). While the use of good judgement may be more art than science, if we keep in mind certain basic principles and remember to think before we act we should give ourselves the best possible chance of a successful forensic outcome. These basic principles are the bedrock upon which any notions of a "best practice" must be constructed and will be the basis of this article.

It should be noted that this article is not intended to provide a list of steps for investigators to take, although I will include a list at the end to summarize the main points, but rather it is an examination of the issues which investigators concerned about "best practices" might care to bear in mind. There are two reasons for this. First, although computer forensic cases may share many common aspects it is rare that they are exactly the same. As a result, a single, specific step-by-step approach applicable to every situation is practically impossible to put together and is likely to be less than useful in the real world. Second, exactly what constitutes a best practice remains a source of some debate within the computer forensics world. What may be a best practice in Paris, Texas might be unacceptable in Paris, France (or vice versa!).

The link for this article located at SecurityFocus is no longer available.