APP.4.3 Relational Database Systems

Based on its general security policy, an organisation MUST draw up a security policy specific to database systems. This MUST describe requirements and specifications for the secure operation of database systems in a comprehensible manner. The guideline MUST be familiar to all employees responsible for database systems. It MUST be integral to their work. If the policy is changed or deviations from the requirements are allowed, this MUST be coordinated with the CISO and documented. The correct implementation of the policy MUST be reviewed on a regular basis. The results MUST be documented in an appropriate manner.

Database management systems MUST be hardened. To this end, a checklist of the steps to be performed MUST be compiled and completed. Passwords MUST NOT be stored in plain text. Basic hardening MUST be reviewed and adapted as required at regular intervals.

New databases MUST be created in accordance with a defined process. When a new database is created, basic information on the database MUST be documented in a comprehensible manner.

System backups of a DBMS and its data MUST be performed at regular intervals. The database system MUST also be backed up before a new database is created. The service programs permitted for this purpose SHOULD be used.

All transactions SHOULD be backed up in such a way that they can be recovered at any time. If the backup process would exceed the available capacity, an extended concept SHOULD be created to back up the database (e.g. incremental backups). The recovery parameters SHOULD be specified based on the protection needs of the data (see CON.3 Backup Concept).

Database management systems SHOULD be installed on sufficiently sized hardware. The hardware SHOULD have sufficient reserves in order to meet potentially increasing requirements. If resource bottlenecks become apparent during operations, these SHOULD be eliminated at an early stage. When sizing hardware, the growth expected for the scheduled deployment period SHOULD be taken into account.

A uniform configuration standard SHOULD be defined for all the database management systems deployed. All database management systems SHOULD be configured and operated in the same manner according to this standard. If an installation requires a deviation from the configuration standard, all steps SHOULD be approved by the CISO and documented in a comprehensible manner. The configuration standard SHOULD be reviewed and adapted as required at regular intervals.

It SHOULD be ensured that only persons accountable are authorised to create database links (DB links). If such links are created, private DB links MUST be preferred to public DB links. All DB links created by the persons accountable SHOULD be documented and reviewed at regular intervals. Additionally, DB links SHOULD be taken into account when the database system is backed up (see APP.4.3.A9 Backing Up a Database System).

A database management system SHOULD be configured in such a way that database communications are always encrypted. The cryptographic methods and protocols used to this end SHOULD comply with the internal specifications of the respective organisation (see CON.1 Crypto Concept).

The manner in which data should be transferred to a database initially or regularly SHOULD be defined in advance. After data is transferred, checks SHOULD be performed to ensure that it is complete and has not been changed.

The parameters, events, and operating states of a database management system that are critical for secure operations SHOULD be defined. These SHOULD be monitored using a corresponding system. Threshold values SHOULD be defined for all critical parameters, events, and operating states. If these values are exceeded, appropriate action MUST be taken. The responsible staff members SHOULD be alerted. Application-specific parameters, events, operating states, and their threshold values SHOULD be coordinated with the persons accountable for the specialised applications in use.

When database scripts are developed, binding quality criteria SHOULD be defined for them (see CON.8 Software Development). Database scripts SHOULD be subjected to extensive functional tests on separate test systems before they are used in production environments. The results SHOULD be documented.

All the components of a database system SHOULD be checked regularly in terms of whether all the specified security safeguards have been implemented and are configured correctly. This SHOULD include checks of whether the documented status corresponds to the actual status and whether the configuration of the database management system corresponds to the documented standard configuration. In addition, it SHOULD be determined whether all the database scripts at hand are actually needed. Whether they meet the quality standards of the respective organisation SHOULD also be checked. Furthermore, the log files of the database system and the operating system SHOULD be checked for irregularities (see DER.1 Detecting Security-Relevant Events). The audit results SHOULD be documented in a transparent manner. They SHOULD be compared against the target status. Deviations SHOULD be investigated.

Information security products SHOULD be used for databases. The products used SHOULD provide the following functions:

• Creation of an overview of all database systems
• Extended configuration options and rights management for databases
• Detection and prevention of possible attacks (e.g. brute force attacks on a user account or SQL injections)
• Audit functions (e.g. checking configuration requirements)

A business continuity plan that includes information on how emergency operations can be carried out SHOULD be prepared for the database management system in use. The resources required for the business continuity plan SHOULD be identified. Additionally, the business continuity plan SHOULD define how the respective organisation can return from emergency operations to regular operations. The business continuity plan SHOULD define the necessary reporting channels, response routes, resources, and response times for the Process Owners. Based on a coordination plan for the restoration of service, all IT systems that depend on the database in question SHOULD be identified in advance and taken into consideration.

If the data of a database system needs to be archived, a corresponding archiving concept SHOULD be drawn up. It SHOULD be ensured that the existing data will be available at a later point in time in a complete and consistent manner.

The archiving concept SHOULD define both archiving intervals and the storage period of the archived data. Additionally, the technology used to archive the database SHOULD be documented. The archived data SHOULD be used for regular recovery tests. The results SHOULD be documented.

The data stored in databases SHOULD be encrypted. In this process, the following factors (among others) SHOULD be considered beforehand:

• Effects on performance
• Key management processes and methods, including separate key storage and security
• Effects on backup recovery concepts
• Functional impact on the database (regarding sorting options, for example)

Security audits SHOULD be carried out on database systems at regular intervals. The systemic and manufacturer-specific aspects of the database infrastructure (e.g. directory services) used and the database management system deployed SHOULD be considered within the framework of security audits.