Computer Security and Penetration

Testing

Chapter 18
Incident Handling
 Objectives
• Identify the necessity of incident handling
• Identify different types of incidents
• Recognize the various phases of incident handling
• Note the phases in preparing for incident handling

Computer Security and Penetration Testing 2

 Objectives (continued)
• Describe the steps in the identification of incidents
• Understand the need for incident reporting and
communication
• Describe the steps in removing a bug
• Identify the steps in recovering from an incident

Computer Security and Penetration Testing 3

 Objectives (continued)
• Identify the importance of following up after incident
handling
• Understand the process of tracking hackers
• List emergency steps that follow an incident

Computer Security and Penetration Testing 4

 Incident Handling
• An incident in a computer-security environment
– An event that tests the security solutions in place on a
network
• Or, in the case of a stand-alone machine, on that
machine itself
• Incidents take many forms
– The most common incidents that affect network
security are attacks from malicious code
• Any incident can be a serious threat to an
organization’s network

Computer Security and Penetration Testing 5

 Incident Handling (continued)
• Common events that may indicate an attack in
progress
– Execution of an unusual process using network
resources
– A pattern of many employee complaints of computer
malfunctions
– Resource requests may increase in an unusual way
– An authentication request by an IP address that is not
a part of the network

Computer Security and Penetration Testing 6

 Incident Handling (continued)
• To prevent the occurrence of such incidents, an
administrator must develop three documents:
– A predictive document describing the possible threats
to the network
– A “hot list” of what to prevent, what to patch, and what
to endure
– An incident response policy to ensure the smoothest
possible response to any threat

Computer Security and Penetration Testing 7

 Need for Incident Handling
• Reasons to develop effective incident handling
policies:
– Less confusion when an incident occurs
– Number of incidents is reduced when organizations
take preventative measures
– Organizations that handle and document incidents
may be less likely to have repeat occurrences
– Proper incident handling helps organizations assess
the strengths and weaknesses

Computer Security and Penetration Testing 8

Need for Incident Handling (continued)
• Reasons to develop effective incident handling
policies: (continued)
– Documented handling of incidents using industry
standard practices safeguard an organization from
potential legal ramifications related to the incidents
– Properly trained incident-response teams give upper
management time
• To prepare a factual and community-involved official
response to the aftermath of a security breach

Computer Security and Penetration Testing 9

 Types of Incidents
• Defaced Pages
– Means an attacker has hacked your Web server
– Results in loss of revenue, reputation, and morale of a
company
• Denial-of-Service Attacks
– Send a large quantity of packets to a server so that
resources are overutilized
• Servers can’t process legitimate requests sent by valid
users
– Three subcategories: buffer overflow conditions,
network flooding, and stack errors

Computer Security and Penetration Testing 10

 Types of Incidents (continued)
• Errors and Omissions
– Any intentional or unintentional misconfiguration of
any resource on the network
– Errors or omissions in the code base of any and all
applications and system software
– Do not always lead to incidents
• Fraud and Theft
– Can be performed either by traditional practices or by
using new tools
– Most incidents of fraud involve “inside” individuals

Computer Security and Penetration Testing 11

 Types of Incidents (continued)
• Intrusion
– Any attempt to gain unauthorized access to a network
– Intruder can be either an insider or an outsider
– Does not always lead to incidents
• Quiet Intrusion
– May be the most devastating for organizations
– Occurs when a hacker intrudes undetected into the
network of an organization
• And leaves little or no trace of his actions

Computer Security and Penetration Testing 12

 Types of Incidents (continued)
• Quiet Intrusion (continued)
– Categories
• Retrieving information
• Corrupting data
• Creating or identifying back doors
• Malicious Code
– Used for destructive purposes only
– Worms, viruses, and Trojan horse programs
– Designed to enter the network unnoticed
– Many are designed to replicate and distribute themselves
automatically

Computer Security and Penetration Testing 13

 Phases of Incident Handling
• The key phases of incident handling are:
– Preparation
– Identification
– Reporting (Logging)
– Setting urgency
– Setting priority
– Eradication
– Recovery
– Postmortem

Computer Security and Penetration Testing 14

Computer Security and Penetration Testing 15
 Preparation for Incident Handling
• Phases include
– Knowing the resources and their vulnerabilities
– Baselining the network to discover all the assets
involved
– Developing systems and policies
• Including creating the incident-response team

Computer Security and Penetration Testing 16

 Preparation for Incident Handling
(continued)
• Planning an Incident-Handling Policy
– All organizations should devise a formal incident-
handling policy with the following sections
• Purpose and sponsor
• Network and system details
• Policy
• Procedures
• Responsible organizations
• History
• Organization should identify the skill sets required to
address the expected range of vulnerabilities
Computer Security and Penetration Testing 17
 Incident-Handling Team
• Responsible for identifying incidents and responding
to them in the most effective manner possible
• Skills represented in an emergency response team
cross department lines
• Minimally, the team needs
– Somebody with experience and skill at identifying
attack signatures and responses
– Somebody with enough clout within the organization
– Somebody who can systematize communications
within the team and with outside entities

Computer Security and Penetration Testing 18

 Incident-Handling Team (continued)

• Incident-handling teams should practice exercises

and drills
• Team should also be trained to retain the evidence
of an incident
• The more efficient and effective the incident-
handling team is
– The lower the losses in productivity, time, money, and
labor

Computer Security and Penetration Testing 19

 Identifying Incidents

• The first step in an incident response is

– To identify whether an incident is actually occurring
• A properly prepared network infrastructure has IDS
and firewalls in place
– Applications provide the administrators with alert
messages
• Administrator has to deal with false positives and
false negatives

Computer Security and Penetration Testing 20

 Identifying Incidents (continued)
• Steps for ascertaining whether there has been an
attack
– Administrator confirms that the issue is an actual
security incident
– Network services that may have been affected must be
identified
– Appropriate historical documents and current
vulnerability alerts ought to be reviewed
– Incident-response team performs forensics to determine
the type of incident
• And the possible responses

Computer Security and Penetration Testing 21

 Identifying Incidents (continued)

• Security experts use the following tools to make

their determinations:
– Approach to incident detection
– Assessing the severity of the incident
– Risk assessment
– Systems and network logging

Computer Security and Penetration Testing 22

 Approach to Incident Detection
• Can seriously impact the number and kinds of
incidents that are detectable
• First step is called watching
– Important to monitor a network for unusual activity
• Next step is checking details of a possible incident
• Last step is taking action
• Specific procedures to ensure that incidents are
detected prior to damaging a network

Computer Security and Penetration Testing 23

 Approach to Incident Detection
(continued)
• A large part of the detection process is ensuring that
proper monitoring tools are available on the network
• Confidential files must be stored in a secure area
• Network administrator must learn to read the system
logs of the resources on the network
– And look for possible attacks

Computer Security and Penetration Testing 24

 Approach to Incident Detection
(continued)
• Detection Tools
– Installed on the network to make early detection
possible
– Types
• System-monitoring tools
• Network analysis tools
• User-analysis tools
• Log-analysis tools

Computer Security and Penetration Testing 25

 Assessing the Severity of an Incident

• The scale of response changes depending on the

scale of the problem
• Potential damage from an attack may include
monetary loss
– But it can also result in a loss of productivity,
company standing, or customer trust
• Severity is also determined by the number of
network resources involved
– Both directly and indirectly

Computer Security and Penetration Testing 26

 Assessing the Severity of an Incident
(continued)
• Many types of attacks are capable of replicating
themselves
– Make it difficult to determine the number of computers
that may have been affected
– Are often considered high-severity attacks
• Severity level may also be affected by the motive of
the attacker

Computer Security and Penetration Testing 27

 Risk Assessment

• Ongoing risk assessment is done for each incident

– To determine whether to use the affected computer
on the network
• Options for dealing with the affected computer:
– Shut it down, disconnect it from the network, or
continue incident-handling operations
• And enable the computer to remain on the network

Computer Security and Penetration Testing 28

 Systems and Network Logging

• When an incident is discovered

– The first sources for information are the log files on
the affected machine
• And general network traffic logs from routers and
switches
• UNIX and Linux Log Files
– syslog
– auth.log
– checksecurity.log
– mail.err, mail.log, and mail.warn
Computer Security and Penetration Testing 29
 Systems and Network Logging
(continued)
• Windows Log Files
– To view Windows system logs, you open the GUI
Event Viewer
• In the Administration Tools control panel
• Additionally, a check needs to be performed for
suspicious files

Computer Security and Penetration Testing 30

 Reporting and Communicating
Incidents
• All users on the network should know how to report
a possible incident
– Even minor incidents should be noted
• The appropriate people to be notified should be
listed in an organization’s security policy
• Incidents must be reported in a uniform way
– Automated intranet forms can be used

Computer Security and Penetration Testing 31

 Reporting the Incident

• The following experts may need to be informed:

– System administrator
– Senior management
– Legal counsel
– System and network users
– Human-resource department
– Public-relations department
– Federal, state, or local law-enforcement agencies

Computer Security and Penetration Testing 32

 Reporting the Incident (continued)

• Incident should be reported in direct and clear

language outlining the facts
• All information of the incident should be reported
• Incident should be reported with neutral tone
– Using nontechnical language in reports to upper
management
• The hacked resource is not the best tool for
spreading information about the attack

Computer Security and Penetration Testing 33

 Communicating the Incident

• Refers to the official communication with the

individuals fixing the incident
– Different from incident reporting
• Includes the following tasks listed below:
– Identifying people with skills that make them useful in
handling the incident
– Determining how much information should be
communicated to the relevant experts
– Determining the amount of responsibility to be
delegated to individuals
Computer Security and Penetration Testing 34
 Communicating the Incident
(continued)
• Includes the following tasks listed below: (continued)
– Determining the mode of communication, and
securing communications
– Identifying an incident-handling team leader to be
responsible for bringing the incident to successful
closure

Computer Security and Penetration Testing 35

 Eradicating the Bug
• One of the key steps while eradicating bugs is to
create backup copies of files
• Making backup copies refers to taking snapshots of
the system to store and preserve
– Helps tracking the hacker after the incident
• Following information must be retrieved:
– A report of the process status with the parent process
ID of each process
– A report of all the open connections
– A backup copy of the temp directory

Computer Security and Penetration Testing 36

 Eradicating the Bug (continued)

• In Linux, you may use the following archival

commands to make backup copies
– tar
– dump
– dd

Computer Security and Penetration Testing 37

 Correcting the Root Problem

• To properly clear the network of problems caused

by the incident
– An analysis should be performed
– Knowledge obtained from previous incidents should
be consulted
• Accuracy of analysis of the problem is important
• Important to remove all traces of the incident from
the network

Computer Security and Penetration Testing 38

 Identifying and Implementing the
Steps to Fix the Problem
• Virus and Worm Attacks
– Isolate the computers that have been affected
– Disconnect the affected computers from the network
to stop the virus or worm from spreading
• Hacker or Cracker Attacks
– Hacker attack may occur in three different ways:
• Activating a new session, terminating an active session,
or hijacking an active session
– An unskilled hacker’s actions can be tracked by
viewing the log files

Computer Security and Penetration Testing 39

 Identifying and Implementing the
Steps to Fix the Problem (continued)
• Hacker or Cracker Attacks (continued)
– If the hacker has ended the session
• The first step for the incident-handling team is to
identify the part of the network that was affected
– The best chance to catch a cracker is when she is
working through an open session
• Denial-of-Service Attacks
– Identify areas that would be affected if the attack is
successful
– Determine the attack method used by the hacker

Computer Security and Penetration Testing 40

 Identifying and Implementing the
Steps to Fix the Problem (continued)
• Denial-of-Service Attacks (continued)
– Locate a point where the attack can be stopped that
will cause minimal disruption
– Implement the procedures that need to be taken to
block the attack
– Reestablish normal network conditions
– Analyze any loopholes in network security
– Identify permanent solutions to cover security
loopholes
– Implement the chosen solutions
Computer Security and Penetration Testing 41
 Recovering from Incidents

• After an incident, recovery without permanent

damage is the goal
• The network should be made functional so that the
organization will face no further revenue loss

Computer Security and Penetration Testing 42

 Phases of Recovery

• Reinstallation
– All infected computers must be either reinstalled or
fixed with a patch
– All the computers that were not infected should be
patched as well

Computer Security and Penetration Testing 43

 Phases of Recovery (continued)

• Reinstallation (continued)
– During reinstallation, check for the following:
• Verify that no traces of the incident are left
• Implement security checks on the network so the
problem does not arise again
• Change the administrative password and users’
passwords
• Make a backup copy of the newly installed settings so
that if a hacker attacks again, the process of reinstalling
is faster

Computer Security and Penetration Testing 44

 Phases of Recovery (continued)

• Reauthentication
– It may be necessary to disable all accounts and then
reenable the accounts
• Pruning the unknown or unused accounts
• Scanning
– Scanning checks should be performed after the
repair, reinstallation, and reauthentication
• Resuming work
– Users may resume their work after all steps have
been completed
Computer Security and Penetration Testing 45
 Postmortem

• After the problem has been fixed

– The next step is to derive lessons that can be
implemented in the future
• Teams must analyze the incident to identify the
possible root cause of the problem
– Identifies the weak areas in network security
– Implies a roadmap to the next continuing vulnerability
to be fixed

Computer Security and Penetration Testing 46

 Identifying the Root Cause of the
Problem
• Incident-handling teams need to perform this step in
a predetermined way
– Teams must ask how and why a problem occurred
• Some of the questions to be addressed
– How did the hacker manage to hack into the network
in the first place?
– How can the network have more security to avoid
more incidents in the future?
– What tools and patches were missing that permitted
the hacker to detect a loophole in the network?
Computer Security and Penetration Testing 47
 Identifying the Root Cause of the
Problem (continued)
• Some of the questions to be addressed (continued)
– What processes or technology could have helped the
incident-handling team fix the issue quickly and
efficiently?
– Are there any changes that need to be made in the
incident-response policy?
– Is there a better network design that will not allow the
hacker to perform operations, even if the hacker
manages to break in?

Computer Security and Penetration Testing 48

Identifying Short-Term and Long-Term
Changes
• After the analysis of the root cause has been
completed
– An action list should be developed
• A logical progression of economically feasible steps
should be generated and then converted into action
• Tasks for the incident-handling teams should be
provided to only the members of the incident-
handling teams

Computer Security and Penetration Testing 49

 Identifying Actions for Any
Unpredictable Incident
• Knowledge obtained from the root cause analysis
(RCA) should be implemented
– In areas that were affected by the previous incident
as well as other areas vulnerable to attacks

Computer Security and Penetration Testing 50

 Implementing the Learning

• The last step of the postmortem phase

– The people involved implement the learning derived
from the incident

Computer Security and Penetration Testing 51

 Tracking Hackers

• Unethical hackers are often educated

– Hackers can be roughly divided into two categories:
amateurs and experts
• Tracking hackers requires patience and coordination
– And support from people and organizations across
the world
– Combination of both technology and psychology
• Two approaches to tracking hackers: “generic to
specific” and “specific to generic to specific”

Computer Security and Penetration Testing 52

 Generic to Specific

• Data whose outline is broad in the beginning

– Yet, with the use of evidence and logic, the output is
specific
• Initially, the hacker-tracking team knows only that an
attack was performed
• Later they discover the details about the technology
used
• In the end, the team may be able to locate the
individual

Computer Security and Penetration Testing 53

 Specific to Generic to Specific

• Information collated before tracking the hacker is

very specific
– And leads to a generic analysis about the hacker
• Log files, ISP server data, and assessments of
existing vulnerabilities
– Provide information regarding the hacker

Computer Security and Penetration Testing 54

 Specific to Generic to Specific
(continued)
• Generic steps to trace a hacker:
– Analyze log files for signatures regarding the hacker
– Analyze the attacker’s possible motivation based on
the results of the hack
– Divide timelines
– Define geographical sectors
– Identify any links that transmitted similar data
– Pinpoint the location of the hacker

Computer Security and Penetration Testing 55

 Emergency Steps

• The following is an emergency guide for use in case

of an attack

Computer Security and Penetration Testing 56

 Important Emergency Steps

• Emergency steps include:

– Stay calm
– Take accurate and comprehensive notes
– Notify the relevant set of people
– Confirm that it is an incident and not an event
– Use secure modes of communication
– Avoid spreading the problem
– Make backups

Computer Security and Penetration Testing 57

 Summary
• An incident in a computer security environment is an
event that tests the security solutions in place
• Most common incidents are attacks from malicious code
and inside jobs by employees, contractors, and
consultants
• Damage from incidents could range from a small
disruption of work to a major network outage
• Be aware of common events may point to an attack in
progress
• To prevent and properly respond to incidents, an
administrator must develop a predictive document

Computer Security and Penetration Testing 58

 Summary (continued)
• Every organization has a unique mix of resources and
vulnerabilities
• The key phases of incident handling are preparation,
identification, reporting (logging), setting urgency,
setting priority, eradication, recovery, and postmortem
• All users on a network should know how to report a
possible incident
• When eradicating bugs, incident-handling teams need
to create backup copies of files by taking snapshots
of the system

Computer Security and Penetration Testing 59

 Summary (continued)
• After an incident, recovery without permanent
damage is the goal
• The four phases of recovery from incidents are
reinstallation, reauthentication, scanning to check
eradication, and resuming work
• Important to learn from successes and from mistakes
• Two approaches to tracking hackers: “generic to
specific” and “specific to generic to specific”
• Know how to handle an emergency

Computer Security and Penetration Testing 60