You must have surely heard a thing or two about GDPR. It’s short for General Data Protection Regulation, being EU’s latest regulation as regards privacy and data protection. It has entered into force on the 25^th of May 2018.

There’s a whole bunch of articles out there, surely you must have opened at least one, just out of curiosity.

I wouldn’t want to turn this post into a GDPR tutorial, as I also do not pretend to be a GDPR connoisseur, but just to stress out some of the implications the new regulation has on cyber security operations developed by SOCs, CSIRTs, cyber security companies etc.

One of the things that bothers me as regards GDPR is its utmost complexity. It has become almost impossible, for laymen, especially for those managing small businesses, to identify what’s the impact upon his business so as to determine what is to be done to become GDPR compliant. Applying GDPR to a company is so utterly complicated that you surely need consultancy for that. GDPR is nothing like a clear and straightforward guideline or standard, but a series of disparate rules that cannot be taken as granted but have to be understood and applied in particular contexts. We could say that we are in an early stage, but it’s more than a year since GDPR entered into force and there’s still a lot of ambiguity. Not saying that it’s good or bad, but the EU has certainly managed to develop a whole new industry here.

When talking GDPR you have to be aware of the main concepts and definitions behind. Well, here they are, in short.

• Personal data: anything that can lead to the identification of a person, meaning IPs, phone numbers, car registration plates etc. Depending on the context, anything can become personal data, even your shoe size.
• Controller: the organization that has the purpose and means of processing your data. Usually the one that you authorize to process your data.
• Processor: the organization that is actually performing the processing, as in hosting the technology used for processing (e.g. cloud provider).
• Consent: any “freely given, specific, informed and unambiguous indication of the data subject’s wishes” by which agrees on his/her’s data being processed.
• Personal data breach: breach of security leading to the destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or processed.
• Special categories of personal data: racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data, sexual orientation, health data. These types of data have a special processing regime, so better stay away. If you indeed need to process them, be sure to take all necessary measures.

Furthermore, before jumping into the problem, several basic principles must be stated. Bear in mind that, as stated above, all the principles below might be subject to a lot of interpretation, so do not expect to be knowledgeable only after reading this blog post. It’s just to give you an idea and get you started. Necessary actions depend a lot on the context of the data processing.

• GDPR is mandatory for controllers and processors in EU (regardless of whether the processing takes place in the Union or not), but also for entities outside EU processing data of EU citizens (offering of goods and services, behavior analysis while persons are in EU).
• Data must be processed lawfully, fairly and in a transparent manner. Lawfully means that there has to be a legal basis for the processing (consent, legal obligation etc.). Transparent means that you have to inform subjects about the types of data you process, you have to be open about what you process.
• Purpose limitation and data minimization: you must process only the necessary data (not all the data you can get) and only for the scope declared. If a customer registers on your website in order to buy a product, you cannot take advantage and sent also marketing offers (unless consent has been given for that also).
• Data should be subject to storage limitation, meaning you only store it for the necessary amount of time. Sometimes storage limits are imposed by law, otherwise you have to specify them within your public data processing policy.
• Data security must be assured, mainly integrity and confidentiality, so as to prevent unauthorized or unlawful processing and against accidental loss, destruction or damage.

Now, after this short and narrow introduction, let’s dive into the cyber security operations domain. If you are connected a bit with the topic you surely know that the daily job of a security analyst, circles around many indicators of compromise (IOC) that might contain: names, email addresses, phone numbers, IPs, MAC addresses, file hashes or even file attachments, host names, URLs etc. Judging by the description provided above we might just include all of them into the personal data category. Yes, even file hashes, as they uniquely identify a certain file, that might belong to a certain person. And as you might also know there is a certain number of false positives within the daily alerts that analysts get.  As shown in this blog post, a 1% false positive rate for a security device, can actually increase the investigation effort about 10 times. Meaning that you will actually investigate 10 times more alerts than needed. For all those false positives you will start collecting additional data that in the end will turn out to be useless. Nobody says you should not do it, but the question comes if you need to apply data minimisation and storage limitation in those cases. Of course, there are justifications for keeping that data for a certain amount of time, but this has to be clearly mentioned within the terms and conditions. Another aspect is that investigations usually cover resources outside your organization (emails, supposedly rogue servers, DNS records and all other stuff that will allow you to track down the source of an attack). In case false positives, all those will belong to legit persons. Should analysts ask for their consent when processing their data? 😊

Another aspect that’s worth mentioning is about all that telemetry that everybody collects. You would be naïve to consider that telemetry does not contain some personal data, at least every once in a while. Anonymizing data should be the answer here, but by doing this you usually loose the link  between data and the subject. If you still want to keep a link between the data and the client, you usually apply pseudo-anonymization. Difference between the two, clearly explained in this  ICO webpage, but in short, pseudo-anonymized data is considered personal data, while anonymized data is not. So, we’ll go by the assumption that telemetry contains personal data. SOCs or MSS providers should make sure they are covered, when collecting telemetry, meaning to have the proper legal basis or consent in place.

One popular approach within the industry is the inter-sharing of telemetry data, between companies. Again, there is no specific clause forbidding that, it can be done, but only when having all prerequisites in place.

Personal data transfers to third countries or international organizations are regulated through a whole chapter within GDPR, namely Chapter V. In short, transfers should be done only if “adequate level of protection” is assured. So better think twice before you start exchanging that telemetry with anybody.

Another important aspect that you should bear in mind, when performing security operations, is the data breach notification obligation, described in Art. 33. The notification to the national data protection authority should not happen later than 72 hours, after having become aware of the breach. The security analysts will probably be the first ones to discover a data breach, so a process should be in place so that you (or the client) don’t miss this deadline.

Anyway, there is hope in cyber security, even after GDPR. Actually, security operations could be among the less impacted industries and this thanks to recital 49, which mentions that “the processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security […], by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned.”

Having this in mind, pls. make sure that you keep the data processing fair by applying purpose limitation, data minimisation, storage limitation, you keep your data accurate and, of course, you keep it secure (integrity and confidentiality).