S 6.124 Specification of where security incident handling overlaps with incident management
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: IT Security Officer
The task of incident management is to receive all messages of malfunctions (also referred to as incidents) as well as requests and orders from the users in order to provide the users with the support needed to do their work and therefore to guarantee that IT can be used without any problems.
In this sense, security incidents can also be considered disruptive incidents since they impair the availability, integrity, or confidentiality of the information processed by the IT and therefore can cause corresponding damage to the business functions.
Service disruptions can also be caused by undetected security incidents. This is the case, for example, if the security incident arises in connection with an attack that specifically exploits certain vulnerabilities to destabilise IT services and the IT systems needed for these services. Occasionally, security incidents are only detected in the first place based on the disruptions they cause. The primary goal of incident management is to eliminate disruptions as quickly as possible and restore the service to be provided to ensure the impact on the business processes is as minimal as possible.
Similarly, IT malfunctions can also open up new security gaps, for example when security mechanisms are disabled due to unstable systems or workaround solutions.
This means service impairments and security incidents can be causes as well as effects. For this reason, they should be examined and handled with this in mind. It is therefore necessary to analyse any possible areas of overlap between incident management, business continuity management, and security management as well as to identify the resources shared by all three management systems. This means incident management must be made aware of the issues relating to security incident handling as well as to those of business continuity management. In addition, security management should have read access to the incident management tools used so they can detect irregularities or identify patterns of incidents.
The following list illustrates the most important steps in the incident management process. The safeguards of the IT-Grundschutz Catalogues referenced describe which integration aspects should be used to adapt the incident management process to the requirements of information security management:
- Detection and documentation (see S 6.130 Detection and documentation of security incidents)
- Classification and initial attempt at a solution (see S 6.131 Classifying and assessing security incidents)
- Analysis and providing a suggested solution (see S 6.131 Classifying and assessing security incidents and S 6.64 Remedial action in connection with security incidents)
- Resolution and restoring service (see S 6.64 Remedial action in connection with security incidents and S 6.133 Recovering the operating environment after security incidents)
- Monitoring and tracking the solution (see S 6.133 Recovering the operating environment after security incidents and S 6.134 Documentation of security incidents)
- Incident closure (see S 6.133 Recovering the operating environment after security incidents)
The chances of being able to handle normal incidents and security incidents in a single comprehensive and standardised incident management system increase when the suggested integration aspects are taken into account.
Review questions:
- Were the possible areas of overlap between incident management, business continuity management, and security management analysed? Were all resources shared by these management systems identified?
- Has incident management been sensitised to issues relating to security incident handling and business continuity management?
- Does security management have read access to the incident management tools used so they can detect irregularities and identify patterns of incidents?