Specifically, the Guidelines outline various fictitious examples of data breaches, together with examples of prior security measures which may be implemented to reduce the likelihood of each example, as well as how to assess the breach and how to respond to the breach, in terms of both mitigation measures and reporting obligations under the GDPR, organised into the following categories:

• ransomware;
• data exfiltration attacks;
• internal human risk source;
• lost or stolen devices and paper documents;
• postal mail mistakes; and
• selected other cases related to social engineering.

More generally, the Guidelines note that as part of any attempt to address a breach the controller should first be able to recognise one. The GDPR defines a 'personal data breach' in Article 4(12) as ''a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed''.

The Guidelines further point out that data breaches are problems in and of themselves, but they are also symptoms of a vulnerable, possibly outdated, data security regime, thus indicate system weaknesses to be addressed and, as a general truth, it is always better to prevent data breaches by preparing in advance, since several consequences of them are irreversible by nature. Furthermore, the Guidelines note that before a controller can fully assess the risk arising from a breach caused by some form of attack, the root cause of the issue should be identified in order to determine whether any vulnerabilities that gave rise to the incident are still present, and are still exploitable.

This article looks specifically at two of the 18 fictitious examples in further detail, one focused on ransomware attacks and the second focusing on data exfiltration attacks.

Ransomware

The Guidelines note that a frequent cause for a data breach notification is a ransomware attack suffered by the data controller and that in these cases a malicious code encrypts the personal data, with the attacker subsequently asking the controller for a ransom in exchange for the decryption code.

Case No. 03: Ransomware with backup and without exfiltration in a hospital

Case summary:

'The information system of a hospital was exposed to a ransomware attack and a significant proportion of its data was encrypted by the attacker. The company is using the expertise of an external cybersecurity company to monitor their network. Logs tracing all data flows leaving the company (including outbound email) are available. After analysing the logs and the data the other detection systems have collected the internal investigation aided by the cybersecurity company determined that the perpetrator only encrypted the data without exfiltrating it. The logs show no outward data flow in the timeframe of the attack. The personal data affected by the breach relates to the employees and patients, which represented thousands of individuals. Backups were available in an electronic form. Most of the data was restored but this operation lasted 2 working days and led to major delays in treating the patients with surgery cancelled / postponed, and to a lowering the level of service due to the unavailability of the systems'.

Prior measures and risk assessment

The Guidelines highlight that as with all risks posed by external actors, the likelihood that a ransomware attack is successful can be drastically reduced by tightening the security of the data controlling environment. In ensuring that the data controller has taken the appropriate organisational, physical, and technological security measures the majority of ransomware breaches can be prevented. The Guidelines outline that an example of such measures include proper patch management and the use of an appropriate anti-malware detection system. In addition, ensuring that the data controller has a proper and separate backup can also help with the mitigation of the consequences of a successful ransomware attack. In addition, the Guidelines suggest that an employee security education, training, and awareness ('SETA') program, will help to prevent and recognise this kind of attack.

Furthermore, the Guidelines outline that when assessing the risks, the controller should investigate the breach and identify the type of malicious code to understand the possible consequences of the attack. Among those risks to be considered is that data was exfiltrated without leaving a trace in the logs of the systems.

The Guidelines highlight that in this example the quantity of breached data and the number of affected data subjects are high, because hospitals usually process large quantities of data and that the unavailability of the data has a high impact on a substantial part of the data subjects. The example also illustrated other important factors, such as the existence of a residual risk of high severity to the confidentiality of the patient data. Important factors that must be considered include type of the breach, nature, sensitivity, and volume of personal data affected in the breach. Despite the existence of a data backup that could be restored in a few days, the breach remains high risk due to the severe consequences data subjects may encounter as a result if the lack of availability of the data resulting from the attack.

Mitigation and obligations

The Guidelines clarify that for this example a number of necessary actions are required. These include a notification to the supervisory advisory, as the breach involved special categories of personal data and considering that major delays in patient care may materialise from the restoration of the data taking a long time. The hospital is also required to inform the data subjects due to the impact on patients, even after the encrypted personal data has been restored.

The Guidelines highlight that this case serves as an example for a ransomware attack with high risk to the rights and freedoms of the data subjects. It should be documented in accordance with Article 33(5) of the GDPR, notified to the supervisory authority in accordance with Article 33 (1) of the GDPR, and communicated to the data subjects in accordance with Article 34 (1) of the GDPR. The organisation also needs to update and remediate its organisational and technical personal data security handling and risk mitigation measures and procedures.

Organisational and technical measures for preventing/mitigating the impacts of ransomware attacks

The Guidelines outline a list of non-exhaustive advisable measures for preventing ransomware attacks, which include, but are not limited to:

• Keeping the firmware, operating system and application software on the servers, client machines, active network components, and any other machines on the same LAN (including Wi-Fi devices) up to date. Ensuring that appropriate IT security measures are in place, making sure they are effective, and keeping them regularly updated when processing or circumstances change or evolve. This includes keeping detailed logs of which patches are applied at which timestamp.
• Designing and organising processing systems and infrastructure to segment or isolate data systems and networks to avoid propagation of malware within the organisation and to external systems.
• The existence of an up-to-date, secure, and tested backup procedure. Media for medium- and long-term back-up should be kept separate from operational data storage and out of reach of third parties even in case of a successful attack (such as daily incremental backup and weekly full backup).

Data exfiltration attacks

The Guidelines note that attacks that exploit vulnerabilities in services offered by the controller to third parties over the internet, e.g. committed by way of injection attacks (such as SQL injection, path traversal), website compromising and similar methods, may resemble ransomware attacks in that the risk emanates from the action of an unauthorised third party, but those attacks typically aim at copying, exfiltrating, and abusing personal data for some malicious end. Data exfiltration attacks are mainly breaches of confidentiality and, possibly, also data integrity. The Guidelines note that, at the same time, if the controller is aware of the characteristics of this kind of breach, there are many measures available to controllers that can substantially reduce the risk of a successful execution of an attack.

CASE No. 05: Exfiltration of job application data from a website

Case summary:

'An employment agency was the victim of a cyber-attack, which placed a malicious code on its website. This malicious code made personal information submitted through online job application forms and stored on the webserver accessible to unauthorised person(s). 213 such forms are possibly affected, after analysing the affected data it was determined that no special categories of data were affected in the breach. The particular malware toolkit installed had functionalities that allowed the attacker to remove any history of exfiltration and also allowed processing on the server to be monitored and to have personal data captured. The toolkit was discovered only a month after its installation'.

Prior measures and risk assessment

The Guidelines highlight in this example that the security of the data controller's environment is extremely important, as the majority of these breaches can be prevented by ensuring that all systems are constantly updated, sensitive data is encrypted, and applications are developed according to high security standards like strong authentication, measures against brute force, attacks, and 'escaping' or 'sanitising' user inputs, etc. Additionally, these types of vulnerabilities may be detected and addressed through the use of periodic IT security audits, vulnerability assessments, and penetration testing. The Guidelines illustrate that, in this particular case, file integrity monitoring tools in production environment might have helped to detect the code injection.

In order for a controller to assess what measures are necessary to be taken following a breach, the controller should first identify the type of the attack and its methods. An incident response plan allows speed and efficiency. The plan should outline the necessary steps to take control over the incident. The Guidelines note that in this particular case, the type of the breach was a risk enhancing factor since not only was data confidentiality curtailed, the infiltrator also had the means to establish changes in the system, so data integrity also became questionable.

The Guidelines further clarifies that the nature, sensitivity, and volume of personal data affected in the breach should be assessed to determine to what extent the breach affected the data subjects. Although in this example the breach did not affect special categories of personal data, the data that was accessed could be misused in a number of ways (targeting with unsolicited marketing, identity theft, etc.), as it contained considerable information about the individuals. Therefore, the Guidelines outlines that the severity of the consequences should increase the risk to the rights and freedoms of the data subjects.

Mitigation and obligations

The Guidelines note that, for this example, a number of consequences arise from the breach. After the problem has been solved, if it is possible, the database should be compared with the one stored in a secure backup. The IT infrastructure should be updated as a result of the knowledge gained and experiences drawn from the breach. The Guidelines note that the data controller should return all affected IT systems to a known clean state, remedy the vulnerability, and implement new security measures to avoid similar data breaches in the future, e.g. file integrity checks and security audits. In the case that personal data was not only exfiltrated, but also deleted, the data controller will need to, among other things, take systematic action to recover the personal data in the state it was in before the breach.

The Guidelines highlight that in light of the above circumstances, as the breach is likely to result in a high risk to the rights and freedoms of natural persons, the data subjects should definitely be informed about it (Article 34(1) of the GDPR), which of course means that the relevant supervisory authorities should also be involved in the form of a data breach notification. The Guidelines further note that documenting the breach is obligatory according to Article 33(5) of the GDPR and makes the assessment of the situation easier.

Organisational and technical measures preventing/mitigating the impacts of hacker attacks

The Guidelines outline a list of non-exhaustive advisable measures for preventing the impacts of hacker attacks, which include, among others:

• State-of-the-art encryption and key management, especially when passwords or sensitive or financial data is being processed. Cryptographic hashing and salting for secret information (passwords) is always preferred over encryption of passwords. The use of authentication methods obviating the need to process passwords on the server side is preferable.
• Keeping the system up to date (software and firmware). Ensuring that all IT security measures are in place, making sure they are effective and keeping them regularly updated when processing or circumstances change or evolve. In order to be able to demonstrate compliance with Article 5(1)(f) in accordance with Article 5(2) of the GDPR, the controller should maintain a record of all updates performed, including also the time when they were applied.
• Use of strong authentication methods like two-factor authentication and authentication servers, complemented by an up-to-date password policy.
• Secure development standards include the filtering of user input (using whitelisting as far as practicable), escaping user inputs, and brute force prevention measures (such as limiting the maximum amount of retries). 'Web Application Firewalls' may assist in the effective use of this technique.

Alahi Fozlay Privacy Analyst
[email protected]