Incident Handling and Computer Forensics

1. Incident Handling and Computer Forensics

2. NIST Publication 800-61 • Computer Security Incident Handling • Computer Security Incidence • Denial of Service • Malicious Code • Unauthorized Access • Inappropriate Usage

3. Incident Policy & Procedures • State of Management commitment • Purpose & objective of the policy • Scope • Who does it apply to • Under what circumstances • What is a computer incident • Organizational structure • Roles and responsibilities • Who can confiscate/disconnect equipment • Who/what can be monitored • What kind of reporting is required

4. Incident Policy & Procedures • Prioritization of incidents • Performance measurements • Reporting and contact info

5. Sharing with Outside Parties

6. Media • Dealing with the media can be tricky • How much info to give out • How to answer questions • How to disseminate info • Press release • News conference • Hold mock interviews to hone skills. Practice answering questions like: • Who attacked you? • When did it happen? • How did they do it? • How wide spread? • Did this happen because you have poor security practices? • Who is affected? • How much $$$ • Etc…

7. Law Enforcement • Who should we contact? • FBI • District attorney offices • State law enforcement • Local (County) law • Only contact one to prevent jurisdiction conflicts • Become familiar with law enforcement personal before an incident • Learn how the various entities want incidents reported • Find out what evidence needs to be collected • Determine a primary point of contact in your organization

8. Incident Reporting Organizations • You will be relying on outside parties to help you. You should contribute to help others • CERT Coordination Center • Run by Carnegie Mellon • Provides an incident reporting system • Information Sharing and Analysis Center (IT-ISAC) • Keeps a alert system about the number of attacks • Forum of Incidence Response and Security (FIRST) • Shares information among incidence teams

9. Other Outside Entities • Your ISP • Owner of the attacking address • Caution, you might be contacting the hacker’ • Software vendors • Affected External Parties • How do you handle someone who calls to tell you your system is attacking them? • How do you contact someone who’s social security number was compromised? • Contact to these parties should happen BEFORE the media hears of it

10. Incident Team Structure • Central • One team is responsible for incidences in the entire organization • Good for smaller or geographically dense organizations • Distributed • Several teams, each responsible for there unit or geographic area • Good for large orgs. • Must have a central team to coordinate common attacks • The need to communicate between teams is essential • Coordinated • A distributed team, but the central team provides guidance and advice, but does not have authority over the teams

11. Incident Team Staffing Models • Employees • All incident work is done in house • Partial Outsourced • Part of the incident teams work is outsourced • Most common: • IDS systems monitoring • They are most likely more skilled (they look at reports all day long) • 24/7 • If an incident is noted, the incent is handed back to the inside team • On call contractors • If an incident is discovered, outside contractors assist in the handling • Fully Outsourced • Mostly used for smaller companies with not enough employees to specialize in Incident handling.

12. Inside Contacts • Management • Information Security • Most likely found the incident • May be needed to alter security settings (IE firewall rules) • Telecommunications • IT Support • Have the best know how about the systems • Know the day to day running of the organization • Legal Department • Rules • Legal ramifications • Right to privacy • Evidence collection • Persecution • Law suits

13. Inside Contacts • Public affairs • Human resources • Business Continuity • Minimize business impact of an incident • Alter business plans and projections based on an incident • Physical Security • Getting access to a workstation in a locked office

14. Incident Team Services • Advisory Role • Monitor current threats and incidents • Relay important info to the rest of the organization • Vulnerability assessment • Scan, probe, penetrate • Intrusion Detection • Education and Awareness • Good passwords • Educate employee to notify them of unusual activity • Train technical staff about vulnerabilities and how to protect against them

15. Incident Life Cycle

16. Incident Life Cycle - Preparation • Tools and Resources needed: • Communications • Outside contact list • On-call list • Incident report mechanisms – forms, emails, anonymous reporting • Pagers/Cell phones of team members • Encryption software – Used to communicate between team members (pgp) • War Room • Secure storage

17. Incident Life Cycle - Preparation • Tools and Resources needed: • Hardware and Software • Forensic workstations • Backup devices • Spare workstations and network equipment • Used to try out malicious code • Restore backups • Blank media (cd-r, dvd-r, usb memory sticks) • Portable printer • Packet sniffers / Protocol analyzers • Forensic software • CDs, usb, and floppies with trusted applications • Evidence gathering accessories • Notebooks • Cameras • Audio recorders • Chain of custody forms • Evidence tags

18. Incident Life Cycle - Preparation • Tools and Resources needed: • Analysis Resources • Port lists • What ports should be open on what machines • Documentation • Network diagrams • What servers, switches, routers, firewalls, etc • What server does email, web, dns, etc and where are they located • Baselines • What is normal activity • Hashes • A collection of hashes of critical applications • Eases detection of infected systems

19. Incident Life Cycle – Detection and Analysis • Detection • Software Alerts • IDS • Antivirus • File Integrity • 3rd party monitoring – probe various services to make sure they are up • Logs • OS • Application • Network device • Publicly available info • Info on new vulnerabilities • Info of incidents at related organizations • People • Internal users • Outside users

20. Incident Life Cycle – Detection and Analysis • Analysis • Understand Normal behavior • Centralized logging • Have devices and software send their logs to a central location or server • Log Retention policy • How long do we keep logs? Archive them? • Event correlation • Events can be caught on several logs • Extract log entries across multiple logs can provide valuable info about the event • Clock synchronization • Logs are almost impossible to correlate if there are different times stamps • Use ntp

21. Incident Life Cycle – Detection and Analysis • Analysis • Maintain a knowledge base of info • Links to malicious code and hoax info – antivirus vendors • Links to lists of black listed spam sites • Links and manuals explaining the various codes associated with error messages • Use google, yahoo, etc… • Run packet sniffers • Filter data if the quantity of events is to large • Experience • Diagnostic matrix for the less experienced

22. Incident Life Cycle – Detection and Analysis • Documentation • As soon as a event is suspected, start a log. • Document events as they are found • Phone conversations • File changes • Time stamp and sign every entry • Can be used in a court of law • Work in teams of 2. • One performs the work • One logs the work • Put the log into a database or some where other team members can get to • You can’t work 24/7 • Vacations, sick time, even death • Need to be able to allow other to start where you left off

23. Incident Life Cycle – Detection and Analysis • Prioritization • If many events happen in quick succession you need to prioritize them • Current and Potential effect • An root compromise on one system, can they get to others • A worm on a few computers may spread to the entire org • Criticality of the affected system • Is it a business critical web server, email, fileserver… • Service level agreements • Maximum time to restore key resources • Maximum time to react to events

25. Incident Life Cycle – Detection and Analysis • Notification • CIO • Head of information security • Other incident teams • System owner • Human resources (if it involves employees) • Public affairs (if it might generate publicity) • Legal dept

26. Incident Life Cycle – Containment, Eradication and Recovery • Containment Strategy • Method • Shut down • Disconnect from the network (wired or wireless) • Segment the network • Disable functions • Block hosts or ports at the perimeter • Rebuild or clean

27. Incident Life Cycle – Containment, Eradication and Recovery • Containment Strategy • Considerations • Potential damage to and theft of resources • Need for evidence preservation • Service availability • Time needed to implement the strategy • Effectiveness of the strategy • Duration of the solution • Emergency work around (several hours) • Temporary work around (several weeks)

28. Incident Life Cycle – Containment, Eradication and Recovery • Evidence Gathering and Handling • Primary reason is to resolve the incidence • May also be needed for legal reasons • Needs to be handled according to procedures that meet applicable laws and regulations • Log of the evidence including: • Identifying info (location, serial number, model number, hostname, MAC address, IP address, etc…) • Name, title, phone or each person who collected data • Time and date of each collection • Location of where the evidence is stored – must be a secured location • Evidence must be accounted for at all times • Chain of custody

29. Incident Life Cycle – Containment, Eradication and Recovery • Volatile Evidence (in order of volatility) • Network Traffic • sniffers

30. Incident Life Cycle – Containment, Eradication and Recovery • Volatile Evidence (in order of volatility) • Memory • Plug in media with trusted software (usb, cd, network share) • Execute shell from trusted media (cmd.exe, bash, etc) • Dump memory to a file (not on the suspected equipment!) • Unix: cat /dev/memory > file • Windows: mdd –o file • Mantech Physical Memory Dump • http://sourceforge.net/projects/mdd/ • Windows Forensic Toolkit • www.accessdata.com • Eject media, hash the extracted file, copy the file to write once media (cd), hash copy and compare. • Copy again, hash compare. • Enter first copy into evidence (recording hash on the evidence tag)

31. Incident Life Cycle – Containment, Eradication and Recovery • Volatile Evidence (in order of volatility) • Hard Drive • Consider • Volume of storage • Drive configuration • Is the machine mission critical • Do a graceful shutdown • Remove hard drive, connect to a work station with a write blocker • Hash original • Duplicate • Hardware duplication is best • www.ics-iq.com • Software • Linux: dd • Encase: www.guidancesoftware.com • Windows: Forensic Toolkit

32. Incident Life Cycle – Containment, Eradication and Recovery • Volatile Evidence (in order of volatility) • Hard Drive • Duplicate • Or reboot the compromised system with helix linux (www.e-fense.com/products.php). Good when the system uses software RAID or LVM • Rehash the original to verify nothing was changed • Hash duplicate and compare to verify that the copy is the same • Enter the original and hash into evidence

33. Incident Life Cycle – Containment, Eradication and Recovery • Volatile Evidence (in order of volatility) • Data Analysis • Verify Hash • Undelete or recover files • Index identifiable words into a database and search • Strings • Hash individual files • NIST has a database of hashes of compromised files • www.nsrl.nist.gov • File signature analysis • Is the file what the extension say it is? • Key word search • Pwdump –outputs hashes of windows passwords • Sysinternals • Dameware: www.dameware.com

34. Incident Life Cycle – Containment, Eradication and Recovery • Volatile Evidence (in order of volatility) • Data Analysis • AV Scan • Multiple AV software brands • www.virustotal.com/ • Method • Find a bad file • Search for other files with the same date and time • Look in the same directory • Check event logs for that date/time • Search registry for file name • Repeat with any new files found

35. Incident Life Cycle – Post Incident Activities Lessons learned Policy updates Pursue legal action