Tignum header logo

TIGNUM X
IT SECURITY

I. INTRODUCTION

This document is intended to create transparency about our decision-making basis as well as an insight into our legal and technical measures with which TIGNUM protects its customer data. It is primarily written for the data protection and information security officer as well as the legal department of your company.

As part of the preparation for the GDPR, TIGNUM examined its hosting concept with regard to data security, availability and scalability. With the involvement of various experts (data protection officer, IT security consultant, etc.), a number of measures have been defined to achieve an optimal solution for TIGNUM X customers in the long term.

This decision of making Amazon Web Services (AWS) TIGNUMs hosting provider was made on the basis of a detailed analysis in which TIGNUM compared various providers and models. In addition to meeting strict security and compliance requirements, the main reason for AWS was the increase in stability and scalability of TIGNUMs infrastructure.

II. COMPLIANCE & LEGAL

The services offered and used by TIGNUM in the AWS region of Frankfurt and in the other European regions, such as RDS (database), S3 (storage for e.g. documents) or KMS (key management) as well as the computer centre in Frankfurt have numerous internationally recognised certifications, which have been attested by independent renowned consulting companies and prove the fulfilment of the highest security requirements.

The AWS region Frankfurt, other regions and corresponding services are certified for IT security according to DIN ISO/IEC 27001 as well as for the protection of personal data in the cloud according to DIN ISO/IEC 27018. In addition, AWS has had itself certified according to the internationally recognized Payment Card Industry Data Security Standard (PCI DSS). This standard is bindingly applied by credit card organizations and is considered one of the strictest security regulations worldwide.

AWS is also the first company to have the security of its cloud environment certified by the German Federal Office for Information Security (BSI) based on the Cloud Computing Compliance Controls Catalogue (C5). This makes AWS a pioneer for cloud security in Germany. An overview of all compliance programs and certifications of AWS can be found: https://aws.amazon.com/de/compliance/ programs/.

1. ENCRYPTION

TIGNUM is using the key management system from Amazon Web Services (AWS KMS). The keys used are derived exclusively from a master key (Customer Master Key - CMK), which is not generated in the AWS cloud and is only stored in encrypted form in the AWS KMS. As a result, Amazon has no access to the keys derived from it or to TIGNUM’s CMK itself. This means that AWS cannot decrypt the data stored in the cloud.

1.1. THE USAGE OF AWS KMS

TIGNUM is using the key management system from Amazon Web Services (AWS KMS). The keys used are derived exclusively from a master key (Customer Master Key - CMK), which is not generated in the AWS cloud and is only stored in encrypted form in the AWS KMS. As a result, Amazon has no access to the keys derived from it or to TIGNUM’s CMK itself. This means that AWS cannot decrypt the data stored in the cloud.

1.2. THE USAGE OF AWS KMS

AWS Key Management Service (AWS KMS) is a Managed Service that simplifies the creation and control of encryption keys for data encryption. The master keys in AWS KMS are protected by FIPS 140-2 validated cryptographic modules.

The following features are fundamentally supported by AWS KMS:
_Creation, description and listing of the master key
_Activate and deactivate master keys
_Create and view permissions and access control policies for the Master Key (Customer Master Key - CMK)

_Activate and deactivate the automatic rotation of the cryptographic material in a master key _Import cryptographic material into an AWS KMS master key
_Mark master keys for easy identification, categorization and tracking
_Deletion of master keys to complete the life cycle of keys

The following cryptographic functions are supported by AWS KMS: _Encrypt, decrypt and re-encrypt data
_Generate keys to encrypt data (Data Encryption Keys) _Generate random numbers for cryptographic applications

1.3. CONFIDENTIALITY

TIGNUM restricts these features due to their security requirements. The random numbers generated by the AWS KMS cannot be regarded as trustworthy, since the hardware used and the algorithms used to generate the random numbers are not disclosed. The security of key material and thus the encryption generated with it is largely dependent on the random components that are used to generate the key. Insufficient randomness or even interception and recording of the random components enables side-channel attacks on the encryption and thus the encryption is broken.

The generating is done using OpenSSL - an open-source encryption library with associated programs - on TIGNUM computers, usually on the work computers of the responsible and competent technical staff, and follows the corresponding state of the art. The key material created in this way is only encrypted and transferred to the AWS KMS. This ensures that AWS employees cannot access encrypted data that TIGNUM stores or processes as part of their order processing.

1.4. MONITORING

AWS KMS enables every access to the keys stored in it to be monitored in detail. Every access is recorded. This enables TIGNUM to ensure that there is no unauthorized access to the keys used to

encrypt the data. Access to the key management is automated and checked for irregularities at regular intervals and if a security incident is suspected, either manually by the defined IT Security Admin or by TIGNUM personnel commissioned by him. AWS KMS also enables you to monitor the exchange of keys and clearly assign them to the people who initiated the exchange.

1.5. STORAGE AND USE OF THE UNENCRYPTED KEY MATERIAL

Unencrypted key material is only kept unencrypted for as long as is necessary to create a CMK. For the purposes of archiving and traceability of the integrity of the keys created from it, the key material is stored in a version management system (Git) using Git-Crypt. Git-Crypt uses Pretty Good Privacy (PGP) encryption to restrict access to this data. Access to the key material archived in this way is only possible for employees of the Infrastructure team. If an employee leaves the team due to leaving the company or moving to another department, their PGP key is immediately removed from the Git repository and access to the key material is prevented.

1.6. DATABASE ENCRYPTION (“DATA AT REST”)

All databases used by TIGNUM use so-called "at rest" encryption. This means that the data can only be read from the database if proper authentication takes place on the respective database system. The files in which the data are stored are stored in encrypted form so that they can only be read by database systems that have the appropriate key for decryption. The same applies to any side channels of the database systems such as binlogs. As described above, the keys are managed in the AWS KMS.

1.7. ENCRYPTION OF STORAGE MEDIA

TIGNUM stores some data directly as files without using a database system. These are, in particular, documents and other uploads by customers as well as log data, which, however, may be associated with database content via IDs or identifiers. To ensure that unauthorized access to this data cannot take place, the storage media (AWS services EBS and S3) are encrypted. SSE-KMS is used for S3, which means that full control over the master key remains with TIGNUM. The use of SSE-S3 is prohibited if customer data or other sensitive data is stored on the storage media. The CMK provided by TIGNUM in the AWS KMS is used for EBS volumes. These master keys are also used to encrypt snapshots that are derived from the volumes (e.g. backups). Which CMK is used depends on the intended use of the system and its respective network in which it is located. See also "Data separation in the context of encryption”.

1.8. OTHER DATA ENCRYPTION

In addition, sensitive data that is not stored on the database or storage media is encrypted on the application side (e.g. caches).

1.9. TRANSPORT ENCRYPTION (“DATA IN TRANSIT”)

TIGNUM systems use transport encryption whenever data has to be transmitted via an insecure or public network (e.g. outside the virtual private cloud).

Which transport encryption is used depends, among other things, on the encryption requested by the client system. TIGNUM also provides some transport encryption algorithms for backward compatibility that are no longer classified as secure. However, only secure transport encryption is used within the company. It is the customer's responsibility to ensure that his client system supports and prefers the appropriate state-of-the-art transport encryption.

HTTPS

The web interface and the API of the TIGNUM application can only be accessed via HTTPS connections. It is recommended to use client systems for access that support at least TLS 1.2.

Administrative accounts

Access to TIGNUM’s systems for administrative purposes is made exclusively via VPN connections or via SSH in order to enable secure transport encryption. If SSH is used, the servers of TIGNUM only support SSHv2. The use of SSHv1 is prohibited in the company and all servers are configured accordingly by the responsible technical staff.

1.10. DATA SEPARATION AS PART OF ENCRYPTION

Just as TIGNUM ensures that the data is strictly separated between different networks (staging, BI and live), the encryption keys used for the different networks are also strictly separated. A key is only used in the network for which it was created. A transfer of keys to another network is not permitted and is prevented by technical measures. Regular security checks ensure that the technical measures taken are not bypassed by manual intervention. It also ensures that a key is always assigned to exactly one purpose. E.g. at infrastructure level, a key that is used for storage encryption cannot be used for database encryption at the same time.

2. RESPONSIBILITIESINTHEAREAOFDATAPROTECTION

TIGNUM has formed a data protection and information security team (DPIST) for all issues relating to data protection and data security, which consists of the following persons:

_Data protection officer (DPO)
_Information Security Management System Management Team (ISMS Management Team) _Legal Department

3. RESPONSIBILITIESINTHEAREAOFDATAPROTECTION

TIGNUM uses different levels of access control for its systems and services at AWS. These are managed using AWS's Identity and Access Management (IAM), which enables a fine granulation of access to various services within the AWS cloud and records access to the services. For TIGNUM, the highest principle in the allocation of rights is "need-to-know". In practice, this means that employees only have access to the functions they need to perform their tasks. Superordinate rights are reserved exclusively for technical management (CTO, HoIE etc.) or the ISM and are based on the dual control principle. They have the access data of the AWS accounts and are accountable to the DPIST. In principle, all other TIGNUM employees get a maximum of IAM accounts, which are limited to the rights they need for their work. The ISM checks in regular audits whether the assigned access rights

correspond to the need-to-know principle. Backend systems are only accessed via VPN. Public release of backend systems is prohibited. Only TIGNUM Infrastructure Team employees have access to the system level of TIGNUM's systems. This direct access is only used for error analysis. By encrypting the data, TIGNUM ensures that AWS employees cannot gain access to customer data. See also the section “Encryption”.

4. FIREWALLINGANDSECURITYGROUPS

Using security groups, AWS provides a packet filter firewall that restricts access to services of a server instance (EC2) or to SaaS services. TIGNUM uses this to ensure that services that run within the AWS environment are only accessible to the networks for which there is a need. This means that access to network ports of various services is restricted to such an extent that access is only possible through those other services that absolutely need access. The security groups are also used for network separation. See section "Network separation". In addition, the Linux firewall "iptables" is available on AWS EC2 instances that are used for TIGNUM's own software, which enables an additional granulation of the filter rules.

5. AVAILABILITYZONESANDGEOLOCATION

TIGNUM stores data in AWS data centers in Germany (Frankfurt). Contractual agreements ensure that AWS does not transfer any data from TIGNUM to other locations, not even for maintenance purposes (see also the "Compliance & Legal" section). Front-end and back-end systems operated by TIGNUM are mostly designed redundantly and are distributed over multiple zones. This ensures that TIGNUM X can be operated without restrictions even if an availability zone fails. Each availability zone is connected to several Internet service providers and is supplied by several circuits. They are connected by high-speed links, so that the applications, which are spread over several zones, can use LAN connections to communicate between the zones. This enables optimal performance of all systems used by TIGNUM X.

6. NETWORK SEPARATION

TIGNUM ensures separation of networks used for different purposes in the AWS environment by different VPCs (Virtual Private Clouds). Data transfer between different VPCs is prevented by the security groups described above.

7. LOGGING / AUDIT TRAIL

TIGNUM has the possibility to record all events within the cloud environment used and not only to create transparent user and resource activities, but also to provide a high level of transparency for forensic analysis of possible security incidents.

8. CHANGE MANAGEMENT

TIGNUM manages configurations of systems and software using "Infrastructure as Code". The associated code is stored in repositories of a version management (Git) in order to make changes in time and content traceable. Before changes are imported into the operating environment, they are tested in a staging environment that is similar to the operating environment. This applies to configuration changes as well as system and software updates.

9. BACKUPS

TIGNUM creates daily backups of all data necessary for the operation of the infrastructure in TIGNUM X. The back up is also periodically restored and routinely tested to ensure recovery objectives can be met as expected. And in case of electrical failure AWS provides a power supply back up.

10.PERFORMANCE AND AUTO SCALING

As far as possible, TIGNUM uses the auto scaling functions provided by AWS to ensure the best possible performance. This makes it possible to connect resources to the networks fully automatically when the available resources are no longer sufficient.

11. MONITORING

TIGNUM uses various monitoring tools to ensure maximum availability and performance of the application. These monitor at least the following parameters:

_Availability:

> Accessibility of the application

> Accessibility of backend systems and services

_Resource utilization of CPUs:

> utilization of network interfaces

> utilization of persistent and volatile memories

_Performance:

> Application Performance Index (Apdex) > Response times of the application
> Response times of backend systems
> Query times for database content

_Security:

> See section “Intrusion Detection / Malware Detection / Logging of security-relevant events”

> Update status of systems

_Monitoring:

> Error logs
> Access logs

In addition to this automated monitoring, ISMS Management Team monitor relevant online media and blogs for security vulnerabilities in order to be able to react promptly.

tignum logo

© 2021

TIGNUM Holding GmbH. All rights reserved.

TIGNUM GmbH is registered in the commercial register of the Amtsgericht (local court) Stuttgart under the number HRB Stuttgart 723762. VAT number as per § 27 a of the German VAT Act Umsatzsteuergesetz: DE255824932

  • LinkedIn
  • YouTube