chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
INF.12.A4 EMC-Compliant Power Supply [Building Services] (B)
The power supply at hand MUST be EMC (electromagnetic compatibility) compliant. To this end, the corresponding power distribution network MUST be designed as a TN-S system. When setting up and operating the power distribution network, the separation distances recommended in the relevant standards MUST be observed to the greatest extent possible. Precautions MUST be taken against external irradiation, power line emissions, and detection of transient currents.
INF.12.A5 Requirements Analysis for Cabling [IT Operation Department, Building Services] (S)
As a general rule, the requirements that may affect the economic efficiency of a cabling installation and its ability to meet all current and future requirements SHOULD be analysed. This requirements analysis SHOULD initially project how the cabling will be used within the organisation in question in the short term. On this basis, estimates SHOULD be made as to how usage might evolve over the longer term. Furthermore, the security objectives of availability, integrity, and confidentiality MUST also be taken into consideration during requirements analysis for cabling.
INF.12.A6 Cabling Approval [IT Operation Department, Building Services] (S)
There SHOULD be an approval process for cabling. Cabling SHOULD always be approved only after all the tasks at hand (possibly within the framework of a milestone) have been completed. The party responsible for its installation SHOULD have reported the tasks as completed and ready for approval. In addition, inspections by the client SHOULD not have revealed any unacceptable defects. The approval date SHOULD be selected so that there is enough time in advance to prepare for the approval inspections. The contractor involved MUST provide written evidence of compliance with all the applicable standards and regulations no later than the approval date. The actual scope of the services rendered MUST be verified during the approval process. A checklist SHOULD be drawn up for the approval report. The approval report MUST be signed in a legally binding manner by the participants and all the persons in charge. The report MUST be part of the internal documentation of cabling.
INF.12.A7 Overvoltage Protection [Building Services] (S)
Every electrical network SHOULD be protected against overvoltage. For this purpose, a corresponding overvoltage protection concept MUST be created that complies with the applicable standards. Emergency power systems (EPS) and uninterruptible power supplies (UPS) MUST be included in the overvoltage protection concept.
INF.12.A8 Removing and Disabling Cables No Longer Required [IT Operation Department, Building Services] (S)
If power cables are no longer required, they SHOULD be properly and completely removed. After cables have been removed, firestop seals MUST be professionally sealed. Cables that are currently no longer needed but can be reasonably left in place as a reserve with the existing technology SHOULD be maintained in a serviceable condition. At minimum, such cables MUST be labelled accordingly at their end points. In principle, an overview of cables that are no longer needed SHOULD be created. The documentation SHOULD show which cables have been removed or disabled.
INF.12.A9 Fire Prevention in Trays [Building Services] (S)
Trays SHOULD be adequately dimensioned. Trays SHOULD have adequate ventilation.
INF.13 Technical Building
Management (TBM)
Target Object: Building/room / Order: R2
INF.13.A1 Assessment of the Current Situation When Taking Over Existing Buildings (B)
When existing buildings are taken over, the installed building services systems, building fabric and equipment, and existing documentation MUST be recorded and assessed with regard to their condition (age, support status, future viability, completeness of documentation, etc).
INF.13.A10 Regulation of the Use of Building Information Modelling (S) [Planner]
Building information modelling (BIM) SHOULD be used whenever possible for the digital modelling of all relevant building data. When using BIM, the BIM project delivery plan SHOULD be specified. 
Furthermore, the BIM architecture SHOULD be comprehensively planned and designed. Information security SHOULD also be adequately ensured for BIM tools.
INF.13.A11 Adequate Hardening of Systems in TBM (S)
All systems in TBM and the systems operated by TBM SHOULD be adequately hardened. These hardening measures SHOULD be documented, reviewed both regularly and whenever required, and adjusted if necessary. 
For all systems in TBM and the systems operated by TBM, it SHOULD be ensured during procurement that they can be hardened appropriately and, in particular, that security-relevant updates will be provided for the systems'' planned service life. 
Systems that do not receive security-relevant updates SHOULD not be used if corresponding vulnerabilities are exposed. If this is not possible, the affected systems SHOULD be separated by network segmentation and their communication controlled and regulated.
INF.13.A12 Secure Configuration of TBM Systems (S)
All systems in TBM and systems operated by TBM SHOULD be configured securely. 
At minimum, these configurations SHOULD be tested before a system is put into operation. Configuration changes during productive operations SHOULD be tested on a test instance before activation or only carried out according to the principle of dual control. 
The configuration of systems SHOULD be backed up to enable quick re-installation of an error-free version (rollback). Rollback tests SHOULD be set up on a test system or performed during maintenance windows. The configurations SHOULD be stored centrally. 
Automated distribution of software updates and configurations SHOULD be set up for similar systems, including devices at the automation and field level (see section 4.1, TBM-Specific Terminology Used). 
Configuration changes SHOULD be made known to all the parties involved in operational and service processes (fault clearance, on-call service, maintenance, etc). In particular, these include: 
•	Changes to access mechanisms or passwords 
•	Changes to communication and control parameters for integrated systems 
In the event of a malfunction, it SHOULD be ensured that a maintenance technician can operate or parameterise the system affected (for example). 
Furthermore, whether systems are configured according to the corresponding specifications SHOULD be checked both regularly and whenever required. The results SHOULD be documented in a transparent manner. Deviations from the specifications SHOULD be corrected.
INF.13.A13 Secure Connection of Restricted Trusted Systems in TBM (S) [Planner]
Systems with limited trustworthiness that need to be integrated into TBM for important operational reasons SHOULD be connected via a system that controls and regulates their communication by means of firewall functions. This system SHOULD be the responsibility of TBM.
INF.13.A14 Consideration of Special Roles and Authorisations in TBM (S)
The TBM role and authorisation concept at hand SHOULD take into account both the demand organisations and the operator organisations of TBM systems and building services systems. This SHOULD be carefully planned, especially if TBM is provided across the entire organisation in question.
INF.13.A15 Protection Against Malware in TBM (S)
If anti-virus programs cannot be run on a system in line with module OPS.1.1.4 Protection Against Malware—for example due to resource constraints or real-time requirements— appropriate alternative protection methods SHOULD be used. 
Each external system and storage medium SHOULD be checked for malware before being connected to a TBM system or transferring data.
INF.13.A16 Process for Changes in TBM (S)
Changes SHOULD always be announced and agreed with all the trades (see section 4.1, TBMSpecific Terminology Used) and operator and demand organisations involved. In addition, provisions SHOULD be made for the event that rolling back flawed changes is not possible, or only possible with a great deal of effort. Therefore, tests should be carried out in change management before a change is executed, including on the possibility of rolling back the change. The respective depth of testing SHOULD be determined for the different types of changes. A correspondingly high depth of testing SHOULD be provided for the introduction of new systems and for major changes to existing systems (see INF.13.A22 Performing System Tests in TBM).
INF.13.A17 Provisions for Maintenance and Repairs in TBM (S)
Building facilities SHOULD be maintained at regular intervals. A maintenance schedule SHOULD be drawn up for this purpose. The security aspects to be observed during maintenance and repair work SHOULD be regulated. The interdependencies of different trades SHOULD also be taken into account. The persons responsible for the maintenance or repair of facilities SHOULD also be specified. The maintenance tasks carried out SHOULD be documented. 
It SHOULD be ensured at all times that maintenance and repair work carried out by third parties is monitored, only carried out in a coordinated manner, and approved upon completion. For this purpose, internal Building Services employees SHOULD be designated to authorise and observe maintenance and repair work, support it if necessary, and approve it upon completion.
INF.13.A18 Proactive Maintenance in TBM (S) [Planner]
Appropriate proactive maintenance SHOULD be carried out for systems managed by TBM. For this purpose, regular maintenance intervals SHOULD be defined for each system. Whether predictive maintenance can be used in addition to regular maintenance SHOULD also be considered for each system, along with the extent to which the regular maintenance intervals can be extended as a result.
INF.13.A19 Conceptualisation and Implementation of Monitoring in TBM (S) [Planner]
A concept for monitoring in TBM SHOULD be developed and implemented. This SHOULD specify how the systems to be managed by TBM can be integrated into a monitoring system that is as uniform as possible and which values should be monitored. For this purpose, the necessary interfaces for monitoring important states of systems that are managed by TBM SHOULD be specified during a requirements analysis. In addition, the systems used for TBM SHOULD be integrated into the monitoring. 
The concept SHOULD be reviewed both regularly and whenever required and updated as necessary to reflect the current state of the art and include the latest findings. 
Status messages or monitoring data SHOULD ONLY be transmitted using secure communication channels.
INF.13.A2 Regulation and Documentation of Responsibilities and Authorities in the Building [Top Management, Planner] (B)
Since there are usually different responsibilities and authorities for different areas in a building, the corresponding rights, duties, tasks, competencies, and related processes MUST be regulated and documented. In this context, the organisational structures in the building MUST also be considered and documented. In particular, all demand and operator organisations MUST be recorded. If TBM is carried out by an external operator organisation, the associated rights, duties, tasks, and competencies MUST be governed by a contract in accordance with module OPS 2.1 Outsourcing for Customers. Furthermore, the interfaces and reporting channels—including for escalation—among all the parties involved MUST be defined and documented. The coordination of different operator organisations MUST also be regulated and documented. Access to the documentation MUST be regulated. All documentation, including the associated contact information, MUST always be up to date and available.
INF.13.A20 Provisions for Event Management in TBM (S) [Planner]
Events that occur in TBM SHOULD be categorised, filtered, and classified with regard to their significance and influence. Threshold values SHOULD be defined for such events to enable their automated classification. Depending on the classification of the events, appropriate measures for monitoring, alerting, and reporting channels (escalation) SHOULD be defined along with measures for logging.
INF.13.A21 Logging in TBM (S)
Events that have been appropriately classified in event management SHOULD be logged. In addition, events relevant to the security of the systems at hand SHOULD be logged. 
All attempts to access configurations and all instances of manual and automated control access SHOULD be logged. Depending on the level of protection required, full logging (including metadata and the content of changes) SHOULD take place. 
Logging SHOULD be consolidated on a central logging instance. 
Logging data SHOULD ONLY be transmitted using secure communication channels. 
In case of security-critical events, alarms SHOULD be raised automatically.
INF.13.A22 Performing System Tests in TBM (S) [Planner]
TBM systems and systems managed by TBM SHOULD be tested with regard to their functional and non-functional requirements before they are put into operation and whenever major system changes are made. This SHOULD include checking of the target and actual behaviour of functions and settings. For non-functional requirements, information security requirements SHOULD also be tested and additional load tests should be performed if required. A specification containing a description of the test environment, the test depth, and the test cases (including the criteria for a successfully completed test) SHOULD be created for the tests. The completion of tests SHOULD be documented in a test report. 
The test specification SHOULD be reviewed both regularly and whenever required and updated as necessary to reflect the current state of the art and include the latest findings.
INF.13.A23 Integration of TBM into Vulnerability Management (S)
TBM systems and systems managed by TBM SHOULD be continuously monitored for possible vulnerabilities. 
For this purpose, information on vulnerabilities that have become known SHOULD be obtained regularly and taken into account accordingly. This SHOULD include a review of the configuration of the systems at hand to determine whether it offers a favourable environment to known vulnerabilities. 
Furthermore, it SHOULD be decided for which systems vulnerability scans should be carried out regularly, or at least when the systems are put into operation and in case of major system changes. For vulnerability scans, the scan depth SHOULD be specified. Whether a passive or an active scan is to be performed SHOULD also be specified. In production environments, passive scans SHOULD be preferred. Active scans SHOULD only be performed in production environments if they are necessary and personnel are called in to resolve any errors or failures that may occur as a result of the scan.
INF.13.A24 Ensuring Control of Cloud-Based Processes for TBM (S) [Planner]
If cloud-based services are used in TBM, control of all TBM processes SHOULD remain in the TBM system. This SHOULD be included in the terms of a corresponding contract when using a service from a cloud provider.
INF.13.A25 Establishment of a Test Environment for TBM (H) [Planner]
In case of increased protection needs, a test environment SHOULD be set up for TBM systems and those managed by TBM. This makes it possible to test hardware and software before they are put into operation and in case of changes, and to reduce errors in productive operation. In addition, provisions SHOULD be specified for dealing with systems for which a test environment cannot be established.
INF.13.A26 Securing BIM (H) [Planner]
If security-critical information is also captured in BIM, appropriate security and hardening measures SHOULD be provided both at the level of the BIM architecture and for the implementation and operation of the BIM solution. The protection SHOULD include a tightened role and authorisation concept and more advanced protection measures such as encryption, segmentation, and higher level authentication mechanisms (in particular, twofactor authentication).
INF.13.A27 Establishment of a Private Cloud for TBM (H) [Planner]
For higher protection needs, cloud services related to TBM SHOULD be located in a private on-premise cloud or a private cloud with a trusted cloud provider. The use of a public cloud SHOULD be avoided.
INF.13.A28 Secure Use of Artificial intelligence in TBM (H)
If artificial intelligence (AI) functions are used in TBM when there is an increased need for protection, only AI that is demonstrably secure SHOULD be used. At the very least, care SHOULD be taken to ensure that no data is routed to networks that do not belong to the organisation in question or are not trustworthy. 
For cloud-based AI services, the criteria of the BSI AI Cloud Service Compliance Criteria Catalogue (AIC4) SHOULD be considered in addition to the requirements of module OPS.2.2 Cloud Usage.
INF.13.A29 Integration of TBM into SIEM (H) [IT Operation Department]
If a system is used for security information and event management (SIEM), the TBM systems and, where possible, the systems managed by TBM SHOULD be integrated accordingly in order to be able to detect and analyse security incidents across systems and applications.
INF.13.A3 Documentation of Building Facilities (B)
All the building facilities pertaining to building services and BACS MUST be documented. Any existing documentation MUST be merged, organised from the perspective of TBM, and supplemented with TBM-specific information. 
Access to the documentation MUST be regulated. All documentation, including the associated contact information, MUST always be up to date and available.
INF.13.A30 Performing Penetration Tests in TBM (H)
Penetration tests SHOULD be carried out as needed to adequately secure TBM systems and systems managed by TBM. At minimum, penetration tests SHOULD be carried out in a test environment before productive operation and in case of major system changes. 
If AI functions are used in TBM, these SHOULD be included in the penetration tests.
INF.13.A4 Creation of a Security Policy for TBM (S)
Based on an organisation's general information security policy, an overall security policy for TBM SHOULD be established and implemented in a comprehensible way. Specific security policies for the different subject areas of TBM SHOULD be derived from this overall security policy. The security policy for TBM SHOULD comprehensibly describe requirements and specifications on how TBM is implemented. The security policy SHOULD be reviewed both regularly and whenever required and updated as necessary to reflect the current state of the art and include the latest findings. It SHOULD be known to all employees responsible for TBM and be integral to their work.
INF.13.A5 Planning TBM (S) [Planer]
TBM, the underlying infrastructure, and the associated processes SHOULD be planned appropriately. This planning SHOULD at least include a detailed requirements analysis and a sufficient rough conceptual design, along with detailed and implementation planning. 
The requirements analysis SHOULD specify requirements for TBM infrastructure and TBM processes. Here, all the essential elements of TBM SHOULD be taken into account. The security policy for TBM SHOULD also be considered. If the demand organisation in question has not yet been defined at the time of planning, basic requirements in line with the current state of the art SHOULD be established at minimum in the context of universal planning. 
For the requirements specification, the interfaces of the systems to be managed SHOULD also be documented (e.g. to ensure the compatibility of the TBM solution and the systems to be managed). 
In addition, before commissioning service providers or purchasing hardware or software for the systems to be managed by TBM, the TBM requirements SHOULD be specified in a TBM requirements specification. This specification SHOULD also take into account the performance of tests (see also INF.13.A22 Performing System Tests in TBM). 
If artificial intelligence (AI) functions are used in TBM, the responsible manufacturer SHOULD be asked whether and how information security is adequately taken into account in this regard. 
The rough conceptual design SHOULD be carried out according to INF.13.A6 Drawing Up a TBM Concept. 
The detailed and implementation planning for TBM SHOULD take into account all the points addressed in the security guideline and the TBM concept.
INF.13.A6 Drawing Up a TBM Concept (S) [Planner]
Based on the security policy drawn up for TBM, a TBM concept SHOULD be established and consistently maintained. In doing so, the following minimum aspects SHOULD be taken into account as required: 
•	Methods, techniques, and tools for TBM 
•	Protection of access and communication 
•	Protection at the network level; in particular, the assignment of TBM components to network segments 
•	Scope of monitoring and alerts 
•	Logging of events and administrative access 
•	Reporting chains in the event of malfunctions and security incidents 
•	Processes required for TBM 
•	Provisioning of TBM information for other areas of the organisation 
•	Integration of TBM into contingency planning 
The TBM concept SHOULD be reviewed both regularly and whenever required and updated as necessary to reflect the current state of the art and include new findings. 
In addition, a gap analysis of the specifications of the concept and the current state SHOULD be carried out on a regular basis. In particular, whether the systems are configured according to the specifications SHOULD be checked. The results SHOULD be documented in a transparent manner. Deviations SHOULD be eliminated.
INF.13.A7 Creating a Radio Frequency Register (S)
To enable an organisation to use radio frequencies with as little interference as possible, a radio frequency register SHOULD be created that lists the systems and users of the frequency spectrum at the organisation''s sites. If frequencies could potentially be used by different systems and users, the primary user SHOULD be established for each frequency. This SHOULD be coordinated between IT and TBM. If OT is used in buildings, this SHOULD also be coordinated. 
The radio frequency register SHOULD be reviewed both regularly and whenever required and updated if necessary.
INF.13.A8 Creation and Maintenance of an Inventory for TBM (S) [Planner]
An inventory SHOULD be created and maintained for the documentation of systems managed by TBM. The inventory SHOULD be kept complete and up to date. The inventory SHOULD show responsibilities and authorities for all systems. 
The elements of the TBM infrastructure itself SHOULD also be documented.
INF.13.A9 Regulation of the Use of Computer-Aided Facility Management (S) [Planner]
If a computer-aided facility management (CAFM) system is used, its use SHOULD be comprehensively planned and designed. If processes are mapped and supported in CAFM, appropriate roles and authorisations SHOULD be defined, especially if external service providers are involved in the processes.
INF.14 Building Automation and
Control Systems (BACS)
Target Object: Building/room / Order: R2