S 1.8 Handling security incidents
Description
In order to maintain information security during operations, it is necessary to design and train the handling of security incidents (referred to as "security incident handling" or "security incident response") in advance. A security incident in this case is defined as an undesired event that affects information security and can cause major damage as a result. Typical consequences of security incidents can include the manipulation or destruction of data or reading data without authorisation. To avoid damage and minimise the damage actually caused, security incidents need to be processed quickly and efficiently. The response time for a security incident can be minimised if there is already a tested procedure available on which the response can be based.
This module focuses on handling security incidents from the standpoint of information technology. In spite of this clear distinction from other types of security incidents, the handling of security incidents overlaps to some extent with the handling of incidents in other areas.
A special area in the handling of security incidents is emergency management (see module S 1.3 Emergency management). In the framework of emergency management, failures of critical components are analysed in advance, risk minimisation safeguards are planned, and a procedure for maintaining or recovering availability is specified (among other things) for business-related processes, departments, and IT systems.
Typical security incidents include, for example:
- faulty configurations that lead to the disclosure of confidential data, losses of integrity of data requiring protection, or losses of the data itself,
- creation of security gaps in hardware or software components due to inherent errors,
- Malware events, or
- criminal acts (hacking into Internet servers, breaking into IT systems, stealing data, sabotage, or IT-related extortion, for example).
Such security incidents can be triggered by the following, for example:
- errors made by users, administrators, or external service providers that result in changes to system parameters that are critical to security and violate internal policies or instructions,
- violation of access rights,
- changes made to software, hardware, or the infrastructure, or
- inadequately securing rooms and buildings requiring protection.
All types of security incidents must be handled adequately. This applies to security incidents that the organisation can prepare for specifically (e.g. computer viruses) as well as to security incidents that occur unexpectedly in the organisation (such as a burst water pipe, for example).
This module illustrates a systematic method for creating a concept for handling security incidents and shows how its implementation and integration can be ensured in a company or government agency. The time and effort required for the creation and implementation of such a concept is considerable.
Threat scenario
Security incidents can be triggered by a large number of threats. The Threat Catalogues contain a large collection of threats that can result in minor or major security incidents. For this reason, this module examines the following threats as examples of the types of threats that can arise in connection with security incidents:
Organisational Shortcomings
| T 2.62 | Inappropriate handling of security incidents |
| T 2.141 | Undetected security incidents |
| T 2.142 | Destruction of evidence while handling security incidents |
Method recommendation
To secure the information system examined, other modules will need to be implemented in addition to this module. These modules are selected based on the results of the IT-Grundschutz modelling process.
A series of steps need to be taken and safeguards need to be implemented to establish an effective system for handling security incidents.
Planning and design
A procedure for handling security incidents must be established together with the corresponding organisational structures (see S 6.58 Establishment of a procedure for handling security incidents). It must be specified who has which responsibilities in the event of a security incident (see S 6.59 Specification of responsibilities for dealing with security incidents).
In addition to specifying the roles, responsibilities, and procedures, in order to effectively handle security incidents, it is essential for those affected to properly handle the effects of such incidents and report the incidents immediately (see S 6.60 Specification of reporting paths for security incidents).
An escalation strategy must be developed that states who is to be contacted in the event of which security incidents (see S 6.61 Escalation strategy for security incidents). In addition, the order in which the damage resulting from a security incident needs to be eliminated must be specified (see S 6.62 Specifying priorities for handling security incidents).
Implementation
It is also essential to detect security incidents in addition to preventing them (see S 6.67 Use of detection measures for security incidents and S 6.127 Establishment of measures for collecting and securing the evidence of security incidents).
For competent handling of security incidents a team of experienced and trustworthy experts should be assembled early on (see S 6.123 Assembling a team of experts for handling security incidents).
Operation
Security incidents first need to be recognised as such and documented (see S 6.130 Detection and documentation of security incidents). After that, they need to be analysed, and then an adequate solution must be suggested (see S 6.131 Classifying and assessing security incidents and S 6.64 Remedial action in connection with security incidents). The safeguards for recovering from security incidents must be suitably controlled and monitored (see S 6.133 Recovering the operating environment after security incidents and S 6.66 Evaluation of security incidents).
The bundle of safeguards for handling security incidents is presented in the following.
Planning and design
| S 6.58 | (A) | Establishment of a procedure for handling security incidents |
| S 6.59 | (A) | Specification of responsibilities for dealing with security incidents |
| S 6.60 | (A) | Specification of reporting paths for security incidents |
| S 6.61 | (C) | Escalation strategy for security incidents |
| S 6.62 | (Z) | Specifying priorities for handling security incidents |
| S 6.121 | (A) | Drawing up a policy for handling security incidents |
| S 6.122 | (C) | Definition of a security incident |
Implementation
| S 6.67 | (Z) | Use of detection measures for security incidents |
| S 6.123 | (Z) | Assembling a team of experts for handling security incidents |
| S 6.124 | (C) | Specification of where security incident handling overlaps with incident management |
| S 6.125 | (A) | Establishment of a central contact point for reporting security incidents |
| S 6.126 | (W) | Introduction to computer forensics |
| S 6.127 | (Z) | Establishment of measures for collecting and securing the evidence of security incidents |
| S 6.128 | (Z) | Training on the use of evidence collection tools |
| S 6.129 | (C) | Training service desk employees how to handle security incidents |
Operation
| S 6.64 | (A) | Remedial action in connection with security incidents |
| S 6.65 | (A) | Notification of parties affected by security incidents |
| S 6.66 | (B) | Evaluation of security incidents |
| S 6.68 | (C) | Testing the effectiveness of the management system for the handling of security incidents |
| S 6.130 | (A) | Detection and documentation of security incidents |
| S 6.131 | (A) | Classifying and assessing security incidents |
| S 6.132 | (A) | Limiting the effects of security incidents |
| S 6.133 | (A) | Recovering the operating environment after security incidents |
| S 6.134 | (B) | Documentation of security incidents |