James Holley wrote: > Bob, > > Most of these issues are settled with methodology. > Ah, well. I've been shot down by your first sentence. [ ... parts deleted for brevity ... ] > I am no expert at operating system design, though I did take a class > on operating systems design in my Masters degree program. However, > the answer to this is, again, methodology. Use clean media. Always > use wiped media to house restored images of evidence drives if you > are using Linux as a forensic platform. Always use clean, wiped media > to house the evidentiary images as well. I think if anyone learns something they didn't already know from this discussion, that would be a good thing to take away. You can't contaminate evidence with something that isn't there. The history of personal computers includes a few examples of developers accidently shipping part of the source code for their products in the unused sectors of the installation floppies, because the original image was created on floppies from which the code had merely been deleted (i.e. the file entry was deleted from the directory, but still existed on the disk) rather than wiped (actually overwriting the data that was in the file). [... more deleted ...] > > Because in court, a defense attorney isn't really interested > > in the truth. His goal is to get the jury to have just a little > > bit of doubt about what happened. If he can do that, he wins. > > Finally, we agree. > > So it is our job to help counsel keep focused on the important issues > and not allow defense counsel to cloud the court with irrelevant > arguments. Well, maybe that's really my point. Even if the defense counsel's questioning borders on frivolous, there is no guarantee that you won't have to deal with it. You can't always count on your side being represented by someone who will object when it is appropriate. > > > Although Linux can be used successfully as a forensic tool in > > many cases simply because the defense wouldn't have the money or > > the expertise to attack it, you should be very cautious about > > using it as an evidentiary tool in a big money case. It would > > be better to use a tool that is easier to explain to a jury. > > OK. Back to being disagreeable. Easy to explain is "This image is > exactly identical to the original evidence. I know that because an > MD5 hash of this image (i.e. md5sum evidence.img) is exactly the same > as an MD5 hash of that hard drive (i.e. md5sum /dev/hdb). This is > very easy to explain. So what imaging tool do you use and how do > you explain its operation to the jury? > Well, I did go a bit overboard. Maybe a lot overboard. There is a limit on what sort of challenge is worth presenting, because it clearly becomes ridiculous. But most people who've never seen the process in action don't understand the degree of care that is necessary to preserve the value of evidence. No, I don't collect evidence for trial, in part because I don't have the tools or procedures in place to do the job right. Which is probably the other lesson to be taken away from this discussion. You must have proper procedures in place _before_ you start collecting evidence, or you are likely to botch it up, regardless of what tools you have. _My_ procedure is to isolate the system in question until it is decided whether there is a need to collect evidence. It is easier to effectively _protect_ evidence than it is to _collect_ it. But, IIRC, that isn't the scenario presented in the original question, which concerned covert evidence collection. And when I collect evidence for internal use, I use FreeBSD instead of Linux ;) > This is a great discussion. > > James - Bob ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sun Jul 01 2001 - 10:36:31 PDT