CSF-DOC-RSMI-3 Incident Response Plan Data Breach

Incident Response Plan: Data Breach

Implementation guidance

The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions document.

Purpose of this document

This document describes the specific steps to take to respond to a data breach on your systems.

Areas of the framework addressed

The following areas of the Cybersecurity Framework are addressed by this document:

• Respond (RS)

o Incident Mitigation (RS.MI)

▪ RS.MI-01

▪ RS.MI-02

General guidance

A data breach is one of the more publicized and potentially damaging incidents that could happen to your organization. Try to identify a breach as early as possible, limit the data available to an attacker and ensure that your communication procedures and timing are as good as they can be. Often data breaches are discovered after the event, when the stolen data appears on the Internet, but even in these circumstances there is still a lot of work to do to find out how it happened and prevent it from happening again.

Review frequency

We would recommend that this document is reviewed annually and upon significant change to the organization.

Document fields

This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.

To update this field (and any others that may exist in this document):

1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.

2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab).

3. Press F9 on the keyboard to update all fields.

4. When prompted, choose the option to just update TOC page numbers.

If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.

Further detail on the above procedure can be found in the toolkit Completion Instructions

This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.

Copyright notice

Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.

Licence terms

This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence.

If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.

Disclaimer

Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use.

Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country.

You should take all reasonable and proper legal and other professional advice before using this document.

CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Incident

Incident Response Plan: Data Breach

Incident Response Plan: Data Breach

Revision history

Distribution

Approval

Incident Response Plan: Data Breach

1 Introduction

A data breach typically involves the theft of data from an organization by an unauthorized third party, often referred to as a “hacker”. The motive for the theft can vary, from financial (for example, demanding a ransom or using the data for fraud), to political (for example to try to create a scandal) to commercial (for example theft of intellectual property such as product designs).

The technical capabilities of the attacker can also vary, ranging from amateur (such as “script-kiddies”) to very professional and experienced (in the case of organized gangs or state-sponsored and funded military sections).

[Organization Name]’s defences are based on an assessment of the risks to its systems and data and are inevitably limited by the amount of money justified by the level of perceived risk. This means that an attack by a highly skilled group may be successful, and a plan needs to be in place to not only defend against attacks, but also to deal with the situation where data has been stolen.

This incident response plan describes the steps that must be taken to manage a data breach and attempt to limit its impact.

This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to [Organization Name] systems.

The following policies and procedures are relevant to this document:

• Information Security Incident Response Procedure

• Personal Data Breach Notification Procedure

2 Responding to a data breach

There are a number of steps that must be carried out by [Organization Name] to respond to a data breach, so that the impact on the organization is minimized and recovery may take place as quickly as possible. These steps must be coordinated with the actions set out in the Information Security Incident Response Procedure which provides an overall framework for the management of such incidents. The steps below are organized to fit in with this framework.

2.1 Detection and analysis

The first signs of an actual or potential data breach will vary and may include:

• Suspicious activity detected via special purpose software tools

• Unusual activity identified through log analysis

• Direct contact from an attacker, for example to demand a ransom

• Reports from individuals, supervisory authorities or law enforcement agencies of data being available on the Internet or being used for fraud

• Anti-virus alerts received

• Unexplained occurrences, for example incorrect application behaviour or services not being available

• Administrators, support staff or users noticing suspicious items such as new files or user accounts created, possibly with unusual names

• Security software becomes disabled

• Unexplained hard drive activity

In many cases the objective of the attacker is to avoid detection, and they may have been active on the network for a long period of time prior to any of the above signs being noticed. Software tools and techniques may also be used by the attacker to disguise their activities.

Once the possibility of malicious activity has been raised, a number of methods may be used to further analyze the situation and establish what has happened:

• Analysis of logs on network devices and servers to piece together a timed audit trail of suspicious activity

• Use of packet sniffers on the network to identify unusual network traffic

• Review of database queries that have been run since the attack is suspected to have started

• Involvement of external specialists to confirm or exclude the possibility of an attack

2.2 Containment

If analysis confirms the existence of malicious activity within the network, initial steps must be taken to contain the impact of the attack. These steps will depend upon the precise nature of the attack, but may include:

• Blocking IP addresses that may be the source of the attack

• Disconnecting the affected systems from the Internet

• Isolating the affected systems from the rest of the internal network

• Changing the passwords of accounts thought to have been compromised

2.3 Eradication

Once the attack has been contained, action must be taken to remove the malicious artefacts that may have been installed by the attacker. Unless there is a high degree of certainty about exactly what happened, the safest course of action will be to reinstall operating software and restore data from backups, so that a clean slate is established. The need to preserve evidence may need to be considered, based on management decisions in this area.

If it is not possible to restore from backup, care must be taken to identify everything that has been installed and changed on the affected systems. Anti-malware software may be used to identify and remove suspicious items and the latest patches must then be installed. Configuration changes that have been made to network devices and computers by the attacker will need to be found and corrected. Examination of audit logs may be necessary to identify such changes.

2.4 Recovery

In addition to repairing the damage done by the attacker, recovery will include a full understanding of how the attack was conducted and addressing every vulnerability that was used in the course of it. This may entail installing patches and changing passwords of compromised accounts and ideally those that are judged to be potentially open to compromise in the future.

If cyber insurance is in place, the provider may be approached to make a claim and to take advantage of available assistance at all stages of the response.

2.5 Notification

Because a data breach may involve the theft of data there are likely to be legal and regulatory requirements for notification, with associated timescales.

Incident Response Plan: Data Breach [Insert classification]

In the event of a data breach involving personal data of EU citizens, the General Data Protection Regulation (GDPR) requires that the relevant supervisory authority be notified within 72 hours of becoming aware of the incident. This depends on an assessment of the likely risk to data subjects from the breach.

[Detail any further legal or regulatory notification requirements]