APP.4.3 Relational Databases
Database systems (DBS) are a frequently used tool to organize, create, modify, and manage large collections of data with IT support. A DBS consists of...
Description
Introduction
Database systems (DBS) are a frequently used tool to organize, create, modify, and manage large collections of data with IT support. A DBS consists of the so-called database management system (DBMS) and one or more databases. A database is a collection of data together with its description (metadata) that is permanently stored in the database system. Since database systems often occupy a central role in IT infrastructure, significant security requirements apply to them. The core processes of an institution are usually dependent on information from databases, which leads to corresponding availability requirements. There are also often high requirements for the confidentiality and integrity of the information stored in databases.
Objective
The objective of this building block is to enable the secure operation of relational database systems and to adequately protect the information processed and stored in databases. For this purpose, requirements are described that allow database systems to be securely planned, implemented, and operated, and through which threats can be reduced.
Scope and Modeling
The building block APP.4.3 Relational Databases must be applied once to every relational database system.
This building block describes requirements for relational database systems. Security requirements for non-relational database systems are not the subject of this building block.
To comprehensively protect the information in databases, security requirements relating to the structure of database tables and access to the database should already be observed during application development. However, requirements on these topics are not listed in this building block.
Likewise, the building block does not address threats and requirements relating to the operating system and hardware on which the database system is installed. Aspects relating to these can be found in the corresponding operating-system-specific building blocks of the SYS IT Systems layer, e.g. SYS.1.3 Server under Linux and Unix or SYS.1.2.3 Windows Server.
Relational database systems should generally be considered in the context of the building blocks OPR.4 Identity and Access Management, OPS.1.1.3 Patch and Change Management, CON.3 Data Backup Concept, OPS.1.2.2 Archiving, OPS.1.1.5 Logging, and OPS.1.1.2 Proper IT Administration.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.4.3 Relational Databases.
Insufficient Dimensioning of System Resources
If the hardware of a database system does not have sufficient system resources, the database may fail entirely or operate incorrectly. For example, data may not be able to be saved. Resources can also be heavily utilized during peak times, which can degrade performance and in turn cause applications to not execute correctly or at all.
Activated Default Accounts
During the initial installation or in the delivery state of a database management system, default accounts (user and administrator accounts) are often not secured or are only secured with publicly known passwords. This can result in these accounts being misused. For example, attackers can log in to the database management system using publicly known credentials as users or even as administrators. They can then read, manipulate, or delete the configuration or stored data.
Unencrypted Database Connection
In the default configuration, many database management systems connect to applications without encryption. If communication between applications and the database management system is unencrypted, transmitted data and access credentials can be intercepted or manipulated in transit.
Data Loss in the Database
Hardware or software errors, as well as human error, can cause data in the database to be lost. Since databases typically store important information for applications, services can fail or entire production processes can grind to a halt.
Loss of Integrity of Stored Data
Through incorrectly configured databases, software errors, or manipulated data, the integrity of information in the database can be compromised. If this is not noticed or is only noticed late, the core processes of the institution can be severely impaired. For example, if referential integrity relationships between tables are not correctly defined, this can result in erroneous data in the database. If this error is only noticed during production or not at all, not only must the inconsistent data be laboriously cleaned up and reconstructed. Over time, significant damage may also have occurred, for example when critical data is involved, such as tax-relevant data, invoice data, or even control data for entire production systems.
SQL Injections
A common attack method against database systems is SQL injection. When an application accesses data in an SQL database, commands in the form of SQL statements are transmitted to the DBMS. If input data within the application is insufficiently validated, attackers can inject their own SQL commands into the application, which are then processed with the permissions of the application’s service account. Attackers can thus read, manipulate, and delete data, add new data, or call system commands. Although SQL injections primarily affect front-end applications, they also significantly impact the database system itself and the associated infrastructure.
Insecure Configuration of the Database Management System
The default configuration of the database management system often has unnecessary functions enabled that make it easier to read or manipulate information from the database in a potential attack. For example, due to an unchanged default installation, attackers may be able to connect to a programming interface not used by the institution to administer the DBMS without having to authenticate themselves. This allows them to gain unauthorized access to the institution’s databases.
Malware and Insecure Database Scripts
In many database management systems, it is possible to automate certain actions via scripts executed in the context of the database, e.g. using Procedural Language/Structured Query Language (PL/SQL). These include so-called database triggers. However, if these are used unchecked by those responsible, the database scripts may not meet the institution’s software development requirements.
Core functions of a database, such as Data Dictionary Tables, can also be manipulated during attacks, for example by malware or database scripts. This type of attack is difficult to detect. Quality deficiencies in these scripts and malware can jeopardize the confidentiality, integrity, and availability of data stored in databases.
Requirements
The following are the specific requirements of the building block APP.4.3 Relational Databases. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.
Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | IT Operations |
| Additional responsibilities | Subject Matter Experts, Developers |
Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.
Basic Requirements
The following requirements MUST be fulfilled with priority for this building block.
APP.4.3.A1 Creation of a Security Policy for Database Systems (B)
Based on the institution’s general security policy, a specific security policy for database systems MUST be created. It MUST contain comprehensible requirements and specifications for how database systems are to be securely operated. The policy MUST be known to all employees responsible in the area of database systems. It MUST form the fundamental basis for their work. If the policy is modified or if requirements are deviated from, this MUST be coordinated with the ISO and documented. It MUST be regularly checked whether the policy is still correctly implemented. The results MUST be meaningfully documented.
APP.4.3.A2 DISCONTINUED (B)
This requirement has been discontinued.
APP.4.3.A3 Baseline Hardening of the Database Management System (B)
The database management system MUST be hardened. For this purpose, a checklist of steps to be performed MUST be compiled and worked through. Passwords MUST NOT be stored in plaintext. Baseline hardening MUST be regularly reviewed and, if necessary, adjusted.
APP.4.3.A4 Regulated Creation of New Databases (B)
New databases MUST be created following a defined process. When a new database is created, basic information about the database MUST be documented in a traceable manner.
APP.4.3.A5 DISCONTINUED (B)
This requirement has been discontinued.
APP.4.3.A6 DISCONTINUED (B)
This requirement has been discontinued.
APP.4.3.A7 DISCONTINUED (B)
This requirement has been discontinued.
APP.4.3.A8 DISCONTINUED (B)
This requirement has been discontinued.
APP.4.3.A9 Data Backup of a Database System (B)
Regular system backups of the DBMS and data MUST be performed. The database system MUST also be backed up before a database is newly created. For this, the permissible utility programs SHOULD be used.
All transactions SHOULD be backed up in such a way that they can be restored at any time. If the data backup exceeds available capacity, an extended concept SHOULD be created to back up the database, e.g. incremental backups. Depending on the protection needs of the data, the recovery parameters SHOULD be specified (see CON.3 Data Backup Concept).
Standard Requirements
Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.
APP.4.3.A10 DISCONTINUED (S)
This requirement has been discontinued.
APP.4.3.A11 Adequate Dimensioning of Hardware (S) [Subject Matter Experts]
Database management systems SHOULD be installed on adequately dimensioned hardware. The hardware SHOULD have sufficient reserves to meet potentially increasing requirements. If resource bottlenecks emerge during operation, these SHOULD be remedied at an early stage. When dimensioning hardware, the expected growth over the planned deployment period SHOULD be taken into account.
APP.4.3.A12 Uniform Configuration Standard for Database Management Systems (S)
A uniform configuration standard SHOULD be defined for all database management systems in use. All database management systems SHOULD be configured according to this standard and operated uniformly. If it is necessary for an installation to deviate from the configuration standard, all steps SHOULD be approved by the ISO and documented in a traceable manner. The configuration standard SHOULD be regularly reviewed and, if necessary, adjusted.
APP.4.3.A13 Restrictive Handling of Database Links (S)
It SHOULD be ensured that only those responsible are authorized to create database links (DB links). Where such links are created, so-called private DB links MUST be preferred over public DB links. All DB links created by those responsible SHOULD be documented and regularly reviewed. DB links SHOULD also be taken into account when backing up the database system (see APP.4.3.A9 Data Backup of a Database System).
APP.4.3.A14 DISCONTINUED (S)
This requirement has been discontinued.
APP.4.3.A15 DISCONTINUED (S)
This requirement has been discontinued.
APP.4.3.A16 Encryption of the Database Connection (S)
The database management system SHOULD be configured so that database connections are always encrypted. The cryptographic methods and protocols used for this SHOULD comply with the institution’s internal guidelines (see CON.1 Cryptographic Concept).
APP.4.3.A17 Data Migration (S) [Subject Matter Experts]
It SHOULD be defined in advance how data is to be initially or regularly imported into a database. After data has been imported, it SHOULD be checked whether it is complete and unchanged.
APP.4.3.A18 Monitoring the Database Management System (S)
The parameters, events, and operating states of the database management system that are critical for secure operation SHOULD be defined. These SHOULD be monitored using a monitoring system. Threshold values SHOULD be defined for all critical parameters, events, and operating states. If these values are exceeded, an appropriate response MUST be made. Responsible employees SHOULD be alerted. Application-specific parameters, events, operating states, and their threshold values SHOULD be coordinated with those responsible for the specialist applications.
APP.4.3.A19 Protection against Malicious Database Scripts (S) [Developers]
If database scripts are developed, mandatory 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 being deployed in production. The results SHOULD be documented.
APP.4.3.A20 Regular Audits (S)
All components of the database system SHOULD be regularly checked to verify that all defined security measures have been implemented and are correctly configured. It SHOULD be checked whether the documented state corresponds to the actual state and whether the configuration of the database management system corresponds to the documented standard configuration. It SHOULD also be checked whether all database scripts are needed and whether they meet the institution’s quality standards. In addition, the log files of the database system and the operating system SHOULD be examined for anomalies (see DER.1 Detection of Security-Relevant Events). Audit results SHOULD be documented in a traceable manner. They SHOULD be compared against the target state. Deviations SHOULD be investigated.
Requirements for High Protection Needs
The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.
APP.4.3.A21 Use of Database Security Tools (H)
Information security products for databases SHOULD be deployed. 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 accounts, SQL injection), and
- audit functions (e.g. review of configuration requirements).
APP.4.3.A22 Emergency Preparedness (H)
An emergency plan SHOULD be created for the database management system, defining how emergency operations can be realized. The resources needed for the emergency plan SHOULD be identified. In addition, the emergency plan SHOULD define how regular operations can be restored from emergency mode. The emergency plan SHOULD specify the necessary notification paths, response paths, resources, and response times for those responsible. Based on a coordination plan for recovery, all IT systems dependent on the database SHOULD be identified and considered in advance.
APP.4.3.A23 Archiving (H)
If data from a database system must be archived, an appropriate archiving concept SHOULD be created. It SHOULD be ensured that the data sets can be fully and consistently recovered at a later point in time.
The archiving concept SHOULD define both the intervals for archiving and the retention periods for archived data. In addition, it SHOULD be documented with which technology the databases were archived. Recovery tests SHOULD be regularly performed with the archived data. The results SHOULD be documented.
APP.4.3.A24 Data Encryption in the Database (H)
Data in the databases SHOULD be encrypted. The following factors, among others, SHOULD be considered beforehand:
- Impact on performance,
- key management processes and procedures, including separate key storage and backup,
- impact on backup and recovery concepts,
- functional effects on the database, such as sorting capabilities.
APP.4.3.A25 Security Reviews of Database Systems (H)
Database systems SHOULD be regularly reviewed using security checks. Security reviews SHOULD address both the systemic and manufacturer-specific aspects of the deployed database infrastructure (e.g. directory services) as well as the deployed database management system.
Additional Information
Good to Know
The BSI has published the following partner contributions on the topic of database security within the framework of the Alliance for Cybersecurity:
- Oracle: Database Security – Basic Considerations
- McAfee: Database Security in Virtualization and Cloud Computing Environments
The Deutsche Telekom Group has published the document “Security Requirements for Database Systems” on the topic of databases as part of its Privacy and Security Assessment (PSA) process.
The Information Security Forum (ISF) provides requirements for securing relational database systems in its standard “The Standard of Good Practice for Information Security” in chapter BA2.3 Protection of Databases.