-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob, Most of these issues are settled with methodology. > The evidence you present must be able to stand up to a defense > attorney asking you to explain exactly how linux moves the data > from one disk to another, and how you know that nothing could have > gone wrong with that process. If a defense attorney is likely to ask this about Linux, they are also likely to ask this about Solaris, SunOS, Windows (pick your version), DOS, and any other OS you may use. Every computer security practitioner can tell you that things go wrong in computer systems routinely. That's why we routinely test both our operating systems and our hardware for performance. Of course something COULD go wrong. But DID something go wrong. If we have properly preserved the evidence and calculated MD5 or SHA1 hashes on all the files, free space and the entire physical device itself, we will be able to identify errors in processing. And what errors may occur because the OS made a mistake moving data from one place to another will be both rare and identifiable if we have done the right processing things up front. Those errors will also be of a type that they will produce random data, not entire picture files that did not exist on the evidence or legitimate entries in the middle of logical log files, or other legitimate data. The OS can not produce, through error, a .jpg file with child pornography. > How do you know that the data that ends up > on the target drive isn't stuff that was already there from a > previous investigation, instead of his client's data? Have you > reviewed the code personally? Are you an expert on operating > system design? 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. > Can you explain why Linux has a history of introducing new file > systems because of problems with the old ones? If you are asking as a defense attorney, I'll ask "Which specific problems do you mean?" And then we'll have a discussion of the changes in file systems and how those changes have enhanced the file system over time and how FAT file systems progressed to FAT12, and to FAT16 and to FAT32 and to FAT32X and on and on and on. Until one attorney objects to the relevance of the testimony. So what!! How does it impact THIS case and THIS evidence. > How about the virtual memory > system? Have you reviewed the code for it? How do you know the VM > system didn't overwrite the disk buffers with old data from unused > sectors on its own boot drive, inserting stuff that was actually > left over from an old investigation that the old drive had been > used in? Again, methodology. We keep images of our forensic platform. We can restore that image to the system at any time and overwrite any data from a former investigation. But to the issue of code review. Who has reviewed the code for Windows and how it uses the Swap file. No one. The court does not require it if something is commonly used in the industry. > Yes, all of these questions _can_ be answered, but will you have > the answers ready when you are faced with them in court? Yes > The advantage of a simple tool is that the answers are simple. > "Well, it doesn't have a VM system, so that couldn't have > happened." If you use custom code of your own writing and it is not generally used by other practitioners in the field, has not been subject to peer review, and has not had formal, impartial testing conducted and documented, then you open yourself up to the kinds of questions you have asked here. And you will have to testify about the source code and how the applications works. Using recognized and tested tools will alleviate you from most of that burden. And Linux and dd have been tested and the results documented in various public forum for anyone to see and validate. > It may be powerful for analyzing data, but how will you defend it > in front of a jury? "No, I don't know if this particular version > of Linux has ever had a complete code audit. No, I don't know if > the people who wrote that code knew what they were doing." (given > the security history of Linux, the answer is: they probably > didn't) Same is true for any other operating system. Who has conducted a complete code audit of Windows (if you say Microsoft I'll laugh). Who has conducted a complete code audit of any operating system. It is an irrelevant argument. > In most U.S. jurisdictions, at least, it isn't the court that will > argue with you. The judge is obligated by law to accept the > testimony of an expert witness as reliable. It is when the defense > presents their own expert witness who explains to the jury why > the tools you used are unreliable that you will have problems. > Once there are two expert witnesses in conflict, the judge has > discretion about whom to believe. And the defense only has to > insert a little bit of doubt in the jury's minds to win the case. If someone wants to present evidence to a court and jury that indicates Linux, as an operating system for forensic purposes is UNRELIABLE, I'd love to be in court to participate in that discussion. I think we'd find that EXPERT quickly impeached. > When the defense hires their own expert on operating system design > who explains how Linux was developed by a bunch of hobbyists, and > challenges you to produce documentation that proves it was designed > by a process that meets industry "best practices", you will have a > problem. Operating system design issues are not relevant. Operating system performance issues are relevant. Lets have counsel keep defense counsel on point. > 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. > 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? This is a great discussion. James ********************************************* James O. Holley Advanced Research Projects Team Fiderus Strategic Security & Privacy Services (w) 703.684.3140 (p) 888.620.5275 jholleyat_private or 6205275at_private Emergency 24 hour response: 1-877-595-8491 ********************************************* -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBOzyTy6vnU17EydfvEQIkYwCg/S0mNr+pvmKp9WfLMzqBwrOIqkwAnj2I Ez672fD0tpkeI9tRLbWFbg+A =4tEO -----END PGP SIGNATURE----- ----------------------------------------------------------------- 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 : Fri Jun 29 2001 - 08:56:48 PDT