Develop an Incident Response Plan: Fillable template and example

[Organization name]

Incident response plan

Template instructions

Instructions: the purpose of this template is to help users in meeting the certification requirements for the develop an incident response plan security control area of cybersecure Canada.

Instructions are provided in blue font within each section of this template. Upon completion of the template, delete these instructions.

It is recommended that users review the eLearning module develop an incident response plan and the completed example of an incident response plan.

Table of contents

• Revision history
• Testing & review cycle
• Purpose & scope
• Authority
• Definitions
• How to recognize a cyber incident
• Cyber security incident response team (CSIRT)
• Incident types
• Severity matrix
• Incident handling process
• Approvals
• References

Revision history

Instructions: it is a best practice for organizations to ensure their policies are reviewed and updated regularly. Document when changes are made, what changes and by whom.

The incident response plan has been modified as follows:

Testing & review cycle

Instructions: determine how often your cyber security incident response plan will be tested and how often reviews are required (bi-annually, annually, etc.). At a minimum, an incident response plan should be reviewed & updated at least once every three years. Testing frequency is at an organization's discretion.

Determine and document the process to test and review your cyber security incident response plan. If appropriate to your organization, the example provided below can be used.

Insert frequency of testing, for example bi-annually, annually, etc. Testing of the incident response plan is necessary to ensure the CSIRT (cyber security incident response team) is aware of its obligations. Unless real incidents occur, which test the full functionality of the process, this can be achieved using walkthroughs and practical simulations of potential incidents.

1. The incident response plan will be tested at least once insert frequency of testing.
2. The incident response plan testing will test your business response to potential incidents, identifying process gaps and improvement areas.
3. The CSIRT will record observations made during the testing, such as steps that were poorly executed or misunderstood by participants and aspects that need improvement.
4. The incident handler will ensure the security incident response plan is updated and distributed to CSIRT members.

Purpose & scope

Purpose

Instructions: describe the purpose of your organization's incident response plan. If appropriate to your organization, the example provided below can be used.

This incident response plan exists to ensure insert organization name is prepared to manage cyber incidents in an effective and efficient manner. Cyber security incidents are more frequent and sophisticated than ever. No organization globally is immune to attack. Organizations must ensure they are prepared to detect, prevent, and respond to incidents. By having a plan, a team, and conducting exercises, we will be better prepared to respond inevitable incidents. In addition, we will be able to contain the damage and mitigate further risk to the organization. Resources must be deployed in an organized fashion with exercised skills and communication strategies.

This document describes the overall plan for responding to cyber security incidents at insert organization name. It identifies the structure, roles and responsibilities, types of common incidents, and the approach to preparing, identifying, containing, eradicating, recovering, and conducting lessons learned in order to minimize the impact of cyber security incidents.

The goal of the incident response plan is to ensure insert organization name is organized to respond to cyber security incidents effectively and efficiently.

Scope

Instructions: determine the scope of your plan, including all affected systems and stakeholders. You can refer to the example below and if appropriate, modify the scope as appropriate to your organization.

This incident response plan applies to our networks, systems, and data, and stakeholders (for example, employees, contractors, 3rd party vendors) that access them. Members of the organization who are part of the cyber security incident response team (CSIRT) are expected to lead or participate in a cyber incidence response. CSIRT members must familiarize themselves with this plan and be prepared to collaborate, with the goal of minimizing adverse effects on the organization.

This document establishes incident handling and incident response capabilities and determines the appropriate response for common cyber security incidents. This document is not intended to provide a detailed list of all activities that should be performed in combatting cyber security incidents.

Authority

Instructions: identify and document the individuals/role in your organization that will be responsible for handling an incident.

Responsibility for the security of company and customer information resides with the president/owner. During times when a high or critical cyber security incident is underway, this responsibility is entrusted to the general manager.

Definitions

Instructions: review the definitions below and retain or revise as required. If necessary, expand the list to best reflect your organization's unique cyber security incident response plan.

Acceptable interruption window in business continuity planning, is the amount of time in which basic functionality must be restored for critical systems. It is a major factor when planning a disaster recovery solution.

Confidentiality is a classification of data that typically refers to personally identifiable information. It may include such things as social insurance numbers, drivers licence numbers, etc.

Cyber security event is an observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, or a user sending email.

Cyber security incident is any incident that occurs by accident or deliberately that impacts communications or information processing systems. An incident may be any event or set of circumstances that threatens the confidentiality, integrity or availability of information, data or services within [organization name]. This includes unauthorized access to, use, disclosure, modification, or destruction of data or services used or provided by [organization name].

Denial of service (attack) also known as a dos attack, seeks to make a remote service unavailable to its intended users by flooding its host with superfluous requests, thereby overloading the system.

Exploit in cyber security terms is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic.

Indicators also known as "indicators of compromise" or iocs, are forensic clues or symptoms left behind by cybersecurity attacks or breaches in the company's network or systems. These clues are sometimes found in log entries, files, or databases.

Integrity refers to the maintenance or assurance of data accuracy, consistency, and its accessibility to authorized users for its entire life-cycle.

Maximum tolerable downtime in business continuity planning, this specifies the maximum period of time that a given business process can be inoperative before the organization's survival is at risk.

Response playbook introduces prescriptive cyber security measures and best practices that can be implemented to improve the organization's security profile. This playbook provides a set of standards to reference the organization, improves current systems and implement new ones.

Service availability describes the state of a system being available and responsive to prospective users. The term is sometimes used to reference a measure of reliability of a system or network resource based on how often it is available as a % of time. For example, 99.97% service availability means that a system is available 99.97% of the time.

Sla stands for service level agreement and is used to describe a guaranteed measure of service availability. If service availability drops below the prescribed sla, there are usually financial repercussions, like a money-back guarantee.

Stakeholder relationship map is a diagram that describes the relationship between individuals in an organization. With respect to cyber security, these diagrams are used to perform it risk assessments to better inform preventative and reactive measures.

Vulnerability is a piece of code or bug within a system that causes unintended or unanticipated behavior. A vulnerability implies that this behaviour can be taken advantage of for malicious reasons.

War room is a dedicated meeting room where major incidents are handled together. It must have a door for privacy, must be available at all times, and must have good communications infrastructure (network, phone, etc.)

Zero-day is a type of vulnerability that is known to the software vendor but doesn't have a patch in place to fix the flaw. It has at least the potential to be exploited, if it has not already been exploited by cybercriminals.

How to recognize a cyber incident

Instructions: review and retain the indicators that are applicable to your organization. Expand the list of indicators as appropriate to your organization.

A cyber security incident may not be recognized straightaway; however, there may be indicators of a security breach, system compromise, unauthorized activity, or signs of misuse within your environment, or that of your third-party service providers.

Look out for any indication that a security incident has occurred or may be in progress. Some of these are outlined below:

1. Excessive or unusual log-in and system activity, in particular from any inactive user ids (user accounts)
2. Excessive or unusual remote access activity into your business. This could relate to staff or third-party providers
3. The occurrence of any new wireless (wi-fi) networks visible or accessible from your environment
4. The presence of or unusual activity in relation to malware (malicious software), suspicious files, or new/unapproved executable files and programs. This could be on your networks or systems, including web-facing systems
5. Hardware or software key-loggers found connected to or installed on systems
6. Suspicious or unusual activity on, or behaviour of web-facing systems, such on as e-commerce websites
7. Point-of-sale (pos) payment devices, payment terminals, chip & pin/signature devices, or dip/swipe card readers showing signs of tampering
8. Any card-skimming devices found in your business
9. Lost, stolen, or misplaced merchant copy receipts or any other records that display a full payment card number or card security code (the three- or four-digit number printed on the card)
10. Lost, stolen, or misplaced computers, laptops, hard drives, or other media devices that contain payment card data or other sensitive data

Cyber security incident response team (CSIRT)

CSIRT structure

Instructions: provide the organization structure of your CSIRT team. At a minimum, it must contain an executive, an incident handler and a communication spokesperson as outlined in the common structure below.

Common structure of a cyber security incident response team (CSIRT).

• Incident Handler
• Communications
• Note-taker
• Network
• Desktop
• Server
• Legal

CSIRT roles

Instructions:

• Define the roles and responsibilities, and provide the respective contact information for each member of the CSIRT in the provided space. A table is provided with examples of best practices
• Each role should have a secondary and often a tertiary alternative identified
• Some CSIRT roles may be fulfilled by third part vendors or contracted individuals
• Note, the incident handler is not usually the company president/CEO, but rather the head of an it team. For organizations that do not have dedicated it personnel, the president/CEO can assume the role
• List key external contacts and stakeholders that you may need to contact during an incident (for example, legal representative, financial insertions, key clients, staff, it provider, etc)

CSIRT roles

CSIRT responsibilities

The responsibilities described below are organized by role within organization name.

Executives

The executives are/is responsible for:

1. Insert responsibilities of executives
2. Insert responsibilities of executives
3. Insert responsibilities of executives
4. Insert responsibilities of executives
5. Insert responsibilities of executives
6. Insert responsibilities of executives

Incident handler

The incident handler is responsible for:

1. Insert responsibilities of incident handler
2. Insert responsibilities of incident handler
3. Insert responsibilities of incident handler
4. Insert responsibilities of incident handler
5. Insert responsibilities of incident handler
6. Insert responsibilities of incident handler

Communications expert

The communications expert is responsible for:

1. Insert responsibilities of communications expert
2. Insert responsibilities of communications expert
3. Insert responsibilities of communications expert
4. Insert responsibilities of communications expert
5. Insert responsibilities of communications expert
6. Insert responsibilities of communications expert

CSIRT team

Cyber security incident response team (CSIRT) members are responsible for:

1. Insert responsibilities of CSIRT team members
2. Insert responsibilities of CSIRT team members
3. Insert responsibilities of CSIRT team members
4. Insert responsibilities of CSIRT team members
5. Insert responsibilities of CSIRT team members

All staff members are responsible for:

1. Insert responsibilities of all staff members
2. Insert responsibilities of all staff members
3. Insert responsibilities of all staff members
4. Insert responsibilities of all staff members
5. Insert responsibilities of all staff members

Contact information

CSIRT contacts

External contacts

Other stakeholder contacts

Incident types

Instructions: review the incidents listed below and their description to determine which are appropriate to be included in your plan. The types can be expanded as necessary.

Incident severity matrix

Instructions: review the sample best practice process below to determine if applicable for your organization's. Revise to align with your organization.

The CSIRT will determine the severity of the incident. They will consider:

1. Whether a single system is affected or multiple
2. The criticality of the system(s) affected
3. Whether impacting a single person or multiple
4. Whether impacting a single team/department, multiple teams/departments, or the entire organization

The incident handler must consider the relevant business context and what else is happening with the business at the time to fully understand the impacts and urgency of remedial action.

The CSIRT will consider the available information to determine the known magnitude of impact compared with the estimated size, along with likelihood of the effect spreading and the potential pace of such spread. The CSIRT will determine the potential impacts to the organization, including financial damage, brand and reputational damage, and other types of harm.

The incident may be the result of a sophisticated or unsophisticated threat, an automated or manual attack, or may be nuisance/vandalism.

The CSIRT will determine:

1. Whether there is evidence of the vulnerability being exploited
2. Whether there is a known patch
3. Whether this is a new threat (for example, zero day) or a known threat
4. The estimated effort to contain the problem

Incident handling process overview

Instructions: develop a process and document action's taken to handle incidents within your organization. Include the following phases: preparation, identification, containment, eradication, recovery and lessons learned (PICERL model).

Refer to the cyber incident response plan example to determine processes that may be applicable to your organization.

In the event of a cyber security incident the cyber security incident response team will adhere to the PICERL process as follows.

• Preparation
• Identification
• Containment
• Eradication
• Recovery
• Lessons Learned

Preparation

Instructions: the preparation phase focuses on preparing your team to handle an incident.

Insert your organization's unique processes/procedures.

Identification

Instructions: the identification phase outlines how your organization will detect and determine if an incident has occurred. This phase requires you to gather information from various sources such as log files, error messages, intrusion detection system reports, and firewalls, which may produce evidence to determine if an incident has occurred.

Insert your organization's unique processes/procedures.

Containment

Instructions: the containment phase is where your organization will outline the action/s it will take to limit the damage and prevent further damage from the incident.

Insert your organization's unique processes/procedures.

Eradication

Instructions: the eradication phase is where your organization will outline how it will remove and restore its affected systems.

Insert your organization's unique processes/procedures.

Recovery

Instructions: the recovery phase is where your organization will outline how it will restore the affected systems to operational status. Consider important factors such as how you plan to test, monitor and validate the systems you are restoring, ensuring they are not still infected by malware or compromised by some other means.

Insert your organization's unique processes/procedures.

Lessons learned

Instructions: the lessons learned phase involves taking stock of the incident; getting to the root of how and why it happened; evaluating how well your incident response plan worked to resolve the issue; and identifying improvements that need to be made.

Insert your organization's unique processes/procedures

Incident specific handling processes

Instructions: provide the steps for handling specific incidents as defined by your organization.

• Review the list of common types of incidents below and determine which are applicable to your organization. Provide additional incident types as necessary.

Refer to the example of a completed cyber incident response plan to determine processes that may apply to your organization.

Data breach

If CSIRT investigations confirm that a data breach security incident has occurred, please execute the following additional steps:

Instructions: insert your organization's unique processes/procedures.

Ransomware

If CSIRT investigations confirm that a ransomware security incident has occurred, please execute the following additional steps:

Instructions: insert your organization's unique processes/procedures.

Tampering of payment terminals

If CSIRT investigations confirm that tampering of pin pads or payment terminals has occurred, please execute the following additional steps:

Instructions: insert your organization's unique processes/procedures.

Widespread service interruption

If CSIRT investigations confirm that widespread service interruption security incident has occurred, please execute the following additional steps:

Instructions: insert your organization's unique processes/procedures.

Loss of equipment

If CSIRT investigations confirm that loss of equipment or theft has occurred, please execute the following:

Instructions: insert your organization's unique processes/procedures.

Approvals

Responsible party

Instructions: determine who will be responsible for the development, updating and enforcement of the incident response plan.

Responsibility for the security of company and customer information resides with the following responsible party:

The responsible party has reviewed the incident response plan and delegates the responsibility for mitigating harm to the organization to the incident handler.

During times when a high or critical cyber security incident is underway this responsibility is entrusted to the incident handler or their delegate.

Incident handler

Instructions: identify who the incident handler is for your plan and their respective responsibilities. If appropriate, you can use the example below.

The incident handler has reviewed the security incident response plan and acknowledges that, when a high or critical cyber security incident is underway, responsibility for managing the incident is entrusted to the incident handler or their delegate.

The incident handler or their delegate is expected to handle the incident in a way that mitigates further exposure of the organization. The incident will be handled according to process including identification, containment, eradication, recovery, and lessons learned.

References

• National institute of standards and technology (NIST), NIST special publication 800-61 revision 2, http://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
• Sysadmin, audit, network & security (sans), https://www.sans.org/reading-room/whitepapers/incident
• Sysadmin, audit, network & security (sans), https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901
• Sans incident handling forms (sans), https://www.sans.org/score/incident-forms
• The office of the privacy commissioner of Canada – the personal information protection and electronic documents act (PIPEDA), https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/
• The office of the privacy commissioner of Canada – PIPEDA: what you need to know about mandatory reporting of breaches of security safeguards, https://www.priv.gc.ca/en/privacy-topics/business-privacy/safeguards-and-breaches/privacy-breaches/respond-to-a-privacy-breach-at-your-business/gd_pb_201810/
• Government of Canada – Canada's anti-spam legislation (CASL), https://www.fightspam.gc.ca/eic/site/030.nsf/eng/home
• Sans giac certifications – incident handler's handbook, https://sansorg.egnyte.com/dl/6btqoa63at/?