Thanks to the GDPR, the attention of organisations 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, organisations have to be concerned about not just customers, clients and prospects, but their own employees and contractors as well. In fact, organisations 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.
These kinds of details are not the only PII that organisations routinely collect about employees and contractors. 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 login 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 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? 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?
Good news is that you don’t need consent from the users of your internal network in order to process their personal data. Network and information security are legitimate reasons to process and store personal data under this clause, as confirmed in Recital 49 of the GDPR. Also, you don’t break the “privacy by design” principle by using your security monitoring and data discovery solutions for security purposes — with one caveat.
Article 30 of the GDPR requires organisations 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.
A few more tips for ensuring compliance. 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:
- 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.
By Matt Middleton-Leal, EMEA General Manager, Netwrix
PrivSec Conferences will bring together leading speakers and experts from privacy and security to deliver compelling content via solo presentations, panel discussions, debates, roundtables and workshops.
For more information on upcoming events, visit the website.
We have been awarded the number 1 GDPR Blog in 2019 by Feedspot.