1. 1 Incident Response Chapter 10 Copyright 2003 Prentice-Hall

2. 2 Figure 10-1: Incident Response Incidents Happen  Protections sometimes break down Incident Severity  False alarms  Minor incidents  Major incidents  Disasters

3. 3 Figure 10-1: Incident Response Speed is of the Essence  The need for speed  The need for prior preparation for speed and correctness during incidents  Most important actions occur before the incident happens Backup, training, rehearsals, etc.

4. 4 Figure 10-2: Program and Data Backup Backup Technology  Centralized backup (see Figure 10-3)  Centralized backup is problematic during attacks  Can be a single point of failure

5. 5 Figure 10-3: Backup Technology Administrator PC with Backup Device Data Mail Server File Server Directory Server

6. 6 Figure 10-2: Program and Data Backup Managing Backup  Frequency of Backup Full backup about once per week Daily partial backups to record changes Restore tapes in order recorded (full first, then partials)  Protecting Backup Media Storage off-site for safety (If stored on-site, disasters could destroy backup media) Store in fireproof containers until moved

7. 7 Figure 10-2: Program and Data Backup Managing Backup  Testing Restoration Is Mandatory  Retention Policies How long to retain backup tapes before reuse Need a policy that reflects importance of server and other factors  Journaling All data since last backup normally is lost in crashes Journaling: Store transactions as they occur on writeable CDs

8. 8 Figure 10-2: Program and Data Backup Managing Backup  Real-Time Database Duplication Maintain duplicate database at remote site Transmit data changes in real time to maintain consistency Prevents almost all data loss Expensive in terms of hardware and data communications

9. 9 Figure 10-4: Intrusion Detection Systems (IDSs) IDSs  Event logging in log files  Analysis of log file data  Alarms Too many false positives (false alarms) Too many false negatives (overlooked incidents)  Log files for retrospective analysis by humans

10. 10 Figure 10-4: Intrusion Detection Systems (IDSs) Elements of an IDS (Figure 10-5)  Event logging  Analysis method  Action  Management

11. 11 Figure 10-5: Elements of a Simple IDS Management: Configuration, Tuning Action: Alarms, Queries, Reports Analysis: Attack Signatures and Heuristics Logging (Data Collection): Individual Events are Time-Stamped Log is Flat File of Events

12. 12 Figure 10-4: Intrusion Detection Systems (IDSs) Distributed IDSs (Figure 10-6)  Managers  Agents  Distribution of functionality between agents and managers (analysis and action)

13. 13 Figure 10-6: Distributed IDS Log File Manager Host IDS Main Firewall Agent Site Internal Switch-Based Network IDS Log File Transfer in Batch Mode or Real Time Stand-Alone Network IDS Internet Connection FW Log

14. 14 Figure 10-4: Intrusion Detection Systems (IDSs) Distributed IDSs (Figure 10-6)  Batch versus Real-Time Data Transfer Batch mode: Every few minutes or hours; efficient Real-time: As events occur or shortly afterward; little or no data loss if attacker eliminates log file on agent’s computer

15. 15 Figure 10-4: Intrusion Detection Systems (IDSs) Distributed IDSs (Figure 10-6)  Secure manager-agent communication  Vendor’s automatic updates with secure communication Network IDSs (NIDSs)  Capture packets  Stand-alone NIDS collects data for only its portion of the network  Switch or router NIDSs can collect data on all ports

16. 16 Figure 10-4: Intrusion Detection Systems (IDSs) Network IDSs (NIDSs)  NIDS placement Between main firewall and internal or external network for relevant or all attacks At internal points to detect internal mischief  Weaknesses Blind spots in network where no NIDS data is collected Cannot filter encrypted packets

17. 17 Figure 10-4: Intrusion Detection Systems (IDSs) HOST IDSs  Protocol Stack Monitor (like NIDS) Collects the same type of information as a NIDS Collects data even if host is in NIDS blind spot Gives data specific to hosts; relevant for diagnosis Might see data after decryption

18. 18 Figure 10-4: Intrusion Detection Systems (IDSs) HOST IDSs  Operating System Monitors Collect data on operating system events Failed logins Attempt to change system executables Attempt to change system configuration (registry keys, etc.)

19. 19 Figure 10-4: Intrusion Detection Systems (IDSs) HOST IDSs  Application Monitors (Monitor Specific Applications) What users did in terms relevant to an application for easy interpretation Filtering input data for buffer overflows Signatures of application-specific attacks

20. 20 Figure 10-4: Intrusion Detection Systems (IDSs) Recap  Protocol monitor Protocol events (suspicious packets, etc.)  Operating monitor Operating system events (file changes, etc.)  Application monitor Application events (application commands issued)

21. 21 Figure 10-4: Intrusion Detection Systems (IDSs) HOST IDSs  Weaknesses of Host IDSs Limited Viewpoint; Only see events on one host If host is hacked, Host IDS can be attacked and disabled

22. 22 Figure 10-4: Intrusion Detection Systems (IDSs) HOST IDSs  Other host-based tools File integrity checker programs  Create baseline message digests for sensitive files  After an attack, recompute message digests  This tells which files were changed; indicates Trojan horses, etc.

23. 23 Figure 10-4: Intrusion Detection Systems (IDSs) HOST IDSs  Other host-based tools Operating system lockdown tools  Limits changes possible during attacks  Limits who may make crucial changes  May interfere with software functioning

24. 24 Figure 10-4: Intrusion Detection Systems (IDSs) Log Files  Flat files of time-stamped events  Individual logs  Integrated logs Aggregation of event logs from multiple IDS agents (Figure 10-7) Difficult to create because of format incompatibilities Time synchronization of IDS event logs is crucial (NTP) Can see suspicious patterns in a series of events across multiple devices

25. 25 Figure 10-7: Event Correlation for an Integrated Log File Sample Log File (Many Irrelevant Log Entries Not Shown) 1. 8:45:05. Packet from 1.15.3.6 to 60.3.4.5 (network IDS log entry) 2. 8:45:07. Host 60.3.4.5. Failed login attempt for account Lee (Host 60.3.4.5 log entry) 3. 8:45:08. Packet from 60.3.4.5 to 1.15.3.6 (network IDS log entry) 4. 8:49:10. Packet from 1.15.3.6 to 60.3.4.5 (network IDS log entry) 5. 8:49:12. Host 60.3.4.5. Failed login attempt for account Lee (Host 60.3.4.5 log entry) External Host Internal Host

26. 26 Figure 10-7: Event Correlation for an Integrated Log File Sample Log File (Many Irrelevant Log Entries Not Shown) 6. 8:49:13. Packet from 60.3.4.5 to 1.15.3.6 (network IDS log entry) 7. 8:52:07. Packet from 1.15.3.6 to 60.3.4.5 (network IDS log entry) 8. 8:52:09. Host 60.3.4.5. Successful login attempt for account Lee (Host 60.3.4.5 log entry) 9. 8:52:10. Packet from 60.3.4.5 to 1.15.3.6 (network IDS log entry) 10. 8:56:12. Packet from 60.3.4.5 to 123.28.5.210. TFTP request (network IDS log entry) 11. (no corresponding host log entry) 12. 8:56:28. Series of packets from 123.28.5.210 to 60.3.4.5. TFTP response (network IDS) 13. (no more host log entries)

27. 27 Figure 10-7: Event Correlation for an Integrated Log File Sample Log File (Many Irrelevant Log Entries Not Shown) 14. 9:03:17. Packet from 60.3.4.5 to 1.17.8.40. SMTP (network IDS) 15. 9:06:12. Packet from 60.3.4.5 to 1.40.22.8. SMTP (network IDS) 16. 9:10:12. Packet from 60.3.4.5 to 60.0.1.1. TCP SYN=1, Destination Port 80 (network IDS) 17. 9:10:13: Packet from 60.3.4.5 to 60.0.1.2. TCP SYN=1, Destination Port 80 (network IDS)

28. 28 Figure 10-4: Intrusion Detection Systems (IDSs) Analysis Methods  Static packet filtering  Stateful filtering  Full protocol decoding (filters based upon stage in dialogue—login, etc.)  Statistical analysis (frequency thresholds for reporting)  Anomaly detection (compares normal and current operation) Creates many false positives

29. 29 Figure 10-4: Intrusion Detection Systems (IDSs) Actions  Alarms  Interactive analysis Manual event inspection of raw log file Pattern retrieval  Reporting

30. 30 Figure 10-4: Intrusion Detection Systems (IDSs) Actions  Automated response Dangerous Special danger of attack-back (might be illegal; might hurt victim) Automation for clear attacks brings speed of response

31. 31 Figure 10-4: Intrusion Detection Systems (IDSs) Managing IDSs  Tuning for precision Too many false positives can overwhelm administrators, dull interest False negatives allow attacks to proceed unseen Tuning for false positives turns off unnecessary rules, reduces alarm levels of unlikely rules IDS might make tuning difficult

32. 32 Figure 10-4: Intrusion Detection Systems (IDSs) Managing IDSs  Updates Program, attack signatures must be updated periodically  Performance If processing speed cannot keep up with network traffic, some packets will not be examined  This can make IDSs useless during DoS attacks

33. 33 Figure 10-4: Intrusion Detection Systems (IDSs) Managing IDSs  Performance If memory requirements are too large, system might crash  Making logs smaller by saving them more frequently hurts longer-duration event correlation

34. 34 Figure 10-8: Intrusion Detection Processes For Major Incidents Organizational Preparation  Incident response procedures  Formation of a Computer Emergency Response Team (CERT) for major incidents  Communication procedures  Rehearsals

35. 35 Figure 10-8: Intrusion Detection Processes Initiation and Analysis  Initiation Report a potential incident Everyone must know how to report incidents  Analysis Confirm that the incident is real Determine its scope: Who is attacking; what are they doing

36. 36 Figure 10-8: Intrusion Detection Processes Containment  Disconnection of the system from the site network or the site network from the internet (damaging) Harmful, so must be done only with proper authorization  Black-holing the attacker (only works for a short time)  Continue to collect data (allows harm to continue) to understand the situation better

37. 37 Figure 10-8: Intrusion Detection Processes Recovery  Repair of running system (hard to do but keeps system operating with no data loss)  Restoration from backup tapes (loses data since last backup)  Reinstallation of operating system and applications Must have good configuration documentation before the incident

38. 38 Figure 10-8: Intrusion Detection Processes Punishment  Punishing employees is fairly easy  The decision to pursue prosecution Cost and effort Probable success if pursue (often attackers are minor) Loss of reputation

39. 39 Figure 10-8: Intrusion Detection Processes Punishment  Collecting and managing evidence Call the authorities for help Preserving evidence (the computer’s state changes rapidly)  Information on disk: Do immediate backup  Ephemeral information: Stored in RAM (who is logged in, etc.)

40. 40 Figure 10-8: Intrusion Detection Processes Punishment  Collecting and managing evidence Protecting evidence and documenting the chain of custody  Ask upstream ISPs for a trap and trace to identify the attacker

41. 41 Figure 10-8: Intrusion Detection Processes Communication  Warn affected people: Other departments, customers  Might need to communicate with the media; Only do so via public relations Protecting the System in the Future  Hacked system must be hardened  Especially important because many hackers will attack it in following weeks or months

42. 42 Figure 10-9: Business Continuity Planning Business Continuity Planning  A business continuity plan specifies how a company plans to restore core business operations when disasters occur

43. 43 Figure 10-9: Business Continuity Planning Business Process and Analysis  Identification of business processes and their interrelationships  Prioritizations of business processes Downtime tolerance (in the extreme, mean time to belly-up)  Resource needs (must be shifted during crises)

44. 44 Figure 10-9: Business Continuity Planning Communicating, Testing, and Updating the Plan  Testing (usually through walkthroughs) needed to find weaknesses  Updated frequently because business conditions change and businesses reorganize constantly Telephone numbers and contact numbers must be updated even more frequently than the plan as a whole

45. 45 Figure 10-10: Disaster Recovery Business Continuity Planning  A business continuity plan specifies how a company plans to restore core business operations when disasters occur Disaster Recovery  Disaster recovery looks specifically at the technical aspects of how a company can get back into operation using backup facilities

46. 46 Figure 10-10: Disaster Recovery Types of Backup Facilities  Hot sites Ready to run (power, HVAC, computers): Just add data Considerations: Rapid readiness versus high cost

47. 47 Figure 10-10: Disaster Recovery Types of Backup Facilities  Cold sites Building facilities, power, HVAC, communication to outside world only No computer equipment Might require too long to get operating

48. 48 Figure 10-10: Disaster Recovery Types of Backup Facilities  Site sharing Site sharing with a firm’s sites (problem of equipment compatibility and data synchronization) Site sharing across firms (potential problem of prioritization, sensitive actions)

49. 49 Figure 10-10: Disaster Recovery Types of Backup Facilities  Hosting Hosting company runs production server at its site Will continue production server operation if user firm’s site fails If hosting site goes down, there have to be contingencies

50. 50 Figure 10-10: Disaster Recovery Restoration of Data and Programs  Restoration from backup tapes: Need backup tapes at the remote recovery site  Real-time journaling (copying each transaction in real time)  Database replication

51. 51 Figure 10-10: Disaster Recovery Testing the Disaster Recovery Plan  The importance of testing: Find problems, work faster  Walkthroughs Go through steps in real time as group but do not take technical actions Fairly realistic Unable to catch subtle problems