chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
DER.2.1.A14 Escalation Strategy for Security Incidents [IT Operation Department] (S)
An escalation strategy SHOULD be formulated that goes beyond the communication and contact strategy at hand. This escalation strategy SHOULD be coordinated among the persons responsible for fault management and information security management. It SHOULD contain clear instructions on who is to be involved in what way and when for each type of identifiable or suspected security incident. It SHOULD also specify the safeguards that are to follow an escalation and how those involved are to respond. Suitable tools (e.g. ticket systems) SHOULD be selected for the defined escalation strategy. These SHOULD also be suitable for processing confidential information. It SHOULD be ensured that the tools will also be available during security incidents and emergencies. The escalation strategy SHOULD be reviewed regularly and updated as required. The checklists (matching scenarios) for fault management SHOULD be complemented by security-relevant topics and updated regularly. The defined escalation paths SHOULD be tested by means of drills.
DER.2.1.A15 Training Service Desk Employees [IT Operation Department] (S)
Service desk employees SHOULD have appropriate tools at their disposal to enable them to identify security incidents. They SHOULD be sufficiently trained to use the tools themselves. Service desk employees SHOULD be familiar with the protection needs of the IT systems in question.
DER.2.1.A16 Documentation for Remedying Security Incidents (S)
The process of remedying security incidents SHOULD be documented in accordance with a standardised procedure. All actions performed and the respective times SHOULD be documented along with the log data of the components affected. In so doing, confidentiality SHOULD be guaranteed while documenting the information and archiving the reports. The necessary information SHOULD be entered into the respective documentation systems before the disruption in question is considered over. The necessary quality assurance requirements SHOULD be defined in advance with the CISO.
DER.2.1.A17 Evaluation of Security Incidents (S)
Security incidents SHOULD be evaluated in a standardised manner. This SHOULD examine how quickly security incidents are detected and remedied. It should also investigate whether the reporting channels worked, whether sufficient information was available for evaluation, and whether the detection safeguards were effective. It SHOULD also check whether the implemented safeguards and activities were effective and efficient. The experience gained from previous security incidents SHOULD be used to develop instructions for comparable security incidents. These instructions SHOULD be announced to the relevant groups of persons and updated at regular intervals on the basis of new findings. An organisation's Top Management SHOULD be informed of the security incidents at annual intervals. If there is a need for immediate action, the Top Management MUST be informed immediately.
DER.2.1.A18 Further Development of Processes Based on Findings from Security Incidents and Industry Developments [Process Owner] (S)
After a security incident has been analysed, there SHOULD be an investigation of whether the procedures for handling security incidents need to be changed or developed further. All those involved in the incident SHOULD report on their respective experiences. 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 SHOULD be examined. If checklists and auxiliary resources are being used (e.g. by service desk members), a check SHOULD be carried out on whether these should be complemented by relevant questions and information.
DER.2.1.A19 Specifying Priorities for Handling Security Incidents [Top Management] (H)
Priorities for handling security incidents SHOULD be established in advance and updated regularly. This SHOULD also take into account the classification of security incidents. The priorities SHOULD be approved and implemented by an organisation’s Top Management. All those with decision authority who are involved in handling security incidents SHOULD be familiar with them. The defined priority classes SHOULD also be stored in an incident management system.
DER.2.1.A2 Drawing Up a Policy for Handling Security Incidents (B)
A policy governing the handling of security incidents MUST be prepared. This policy MUST define its purpose and objective and govern all aspects of handling security incidents. It MUST therefore describe codes of conduct for the different types of security incidents. In addition, there MUST be target-group-oriented and practically usable instructions for all employees. Furthermore, the interfaces with other management areas SHOULD be taken into account, including in business continuity management. All employees MUST be familiar with the policy. It MUST be agreed by the IT Operation Department and approved by the organisation’s Top Management. The policy MUST be reviewed and updated regularly
DER.2.1.A20 Creation of a Dedicated Reporting Office for Security Incidents (H)
A dedicated office SHOULD be established for reporting security incidents. It SHOULD be guaranteed that the reporting office is available during normal office hours. However, it SHOULD also be possible for employees to report security incidents outside of normal office hours. The reporting office employees SHOULD be adequately trained and aware of issues related to information security. All information on security incidents SHOULD be treated confidentially within the reporting office.
DER.2.1.A21 Assembling a Team of Experts for Handling Security Incidents (H)
A team of experienced and trusted experts SHOULD be established. Along with technical expertise, the members of the team SHOULD also have competences in the field of communication. The trustworthiness of the members of the team of experts SHOULD be checked. The composition of the expert team SHOULD be checked regularly and changed as necessary. The members of the team of experts SHOULD be included in the escalation and reporting channels. The team of experts SHOULD be trained to analyse security incidents in the systems deployed in their organisation. The members of the team of experts SHOULD receive regular training in both the systems used and detecting and responding to security incidents. The team of experts SHOULD have access to any existing documentation and the financial and technical resources required to handle security incidents quickly and discretely. The expert team SHOULD be appropriately considered and integrated into the organisational structures at hand. The responsibilities of the expert team SHOULD be coordinated in advance with those of the security incident team.
DER.2.1.A22 Reviewing Management System Efficiency in Handling Security Incidents (H)
Regular checks SHOULD ensure that the management system for handling security incidents is still up to date and effective. To this end, both announced and unannounced drills SHOULD be conducted. The drills SHOULD be coordinated in advance with the Top Management of the organisation in question. The parameters that are measured when security incidents are recorded, reported, and escalated (e.g. the time from the initial report to the binding confirmation of a security incident) SHOULD be evaluated. In addition, simulation exercises SHOULD be conducted on the handling of security incidents.
DER.2.1.A3 Specification of Responsibilities and Contact Persons in the Event of Security Incidents (B)
It MUST be specified who will be responsible for what in the event of security incidents. The tasks and competencies applicable in the event of security incidents MUST be defined for all employees. In particular, the employees who will handle security incidents MUST be informed of their tasks and competencies. In this context, it MUST be specified who will make the eventual decision regarding a forensic examination, the criteria to be followed in carrying it out, and when this should take place. The employees MUST know the contact persons for all types of security incident. Contact information MUST always be updated and easily accessible.
DER.2.1.A4 Notification of Entities Affected by Security Incidents [Top Management, IT Operation Department, Data Protection Officer, BCM Officer] (B)
When a security incident occurs, all the internal and external entities affected MUST be informed of the incident promptly. In this process, it MUST be checked whether the Data Protection Officer, the works council and personnel council, and employees from the legal department must be consulted. The reporting duties for public authorities and regulated industries MUST be taken into consideration, as well. Furthermore, it MUST be guaranteed that the entities affected are informed of the actions they need to take.
DER.2.1.A5 Remedial Action in Connection with Security incidents [IT Operation Department] (B)
In order for a security incident to be remedied successfully, the person responsible MUST initially contain the problem and find the cause. They MUST then select the safeguards necessary to fix the problem. The head of the IT Operation Department MUST approve the safeguards before they are implemented. The cause MUST then be eliminated and a secure state established. There MUST be a current list of internal and external security experts who may be consulted in the event of security incidents to answer questions from the subject areas involved. Secure communication methods with these internal and external entities MUST be established.
DER.2.1.A6 Recovering the Operating Environment After Security Incidents [IT Operation Department] (B)
After a security incident, the affected components MUST be removed from the network. In addition, all necessary data that could provide information about the nature and cause of the problem MUST be backed up. On all the components affected, the operating systems and all applications MUST be checked for changes. The original data MUST be reinstalled from write-protected data storage media. In so doing, all security-related configurations and patches MUST also be implemented. If data from backups is reimported, it MUST be ensured that the data was not affected by the security incident. After an attack, all access data on the affected components MUST be changed before they are put back into operation. The components affected SHOULD be subjected to a penetration test before they are used again. When recovering the secure operating environment, the users MUST be involved in the functional tests of the applications. After everything has been recovered, the components (including the network transitions) MUST be monitored in a targeted manner.
DER.2.1.A7 Establishment of a Procedure for Handling Security Incidents [Top Management] (S)
A suitable procedure SHOULD be established for handling security incidents. The procedures and specifications for different security incidents SHOULD be clearly stipulated and documented appropriately. An organisation’s Top Management SHOULD implement the agreed procedure and make it accessible to everyone involved. Regular checks SHOULD be carried out to ensure that the procedure is still up to date and effective. The procedure SHOULD then be amended as required.
DER.2.1.A8 Design of Organisational Structures for Handling Security Incidents (S)
Appropriate organisational structures SHOULD be defined for handling security incidents. A security incident team SHOULD be established with members who may be called in depending on the type of incident. Even if the security incident team only meets when a specific incident has occurred, appropriate members SHOULD be appointed in advance and instructed on how to perform their tasks. Regular checks SHOULD be carried out to ensure that the composition of the security incident team is still appropriate. Changes SHOULD then be made to the security incident team as required.
DER.2.1.A9 Definition of Reporting Paths for Security Incidents (S)
Reporting channels SHOULD be established that are appropriate to the different types of security incidents. These SHOULD ensure that employees can report security incidents quickly and easily using reliable and trustworthy channels. If a central contact point for reporting failures or security incidents is established, this SHOULD also be communicated to all employees. There SHOULD be a communication and contact strategy. This strategy SHOULD specify who must be informed as a matter of principle, who may be informed, who is responsible for handling this and in what order, and the level of detail of the information provided. It SHOULD specify who will pass information about security incidents on to third parties. It SHOULD ensure that no unauthorised persons forward information on security incidents.
DER.2.2 Provisions for IT Forensics
Target Object: Information domain/generic aspects / Order: R3
DER.2.2.A1 Examination of Legal and Regulatory Framework Conditions for Acquisition and Evaluation [Data Protection Officer, Top Management] (B)
If data is acquired and evaluated for forensic examinations, all the legal and regulatory framework conditions MUST be identified and met (see ORP.5 Compliance Management). Internal regulations and agreements with employees MUST NOT be violated. To that end, the supervisory/personnel board and the Data Protection Officer MUST be involved.
DER.2.2.A10 Forensic Securing of IT Evidence [Process Owner] (S)
Storage media SHOULD be forensically duplicated as completely as possible. If this is not possible (e.g. in the case of volatile data in RAM or SAN partitions), a method that changes as little data as possible SHOULD be selected. The original storage media SHOULD sealed and retained. Cryptographic checksums that are documented in writing SHOULD be created from the storage media. These SHOULD be kept separately and in multiple copies. In addition, it SHOULD be ensured that the checksums documented in this way cannot be changed. A witness SHOULD confirm the corresponding procedure and certify the checksums so that the data is admissible in court. Only trained personnel (see DER.2.2.A6 Training Personnel on Forensic Securing of Evidence) or a provider of forensic services (see DER.2.2.A3 Pre-Selection of Forensic Service Providers) SHOULD be assigned to secure evidence.
DER.2.2.A11 Documentation of Securing Evidence [Process Owner] (S)
When evidence is secured forensically, all the steps carried out SHOULD be documented. The documentation SHOULD provide seamless proof of how secured original evidence has been handled. In addition, the employed methods and the reasons why the persons in charge used them SHOULD be documented.
DER.2.2.A12 Secure Storage of Original Storage Media and Evidence [Process Owner] (S)
All secured original storage media SHOULD be stored physically in such a way that only investigating employees known by name can access them. If original storage media and evidence are stored, the period for which they are to be retained SHOULD be specified. After this period expires, it SHOULD be checked whether the storage media and evidence must be stored further. At the end of the storage period, evidence SHOULD be securely deleted or destroyed and the original storage media returned.
DER.2.2.A13 Framework Agreements with External Service Providers (H)
An organisation SHOULD conclude call-off agreements or framework contracts with forensic service providers in order to have possible IT security incidents forensically investigated more quickly.
DER.2.2.A14 Specifying Standard Procedures for Securing Evidence (H)
Standard procedures that make it possible to forensically secure volatile and non-volatile data as completely as possible SHOULD be created for applications, IT systems, and IT system groups with increased protection needs, as well as for distributed system configurations. The relevant system-specific standard procedures SHOULD be implemented by proven (and preferably automated) processes. Furthermore, they SHOULD be supported by checklists and auxiliary technical resources—for example, by software, software tools on mobile storage media, and forensic IT hardware such as write-blockers.
DER.2.2.A15 Conducting Drills on Securing Evidence (H)
All the employees involved in forensic analyses SHOULD take part in regular drills that provide training on how to secure evidence should an IT security incident occur.
DER.2.2.A2 Drawing Up a Guide for Initial Measures in Case of an IT Security Incident (B)
A guide MUST be drawn up for the IT systems used that describes the initial measures that must be carried out in the event of an IT security incident in order to destroy as little evidence as possible. This guide MUST also describe the actions that could destroy potential evidence and how they can be avoided.
DER.2.2.A3 Pre-Selection of Forensic Service Providers (B)
If an organisation does not have its own forensics team, suitable providers of forensic services MUST be identified during the preparatory phase. The eligible providers of forensic services MUST be documented.
DER.2.2.A4 Identifying Common Areas Between IT Forensics and Crisis / Business Continuity Management (S)
The areas in which forensic IT examinations and crisis / business continuity management overlap SHOULD be defined and documented. The employees responsible for specific tasks and the channels to be used to communicate with them SHOULD be specified. Furthermore, it SHOULD be ensured that the responsible contact persons are always available.
DER.2.2.A5 Drawing Up a Guide to Securing Evidence in Case of IT Security Incidents (S)
A guide describing how evidence is to be secured SHOULD be drawn up. This guide SHOULD specify procedures, technical tools, legal framework conditions, and documentation requirements.
DER.2.2.A6 Training Personnel on Forensic Securing of Evidence (S)
All the employees responsible SHOULD know how to secure evidence and use forensic tools correctly. In this regard, suitable training SHOULD be carried out.
DER.2.2.A7 Selecting Tools for Forensics (S)
It SHOULD be ensured that tools for securing and analysing evidence forensically are suitable for these purposes. Before using a tool for forensics, it SHOULD be checked that it works properly. It SHOULD also be verified and documented that it has not been manipulated.
DER.2.2.A8 Selection and Order of Evidence to Be Secured [Process Owner] (S)
A forensic examination SHOULD always start by defining the goals or assignment in question. The goals SHOULD be formulated as precisely as possible. All the required data sources SHOULD then be identified. The order in which data is to be secured and a detailed process for doing so SHOULD also be specified. The order SHOULD be based on the volatility of the data to be secured. Highly volatile data SHOULD be secured promptly. Non-volatile data such as read-only memory SHOULD only be secured afterwards, followed by backups.
DER.2.2.A9 Pre-Selection of Forensically Relevant Data [Process Owner] (S)
The method and time period for storing secondary data (e.g. log data or traffic transcripts) within the scope of the legal framework conditions for forensic measures to secure evidence SHOULD be specified.
DER.2.3 Clean-Up of Extensive Security Incidents
Target Object: Information domain/generic aspects / Order: R3
DER.2.3.A1 Creation of a Management Committee (B)
In order to clean up an APT incident, a management committee MUST be created to plan, coordinate, and monitor all the necessary activities. The committee MUST be provided with all the managerial authority necessary for its tasks. If a management committee of this kind was already in place when the APT incident was detected and classified, the same committee SHOULD also plan and oversee the cleaning process. If a specialised forensic service provider has already been brought in to analyse the APT incident, it SHOULD also be involved in the clean-up effort. The idea of setting up a crisis team SHOULD be examined if the IT systems in question are too compromised to continue operating or the clean-up measures are very extensive. In this case, the management committee MUST monitor the clean-up measures. The management committee MUST then report to the crisis team.
DER.2.3.A10 Modifications to Help Thwart a Repeat Attack (H)
If an organisation wants to prevent a previous attacker from performing another APT attack on its IT systems, the organisation SHOULD change the internal design of its network environment. Furthermore, mechanisms SHOULD be established that can be used to quickly detect a recurring attacker.
DER.2.3.A2 Deciding on a Cleaning Strategy (B)
Before an APT incident is actually cleaned up, the management committee MUST define a cleaning strategy. Here, it MUST be decided in particular whether the malware can be removed from the compromised IT systems and whether certain IT systems have to be reinstalled or replaced completely (including their hardware). Furthermore, the IT systems to be cleaned MUST be defined. These decisions MUST be based on the results of a previous forensic examination. All the IT systems affected SHOULD be reinstalled. Afterwards, the organisation's recovery schemes MUST be followed. Before backups are restored, however, forensic examinations MUST be performed to ensure that no manipulated data or programs will be transferred to a reinstalled IT system. If the organisation decides that it does not want to reinstall all of its IT systems, a targeted APT clean-up process MUST be implemented. To minimise the risk of overlooked backdoors, IT systems MUST be specifically monitored after the clean-up to see if they are still communicating with the attacker.
DER.2.3.A3 Isolation of Affected Network Segments (B)
The network segments affected by an APT incident MUST be isolated completely. In particular, these network segments MUST be cut off from the Internet. In order to effectively lock out the attacker and prevent them from covering their tracks or sabotaging other IT systems, the network segments MUST be isolated simultaneously. The network segments to be isolated MUST be determined in advance through forensic analysis. This MUST identify all the segments affected. If this cannot be guaranteed, all suspicious network segments MUST be isolated along with all those that are only theoretically infected. To effectively isolate network segments, all local Internet connections (e.g. additional DSL connections in individual sub-networks) MUST be documented as comprehensively as possible and taken into account.
DER.2.3.A4 Blocking and Changing Access Data and Cryptographic Keys (B)
All access data MUST be changed after an affected network is isolated. Furthermore, access data managed in a centralised manner MUST also be reset, including in Active Directory environments or when the Lightweight Directory Access Protocol (LDAP) has been used. If the central authentication server (domain controller or LDAP server) has been compromised, all the users on it MUST be blocked and have their passwords changed. This MUST be implemented by experienced administrators—if necessary, with the help of internal or external forensics experts. If TLS keys or an internal certification authority (CA) has been compromised by the APT attack, corresponding keys, certificates, and infrastructures MUST be regenerated and redistributed. The compromised keys and certificates MUST also be reliably blocked and withdrawn.
DER.2.3.A5 Closing the Initial Entry Route (B)
If a forensic examination determines that the attackers used a technical vulnerability to penetrate the network of the organisation in question, this vulnerability MUST be closed. If the attackers were able to compromise the IT systems as a consequence of human error, organisational, personnel-related, and technical measures MUST be taken to prevent similar incidents in the future.