<x> Energy

Incident Response Plan

Prepared by:

<date>

<x> Energy IRP

Incident Response Plan

<date>

Page 2

<x> Energy IRP

<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

Incident Response Plan <$entity> <$regulation>

Page i

<x> Energy IRP

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

Note to all prospective Incident Response Team (IRT) members.

Read and become familiar with this document as soon
as possible, it is only a matter of time before an incident
will occur. Your review and understanding of this
document is critical to ensuring <x> Energy can
appropriately react to security incidents.

Incident Response Plan <$entity> <$regulation>

Page 1

<x> Energy IRP

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

Incident Response Plan

Page 2

<x> Energy IRP

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

Incident Response Plan

Page 3

<x> Energy IRP

<date>

computer intrusions, denial-of-service attacks, theft of information, inappropriate

modification of data, any unauthorized or unlawful activity that requires support
personnel, system administrators, or computer crime investigators to respond.

Incident Response Plan

Page 4

<x> Energy IRP

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

4.1 Possible Events

This lists events that may trigger the suspicion of an incident.
1. Failure to comply with <x> Energys security policies, procedures, or standards.
2. Malicious software infections (virus, worm, Trojan Horse, etc.).
3. An attack against critical infrastructure or critical <x> Energy system.
4. An attack against a mission critical system that requires special circumstances for
service disconnection.

Incident Response Plan

Page 5

<x> Energy IRP

<date>

5. A denial of service attack affecting critical infrastructure or critical <x> Energy

system.
6. Any system external to and not owned by <x> Energy that is being attacked by a
<x> Energy system.
7. Unauthorized scanning of systems.
8. An active, compromised system.
9. Any fraud, waste, or misuse of a <x> Energy system.
10. An attack apparently originating from a <x> Energy system directed to an outside
system.

Incident Response Plan

Page 6

<x> Energy IRP

<date>

5 INCIDENT RESPONSE FRAMEWORK

The objective of an incident response framework is to provide a systematic approach in
developing an Incident Response Plan. A well-defined Incident Response Plan will enable
<x> Energy to handle any incident efficiently and effectively with minimal impact to the
business operations. When developing these plans, efforts must be made to anticipate
scenarios before they happen, and to make the following decisions in advance of the
incident:
1. Where did the incident occur?
2. Which areas of the business processes are affected?
3. Who should be notified?
4. What are the procedures/actions to be taken?
5. How should the procedures/actions be performed?

Incident Response Plan

Page 7

<x> Energy IRP

<date>

6 INCIDENT RESPONSE TEAM

Below are the IRT member titles, contact information, and responsibilities.
Table 1. IRT Members
Position

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

Perform response recovery

with new process
components.

Physical Security
Officer

Building security issues.

Remote Sites:
Location Manager:
Incident Response Plan

Page 8

<x> Energy IRP

Contacts
Primary:
Alternate:

Incident Response Plan

Office Phone

<date>

Pager

E-Mail

Page 9

<x> Energy IRP

<date>

7 INCIDENT RESPONSE PLAN STRUCTURE

Fig 1 below is a depiction of an IR Framework. Because <x> Energy is dictated to have
an IRP that is geared specifically to systems that that fall under the <$regulation> or can
adversely impact business processes.

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

Incident Response Plan

Page 10

<x> Energy IRP

<date>

3. Accounting discrepancies (e.g. an eighteen-minute gap in the accounting log with

no entries).
4. Repetitive unsuccessful logon attempts within a short time interval.
5. Unexplained new user accounts.
6. Unexplained new files or unfamiliar file names.
7. Unexplained modifications to file lengths and/or dates, especially in system
executable files.
8. Unexplained attempts to write to system files or changes in system files.
9. Unexplained modification or deletion of data.
10. Denial/disruption of service or inability of one or more users to login to an
account.
11. System crashes.
12. Poor system performance of dedicated servers.
13. Operation of a program or sniffer device to capture network traffic.
14. Unusual time of usage (e.g. users login during non-working hours).
This section outlines the methods used to detect events. Events can be detected through a
variety of technical and procedural mechanisms. Technical mechanisms include intrusion
detection/prevention systems (IDS/IPS), log aggregation systems, and firewalls which
produce alerts when suspicious network activity occurs. Procedural mechanisms include
system log reviews, observations of abnormal resource utilization and suspicious account
activity. Additionally, sources external to <x> Energy may detect issues by recognizing
unauthorized activity or abnormal behavior on their systems and reporting the activity.
Typical and initial indications of security incidents 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 user obtains privileged
access without using authorized methods).
Incident Response Plan

Page 11

<x> Energy IRP

<date>

3. Accounting discrepancies (e.g., someone notices an 18-minute gap in the

accounting log for which there is no correlation).
4. Unsuccessful logon attempts.
5. New user accounts of unknown origin.
6. New files of unknown origin and function.
7. Unexplained changes or attempts to change file sizes, check sums, date/time
stamps, especially those related to system binaries or configuration files.
8. Unexplained addition, deletion, or modification of data.
9. Denial of service activity or inability of one or more users to login to an account;
including admin/root logins at the console.
10. System crashes.
11. Poor system performance.
12. Unauthorized operation of a program or the addition of a sniffer application to
capture network traffic or usernames/passwords.
13. Port/System Scanning (use of exploit and vulnerability scanners, using networkaware applications or utilities for information gathering about systems and/or
users).
14. Unusual usage times (statistically, more security incidents occur during nonworking hours than any other time).
15. An indicated last time of usage of a account that does not correspond to the actual
last time of usage for that account.
16. Unusual usage patterns (e.g., programs are being compiled by the account of a
user who does not know how to program).
17. Social engineering attempts.

Incident Response Plan

Page 12

<x> Energy IRP

<date>

Although observing one of these symptoms is generally inconclusive, observing multiple

symptoms in conjunction is motivation for further scrutiny.

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

<x> Energy IRP

<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

Checking other systems on the network

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.

Incident Response Plan

Page 14

<x> Energy IRP

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

Applying all the latest patches

Disabling any unnecessary services
Installing anti-virus software, and
Applying <x> Energys security policy to the system.

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

Incident Response Plan

Page 15

<x> Energy IRP

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

Analyzing what has transpired and what was done to intervene.

Was there sufficient preparation to prevent the incident?

Did detection occur promptly? If not, why?

Incident Response Plan

Page 16

<x> Energy IRP

<date>

Could additional tools have helped the detection and recovery process?

Was the incident sufficiently contained?

Was communication adequate, or could it have been better? How?

What practical difficulties were encountered?

How could any sensitive data have been better protected?

Are adequate administrative, technical, and/or physical controls in place to

mitigate any future incident(s)? If not, recommendations for additional controls.

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?

How much disruption did the incident cause?

Was any data irrecoverably lost or stolen, and, if so, what was the effect of the
loss?

Was <x> Energy sensitive data potentially compromised?

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

Revising policies, processes, standards, and procedures

Developing effective policies and processes is an iterative process in which feedback

from follow-up activity is essential. The Incident Report should be used as the basis for
modifying <x> Energy Policies and IH Procedures.

Incident Response Plan

Page 17

<x> Energy IRP

<date>

8 DOCUMENTS AND FORMS

8.1 Contact Information
This table lists external contacts.
Entity
Internet Service Provider
Service Providers
City Law Enforcement

Contact Name
Prepared by:

External Contacts
Contact Info
Date Updated:
Prepared by:
Prepared by:

Prepared by:

State Law Enforcement

FBI
Customers?

Incident Response Plan

Page 18

<x> Energy IRP

<date>

8.2 Incident Handling Form

Type of Incident (Security, Reliability, Virus, etc)

Incident Date

Individuals Providing Report (Full Name)

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.

Incident Response Plan

Page 19

<x> Energy IRP

<date>

8.3 Chain of Custody

CASE INFORMATION
Case Name:

Case Number:
Notes:
Case Manager:

SOURCE INFORMATION
Evidence Bag #
Make & Size

ID#
Serial #
Description:
Activity Dates:
<Date 1>

Party Performing Activity

Type of Activity Performed

Location of Activity

<Date 2>
IMAGE INFORMATION
Evidence Bag #
Make & Size

ID#
Serial #
Description:
Activity Dates:

Party Performing Activity

Type of Activity Performed

Location of Activity

<Date 1>
<Date 2>

Incident Response Plan

Page 20

<x> Energy IRP

<date>

8.4 Network Component, System, and Application Sensitivity

Sensitivity is a combination of several factors and should come from the <x> Energy
Risk Assessment. Factors include: data processed [e.g., <x> Energy Confidential,
medical, financial, internal, and public (these should be identified in the <x> Energy
Enterprise-wide Information Security program)], criticality to operations, and etc.).
Network
Component

IP Address

Sensitivity

Name

IP Address

Sensitivity

Application

IP Address

Sensitivity

System

Incident Response Plan

Page 21

<x> Energy IRP

<date>

8.5 Revision History

Revision
Number
0.1

Incident Response Plan

Approval
Date

Name

Changes
Draft

Page 22