There seems to be a lot of confusion out there about how GDPR relates to security monitoring so I thought I’d take a moment to explain.
GDPR is a wide ranging piece of legislation which was introduced to standardise data protection across EU states. In many ways GDPR was not new, it simply brought different similar legislation in member countries into line. It did however introduce some pretty big penalties for companies who disregard data protection for EU located individuals and for that reason many companies have woken up to GDPR and worried that their security monitoring might fall foul of the regulations.
Let me start by saying that GDPR is meant as a protection for personal data. It was designed to protect individuals from bad or careless data practices and it put a duty of care on companies to protect that data. Security monitoring is one such security control so from that standpoint SIEM deployments are generally an expected GDPR control and contribute to the due-diligence for data protection the legislation is designed to encourage.
If you have a SIEM then there are certain things you must do to avoid flipping the SIEM from being a good thing in the eyes of an information commissioner to a bad thing. A SIEM is a security control; if you are also using it to do other things you are already on shaky grounds. Any company which uses it to monitor employee efficiency for instance, is not only going to find they have GDPR problems but will also very quickly run into problems with other European institutions.
As a security control it is expected that only security professionals will have access to it and that you can audit what actions they take. Weak access controls or a lack of a robust process around granting or revoking access will also be a problem for you. You may need to demonstrate that only those who have a need to access the SIEM can access it and that individuals who move to different roles automatically loose access at that point. You don’t need very granular Role Based Access Controls to particular data sources unless you are trying to do more than just security with your SIEM. A security person should be able to run an investigation without finding that some data is walled off from them – unless that data has nothing to do with security monitoring in which case, don’t put it in your SIEM.
On that subject be careful with how your parsers work and how you process data, particularly sources such as email and proxy. You are likely to find personal information in URLs and email addresses and subjects. If you don’t have a use case for this data then don’t store it. If you do then be very careful. This is where those audit logs for SOC teams is vital. You’ll need to identify people who go searching this data or focus on individuals without just cause. You also need to make sure you have robust controls around data export whether that is into downstream systems or into case notes for incidents. You need to protect the entire data chain when it contains this category of data. This is probably your only risk area as a URL or email header may well be valid security related data to collect. Here I think UEBA based systems have a lot to offer as you stop initiating investigations on the whim of an individual and do it based upon a behavioural algorithm.
One of the things I’m frequently asked about is the so called right to be forgotten.The actual GDPR element most people are thinking off is the right to request and have granted the cessation of processing. This is to allow individuals to ask for an organisation to remove them from mailing lists or to delete histories of their purchases or blog posts or other activities. Companies can deny this request if they see a good reason to do so and under some circumstances such a dispute might be escalated to a regional Information Commissioner. When it comes to security logs in a SIEM the defence that those logs form part of the record, not of the person but of their account or system activity. In addition, security breaches may come to light far into the future so such records must be maintained. As such there is no requirement what-so-ever to remove security logs relating to a departed user from your SIEM.
I also get asked a lot if users can opt-out of having their logs captured and analysed in a SIEM and the answer is an emphatic no. The defence is that the SIEM is a data protection control so opting out puts that control at risk of being ineffective. Remember, this is monitoring the account activity and accounts can be subverted by external or internal bad actors. To be really sure I’d advise putting that in employee handbooks and/or employment contracts, but even without that the defence is very solid.
SIEM managers also ask about adding contextual information to SIEM systems, users manager, their phone numbers etc. Here there is less certainty, but the rule of thumb is that if this enhances controls and makes the SIEM more effective you have the basis for a defence. Adding in their gender, or religion or such like takes you onto very shaky grounds and you would have to demonstrate how this improved security and no, some form or stereotype profiling is really not on. Keep context to a minimum. Organisational hierarchy and contact details are fine, organisational group membership is also fine but avoid things which are personal like age, race, or options on any subject. Ask yourself if you should even have that information.
GDPR was never designed to make security monitoring harder or less effective. Applying a little common sense normally gets you to the right answer when thinking about what you can and can’t do. Actually read the legislation, it isn’t too long and the language is actually fairly accessible, for a piece of compliance anyway. Most of the GDPR arguments I have had are with people, most often in house legal people not based in Europe, who have’t even bothered to read it. Having read it, take a moment to think about what it is trying to achieve. I see GDPR as a very good thing, as do most Europeans, and I certainly don’t see anything in it designed to make security monitoring more difficult. GDPR mandates robust access to sensitive data and a SIEM is a very valid secondary control and as such forms a vital part of GDPR compliance.
Oh and in case you are wondering, the UK adopted GDPR into British law before Brexit so the same rules apply to Britain as to the rest of Europe.