Professional Documents
Culture Documents
<date>
<date>
Page 2
<date>
Table of Contents
1
2
3
4
5
6
7
Introduction..................................................................................................................1
Scope............................................................................................................................2
Key Definitions............................................................................................................3
Classifying an Event....................................................................................................5
4.1
Possible Events....................................................................................................5
Incident response framework.......................................................................................7
Incident Response Team..............................................................................................8
Incident Response Plan Structure..............................................................................10
7.1
Identification......................................................................................................10
7.2
Assessment........................................................................................................13
7.3
Containment.......................................................................................................13
7.3.1
Checking other systems on the network....................................................14
7.3.2
Checkingforsystemsinvolvedoraffectedatremotesites.......................14
7.4
Eradication.........................................................................................................15
7.5
Recovery............................................................................................................15
7.6
Follow-up...........................................................................................................15
7.7
Documentation...................................................................................................16
7.7.1
Revising policies, processes, standards, and procedures...........................17
Documents and Forms...............................................................................................18
8.1
Contact Information...........................................................................................18
8.2
Incident Handling Form.....................................................................................19
8.3
Communication Log..........................................................................................21
8.4
Network Component, System, and Application Sensitivity..............................24
Page i
<date>
1 INTRODUCTION
This document provides relevant information and steps required to identify, eradicate and
recover if an unforeseen security event were to occur to any system that falls under
<$regulation> or can adversely impact business processes.
While security incidents are not necessarily to be expected, the response to them needs to
be formally documented before a security incident occurs. Requirements dictate <x>
Energy to have an Incident Response Program that specifically addresses the way in
which the <x> Energy will handle unauthorized incidents.
Note that this document is required by <regulation entity> and therefore depends heavily
on their suggested formats and definitions.
Page 1
<date>
2 SCOPE
This document implements the general principles established by <x> Energy regarding
the specific processes that <x> Energy personnel must follow when responding to an
incident.
This document is meant to provide <x> Energy personnel with a specific and systematic
approach for dealing with computer security incidents. This document has been
developed to establish whether an incident has occurred, what data has been accessed
inappropriately, who needs to be contacted, and how to recover. Sub-goals are below.
1. Confirm or dispel the incident.
2. Determine the level of threat from an incident.
3. Determine the appropriate response to the incident, including who and when
to notify.
4. Direct actions on the containment, eradication, and recovery from the
incident.
5. Promote the accumulation of accurate information.
6. Establish controls for proper retrieval and handling of evidence.
7. Minimize disruptions to business functions and network operations.
8. Allow for legal or civil recriminations against perpetrators.
9. Provide accurate reports and useful recommendations.
Page 2
<date>
3 KEY DEFINITIONS
AssessmentAfter the identification phase, an initial assessment should be performed to
confirm the existence of the incident. The assessment should include determining the
scope, the impact of the incident, and the extent of the damage caused by the incident.
ContainmentContainment of the incident is necessary to minimize and isolate the
damage incurred.
EradicationIn order to successfully eliminate the possibility of the incident
reoccurring again, the IRT needs to determine the cause of the incident that resulted in the
system compromise.
EventAn occurrence that has not been verified as a Security Incident.
Follow-upAs a follow-up, a post-mortem analysis of the compromised system should
be performed to understand the weaknesses that resulted in the incident and other
potential vulnerable areas. In the event that <x> Energy is considering legal action
against the perpetrator, forensic specialists and/or law enforcement agencies should be
engaged to ensure that digital evidence are accumulated and preserved in a manner that is
consistent with a legal follow-up.
IdentificationThe occurrence of an incident is unpredictable. An anomaly in the
system behavior may indicate an incident or configuration errors. Hence, identifying an
incident amidst routine daily operations is not always an easy task.
PreparationIn any Incident Response Plan, it is essential to form an Incident
Response Team (IRT) prior to other tasks. The role of the team is to promptly handle an
incident so that it will have minimal impact to the business operation. The team is formed
of members from various functional roles in <x> Energy.
RecoveryThe recovery phase restores operations of the compromised system to
facilitate the resumption of normal business operations. Prior to the resumption process, a
validation check should be performed to ensure that the system is secured against any
repeated incidents. Furthermore, the system should be placed under surveillance to ensure
that if the perpetrator returns, unauthorized attempts may be detected early.
Security IncidentAn irregular or adverse event that occurs within any part of <x>
Energys information systems infrastructure. These include (but are not limited to)
Page 3
<date>
Page 4
<date>
4 CLASSIFYING AN EVENT
The below categories will be used within <x> Energy.
Critical - These incidents can potentially affect human life or cause irreversible loss of
company resources; they also include for example, loss of large quantities of customer
data.
High - These incidents may affect the integrity or confidentiality of data, which may
result in direct loss of business and/or reputation, e.g. loss of large quantities of account
numbers and expiry dates.
Medium - These incidents typically affect the availability of information, but not data
integrity, e.g. acquiring network failures.
Low - These incidents may affect the confidentiality, integrity or availability of data
however no loss has occurred. <x> Energy should already be secured against these
incidents but constant surveillance may still be necessary to detect early signs of
unauthorized activities.
Insignificant - These incidents pose negligible risk to <x> Energy.
<$regulatory body> must be notified of any Critical or High
incidents.
Page 5
<date>
Page 6
<date>
Page 7
<date>
Contact Information
Information
Services
Manager
Information
Services
Administrator
Network
Administrator
Database
Administrator
CFO/CIO
Applications
Manager
Manager of Store
Services
Priority and
Responsibilities
Oversee incident response
process.
Perform response recovery
with systems.
Perform response recovery
with network components.
Perform response recovery
with databases systems.
Public Relations and
Incident Reporting Official
Perform response recovery
with application
components.
Perform response recovery
with POS components.
New Process
Development
Manager
Physical Security
Officer
Remote Sites:
Location Manager:
Incident Response Plan
Page 8
Contacts
Primary:
Alternate:
Office Phone
<date>
Pager
Page 9
<date>
Figure 1. IR Framework
* The sections below address each aspect of the framework.
7.1 Identification
The cost of incident response and recovery can be high. When a staff member notices a
suspicious anomaly in data, a system, or the network, the IRT has to perform
investigation and verification, which is time and resource consuming. This activity in
itself is at risk if the number of false reports exceeds the number of real incidents that
occurred, as it diverts resources away from real incidents. To facilitate the task of
identification, the following is a list of typical symptoms of security incidents, which
include any of the following:
1. A system alarm or similar indication from an intrusion detection tool.
2. Suspicious entries in system or network accounting (e.g. a UNIX user obtains root
access without going through the normal sequence).
Page 10
<date>
Page 11
<date>
Page 12
<date>
7.2 Assessment
The next step to be performed by the IRT is to assess the scope, the impact and the
magnitude of the incident. As a note of precaution, never power off or reboot a
compromised system immediately as this may result in the loss of data, information or
evidence required for forensic investigation later. The following are some of the factors
to consider during the assessment:
1. How many computers are affected by this incident?
2. Is sensitive information involved?
3. What is the entry point of the incident (e.g. network, phone dial)?
4. What is the potential damage caused by the incident?
5. What is the estimated time to recover from the incident?
6. What resources are required to manage the situation?
7. How should the assessment be performed effectively?
Depending on the severity of the situation, top management may have to be informed.
Notification guidelines should be developed by the IRT during the preparation of the
Incident Response Plan. For Extreme and High risk incidents, the IRT should
escalate them. The list of key contacts should be completed in the Incident Response
Contact List. The Incident Reporting Form can be used to document the information
gathered from the assessment.
7.3 Containment
The objective of the containment phase is for the IRT to regain control of the situation by
limiting the extent of the damage. The IRT may consider isolating the compromised
system from the rest of the network systems. However, this may disrupt the business
operation if the compromised system is critical or many systems were affected by the
incident, as in the example of a virus outbreak. Hence, the IRT must evaluate with the
management on a per case basis the risk of continuing operations versus regaining control
Incident Response Plan
Page 13
<date>
of the compromised system. All attempts to contain the threat must take into account
every effort to minimize the impact to the business operations.
Furthermore, a backup should also be performed on the system to maintain the current
state of the system to facilitate the post-mortem and forensic investigation later. The IRT
may also consider changing the system passwords to prevent the possibility of Trojan
programs being installed on the compromised system that allows the intruder from
returning to the system via a backdoor.
Keep in mind that some legitimate network monitors and protocol analyzers will set a
network interface in promiscuous mode. Detecting an interface in promiscuous mode
does not necessarily mean that a sniffer is running on a system. If a sniffer has been
installed on a system, examine the output file from the sniffer, if available, to determine
what other machines or accounts are at risk. Machines at risk are those that appear in the
destination field of a captured packet, but if passwords across systems are common or if
the source and destination machines trust each other the source machine will also be at
further risk. Additionally, it is important to note that some sniffers encrypt their logs so
they may not be obvious. Because of this check for files that grow quickly.
Be aware that there may be other machines at risk in addition to the ones that appear in
the sniffer log. This may be because the intruder has obtained previous sniffer logs from
local systems or through other attack methods.
7.3.1
It is a good practice to check all systems related to the affected system, not just the one
that is known to be compromised. This check should include any systems associated with
the compromised system through shared network-based services (such as NIS and NFS)
or through any method of trust (such as systems in hosts.equiv or .rhosts files, or a
Kerberos server). It should be noted that the use of hosts.equiv or .rhosts files is highly
discouraged and the use of them and the services that use them are not considered a best
practice.
7.3.2
Checkingforsystemsinvolvedoraffectedatremotesites
While examining log files, intruder output files, and any files modified or created during
or since the time of the intrusion, also look for information that leads to another site that
may be associated with the compromise. It is often found that additional sites associated
with a compromised system (whether upstream or downstream) have also been victims.
Therefore it is important, responsible, and courteous to identify and notify all other
potential victim sites as soon as possible.
Page 14
<date>
7.4 Eradication
After the containment phase, further investigation should be performed to uncover the
cause of the incident by analyzing system logs of various devices (e.g. firewall, router,
host logs). It is important that the IRT uses a separate set of administrative tools for the
investigation and not those in the compromised system. In the event that the perpetrator
has modified the system configuration, execution of any system tools may have dire
consequences. For example, the intruder may have modified the DOS CMD.EXE
application of the compromised system to delete all files in the system rather than to
return a command shell.
Some of the eradication steps are already addressed in the previous section
(Assess/Contain). Identify when it is necessary to consider the system too compromised
to sanitize without completely rebuilding the system from scratch.
A clean operating system should be reloaded into the compromised server after the
investigation. Many off-the shelf operating systems are not developed with security in
mind. Hence, to increase the security defense of the system, it must undergo a hardening
process, which should include:
1.
2.
3.
4.
7.5 Recovery
Prior to restoring the system from a clean backup, it is recommended that the IRT
validate that the eradication procedures have been properly performed. After installing
the backup, the system should be monitored in a test environment to determine if it is
functioning normally before it can be restored into the business operation.
Furthermore, a network surveillance tool should be implemented to detect any
unauthorized attempts such as additional scans or probes that may signal the return of the
intruder.
7.6 Follow-up
The objective of a post-mortem analysis is to perform a detailed investigation of the
incident to identify the extent of the incident and potential impact prevention
mechanisms. There are three options for performing a post-mortem analysis as shown in
Table 2. The IRT should select the option based on the severity of the incident, the
Page 15
<date>
damage incurred by the Company and the need for legal actions to be taken against the
perpetrator.
7.7 Documentation
All details related to the incident response process should be documented and filed for
easy reference. This provides valuable information to unravel the course of events and an
serve as evidence if prosecution of intruders is necessary. It is recommended that he
following items be maintained:
1. All system events (audit records)
2. All actions taken (including the time that an action is performed), and
3. All external conversations (including person with whom the discussion
was held, the date and time and the content of the conversation).
furthermore, an incident report documenting the following should be
written by the IRT at the end of the exercise:
4. A description of the exact sequence of events
5. The method of discovery
6. Preventive measure put in place, and
7. Assessment to determine if the recovery step taken is sufficient and what
other
8. Recommendations need to be considered.
The objective of the report is to identify potential areas of improvement in the incident
handling and reporting procedures. Hence, the review of the report by management
should be documented, together with the lessons learnt, to improve on the identified areas
and used as reference for future incidents.
Documentation occurs at every stage in the incident handling process. Use the Incident
Handling Form to document all phases of the incident. Use the Communication Log to
document all verbal communication. Consolidate any email communications in a manner
such that it can be consolidated when there is time to perform the final documentation of
the incident.
Performing follow-up is one of the most critical activities in responding to incidents. This
helps improve the incident response process as well as aiding in the continuing support of
any efforts to prosecute those who have broken the law. Follow-up activity includes the
below.
Page 16
<date>
Could additional tools have helped the detection and recovery process?
Was the work performed within the stipulated time frames allocated to dealing
with the incident (including time necessary to restore systems)?
An Incident Report should be created for any security incident. Answers to the
following questions and any plans for mitigation of future incidents should be included in
this report.
How much was the monetary cost of the incidentincluding all time required to
respond and recover?
Was any data irrecoverably lost or stolen, and, if so, what was the effect of the
loss?
Each report is released to the necessary audience so that they can learn about the incident
response process even if they were not involved in responding to the particular incident in
question. The report should be developed by the SO and forwarded to the IT Steering
Committee for review before final approval by the President. Full details of some
incidents may need to be sanitized, depending on the intended audience.
7.7.1
Page 17
<date>
Contact Name
Prepared by:
External Contacts
Contact Info
Date Updated:
Prepared by:
Prepared by:
Prepared by:
Page 18
<date>
Incident Date
Report Date
Phone
Incident Number
Division
Incident Description
Complete all information known at the time of the report preparation. Supervisors and
investigators will complete other items on the report as results become available.
Incident Description
Information/Systems Compromised or at
Risk
Business Area(s) Impacted
Location of the Incident or Systems
Third Party Affected
Systems/Sites/information
Observed Damage Resulting from the
Incident
(Impact on Operations to include
downtime, costs, other damages)
Summary of Incident Investigation Results
(i.e. number of hosts attacked, how
access was obtained, how the attack was
identified, was an incident response
organization contacted prior to
submission of this report, etc)
Identify all parties that received a report
concerning this incident.
Page 19
<date>
CASE INFORMATION
Case Name:
Case Number:
Notes:
Case Manager:
SOURCE INFORMATION
Evidence Bag #
Make & Size
ID#
Serial #
Description:
Activity Dates:
<Date 1>
Location of Activity
<Date 2>
IMAGE INFORMATION
Evidence Bag #
Make & Size
ID#
Serial #
Description:
Activity Dates:
Location of Activity
<Date 1>
<Date 2>
Page 20
<date>
IP Address
Sensitivity
Name
IP Address
Sensitivity
Application
IP Address
Sensitivity
System
Page 21
<date>
Approval
Date
Name
Changes
Draft
Page 22