INCIDENT RESPONSE PLANNING and FORENSIC READINESS

1. INCIDENT RESPONSE PLANNINGand FORENSIC READINESS Denver ISACA Presentation February 21, 2002

2. Incident Response Planning and Forensic Readiness Kevin Rich Managing Security Architect @stake @stake is a consulting firm specializing in secure design, architecture, and assessments of digital technology @stake, the best minds in digital security

3. Objectives • This is not a comprehensive discussion • Get you thinking about Incident Response and Forensic Readiness • Ideas and guidelines for your own implementation • Agenda • Definitions • Scoping • Planning • Readiness • ROI • Questions

4. Definitions • Incident Response • Any action by your organization to a defined event • There are many types of incidents • Our focus will be on technology incidents • Incident Response Planning • Efforts by your organization to handle any incident • Forensic Readiness • Preparedness to gather, store, and handle your incident response data

5. If a tree falls in the woods … • Incident and incident types need to be defined in advance so that a proper response mechanism can be defined. • Incident response is not a standalone item, but must rest on a foundation of policies and an ability to properly determine what an “incident” is and when one has occurred.

6. Lifecycle • An incident is some event at a particular time and place • Planning and preparedness are both strategic processes • Planning and preparedness must come before the event.

7. What does your threat model look like? • Internal • Surveys indicate ~70% percent of security threats come from the inside • External • Do you have a highly visible Internet presence. • Are you a target of choice or a target of chance • Financial institutions verses Frankstacos.com • Failures • Does your organization require “highly available” systems • How much down time is acceptable

8. Threat Model: Internal • Willful Destruction • Theft • Abuse or privilege or resources • Accidental • These all have many categories but can be lumped into a few containers such as: • Property • Data • Resources

9. Willful Destruction • Definition • The act of destroying; a tearing down; a bringing to naught; subversion; demolition; ruin; slaying; devastation. • Example • A disgruntled employee physically destroys their laptop or formats the hard drive destroying data critical to project success

10. Theft • Definition • The act of stealing; specifically, the felonious taking and removing of personal property, with an intent to deprive the rightful owner of the same; larceny. Note: To constitute theft there must be a taking without the owner's consent, and it must be unlawful or felonious; every part of the property stolen must be removed, however slightly, from its former position; and it must be, at least momentarily, in the complete possession of the thief. • Example • An employee removes internal client information for sale to a competitor

11. Abuse of Privilege • Definition To use one’s legitimate access rights to perpetrate a malicious activity. • Example: IT VAR monitors financial firm’s buy and sell activity by pulling Sybase traffic from a protocol analyzer deployed to capture said data for performance analysis.

12. Accidental • Definition Occurring unexpectedly, unintentionally, or by chance. • Examples • An employee selects files for deletion on the corporate file server. But unwittingly deletes files not owned by them. • The cleaning crew unplugs a server so that they can plug in their vacuum cleaner. • The hot water heater explodes and floods the server room.

13. Threat Model: External • Social Engineering • Worms and Virii • DDoS • “Hackers” • Mis-configured and unconfigured devices

14. Social Engineering • Definition Term used among crackers and samurai for cracking techniques that rely on weaknesses in wetware rather than software; the aim is to trick people into revealing passwords or other information that compromises a target system's security. Classic scams include phoning up a mark who has the required information and posing as a field service tech or a fellow employee with an urgent access problem. • Example “Hello, this is Jim from Systems, we need your password”

15. Virii and Worms • Definition • Worm - A program that propagates itself over a network, reproducing itself as it goes. • Virii - Unlike a worm, a virus cannot infect other computers without assistance. It is propagated by vectors such as humans trading programs with their friends. The virus may do nothing but propagate itself and then allow the program to run normally. Usually, however, after propagating silently for a while, it starts doing things like writing cute messages on the terminal or playing strange tricks with the display (some viruses include nice display hacks). Many nasty viruses, written by particularly perversely minded crackers, do irreversible damage, like nuking all the user's files. • Examples CodeRed Stoned

16. DDoS • Definition Distributed Denial Of Service – A resource attack to a single target originating from multiple sources • Example • Yahoo, Buy.com, eBay, CNN, E*Trade, and Amazon attacks • Tools • Trinoo • Stacheldraht

17. “Hackers” • Definition There are many definitions, but for this discussion we’ll label hackers as “Bad Guys” attacking your systems or resources with malicious intent • Example A malicious intruder exploits a vulnerability in your organizations web application(s) and retrieves sensitive customer data

18. Mis-configured or unconfigured devices • Definition Any device placed into services before having undergone proper configuration. • Examples • Default OE installations • Default web server installation • Development systems • “Temporary” changes for testing or other purposes • Devices deployed by uninformed administrators

19. Threat Model: Failures Overview • Hardware Failures • HA component failures not noticed • Gradual component failures not noticed • Mis-configuration • Wireless AP breach of security perimeter • Unconfigured, Unused and Unknown services • Cascading ACLs mis-applied or mis-understood • Overly permissive ACLs by policy • Software Failures

20. Planning for an Incident • Policy and Procedures • Identify • Respond

21. Planning – Policy and Procedure • This must be the basis for any Incident Response Strategy • Publish it • Disseminate it • Keep it current

22. Planning – Identify • A vital part of incident response is knowing that an incident occurred. Identification may come thru human intelligence or system intelligence. Incident identification must be based on defined policy. • Awareness training for employees • Simple means of reporting incidents to the correct department(s) • Intrusion Detection Systems (HIDS and NIDS) • Properly formatted logs in a central location • Common Format • Segregated • NTP is a must • Monitoring • Monitoring can be performed internally or thru managed service providers • Automated • Manual

23. Planning – Respond • Knowing how you will respond before it’s time to respond is critical. • Based on Policy • Training and Drills • Legal Issues • What types of events will involve your legal department • If you do not plan to prosecute, the incident can be handled differently • Who will be contacted • Escalation procedures (when do we tell the VP?) • How will personnel be contacted? • Pager, phone, e-mail, running thru the halls screaming “FIRE” • How and When do escalation occur • Does time affect who will be contacted

24. Planning – Respond • Keeping Accurate Records • Record everything and timestamp it • Keep the record book with you at all times • Who touched, when did they touch it, and why did they touch it • Knowing where things are • Does anybody know where the backups are • Hot swaps for failures • Contact information for vendors, support contract, internal employees • Checkpoints • Somebody needs to “own” the process • This should be someone who is not involved in the tactical effort • Is everyone on track • Are efforts being duplicated • Have the correct departments been notified of restoration or delays

25. Forensic Readiness • Readiness is the key – Without being ready, your results will most likely fall short of a full understanding of what really happened. If you intend to make a legal case, the investigation must be complete. • Forensic efforts must be conducted by trained experts. • Tools are complex • If used improperly, the tool will destroy the very evidence that you are trying to preserve • The forensic effort is VERY manual in nature • After the data is properly collected, analysis is often not intuitive

26. Forensic Readiness - Baseline • Collect the Evidence – Like a police investigation, the crime scene must be preserved by blocking access and taking “pictures”. Digital information is stored on the disks of compromised systems and requires a cryptographically signed image. The system should be taken offline and the physical disk(s) stored properly. Time is of the essence for collection procedures. • Evidence Retention – Establish a chain of custody to document who has had custody from time of discovery to presentation in court. Additional evidence such as logs from firewalls, IDS, and sniffers are useful. All systems should use NTP or other form of authoritative time stamps.

27. Forensic Readiness – Baseline (cont) • Reconstruction – Step 1 is to reinstall as much as possible and restore as little as possible. Reinstalling from trusted media reduces the threat of reintroduction. OS, applications and database stored procedures should all be reinstalled. • Host Hardening – Even fully patched systems are vulnerable. Production systems should have all unnecessary functionality removed and the remaining functionality should be hardened and configured to run with least privilege.

28. Forensic Readiness – Baseline (cont) • Logging – Accountability is the foundation for incident response and forensics. To use your logs effectively, answer these questions: • What information do the logs contain? • Where are the logs located? • How are the logs protected? • How are logs from multiple sources correlated ? • How is time synchronized? • Protecting Logs – The primary way of protecting logs is via file-system permissions. The process writing the log should only be able to write. Administrators should only be able to read logs. Other approaches include WORM media such as CD-ROM and printers.

29. Forensic Readiness – Baseline (cont) • Time Synchronization – Synchronizing system clocks in advance saves substantial time during incident response and evidence is strengthened when your IDS, firewall, and hosts all report the same event at the same time. • Network Time Protocol (NTP) is not a secure protocol, but is generally accepted. • STIME – http://www.ietf.org/html.charters/stime-charter.html - is headed for RFC and holds the most promise for becoming the industry standard.

30. Return On Investment (ROI) Benefits of forensic readiness Forensic readiness allows businesses to: • Quickly determine attack vector • Understand and isolate relevant information, minimizing required resources • Promptly remove threat of repeat entry • Recover from damage more completely and with less downtime • Detect trends over time • Receive insurance premium discounts

31. Return On Investment (ROI) Benefits of forensic readiness Lack of forensic readiness can result in: • Loss of business – damage to reputation • Loss of revenue – loss of clients • Legal action – inability to meet SLA, inappropriate actions, etc… • Data theft, modification or destruction • Inability to effectively regain administrative access/control • System downtime

32. Return On Investment (ROI) Honeynet (http://www.honeynet.org) project statistics • System running default installation was compromised • System infiltration lasted 30 minutes • Image was taken and made public for open source forensic examination • 13 teams participated • Teams required 48 person-hours for analysis on average • Just forensic analysis: • No IDS analysis or decision making • No forensic acquisition • No reconstitution • No stakeholder communications (beyond the reports generated)

33. Is my organization “Prepared” & “Ready”? • If you’re not sure, then you’re not! • @stake offers forensics readiness consulting • @stake Academy offers training courses to help get your organization prepared • Contact Information • Kevin Rich Managing Security Architect krich@stake.com • Sue Teague Account Executive steague@stake.com • Denver Office: 303 979-0035