Addressing Data Across Borders for the GDPR
Most enterprises today do business across the globe, have databases in multiple countries and DBAs or users in different regions who have access to those databases. With GDPR mandating privacy requirements for personal data of European Union (EU) residents and visitors, it is important for an organization to know and control who accesses that data and what those with access authority can do with it.
Chapter 5 of the GDPR addresses “data transfers to third country or international organizations” and Article 44 of Chapter 5 specifically talks about “general principle for transfers”, which outlines the requirement for preventing unauthorized data transfers outside of EU member states.
Compliance with GDPR Article 44 requires either:
- Blocking transfer of personal data outside the EU; or
- Ensuring adequate data protection
Imperva SecureSphere can help organizations comply with the GDPR by blocking the transfer of personal data outside the EU and ensuring adequate data protection. In this post, I’ll review how the SecureSphere database security solution can not only classify sensitive data and prevent it from crossing a specific geographic location to meet the Article 44 requirement, but also generate audit logs and reports that can assist with investigations, reporting mandates and data forensics (Figure 1).
Figure 1: Imperva SecureSphere helps enforce cross-border data transfers by mapping to GDPR requirements
Many organizations are not aware of all the databases that exist in their network. Often times, a DBA may create databases to test an upgrade for example, then forget to take it down, thus leaving a database containing potentially sensitive data unsecured and unmonitored. SecureSphere Database Discovery scans and reports on all the databases that exist in the network, providing you with detailed information on each including IP address, port number, OS type and version (Figure 2).
Figure 2: Database Discovery scan results
After database discovery, it is important to understand what kind of data exists in your databases. The goal here is to look for any sensitive or privileged information. SecureSphere can identify sensitive data using column names or a content-based search using regular expressions making it highly accurate (Figure 3).
Figure 3: Data classification scan results
Security policies play a key role in protecting against known/unknown attacks and threats and complying with regulations and organization guidelines. Let’s say for example you have two DBAs in different countries trying to access a database in Germany. You would need to define and enforce security policies that ensure the DBAs are accessing only the data they are authorized to access based on their location (Figure 4).
You can set up a security policy in SecureSphere that allows Mark, a DBA in Germany, to access the database in Germany, but block access by Franc, a DBA in Singapore, as Franc should not be allowed access due to his geo location (Figure 5).
Figure 4: User role and location mapping
In our example, SecureSphere’s security policy is tracking and blocking based on:
- User first name, last name and role
- From which country they are accessing the data
- What query are they trying to run
- Which database they are trying to access and if that database contains any sensitive information
Figure 5: SecureSphere security policy blocks a DBA in Singapore from accessing a German database
Auditing is necessary as it records all user activities, provides visibility into transactions, and creates an audit trail that can assist in analyzing data theft and sensitive data exposure.
In the snapshot below, you see response size “0” for the DBA in Singapore, confirming he was not able to access and perform a query on the database in Germany. Whereas the DBA from Germany has a response size of “178”, indicating he was able to execute the query and access the database (Figure 6).
Figure 6: SecureSphere audit logs showing database activity
Measurement and Reporting
SecureSphere can also create detailed reports with charts using multiple parameters such as user, database, schema, query, operation, response size, sensitive data access, affected rows and more (Figure 7). This information can be used to report on activity that assists in maintaining compliance with various regulations.
Figure 7: Create and manage reports on database activity