S 6.64 Remedial action in connection with security incidents

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: IT Security Management, Head of IT Section, Administrator

As soon as the cause of a security incident has been identified, the measures needed to deal with it should be selected and implemented. This requires first of all containing and removing the problem, and then restoring the "normal" state of affairs.

Supplying the necessary expert knowledge

To investigate and deal with a security weakness, it is essential to have the relevant technical knowledge. Therefore either staff must have the appropriate training or else experts will have to be called in. For this purpose, a list containing the contact addresses of appropriate internal and external experts from the various subject areas must be prepared so that they can be called upon for advice without delay. External experts include

• Computer Emergency Response Teams (CERTs) (see also S 2.35 Obtaining information on security weaknesses of the system),

• vendors and distributors of the IT systems concerned (see also S 4.107 Use of vendor resources),

• vendors and distributors of security systems used such as anti-virus programs, firewalls, access control etc.,

• external consultants with specialist security expertise.

Restoring secure operations

To eliminate any security weaknesses, the IT systems concerned must be taken off the network and all the files which could provide any information about the nature and cause of the problem which has occurred must be backed up. This includes especially all relevant log files. As the entire IT system should be viewed as insecure or as having been tampered with, the operating system and all the applications must be examined for changes. In addition to programs, configuration files and user files must also be examined for possible manipulation. It is appropriate here to use checksum procedures. However, this presupposes that the checksums associated with the "secure" condition have been ascertained in advance and transferred to write-protected data media (see also S 4.93 Regular integrity checking).

To be certain that any Trojan horses left behind by an adversary have really been removed, the original files should be reimported from write-protected data media. Care should be taken here that all security-relevant configurations and patches are also imported as well. Where files are reimported from data backups, steps must be taken to ensure that these have not been affected by the security incident, i.e. they have not already been infected with the computer virus. On the other hand, examination of the data backups may be helpful in order to establish when the attack began or when infection with a computer virus occurred.

Before restoring operations after an attack, all passwords on the IT systems concerned should be changed. This also includes IT systems which were not directly affected by manipulation, but from which the attacker may already have obtained information about users and/or passwords.

It should be assumed that once the "secure" condition has been restored, the adversary will attempt a further attack. For this reason the IT systems, especially the network connections, should be monitored using the appropriate monitoring tools (see also S 5.71 Intrusion detection and intrusion response systems).

Documentation

All actions performed while dealing with a security problem should be documented in as much detail as possible so as to

• retain the details of what happened,

• make it possible to retrace the problems which occurred,

• be able to rectify any problems/faults which could result from hasty implementation of countermeasures,

• be able to resolve problems already known more quickly should they occur again,

• be able to eliminate the security weaknesses and draw up preventive measures and

• collect evidence if a prosecution is to be brought.

Such documentation includes not only a description of the actions carried out including the times at which they were taken, but also the log files of the affected IT systems.

Reaction to deliberate action

Where a security incident was triggered by an adversary, a decision must be made as to whether to stand back and watch the attack or whether countermeasures should be implemented as soon as possible. Naturally an attempt can be made to catch the adversary "red-handed" but this runs the risk that in the meantime he will destroy, tamper with or read data.

Regrettably, investigation of security problems indicates that these are often caused by staff from within the organisation. This can be the result of an oversight, inappropriate working procedures or technical problems, but it could also be a case of failure to observe security measures or even deliberate action.

Wherever security problems are caused internally, the trigger must be investigated. Often the problems turn out to stem from inappropriate or incomprehensible procedures. It is then necessary to amend the procedures accordingly or else to supplement them with additional measures, e.g. of a technical nature.

If the security problems are the result of deliberate action or negligence, appropriate disciplinary measures should be taken.

Additional controls:

• When was the list of security experts last updated?

• Have any deliberate attacks perpetrated by insiders been observed before?