DER.2.1 Security Incident Handling

Description

Introduction

To limit damage and prevent further harm, detected security incidents must be handled quickly and efficiently. To achieve this, it is necessary to establish a predefined and tested procedure for handling security incidents (Security Incident Handling or Security Incident Response).

A security incident can have a significant impact on an institution and cause major damage. Examples of such incidents include misconfigurations that lead to the disclosure of confidential information, or criminal acts such as attacks on servers, the theft of confidential information, and IT-related sabotage or extortion.

The causes of security incidents are varied; malware, outdated system infrastructures, and insider threats all play a role, among others. Attackers also frequently exploit zero-day exploits — security vulnerabilities in programs for which no patch yet exists. Another serious threat is that of so-called Advanced Persistent Threats (APTs).

Additionally, users, IT Operations, or external service providers may behave incorrectly, causing security-critical changes to system parameters or violations of internal policies. Further possible causes include violations of access rights, unauthorized changes to software and hardware, or inadequate security of premises and buildings that require protection.

Objective

The objective of this building block is to present a systematic approach for creating a concept for handling security incidents.

Scope and Modeling

The building block DER.2.1 Security Incident Handling is to be applied once to the information network.

This building block focuses on handling security incidents from an information technology perspective. Before security incidents can be handled, however, they must first be detected. Security requirements for this are contained in building block DER.1 Detection of Security-Relevant Events and are assumed as a prerequisite in the present building block. The precautionary measures necessary to enable IT forensic investigations are described in building block DER.2.2 Precautions for IT Forensics. The remediation following an APT incident is addressed in building block DER.2.3 Remediation of Extensive Security Incidents. A special area of security incident handling is emergency management, which is addressed in building block DER.4 Emergency Management and is not further examined here. It should be noted, however, that the decision as to whether an emergency exists or not is made within the scope of the present building block.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information networks, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular importance for building block DER.2.1 Security Incident Handling.

Inappropriate Handling of Security Incidents

In practice, it can never be ruled out that security incidents will occur. This applies even when many security measures have been implemented. However, if acute security incidents are not responded to, or not responded to appropriately, major damage with catastrophic consequences can result. Examples include:

• Unusual entries appear in the log files of a firewall. If it is not promptly investigated whether these are the first signs of an intrusion attempt, attackers may successfully bypass the firewall undetected and penetrate the institution’s internal network.
• Security vulnerabilities become known in the IT systems or applications being used. If the institution does not obtain this information in time and does not promptly initiate the necessary countermeasures, these vulnerabilities can be exploited in an attack.
• A burglary at a branch office is treated as a case of opportunistic theft because notebooks and flat-screen monitors were stolen. The fact that the notebooks contained confidential information and credentials for IT systems on the intranet is not given significant consideration. The Information Security Officer (ISO) is therefore not informed. As a result, the institution is unprepared for the subsequent attacks on the IT systems at other locations and the company headquarters. The data found on the stolen notebooks was used to carry out the attack.

When no appropriate procedure is prescribed for handling security incidents, wrong decisions can be made in haste and under stress. These can lead, for example, to the press being misinformed. Third parties could also be harmed by the institution’s own IT systems and demand compensation. It is also possible that no contingency or recovery measures have been put in place, significantly increasing the damage to the institution.

Destruction of Evidence During Security Incident Handling

If careless action is taken after a security incident, or if the prescribed procedures are not followed, important forensic evidence for clarifying the incident or for later legal proceedings can be inadvertently destroyed or rendered inadmissible in court.

Examples include:

• Malware was placed on a client during an attack, and its mode of operation and target can only be analyzed while it is running. To do this, information about active processes and the contents of main memory would have to be preserved and evaluated. If the client is prematurely shut down, this information can no longer be used for analyzing and clarifying the security incident.
• IT Operations discovers a running process on a server that is causing above-average CPU utilization. In addition, this process is generating temporary files and sending unknown information over the internet. If the process is prematurely terminated and the temporary files are simply deleted, it will be impossible to determine whether confidential information was exfiltrated.
• An important server is compromised because IT Operations was unable to apply the latest security updates as planned due to heavy workload and a missing maintenance window. To avoid potential disciplinary consequences, IT Operations applies the missing updates before a security team can analyze the cause of the intrusion and the damage incurred. A poor error culture has thus prevented an analysis of the problem.

Requirements

The following are the specific requirements of building block DER.2.1 Security Incident Handling. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled insofar as this is reasonable and appropriate.

Exactly one role should be primarily responsible. In addition, there may be additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural does not indicate how many people should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

DER.2.1.A1 Definition of a Security Incident (B)

An institution MUST have a clear definition of what constitutes a security incident. A security incident MUST be distinguished from disruptions in day-to-day operations as far as possible. All employees involved in handling security incidents MUST know the definition of a security incident. The definition and the threshold criteria for such an incident SHOULD be based on the protection needs of the affected business processes, IT systems, or applications.

DER.2.1.A2 Creation of a Policy for Handling Security Incidents (B)

A policy for handling security incidents MUST be created. It MUST define the purpose and objective of the policy and regulate all aspects of security incident handling. In particular, it MUST describe behavioral guidelines for the various types of security incidents. In addition, there MUST be target-group-oriented and practically applicable instructions for all employees. Furthermore, the interfaces to other management areas SHOULD be considered, for example, to emergency management.

The policy MUST be known to all employees. It MUST be coordinated with IT Operations and formally approved by Top Management. The policy MUST be regularly reviewed and updated.

DER.2.1.A3 Establishment of Responsibilities and Contact Persons for Security Incidents (B)

It MUST be regulated who is responsible for what in the event of security incidents. The responsibilities and competencies in security incidents MUST be established for all employees. In particular, employees who are to handle security incidents MUST be informed of their responsibilities and competencies. This MUST also include regulation of who makes the possible decision for a forensic investigation, based on which criteria it will be conducted, and when it should take place.

The contact persons for all types of security incidents MUST be known to employees. Contact information MUST always be current and easily accessible.

DER.2.1.A4 Notification of Affected Parties in Security Incidents (B) [Top Management, IT Operations, Data Protection Officer, Emergency Officer]

All affected internal and external parties MUST be informed promptly of a security incident. It MUST be checked whether the Data Protection Officer, the works council or staff council, and employees from the legal department must be involved. Reporting obligations for authorities and regulated industries MUST also be taken into account. Furthermore, it MUST be ensured that affected parties are informed of the required measures.

DER.2.1.A5 Remediation of Security Incidents (B) [IT Operations]

For a security incident to be successfully remediated, those responsible MUST first narrow down the problem and identify the cause. They MUST then select the required measures to resolve the problem. The head of IT Operations MUST grant approval before the measures are implemented. The cause MUST then be eliminated and a secure state restored.

A current list of internal and external security experts MUST be available who can be consulted in the event of security incidents for questions from the required subject areas. Secure communication procedures MUST be established with these internal and external parties.

DER.2.1.A6 Restoration of the Operating Environment After Security Incidents (B) [IT Operations]

After a security incident, the affected components MUST be disconnected from the network. In addition, all data MUST be backed up that could provide information about the nature and cause of the problem. The operating system and all applications on all affected components MUST be examined for changes.

The original data MUST be reinstalled from write-protected storage media. All security-relevant configurations and patches MUST be applied in the process. When data from backups is restored, it MUST be ensured that the backups were not affected by the security incident. After an attack, all credentials on the affected components MUST be changed before they are put back into operation. The affected components SHOULD be subjected to a penetration test before they are put back into use.

When restoring the secure operating environment, users MUST be involved in application function tests. After everything has been restored, the components, including the network transition points, MUST be specifically monitored.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be fulfilled.

DER.2.1.A7 Establishment of a Procedure for Handling Security Incidents (S) [Top Management]

A suitable procedure for handling security incidents SHOULD be defined. The processes, procedures, and specifications for the various security incidents SHOULD be clearly regulated and appropriately documented. Top Management SHOULD put the established procedure into effect and make it accessible to all parties involved. It SHOULD be regularly checked whether the procedure is still current and effective. The procedure SHOULD be adjusted as needed.

DER.2.1.A8 Development of Organizational Structures for Handling Security Incidents (S)

Suitable organizational structures SHOULD be established for handling security incidents. A security incident team SHOULD be established whose members can be convened depending on the type of incident. Even if the security incident team only convenes for a specific case, suitable members SHOULD already have been designated and briefed on their responsibilities in advance. It SHOULD be regularly checked whether the composition of the security incident team is still appropriate. If necessary, the security incident team SHOULD be restructured.

DER.2.1.A9 Establishment of Reporting Channels for Security Incidents (S)

The appropriate reporting channels SHOULD be established for the various types of security incidents. It SHOULD be ensured that employees can report security incidents quickly and easily through reliable and trustworthy channels.

If a central point of contact is established for reporting disruptions or security incidents, this SHOULD be communicated to all employees.

A communication and contact strategy SHOULD be in place. It SHOULD regulate who generally must be informed and who may be informed, by whom and in what order this occurs, and to what level of detail information is provided. It SHOULD be defined who passes on information about security incidents to third parties. It SHOULD also be ensured that no unauthorized persons pass on information about the security incident.

DER.2.1.A10 Containment of the Impact of Security Incidents (S) [Emergency Officer, IT Operations]

In parallel with the root cause analysis of a security incident, a decision SHOULD be made as to whether it is more important to contain the damage caused or to investigate the incident. To be able to assess the impact of a security incident, sufficient information SHOULD be available. For selected security incident scenarios, worst-case assessments SHOULD be conducted in advance.

DER.2.1.A11 Classification of Security Incidents (S) [IT Operations]

A uniform procedure SHOULD be established for classifying security incidents and disruptions. The classification procedure for security incidents SHOULD be coordinated between security management and incident management.

DER.2.1.A12 Definition of the Interfaces Between Security Incident Handling and Incident Management (S) [Emergency Officer]

The interfaces between incident management, emergency management, and security management SHOULD be analyzed. Any resources that may be shared should also be identified.

The employees involved in incident management SHOULD be made aware of security incident handling and emergency management. Security management SHOULD have read access to the incident management tools in use.

DER.2.1.A13 Integration into Security and Emergency Management (S) [Emergency Officer]

The handling of security incidents SHOULD be coordinated with emergency management. If the institution has a dedicated role for incident management, this SHOULD also be involved.

DER.2.1.A14 Escalation Strategy for Security Incidents (S) [IT Operations]

Beyond the communication and contact strategy, an escalation strategy SHOULD be formulated. This SHOULD be coordinated between those responsible for incident management and information security management.

The escalation strategy SHOULD contain clear instructions on who is to be involved, by what means, for which types of recognizable or suspected security disruptions, and when. It SHOULD be regulated what measures an escalation triggers and how to respond.

For the established escalation strategy, suitable tools such as ticketing systems SHOULD be selected. These SHOULD also be suitable for processing confidential information. It SHOULD be ensured that the tools are also available during a security incident or emergency.

The escalation strategy SHOULD be regularly reviewed and updated if necessary. The checklists (matching scenarios) for incident management SHOULD be regularly supplemented or updated with security-relevant topics. The established escalation channels SHOULD be practiced in exercises.

DER.2.1.A15 Training of Service Desk Staff (S) [IT Operations]

Service desk staff SHOULD have appropriate tools available to enable them to recognize security incidents. They SHOULD be sufficiently trained to be able to use the tools themselves. Service desk employees SHOULD be familiar with the protection needs of the affected IT systems.

DER.2.1.A16 Documentation of Security Incident Remediation (S)

The remediation of security incidents SHOULD be documented according to a standardized procedure. All actions performed, including timestamps, and the log data of the affected components SHOULD be documented. Confidentiality SHOULD be ensured in the documentation and archiving of reports.

The required information SHOULD be entered into the respective documentation systems before the disruption is marked as resolved and closed. In advance, the requirements for quality assurance necessary for this SHOULD be defined with the ISO.

DER.2.1.A17 Follow-up of Security Incidents (S)

Security incidents SHOULD be followed up in a standardized manner. It SHOULD be investigated how quickly the security incidents were detected and remediated. It SHOULD further be investigated whether the reporting channels functioned, whether sufficient information was available for the assessment, and whether the detection measures were effective. It SHOULD also be checked whether the measures and actions taken were effective and efficient.

Lessons learned from past security incidents SHOULD be used to create action instructions for comparable security incidents. These instructions SHOULD be communicated to the relevant groups of persons and regularly updated based on new findings.

Top Management SHOULD be informed annually about security incidents. If there is an immediate need for action, Top Management MUST be informed without delay.

DER.2.1.A18 Further Development of Processes Based on Findings from Security Incidents and Industry Developments (S) [Subject Matter Experts]

After a security incident has been analyzed, it SHOULD be investigated whether the processes and procedures for handling security incidents need to be changed or further developed. All persons involved in the incident SHOULD report on their respective experiences.

It SHOULD be checked whether there are new developments in the field of incident management and forensics and whether these can be incorporated into the respective documents and procedures.

If tools and checklists are used, for example for service desk employees, it SHOULD be checked whether these need to be supplemented with relevant questions and information.

Requirements for High Protection Needs

The following are exemplary proposals for requirements that go beyond the level of protection corresponding to the state of the art for this building block. The proposals SHOULD be considered when there are elevated protection needs. The specific determination is made within the framework of an individual risk analysis.

DER.2.1.A19 Establishment of Priorities for Handling Security Incidents (H) [Top Management]

Priorities for handling security incidents SHOULD be established in advance and regularly updated. The established classification of security incidents SHOULD also be taken into account.

The priorities SHOULD be approved and put into effect by Top Management. They SHOULD be known to all those responsible who are involved in handling security incidents. The established priority classes SHOULD also be recorded in the incident management system.

DER.2.1.A20 Establishment of a Dedicated Reporting Point for Security Incidents (H)

A dedicated point for reporting security incidents SHOULD be established. It SHOULD be ensured that the reporting point is reachable during normal business hours. In addition, it SHOULD be possible to report security incidents outside of normal business hours. The staff at the reporting point SHOULD be sufficiently trained and sensitized to information security matters. All information about security incidents SHOULD be treated confidentially at the reporting point.

DER.2.1.A21 Establishment of a Team of Experts for Handling Security Incidents (H)

A team of experienced and trustworthy experts SHOULD be assembled. In addition to technical expertise, team members SHOULD also have competencies in communication. The trustworthiness of team members SHOULD be verified. The composition of the team SHOULD be regularly reviewed and changed if necessary.

Team members SHOULD be integrated into the escalation and reporting channels. The expert team SHOULD be trained to analyze security incidents on the systems deployed in the institution. Members of the expert team SHOULD regularly continue their education, both on the deployed systems and on the detection and response to security incidents. The expert team SHOULD have access to all existing documentation as well as financial and technical resources to handle security incidents quickly and discreetly.

The expert team SHOULD be appropriately considered and integrated into the organizational structures. The team’s responsibilities SHOULD be coordinated in advance with those of the security incident team.

DER.2.1.A22 Review of the Effectiveness of the Security Incident Management System (H)

The security incident management system SHOULD be regularly reviewed to determine whether it is still current and effective. Both announced and unannounced exercises SHOULD be conducted for this purpose. The exercises SHOULD be coordinated with Top Management in advance. The metrics that arise when security incidents are recorded, reported, and escalated — such as the time periods from initial report to the binding confirmation of a security incident — SHOULD be evaluated.

In addition, tabletop exercises for handling security incidents SHOULD be conducted.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides requirements for the handling of security incidents in standard ISO/IEC 27001:2013 “Information technology - Security techniques - Information security management systems - Requirements” in Annex A16 “Information security incident management”.

The International Organization for Standardization (ISO) provides requirements for the handling of security incidents in standard ISO/IEC 27035:2016 “Information technology - Security techniques - Information security incident management”.

The National Institute of Standards and Technology (NIST) provides general guidance on handling security incidents in its Special Publication 800-61 Revision 2 “Computer Security Incident Handling Guide”.

The National Institute of Standards and Technology (NIST) provides specific guidance on handling malware infections on laptops and desktops in its Special Publication 800-83 Revision 1 “Guide to Malware Incident Prevention and Handling for Desktops and Laptops”.

The Information Security Forum (ISF) provides requirements for handling security incidents in Chapter TS1.4 “Technical Security Management; Identity and Access Management” of its standard “The Standard of Good Practice for Information Security”.