IT Baseline Protection Manual S 2.124 Selection of suitable database software
S 2.124 Selection of suitable database software
Initiation responsibility: Head of IT Section, IT Security Management
Implementation responsibility: IT Security Management, Administrators
During the procurement of a new database software, it should be selected so as to achieve the highest possible degree of security with a minimum of personnel and organisational resources during future operation.
To start with, the area of application and the purpose of the database system needs to be ascertained in order to formulate requirements concerning availability, integrity and confidentiality. Furthermore, the requirements regarding processed data volumes, processing rate and throughput need to be quantified. This will shape the features required of the database software, such as portability to particular hardware platforms and operating systems, or the scope of necessary security mechanisms. At this stage of planning, it is already possible to determine whether and to what extent hardware will need to be extended and upgraded for future operation of the database system. The required monitoring functions must also be defined on the basis of the availability requirements, i.e. it must be decided which various database states should be identified and in which form (e.g. by means of a log file) as well as the method of notifying responsible persons or groups of persons about critical states of the database (for example, through the output of messages to the console).
Particular note must be made of the following items when procuring database software:
The database software itself must possess suitable mechanisms for the identification and authentication of users (refer to S 2.128 Controlling Access to a Database System).
The database software must possess suitable mechanisms for limiting resources (refer to S 4.73 Specifying upper limits).
If the database is used to manage confidential data, it must be protected against access by unauthorised persons. In this case, the selected database software must possess appropriate mechanisms for access control (refer to S 2.129 Controlling Access to Database Information).
It should be possible to put several users with identical access rights into groups. In this case, it is necessary to distinguish between administrator groups and user groups. Distinction between various administrative roles should also be supported (refer to S 2.131 Separation of Administrative Tasks for Database Systems).
Different databases are equipped with mechanisms providing different scopes of access control; they might even be equipped with similar security mechanisms providing different degrees of resolution. Clarification is required in advance as to which type of access control is needed, and which database software fulfils the defined security requirements. Of key importance here are techniques of restricting access rights to database objects and data itself.
Examples:
Users can be denied the rights to create or modify database objects (e.g. tables).
Users can be granted read-only access to a table, but denied write-access to it.
Individual users can be denied access to particular tables or table fields.
Some users can be denied access to data records with certain attributes (e.g. an official in Bonn can be denied access to the data of an official in Cologne).
Some manufacturers offer the possibility of defining groups as well as roles. This allows differentiated access control to database objects. Related requirements must be clarified in advance and taken into consideration when selecting the database software.
The database software must also be examined with respect to the monitoring and control mechanisms it offers. Related requirements must be defined and compared with the features of the products (examples are provided in S 2.133 Checking the Log Files of a Database System and S 2.126 Creation of a Database Security Concept).
It must be checked as to whether the database software supports distinction between the roles of administrator and auditor. It should be possible to configure the role of an auditor who is solely authorised to analyse and delete log files. This prevents potential manipulations by the database administrator.
To protect the integrity of the database, the database software must be equipped with a complete transaction system in compliance with the ACID principle. Nowadays, this requirement is fulfilled by all major relational database management systems.
Mechanisms for backing up the database must be available (refer to S 6.49 Data Backup in a Database).
Clarification is required in advance as to which data backup features the database software needs to provide. For example, a partial database backup is not possible with all commercially available products. In individual cases, a check is therefore required as to whether the prepared database backup policy can be implemented with the available mechanisms.
These criteria must be used as a basis for testing and evaluating the available database systems. The software finally selected should fulfil the specified requirements to the greatest possible extent. Any remaining requirements should be covered using externally or internally developed add-ons. Before procurement, clarification is required as to which external add-ons are available for which database software, in order to avoid costly internal development.
Most commercial database management systems are available in different versions. Versions of the same database management system can differ in terms of their functionality, also as regards data security. Due to intense competition between manufacturers, some of the software programs supplied by them are not yet fully developed, and are thus potentially restricted in their functionality and reliability.
In view of this, a test phase should be implemented in order to check whether the selected database software actually performs the required functions in the stipulated operating environment. This applies particularly to performance specifications and contingency planning mechanisms.
Experience gathered from comparable installations should also be taken into consideration before procurement of the database software.
Additional controls:
Have the requirements for the database software been formulated and documented?
Have relevant database systems been evaluated on the basis of these requirements?