S 6.58 Establishment of a management system for handling security incidents

Initiation responsibility: Agency/Company management

Implementation responsibility: IT Security Management

As IT is increasingly integrated into every area of an agency's or company's operations, its correct functioning is becoming ever more critical. A major function of IT Security Management is therefore to take sufficient proactive measures to deal with security incidents of all kinds. Security incidents can be triggered by many different events and, for example, result in loss of availability, integrity and/or the confidentiality of data, individual IT systems or the entire network.

The security incidents which require special handling by IT Security Management are those which have the potential to cause significant damage. Security problems which cause or can cause only minor damage which is locally confined should be resolved locally so as to avoid overloading IT Security Management.

Handling of security incidents is ultimately the responsibility of IT Security Management and should be aimed at ensuring the following:

• the ability to respond so that security incidents and security problems are detected and reported to the appropriate responsible person(s) promptly;

• the ability to decide whether it is a local security problem or constitutes a security incident;

• the ability to take action so that in the event of a security incident the necessary measures can be taken and implemented at short notice;

• minimisation of damage - this is achieved through prompt notification of any other parts of the organisation which could be affected, and

• effectiveness - this is achieved by practising and monitoring the capability to handle security incidents.

To achieve these objectives, a management system must be established for dealing with security incidents. It is essential here that Management is involved and ultimately puts the management system into effect so as to ensure that the necessary awareness of IT security issues is generated, decision-making responsibilities are assigned and the security objectives are supported.

The steps described below provide a suggested approach as to how to establish a management system handling security incidents.

Step 1: Inclusion in the security guidelines

The handling of security incidents is one aspect of IT security management and, as such, should be spelt out in the security guidelines and/or IT security policy of the agency or company. These documents must specify that security incidents and security problems are to be reported by users and those affected to the responsible security officer. In addition, the decision-making process must be described and staff must be motivated as to the necessity of following the stipulated procedures. At the same time, inclusion in the security guidelines is a way of demonstrating Management's support for IT security.

Step 2: Specification of responsibilities

This step entails specifying who has what responsibility in the event of security incidents occurring. For example, the following groups might have these responsibilities:

• IT users: report security problems and security incidents.

• IT Administrators: receive reports, take initial steps enabling decision as to whether the occurrence is a security problem or a security incident, initiate escalation.

• Person responsible for IT application: participate in decision process and selection of measures in the light of own assessment of the degree of protection required by the IT application.

• IT Security Officer or IT Security Management: receive reports, decide whether it is a case of a security problem or a security incident, set escalation in motion, implement necessary measures.

• Security Incident Team: a team composed of IT administrators, IT users, IT Security Officers concerned, together with Public Relations staff and possibly Management, for handling a security incident.

• Public Relations staff or Press Office: prepare information policy regarding the security incident as required.

• IT Security Auditor: review management system and evaluate security incident.

• Management: make final decisions

The responsibilities must be defined and put into effect. For further information, see safeguard S 6.59 Specification of responsibilities for dealing with security incidents.

To deal with security incidents effectively, it is essential that those affected behave in a correct and level-headed manner and report the incident immediately. The necessary procedural rules (keep calm, reporting obligation, duty to provide information on attendant circumstances etc.) must be defined and IT users trained accordingly. In particular, the person to whom IT security problems or incidents should be reported must be determined.

Instructions on actions to be taken in the event of security incidents which may typically be expected (e.g. appearance of a computer virus, manipulation of data by insiders, hacking attempts by outsiders etc.) can be drawn up in advance. If an emergency occurs, people will then be able to respond more quickly so that the damage can be reduced. Since the effort required to prepare these action options is not inconsiderable, it should be restricted to the relevant areas in which it is possible to make plans.

This topic is covered in detailed in safeguard S 6.60 Procedural rules and reporting channels in the event of security incidents.

Step 4: Escalation strategy for security incidents

The more critical a security incident is, the greater the authority that is required as a rule to deal with the security incident. In the extreme this can mean that Management has to be informed and involved early in order that necessary measures such as a ban on divulging any information, calling in the police, taking costly alternative measures can be implemented. However, this requires that an escalation strategy specifying who should be consulted in what cases is drawn up in advance. Further information on this is provided in safeguard S 6.61 Escalation strategy for security incidents.

Step 5: Setting priorities

Because security incidents are generally the culmination of a chain of different causes and affect different IT application areas, the measures to be adopted should be implemented with the aid of a priority list. This setting of priorities depends on the protection requirement, the range of IT applications and the individual dependencies of the agency/company. Just as is necessary when determining the protection requirements, a list of priorities must be drawn up in advance for the purpose of specifying the order in which damage resulting from a security incident should be tackled (see S 6.62 Specifying priorities for handling security incidents).

Step 6: Methodology for investigating and assessing security incidents

Once a security-relevant irregularity has been reported, a decision must be made initially as to whether it can be regarded as a local security problem or constitutes a potentially more damaging security incident. A number of factors have to be ascertained and assessed before this decision can be made (the extent of the potential damage and consequential damage, the cause, which IT systems are affected, what immediate measures are required). If necessary, the next levels of management should be consulted, as specified in an escalation strategy. Further details will be found in safeguard S 6.63 Investigation and assessment of a security incident.

Step 7: Implementation of measures for taking remedial action in connection with security incidents

When implementing the measures necessary to remedy security incidents, it should be borne in mind that these measures will generally have to be implemented under time pressure. Therefore it is not inconceivable that the measures taken could themselves create new problems. Consequently it is important to document implementation of the measures adequately. Furthermore, assuming that the incident is the result of wilful action, the question of how the "perpetrator" should be dealt with should also be thought about. In some circumstances there may be personnel implications. For further information, see S 6.64 Remedial action in connection with security incidents.

Step 8: Notification of the parties affected

If it transpires that the impact of a security incident is not confined to the agency/company or individual organisational unit(s) concerned, to contain the damage all the other internal departments and external agencies affected must be notified. To accelerate notification, the communication channels should be ascertained and a dependency analysis should be carried out in advance (see S 6.65 Notification of the parties affected).

Step 9: Evaluation of a security incident

To ensure that the appropriate lessons are learnt from a security incident which has occurred, the procedure to be adopted for evaluating the handling of security incidents should be specified. Often this will result in improvements in dealing with security incidents or permit conclusions to be drawn as to the effectiveness of the IT security concept. The aspects to be considered here include the following:

• Time taken to react

• Extent of awareness of the reporting channel

• Effectiveness of the escalation strategy

• Effectiveness of the investigation

• Means for notifying affected parties

This subject is addressed in detailed in safeguard S 6.66 Evaluation of security incidents.

Step 10: Use of detection measures for security incidents

The sooner a security incident is detected and reported, the more effectively can countermeasures be taken. Any automated detection measures available should be used so as to reduce any delays induced by reliance on human actions. Examples of such measures are anti-virus programs, analysis of logged data and intrusion detection systems. Identification and activation of these measures and the related communication channels are described in safeguard S 6.67 Use of detection measures for security incidents.

Step 11: Effectiveness testing

In order to be able to measure the effectiveness of a management system for the handling of security incidents and promote the necessary practice at these management tasks, exercises and gaming should be performed. As these may require considerable personnel resources and can interfere with normal operations, they should be confined to important areas. Further suggestions will be found in safeguard S 6.68 Testing the effectiveness of the management system for the handling of security incidents.

The results of these steps should be documented appropriately in a "Concept for handling security incidents" paper. This concept should be updated at regular intervals and be notified to those affected in a suitable way.

Additional controls:

• Are there clearly defined procedures and rules covering the different types of security incident?

• Are the procedural rules and reporting channels to be used in the event of security incidents specified in writing?

• Are these known to all employees?