Apart from the legal obligations in the event of a data breach and thus the notification to be made to the Data Protection Authority, it is necessary to understand how to respond to a cyber incident.
The nature of a data breach
It has been explained several times on this site: a data breach is a breach of computer security that can be culpable when it is accidental, malicious when it is intentional and, according to ISO 27005, also environmental. In summary, we can subdivide data breaches as follows.
- Accidental (culpable) nature: e.g. when an employee accidentally spills a glass of water on the organisation’s computer.
- Intentional (malicious) nature: e.g. when a malicious actor attacks the organisation’s computer system with a virus.
- Environmental nature (culpable): related to climatic, seismic, volcanic, meteorological phenomena. For more information , please refer to this article.
These are the basics of the nature of an information security breach and apply in any incident condition. Consequently, the identification of the nature is crucial and must be done in a timely manner.
Responding to a data breach
Responding to a data breach, i.e. a security breach (whether negligent or malicious), requires certain essential procedural aspects that are well summarised within Critical Security Controls (CSC) 8. Let us therefore try to answer the question how should one respond to a data breach?
| DESCRIPTION | Description |
|---|---|
| Designate the Personnel in charge of incident management. Safeguard 17.1 | Designate a key person and at least one deputy who will lead the incident management process. Management personnel are responsible for coordinating and documenting incident and incident response and recovery activities; you may use internal employees, a third party or choose a hybrid solution. If a third-party provider is used, designate at least one person within the company to supervise its work. Review annually or when significant business changes occur that could impact this Safeguard. |
| Establishing and maintaining contact information for reporting security incidents Safeguard 17.2 | Establish and maintain a list of persons who should be informed of security incidents. Contacts may include internal staff, third-party vendors, law enforcement, computer insurance companies, government agencies, Information Sharing and Analysis Centre (ISAC) partners or other interested parties. Check contacts annually to ensure that information is up-to-date. |
| Establish and Maintain a Company Incident Reporting Procedure Safeguard 17.3 | Establish and maintain a procedure for company personnel to report security incidents. This includes when to report, who to contact, the reporting mechanism and the minimum information to be reported. Ensure the procedure is publicly available to all personnel. Review annually or when significant business changes occur that could impact on this Safeguard. |
| Establishing and Maintaining an Incident Response Procedure Safeguarding 17.4 | Establish and maintain an incident response procedure that includes roles and responsibilities, compliance requirements and a communication plan. Review annually or when significant business changes occur that could impact this safeguard. |
| Assigning key roles and responsibilities Safeguarding 17.5 | Assign key roles and responsibilities for incident response, including legal, IT, information security, facilities, public relations, human resources, incident contacts and analysts, if possible. Review annually or when significant business changes occur that could impact this Safeguard |
| Define communication mechanisms during incident response Safeguard 17.6 | Determine which primary and secondary modes will be used to communicate and report during a security incident. Mechanisms may include telephone calls, e-mails or letters. Keep in mind that certain mechanisms, such as e-mail, may not work following a security incident. Review annually or when significant business changes occur that could impact this Safeguard. |
| Conducting Routine Exercises in Response to Incidents Safeguarding 17.7 | Plan and conduct routine exercises and scenarios in response to incidents for key personnel involved in the procedure to prepare them to cope with the eventuality in real cases. The exercises should test communication channels, decision-making and workflows. Carry out tests at least on an annual basis. |
| Carry out post-accident reviews Safeguard 17.8 | Post-accident reviews help prevent the recurrence of accidents through the identification of lessons learnt and follow-up action. |
| Establishing and maintaining levels for security incidents Safeguard 17.9 | Establish and maintain levels for security incidents, including, at a minimum, differentiating between an incident and an event. Examples may include: abnormal activity, security vulnerability, security weakness, data breach, privacy incident, etc. Review annually or when significant business changes occur that could impact this safeguard. |
For more information on the relationship between security breaches, responses and CSCs, we recommend reading the following article.
Routine exercises and indemnity between CSC and ISO27001
Safeguard 17.7 requires routine ‘exercises’ and scenarios to be conducted in response to incidents. Conducting these simulations is essential and is intended to ensure that control is maintained during the actual incident. Simulations are essential in order to remind all parties involved who has to do what, and more importantly how and when. It is important to understand that routine exercises do not directly coincide with penetration tests, they may simply be focused on evaluating sub-procedures or minor aspects that relate to the management of the incident. A distinction must be made between routine exercises and scenarios.
The routine exercise is the practical simulation of a specific process to achieve a specific purpose. For example, how departments communicate in a timely manner during a data breach.
Scenario simulation is the reconstruction of an IT incident, in its entirety and complexity, to assess the management competence of all actors involved.
This is a very interesting topic with regard to penetration tests as well as routines and simulation scenarios. Indeed, it is not always possible for the organisation to offer testers a dedicated environment on which to carry out simulations and, when this happens, it is necessary to employ a part of the production environment in order to set up simulations. However, the production environment is delicate: it houses all the ‘real’ data and its tampering, loss, corruption, would be a serious problem for the organisation.
It is also clear that the test is prepared beforehand by offering guarantees regarding the protection and safeguarding of data, but it is normal practice for the tester to sign a disclaimer regarding potential problems that may arise. In this sense, it is very interesting to look at what is prescribed in security control 8.34 of ISO 27001:2022
| ID | Title | Description |
|---|---|---|
| 8.32 | Protection of information systems during audit testing Protection of information systems during audit testing | Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management. Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management. |
There is therefore a specific security check that warns organisations to safeguard their data before the tests are carried out.
The CREST
Perhaps not everyone is familiar with CREST (Council of Registered Ethical Security Testers), their website states:
CREST is an international not-for-profit body representing the global IT security industry. Since 2006, we have been leading the cybersecurity community to collectively raise the standards of IT service providers and practitioners, ensuring the quality of the industry and, in turn, providing confidence to the buying community, government and regulators.
Source: CREST(Link)
In Italy, for example, there are a number of emanations of CREST assigned to perform a number of interesting tasks such as, but not limited to:
- Ethical Hacking (Offensive Security/Pen Test)
- Crisis Response
- SOC Solutions
- Security Architectures
CREST is mentioned within CSCv8 because it helped to define the safeguards mentioned above.
