INF.13 Technical Building Management (TBM)

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Changes SHOULD always be announced and agreed with all the trades (see section 4.1, TBM-Specific 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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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, two-factor authentication).

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.

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.

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.

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.