S 6.61 Escalation strategy for security incidents
Initiation responsibility: IT Security Officer, Top Management
Implementation responsibility: Head of IT, IT Security Officer
After the responsibilities for security incidents have been specified (see S 6.59 Specification of responsibilities for dealing with security incidents) and all those concerned have been informed of the procedures and reporting paths (see S 6.60 Specification of reporting paths for security incidents), the next step is to determine how to proceed once the reports are received. An escalation strategy must be formulated for this purpose. The people responsible for incident management and information security management should work together during the development of the escalation strategy. This is necessary to efficiently and effectively utilise any methods and procedures already existing in the organisation (see S 6.124 Specification of where security incident handling overlaps with incident management).
The person who receives a report of a security incident must first examine and assess the report (see also S 6.63 Investigation and assessment of a security incident). If the incident is actually a security incident, then additional measures must be taken. The following questions arise in this case:
- Where escalation is required, i.e. the action chain is extended, who should be informed?
- What cases require immediate escalation?
- Under what other circumstances is escalation appropriate?
- When should escalation occur (immediately, the next day, the next working day)?
- What media should be used to pass on the report?
The answers to these questions are to be documented in an escalation strategy, and the employees must be informed of the escalation strategy.
In order for the persons responsible to be able to process the security incidents after their detection and registration without losing any time, the escalation strategies, escalation contacts, and escalation paths must be defined in advance. It is recommended to synchronise them with the escalation procedures of the persons responsible for incident management and with emergency management (see also S 6.124 Specification of where security incident handling overlaps with incident management).
There are two basic types of escalation, functional escalation and hierarchical escalation.
Functional escalation is initiated by incident management when no appropriate solution, for example in the form of a checklist (matching scenario), is available in first level support as an initial solution or when the matching scenario in the escalation path requires additional people with the corresponding authorisations to become involved. Security management should also be involved regularly according to the same conditions. The incident should be escalated immediately to security management in cases where it is suspected a security incident has occurred for which first level support does not have a matching scenario available. For this reason, first level support should have a copy of the current escalation strategy available.
Hierarchical escalation should be initiated when the following applies:
- If, in addition to the prerequisites mentioned above, it is only a matter of time until it becomes impossible to maintain the recovery time objectives
- When decisions need to be made in the course of processing the incident which the person processing the incident does not have the authority to make, e.g. because
- business processes that are critical to security are affected,
- it is suspected that the damage could threaten the existence of the organisation,
- criminal activity is suspected,
- widespread incidents or emergencies are foreseeable, etc.
It is also necessary to clearly define the escalation response and escalation activities expected in order to plan the escalation strategy instance and to ensure the escalation plan does not only have an informative character. All escalations performed must be clearly documented.
The escalation strategy can be created in three steps:
Step 1: Specification of the escalation paths
Who is responsible for handling security incidents was specified in safeguard S 6.59 Specification of responsibilities for dealing with security incidents. The specification of the escalation path must also define who will pass a given report on to whom. This can be illustrated quite simply using a digraph (directed graph). The graph should take the regular escalation paths as well as paths in case of a substitution into account.
Example:
Figure: Reporting paths for handling security incidents
Step 2: Decision-making aids for escalation
In this step, you must first determine which cases require immediate escalation without any further examination or assessment. An example of such a list is shown in the table below:
| Event | Persons to be informed immediately |
|---|---|
| Infection with a computer virus | IT Security Officer, Administrator |
| Fire | Gatekeepers, Fire Safety Engineer, fire department |
| Deliberate acts and suspected criminal activity | IT Security Officer |
| Suspicion of corporate espionage | IT Security Officer, board of directors |
| The need to call in the police and criminal prosecution authorities | Board of directors |
| Damage threatening the existence of the organisation | Board of directors, Emergency Officer, and head of the crisis team |
Table: Who needs to be informed and when they need to be informed
Afterwards, it must be specified when the other cases need to be escalated. Possible reasons for escalation include the following:
- The amount of damage expected exceeds the responsibility of the location that received the report.
- The cost and resources required to eliminate the damage are beyond the authority of the corresponding location.
- The complexity of the security incident is beyond their capabilities and exceeds their responsibilities.
Step 3: Type and method of escalation
In this step, it must be specified how the next higher link in the escalation chain needs to be informed. Possible methods for this purpose include the following:
- meeting in person
- submitting a written report
- by e-mail
- using a trouble ticket system
- by telephone or mobile phone
- via courier using sealed envelopes
If tools such as ticket systems are used for escalation, then these tools must be checked to ensure that they will also be available during a security incident or an emergency, so that it is also possible to process confidential information with them.
Likewise, it must be specified when the report needs to be submitted. Examples include:
- In case of events that require immediate measures to be taken, for example in case of a bomb threat by telephone: immediately.
- In case of events that need to be processed quickly, for example if there are signs of a computer virus infection in the LAN: immediately within one hour.
- In case of events that are under control but which require the next escalation level to be informed, for example in case of an attack by known malware that was successfully blocked on the security gateway: on the next working day.
When specifying the criteria determining when the reports need to be submitted, the functional and hierarchical escalation definitions (see above), among others, can be a useful aid.
This escalation strategy should be provided to all possible recipients of reports on security incidents in order to enable a fast response. Application of the escalation strategy and the use of the reporting paths must be practised in exercises. Such exercises also help the participants to obtain the necessary routine, which then helps to reduce the level of stress in crisis situations. Since the reporting paths and assessments of events are subject to constant change, the escalation strategy must be checked and updated regularly, but at least once per year.
In general, action must be taken quickly to contain a security incident. It may be necessary to call in employees from other projects or even call them in outside of normal working hours. For this reason, it is also necessary to specify how the additional work will be dealt with and how the on-call service will be organised (see also S 6.59 Specification of responsibilities for dealing with security incidents).
Review questions:
- Is a current escalation strategy available?
- Is the escalation strategy checked regularly and revised when necessary?
- Were the escalation paths tested in exercises?
- Does the escalation strategy contain clear instructions stating who needs to be contacted using which reporting paths within what time and for which type of detected or suspected security incident?
- Has it also been specified which measures and activities will be triggered by escalation?
- Are the checklists (matching scenarios) from incident management checked and updated regularly to reflect new security-related topics?
- Are the tools used for the escalation procedure also suitable for use with confidential information?
- Are the tools used for escalation also available during a security incident or an emergency?