Detection and Response

Introduction

In order to protect IT systems, security-relevant events must be detected and handled in good time. To this end, organisations must plan, implement, and regularly drill appropriate organisational, personnel, and technical safeguards in advance. When an organisation has a defined and tested method to build on, it can shorten its reaction times and optimise its existing processes.

The term "security-relevant event" refers to an event that affects information security or may impair confidentiality, integrity, and availability. Typical consequences of such events involve information being intercepted, manipulated, or destroyed. The reasons for this are manifold. Malware, legacy system infrastructures, or internal attackers can play a role. However, attackers often also capitalise on zero-day exploits—that is, on vulnerabilities in programs that have not yet been patched. Another threat to be taken seriously has to do with Advanced Persistent Threats (APTs). These are targeted cyber attacks on organisations in which an attacker gains permanent access to a network and subsequently extends this access to other IT systems. Such incursions are often difficult to detect and characterised by the very large amount of resources used, as well as significant technical skills on the part of the attackers.

Objective

This module illustrates a systematic way in which information may be collected, correlated, and evaluated in order to detect security-relevant events as completely and promptly as possible. The findings gained within the framework of detection should then improve an organisation's ability to detect and react appropriately to security-relevant events.

Scoping and Modelling

Module DER.1 Detecting Security-Relevant Events must be applied once to the entire information domain under consideration.

It includes basic specifications that must be considered and met when security-relevant events are detected. These requirements, however, depend on comprehensive logging. The requirements necessary in this regard are not described in this module, but are included in OPS.1.1.5 Logging.

When laying the groundwork for the detection of security-relevant events, it is important that responsibilities and competences be clearly defined and assigned. Particular attention should be paid to the principle of separation of duties. This topic is not part of this module; it is covered in module ORP. 1 Organisation.

Furthermore, this module does not describe how to handle security-relevant events after they have been detected. Recommendations on this subject are provided in the modules DER.2.1 Security Incident Handling and DER.2.2 Provisions for IT Forensics. This module also does not address the topic of data protection, which is covered in module CON.2 Data Protection.

In order to detect security-relevant events, additional programs are often required, such as anti-virus programs, firewalls, or intrusion detection/prevention systems (IDS/IPS). The security aspects of these systems are not considered in this module. They are addressed, for example, in the modules NET.3.4 IDS/IPS, OPS.1.1.4 Protection Against Malware, and NET.3.2 Firewall.

Useful Resources

The Federal Office for Information Security (BSI) regulates the logging and detection of security-relevant events in its “Mindeststandard des BSI zur Protokollierung und Detektion von Cyber-Angriffen” [BSI Minimum Standard for Logging and Detection of Cyber Attacks].

On the topic of intrusion detection, the BSI has published the additional document “BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen, Version 1.0” [BSI Guidelines for the Introduction of Intrusion Detection Systems, Version 1.0].

In "The Standard of Good Practice for Information Security", the Information Security Forum (ISF) provides guidelines for the use of intrusion detection systems in section TS1.5, "Intrusion Detection Systems".

Introduction

In order to limit damage and avoid additional ramifications, detected security incidents need to be addressed quickly and efficiently. To this end, it is necessary to establish a specified and tested method for handling security incidents (also referred to as security incident handling or security incident response).

A security incident may have significant effects on an organisation and entail major damage. Examples of such incidents include incorrect configurations that cause confidential information to be disclosed, or criminal acts such as attacks on servers, the theft of confidential information, sabotage, or blackmail associated with IT.

The causes of security incidents are manifold and can include malware, outdated system infrastructures, or internal attackers. Attackers also often take advantage of zero-day exploits— that is, vulnerabilities in programs that have not yet been patched. Another threat to be taken seriously has to do with Advanced Persistent Threats (APTs).

Furthermore, users, administrators, or external service providers may behave incorrectly, such as by changing system parameters in a security-critical manner or violating internal policies. Other plausible causes include violations of access rights, changes in software or hardware, or insufficient protection of sensitive rooms and buildings.

Objective

The objective of this module is to demonstrate a systematic way of creating a concept for security incident handling.

Scoping and Modelling

Module DER.2.1 Security Incident Handling must be applied once to the entire information domain under consideration.

This module focuses on handling security incidents from the standpoint of information technology. Before security incidents can be handled, however, they must first be recognised. The security requirements related to this are included in module DER.1 Detecting Security-Relevant Events, which is a prerequisite of this module. Safeguard required for conducting forensic IT examinations are described in module DER.2.2 Provisions for IT Forensics. The process of cleaning up after an ATP incident is covered in module DER.2.3 Clean-Up of Extensive Security Incidents. A special area of handling security incidents is business continuity management, which is addressed in module DER.4 Business Continuity Management and not considered further here. The present module does, however, cover how to determine whether or not a given situation is an emergency.

Useful Resources

The International Organization for Standardization (ISO) provides guidelines for handling security incidents in ISO/IEC 27001:2013 “Information technology – Security techniques – Information security management systems – Requirements” (annex A16, “Information security incident management”).

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

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

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

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

Introduction

IT forensics involves the strictly methodical data analysis of storage media and data networks that is needed to get to the bottom of security incidents in IT systems.

Forensic investigation of IT security incidents is always necessary to assess damage, avert attacks and prevent them in the future, and identify attackers. Whether or not an IT security incident requires forensic examination is determined whilst handling the incident. In the context of this module, IT forensic examination consists of the following phases:

• Strategic preparation: During this phase, processes are planned and established to ensure that an organisation is able to forensically analyse IT security incidents. It is also required if the organisation does not have its own forensics experts.
• Initialisation: Once the responsible employees have decided to forensically examine an IT security incident, the processes planned in advance are triggered. The examination framework is also specified and the initial measures are implemented.
• Securing evidence: Here, the evidence to be secured is selected, and the data is secured forensically. In this regard, a differentiation is made between live forensics and post-mortem forensics. Live forensics ensures that the affected IT system's volatile data (in terms of network connections or RAM, for example) is secured. During post-mortem forensics, forensic copies of storage media are created.
• Analysis: The collected data is analysed forensically. In this regard, data is considered both individually and in the overall context at hand.
• Presentation of results: The relevant examination results are processed and communicated to meet the needs of specific target groups.

Objective

This module covers the safeguards required to conduct forensic IT examinations. The main focus is on how to prepare and carry out evidence recovery.

If providers of forensics services secure evidence either partially or entirely on their own, the requirements of this module also apply to them. Contractual arrangements and tests can be used to ensure that a service provider will comply with such requirements.

Scoping and Modelling

Module DER.2.2 Provisions for IT Forensics must be applied once to the entire information domain under consideration.

This module addresses safeguards that are essential for later forensic IT examinations.

The actual performance of forensic analysis is thus not part of this module. It does not describe requirements that are designed to ensure that attacks will be detected. These are included in module DER.1 Detecting Security-Relevant Events and are a prerequisite of this module. In addition, this module does not address criteria and processes used by the persons in charge to decide whether an IT security incident must be forensically examined. This decision will be made during the handling of each security incident (see DER.2.1 Security Incident Handling).

The module also not cover forensic IT investigations of criminal offences.

Finally, this module does not address how IT infrastructures can be cleaned after being attacked (see DER.2.3 Clean-Up of Extensive Security Incidents). The activities described in DER.2.3 can, however, be supported significantly by the results of forensic IT examinations.

Useful Resources

The BSI provides further information on this subject in “Leitfaden IT-Forensik” [BSI Guide for IT Forensics], which also serves as a reference work for individual problems that can arise in practice.

The International Organization for Standardization (ISO) provides guidelines for conducting forensic analyses in the standards ISO/IEC 27042:2015 and 27043:2015 01:2013.

“The Standard of Good Practice for Information Security” published by the Information Security Forum (ISF) provides guidelines for conducting forensic analyses (section TM 2.4, "Forensic Investigations").

Request for Comments (RFC) 3227, “Guidelines for Evidence Collection and Archiving”, provides information on basic procedure in securing forensic evidence.

Introduction

Advanced Persistent Threats (APT) are cyber attacks that target specific organisations and facilities. In such cases, an attacker gains permanent access to a network and expands this access to further IT systems. The attacks are characterised by a very high use of resources and extensive technical skills on the part of the attackers. Attacks of this type are usually difficult to detect.

After an APT attack has been detected, the persons in charge at the affected organisation face great challenges in carrying out a clean-up effort that goes beyond the usual procedure for dealing with IT security incidents. It can be assumed that the discovered attackers have been able to access the affected IT infrastructure for quite some time. They have probably also been using complex attack tools to bypass standard security mechanisms and establish various backdoors. Furthermore, there is the risk that the attackers are observing the infected environment in detail and will react to cleaning attempts by erasing their traces and sabotaging the investigation.

This module assumes that the organisation in question faces a serious threat because it has fallen victim to a targeted attack by highly motivated perpetrators with above-average resources. In real-world situations, a (certified) forensics expert is usually consulted in the event of an incident like this if the organisation does not have its own forensic experts. While forensic service providers are already called in during the forensic analysis phase, they are also involved (at least in an advisory capacity) during clean-up.

Objective

This module describes what an organisation should do in order to clean its IT systems and restore the normal and secure operating condition of its information domain after an APT attack.

Scoping and Modelling

Module DER.2.3 Clean-Up of Extensive Security Incidents must always be applied when the regular and secure operating condition of an information domain is to be restored following an APT incident. The module must be applied to the information domain under consideration.

An information domain can only be cleaned after an APT incident has been detected successfully and analysed forensically. Detection and forensics are therefore not dealt with in this module. These topics are covered in the modules DER.1 Detecting Security-Relevant Events and DER.2.2 Provisions for IT Forensics.

This module deals exclusively with the process of cleaning up after APT incidents. Other incidents are covered in module DER.2.1 Security Incident Handling. This module does not describe how indicators of compromise (IoCs, which are evidence of penetration) are to be derived and how they may be used to identify recurring attackers. It also does not address how to find backdoors that may have been overlooked during analysis and cleaning.

This module only considers cyber attacks; attacks in which attackers gain physical access to an information domain are not considered. For example, forms of attack in which data centres are broken into, administrators are bribed, newly acquired hardware is intercepted and manipulated, or electromagnetic radiation is intercepted are not considered in this module.

The requirements of this module also apply to forensic service providers that clean up affected IT systems either entirely or in part. Contractual agreements and checks can be used to ensure that the service providers adhere to these requirements (see OPS.2.1 Outsourcing for Customers).

Useful Resources

The BSI has published the following documents associated with APTs:

• BSI publication on cyber security (BSI-CS 072): “Erste Hilfe bei einem APT Angriff” [First Aid in the Event of an APT Attack]
• Common Criteria Protection Profile for Remote-Controlled Browsers System (ReCoBS): BSI-PP-0040

CERT-EU has published the security whitepaper 2014-007, "Kerberos Golden Ticket Protection: Mitigating Pass-the-Ticket on Active Directory" on the topic of APTs.

Introduction

Audits and revisions are fundamental to every successful information security management system (ISMS). An organisation's overall level of information security can only be assessed when established security safeguards and processes are regularly audited to determine whether they are still effective, complete, appropriate, and up to date. Hence, audits and revisions are a suitable tool for determining, achieving, and maintaining an appropriate level of security. Audits and revisions make it possible to identify security deficiencies and undesirable developments and create appropriate safeguards in response.

An audit (lat. audire = to hear, to listen) is a systematic, independent examination of activities and their results. This involves checking compliance with defined requirements such as norms, standards, or guidelines. A revision (revise = control, check) investigates whether documents, conditions, objects, or methodologies are correct, effective, and appropriate. Unlike an audit, a revision does not necessarily have to be performed independently. A revision may also include maintenance that incorporates subsequent improvements.

Objective

Module DER.3.1 Audits and Revisions defines requirements for audits and revisions in order to improve information security in an organisation, avoid improper developments in this area, and optimise security safeguards and processes.

Scoping and Modelling

The module must be applied once to the entire information domain under consideration. It covers internal audits (first-party audits) and revisions, as well as audits of service providers and partners (second-party audits). Certification audits (third-party audits) are not considered in this module.

The IS audits that are obligatory for federal government agencies in Germany are also not addressed. These are covered in module DER 3.2 Audits Based on the BSI "Guideline for IS Audits”.

Useful Resources

The International Organization for Standardization (ISO) describes guidelines for auditing management systems in the standard ISO 19011:2011.

The International Organization for Standardization (ISO) describes guidelines for auditing an ISMS in the standard ISO/IEC 27007:2011.

The Information Security Forum describes guidelines for auditing an ISMS in “The Standard of Good Practice for Information Security”.

Introduction

Information security (IS) audits based on IT-Grundschutz represent a special form of auditing that follows the document Information Security Audit (IS Audit) – A Guideline for IS Audits Based on IT-Grundschutz (in short, the “Guideline for IS Audits”).

The “Guideline for IS Audits” is a document published by the BSI that describes the procedure for IS auditing. Federal authorities are obliged to review their information security management systems (ISMS) using IS audits. If they want to check the implementation of their ISMS, other organisations can carry out an IS audit based on the guideline instead of a regular IT audit.

IS audits based on the BSI guideline feature a holistic approach. This means that all levels of an ISMS are checked, from the establishment of an information security organisation and personnel aspects to the configuration of IT systems and applications. Economic efficiency and compliance, which are the focus of traditional IT audits, are only of secondary importance. Information security (including the adequacy of the security safeguards at hand) is thus the essential test criterion of an IS audit based on IT-Grundschutz.

An IS audit based on IT-Grundschutz is a fundamental part of successful information security management. After all, regular checks are the only way to evaluate whether the established measures and information security processes are effectively implemented, complete, up to date, and appropriate. An IS audit based on IT-Grundschutz is therefore a suitable tool for determining, achieving, and maintaining an appropriate and continuously improving level of security in an organisation.

The main task of an IS audit based on IT-Grundschutz is to support and accompany the top management, the IS management team and, in particular, the Chief Information Security Officer (CISO) in achieving the highest possible level of information security in their organisation.

Objective

This module defines requirements for an IS audit based on IT-Grundschutz in order to improve the information security in an organisation, avoid improper developments in this area, and optimise security safeguards and processes.

Scoping and Modelling

This module must be applied whenever an organisation is obliged to carry out audits based on the "Guideline for IS Audits" or wishes to do so voluntarily. The module must be applied once to the entire information domain under consideration.

The ways in which an IS audit based on IT-Grundschutz can be integrated into an existing overarching audit unit (e.g. an internal auditing department) within an organisation are not covered. Module DER.3.2 Audits Based on the BSI “Guideline for IS Audits” is a specific example of the requirements described in general in module DER.3.1 Audits and Revisions. Organisations that implement the present module no longer need to implement DER.3.1 Audits and Revisions, as its requirements are fully contained in this module.

IS audits and the certification of an ISMS in line with ISO 27001 on the basis of IT-Grundschutz complement each other. IS audits can accompany the path to certification and, in contrast, can be carried out during the initiation of the security process in a given organisation. They show the organisation where there is an urgent need for action and which security deficiencies should be addressed as a matter of priority. If individual information domains in the organisation are certified according to ISO 27001 on the basis of IT-Grundschutz, recertification and IS audits for these information domains should be carried out together if possible. The findings of surveillance audits or certification procedures can be used for IS audits.

If an ISO 27001 certificate based on IT-Grundschutz is available for the entire organisation, the surveillance audits required in the certification procedure replace the IS audits.

The regulations regarding the protection of classified information and the General Administrative Instructions for the physical and organisational protection of classified material (Classified Material Instructions) issued by the Federal Ministry of the Interior remain unaffected and apply regardless of the requirements of this module.

Useful Resources

The Federal Office for Information Security (BSI) describes how an IS audit should be carried out in “Information Security Audit (IS Audit) – A Guideline for IS Audits Based on IT-Grundschutz”.

The Federal Office for Information Security (BSI) describes topics that should be audited during an IS partial audit in the document “Verbindliche Prüfthemen für die IS-Kurzrevision” [Binding Audit Subject List for IS Partial Audits].

The Federal Office for Information Security (BSI) provides an example manual for IS auditing in “Revisionshandbuch zur Informationssicherheit nach UP Bund” [Audit Manual for Information Security in Line with UP Bund].

The Federal Ministry of the Interior (BMI) describes the specifications to be observed when handling classified material in the "Verschlusssachenanweisung" [Classified Material Instructions].

Introduction

In emergencies, organisations must having continued access to information in order to be able to restore a business process, an IT system, or a specialised task. To be able to maintain information security even in an emergency, appropriate processes should therefore be planned, established, and reviewed.

Optimal contingency planning and emergency response can only be achieved by adopting a planned and organised approach. A professional process for business continuity management reduces the impact of an emergency and thereby secures operations and the continued existence of the organisation affected. Suitable measures must be identified and implemented to make time-critical business processes and specialised tasks more robust and fail-safe. On the other hand, these measures should make it possible to deal with an emergency in a quick and targeted manner.

The preservation of information security in an emergency must be integrated into overarching business continuity management, ideally as part of an emergency management system. However, business continuity management has its own Process Owner: the BCM Officer, who coordinates with the Chief Information Security Officer.

Objective

The aim of this module is to describe requirements to ensure information security in organisations even in critical situations. For this purpose, the corresponding measures should be embedded in a holistic approach to business continuity management. In addition, all aspects should be considered that are necessary for maintaining information security even in the event of damage or emergencies. This includes anything from planning to the checking of all processes.

Scoping and Modelling

Module DER.4 Business Continuity Management must be applied once to the entire information domain under consideration.

In the event of damage, the correct information must be fully available. The present module does not address criteria or processes used by persons in charge to decide whether an emergency has occurred. This decision will be made during the handling of each security incident (see DER.2.1 Security Incident Handling).

Crises are considered within the scope of an own crisis management and only are addressed as interface in this module, e.g. within the scope of further escalation of emergencies. Further information on the individual phases of business continuity management and the differentiation between business continuity management and crisis management is included in BSI Standard 100-4, “Business Continuity Management”.

Useful resources

The International Organization for Standardization (ISO) provides guidelines for ensuring information security in the event of an emergency in ISO/IEC 27001:2013, “Information Technology - Security Techniques – Information Security Management Systems – Requirements” (annex A17, “Information Security Aspects of Business Continuity Management”).

The International Organization for Standardization (ISO) provides a framework for business continuity management in the standard ISO/IEC 22301:2012, “Societal Security – Business Continuity Management Systems – Requirements”. The requirements from the aforementioned standard ISO/IEC 27001:2013 (for example) can be integrated into this standard.

BSI Standard 100-4, “Business Continuity Management”, describes how a BCM can be established, maintained, and continuously improved.

The implementation framework (UMRA) published by the BSI on business continuity management in line with BSI Standard 100-4 contains further auxiliar resources to facilitate the establishment of a BCMS.

In addition, the web course “Business Continuity Management” provides an introduction to the topic in line with BSI Standard 100-4.

In “The Standard of Good Practice for Information Security”, the Information Security Forum (ISF) provides specifications on business continuity in the category BC (Business Continuity). Among other things, it requires that a continuity strategy be coordinated with a corresponding information security strategy.

In its Special Publication 800-34, Rev. 1, “Contingency Planning Guide for Federal Information Systems”, the National Institute of Standards and Technology (NIST) provides a guide for establishing continuity planning for (federal) information systems, which also incorporates information security. This document also provides information on interrelationships between continuity planning for information systems and other types of plans related to security and emergency management (e.g. a business continuity plan).