INF.13 Technical Building Management

Description

Introduction

Building management (BM), also known as facility management, is responsible for all services arising during the planning and operational phases of buildings, building complexes, properties, or property portfolios. In the following, the term “building” is used uniformly for all of these. Exceptions are explicitly noted.

BM is site-specific and object-specific in its orientation. It can be subdivided into technical, infrastructural, and commercial BM.

Technical building management (TBM) encompasses, in accordance with DIN 32736, all services that maintain the technical function and availability of a building. These services include, among others:

• Operation
• Documentation
• Energy and environmental management
• Information management
• Modernization
• Renovation
• Conversion
• Monitoring of technical warranty obligations

Essential technical functions of a building are provided by the building services engineering (BSE), which is operated, maintained, and further developed by TBM. BSE encompasses, in accordance with VDI 4700 Sheet 1, all technical and usage-specific installations built into and connected to the structure, as well as technical installations in outdoor facilities and furnishings (see also Section 4.1 TBM-specific technical terms used). If the BSE is to be operated in an automated and cross-trade manner, additional technical infrastructure for building automation (BA, English: Building Automation and Control Systems, BACS) is employed. BA is therefore a central tool of TBM. A building can be operated by TBM without BA, but BA is always accompanied by TBM. Certain BA components also belong to BSE, such as real-time-capable industrial Ethernet switches.

While BSE in the past was mostly operated independently of IT and process control and automation technology (Operational Technology, OT), network transitions to these areas are increasingly being established today. In addition, parts of BSE are used around the clock. Therefore, changes must often be made in parallel with productive use.

The fundamental values of information security must also be taken into account in TBM, because loss of availability, confidentiality, and integrity of systems in TBM can have far-reaching consequences, including threats to life and limb.

Objective

The objective of this building block is to establish information security as an integral component in planning, implementation, and operation within the framework of TBM.

Scope and Modeling

The building block INF.13 Technical Building Management is to be applied to the TBM of an institution as soon as buildings with BSE are planned, constructed, or operated.

This building block addresses TBM, thus the tasks and processes required for planning and operating the BSE systems (see Section 4.1 TBM-specific technical terms used) of a building. The technical infrastructure for the automated operation of buildings is addressed in the building block INF.14 Building Automation. The latter must be applied in addition to the building block INF.13 Technical Building Management when the BSE to be operated is automated and controlled across systems. In this sense, TBM also encompasses the processes of BA.

Furthermore, it is possible that the systems to be managed also include those modeled by building blocks from the IND Industrial IT and SYS IT Systems layers — for example IND.2.1 General ICS Component or SYS.4.4 General IoT Device. In addition, aspects of the ORP and OPS layers relevant to TBM must be observed, in particular sub-layers OPS.1 Own Operations and OPS.2 Third-Party Operations, as well as the building blocks ORP.2 Personnel and ORP.4 Identity and Access Management. If cloud services are used for TBM, the building block OPS.2.2 Cloud Use must be taken into account for selecting these services.

For securing remote access in TBM, the building blocks OPS.1.2.5 Remote Maintenance and IND.3.2 Remote Maintenance in Industrial Environments are to be applied.

The building block INF.13 Technical Building Management does not address the physical security of buildings; this is addressed in the building block INF.1 General Building. Likewise, the aspect of safety does not play a prominent role in this building block, but is addressed in the building block IND.2.7 Safety Instrumented Systems.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block INF.13 Technical Building Management.

Missing Foundations for TBM Planning

If the demand organizations (see Section 4.1 TBM-specific technical terms used) are not yet established when a building is being constructed, contact persons, objectives, and requirements for TBM are lacking. This can lead to TBM during operations not meeting actual needs, because these could not be ascertained at the time of planning and implementation.

Insufficient Documentation in TBM

A large number of service providers is frequently involved in TBM. If documentation of responsibilities with contact persons and associated SLAs is incomplete or inaccessible, this leads to avoidable delays in critical cases when important systems fail — delays that can potentially even result in personal injury.

Missing documentation of security certifications for BSE systems, including dates for required renewals, can mean that expired certifications are not renewed in time. This can result in violations of laws, and depending on the BSE system can create a threat to life and limb, and damage may not be able to be processed through corresponding insurance policies.

Compromise of Interfaces with TBM

TBM has technical interfaces to particularly sensitive areas — for example, Safety Instrumented Systems (SIS), security services, and fire alarm systems. If these interfaces are compromised deliberately or inadvertently through errors in TBM, this can result in violations of laws and threats to life and limb.

If, for example, an optical or acoustic warning is disabled during a fire alarm in a data center, persons present in the room may not be able to leave it in time before the room is flooded with extinguishing gas. Similarly, a simulated fire alarm could cause escape doors to open, thereby granting unauthorized access to the building, or doors to close and potentially trapping persons.

Insufficient Monitoring of BSE

If BSE is monitored only inadequately through corresponding monitoring, security-relevant events — such as relevant malfunctions in BSE — may not be detected, or only detected too late. Depending on the event, this can lead to further damage or threaten life and limb.

If, for example, a heating failure at outdoor temperatures below zero is not reported, the rooms will cool down significantly before the failure is noticed and remediation can be initiated.

Insufficient Role and Access Rights Management

If TBM or individual parts thereof are physically separated from the rest of the institution’s IT, a dedicated identity and access management system is generally also set up. If this is inadequately conceived and implemented, it cannot be ruled out that multiple persons share the same account, or that access rights of departed internal or external employees or service providers have not been deleted. As a result, unauthorized access to TBM may occur.

Requirements

The following are the specific requirements of the building block INF.13 Technical Building Management. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled where meaningful and appropriate.

Exactly one role should be Primarily responsible. There may also be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a specific requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural does not imply anything about the number of persons filling these roles.

Basic Requirements

The following requirements MUST be met as a priority for this building block.

INF.13.A1 Assessment of the Current State When Taking Over Existing Buildings (B)

When taking over existing buildings, the BSE systems installed in the building, the building fabric and furnishings, and existing documentation MUST be recorded and assessed with regard to their condition (age, support status, future viability, completeness of documentation, etc.).

INF.13.A2 Regulation and Documentation of Responsibilities and Accountabilities in the Building (B) [Top Management, Planners]

Since there are usually different responsibilities and accountabilities for various areas within a building, the corresponding rights, obligations, tasks, competencies, and associated processes MUST be regulated and documented.

The organizational structures within the building MUST also be taken into account and documented. In particular, all demand and operating organizations MUST be recorded. If TBM is operated by an external organization, the associated rights, obligations, tasks, and competencies MUST be contractually stipulated in accordance with the building block OPS.2.3 Use of Outsourcing.

Furthermore, the interfaces and reporting channels including escalation between all parties MUST be defined and documented. The coordination of various operating organizations MUST also be regulated and documented.

Access to the documentation MUST be regulated. The entire documentation, including associated contact information, MUST always be current and available.

INF.13.A3 Documentation of Building Installations (B)

All building installations of BSE including BA MUST be documented. All documentation already available, including that already on hand, MUST be consolidated, organized from the TBM perspective, and supplemented with TBM-specific information.

Access to the documentation MUST be regulated. The entire documentation, including associated contact information, MUST always be current and available.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be met.

INF.13.A4 Creation of a Security Policy for TBM (S)

Based on the institution’s general security guideline, a top-level security policy for TBM SHOULD be created and implemented in a traceable manner. Specific security policies for the various subject areas of TBM SHOULD be derived from this top-level security policy. The security policy for TBM SHOULD contain traceable descriptions of requirements and specifications for how TBM is implemented. The security policy SHOULD be regularly and additionally as needed reviewed and updated if necessary to reflect the current state of the art and cover the latest findings. It SHOULD be known to all employees responsible in the TBM area and be fundamental to their work.

INF.13.A5 Planning of TBM (S) [Planners]

TBM, the underlying infrastructure, and the associated processes SHOULD be appropriately planned. The planning SHOULD include at minimum a detailed requirements analysis, adequate high-level conceptual design, and detailed implementation planning.

As part of the requirements analysis, requirements for TBM infrastructure and TBM processes SHOULD be specified. All essential elements for TBM SHOULD be taken into account. The security policy for TBM SHOULD also be observed. If the demand organization is not yet known at the time of planning, at minimum basic requirements that meet the state of the art SHOULD be captured within the framework of universal planning.

For the requirements specification, the interfaces of the systems to be managed SHOULD also be documented — for example, to ensure compatibility between the TBM solution and the systems to be managed.

Furthermore, the TBM requirements SHOULD be specified in a TBM requirements specification before service providers are commissioned or hardware or software for the systems to be managed by TBM is procured. This requirements specification SHOULD also take into account the conduct of tests (see also INF.13.A22 Conduct of 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 here.

High-level conceptual design SHOULD be carried out in accordance with INF.13.A6 Creation of a TBM Concept.

In the detailed implementation planning for TBM, all points addressed in the security policy and TBM concept SHOULD be taken into account.

INF.13.A6 Creation of a TBM Concept (S) [Planners]

Based on the security policy for TBM, a TBM concept SHOULD be developed and maintained. At minimum the following aspects SHOULD be appropriately addressed as needed:

• Methods, techniques, and tools for TBM
• Securing access and communications
• Securing at the network level, in particular assignment of TBM components to network segments
• Scope of monitoring and alerting
• Logging of events and administrative accesses
• Notification chains for disruptions and security incidents
• Processes required for TBM
• Provision of TBM information to other operational areas
• Integration of TBM in emergency planning

The TBM concept SHOULD be regularly and additionally as needed reviewed and updated if necessary to reflect the current state of the art and cover new findings.

Furthermore, a target-actual comparison between the specifications of the concept and the current state SHOULD be regularly carried out. In particular, it SHOULD be checked whether the systems are configured in accordance with the specifications. The results SHOULD be documented in a traceable manner. Deviations SHOULD be remedied.

INF.13.A7 Creation of a Radio Frequency Register (S)

In order to use radio frequencies as free from interference as possible, a radio frequency register SHOULD be created that lists the systems and users of the frequency spectrum at the institution’s sites. When different systems and users potentially use frequencies, it SHOULD be specified who is the primary user for which frequencies. Coordination between IT and TBM SHOULD also take place. If OT is deployed in the buildings, coordination SHOULD also take place there.

The radio frequency register SHOULD be regularly and additionally as needed reviewed and updated if necessary.

INF.13.A8 Creation and Maintenance of an Inventory for TBM (S) [Planners]

An inventory SHOULD be created and maintained for documenting systems managed by TBM. The inventory SHOULD be kept complete and up to date. For all systems, responsibilities and accountabilities SHOULD be apparent from the inventory.

The elements of the TBM infrastructure itself SHOULD also be documented.

INF.13.A9 Regulation of the Use of Computer-Aided Facility Management (S) [Planners]

If a Computer-Aided Facility Management system (CAFM system) is used, this use SHOULD be comprehensively planned and conceptualized. If processes are mapped and supported in CAFM, corresponding roles and permissions SHOULD be defined, particularly when external service providers are involved in the processes.

INF.13.A10 Regulation of the Use of Building Information Modeling (S) [Planners]

Where possible, Building Information Modeling (BIM) SHOULD be used for the digital modeling of all relevant building data. When using BIM, the BIM project execution plan SHOULD be specified.

Furthermore, the BIM architecture SHOULD be comprehensively planned and conceptualized. Information security SHOULD also be appropriately ensured for BIM tools.

INF.13.A11 Appropriate Hardening of Systems in TBM (S)

All systems in TBM and the systems operated by TBM SHOULD be appropriately hardened. Hardening measures SHOULD be documented, regularly and additionally as needed reviewed, 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 appropriately hardened and in particular that security-relevant updates are provided for the planned service life.

Systems for which no security-relevant updates are available SHOULD no longer be used after vulnerabilities become known. If this is not possible, the affected systems SHOULD be separated using network segmentation and communications SHOULD be controlled and regulated.

INF.13.A12 Secure Configuration of TBM Systems (S)

All systems in TBM and the systems operated by TBM SHOULD be securely configured.

Configuration SHOULD at minimum be tested before commissioning a system. Configuration changes during productive operations SHOULD be tested on a test instance before activation or carried out using the four-eyes principle only.

The configuration of systems SHOULD be backed up to enable rapid restoration of a fault-free version (rollback). Rollback tests SHOULD be established on a test system or conducted during maintenance windows. Configurations SHOULD be stored centrally.

For similar systems, including devices at the automation and field level (see Section 4.1 TBM-specific technical terms used), automated distribution of software updates and configurations SHOULD be established.

Configuration changes SHOULD be communicated to all parties involved in operational and service processes (fault resolution, on-call duty, maintenance, etc.), in particular:

• changes to access mechanisms or passwords, and
• changes to communication and control parameters for the connected systems.

It SHOULD be ensured that in the event of a disruption, for example a maintenance technician can operate or parameterize the system.

Furthermore, it SHOULD be regularly and additionally as needed checked whether the systems are configured in accordance with the specifications. The results SHOULD be documented in a traceable manner. Deviations from the specifications SHOULD be remedied.

INF.13.A13 Secure Connection of Systems with Limited Trustworthiness in TBM (S) [Planners]

Systems with limited trustworthiness that must be included in TBM for important operational reasons SHOULD be connected via a system that controls and regulates communications using firewall functions. This system SHOULD be under the responsibility of TBM.

INF.13.A14 Consideration of Special Roles and Permissions in TBM (S)

The roles and permissions concept for TBM SHOULD take into account both demand and operating organizations of TBM systems and BSE systems. This SHOULD be particularly carefully planned when TBM is provided across institutional boundaries.

INF.13.A15 Protection Against Malware in TBM (S)

If anti-virus programs in accordance with the building block OPS.1.1.4 Protection Against Malicious Programs cannot be run on a system — for example due to limited resources or real-time requirements — appropriate alternative protection methods SHOULD be employed.

Every external system and every external storage medium SHOULD be checked for malware before being connected to a TBM system and before data transfer.

INF.13.A16 Process for Changes in TBM (S)

Changes SHOULD always be announced and coordinated with all involved trades (see Section 4.1 TBM-specific technical terms used), demand and operating organizations. Furthermore, rules SHOULD be established for the event that a rollback of changes with erroneous results is not possible or only possible with great effort. Therefore, change management should include tests prior to executing the change that also cover the ability to roll back. For the various types of changes, the respective test depth SHOULD be specified. For the introduction of new systems and for major changes to existing systems, a correspondingly high test depth SHOULD be planned (see INF.13.A22 Conduct of System Tests in TBM).

INF.13.A17 Regulation of Maintenance and Repair Work in TBM (S)

Building installations SHOULD be regularly maintained. A maintenance plan SHOULD be created for this purpose. It SHOULD be regulated which security aspects must be observed during maintenance and repair work. The dependencies between the various trades SHOULD also be taken into account. Furthermore, it SHOULD be specified who is responsible for the maintenance or repair of installations. Maintenance work carried out SHOULD be documented.

It SHOULD be ensured at all times that maintenance and repair work carried out by third parties is monitored, carried out only in a coordinated manner, and accepted. For this purpose, internal employees of Facility Management SHOULD be designated to authorize, observe, support if necessary, and accept such maintenance and repair work.

INF.13.A18 Proactive Maintenance in TBM (S) [Planners]

For systems managed by TBM, appropriate proactive maintenance SHOULD be carried out. For this purpose, the regular maintenance intervals per system SHOULD be specified. Additionally, it SHOULD be weighed for each system whether predictive maintenance can be used in addition to regular maintenance and to what extent this can extend regular maintenance intervals.

INF.13.A19 Conceptualization and Conduct of Monitoring in TBM (S) [Planners]

A concept for monitoring in TBM SHOULD be developed and implemented. It SHOULD specify how systems to be managed by TBM can be included in monitoring that is as uniform as possible and which values should be monitored. For this purpose, required interfaces for monitoring important states of systems managed by TBM SHOULD already be specified during the requirements analysis. The systems used for TBM SHOULD also be included in monitoring.

The concept SHOULD be regularly and additionally as needed reviewed and updated if necessary to reflect the current state of the art and cover the latest findings.

Status messages and monitoring data SHOULD ONLY be transmitted via secure communication channels.

INF.13.A20 Regulation of Event Management in TBM (S) [Planners]

Events occurring in TBM SHOULD be categorized, filtered, and classified (event management) with regard to their significance and impact. Threshold values SHOULD be defined for events to enable automated classification of events. Depending on the classification of events, appropriate measures for monitoring, alerting, and notification channels (escalation) as well as logging measures SHOULD be specified.

INF.13.A21 Logging in TBM (S)

Events classified correspondingly in event management SHOULD be logged. Additionally, security-relevant events SHOULD be logged for the systems.

All configuration accesses as well as all manual and automated control accesses SHOULD be logged. Depending on the protection needs, comprehensive logging including metadata and content of changes SHOULD be carried out.

Logging SHOULD be consolidated on a central logging instance.

Logging data SHOULD ONLY be transmitted via secure communication channels.

Automatic alerts SHOULD be triggered for security-critical events.

INF.13.A22 Conduct of System Tests in TBM (S) [Planners]

Systems of TBM and systems managed by TBM SHOULD be tested before commissioning and for major system changes with regard to their functional and non-functional requirements. The target and actual behavior of functions and settings SHOULD also be checked. For non-functional requirements, information security requirements SHOULD also be tested and, additionally as needed, load tests SHOULD also be carried out. A test specification SHOULD be created for the tests containing a description of the test environment, the test depth, and the test cases including criteria for successful test execution. Test execution SHOULD be documented in a test report.

Test specifications SHOULD be regularly and additionally as needed reviewed and updated if necessary to reflect the current state of the art and cover the latest findings.

INF.13.A23 Integration of TBM in Vulnerability Management (S)

Systems of TBM and systems managed by TBM SHOULD be continuously monitored for possible vulnerabilities.

Information about newly discovered vulnerabilities SHOULD be regularly obtained and taken into account accordingly. The configuration of systems SHOULD also be reviewed to determine whether it promotes known vulnerabilities.

Furthermore, a decision SHOULD be made as to which systems are subjected to vulnerability scans regularly or at least during commissioning and major system changes. For vulnerability scans, the scan depth SHOULD be specified. It SHOULD also be specified whether a passive or active scan is conducted. In productive environments, passive scans SHOULD be preferred. Active scans SHOULD only be conducted in productive environments when necessary and with personnel available who can remedy any faults or failures that may occur due to the scan.

INF.13.A24 Ensuring Control Over Processes When Using Cloud Services for TBM (S) [Planners]

If cloud-based services are used in TBM, control over all TBM processes SHOULD remain within TBM. This SHOULD be contractually stipulated with the providing company when using a cloud service.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection representing the state of the art. The proposals SHOULD be considered when protection needs are elevated. The specific determination is made within an individual risk analysis.

INF.13.A25 Establishment of a Test Environment for TBM (H) [Planners]

For elevated protection needs, a test environment SHOULD be established for systems of TBM and for systems managed by TBM, so that hardware and software can be tested before commissioning and during changes, and errors in productive operation can be reduced. Furthermore, rules SHOULD be specified for handling systems for which no test environment can be set up.

INF.13.A26 Securing BIM (H) [Planners]

If security-critical information is also recorded in BIM, appropriate security and hardening measures SHOULD be planned both at the level of the BIM architecture and for the implementation and operation of the BIM solution. Securing SHOULD include a stricter roles and permissions concept as well as additional protective measures such as encryption, segmentation, and higher-grade authentication mechanisms, in particular two-factor authentication.

INF.13.A27 Establishment of a Private Cloud for TBM (H) [Planners]

For elevated protection needs, cloud services for TBM SHOULD be positioned in a private cloud on-premises or a private cloud with a trustworthy 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 with elevated protection needs, ONLY AI that has demonstrably been proven secure SHOULD be used. At minimum, care SHOULD be taken that no data is routed into networks that do not belong to the institution or are not trustworthy.

For cloud-based AI services, the criteria of the AI Cloud Service Compliance Criteria Catalogue (AIC4) of the BSI SHOULD also be taken into account in addition to the requirements of the building block OPS.2.2 Cloud Use.

INF.13.A29 Integration of TBM in a SIEM (H) [IT Operations]

If a Security Information and Event Management (SIEM) system is used, TBM systems and, where possible, systems managed by TBM SHOULD be incorporated accordingly, in order to detect and analyze security-relevant incidents across systems and applications.

INF.13.A30 Conduct of Penetration Tests in TBM (H)

To adequately secure systems of TBM and systems managed by TBM, demand-oriented penetration tests SHOULD be carried out. At minimum, penetration tests SHOULD be conducted in a test environment before commissioning and for major system changes.

If AI functions are used in TBM, these SHOULD be included in the penetration tests.

Additional Information

TBM-specific Technical Terms Used

Automation Level

The automation level is located in the automation pyramid between the field level and the management level. It brings together data supplied by the field level and specifications transmitted by the management level. BSE systems are controlled and regulated here, but also monitoring of limit values, switching states, or meter readings.

Building Information Modeling (BIM)

According to VDI 2552 Sheet 2, BIM is a methodology for planning, executing, and operating structures using a collaborative approach based on a digital information model of the structure for shared use.

Computer-Aided Facility Management (CAFM)

According to VDI 3814 Sheet 2.1, CAFM serves as a tool for recording, processing, preparing, and archiving data and information with the goal of supporting the service processes and tasks in the operational phase of a building.

Field Level

The field level represents the lowest level of the automation pyramid and encompasses various components of BA or OT. As a rule, sensors and actuators are operated here. Sensors collect information (e.g., motion, brightness, temperature) and transmit it to the automation level. Actuators receive control information and convert it into switching signals, e.g., for lighting, heating, climate, and ventilation systems.

Building

The term “building” is used synonymously in the building block INF.13 Technical Building Management and in the associated implementation notes for building, building complex, property, and property portfolio. Furthermore, the term “building” describes not only houses and halls, but also, for example, a television tower or an oil platform.

Building Automation (English: Building Automation and Control Systems, BACS)

Building automation (BA) encompasses, in accordance with VDI 3814-1, all products and services for the goal-oriented operation of Building Services Engineering (BSE).

Building Complex

A building complex is a group of buildings that are structurally connected and perceived as a single unit.

Trade

In construction, a trade generally encompasses the work to be assigned to a self-contained area of construction services. It is a functional area that can in particular encompass various BSE systems.

Example: HVAC systems (cost group 430 in DIN 276), which include, for example, ventilation systems, air conditioning systems, and refrigeration systems.

Control Center (English: Control Center)

A control center (also operating and monitoring units) is a technical tool for visualizing current processes, states, and situations of processes, including TBM and especially BA processes.

Property

A property is a parcel of land including its development. Development includes all immovable objects, i.e., buildings and other things that cannot be readily removed from the parcel of land.

Property Portfolio

The property portfolio refers to the entirety of properties owned.

Demand Organization

A demand organization is, in accordance with DIN EN ISO 41011, an organizational unit within or outside the institution that is authorized for its requirements to make corresponding demands on BSE, BA, or TBM and to bear the costs for fulfilling the requirements.

Examples: Tenants within a building, owners of a building, service providers within an institution, e.g., cafeteria.

System

The term “system” in the building block INF.13 Technical Building Management and in the associated implementation notes addresses not only an IT system in the classical sense (compare building blocks of the SYS layer), but also encompasses all components of BSE including all components of the field level, such as sensors, actuators, etc.

Building Services Engineering (English: Building Services, BS)

Building Services Engineering (BSE) encompasses, in accordance with VDI 4700 Sheet 1, all technical and usage-specific installations built into and connected to the structure, as well as technical installations in outdoor facilities and furnishings. Certain components of building automation are also to be assigned to BSE, e.g., real-time-capable industrial Ethernet switches.

Technical Building Management (English: Technical Building Management, TBM)

Technical Building Management (TBM) contains, in accordance with DIN 32736, all services for maintaining the technical function and availability of a building. TBM thus takes over for BSE the operation, maintenance, modernization, and documentation of components and defines all necessary processes.

BSE System

A BSE system describes the totality of all technical components working together to fulfill specific functions. Examples according to DIN 276 “Construction Costs” are heat supply systems, ventilation systems, or lighting systems.

Abbreviations

Good to Know

Standards and documents referenced:

• AI Cloud Service Compliance Criteria Catalogue (AIC4), Federal Office for Information Security, February 2021, available at https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CloudComputing/AIC4/AI-Cloud-Service-Compliance-Criteria-Catalogue_AIC4.html
• BSI-CS 108 - Remote Maintenance in Industrial Environments, BSI Publication on Cyber Security, July 2018, accessible via https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/BSI-CS/BSI-CS_108.pdf
• DIN 276 - Construction Costs, Deutsches Institut für Normung e.V., December 2018, available from Beuth-Verlag
• DIN 32736 - Building Management – Concepts and Services, Deutsches Institut für Normung, August 2000, available from Beuth-Verlag
• VDI 4700 Sheet 1 - Concepts of Building and Construction Technology, Verein Deutscher Ingenieure e.V., October 2015, available from Beuth-Verlag