cyphoss ir template

<x> Energy

Incident Response Plan

Prepared by:

<date>

<x> Energy IRP <date>

Incident Response Plan


Table of Contents

1 Introduction..................................................................................................................12 Scope............................................................................................................................23 Key Definitions............................................................................................................34 Classifying an Event....................................................................................................5

4.1 Possible Events....................................................................................................55 Incident response framework.......................................................................................76 Incident Response Team..............................................................................................87 Incident Response Plan Structure..............................................................................10

7.1 Identification......................................................................................................107.2 Assessment........................................................................................................137.3 Containment.......................................................................................................13

7.3.1 Checking other systems on the network....................................................147.3.2 Checking for systems involved or affected at remote sites.......................14

7.4 Eradication.........................................................................................................157.5 Recovery............................................................................................................157.6 Follow-up...........................................................................................................157.7 Documentation...................................................................................................16

7.7.1 Revising policies, processes, standards, and procedures...........................178 Documents and Forms...............................................................................................18

8.1 Contact Information...........................................................................................188.2 Incident Handling Form.....................................................................................198.3 Communication Log..........................................................................................218.4 Network Component, System, and Application Sensitivity..............................24

Incident Response Plan <$entity> <$regulation> Page i


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.

Incident Response Plan <$entity> <$regulation> Page 1

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.


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


3 KEY DEFINITIONS

Assessment—After 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.

Containment—Containment of the incident is necessary to minimize and isolate the damage incurred.

Eradication—In 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.

Event—An occurrence that has not been verified as a Security Incident.

Follow-up—As 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.

Identification—The 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.

Preparation—In 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.

Recovery—The 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 Incident—An irregular or adverse event that occurs within any part of <x> Energy’s information systems infrastructure. These include (but are not limited to)



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.



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.

4.1 Possible EventsThis lists events that may trigger the suspicion of an incident.

1. Failure to comply with <x> Energy’s 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.


<$regulatory body> must be notified of any “Critical” or “High” incidents.


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.



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?



6 INCIDENT RESPONSE TEAM

Below are the IRT member titles, contact information, and responsibilities.

Table 1. IRT Members

Position Contact InformationPriority and Responsibilities

Information Services Manager

Oversee incident response process.

Information Services Administrator

Perform response recovery with systems.

Network Administrator

Perform response recovery with network components.

Database Administrator

Perform response recovery with databases systems.

CFO/CIO Public Relations and Incident Reporting Official

Applications Manager

Perform response recovery with application components.

Manager of Store Services

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:

Contacts Office Phone Pager E-MailPrimary: Alternate:



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



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



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 network-aware applications or utilities for information gathering about systems and/or users).

14. Unusual usage times (statistically, more security incidents occur during non-working 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.



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



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 Checking for systems involved or affected at remote sites

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.



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. Applying all the latest patches2. Disabling any unnecessary services3. Installing anti-virus software, and4. Applying <x> Energy’s 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-upThe 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



damage incurred by the Company and the need for legal actions to be taken against the perpetrator.

7.7 DocumentationAll 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), and3. 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 events5. The method of discovery6. Preventive measure put in place, and7. Assessment to determine if the recovery step taken is sufficient and what

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

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 incident—including 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.



8 DOCUMENTS AND FORMS

8.1 Contact Information

This table lists external contacts.

External ContactsEntity Contact Name Contact Info Date Updated:Internet Service Provider Prepared by: Prepared by: Prepared by: Prepared by:Service ProvidersCity Law Enforcement

State Law Enforcement

FBI

Customers?



8.2 Incident Handling Form

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

Individuals Providing Report (Full Name) Report Date

Phone Division Incident Number

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.



8.3 Chain of Custody

CASE INFORMATION

Case Number: Case Name:

Notes:

Case Manager:

SOURCE INFORMATION

ID# Evidence Bag #

Serial # Make & Size

Description:

Activity Dates: Party Performing Activity Type of Activity Performed Location of Activity

<Date 1>

<Date 2>

IMAGE INFORMATION

ID# Evidence Bag #

Serial # Make & Size

Description:

Activity Dates: Party Performing Activity Type of Activity Performed Location of Activity

<Date 1>

<Date 2>



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

System Name IP Address Sensitivity

Application IP Address Sensitivity



8.5 Revision History

Revision NumberApproval Date

Name Changes

0.1 Draft


cyphoss ir template

Documents

incident reoccurring

incident response framework

incident response program

incident handling form

appropriate response

energy personnel

scopethis document

computer security incidents