S 6.63 Investigation and assessment of a security incident

Initiation responsibility: IT Security Management

Implementation responsibility: IT Security Management, IT Administrator, IT Application Manager, Security Incident Team

Not every security incident is recognised as such immediately. Especially where targeted and wilful attacks are aimed at IT systems, many security incidents only come to light days or weeks after the event. False alarms are also a common occurrence, e.g. because hardware or software problems have been wrongly interpreted as cases of infection with computer viruses.

However, in order to be able to investigate and assess a security-relevant irregularity, it is necessary that certain preliminary assessments have already been carried out. These include:

• ascertaining the existing IT structure and IT network,

• ascertaining the point of contacts and users of the IT systems,

• ascertaining the IT applications on the IT systems concerned, and

• defining the protection requirements of the IT systems.

These investigations are carried out as the first stage of using the IT Baseline Protection Manual (see Section 2.2) and the results should therefore be available to IT Security Management.

Following receipt of an incoming report, the above information can be used to decide quickly which IT system is affected, and what IT applications and protection requirements are involved. At the same time, since the point of contact is known, this person can be called in quickly to assist with making the appropriate decisions.

Should it transpire that an IT system or an IT application with a high-level protection requirement is affected, then the matter should be regarded as a security incident and the predefined steps required to handle it must be implemented. On the other hand, if only IT applications and IT systems having a low protection requirement are affected, an attempt can be made to resolve the security problem locally.

If it appears that the security incident could have serious consequences and is sufficiently complex, it may be appropriate to call in the Security Incident Team without delay (see S 6.59 Specification of responsibilities for dealing with security incidents).

The following factors should be ascertained as a first step to investigating and assessing the security incident:

• What additional IT systems and IT applications could be affected by the security incident?

• Could any consequential damage also occur through networking of the IT systems?

• Which IT systems and IT applications will definitely not suffer any damage or consequential damage?

• How high could any direct damage or consequential damage caused by the security incident be? Particular attention should be paid here to the dependence of the various IT systems and IT applications.

• What was the trigger for the security incident (e.g. carelessness, an adversary or failure of the infrastructure)?

• When and in which location did the security incident occur? This could actually be some time prior to when the security incident was first detected. Well maintained log files can be extremely useful here, but only if one can be sure that they have not been tampered with.

• Are only internal IT users affected by the security incident, or are external third parties affected also?

• How much information regarding the security incident has already leaked out to the public?

If it transpires that the security incident could have serious consequences then it should be escalated to at least the next level.

Once these factors have been clarified, the options available must be specified. These will consist of both immediate measures and supplementary measures. The previously determined assignment of priorities should be considered here (see S 6.62 Specifying priorities for handling security incidents). The time that will be required to implement these measures and the cost and resources which will be necessary to resolve the problem and restore normal operating conditions must also be estimated.

If the level of the damage, the time required to repair the situation and the cost of this exceed predefined limits, then the next higher escalation and decision levels must be called in before any decisions are made as to which measures should be selected. The outcome of a structured investigation and assessment of a security incident on the lines outlined above will be the various options available.

Additional controls:

• Is the necessary information generated from the definition of protection requirements available to the persons receiving reports of security incidents and the next escalation levels?

• Are any technical means available to support the evaluation of security incidents, for example, tools for analysing logged data?