Collecting Digital Evidence from Intrusion Detection Systems

1
Collecting Digital Evidence from Intrusion
Detection Systems

• Bill Allen
• CGS 5132 - Computer Forensics II
• Spring 2002

2
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

3
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

4
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

5
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

6
What went right

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

7
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, couldnt link Pryce to ISP
• Pryces 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

8
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

9
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