chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
INF.14.A1 Planning BACS (B) [Planner]
For the trades controlled by BACS, a plan for designing the BACS in a secure manner MUST be established. 
BACS MUST be taken into account when planning the new construction, conversion, extension, or refurbishment of a building. BACS MUST therefore be considered in planning and construction processes for all BACS-relevant components and building services systems, including in connection with building information modelling (BIM). 
Within the scope of BACS planning, the BACS to be set up MUST be specified. The extent to which building services systems are to be controlled automatically via BACS MUST be specified. 
BACS SHOULD be planned in a way that minimises the different BACS, communication protocols, and interfaces used for the coupling and integration of building services systems. Secure and standardised protocols and interfaces SHOULD be used. When taking decisions regarding the necessary systems, protocols, and interfaces, the expected functionality SHOULD be weighed against a potential increase in effort to ensure operational and information security. 
The planning SHOULD be documented, reviewed both regularly and whenever required, and adjusted to the state of the art if necessary. 
Furthermore, the planning SHOULD be compared against the current configuration both on a regular basis and as required (gap analysis).
INF.14.A10 Formation of Independent BACS Areas (S) [Planner]
In BACS, different BACS areas SHOULD be planned and implemented in a way that minimises dependencies among them and makes it possible to control them independently. A disruption in one BACS area SHOULD have little or no impact on other BACS areas. 
In particular, it SHOULD be possible to control the buildings within a building complex or property separately. 
Accordingly, the established BACS areas SHOULD also be visible in the BACS management system.
INF.14.A11 Securing Freely Accessible Ports and Access Points in BACS (S) [Planner]
The connection of components (especially unauthorised, unknown components and thirdparty devices) SHOULD be controlled and restricted, particularly in the case of freely accessible Ethernet ports, USB ports, and other BACS interfaces. 
Connections of unauthorised or unknown components SHOULD be included in corresponding event logging. Direct IP-based communication from such components to BACS SHOULD be prevented (see INF.14.A13). 
For freely accessible LAN or WLAN connections, network access control in line with IEEE 802.1X or comparable security mechanisms SHOULD be used. This SHOULD include locating insufficiently authenticated and authorised components in separate network segments. 
Freely accessible interfaces used for temporary maintenance purposes (such as USB ports on BACS components) SHOULD only be activated when required.
INF.14.A12 Use of Secure Transmission Protocols for BACS (S)
For the configuration, maintenance, and control of BACS-relevant components based on Ethernet and IP, secure protocols SHOULD be used if communication does not take place via trusted network segments. 
Outside of trusted network segments, communication via Ethernet and IP between BACS SHOULD be encrypted. Encryption SHOULD be carried out using up-to-date encryption mechanisms.
INF.14.A13 Network Segmentation in BACS (S) [Planner]
Network segmentation SHOULD be implemented within a BACS network in a manner that separates individual BACS, individual building services systems, and individual groups of building services systems within each BACS as required. 
Appropriate rules SHOULD be defined for the transitions between the segments and used to implement components with security functions (stateful packet filters at minimum).
INF.14.A14 Use of BACS-Appropriate Access Protection (S)
For BACS, identity and access management in line with module ORP.4 Identity and Access Management SHOULD be used that adequately meets the requirements of the BACS at hand. For this purpose, a BACS-internal authentication solution or a suitable replication of a central authentication solution used by the organisation in question SHOULD be implemented in line with the relevant requirements. All BACS-relevant components SHOULD be integrated into the authentication solution whenever possible. 
Operators of BACS, operators of building services systems, and demand organisations SHOULD be adequately considered in the corresponding role and access concept with regard to BACS. This SHOULD be carefully planned and coordinated, especially if the BACS are provided across multiple organisations. 
All BACS-relevant components, including field-level components and control elements, SHOULD be able to implement suitable functions to secure access. Components that do not provide access protection or offer access parameters from the manufacturer that cannot be modified SHOULD NOT be used.
INF.14.A15 Security of BACS-Specific Networks (S)
If communication security mechanisms are available in BACS-specific networks such as BACnet, they SHOULD be used. At minimum, mechanisms for authentication and encryption SHOULD be used. 
For BACS-specific networks that cannot implement adequate security mechanisms, consideration SHOULD be given to switching them to a BACS-specific network with adequate security mechanisms. 
In principle, communication with BACS-specific networks SHOULD be controlled and, if necessary, regulated by coupling elements with security functions.
INF.14.A16 Securing Wireless Communication in BACS Networks (S) [Planner]
In BACS networks based on wireless communication such as EnOcean, the security mechanisms of the respective radio technology SHOULD be used to secure communications. In particular, appropriate authentication and encryption SHOULD be implemented on the air interface. If this is not possible with the mobile devices in use, communications involving these devices SHOULD be controlled at the transition to wired networks (e.g. by a component with a firewall function). 
Furthermore, possible interference in the propagation of radio waves (e.g. due to shadowing) SHOULD be taken into account when planning BACS networks.
INF.14.A17 Securing Mobile Communications in BACS Networks (S) [Planner]
If mobile communications are used in the context of BACS, the security mechanisms of the respective mobile networks SHOULD be used for such BACS networks. 
If public mobile networks such as 5G or Sigfox are used in BACS, uncontrolled direct IP-based communication with BACS-relevant components SHOULD be prevented. 
BACS components SHOULD only be equipped with a dedicated connection to a public mobile network if this is essential for their operation. For this purpose, the BACS components for which a connection to public mobile networks is necessary SHOULD be checked and determined. 
If it is not possible to separate BACS networks in the public mobile network (e.g. using slicing in the case of 5G), IP communication SHOULD be decoupled in the communication channel at hand by means of an application layer gateway (ALG). 
If mobile technologies are used in BACS as part of the public mobile infrastructure of a mobile operator, one or more virtual mobile networks SHOULD be implemented and made exclusively available to the BACS using each respective mobile technology. 
If autonomous private mobile networks are set up locally on a given campus in BACS using mobile technologies such as LTE and 5G, the transition between these mobile networks and other networks SHOULD be secured by a coupling element with a firewall function. 
Segmentation into several virtual mobile networks SHOULD be implemented for private mobile networks, as well.
INF.14.A18 Secure Integration of BACS-External Systems (S)
The communication of BACS with BACS-external systems SHOULD be only be possible via defined interfaces and IT systems. This communication SHOULD be authenticated and encrypted. 
The possible interfaces to BACS-external systems SHOULD be limited to those required.
INF.14.A19 Use of Dedicated Address Ranges for BACS Networks (S) [Planner]
For BACS, dedicated address ranges SHOULD be used that differ in particular from the address ranges of office IT and OT. For these address ranges, the ranges from which static addresses are 
to be assigned and the BACS-relevant components that are to receive static addresses SHOULD be defined. 
If the network areas connected to BACS (e.g. building services systems) use identical address areas (replicating system configurations), they MUST be located in separate segments to prevent address conflicts. In this case, cross-segment communication MUST be secured by appropriate mechanisms—for example, using an ALG or network address translation (NAT).
INF.14.A2 Defining Commissioning and Interface Management for BACS (B)
Due to the large number of building services systems and building components that are connected in BACS, the commissioning procedure for the building services systems and BACSrelevant components involved MUST be coordinated and defined across the multiple areas at hand. This process MUST be implemented in a coordinated manner to ensure a fully functional building. 
Clear interfaces MUST also be defined between the operator organisations of the BACS and the BACS-relevant components, as well as between the operator organisations of the building services systems. 
Commissioning and interface management MUST be documented. The specifications MUST 
be checked and readjusted both regularly and whenever required. In particular, the specifications must be adapted in case of changes within the BACS.
INF.14.A20 Avoiding Broadcast Communication in BACS Networks (S) [Planner]
In BACS networks, the broadcast load on OSI Layer 2 or OSI Layer 3 for uninvolved systems and components SHOULD be minimised to avoid overloads. For this purpose, communication SHOULD be switched to group-specific multicasts or considered accordingly in segmentation planning.
INF.14.A21 Displaying Validity of Information in BACS (S)
BACS SHOULD make it clear whether the information they display in terms of time, place, value, state, or event is based on information that was received as planned. Information showing simulated or “frozen” values SHOULD be recognisable or trigger an alarm depending on the protection needs of the BACS at hand.
INF.14.A22 Ensuring Autonomous Functioning of BACS and Building Services Systems (S) [Planner]
Within BACS, it SHOULD be ensured that building services systems also function autonomously according to their protection needs, independent of their connection to BACS. In particular, BACS SHOULD be configured in such a way that there are no dependencies on TBM, other BACS, or building services systems that would prevent their operation. A building services system SHOULD remain operational and perform its functions for a certain period of time according to the respective protection needs, even if its connection to BACS fails.
INF.14.A23 Use of Physically Robust Components for BACS (S) [Planner]
Depending on the circumstances in which BACS components are to operate, corresponding physically robust components SHOULD be used that are especially intended or designated for harsh environmental conditions. If appropriately robust components are not available, suitable compensatory measures SHOULD be taken.
INF.14.A24 Time Synchronisation for BACS (S)
All components and building services systems connected in BACS SHOULD use a synchronous time to ensure automated measurement, control, and regulation (see also OPS.1.2.6 NTP Time Synchronisation). BACS that are interconnected SHOULD also use a synchronous time. If BACS span multiple building complexes or properties, time synchronisation SHOULD be ensured for all these buildings. 
If real-time communication is required within a BACS, PTP or a comparable mechanism SHOULD be used for time synchronisation instead of NTP.
INF.14.A25 Dedicated Monitoring in BACS (S)
A suitable monitoring concept SHOULD be established and implemented for all components that are relevant to BACS operations. The availability and significant parameters of BACSrelevant components SHOULD be continuously monitored. Error conditions and defined thresholds that are exceeded SHOULD be reported to the operator organisation automatically. 
At minimum, alarms SHOULD be triggered by BACS if building services systems fail or important functions for automated control and regulation are not available. In addition, particularly safety-relevant events and other events for which automatic alarm messages should be generated SHOULD be defined. 
Status messages and monitoring data SHOULD ONLY be transmitted using secure communication channels.
INF.14.A26 Logging in BACS (S)
As a supplement to OPS.1.1.5 Logging, status changes in BACS-relevant components and security-relevant events SHOULD be logged. In addition, all instances of write access to configurations of building services systems (and, if applicable, BACS-relevant components) SHOULD be logged, along with all manual and automated changes to the states of these systems and components. 
The logging data to be merged on a central logging instance SHOULD be determined. 
Logging data SHOULD ONLY be transmitted using secure communication channels.
INF.14.A27 Consideration of Interactions Between BACS Components in Contingency Planning (S)
The impact that BACS and the planning and concepts derived from them have on contingency planning SHOULD be analysed initially and at regular intervals in a transparent way. In particular, it SHOULD be determined how interactions with other building services, BACSrelevant systems, and TBM can be minimised in the event of a failure of building services systems or BACS-relevant components due to a technical defect or attack. Within the scope of contingency planning, it SHOULD also be determined which maintenance personnel are responsible for the affected building services systems and BACS-relevant systems and which reporting channels can be used to reach them. In addition, the authorisations the maintenance personnel have to remedy emergencies SHOULD be determined. 
Contingency planning SHOULD also specify how any necessary emergency operation of building services systems will be ensured in the event of a BACS failure. A restart sequence SHOULD be defined for all building services systems and BACS (including all BACS-relevant components) and documented in the corresponding plans for restoration of service.
INF.14.A28 Physical Separation of BACS (H) [Planner]
In case of increased protection requirements, BACS networks SHOULD be realised as physically separated zones according to module NET.1.1 Network Architecture and Design. 
Depending on the protection requirements at hand, dedicated, restrictively regulated Internet access SHOULD be provided for connections to manufacturer clouds, for example. 
Depending on the protection needs of BACS, connections to untrusted networks and to the respective organisation's own office or OT networks SHOULD be prevented where applicable.
INF.14.A29 Separation of Individual Building Services Systems (H)
In order to secure individual building services systems with increased protection requirements within BACS, such building services systems SHOULD be located in separate network segments. To control communication, firewall functions SHOULD be positioned directly before the system network.
INF.14.A30 Provision of a Dedicated BACS Time Server for Time Synchronisation (H)
For BACS with increased protection needs (including at the individual system level), a dedicated BACS time server SHOULD be provided that is directly coupled to an atomic or radio clock (stratum 0) and supports the connection of further downstream BACS time servers.
INF.14.A4 Consideration of Hazard Detection Systems in BACS (B) [Planner]
Hazard detection systems (including security systems) MUST be coupled to BACS in a nonreactive manner. They MUST NOT be integrated into BACS. 
Physically separate network components and physically separate segments MUST be used for the corresponding network connections. If radio networks are used for coupling, the respective building services systems MUST be designated as primary users for the frequency ranges used. Certified mechanisms SHOULD be used for communication via radio networks.
INF.14.A5 Documentation of BACS (B)
The many different components and points of access pertaining to BACS MUST be documented. This documentation MUST be checked and adapted both regularly and in case of changes within the BACS in question. 
In particular, all deactivated physical communication interfaces, protocols, and points of access to the BACS MUST be documented. Furthermore, all interactions and dependencies of BACS-relevant components, as well as of building services systems integrated into or coupled with BACS, MUST be documented. The available and utilised security features of the protocols in use SHOULD be documented. 
The documentation SHOULD be coordinated for all BACS with regard to their content and data structures.
INF.14.A6 Separation of BACS Networks (B) [Planner, IT Operation Department]
BACS networks MUST be at least logically separated from office networks and other networks of the organisation at hand. Any communication between BACS and other IT systems MUST be controlled and regulated. For this purpose, appropriate components with security functions 
(a firewall function at minimum) MUST be provided at all the transitions in such segmentation. 
If BACS are set up centrally for a building complex or property, the BACS communication across buildings via LAN, WLAN, WAN, radio networks, or Internet connections MUST also be separated at the network level. 
3.2. Standard Requirements 
Along with the Basic Requirements above, the following requirements correspond to the stateof-the-art technology for this module. They SHOULD be met as a matter of principle.
INF.14.A7 Drawing Up a Security Policy for BACS (S)
Based on the general security information security policy of the organisation in question and its overarching security policy for TBM, the security requirements for all BACS SHOULD be specified in a corresponding security policy. This policy SHOULD be known to all persons involved in planning, procuring, implementing, and operating BACS and be integral to their work. The contents and implementation of the required policy SHOULD be reviewed regularly and adjusted if necessary, and the results of these reviews SHOULD be documented in a comprehensible manner. 
The security policy SHOULD also specify the development and testing requirements for the use of BACS.
INF.14.A8 Requirements Specification for BACS (S)
Based on an organisation's BACS security policy, an overall requirements specification SHOULD be established for the BACS at hand, along with a separate requirements specification for each individual system. From these requirements, it SHOULD be possible to derive all the elements essential for the architecture and design of each BACS and the intercoupling thereof. 
The overall requirements specification SHOULD be documented and adapted to the state of the art both on a regular basis and as needed. Furthermore, the implementation of the requirements SHOULD be checked regularly. 
Only components that provide authentication (via a changeable user name and password at minimum) SHOULD be used in BACS.
INF.14.A9 Developing a BACS Concept (S)
Based on an organisation's BACS security policy and requirements specifications, an overall concept SHOULD be developed for the BACS at hand. Detailed concepts SHOULD be derived from this overall concept and developed for all BACS. At minimum, the following points SHOULD be adequately considered in these concepts: 
•	All building services systems integrated into the respective BACS 
•	All building services systems coupled with the respective BACS 
•	All BACS-relevant components and their respective communication links 
The concepts SHOULD describe all the relevant technical and organisational requirements. The concepts SHOULD be checked regularly and updated if necessary.
INF.2 Data Centre and Server Room
Target Object: Building/room / Order: R2
INF.2.A1 Defining Requirements [Building Services, Planner] (B)
Adequate technical and organisational requirements MUST be defined and implemented for a data centre. When planning a data centre or choosing suitable rooms, appropriate security safeguards MUST also be planned that take the protection needs of the IT components (especially regarding their availability) into account. A data centre as a whole MUST be designed as a closed security area. In addition, it MUST have different security zones. For example, administration, logistics, and IT operations and support areas MUST be clearly separated from each other. In the case of a server room, it SHOULD be checked whether it is possible to implement different security zones.
INF.2.A10 Inspection and Maintenance of Infrastructure [Maintenance Personnel, Building Services] (B)
For all components of building services infrastructure, the intervals and requirements for inspection and maintenance recommended by the manufacturer or specified by corresponding standards MUST be observed at minimum. Inspections and maintenance work MUST be documented. Firestop seals MUST be checked to ensure that they are intact. The results MUST be documented.
INF.2.A11 Automatic Monitoring of Infrastructure [Building Services] (B)
All infrastructure facilities, such as leakage monitoring, air conditioning, and power and UPS systems, MUST be automatically monitored. Detected disruptions MUST be forwarded and dealt with in an appropriate manner as quickly as possible. In the case of a server room, IT and support devices that do not or only occasionally need to be operated by a person SHOULD be equipped with a remote indication of malfunctions. The responsible employees MUST be alarmed promptly
INF.2.A12 Data Centre Perimeter Protection [Planner, Building Services] (S)
Perimeter protection SHOULD be in place for data centres. Depending on the protection needs defined for a given data centre and its premises, perimeter protection SHOULD consist of the following components: • A wall or fence around the property • Security safeguards against accidental trespassing (crossing the property line) • Security safeguards against deliberate trespassing without the use of force • Security safeguards against deliberate trespassing through the use of force • Outdoor security safeguards • Visual detection of people and vehicles • Safeguards for preserving evidence (e.g. video recording) • Automatic alerts
INF.2.A13 Planning and Installation of Alarm Systems [Building Services] (S)
The corresponding building's security concept SHOULD be used to plan which alarm systems are needed and should be installed for specific areas of a data centre. In addition, a procedure for dealing with alarm messages SHOULD be defined. The security concept SHOULD always be adapted if and when the use of the building's areas changes. An alarm system that is fit for purpose SHOULD be installed. The notifications from the alarm system SHOULD be transmitted to an alarm receiving centre in compliance with the applicable technical connection requirements. The selected alarm receiving centre MUST be reachable at all times. It MUST able to react appropriately to the alarms in terms of its technology and personnel. The transmission path between the alarm system and the alarm receiving centre SHOULD be designed according to the technical connection requirements at hand and, if possible, with redundancy. All established transmission routes MUST be tested at regular intervals.