General Data Protection Regulation - Implications and Tooling for GDPR Readiness, Part 2 of 2

February 28, 2018

Part II

How U2 can help address GDPR requirements – Practicalities

The simplest way to illustrate this is probably by example, as while a picture may paint a thousand words, a real-world example can speak volumes.

Scenario: The example picked is that of a Solution Provider offering Software as a Service (SaaS) to multiple business clients. The application used is the same for the various SaaS clients using the service, and the individual client data is held in separate data accounts on the same server. The Service is cloud-hosted by a third-party commercial hosting service and multiple clients.

Requirement: Information on all Data Subjects is available and visible only to the specific SaaS customer using their specific account-based environment. Subsets of the data are only available to specific individual users of each SaaS service according to rules laid down under GDPR and the Data Controller. The data must not be exposed to the SaaS service provider, while still allowing the SaaS Service provider to perform normal housekeeping, maintenance and software-related tasks. In other words, there is a “hard wall” between the roles of:

• System Administrator – a mix of the cloud service provider and SaaS Service provider with responsibility for the operational environment. No access to data.
• Data Controller – has responsibility for but not access to data within their specific data (account) subset.
• Data Administrator – Performs day-to-day database administration tasks. Has access to accounts and files within their purview for (for example) resize and backup purposes but no entitlement to see data content.
• Data users –have conditional access only to specific data within the area administered by the Data Controller. Data Subject data to point being rigidly regulated in terms of who can see what and for which express – and limited – purpose.

Implementation and Tooling:

File and Account Physical Separation: The starting point would be to separate the SaaS application data into separate data accounts so that commercially separate data cannot be accessed by other SaaS Service consumers (“Consumers”). Or indeed, while technically accessible to the SaaS Service Provider themselves without the express (and temporary) permission of the Data Controller for a specific task. While separation of account environments is a routine task for U2 users the next step may be less familiar.

File and Account Visibility:

Within each Consumer environment, identify all the data files and separate them into groups:

• Non-confidential information: g. file dictionaries and similar.
• Secure information: basically, everything else that should be encrypted.
• Private information – information subsets at both the whole file and individual field level within the Consumer’ data that is available to only to specific groups or individual users.

Having separated the data into appropriate groups then start the encryption process for each data subset as identified. Taking a SaaS system providing sales and ordering for example:

• Files available to all
  • ORDERS
  • GOODS-IN
  • GOODS-OUT
  • Etc.
• Files available to specific user groups – with field level separation
  • EMPLOYEE
    • Field subset of names and office contact details available to all
    • Field subset of home addresses and personal phone numbers available to HR, supervisors and managers only
    • Field subset of payroll data available to HR and line managers only.
  • Etc.

The tool of choice here is Automatic Data Encryption (ADE), where data is securely encrypted within designated files and the right to decrypt data is GRANTed to specific individuals. Each Consumer would have their own unique set of encryption keys that prevent unauthorised access to data – even for the highest level of O/S user such as “root” or “Administrator”. Optionally, an additional level of security requiring a key activation password can be implemented for the highest level of security. Any password used can also be forced to comply with local security policies for complexity, age length and potential re-use of the same password.

General Access: In this simplified example we have the ORDERS file and other files where all the data is available to all users. The appropriate choice here is WHOLEFILE encryption using a single encryption KEY that is GRANTed to all of an individual Consumer’s users.  Each user within the Consumer’s domain would have the requisite access, governed further by the application environment and any additional data constraints that might be (more later).

Restricted Access: The EMPLOYEE file is quite different in nature to the ORDERS file, in that some information is open to all of a Consumer’s users, and other data has restricted access. The choice here would be FIELD LEVEL encryption where different fields have different encryption keys, and the keys are only GRANTed to specific users within the Consumer’s community. Using this methodology, a user who has ALL the requisite keys GRANTed has open access to the contents of individual files. A user who has limited access can only access data to which they have been granted access to the appropriate keys.

Multiple key activation: ADE has the concept of a “Wallet”, where multiple keys can be kept together

Data at Rest / Automatic Data Encryption Summary

ADE therefore addresses the data administration requirements of GDPR by providing:

• A simple, safe and secure separation of data visibility by Consumer group, role and responsibility can be reasonably achieved. As an additional benefit, depending upon the implementation methodology it can either be introduced transparently to the application or bound by varying degrees into the application logic – e.g. prompting “On demand” for encryption password activation at the point of use and disabling the key immediately after data use. This approach helps mitigate against “piggy-backing” where one user might step over to another (unlocked) terminal when another more entitled user is away and try to take advantage of their access. As ADE encryption extends into all backup media, the built-in security extends into the full information lifecycle process for backup media until they are no longer required and are destroyed. Even physical possession of a full system backup is not sufficient to make use of encrypted data when appropriately configured.

Data Visibility in Transit:

When data is moving between a data provider or data consumer it can become exposed to “piggy-in-the-middle” attacks or network snooping. U2 provides secure data in transit using industry-standard data encryption protocols (e.g. TLS1.2) based upon the OpenSSL security standard and secure Certificates.

This option is available for all u2 communications interfaces where data might become exposed, including:

• UniRPC – used for UniObjects and client-server connections
• Query – ODBC / JDBC
• HTTP and Socket APIs
• Web Services
• Secure Telnet – while equivalent to Telnet, this is a distinct and separate service to the standard unencrypted Telnet service.

Internally within an organisation a “self-signed” locally-generated Secure Certificate may be acceptable. For the outside world however, a Certificate Authority (CA) certificate is the norm. A secure Certificate is a guarantee that data is encrypted end-to-end and comes from a warranted source. Optionally a client certificate may also be used to ensure that a data consumer is also an eligible data consumer.

Data in transit / Secure Certificates Summary:

By providing end-to-end encryption and external authentication via a Secure Certificate, U2 addresses the same GDPR requirements for data in transit as ADE does for data at rest.

Accountability and Auditing:

As part of the Data Controller role, it is important to know of any unauthorised access or “breach” and trace it back to the source. U2 implements a database AUDIT feature that allows secure recording of specified classes of database events to log files for archive and retrieval purposes.

At its most granular level, AUDIT allows recording of:

• Commands executed
• Programs run
• Data – and database – change events – down to a detailed individual record level
• Data access – even looking can be audited.

In this way, AUDIT allows day-to-day reporting upon activities at a statistical level to look for unusual patterns of activity that warrant further examination. It also provides configurable levels of detailed logging that can identify the smallest level of database activity in detail.

Accounting and AUDIT summary

As AUDIT logs are themselves encrypted, they are also covered by GDPR’s basic requirement of confidentiality-by-default as well as allowing a Data Controller a high degree of control and visibility of database use.

This feature has application not only for GDPR but also for mandated Compliance requirements for specific industry regulations.

Additional Data Constraints:

In any application system, the right to view data does not necessarily empower a user to modify the same data. While in major part this is governed by Application logic and controls, there still exists a possibility that a change could be made – either by an application logic anomaly permitting a change to be made, or by a system “event” of some form which might deposit a user at (arguably) one of the most powerful system locations – the command prompt.

There are two major tools to control access here – as well as the ever-present AUDIT feature which is global and records every event in background for forensic examination. These are:

File Triggers:

A file trigger exists where a coded subroutine is attached to a file and a file event – for example “BEFORE INSERT”. In this case any attempt to insert a new record would result in the subroutine being invoked before the data change was permitted. Here local logic can be implemented that can make a value decision as to whether the requested action should be permitted (for example) for this user, at this time, in this account and using this command. If the answer is YES, then the insertion proceeds. If, however, the answer is NO then the insertion is denied and cannot be made. In such a denial scenario further actions are normal, such as logging and a possible change in the user status – e.g. log off and disable the user account. Given that the same rules on who-can-do-what tend to be application-wide, the same trigger code can often be reused on multiple files so protected with no modification.

Security Subroutines:

Security Subroutines fulfil for executed commands the same function that file triggers perform for files. Any command in the VOC file that has a security subroutine associated will run a local security subroutine before the command can proceed. In the course of validation, additional logging or other processing can also be included (as with file triggers – above). On completion a security subroutine also answers “YES” and the command proceeds, or “NO” and the command is rejected. Any command in the VOC file can be similarly protected. And the same program logic in a single security subroutine is typically reused throughout a system as it is eminently reusable.

GDPR – overall – Summarising what has been achieved in GDPR terms:

U2 has addressed each of the IT operational areas of a data system in turn. It is part of a much larger jigsaw in which it can be used as a key tool for Regulation and Compliance. To reprise and taking each point in turn:

• ADE: Data is protected in storage – both current and archival – from both sight and change unless specifically authorised by user group or individual user basis, all under the control of the Data Controller. This satisfies the Data Use and Data Sharing requirements of data as held on the system – even if other user communities co-reside on the same server platform. Encrypted data is fully obscured even from Administrators – ensuring no unauthorised data access by operational staff.

With ADE even theft of data does not mean disclosure of information.  Without the multi-part encryption keys and passwords any encrypted data is very firmly beyond use.

• TLS Security: Data is both protected in transit and only accessible by authorised recipients on receipt.
• AUDIT: A full audit trail of events is maintained. This allows proactive monitoring of activity levels to identify suspicious patterns of activity and a forensic examination of historic events to identify any anomalies or potential breaches, satisfying a significant part of the Monitoring and Compliance part for GDPR.

Triggers and Security Subroutines further buffer Data Use controls and also provide monitoring capabilities as suspicious activity can result in immediate action and lockdown.

To see the number of days until GDPR goes into effect, visit www.eugdpr.org –  GDPR goes into effect on 25 May 2018.

For more information, read GDPR for Rocket MV Databases