Collecting Digital Evidence from Intrusion Detection Systems: Collecting Digital Evidence from Intrusion Detection Systems Bill Allen CGS 5132 - Computer Forensics II Spring 2002


Intrusion Detection Systems are not designed for forensic use: Intrusion Detection Systems are not designed for forensic use opposing design goals - speed vs. accuracy high false-alarm rate - accuracy is not proven, will it be admissible? reliability not proven - evaluations show that packets are often dropped in high traffic periods insecure logging of alerts/data - chain of custody may not be maintained usually runs unattended - who can access it? can be attacked - susceptible to denial of service


What is needed?: What is needed? reliability - no dropped packets or lost files reducibility - need tools to filter out everything but the real evidence secure storage of evidence - need the digital equivalent of an evidence locker access controls for operators / investigators - access to hardware, software and data must be controlled and automatically logged to prevent tampering or a break in the chain of evidence


The IDS Logs are the Key!: The IDS Logs are the Key! must include sufficient detail to identify date/time, type of intrusion, possible sources, etc. must be stored in a safe place, not on a machine that can be compromised must be protected from being compromised before, during and after the intrusion must accurately report all evidence of the intrusion must be coordinated to show all of the actions taken by the intruder, system-wide


Case Study: Rome AFB 1994: Case Study: Rome AFB 1994 intruder detected by IDS at Rome, NY AFB individual named Richard Pryce was identified and arrested by Scotland Yard in England AF must prove that Pryce was the intruder: he used a phone hop through Bogota to a Seattle ISP he hacked several machines at Rome and downloaded classified data his home computer and phone records were seized logs at Seattle ISP and from Rome IDS were available


What went right…: What went right… Pryce was identified because he bragged to an undercover AF intelligence officer in a chat room Pryce’s computer contained stolen classified data Pryce’s phone records showed that his calls matched the time of intrusion Seattle ISP logs showed Pryce’s hacking activities Investigators and prosecutors presented enough evidence that Pryce plea bargained soon after the trial began and before a ruling was made


What could have gone wrong…: What could have gone wrong… the defense was not allowed access to much of the forensic data because it was classified no logs from Bogota, couldn’t link Pryce to ISP Pryce’s phone logs only showed time of calls there was no proof of a direct connection between Pryce and the intruder at Rome AFB because a large team was involved in the case, the presenter of evidence in court was not one of the forensic investigators


Suggestions…: Suggestions… IDS should be used to indicate possible intrusions gathering / investigating forensic evidence should be a separate operation must be able to coordinate multiple sources with time / data synchronization evidence logs should be cryptographically secure access to data, hardware and software must be controlled and logged


References: References Peter Sommer, Intrusion detection systems as evidence, Computer Networks 31, 1999 Peter Stephenson, The Application of Intrusion Detection Systems in a Forensic Environment, proceedings of RAID 2000 Patrick Mueller, Dragon Claws its Way to the Top, Network Computing, Aug 2001 Bruce Schneier and John Kelsey, Secure Audit Logs to Support Computer Forensics, ACM Trans. on Information and Computer Security, May 1999