S 5.7 Databases
Description
Database systems (DBSs) are a commonly used resource for the computer-based organisation, generation, alteration, and administration of large collections of data and represent the main source of information in many companies and organisations for performing their tasks. A DBS consists of the Database Management System (DBMS) and one or more databases.
A database is a collection of data, including their descriptions (metadata), that is stored persistently in the DBS.
The DBMS forms the interface between the databases and can be used by the users to change and administrate the data. The primary tasks of a DBMS are to provide various views of the data, to check the consistency of the data (i.e. to secure the integrity of the data), to check authorisations, to handle simultaneous accesses from different users (synchronisation), and to provide data backup capabilities to enable fast restoration of the data in case of a system failure.
For the most part, state-of-the-art database systems are one part of a 3-tier architecture. As an extension to the 2-tier architecture (client/server architecture), a 3-tier architecture includes an application server in a third level between client and server to provide access to the database applications. This architecture may lead to lower costs, since less complicated client configurations are needed and it simplifies database administration, especially when distributing software. With this architecture, new software versions can be provided to the users with less effort, because new software versions are downloaded automatically by the users from the database system via the application server.
Figure: Three-tier architecture of a DBMS
A database system must be able to process different user requests (transactions) in parallel. The following four properties, referred to as the ACID principles, are an essential requirement for the reliable processing of such transactions:
- Atomicity
A transaction is the smallest indecomposable set of processing steps and will only be performed completely or not at all. If an error occurs during the execution of a transaction and/or a transaction is cancelled while it is executed, all changes already made to the database in the transaction are undone. - Consistency
A transaction always transfers a database from one consistent state to another consistent state, i.e. all integrity requirements of the database are met. - Isolation
Every transaction executes in an isolated environment and is independent in all regards from the other transactions. This also means that a given transaction is only provided with data from the database that is in a consistent state. If transactions executing in parallel require resources concurrently, the transactions need to be serialised. - Durability
The results of a transaction completed successfully are stored persistently in the database.
Database systems are standard software applications and are offered on the market by a wide variety of manufacturers. If a database is to be used to process data, the first step is to select a suitable DBS. For this reason, the corresponding threats and safeguards in module S 1.10 Standard software must be taken into consideration.
Databases cannot be examined without taking into consideration the environment in which they are used. For example, the database may be installed on a stand-alone PC, in a mainframe computer environment, or in a networked Unix or Windows system. Accordingly, the modules in layers 3 through 5 must be taken into account accordingly depending on the operating environment.
Threat scenario
In addition to the basic threats that generally apply to all IT systems, there are also special threats to the availability of databases, as well as the confidentiality or integrity of the data stored in the database.
In general, the threat scenario depends on the operational scenario and the group of authorised users. For example, the threat posed by a scenario in which anonymous users are permitted access (e.g. access using the internet) to the database is higher than that posed by a scenario in which access is only allowed for certain identifiable user groups in a government agency or company.
Another aspect arises due to the increasing complexity of a DBMS, for example because a given DBMS maintains a separate database at a remote location, and therefore corresponding requirements for secure lines of communication and consistent data synchronisation must be fulfilled.
The following typical threats to the IT-Grundschutz of databases are assumed to exist:
Organisational Shortcomings
| T 2.22 | Lack of or insufficient evaluation of auditing data |
| T 2.26 | Lack of, or inadequate, test and release procedures |
| T 2.38 | Lack of, or inadequate, implementation of database security mechanisms |
| T 2.39 | Complexity of a DBMS |
| T 2.40 | Complexity of database access |
| T 2.41 | Poor organisation of the exchange of database users |
| T 2.57 | Inadequate storage of media in the event of an emergency |
| T 2.110 | Inadequate organisation of release changes and migration of databases |
Human Error
| T 3.6 | Hazards posed by cleaning staff or outside staff |
| T 3.16 | Incorrect administration of site and data access rights |
| T 3.23 | Improper administration of a DBMS |
| T 3.24 | Inadvertent manipulation of data |
| T 3.80 | Errors during synchronisation of databases |
Technical Failure
| T 4.26 | Failure of a database |
| T 4.27 | Circumvention of access control via ODBC |
| T 4.28 | Loss of data in a database |
| T 4.30 | Loss of database integrity/consistency |
Deliberate Acts
| T 5.9 | Unauthorised use of IT systems |
| T 5.10 | Abuse of remote maintenance ports |
| T 5.18 | Systematic trying-out of passwords |
| T 5.64 | Manipulation of data or software in database systems |
| T 5.65 | Denial of services in a database system |
| T 5.131 | SQL injection |
Method recommendation
To secure the information system examined, other modules will need to be implemented in addition to this module. These modules are selected based on the results of the IT-Grundschutz modelling process.
When a database is used as a central information store in a government agency or company, it is recommended to set up the database server in a separate server room or in a central computer centre. The safeguards to be implemented in this case are described in modules S 2.4 Server rooms and S 2.9 Computer centres.
If the database server is installed in a protective cabinet, module S 2.7 Protective cabinets must be taken into consideration when implementing the safeguards.
If mobile terminal devices such as correspondingly equipped mobile phones or PDAs will be used to access a database, modules S 3.4 Mobile telephones and/or S 3.5 PDAs must be taken into consideration.
The security safeguards are organised in this module according to the life cycle of a database system. The following steps should be followed, amongst other steps, for the secure use of database systems:
1. Planning
Database systems are complex products whose use and operation needs to be planned systematically. Amongst other things, this leads to a requirements catalogue for the software to be purchased (see S 2.80 Drawing up a requirements catalogue for standard software), as well as a database security concept (see S 2.126 Creation of a database security concept).
2. Training the administrators and purchasing the software
Before the database software can be used for productive operations, the administrators responsible must receive appropriate training regarding the secure operation of the database system (see S 3.11 Training of maintenance and administration staff). This training measure should be completed before the database system is purchased, if possible (see S 2.124 Selection of a suitable database software) so that the administrators responsible can be involved effectively in the early conception and configuration phases.
3. Creation of a database concept / database model
Before the database system is put into productive operation, a database concept must be drawn up that describes both the installation and configuration of the database components and the structure of the application-specific database. Furthermore, a practical user concept must be drawn up. Such a concept may become very extensive depending on the size and area of application of the database and on the standard database software selected (S 2.125 Installation and configuration of a database, S 2.126 Creation of a database security concept, S 2.128 Controlling access to a database system, and S 2.129 Controlling access to database information).
4. Operation of the database system
In addition to implementing the database concept, the database system requires continuous monitoring during initial operation and normal operation to ensure the availability, integrity, and confidentiality of the data. The most important safeguards in this context refer to the documentation (S 2.31 Documentation on authorised users and on rights profiles, S 2.34 Documentation on changes made to an existing IT system), administration (S 2.130 Ensuring the integrity of a database, S 2.133 Checking the log files of a database system), and the use (S 2.65 Checking the efficiency of user separation on an IT system, S 3.18 Log-out obligation for PC users) of the database.
5. Contingency Planning
In addition to implementing the safeguards for the introduction and trouble-free operation of a database system, it is also necessary to prevent various types of failures and to minimise their effects when they actually do occur. For this, the database-specific requirements must be taken into consideration so that the requirements for a fast recovery of the DBS after a system and/or database failure can be met and the risk of a loss of data is minimised (S 6.49 Data backup in a database, S 6.50 Archiving a database).
The bundle of security safeguards to be used for the "Databases" module is presented in the following:
Planning and design
| S 2.80 | (A) | Drawing up a requirements catalogue for standard software |
| S 2.126 | (A) | Creation of a database security concept |
| S 2.132 | (A) | Provisions for configuring database users / user groups |
| S 2.134 | (B) | Guidelines for database queries |
| S 2.363 | (B) | Protection against SQL injection |
| S 5.58 | (B) | Selection and installation of database interface drivers |
Purchasing
| S 2.124 | (B) | Selection of suitable database software |
Implementation
| S 2.125 | (A) | Installation and configuration of a database |
| S 2.135 | (C) | Safe transfer of data to a database |
| S 4.7 | (A) | Change of preset passwords |
| S 4.71 | (C) | Restrictive handling of database links |
| S 4.73 | (C) | Specification of upper limits for selectable records |
Operation
| S 2.31 | (A) | Documentation of authorised users and rights profiles |
| S 2.34 | (A) | Documentation on changes made to an existing IT system |
| S 2.65 | (C) | Checking the efficiency of user separation on an IT system |
| S 2.127 | (B) | Inference prevention |
| S 2.128 | (A) | Controlling access to a database system |
| S 2.129 | (A) | Controlling access to database information |
| S 2.130 | (A) | Ensuring the integrity of a database |
| S 2.131 | (C) | Separation of administrative tasks for database systems |
| S 2.133 | (A) | Checking the log files of a database system |
| S 3.18 | (A) | Log-out obligation for PC users |
| S 4.67 | (B) | Locking and deleting database accounts which are no longer required |
| S 4.68 | (A) | Ensuring consistent database management |
| S 4.69 | (B) | Regular checks of database security |
| S 4.70 | (C) | Monitoring a database |
| S 4.72 | (Z) | Database encryption |
| S 5.117 | (Z) | Integration of a database server into a security gateway |
Contingency Planning
| S 6.48 | (A) | Procedures in case of a loss of database integrity |
| S 6.49 | (A) | Data backup in a database |
| S 6.50 | (Z) | Archiving a database |
| S 6.51 | (B) | Restoring a database |