EXAMPLE Incident Lessons Learned Report

Incident Lessons Learned Report

INCIDENT DESCRIPTION

Breach of personal data from online portal

DATE LOGGED

November 2 20xx

SERVICE DESK REF

INC12345678

REPORT AUTHOR

J. Smith

DATE OF REPORT

January 30 20xx

CHRONOLOGY OF THE INCIDENT On November 2 20xx, routine checks of the configuration of network components identified a misconfiguration that had allowed attackers to access data from a database concerned with the processing of online insurance claims.

Logs showed that the attack had begun approximately one month before and had resulted in the theft of 4,000 records containing the personal data of customers, including names, addresses, policy numbers, limited financial information and claim details.

An incident record was raised on November 2 20xx and the incident management procedure was invoked. It was decided to report the breach to the supervisory authority, which was done on November 3 20xx, approximately 24 hours after it was discovered.

The servers involved were taken offline immediately and a vulnerability was identified which had allowed the attackers remote command line access to the server operating system. This vulnerability was patched on November 4 20xx on all affected systems.

A third-party consultancy firm was engaged to provide advice and collect any digital evidence available for later submission to the authorities, if required.

Incident Lessons Learned Report IMPACT OF THE INCIDENT The personal data of 4,000 customers were affected and these customers were notified of the breach and its potential implications by letter on November 7 20xx.

The online insurance claim system was down for a total period of three weeks whilst the incident was investigated. As a result, additional staffing costs of £50,000 were incurred to receive claims via telephone.

It is not yet known whether the supervisory authority will take legal action as a result of the breach. The company’s share price fell ten percent as a result of coverage of the breach in the media.

UNDERLYING CAUSE, IF KNOWN The attackers gained access to the server by exploiting a vulnerability in the open source software used. The vulnerability had been identified by the software vendor six months earlier but the patch that addressed it had not been installed on the server in question due to a miscommunication within the IT team. It is known that the servers had been scanned by several outside parties in the run up to the breach, looking for vulnerabilities.

It is not known where the attackers originate from, or their specific motives.

The attackers had run scripts against the databases they had gained access to and did this slowly over a period of time to avoid raising suspicion and to look like normal system activity. They were able to use encryption to further disguise what they were doing. Our intrusion detection system (IDS) was unable to identify this as suspicious behavior because it did not have access to encrypted traffic within the network. This was due to a certificate having expired several months previously which was not renewed, so disabling this feature within the IDS.

RECOMMENDATIONS TO CUT RISK OF A REPEAT INCIDENT 1. Improve the software inventory so that it accurately reflects where software is installed and so where it should be patched.

2. Improve procedures for applying patches to software exposed to the Internet, so that they are applied sooner after release.

3. Ensure that the process for renewing certificates results in them not expiring and so limiting visibility of unauthorized activities.

CSF-FORM-IDIM-2 Version 1

Page 2 of 3

[Insert date]

Incident Lessons Learned Report

LESSONS LEARNED A number of positive lessons were learned from this incident: • • • •

The procedure for reacting to such information security incidents worked well once the breach had been detected.

Logs were successfully protected from amendment by the attackers and represented a definitive record of what had been done, which allowed the extent of the breach to be determined.

Timely liaison with the supervisory authority and communication with the data subjects affected was seen in a positive light and limited the reputational impact.

The third-party consultancy brought in to advise proved very effective and speeded up the investigation and remediation activities significantly.

Areas which could have improved our ability to address the incident effectively were: • • •

If the breach could have been identified earlier, less data might have been compromised.

Technical limits on the number of database queries that may be run in a specified time period might have slowed the attack down.

The importance of timely patching of software was illustrated by this attack.

CSF-FORM-IDIM-2 Version 1

Page 3 of 3

[Insert date]