chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
DER.3.2.A8 Storage of IS Audit Reports (B)
The organisation in question MUST securely store the IS audit report and the reference documents the report is based on for at least 10 years after it is produced, unless different laws or regulations apply. The organisation MUST ensure that only authorised persons may access the IS audit reports and reference documents.
DER.3.2.A9 Integration into the Information Security Process (S)
The Chief Information Security Officer SHOULD ensure that IS audits based on IT-Grundschutz form part of their organisation's security process. Furthermore, the results of IS audits SHOULD be incorporated back into the improvement of the ISMS at hand. In addition, the results of IS audits and activities to remedy deficiencies and improve quality SHOULD be included in the CISO's regular report to the organisation's Top Management.
DER.4 Business Continuity Management
Target Object: Information domain/generic aspects / Order: R3
DER.4.A1 Creating an Emergency Handbook (S)
An emergency handbook SHOULD be drawn up that contains the most important information on the following: • Roles • Immediate measures • Alerts and escalation • Communication plans, basic business continuity plans, and restoration plans Responsibilities and competencies SHOULD be assigned, communicated, and recorded in the emergency handbook. It SHOULD be ensured that appropriately trained personnel are available in emergencies. Tests and drills SHOULD be performed regularly to check that the safeguards described in the emergency handbook work as intended. The emergency handbook SHOULD be checked regularly and updated as required. It SHOULD be accessible in an emergency. The emergency handbook SHOULD be supplemented with codes of conduct for special cases (involving a fire, for example). These rules SHOULD be communicated to all employees.
DER.4.A10 Tests and Emergency Drills [Top Management] (H)
Regular and event-based testing and drills of all essential emergency measures and emergency plans SHOULD be carried out in an appropriate manner. The time frame and technical coverage of all drills SHOULD be documented in an overall drill plan. Business continuity management SHOULD have adequate resources available for planning, designing, executing, and assessing tests and drills.
DER.4.A12 Documentation in the Business Continuity Management Process (H)
The sequence of events in the business continuity management process, the results of the work done in each of the phases, and all major decisions SHOULD be documented. An established procedure SHOULD ensure that these documents are regularly updated. Furthermore, access to the documentation SHOULD be limited to authorised persons.
DER.4.A13 Checking and Controlling the Business Continuity Management System [Top Management] (H)
The Top Management of the organisation at hand SHOULD regularly obtain information on the status of its business continuity management system through management reports. It SHOULD therefore review and assess the business continuity management system on a regular basis and make any necessary corrections.
DER.4.A14 Regular Checking and Improvement of Business Continuity Safeguards [Top Management] (H)
All business continuity safeguards SHOULD be checked regularly or in case of major changes to see if they are still being adhered to and correctly implemented. Whether they are still suitable to achieve the defined objectives SHOULD be checked. During this process, it SHOULD be determined whether technical safeguards are implemented and configured correctly, and whether organisational safeguards are implemented effectively and efficiently. In case of deviations, the causes of defects SHOULD be identified and measures for improvement initiated. The organisation's Top Management SHOULD approve the summary of results. Furthermore, a process that controls and monitors whether and how measures for improvement are implemented SHOULD be established. Delays SHOULD be reported promptly to Top Management. The organisation's Top Management SHOULD specify how to coordinate the reviews. These examinations SHOULD be planned so that no relevant parts are skipped. In particular, the examinations performed in the areas of auditing, IT, security management, information security management, and business continuity management should be coordinated with each other. To this end, regulations SHOULD be in place that define who should which safeguards and when.
DER.4.A15 Assessing the Performance of the Business Continuity Management System [Top Management] (H)
The performance and effectiveness of a business continuity management system SHOULD be assessed regularly. Measurement and assessment criteria such as key performance indicators SHOULD be defined for this purpose. These metrics SHOULD be determined regularly and compared against suitable previous values, including (at minimum) the previous year's values. If the values deviate in a negative way, the causes SHOULD be identified and measures for improvement defined. The results of the assessment SHOULD be reported to Top Management. Top management SHOULD define the safeguards to be included in the further development of the business continuity management system. All Top Management decisions SHOULD be documented and the previous records updated.
DER.4.A16 Contingency Planning and Emergency Response Planning for Outsourced Components [Top Management] (H)
Contingency planning and emergency response planning for outsourced components SHOULD include regular reviews of the business continuity management systems of the respective suppliers and service providers with respect to the contracts signed with them. The processes in place SHOULD also be coordinated and, if applicable, performed together with the suppliers and outsourcing service providers in business continuity tests and drills. The results and assessments SHOULD be exchanged regularly between suppliers and service provides and the Top Management of the organisation in question. The assessments SHOULD also include any possible measures for improvement.
DER.4.A2 Integration of Business Continuity Management and Information Security Management [Chief Information Security Officer (CISO)] (S)
Security management processes SHOULD be coordinated with business continuity management (see DER.2.1 Security Incident Handling).
DER.4.A3 Specifying the Scope and the Business Continuity Strategy [Top Management] (H)
The scope of the business continuity management system at hand SHOULD be clearly specified. The respective organisation's Top Management SHOULD specify a business continuity strategy that states the goals to be reached and the level of risk considered acceptable.
DER.4.A4 Policy for Business Continuity Management and Acceptance of Overall Responsibility by Top Management [Top Management] (H)
The Top Management SHOULD adopt a policy for business continuity management. This SHOULD include the essential aspects of business continuity management. The business continuity policy SHOULD be checked regularly and revised when necessary. All employees SHOULD be informed of its provisions.
DER.4.A5 Establishing a Suitable Organisational Structure for Business Continuity Management [Top Management] (H)
Roles for business continuity management SHOULD be appropriately defined for the circumstances of the organisation in question. This SHOULD be documented in writing together with the tasks, obligations, and competencies of the roles. Qualified employees SHOULD be appointed to all the roles involved in the organisation's business continuity management. The organisational structure in business continuity management SHOULD be regularly checked to ensure it is effective, efficient, and fit for purpose.
DER.4.A6 Providing Adequate Resources for Business Continuity Management [Top Management] (H)
The financial, technical, and personnel resources provided SHOULD be sufficient to achieve an organisation's intended goals in business continuity management. The BCM Officer and the members of the business continuity management team SHOULD be allocated sufficient time to perform their tasks.
DER.4.A7 Creating a Contingency Concept [Top Management] (H)
All critical business processes and resources SHOULD be identified (e.g. based on a business impact analysis, or BIA). The most important and relevant risks to critical business processes and specialised tasks and the resources they require SHOULD be identified. The strategies to be used to treat risks SHOULD be specified for each identified risk. An organisation SHOULD develop continuity strategies that enable its critical business processes to be restored and restarted within the required time. A contingency concept SHOULD be drawn up. Contingency plans and safeguards SHOULD also be developed and implemented that enable an effective emergency response and quick recovery of the critical business processes. The contingency concept SHOULD include considerations of information security and elaborate on corresponding security concepts for business continuity solutions.
DER.4.A8 Integrating Employees into the Business Continuity Management Process [Supervisor, Human Resources Department] (H)
All employees SHOULD receive appropriate awareness training on business continuity management on a regular basis. There SHOULD be a training and awareness concept for business continuity management. The employees on the business continuity management team SHOULD receive regular training to hone the skills they need.
DER.4.A9 Integrating Business Continuity Management into Organisation-Wide Procedures and Processes [Top Management] (H)
It SHOULD be ensured that business continuity aspects are taken into account in all of an organisation's business processes and specialised tasks. The processes, requirements, and responsibilities in business continuity management SHOULD be coordinated with risk management and crisis management.
IND.1 Process Control and Automation Technology
Target Object: Information domain/generic aspects  / Order: R2
IND.1.A1 Integration into the Security Organisation (B)
An information security management system (ISMS) for the operation of OT infrastructure MUST exist either as a stand-alone ISMS or as part of an overall ISMS. A person MUST be appointed with overall responsibility for OT information security. The details of this appointment MUST be publicised within the organisation in question.
IND.1.A10 Monitoring, Logging, and Detection [OT Operations] (S)
Operational and security-relevant events SHOULD be identified promptly. For this purpose, a suitable approach to log and event management SHOULD be developed and implemented. Log and event management SHOULD include adequate measures to detect and record security relevant events. It SHOULD also include a security incident response plan. The response plan SHOULD define procedures for handling security incidents. This plan SHOULD cover the classification of events, reporting channels and the definition of the organisational units to be involved, response plans to limit damage, the analysis and restoration of systems and services, and the documentation of and follow-up process for incidents.
IND.1.A11 Secure Procurement and System Development (S)
If OT systems are to be procured, planned, or developed, information security regulations SHOULD be established in this regard. The documents SHOULD be part of any related tender. During procurement, planning, or development, information security SHOULD be taken into consideration through the entire lifecycle. Prerequisites and implementation instructions for the secure operation of ICS components by manufacturers SHOULD be planned and implemented at an early stage. Uniform requirements for information security that correspond to the protection needs at hand SHOULD be defined for ICS components. These SHOULD be taken into consideration when procuring new ICS components. Compliance and implementation SHOULD be documented. The organisation in question SHOULD document how the system fits into its concepts for zoning, authorisation, and vulnerability management (as well as for virus protection) and adapt them if necessary. A plan for maintaining operations should a given partner stop providing its services SHOULD be formulated.
IND.1.A12 Establishing Vulnerability Management (S)
To ensure the secure operation of its OT environment, an organisation SHOULD establish a vulnerability management approach. Vulnerability management SHOULD identify gaps in software, components, protocols, and external interfaces in the environment under consideration. It SHOULD also make it possible to derive, assess, and implement necessary actions. This SHOULD be based on reports on vulnerabilities from manufacturers and publicly available CERT messages. In addition, organisational and technical audits SHOULD be performed for vulnerability analysis.
IND.1.A13 Contingency Planning for OT (H)
Business continuity plans SHOULD be defined, documented, tested after each major change, and drilled regularly for each zone to address the possibility of it failing or becoming compromised. An effective substitute procedure SHOULD also be defined, documented, and tested in case the option of (remote) administration fails.
IND.1.A14 Strong Authentication for OT Components (H)
A central directory service SHOULD be set up for the secure authorisation of privileged users in the control systems at hand (see module ORP.4 Identity and Access Management). Authentication SHOULD be secured further using several factors, such as knowledge, ownership, or biometrics. During planning, it SHOULD be ensured that any resulting dependencies in user authentication are known and taken into consideration when implementing a corresponding solution. It SHOULD be ensured that operationally required technical accounts can be authorised in emergencies.
IND.1.A15 Monitoring of Wide-Ranging Authorisations (H)
Organisations SHOULD maintain an inventory of all the access rights that have been granted for critical systems. This inventory SHOULD list the rights a particular user effectively has and who has what rights on a particular system. All critical administrative activities SHOULD be logged. The IT Operation Department SHOULD NOT be able to delete or manipulate the logs.
IND.1.A16 Stronger Compartmentalisation of Zones (H)
Interface systems with security checking functions SHOULD be used as a preventive measure in ICS environments that are highly sensitive or are difficult to secure. Continuous external connections SHOULD be terminated by implementing one or more connection zones (DMZ) in a P-A-P structure. Required security checks SHOULD be carried out in such a way that the respective ICS system does not have to be adapted.
IND.1.A17 Regular Security Vetting (H)
The security configurations of OT components SHOULD be checked regularly and as needed in the case of sudden threats which were previously unknown. This security vetting SHOULD at least cover exposed systems that involve external interfaces or user interaction. The implemented security concept SHOULD also be checked at regular intervals. Security vetting SHOULD be carried out as a configuration review, or also through automated conformity evaluations.
IND.1.A18 Logging [OT Operations)] (B)
Every change made to ICS components MUST be logged. In addition, all attempts to access to ICS components MUST be logged.
IND.1.A19 Creating Backups [Employee, OT Operations] (B)
Programs and data MUST be backed up regularly. A backup MUST also be made after each system change made to OT components.
IND.1.A20 System Documentation [Employee, OT Operations] (S)
Advanced system documentation SHOULD be drawn up. It SHOULD record particularities in operations and options for system administration. In addition, any changes made to ICS components SHOULD be documented.
IND.1.A21 Documentation of Communication Relationships [OT Operations)] (S)
The systems with which an ICS component exchanges data and the data exchanged in this regard SHOULD be documented. Furthermore, the communication links of newly integrated ICS components SHOULD be documented.
IND.1.A22 Central System Logging and System Monitoring [OT Operations] (S)
Log data of ICS components SHOULD be stored centrally. In case of security-critical events, alarms SHOULD be raised automatically.
IND.1.A23 Disposal of ICS Components [OT Operations] (S)
Sensitive data SHOULD be erased prior to the disposal of old or defective ICS components. In particular, it SHOULD be ensured that all access data has been permanently removed.
IND.1.A24 Communication in the Event of Incidents [OT Operations] (S)
Alternative and independent communication options SHOULD be established and operated.
IND.1.A3 Protection Against Malware (B)
When using anti-virus software on OT components, consideration MUST be given to whether and in which configuration the operation of anti-virus software is supported by its manufacturer. If this is not the case, the need for alternative protection methods MUST be checked. Virus signatures MUST NOT be obtained by OT systems directly from the Internet.
IND.1.A4 Documentation of OT Infrastructure (S)
All the security-relevant parameters of the OT infrastructure at hand SHOULD be documented. All software and system components SHOULD be documented in an inventory list. This list SHOULD state the product and protocol versions used, as well as the respective responsibilities. For the components used, any applicable manufacturer restrictions or regulatory conditions SHOULD be defined. This documentation and a system inventory SHOULD be maintained—for example, in a control system. In addition to this, an up-to-date network plan SHOULD document zones, zone transitions (conduits), and the communication protocols and methods used, as well as the external interfaces. For the interfaces, active network components and manual data transfer methods (e.g. using removable media) SHOULD be taken into account. Automation solutions SHOULD be structured into cells and communication channels to enable the zones and conduits at hand to protect the OT infrastructure.
IND.1.A5 Development of a Suitable Zone Concept [Planner] (S)
OT infrastructure SHOULD also be segmented horizontally into independent functional areas such as facilities. The individual zones SHOULD be as independent from one another as possible during operations. In particular, the zones where the respective technical process is controlled SHOULD continue to function for a certain period of time if the other zones fail. This period SHOULD be appropriately defined and documented, and decoupling SHOULD also continue to function after an attack. The network SHOULD be designed to be resistant to errors and manipulation.
IND.1.A6 Change Management in OT Operations (S)
A suitable change process SHOULD be defined, documented, and used actively when making changes to OT.
IND.1.A7 Establishing Comprehensive Authorisation Management Across OT and Office IT (S)
An organisation SHOULD establish a process for managing user access and assigned authorisations for OT. A corresponding authorisation management system SHOULD cover this process, along with the implementation and documentation of activities involved in applying for, configuring, and withdrawing authorisations. The authorisation management system SHOULD ensure that authorisations are granted according to the minimum principle and checked at regular intervals. In the authorisation management system, access to IT systems SHOULD be regulated for employees, administrators, and third parties. Everyone involved SHOULD be made aware of the rules to be followed at regular intervals. Compliance SHOULD be checked. Misconduct SHOULD be sanctioned.
IND.1.A8 Secure Administration [IT Operation Department] (S)
For the initial configuration, administration, and remote maintenance of OT, either secure protocols or separate administration networks with corresponding protection needs SHOULD be used. Access to these interfaces SHOULD be restricted to the persons authorised. The access granted to systems and functions SHOULD be limited to the requirements for the respective administration tasks. The systems and communication channels used to carry out administration or remote maintenance SHOULD have the same level of protection as the OT components administered.
IND.1.A9 Restrictive Use of Removable Media and Mobile Devices in ICS Environments (S)
Rules for handling removable media and mobile devices SHOULD be established and communicated. The use of removable media and mobile devices in ICS environments SHOULD be restricted. For the media and devices of service providers, an approval process and a requirements list SHOULD be available. Each service provider SHOULD be familiar with the specifications and confirm them in writing. On OT components, all interfaces that are not required SHOULD be disabled. The usage of active interfaces SHOULD be restricted to certain devices or media.
IND.2.1 General ICS Components
Target Object: IT system / Order: R2
IND.2.1.A1 Restriction of Access to Configuration and Maintenance Interfaces [OT Operations] (B)
Passwords set by default or by the manufacturer MUST be changed (see ORP.4 Identity and Access Management). These changes MUST be documented. Passwords MUST be stored securely. It MUST be ensured that only authorised employees are allowed to access the configuration and maintenance interfaces of ICS components. The configuration of an ICS component MUST ONLY be changed after the approval or authentication of the person in charge.
IND.2.1.A11 Maintenance of ICS Components [Employee, OT Operations, Maintenance Personnel] (S)
The latest approved security updates SHOULD always be installed when maintaining an ICS component. Updates for the respective operating system SHOULD only be installed following approval by the manufacturer of a given ICS component. Alternatively, updates SHOULD be checked in a test environment before they are used in a productive ICS component. Maintenance SHOULD be performed on short notice for critical security updates.
IND.2.1.A13 Appropriate Commissioning of ICS Components [OT Operations] (S)
Before they are commissioned, ICS components SHOULD correspond to the latest internally approved firmware, software, and patch status. New ICS components SHOULD be integrated into existing operating, monitoring, and information security management processes.
IND.2.1.A16 Protecting External Interfaces [OT Operations] (S)
Externally accessible interfaces SHOULD be protected against misuse.
IND.2.1.A17 Use of Secure Protocols for the Transmission of Measurement and Control Data [OT Operations] (S)
Measurement or control data SHOULD be protected against unauthorised access or changes during transmission. Whether this is necessary or feasible SHOULD be checked in situations involving applications with real-time requirements. If measurement or control data is transmitted using public networks, it SHOULD be protected appropriately.
IND.2.1.A18 Communication in the Event of Incidents [OT Operations, Employee] (S)
There SHOULD be alternative and independent communication options that an organisation can use to maintain its ability to function in the event of malfunctions.
IND.2.1.A19 Security Tests [OT Operations] (H)
Regular security tests SHOULD be carried out to check whether the technical security safeguards in place are still implemented efficiently. These security tests SHOULD NOT be carried out while the respective system is running. Such tests SHOULD be scheduled for maintenance periods. The results SHOULD be documented. Identified risks SHOULD be evaluated and addressed.
IND.2.1.A2 Using Secure Transmission Protocols for Configuration and Maintenance [Maintenance Personnel, OT Operations] (B)
Secure protocols MUST be implemented for configuring and maintaining ICS components. Information MUST be protected during transmission.
IND.2.1.A20 Trustworthy Code [OT Operations] (H)
Firmware updates or new control programs SHOULD ONLY be installed after their integrity has been checked. They SHOULD only come from trusted sources.
IND.2.1.A4 Disabling or Uninstalling Unused Services, Functions, and Interfaces [Maintenance Personnel, OT Operations] (B)
All services, features, and interfaces of ICS components that are not being used MUST be disabled or uninstalled.