Thanks to the GDPR, the attention of organizations everywhere seems to be focused on the personally identifiable information (PII) that they collect, process and store. Since the GDPR requires protecting the PII of all EU residents, organizations have to be concerned about not just customers, clients and prospects, but their own employees and contractors as well. In fact, organizations often store a lot more PII about the people who work for them than they do about customers: names, IDs, health records, credit card numbers, personal addresses, phone numbers and so on.
How your security and data discovery solutions might run afoul of the GDPR
But the fact is, these kinds of details are not the only PII that organizations routinely collect about employees and contractors. The GDPR defines personal data much more broadly, as “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”
That definition actually makes a lot of data that you probably process “personal data.” For example, your data-centric audit and protection (DCAP), security information and event management (SIEM), and user behavior analytics (UBA) collect and process information about each individual’s logon times, their actions in specific systems, their behavior patterns and possibly even their fingerprints. All that data is tied to a unique natural person — in fact, most of it has to be in order to achieve the goals you bought the solutions for, such as spotting abnormal behavior that could be an attack and ensuring individual accountability.
Moreover, your data discovery solutions make it extremely easy to extract PII about a particular individual from the files in your environment — again, by design, since you need to be able to do that to uphold the rights of data subjects.
Does this mean I need to stop using my security and data discovery solutions?
Does this mean you need to ask for consent from every user in your network, and stop monitoring their activity if they don’t give their consent or later withdraw it? And how do you comply with the “privacy by design” principle if your data discovery solutions enable employees to see the PII of an individual in a couple of clicks? Do you have to stop using your security monitoring and data discovery solutions altogether?
According to Article 6 of the GDPR, getting consent is just one of six criteria that make processing of personal data legal. Another criterion is when the processing “is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. ” (emphasis in original)
Network and information security are legitimate reasons to process and store personal data under this clause, as confirmed in Recital 49 of the GDPR:
“The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, 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.”
Therefore, you don’t need consent from the users of your internal network in order to process their personal data, and you don’t break the “privacy by design” principle by using your security monitoring and data discovery solutions for security purposes — with one caveat.
What more do I need to do to ensure my processes are GDPR-compliant?
Article 30 of the GDPR requires organizations to carefully document their processing activity. This documentation should include the following: the purpose of the processing, the categories of both the data subjects and personal data that’s being processed, and the categories of those to whom this data is disclosed. If you already have detailed security policies that thoroughly describe your monitoring activity, you might want to check for gaps in your documentation compared to what is required under the regulation. If you don’t have well-documented policies, you should work on them right away.
As you document the reasons for your security monitoring and data discovery activities, consider the impact of not performing these activities. If you are unable to mitigate cyber threats to the GDPR-regulated data you collect, process and store on your servers, how can you ensure the security of this data as the regulation requires you to? How could you uphold the rights of data subjects if you weren’t able to discover all their PII across your environment? Moreover, remember that the solutions you use to perform these activities often provide additional capabilities that help you reduce the risk of exposure of your audit trail and classified data to unauthorized people.
Any other tips for ensuring compliance?
Remember that the GDPR requires you to limit the amount of data you collect to what you actually need, so take advantage of the following capabilities, if your solutions offer them (and if you’re shopping for tools, add these features to your “must-have” list):
- Pseudonymization. This is one of the measures highlighted in the standard. It means to process personal data in such a manner that it can’t be attributed to a specific person. This functionality is more applicable to security monitoring solutions than data discovery tools. For example, some SIEMs can pseudonymize personal information in log files.
- Role-based access control (RBAC). RBAC enables you to control access to the audit trail and ensure that only selected individuals have access to the personal data in log files. Many solutions provide this useful feature. Some enable you to granularly limit the scope of data available to a specific person.
- Self-audit. Monitor user activity in your security monitoring and data discovery solutions themselves. This enables you to detect suspicious access or changes to the solution that could affect the confidentiality and integrity of personal data that can be accessed through these solutions. If your solutions don’t have a self-audit capability, you should at least closely monitor user activity on the machines where the solutions are installed. You can also use screen activity video recording on these machines to have more context around that activity.
Key takeaways
Let’s summarize the key steps you should take to ensure your security monitoring and data discovery processes are GDPR-compliant:
- Document your monitoring policies thoroughly. Include reasonable justification for why you perform security monitoring and data discovery; describe the types of personal data that is involved in these processes; and detail who will have access to it through your security monitoring and data discovery solution.
- Use pseudonymization whenever possible.
- Use RBAC to provide access to your security monitoring and data discovery solutions strictly on a need-to-know basis
- Whenever possible, monitor access to these solutions and changes made to them.
In addition to facilitating GDPR compliance, following these simple steps will also help you mitigate risks to the sensitive data you process and enhance your overall security posture.
