Incident Response Chapter 10

Incident Response Chapter 10
Panko, Corporate Computer and Network Security Copyright 2004 Prentice-Hall

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

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 Most important actions occur before the incident happens Backup, training, rehearsals, etc.

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

Figure 10-3: Backup Technology
Directory Server Administrator PC with Backup Device Data Mail Server File 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)

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

Managing Backup Retention Policies How long to retain backup tapes before reuse Need a policy that reflects importance of server and other factors

Managing Backup Journaling All data since last backup normally is lost in crashes Journaling: Store transactions as they occur on writeable CDs

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

Figure 10-4: Intrusion Detection Systems (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) Log files for retrospective analysis by humans

Elements of an IDS (Figure 10-5) Event logging Analysis method Action Management

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

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

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

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

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

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.)

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

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)

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

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.

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

Log Files Flat files of time-stamped events Individual logs only see what the host, switch, or router can see

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

Figure 10-7: Event Correlation for an Integrated Log File
Sample Log File (Many Irrelevant Log Entries Not Shown) External Host 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)

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)

Sample Log File (Many Irrelevant Log Entries Not Shown) 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)

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)

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

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 longer- duration events

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

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

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

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

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

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.)

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 After the incident, reflect on what you learned and change your intrusion response method accordingly New: Should have been in the book

Communication Warn affected people: Other departments, customers Might need to communicate with the media; Only do so via public relations

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
A business continuity plan specifies how a company plans to restore core business operations when disasters occur

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)

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

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

Types of Backup Facilities Hot sites Ready to run (power, HVAC, computers): Just add data Considerations: Rapid readiness versus high cost

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

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)

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

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

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

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

Topics Covered Incidents Happen Incident Severity
Protections sometimes break down 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

Topics Covered Speed is of the essence Backup technology
Prior actions are the key to success 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

Topics Covered Backup Protect backup media with off-site storage
Restoration testing is mandatory Need retention policy Journaling provides constant backup Real-time backup to another site is best but expensive

Topics Covered Intrusion Detection Systems (IDSs)
Detect and log attacks Give warnings if attack is sufficiently severe

Topics Covered IDS Elements Action: Alarms, Queries, Reports
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

Topics Covered 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

Topics Covered 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

Topics Covered 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

Topics Covered 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) Many false positives (false alarms)

Topics Cover 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

Topics Covered Response
Detect attacks with IDSs or odd application behavior Classify by severity False alarms and minor incidents are handled by the on-duty staff

Topics Covered Response to Major Incident CSIRT
Not just IT and security employees Corporate counsel, public relations, etc. Must rehears for effectiveness and speed

Topics Covered 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

Topics Covered 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

Topics Covered Disaster Recovery Hot sites Cold sites
Site sharing within and between firms Hosting

Topics Covered Business Continuity Analysis Business Process Analysis
Identification of business processes and their interrelationships Prioritizations of business processes Resource needs (must be shifted during crises)

Topics Covered Testing Response Plans Walkthroughs Live testing

Incident Response Chapter 10

Similar presentations

Presentation on theme: "Incident Response Chapter 10"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Incident Response Chapter 10

Similar presentations

Presentation on theme: "Incident Response Chapter 10"— Presentation transcript:

Similar presentations

About project

Feedback