In California, (and this may be true in others as well) If you can show credible testimony that origin of the logs stems from an automated process you have a large part of the battle. This is true from many methods of obtaining digital forensic evidence like imaging, searching etc. Then you only have to provide testimony as to chain of custody an origin. IE, we brought in the sys admin who testified as to how the logs originated, I testified as to how the logs were then taken from the machine, and then the format I had them in, (CD, another drive whatever)and that they were unchanged (MD5 hashes) from the time they were obtained. It helps get over the Daubert standard for admissibility. Can someone attack this, of course. It all boils down to the witness's credibility, and as Jonathan said, correlating and authenticating what you have. I have tried to never hang my hat on one nail doing forensics. Ed Hudson District Services Manager X-Force Professional Security Services Internet Security Systems (ISS) San Francisco CA Office: (707) 836-9740 Cell: (707) 799-3250 Fax: (707) 581-1886 E-Mail: ed.hudsonat_private Internet Security Systems-- "The Power to Protect" ************************************* Declare an Emergency 1-888-546-2407 ************************************* -----Original Message----- From: Jonathan A. Zdziarski [mailto:jonathanat_private] Sent: Tuesday, June 18, 2002 6:22 PM To: mstevensonat_private; forensicsat_private Subject: RE: Audit Logs as submissible evidence. It all comes down to the credibility/reliability of the data and the authentication of that data. Evidence such as tape recordings and server logs must be authenticated to be admitted into court, and the authentication always turns out to be your burden. If the data is credible enough, the judge may allow it but if there is doubt, it will most likely be argued as hearsay (The logs told me this...the sysadmin told me that...) The best defense would be to do everything you can to authenticate the data. MD5 checksums, private encrypted network channels, token authentication, and of course remote logging are all very supportive, but ultimately someone has to be able to get up and testify that the data is original and valid. Trace the reliability of the data back through the network and finally get some expert security specialists to testify that the data couldn't possibly be corrupted. Most importantly keep it simple. You've seen how confused judges get when us geeks start talking technical. Explaining in simple terms from reliable witnesses who can vouch for the data is probably the only thing that will disarm a confusopoly [Dilbert] that the other side will try and explode. One important thing that I've been told has played a big role in evidence gathering during my time doing forensics is correlation. In one instance, we had the logs from some of our local machines, but it was backed up by the logs of another system that was compromised a few thousand miles away. Correlating the IP addresses and timestamps back to the originating network (and ultimately back to the user) and getting at least two or three of the networks to authenticate the information is very effective in proving reliability of the data. -----Original Message----- From: mstevensonat_private [mailto:mstevensonat_private] Sent: Tuesday, June 18, 2002 11:15 AM To: forensicsat_private Subject: Audit Logs as submissible evidence. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There have been a lot of posts about imaging compromised systems and using that as forensic evidence, but it seems to me that this approach gives a lot of clues about the what, but not the who. Most of the clues that you would need to find the what, when, who and how are in the audit logs (assuming the administrator turns logging on). If the audit logs could be handled in such a way that it could be proved that they are telling the truth, then it seems to me that they would yield enough evidence for legal action. Has anyone had any experience with using audit logs as forensic evidence? What should an administrator do to ensure the logs he keeps can be used in case legal action is required? Obviously you can not trust logs residing on the compromised system, but what can you trust? A seperate log server using MD5 checksums? What about the things an administrator may do to better handle the sheer mass of audit logs? If he parses raw logs and imports them into a database for better analysis, does that taint the evidence to where it couldn't be used? What about syslog? Does syslog "taint" the evidence of raw audit logs? If raw kernel generated audit logs are the only things submissible as forensic evidence, how do you obtain them and keep them "clean"? - -Miles -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPQ9Ob4mSCsFQKGr9EQKX4ACg08E6eS4ZGeCsS6Dg2qxRiR+yqUUAoO2h E+j5qbFzu4gIQ4KAMkebMfGf =6Cx6 -----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 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 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 : Wed Jun 19 2002 - 08:03:22 PDT