S 6.130 Detection and documentation of security incidents

Initiation responsibility: IT Security Officer

Implementation responsibility: Administrator, Emergency Officer, Specialists Responsible, IT Security Officer

Not every security incident can be recognised immediately as such. Many security incidents, especially when the incident involves targeted, deliberate attacks to IT systems, are only noticed after several days or weeks. False alarms are also common because hardware or software problems are misinterpreted as computer virus infections, for example.

In order to be able to examine and evaluate a security-related irregularity, though, certain analyses need to be performed in advance. These aspects include:

• a survey of the existing IT structures and IT networks,
• a list of contacts and of the users of the IT systems,
• a survey of the IT applications on the particular IT systems,
• the protection requirements determined for the information, IT systems, and IT applications.

These analyses are performed in the first step when applying the IT-Grundschutz methodology, so security management should already have the results of these analyses.

Security incidents can be detected in various ways:

• Discovery by the users: The users typically report incidents such as suspected or actual cases of virus infections, losses of data, or modifications to information.
• Detection by a system:
  • The system monitor (monitoring) generates an event when a critical limit is exceeded and either forwards the event as an incident to a support team or automatically sends it to an incident management system.
  • An intrusion detection system (IDS) reports an attempted attack or intrusion on a server.
• Detection by an employee from the IT department: As soon as an incident is detected, the employee usually registers the incident with the incident recording system.
• Detection by an external partner: Under some circumstances, an external partner may be the first party to report a security incident, for example because they have noticed that the response of the IT service is different than normal. In this case, it is particularly important to take all reports seriously and forward them to the right parties because outsiders will not always know the correct contact person or be familiar with the terminology used in the organisation.
• Information provided by criminal prosecution authorities or the press: Unfortunately, an organisation affected by a security incident may only become aware of this after being informed by the police or the press. It is also important in this case to forward the information to the correct contact person.

Based on this information, it is possible to decide quickly which IT systems and IT applications with which protection requirements are affected when a report of a security incident is received. This information also always indicates, as described in the following, which business-critical information and business processes are affected without having to state them explicitly every time. At the same time, it is also possible to identify who was appointed as the contact person and can help make such decisions quickly.

If it is determined that an IT system or IT application with a high protection requirement is affected, the incident is a security incident and the steps specified for handling security incidents must be initiated. However, if only IT applications and IT systems with normal protection requirements are affected, the organisation can attempt to eliminate the security problem locally if the problem is not expected to affect other systems with higher protection requirements. However, possible cumulative effects also need to be taken into account when it is clear that a large number of IT applications and IT systems with normal protection requirements could be affected.

If it is determined that the security incident is highly complex and could have serious consequences, it may make sense to call in the security incident team promptly (see S 6.59 Specification of responsibilities for dealing with security incidents).

If special platform-specific or site-specific knowledge is needed to analyse and manage the security incident, it may help to call in the team of experts for handling security incidents (see S 6.123 Assembling a team of experts for handling security incidents).

The next step in the investigation and assessment of the security incident is to determine the following influencing factors:

• Which additional IT systems and IT applications could be affected by the security incident?
• Could consequential damage also be incurred due to the fact that the IT systems are networked?
• For which IT systems and IT applications can direct damage and consequential damage be ruled out?
• How much direct damage and consequential damage could be caused by the security incident? It is especially necessary in this case to consider the dependencies between the various IT systems and IT applications.
• What triggered the security incident (i.e. was it due to carelessness, an attacker, or the failure of the infrastructure)?
• When and at which location did the security incident occur? The security incident could also have occurred long before it was actually noticed. Good log records can be a valuable aid when answering this question, but only if you can be sure they have not been manipulated in the meantime.
• Does the security incident only affect internal IT users or are external third parties also affected?
• How much information on the security incident has already gotten through to the general public?

If it turns out that the security incident could have serious consequences, at least the next escalation level should become involved.

After surveying the influencing factors, the courses of action resulting from the immediate safeguards and supplemental safeguards must be specified. The priorities specified must be taken into account when specifying the courses of action (see S 6.62 Specifying priorities for handling security incidents). This also includes estimating the time needed to implement these safeguards and estimating the cost and resources required to eliminate the problem and restore operations.

If the extent of the damage, time required, and resulting costs exceed a prescribed limit, the next highest escalation level and decision-making level must become involved before deciding which safeguards to select. The structured investigation and assessment of a security incident reveal the courses of action available.

Incidents reported by users are recorded in incident management by first level support. This means first level support and the service desk are involved in the incident processing cycle right from the start. Incidents detected in IT operations are usually recorded by the administrators of the systems themselves in a trouble ticket system or using similar tools. The incidents are therefore detected and recorded in a variety of different ways. This clearly shows that it is wise to have clear process controls to control the problem and process the security incident.

When an incident is recorded in incident management by first level support, there may be signs indicating that the incident is a security incident without the users even being aware of this. Incident management - in this case first level support -should note that it may be necessary to involve security management and should point this out to the person reporting the incident accordingly.

Review questions:

• Are all preliminary analyses available, such as the protection requirements determination and structure analysis?
• Do the alarm centres (especially in incident management) and the subsequent escalation levels have the information needed from the protection requirements determination available?
• Are technical resources available to support the assessment of security incidents, for example tools for evaluating log data?