S 2.133 Checking the log files of a database system
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Administrator
A reasonable scope for the logging and/or auditing functionality provided by a database system should be enabled. Logging too many events has negative effects on the performance of the database and causes the log files to grow quickly. For this reason, it is always necessary to weigh the requirement to collect as much information as possible to ensure the security of the database against the storage and evaluation capabilities for this information.
When logging, the following events in particular are of interest:
- times and duration of login of the users,
- number of connections to the database,
- failed and/or rejected attempts to establish a connection to the database,
- occurrences of deadlocks in the database system,
- I/O statistics for each user,
- accesses to the systems tables (see also S 4.69 Regular checks of database security),
- generation of new database objects, and
- modifications to the data (possibly including the time, date, and user).
However, the logging of security-related events is only effective as a security safeguard when the logged data is actually evaluated. For this reason, the log files must be evaluated at regular intervals by an auditor. If it is impossible for organisational or technical reasons to contract an independent auditor to evaluate the log files, it is very difficult to control the activities of the administrators.
Furthermore, the following must be taken into account when logging security-relevant events and when examining (monitoring) the log files:
The log files to be examined should always be copied to another environment before examination. Suitable tools should be used for this purpose. The responsibilities for logging and the responsibilities for the activities to be logged must be separated. When logging security-relevant events, it should only be possible to perform changes applying the two-man rule.
The logging function must be protected against:
- being disabled,
- changes to the types of events to be logged,
- changes to the logged data (content), and
- a loss of data on the logging media, for example due to overwriting the data, writing it incorrectly, or improper media storage.
The logged data must be deleted regularly from the production system to prevent the log files from becoming too large. However, the log files should only be deleted after they have been examined and evaluated. Under some circumstances, the logged data may need to be archived. The archiving or, if necessary, the deletion of the log files can be performed manually or automatically if the corresponding tools are available.
Suspicious activities must be reported to the Security Management.
Furthermore, access to the log files must be strictly limited. On the one hand, it is necessary to prevent attackers from hiding their activities by subsequently changing the log files and, on the other hand, it is possible to generate activity profiles of the users by examining the log files accordingly. For this reason, it should be impossible to change the log files and read access to them should only be granted to auditors.
The Data Protection Officer and the personnel representative must be involved early on when specifying the procedure to be used to record and evaluate the logged data.
In order to make the evaluation of the logged data easier, the database administrator may use additional tools enabling the log files to be monitored automatically. For example, such products may browse the log files of database systems for specified patterns and generate an alarm if necessary.
Additional safeguards to be taken into consideration in this regard can be found in S 2.64 Checking the log files.
Review questions:
- Have the logging and/or auditing capabilities in the database systems been enabled to a reasonable extent?