Incident Response. Figure 10-1: Incident Response. Figure 10-2: Program and Data Backup. Figure 10-1: Incident Response. Figure 10-2: Program and Data

Transcription

1 Figure 10-1: Incident Response Incident Response Chapter 10 Panko, Corporate Computer and Network Security Copyright 2004 Prentice-Hall Incidents Happen Protections sometimes break down Incident Severity False alarms Minor incidents Major incidents Disasters 2 Figure 10-1: Incident Response Speed is of the Essence Attackers must be stopped quickly to minimize damage The need for prior preparation for speed and correctness during incidents 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 Most important actions occur before the incident happens Backup, training, rehearsals, etc. 3 4 Figure 10-3: Backup Technology Figure 10-2: Program and Data Backup Administrator PC with Backup Device Data Mail Server Directory Server 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 in order recorded) File Server 5 6

2 Figure 10-2: Program and Data Backup Managing Backup Protecting Backup Media Storage off-site for safety (If stored on-site, disasters could destroy backup media) Store in fireproof containers until moved Testing Restoration Is Mandatory No surprises during a crisis Figure 10-2: Program and Data Backup Managing Backup Retention Policies How long to retain backup tapes before reuse Need a policy that reflects importance of server and other factors 7 8 Figure 10-2: Program and Data Backup Managing Backup Journaling All data since last backup normally is lost in crashes Journaling: Store transactions as they occur on writeable CDs 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 10 IDSs Identify apparent attacks Event logging in log files for analysis Problems with Accuracy Too many false positives (false alarms) Too many false negatives (overlooked incidents) Elements of an IDS (Figure 10-5) Event logging Analysis method Action Management Log files for retrospective analysis by humans 11 12

3 Figure 10-5: Elements of a Simple IDS Figure 10-6: Distributed 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 13 Manager Agent Log File Internal Switch-Based Network IDS Agent Agent Log File Transfer in Batch Mode or Real Time Stand-Alone Network IDS Host IDS Agent FW Log Site Internet Connection Main Firewall 14 Distributed IDSs (Figure 10-6) Manager Agents Distribution of functionality between agents and managers (analysis and action) 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 Distributed IDSs (Figure 10-6) Must have secure manager-agent communication Must have automatic vendor updates with secure communication 17 Network IDSs (NIDSs) Located at crucial network nodes (switches, routers, etc.) Capture packets Stand-alone NIDS collects data for only its portion of the network Switch or router NIDSs can collect data on all ports Collect data to and from many hosts Only see traffic passing through their locations 18

4 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 Network IDSs (NIDSs) Weaknesses Blind spots in network where no NIDS data is collected Cannot filter encrypted packets HOST IDSs Located on individual host computers Protocol Stack Monitor (like NIDS) Collects the same type of information as a NIDS but only for that host Works even if host is in NIDS blind spot Gives data specific to hosts; relevant for diagnosis Might see data after decryption 21 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.) 22 HOST IDSs Application Monitors (Monitor Specific Applications) What users did in terms relevant to an application for easy interpretation (e.g., update a particular database record) Filtering input data for buffer overflows Signatures of application-specific attacks 23 Recap: Host IDSs Protocol monitor Protocol events (suspicious packets, etc.) Operating monitor Operating system events (file changes, etc.) Application monitor Application events (application commands issued) 24

5 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 25 HOST IDSs Other host-based tools File integrity checker programs Create baseline message digests for sensitive files After an attack, recompute message digests for these files This tells which files were changed; indicates Trojan horses, etc. 26 HOST IDSs Other host-based tools Operating system lockdown tools Limits changes possible during attacks Log Files Flat files of time-stamped events Individual logs only see what the host, switch, or router can see Limits who may make crucial changes May interfere with software functioning Figure 10-7: Event Correlation for an Integrated Log File Log Files 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 (Network Time Protocol or NTP) Can see suspicious patterns in a series of events across multiple devices 29 External Host Sample Log File (Many Irrelevant Log Entries Not Shown) Internal Host 1. 8:45:05. Packet from to (network IDS log entry) 2. 8:45:07. Host Failed login attempt for account Lee (Host log entry) 3. 8:45:08. Packet from to (network IDS log entry) 4. 8:49:10. Packet from to (network IDS log entry) 30

6 Figure 10-7: Event Correlation for an Integrated Log File Sample Log File (Many Irrelevant Log Entries Not Shown) Figure 10-7: Event Correlation for an Integrated Log File Sample Log File (Many Irrelevant Log Entries Not Shown) 5. 8:49:12. Host Failed login attempt for account Lee (Host log entry) 6. 8:49:13. Packet from to (network IDS log entry) 7. 8:52:07. Packet from to (network IDS log entry) 8. 8:52:09. Host Successful login attempt for account Lee (Host log entry) 9. 8:52:10. Packet from to (network IDS log entry) 10. 8:56:12. Packet from to TFTP request (network IDS log entry) Figure 10-7: Event Correlation for an Integrated Log File Sample Log File (Many Irrelevant Log Entries Not Shown) 11. (no corresponding host log entry) 12. 8:56:28. Series of packets from to TFTP response (network IDS) 13. (no more host log entries) 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 to SMTP (network IDS) 15. 9:06:12. Packet from to SMTP (network IDS) 16. 9:10:12. Packet from to TCP SYN=1, Destination Port 80 (network IDS) 17. 9:10:13: Packet from to TCP SYN=1, Destination Port 80 (network IDS) Analysis Methods Static packet filtering Stateful filtering Full protocol decoding (filters based upon stage in dialogue login, etc.) Analysis Methods Statistical analysis (frequency thresholds for reporting) Anomaly detection (compares normal and current operation) Creates many false positives 35 36

7 Actions Alarms Interactive analysis Manual event inspection of raw log file Pattern retrieval Reporting Actions Automated response Dangerous Special danger of attack-back (might be illegal; might hurt victim) Automation for clear attacks brings speed of response 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 (such as Windows vulnerabilities on Unix servers), reduces alarm levels of unlikely rules Managing IDSs Updates Program, attack signatures must be updated periodically Managing IDSs Performance If processing speed cannot keep up with network traffic, some packets will not be examined This can make IDSs that work well most of the time useless during DoS attacks Managing IDSs Performance If memory requirements are too large, system might crash But making logs smaller to fit more easily onto disks can hurt correlation for longerduration events 41 42

8 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 AKA computer security incident response teams (CSIRTs) Communication procedures Rehearsals 43 Figure 10-8: Intrusion Response 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 44 Figure 10-8: Intrusion Response 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) Sometimes, continue to collect data (allows harm to continue) to understand the situation better 45 Figure 10-8: Intrusion Response 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 46 Figure 10-8: Intrusion Response Punishment Punishing employees is fairly easy given employment laws, unless the firm is unioninzed Pursue prosecution? Cost and effort Probable success if pursue (often attackers are minor) Loss of reputation 47 Figure 10-8: Intrusion Response Punishment Collecting and managing evidence Call the authorities for help Preserving evidence (the computer s state changes rapidly) Information on disk: Do immediate backup using forensics disk copier only Ephemeral information: Stored in RAM (who is logged in, etc.) 48

9 Figure 10-8: Intrusion Response 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 Post-Mortem New: Should have been in the book After the incident, reflect on what you learned and change your intrusion response method accordingly Figure 10-8: Intrusion Response Communication Warn affected people: Other departments, customers Might need to communicate with the media; Only do so via public relations Figure 10-8: Intrusion Response Protecting the System After the Attack Hacked system must be hardened Especially important because many hackers will attack it in following weeks or months 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 Figure 10-9: Business Continuity Planning Business Process 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) 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, addresses, etc. must be updated even more frequently than the plan as a whole 53 54

10 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 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 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 Figure 10-10: Disaster Recovery Types of Backup Facilities Site sharing Site sharing across firms (potential problem of prioritization, sensitive actions) Site sharing with a firm s sites (problem of equipment compatibility and data synchronization) 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 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 If hosting site goes down, there have to be contingencies 59 60

11 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 Figure 10-10: Disaster Recovery Testing the Disaster Recovery Plan Live testing Full process is followed, including technical steps (data restoration, etc.) High cost Realistic and can catch subtle errors Incidents Happen Protections sometimes break down Speed is of the essence Prior actions are the key to success Incident Severity False alarms Minor incidents handled by the on-duty staff Major incidents handled by CSIRT Disasters handled by disaster response and business continuity teams 63 Practice is needed for speed of response Backup technology Centralized backup is efficient unreliable during incidents Full backups once a week Partial backups nightly Restore full than partials in order created 64 Backup Intrusion Detection Protect backup media with off-site storage Detect and log attacks Restoration testing is mandatory Give warnings if attack is sufficiently severe Need retention policy Journaling provides constant backup Real-time backup to another site is best but expensive 65 66

12 IDS Elements 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 67 Distributed IDSs Multiple host IDSs and network IDSs with agents Must send all data to the manager Batch mode Real-time mode does not allow attackers to remove all traces Must do event correlation to understand events Time synchronization is crucial Must have secure communication and updates 68 Network IDSs (NIDSs) Located at crucial network nodes (switches, routers, etc.) Stand-alone NIDS collects data for only its portion of the network Switch or router NIDSs can collect data on all ports Collect data to and from many hosts Only see traffic passing through their locations Cannot filter encrypted traffic At border or at internal locations 69 HOST IDSs Located on individual host computers Technologies Protocol Stack Monitor (like NIDS) Operating System Monitors Application Monitors (for Specific Applications) Only see one host If the host is hacked, they are compromised Work even if no NIDS sees the traffic 70 Topics Cover Analysis Methods Static packet filtering Stateful filtering Full protocol decoding (filters based upon stage in dialogue login, etc.) Statistical analysis (frequency thresholds for reporting) IDS Many false positives Tuning can reduce the problem Performance is crucial Must be able to filter all packets, even during attacks that drastically increase traffic Anomaly detection (compares normal and current operation) Many false positives (false alarms) 71 72

13 Response Detect attacks with IDSs or odd application behavior Classify by severity False alarms and minor incidents are handled by the on-duty staff Response to Major Incident CSIRT Not just IT and security employees Corporate counsel, public relations, etc. Must rehears for effectiveness and speed Response to Major Incident Phases Initialization Analysis Stopping the attack Repair Ranges from backup to complete reinstallation of the server Punishment? Easier for employees than external attackers 75 Response to Disasters Disasters Both natural and due to disasters Two Aspects Disaster response: get IT systems back online Business continuity response: get business started again Both teams need to practice 76 Disaster Recovery Hot sites Cold sites Site sharing within and between firms Hosting Business Continuity Analysis Business Process Analysis Identification of business processes and their interrelationships Prioritizations of business processes Resource needs (must be shifted during crises) 77 78

14 Testing Response Plans Walkthroughs Live testing 79