When incident response teams (CSIRTs) detect an attack on their systems, they normally report details back to the network or organisation from which the attack comes. This can have two benefits for the reporter: in the short term, making the attack stop; in the longer term helping that organisation to improve the security of its systems so they are less likely to be used in future attacks. The vast majority of attacks will not, in fact, be initiated by individuals within those organisations, but by third parties who have managed to compromise accounts or systems belonging to the organisation.
To be useful to the recipient (and therefore effective to the sender), such reports need to include details of the source, time and nature of the attack. e.g. “between 1400-1500 UTC on Friday 23rd Feb, your IP address 192.168.10.10 participated in an NTP DDoS attack against me”. It’s not usually necessary to give specific details of the systems or accounts attacked. However such a report is likely to constitute personal data, since it mentions a specific IP address, so be subject to data protection law. In some cases the addresses in the report will not in fact be connected to an individual, but the reporting organisation cannot be sure of that. Within Europe such reporting has been justified for some time as a legitimate interest of the reporting organisation (paper from 2011); however it has been less clear which legal provision applied when sending reports outside the EEA, thereby exporting personal data. The UK Information Commissioner has helpfully noted that when sending personal data back to where it came from the privacy expectations of that country, rather than of Europe, are relevant.
The Article 29 Working Party’s new draft guidance on exporting personal data is clearly aware of this issue, though perhaps not of how often it arises. The General Data Protection Regulation, for the first time, adds legitimate interests as a justification for exporting personal data. According to the guidance this can only be done where:
- Exports are “occasional” or “not repetitive” (p4): i.e. “such transfers may happen more than once, but not regularly, and would occur outside the regular course of actions, for example, under random, unknown circumstances and within arbitrary time intervals”. Since reports are only sent when an attack occurs, and the aim is to prevent future attacks, CSIRTs definitely do not intend them to occur “regularly within a stable relationship between the data exporter and a certain data importer”. Ideally, we’d like each reporting relationship to be used only once!
- Export is necessary for a compelling legitimate interest (p15): protecting network and information security is recognised as a legitimate interest by Recital 49 of the GDPR. Indeed the Working Party’s guidance gives as an example “to protect its organisation or systems from serious immediate harm” – a description that clearly fits a hacking or denial of service attack.
- All other legal grounds must be inapplicable (p15): it is highly unlikely that an attacker would consent to his attack being reported and investigated or that there will be time to establish a model clauses contract between the CSIRT and the organisation to which it needs to report the attack.
- Export must involve only a limited number of data subjects (p16): most reports will only involve one, or a small number of, IP or email addresses used in the attack.
- Export must be subject to safeguards (p17): the information in reports will almost always be pseudonyms, since the reporting CSIRT will have no way to link IP or e-mail addresses to individual users in the organisation to which it reports. Where possible the report will be sent to either a known CSIRT or the advertised security contact for the organisation: both can be expected to only use the information for the purpose of stopping the attack and fixing the security problem that permitted it.
- Export must balance the interests, rights and freedoms of the individual (p16): as noted above, in most cases any individual whose IP or e-mail address is contained in a report will also be a victim whose system has been compromised. Reporting should therefore result in that individual’s rights being enhanced (because the attacker’s access to their account, systems and data will be removed), rather than damaged. The safeguards listed above should further protect their rights.
- Individual must be informed of the export (p17): the effect of the report should be precisely to inform any affected individuals both that their data have been (re-)exported from the EEA and, more importantly, that they have a security problem that they need to address.
It therefore appears that European CSIRTs now have an explicitly recognised legal basis for sending incident reports overseas. Furthermore this is the same legal basis as used within Europe, so they can apply the same processes and policies to both groups of destinations.
The one requirement that may cause problems, though mostly for national regulators rather than CSIRTs, is that “[t]he controller shall inform the supervisory authority of the transfer” (Article 49). Neither the GDPR nor the new guidance indicate whether this should be done every time an overseas incident report is made, or whether a single general notification of the practice will be sufficient. Since a busy team may send tens or hundreds of incident reports per day, the latter would be better to protect regulators’ inboxes.
