1 Incident Response Chapter 10 Copyright 2003 Prentice-Hall.

1

Incident Response

Chapter 10

Copyright 2003 Prentice-Hall

2

Figure 10-1: Incident Response

Incidents Happen Protections sometimes break down

Incident Severity False alarms

Minor incidents

Major incidents

Disasters

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

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

Figure 10-3: Backup Technology

AdministratorPC with BackupDevice Data

MailServer

File Server

DirectoryServer

6


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


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


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

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


Elements of an IDS (Figure 10-5)

Event logging

Analysis method

Action

Management

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


Distributed IDSs (Figure 10-6)

Managers

Agents

Distribution of functionality between agents and managers (analysis and action)

13

Figure 10-6: Distributed IDS

Log File

ManagerHost IDS

MainFirewall

Agent

AgentAgent

AgentSite

InternalSwitch-BasedNetwork IDS

Log FileTransfer in

Batch Mode orReal Time

Stand-AloneNetwork IDS

InternetConnection

FW Log

14



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



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


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


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


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


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


Recap

Protocol monitor

Protocol events (suspicious packets, etc.)

Operating monitor

Operating system events (file changes, etc.)

Application monitor

Application events (application commands issued)

21


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


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


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


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

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)



5. 8:49:12. Host 60.3.4.5. Failed login attempt for account Lee(Host 60.3.4.5 log entry)

ExternalHost

InternalHost

26



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



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


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


Actions

Alarms

Interactive analysis

Manual event inspection of raw log file

Pattern retrieval

Reporting

30


Actions Automated response

Dangerous

Special danger of attack-back (might be illegal; might hurt victim)

Automation for clear attacks brings speed of response

31


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


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


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

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


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


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


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


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


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


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


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

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


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


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

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


Types of Backup Facilities

Hot sites

Ready to run (power, HVAC, computers): Just add data

Considerations: Rapid readiness versus high cost

47



Cold sites

Building facilities, power, HVAC, communication to outside world only

No computer equipment

Might require too long to get operating

48



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



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


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


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

Date post:	25-Dec-2015
Category:	Documents
Upload:	priscilla-johnston
View:	217 times
Download:	3 times

1 Incident Response Chapter 10 Copyright 2003 Prentice-Hall.

Documents