Data security & privacy

Reframe Data is a “Cloud Services Made in Germany” certified company. CONNECT is hosted on servers in Germany being fully compliant with German and EU guidelines. 

Reframe is built on a modern software technology stack. We guarantee a system and data security on all three levels of security (system infrastructure, software and databases).

Access to the Reframe is secured by an state-of-the-art identity management system (https://www.keycloak.org/) following the OAuth 2.0 security protocol.

Reframe includes a role-based permission scheme. This means that users get access to different sections of the system based on their roles. For each role, certain permissions can be granted per section to view, edit and/or create data entries. The user accounts and permissions can be managed via a user interface in the system.

Permissions can even be connected to dynamic elements, e.g. countries, provinces, schools, action areas or projects.

Personal data will be processed on behalf of the client. Therefore, an agreement on “Outsourcing of data processing (AuV)” will be concluded with the contractor in accordance with Art. 28 GDPR. For this purpose, the technical and organisational measures (TOM) for compliance with the data protection requirements must be outlined prior to conclusion of the contract. If the contractor has already been audited by GIZ in the past, an update in accordance

with GDPR must nevertheless be sent. After a positive check, the contract is concluded with the AuV attachment.

When developing data processing systems on behalf of the GIZ, the contractor must comply with the provisions of the GDPR and some local laws (which must be verified, especially in non-EU countries) regulating such systems, as they (the systems) are meant for the processing of personal data. In this regard, compliance with the requirements of data protection by design and by default becomes imperative, when creating Apps, software, websites, monitoring cameras, and any other tool that is used to process personal data.

At the centre of such considerations for privacy by design and by default are data protection principles and the rights of the data subjects. The most relevant data protection principles here are: lawfulness, transparency, data minimization, storage limitation, accuracy, and most especially, integrity and confidentiality. The principle of integrity and confidentiality, for instance, demands the application of privacy enhancing technologies, such as access control
(through strong passwords), authentication, encryption, pseudonymization etc., to protect against data breaches. The practical implication of these principles is well elaborated in Annex 4 (“The development of a data processing system under the GDPR”).

Parallel to the above-mentioned principles are the numerous rights accorded to the data subject, which cannot be given less weight. As a matter of fact, the GDPR requires the controller to facilitate the exercise of the data subject’s rights. The system must foresee and provide the possibility for the exercise of the following rights: the rights to rectification; erasure; and data portability; the right to withdraw consent; rights to restrict or object to processing (with these last two requiring the temporal deactivation of the profile without deleting his personal data).

Information Security (Hardening of the system)

Hosting of the application: An ISO27001 certified hoster must be selected for hosting.

The system must be hardened against cross-site scripting (XXS) and SQL injection.

XXS: Protect the web server from reflected or persistent cross-site scripting by securing the server source code. All data to be processed by the server must be checked before execution. Whitelists of allowed data can be used for this purpose. General conversion of certain script characters is also a popular method. This prevents executable metacharacters of scripts from being read by the server.

SQL Injection: Checking, filtering and cleaning user input. The input must have only expected properties and characters and must not contain any unauthorized metacharacters that are passed to the SQL interpreter. Another protective measure is the restriction of user privileges. A web application that authenticates itself to a database server via a user should always have only the privileges it actually needs -> principle of minimal privileges.

When implementing API interfaces, it is essential to harden them against the introduction of malicious code (SQL injection, etc.) via the URL.

Appropriate filters must be provided for the upload of files so that no files with executable scripts or SQL codes can be uploaded and executed.

When configuring the web server, you must pay attention to the following

• minimum number of digits e.g. 12
• latin capital letters (A-Z)
• lower case Latin letters (a-z)
• basic digits (0-9)
• non-alphanumeric characters (like !, $, #, -, &)
• your password must not contain the whole or parts of your login name!
• after 5 wrong entries the account should be locked for 3 minutes
• max. password age 90 days
• password history, at least 5 different passwords in before a previously used password is accepted again, new passwords that differ only by consecutive numbers should not be accepted.

2-factor authentication (2FA) is to be implemented, the use of the Google Authenticator for this purpose is to be refrained from. 2FA should be possible via several channels (app or SMS).

A role and authorization concept must be implemented that includes at least the roles System Admins (full authorization to the entire system), CMS Admins (account management), Editors and Authors (editing content/articles).

Only the following user groups will have access to the backend: Developers and administrators of the contractor as well as employees for the editorial maintenance of the client. Therefore, only very limited user groups may have access to the backend.

If possible, the application (web server + application) and data (database server with database) should be separated, i.e., the application and data should be installed on different systems.

The communication of these systems must be secured via a firewall.

A system log must be implemented, in which at least logins and logouts of all users and actions such as updates, backups, uploads and downloads are documented. The inclusion of further log data is still to be discussed in detail with the project.

The periodic backups of the complete system are to be carried out by the contractor and checked accordingly for restore. The backup can be stored on the server, but a copy must always be stored offline to prevent losses due to hacker attacks. The intervals for the backups must be coordinated with the project.

Separate environments for development, testing and production must be provided. The storage and transmission of sensitive and/or personal data must comply with current encryption standards.