S 6.48 Procedures in case of a loss of database integrity

Initiation responsibility: Head of IT, Information Security Management

Implementation responsibility: User, Administrator

If the database system does not respond as expected (undefined system response, tables or records that cannot be found any more, altered table contents, inexplicably long response times, or similar indicators), it is possible that the database integrity has been lost. This may also have been caused by the system having been misused, for example due to changes to the system settings.

To resolve such problems, a concept (restoration concept) should be created that describes the checks, decisions, and actions necessary to quickly and securely restore the availability of the database (see S 6.51 Restoring a database).

It is also important to notify the database users of such problems. They should be informed immediately after any indication of a loss of database integrity and before beginning the restoration work. In this case and in situations where a user notices irregularities when using the database, the users should be provided with codes of conduct in the form of a leaflet containing at least the following information:

• Keep calm!
• Notify the database administrator.
• Do not access the database any more.
• Follow the instructions provided by the database administrator.

The database administrator should proceed exactly as stated in the restoration concept, which should contain the following steps, amongst other steps, that must be performed depending on the cause of the error:

Information

• immediate notification of all affected users with a request to withhold from further accesses to the database and to wait for new instructions.
• notification of the affected users at regular intervals on the current status of the repairs.

Securing the current database state

• shutdown of the database system.
• restart of the database system in the exclusive mode (if this mode is supported by the database system).
• backup of all files that could provide clues as to the type and cause of the problem occurred (for example whether the database system has actually been attacked and, if so, how the attacker was able to penetrate the system) i.e. backing up all relevant log files, in particular.

Analysis and Interpretation

• examination of log files for irregularities and interpretation of these irregularities (in cooperation with the auditor and/or the IT Security Officer).
• examination of the access rights granted for the systems tables.
• examination of the database software for visible changes, for example to the date of creation and in the size of the corresponding files. (Since these may also be reset to their original values by an attacker, a checksum method should be used.)

Reaction according to the situation

• deletion of the database software and re-installation of the original files from write-protected data media (see S 6.21 Backup copy of the software used). Programs from existing data backups should only be restored if it is sufficiently certain that the software restored from these backups does not already contain the error.
• reset of the user passwords.
• reset of the access rights for the systems tables.
• notification of the users with a request to check their areas for any irregularities.

After the passwords have been reset to default passwords, the users should be immediately requested to assign a new password the next time they log in and to make sure they abide by the password specifications in the password policy. If it is not possible to reset the passwords to default passwords or if this is not allowed by the password policy, random passwords should be created and sent to the users using reliable communication paths, for example using sealed envelopes. The passwords should be changed immediately during the next login. The administrator should check that the default passwords were changed immediately after logging in.

If data was deleted or undesired changes were made to it, this data can be restored from the data backups (see S 6.51 Restoring a database).

If there is any indication of a deliberate attack on a database, immediate action must be taken to minimise the resulting damages and to prevent any further damage from occurring. For this, it is necessary to draw up an alarm plan containing a list of the steps to be taken and specifying who needs to be informed of the incident (see also S 6.60 Specification of reporting paths for security incidents). If necessary, the alarm plan should also contain information on if and how the Data Protection Officer and the legal department should become involved.

Review questions:

• Is there a tested restoration concept that can be used in the event of a loss of database integrity and that describes checks, decisions, and actions necessary for the quick and secure restoration of the database?
• Are there codes of conduct for the users applicable to unusual system behaviour of the database?
• Is there a tested procedure for quickly and securely assigning passwords (upon restoration of the database)?
• Is there a tested alarm plan, according to which damage containment safeguards are initiated in the event of a suspected attack against the database?