S 6.60 Procedural rules and reporting channels for security incidents

Initiation responsibility: Agency/company Management, IT Security Management

Implementation responsibility: IT Security Management

Many security incidents only turn into serious problems because inappropriate action was taken in response to them as a result of hasty decisions, for example, resulting in the spontaneous deletion of data which was needed to understand the event.

A distinction should be made here between generally applicable procedural rules which apply to all imaginable security incidents and IT-specific procedural rules. The following general procedural rules can be specified for all types of security-relevant irregularities:

• All those involved should remain calm and desist from taking hasty measures.

• Irregularities should be reported immediately in accordance with a reporting plan.

• Countermeasures must not be taken until or unless they have been requested by authorised persons.

• All the attendant circumstances must be explained frankly and transparently and without any glossing over, so that the damage can be minimised.

• Based on personal experience, an initial assessment of the potential extent of the damage, the consequential damage, the parties both within and without the organisation who are potentially affected and the possible consequences should be performed.

• Information regarding the security incident should not be passed to third parties without authorisation.

All staff in the agency/company who are potentially affected must be notified of these general procedural rules in a suitable fashion.

In addition, specific procedural rules can be provided to those affected, especially those in positions which are notified in cases of security incidents and are expected to take the first decisions and/or initiate the first measures. This includes IT Administrators, those responsible for IT applications and IT Security Management. These procedural rules should cover the measures described in

• S 6.23 Procedure in the event of computer virus infection

• S 6.31 Procedural patterns following a loss of system integrity

• S 6.48 Procedures in case of a loss of database integrity

• S 6.54 Procedures in case of a loss of network integrity

Once the procedural rules have been specified, the reporting channels must also be defined. We recommend proceeding on the following lines:

• In cases of force majeure such as fire, water, power failure, break-in and theft, the relevant local services should be informed (fire department, site technical service, entrance control staff, security guards etc.).

• In cases of hardware problems or irregularities in the operation of IT systems, the responsible IT Administrator should be informed.

• In cases of suspected wilful action and events which cannot be explained by any other means (e.g. manipulation of data, unauthorised exercise of permissions, suspected espionage or sabotage), the IT Security Officer and/or IT Security Management must be informed.

It is especially important here that all employees know whom to contact and the reporting channels which apply to all types of security incident. For example, a list of names, telephone numbers and e-mail addresses of the relevant points of contact could be included in the internal telephone directory or on the Intranet. However, it must not be difficult to report one's suspicions, nor must this entail any longwinded procedure. Fast and secure communication connections must be available for this purpose. The authenticity of the communication partner must be assured and the information reported concerning the suspicious occurrences must be treated as confidential.

All staff should also be informed that information regarding the security incident may only be divulged to third parties via IT Security Management (see S 6.65 Notification of the parties affected).

Exercises or practice runs should be held sporadically to check whether the procedural rules for security incidents are appropriate and can be implemented and whether all staff are aware of them (see also S 6.68 Testing the effectiveness of the management system for the handling of security incidents).

Experience of security incidents shows how important a good operating environment and a healthy communications culture are for the prompt and frank reporting of security incidents (see also S 3.8 Avoidance of factors impairing the organisation climate).

One possible way of informing all employees affected of the procedural rules and reporting plan is to issue an information sheet signed by the Management, on which the most important information is summarised. This can be held at the workplace and additionally on the Intranet. An example of such an information sheet can be found in the help available on the IT Baseline Protection Manual CD-ROM (directory ...\HILFSMI\15VERHAL.DOC). To ensure that the information is actually available when the real thing happens, we do not advise distributing this information sheet only in electronic form as the electronic version itself could then be affected by the security incident.

All information sheets on potential security incidents must be immediately updated whenever a relevant change takes place in the organisation, in order that the procedural rules described in them remain applicable and the reporting channels are correct.

Additional controls:

• Are there clearly defined procedural rules covering the different types of security incident?

• Are these known to all employees?

• When was this information last updated?