Database systems (DBS) are commonly accepted
computer-aided techniques of organising, generating,
manipulating and managing large amounts of data. A
database system consists of the database management
system (DBMS) and a certain number of databases. A
database is a collection of data representing facts on a
specific application in the real world. The DBMS acts as
an interface between users and the database, allowing
efficient and centrally monitored access to data, and
ensuring the pemanent availability of this data.
Database management systems now form an indispensable part of IT applications. Without a DBMS, it
would not be possible to manage the vast amounts of data which need to be collected, processed and
evaluated. The concept of a DBMS is based on a particular database model. The most important
database models are described in the following:
Hierarchical database model
This is the oldest existing variant, also regarded as the database model of the first generation. This
database model is structured like a tree. The nodes and leaves in this structure represent the files. A
node or leaf has exactly one predecessor, and data is always accessed sequentially. The access routes
are determined by the tree structure (and file structure respectively).
Relational database model
The relational database model involves strict separation between the data and the methods of accessing
it. The data is stored in the form of tables, where each row represents a data record (also termed tupel)
and each column represents an attribute of the data record. Tupels can be related to other tupels in
different tables, which is marked by a corresponding relationship. As opposed to the hierarchical model,
the relational database model does not impose any restrictions on access to data.
SQL (Standard Query Language), standardised by the ISO, is the database language provided with all
relational database systems.
Object-oriented database model
Object-oriented database models are an extension of classical database models and involve an object-oriented
(OO) technique. In this case, objects with similar attributes are grouped into classes which, in
turn, can be assigned class hierarchies. Only defined methods can be used to modify the objects, the
inheritance of methods and attributes playing a key role in object-oriented design. Standard data types
such as "Integer" and "Character" can be supplemented with type constructors allowing the definition of
This chapter only provides a treatment of databases based on the relational database model, as it is
currently the most prevalent.
A database system generally provides simultaneous access for different users. It therefore has to process
several user requests (transactions) in parallel and guarantee a distinct level of fault tolerance. Of
central importance are four requirements which are called the ACID-principle:
From the view of a user, a transaction will either be completed as a whole or not at all. If there is an
error or interruption, all changes made so far will be undone. This is ensured in the DBMS with
appropriate recovery measures.
All integrity conditions in the database are maintained. A transaction leads the database from a
consistent state into another consistent state. This can be ensured by appropriate synchronisation
mechanisms in the database.
Every transaction is isolated from all other transactions. This also implies that a transaction can
access only data that are part of a consistent state of the database.
If a transaction has been reported to the user as successfully completed, all changes made in the
database will survive subsequent hardware or software failures (unless the database is destroyed as a
These requirements are fulfilled by almost all commercially available DBMS systems.
Database systems are based on standard commercial software offered by a variety of manufacturers.
The first step in acquiring a database for processing data is to select a suitable standard software
package. The related threats and safeguards stated in Chapter 9.1 Standard Software must also be
Databases cannot be treated separately from the environment in which they are used. A stand-alone PC
is just as feasible as a mainframe or a network of Unix systems. For this reason, the threats and
safeguards described in Chapter 5 Non-networked systems, Chapter 6 Local Area Networks and
Chapter 7 Data Transfer Systems should be taken into consideration in accordance with the type of
environment involved. To prevent redundancies, this chapter does not repeat descriptions of threats and
safeguards unless they are of particular importance.
The following threats are assumed to be applicable to the IT baseline protection of databases:
- T 2.3 A lack of compatible, or unsuitable, resources
- T 2.22 Lack of 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 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 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.29 Loss of data in a database caused by a lack of storage space
- T 4.30 Loss of database integrity/consistency
- 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
Recommended Countermeasures (S)
For the purpose of IT baseline protection, we recommend the complete implementation of the safeguard
packages (modules) summarised in Chapters 2.1 and 2.4.
It is advisable to install the database server in a separate server room. The appropriate measures are
described in Chapter 4.3.2. If an office is used simultaneously as a server room, the safeguards
described in Chapter 4.3.1 must also be implemented.
If the database server is installed in a protective cabinet, also refer to
Chapter 4.4 Protective Cabinets.
The following essential steps must also be taken for databases:
- Determining the requirements to be fulfilled by the database software.
First prepare a requirements catalogue to allow the selection of a suitable standard database software
(S 2.80 and S 2.124).
- Training administrators
Before the database software is used in a productive environment, the responsible administrators
must be trained (S 3.11). If possible, this should be done before procuring the software package.
- Design a database concept
Before using the database software, design a database concept which describes the installation and
configuration of the database software, the suitable concept for database users and their access
rights, as well as the application-specific database. Depending on the capacity and environment of
the database as well as the selected standard database software, such a concept can be very extensive
(S 2.125, S 2.128, S 2.129
and S 2.126).
- Operating the database
Commissioning and operation of the database include the implementation of the database concept, as
well as continuous monitoring of the DBMS in order to ensure the availability, data integrity and
protection of confidential data. The most important safeguards here concern documentation
(S 2.25, S 2.31, S 2.34),
administration (S 2.130, S 2.133) and
utilisation of the database.
- Contingency planning
In addition to the general safeguards relating to this topic, it is important to consider database-specific
circumstances in order to keep data losses and recovery times within reasonable limits in the
event of a system crash or database crash. (S 6.32, S 6.49,
The safeguard package for databases is listed in the following:
- S 2.22 (2) Escrow of passwords
- S 2.25 (1) Documentation on the system configuration
- S 2.31 (1) Documentation on authorised users and on rights profiles
- S 2.34 (1) Documentation on changes made to an existing IT system
- S 2.80 (1) Drawing up a requirements catalogue for standard software
- S 2.111 (2) Keeping manuals at hand
- S 2.124 (1) Selection of suitable database software
- S 2.125 (1) Installation and configuration of a database
- S 2.126 (1) Creation of a database security concept
- S 2.127 (2) Inference prevention
- S 2.128 (1) Controlling access to a database system
- S 2.129 (1) Controlling access to database information
- S 2.130 (1) Ensuring the integrity of a database
- S 2.131 (1) Separation of administrative tasks for database systems
- S 2.132 (1) Rules for configuring database users / user groups
- S 2.133 (2) Checking the log files of a database system
- S 2.134 (2) Guidelines for database queries
- S 2.135 (3) Save transfer of data to a database
- S 3.4 (1) Training before actual use of a program
- S 3.5 (1) Education on IT security measures
- S 3.10 (1) Selection of a trustworthy administrator and his substitute
- S 3.11 (1) Training of maintenance and administration staff
- S 4.1 (1) Password protection for IT systems
- S 4.7 (1) Change of preset passwords
- S 4.67 (3) Locking and deleting database accounts which are no longer required
- S 4.68 (1) Ensuring consistent database management
- S 4.69 (2) Regular checks of database security
- S 4.70 (3) Monitoring a database
- S 4.71 (2) Restrictive utilisation of database links
- S 4.72 (2) Database encryption (optional)
- S 4.73 (2) Specifying upper limits for selectable data records
- S 5.58 (1) Installation of ODBC drivers
- S 6.32 (1) Regular data backup
- S 6.48 (2) Procedures in case of a loss of database integrity
- S 6.49 (1) Data backup in a database
- S 6.50 (1) Archiving database
- S 6.51 (3) Restoring a database
© Copyright by Bundesamt für Sicherheit in der Informationstechnik 2000
Last Update on 6 April 2000