INF.14 Building Automation and Control Systems (BACS)

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).

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 BACS-relevant 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.

For all building services systems, BACS, and BACS-relevant components, it MUST be specified whether actions may be triggered by other building services systems, BACS, and BACS-relevant components. If this type of integration is allowed, rules SHOULD be set regarding which automated actions may be triggered by which information from a BACS.

If a building services system is to be coupled with a BACS but cannot or must not be integrated into the BACS, the building services system information to be reported to the BACS MUST be defined.

Both the integration of building services systems into a BACS and the non-reactive coupling of building systems to BACS MUST be adequately secured. The connections between building services systems MUST also be adequately secured.

In particular, the sequence and function chains within or between BACS MUST be adequately planned for this purpose. All transitions between trades and technologies MUST be taken into account.

These process and function chains MUST be comprehensively tested and readjusted in the event of any malfunction.

The specifications MUST be fully documented. The documentation SHOULD be checked both regularly and whenever necessary to ensure that it is still up to date. In case of deviations, the cause MUST be identified and corrected.

Hazard detection systems (including security systems) MUST be coupled to BACS in a non-reactive 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.

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.

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.

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.

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.

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.

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.

The connection of components (especially unauthorised, unknown components and third-party 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.

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.

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).

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

A suitable monitoring concept SHOULD be established and implemented for all components that are relevant to BACS operations. The availability and significant parameters of BACS-relevant 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.

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.

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, BACS-relevant 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.

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.

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.

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.