A first part of a dedicated GDPR guide has been published to help you building your GDPR compliance and get you started with your General Data Protection Regulation journey, along with a White Paper that can serve as a support to initiate your GDPR compliance.
4D recommends that the GDPR compliance journey starts by focusing on four key steps:
Discovery: locate the systems storing personal data.
Management: limit which personal data is accessed, and by whom.
Protection: Implement an appropriate level of security to prevent and detect vulnerabilities and data breaches.
Reporting: make sure you have the right procedures in place to detect, report, and investigate a personal data breach.
This second part of the GDPR guide describes how these steps specifically apply to your 4D based product, as well as providing you with best practices while evaluating several existing 4D built-in features that can help you on you journey to GDPR compliance!
This is the first step where you need to locate where personal data is stored and identify which data qualifies as personal according to the GDPR. Which databases contain personal data? Which fields or records can be marked as containing personal data?
Personal and Sensitive data as defined by GDPR is anything that contains:
- Directly identifying information such as a person’s name, surname, phone numbers, picture, etc.
- Pseudonymous data or indirectly identifying information, which allows the singling out of individual behaviours.
4D has published a White Paper providing you with a reference document to identify what personal and sensitive data are, and presenting you in a didactic and simple format, what the regulation impacts are for a software developer or software publisher.
What GDPR requires?
GDPR has defined the personal data requirement in Article 4, section 2 as: ” ‘Processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction”.
How 4D helps?
Use comment fields
4D provides mechanisms to help you identify personal: for instance, in the Structure Editor, you have for each table AND for each field a Comment field, where you can write a note indicating that this structure contains personal data and therefore is concerned with the GDPR. It is possible to use Find in design search capabilities to search for keywords used as comments for personal data in fields/tables.
You can find the whole database example along with detailed explanation in this blog post.
Another recommandation by 4D, is the use of regular expressions (regex) to detect any data that is considered as personal by GDPR. Regular expressions can be used to locate sequences that follow the known patterns of various types of personal data. For instance, numbers that match the number of digits for EU passports, or a EU Debit Card Number.
Once personal data is located, mapping the attack surface and appropriate access policies should be put in place to reduce risks of unauthorized access or loss.
What GDPR requires?
In article 39, GDPR talks about ensuring the security of personal data: “Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorized access to or use of personal data and the equipment used for the processing.” And here comes the role of authentication. As for authorization, GDPR mentions in article 25: “the need for mechanisms which limit access to data, requiring measures [that] shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.”
How 4D helps?
4D provides multiple means of controlling access to data. Beside a security review to map the attack surface area, fundamental mechanisms that address this are: Authentication and Authorization mechanisms, which can help manage database permissions.
4D supports three types of authentication:
- Built-in authentication system: login and password checking.
- External authentication: 4D Server application can delegate the authentication to your Active Directory and get the Windows session login, which can be used to log a 4D user into an application via standard login method.
- Customized system: 4D provides a set of tools and commands to build a custom authentication system.
This table summarises best practices for 4D authentication:
|A customized system||
It’s highly advisable to control database access, especially when there is more than one user. 4D’s access control system is based on users and groups. After creating users, you can put them into groups, and assign each group the appropriate access rights. Groups can be assigned access privileges to specific operations.
Since the access system is not activated by default, it’s recommended to activate it by assigning a password to the Designer account, then all the access privileges you have assigned to forms, menus, and methods will take effect. Keep in mind that access policies should stand for the principle of least privilege, which requires that users and applications always log in with the minimum privileges required to perform their task.
manage your access points
It is necessary to identify and understand the data access policies to reduce the attack surface area. And that can be achieved by a security review to map the attack surface of the 4D database by understanding what features and capabilities are enabled that can be used to gain access to data in hidden ways.That’s why 4D recommends to disable all features that are not in use to reduce this risk. For example if your application does not need external SQL access (via ODBC), it is recommended to disable the external SQL access completely (using Database Setting or via ON SQL Authentication). Internal SQL commands are not impacted by disabling external access. Similar for external Web access, Web Service access or the PHP interpreter, disable them if you do not need them. It is also recommended to disallow global execution rights of project methods and control execution via white listing (Database Setting, Security tab, Filtering of commands and project methods option).
An additional thing to mention, you should be aware of all the access points to your 4D server (HTTP, SQL, and application), this way you have more control over how users can access your application.
Limit Security Risks From Plugins
Every plugin you install increases your attack surface. Running an external code raises the odds of having a security vulnerability since it represents another developer you are relying on to keep your best interests in mind. 4D recommends to only download plugins from known developers and remove abandoned plugins.
In the two previous steps, the focus was on discovery of where the personal data is located and how the access can be limited. The aim was to create access controls to data by enabling only authorized access. In this phase, the focus shifts to the data itself, and the mechanisms and best practices 4D has to offer to thoroughly protect it.
What GDPR requires?
Protecting personal data against security threats is declared as a core requirement of the GDPR. There are multiple articles emphasizing the importance of this obligation.
As a starter, GDPR requires that organizations implement “Data protection by design and by default” GDPR Article 25.
Article 32- section 1- also states that an organization must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk:
- The pseudonymization and encryption of personal data.
- The ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services.
- The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident.
How 4D helps?
TLS (Transport layer security)
4D Client/Server connection, 4D Web Server and 4D SQL Server can communicate securely via TLS. It’s highly recommended to avoid unencrypted communications, and it’s up to the developer to deny or redirect requests made in a non-secure manner. This ensures that data is encrypted in transit to and from the database, and reduces susceptibility to “man-in-the-middle” attacks.
To activate encryption of 4D Client/Server communications, go to the Client-Server/Network options page of the Database Settings and check the option “Encrypt Client/Server Connections”. To do the same for web connections, go to the Web/Configuration page of the Database Settings and check the “Enable TLS” option.
PFS (Perfect forward secrecy)
Perfect Forward Secrecy (PFS) is a property of key agreement protocols ensuring that a session key derived from a set of long term keys cannot be compromised if one of these keys is compromised in the future.
PFS is enabled by default in 4D Web Server just make sure that the TLS protocol is enabled and that your cipher list contains one or more ECDHE or DHE (which is true by default).
4D provides you two security-oriented functions to store a password hash, as well as making sure the stored hash matches the given password. When using these functions, passwords are never stored in the database, this ensures a good level of security. Additionally, both commands are based on the bCrypt algorithm which is slow by design. Thus, making it resistant to brute force attacks and minimizing potential impacts.
4D allows you to encrypt data at a database level – on a per table basis. It converts selected data into an unintelligible, encrypted format, to protect its confidentiality. Encrypted data can only be decrypted and read if the matching encryption key is provided. Encryption key can be given by the user via a passphrase, or by plugging an USB device on which an encryption key file was previously saved. During the working session, 4D maintains in memory the list of provided encryption keys. Data file encryption can be monitored using the MSC or dedicated commands.
An entirely encrypted hard drive can also provide strong protection. Employing hardware solutions like encrypted SSDs or software like BitLocker (Windows) or FileVault (Mac) is always a good idea. Self-encrypting drives use an encryption engine built into the SSD’s controller to encrypt every file. Due to the inherently faster technology in SSDs, you can perform every day storage tasks much faster than a hard drive, while simultaneously improving your data security. In some cases, like in virtualised environments, it could be useful to encrypt only the folder containing your database. Microsoft Bitlocker supports these as well.
In this step, GDPR requires to notify a data breach to the supervisory authority. A personal data breach can be defined a security incident that has affected the confidentiality, integrity or availability of personal data. There will be a personal data breach whenever any personal data is lost, destroyed, corrupted or disclosed.
What GDPR requires?
Regarding auditing and logging that is a part of data protection, GDPR designates a requirement that “Each controller… shall maintain a record of processing activities under its responsibility.”
In addition to that, GDPR has a requirement concerning data breaches that states: “In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority”.
How 4D helps?
auditing and logging
Auditing tracks database activities by writing events to an audit log. For instance, 4D allows you to obtain a log of HTTP requests -(Database Settings on the Web/Log (type) page)- which allows you to understand, analyze and investigate activities to identify potential threats or security violations.
Also note that 4D provides an out-of-the-box transactional-based log system. Every data modification operation is logged and can be rolled back if necessary. In case of an emergency, transactions can be restored – nothing is lost. In case of an interruption, the database is automatically reviewed upon restart and any missing operations (i.e. those in memory, not stored to disk yet) are restored, to return the database to its prior state. Even in case of total data corruption (i.e. bad disk, etc.…), the data file is automatically restored from the last full backup and a journal (transaction log file) including the most recent work is integrated.
4D allows you to keep an eye on your server by retrieving detailed information about your 4D Web Server, as well as a list of connected users and running processes. This way, you’re aware of what’s going in case of a data breach.
4D provides many built-in features to help you meet various requirements of the GDPR, and helps to significantly ease this process. From an authentication and authorization system, to various capabilities to protect and maintain the availability of data. We hope this compilation of best practices can help you with your GDPR compliance journey.