Smart Building und IT-Sicherheit: Alles ist verbunden

Ergänzend dazu benötigt der zukünftige Gebäudebetrieb ein Betreiberdatenmodell, in dem die Bedarfe des technischen und betriebswirtschaftlichen Gebäudemanagements zusammengeführt werden – eine Verbindung zwischen Facility- und Real-Estate-Management ohne Informations- und Datenbruch. Die Konsolidierung sämtlicher für den Gebäudebetrieb relevanter Informationen in einer zentralen digitalen Verwaltungsschale wird im Projekt „Gebäudebetrieb 4.0“ vom Smart-Building-Reallabor der Hochschule Mainz entwickelt. Ziel ist es, einen durchgängig digitalisierten, interoperablen, sicheren und effizienten Gebäudebetrieb zu ermöglichen. 

Das Konzept Gebäudebetrieb 4.0 basiert maßgeblich auf einer Message-Queueing-Telemetry-Transport-MQTT-)Kommunikationsstruktur. In diesem Artikel werden neben der Vorstellung einer Smart-Building-Topologie und des Gebäudebetriebs 4.0 insbesondere eine IT-Sicherheitsarchitektur für die MQTT-Struktur erläutert. 

ComConsult – Smart-Building-Planung

Bereits seit vielen Jahren beschäftigt sich ComConsult mit der Planung, dem Netzwerk und der IT-Infrastruktur von Smart Buildings. Alle Anforderungen, Herausforderungen und Chancen von Smart Buildings in einem einzigen Artikel abzubilden, wäre nicht möglich. Deshalb erhalten Sie einleitend eine Themen- und Artikelübersicht mit ausgewählten Zitaten: 

• Moderne Gebäude: Eine Netzplanung für alle? Von Dr. Johannes Dams: „Das Gebäude der Zukunft braucht IT-Infrastrukturen, die über unterschiedliche Gewerke hinweg verschiedenste Endgeräte und Technologien auf IP-Basis vereinen“​ [1]​ 
• Sichere Kommunikationsprotokolle in der Gebäudeautomation – im Fokus: BACnet Secure Connect von Dr. Andreas Kaup: „Um eine Kommunikation zwischen allen Systemen der Gebäudeautomatisierung und -steuerung zu ermöglichen, bedarf es herstellerunabhängiger Kommunikationsprotokolle. Da die Netzwerke der Gebäudetechnik für moderne Gebäude keine geschlossenen Systeme mehr sind, wird die IT-Sicherheit in der Gebäudeautomation stetig wichtiger. ​[2]​ 
• Bauprojekte und die Planung des Netzes von Dr. Johannes Dams: „Bereits vor der eigentlichen IT-Planung sollte feststehen, welche Gewerke gegebenenfalls eigene Netze mitbringen (z. B. Medientechnik oder Gebäudetechnik). Anknüpfungspunkte sollten dabei festgelegt werden. Diese Entscheidung kann einen erheblichen Einfluss auf das Bauprojekt und den späteren Betrieb haben.“ ​[3]​. 
• GA-IT-Infrastruktur – Nachrüsten und Modernisierung der Gebäudeautomation gemäß GEG und EPBD von Dr. Andreas: „Kurz gesagt – eine Verpflichtung zur Datenerhebung und -analyse mit darauf basierenden Optimierungsmaßnahmen sowie die Abkehr von proprietären Kommunikationsprotokollen und Schnittstellen.“ ​[4]​ 
• BSI-IT-Grundschutz für Gebäudeinfrastrukturen – wie soll man das denn umsetzen? von Thomas Steil: „Die Trennung der Gewerke ist in der IT schon lange ein absoluter Mindeststandard, doch in den Netzen der Gebäudeautomation leider noch nicht sonderlich verbreitet.“ ​[5]​ 
• BSI-IT-Grundschutz für Gebäudeinfrastrukturen von Thomas Steil: „Eine Immobilie, die kein geeignetes Netzwerk bereitstellt, ist in der Nutzung ähnlich stark eingeschränkt wie eine Immobilie ohne Wasser oder Strom.“ ​[6]​ 
• IT-Infrastrukturen für das Gebäude der Zukunft von Thomas Steil: „Die Anforderungen an die IT-Infrastruktur eines Gebäudes sind in den letzten 30 Jahren stetig gewachsen.“ ​[7]​ 
• Smart Building? – Aber sicher! Von Dr. Andreas Kaup: „Ein elementarer Punkt, der bei Smartifizierung von Gebäuden nicht vergessen werden darf, ist die IT-Sicherheit. Je intelligenter das Gebäude wird, sprich je mehr Schnittstellenkommunikation es zwischen digitalen Bausteinen im Gebäude gibt und je mehr Kommunikation nach außen ins Internet und in die Cloud geht, desto mehr mögliche Angriffsflächen entstehen für die Cyberkriminalität.“ ​[8]​ 

Die Smart-Building-Topologie

Das Herzstück einer Smart-Building-Planung bildet die Topologie, in der Use Cases, Gewerke, Schnittstellen, Funktionen und Kommunikationsprotokolle visualisiert werden, siehe Abbildung 1. Die Topologie bestätigt zuerst einmal die Relevanz der Netzwerkinfrastruktur. Die Nutzung von IP-Kommunikation erstreckt sich über fast alle Gewerke der Kostengruppenzuordnung 400 „Bauwerk – Technische Anlagen“ gemäß DIN 276 ​[9]​. Nachfolgend werden anhand der Topologie einige Beispiele genannt und den Kostengruppen zugeordnet. Hierbei handelt es sich explizit um keine vollständige Auflistung.  

Für die Planung von Netzwerk und IT-Sicherheit liefert eine solche Topologie erheblichen Mehrwert. Grundsätzlich gibt die Topologie einen Überblick darüber, welche Gewerke in einem Netzwerkkonzept berücksichtigt werden müssen und welcher Zone diese zugeordnet werden. Eine wichtige Information sind zudem die Fernwartungs-Bedarfe. So kann nach Möglichkeit ein zentralisierter Fernwartungszugang bereitgestellt werden und über den alle Fernzugriffe geregelt werden. Dies dient der Vermeidung des Status quo in Bestandsgebäuden, wo es unzählige separate, zumeist ungesicherte Fernwartungslösungen im Gebäude gibt. 

In der Topologie sind manche IT-Sicherheitsmerkmale bereits direkt dokumentiert: 

• ein zweistufiges Firewall-Konzept mit Demilitarisierter Zone (DMZ), 
• restriktive Netzübergänge, 
• sichere Kommunikationsprotokolle in der Gebäudeautomation (BACnet Secure Connect, KNX IP Secure), 
• eine redundante Internetanbindung. 

Des Weiteren können anhand der Topologie IT-Sicherheitsbedarfe identifiziert werden, die in einer IT-Sicherheitsrichtlinie und einem IT-Sicherheitskonzept hinsichtlich Anforderung und Umsetzung behandelt werden sollten: 

• Cloud-Security 
• Applikations- und API-Security 
• Datenschutz 
• Kryptographie 
• Drahtlose Kommunikation (WLAN, BLE) 

Weitere Mehrwerte: 

• Grundlage für Freigabeprozess mit Betriebsrat 
• Datenschutzbeauftragten 
• IT-Governance  

Zwischenfazit: Wenn Netzwerkinfrastruktur sowie IT-Sicherheits- und Smart-Building-Konzepte auf hohem Qualitätsniveau geplant und umgesetzt werden, entstehen vielseitige Möglichkeiten. Die Branche befindet sich weiterhin in der Entwicklungsphase, und die in einer solchen Topologie vorhandene Vernetzung sowie die erhobenen Daten werden neue Mehrwerte schaffen, die aktuell noch nicht definiert sind. Aber es gibt bereits Ansätze, solche Smart-Building-Topologien um eine Anwendungsebene zu erweitern, indem der Gebäudebetrieb stärker einbezogen wird. Lange Zeit sind in den Smart-Building-Konzepten dieser Welt die Datenströme aller Gewerke und Use Cases in einem Data Lake, dem „Gehirn“ des Gebäudes, zusammengelaufen, ohne dass dieses Element immer mit einer klaren Definition und Funktion versehen wurde. An dieser Stelle soll zukünftig das Konzept Gebäudebetrieb 4.0 mit der Verwaltungsschale ansetzen ​[10]​. 

Gebäudebetrieb 4.0

Das Konzept Gebäudebetrieb 4.0 basiert auf der Asset Administraion Shell (AAS) der Industrial Digital Twin Association (IDTA) mit dem Ziel des lebenszyklusorientieren Datenmanagements mit standardisierter Datengrundlage. Durch die Verknüpfung der technischen Gewerke und „Real-Estate-Gewerke“ werden digitale Betriebsdaten sicher erfasst, verarbeitet und zur Prozessoptimierung bereitgestellt. So entsteht ein vollständiges Betreiberdatenmodell. 

Unter Berücksichtigung des Gebäudebetriebs erweitert sich die Liste der Smart-Building-Use-Cases um Themen wie zum Beispiel: 

• Vertragsmanagement
• Life-Cycle-Cost-Management 
• Betreiberverantwortung 
• Wartung und Instandhaltung 
• EU-Taxonomie 

Jeder technischen Einheit wird ein standardisiertes digitales Datenmodell zugeordnet, womit Transparenz und interoperable Schnittstellen ermöglicht werden. In dem Konzept werden sämtliche Betriebs- und Messdaten über das MQTT-Protokoll in das AAS-Modell geleitet. Zukünftig können so KI-basierte Funktionen unter anderem Lastspitzen reduzieren, Betriebsanomalien erkennen sowie Wartungs- und Reparaturmaßnahmen effizient steuern – inlusive der Bereitstellung aller notwendigen Daten und Pläne. Die Nutzung der AAS als Industriestandard ist sehr sinvoll, da der Unterschied zwischen Smart Building und Smart Factory (Industrie 4.0) in vielen Bereichen immer kleiner wird. Beide haben das Ziel, durch einen hohen Automatisierungsgrad die Effizienz einer Ressource zu maximieren. Die Zielgröße beziehungsweise die Ressource, auf die sich die Effizienz bezieht, können dabei variieren. Übergeordnet bleiben sie jedoch gleich. Insbesondere der Verbrauch der Ressourcen Energie, Zeit und Geld sind zu optimieren. Im Gebäudebetrieb 4.0 bedeutet dies vor allem die Senkung der Betriebskosten durch effiziente organisatorische Prozesse (Dokumentation, Ausschreibung, Vergabe, Abrechnung) und eine verbesserte Energieeffizienz. Dabei entstehen sekundär Vorteile wie erhöhter Nutzerkomfort und digitales Nutzererlebnis. 

Die Struktur der AAS ist in der IEC 63278-1 definiert ​[11]​. Zudem sind die Spezifikationen zu Softwarestruktur, Schnittstellen und  Semantik der AAS -Verwaltungsschale bei der IDTA frei abrufbar ​[12]​. 

Cybersecurity „Gebäudebetrieb 4.0“ – im Fokus: MQTT

Aus den vernetzten, automatisierten und datengetriebenen Prozessen im Sinne eines „Gebäudebetriebs 4.0“ ergeben sich neue Herausforderungen an die IT-Sicherheit. Immerhin werden hier nicht nur Daten aus verschiedenen Gewerken der Gebäudetechnik gesammelt, wofür bereits IT-Sicherheitsmaßnahmen umzusetzen sind. Es findet zudem ein API-Datenaustausch mit Third-Party Applications statt, die häufig in der Cloud betrieben werden. Zumindest sieht das Konzept die zusätzliche Einbindung der Systeme für das Enterprise Resource Planning (ERP), das Computer-Aided Facility Management (CAFM) und das Building Information Modeling (BIM) vor. Daher geht es darum, wie der MQTT-Datenfluss mit so vielen Gewerken und Schnittstellen möglichst sicher konstruiert werden kann. 

Mit dem zunehmenden Grad an Digitalisierung und Vernetzung im Gebäudebetrieb gewinnt die IT/OT-Sicherheit eine zentrale Bedeutung und muss von Beginn an und über den gesamten Lebenszyklus berücksichtigt werden. „Das Gebäude der Zukunft spielt nach den Regeln der IT.“ [Frank Schröder, Director of efficient Technologies Corporate Facility Management von Phoenix Contact]

Grundlagen von MQTT

Das Protokoll Message Queueing Telemetry Transport (MQTT) wurde ursprünglich für die Machine-to-Machine-Kommunikation in der Industrie entwickelt. Ausgangspunkt war die Satellitenkommunikation mit SCADA-Systemen​ [13]​. Seit 2013 wird MQTT von der „Organization for the Advancement of Structured Information Standards“ (OASIS) standardisiert;  2014 erschien die Version 3.1.1 ​[14]​, die in der ISO/IEC 20922:2016 normiert ist​ [15]​. Im Jahr 2019 veröffentlichte OASIS die Version 5.0 ​[16]​. Heute gilt MQTT als De-facto-Standard für leichtgewichtige Kommunikation in IoT- und OT-Umgebungen. Die Protokollarchitektur bietet jedoch keine integrierten Sicherheitsmechanismen, was bei unzureichender Implementierung zu erheblichen Sicherheitsrisiken führt. Entscheidend ist daher nicht die normative Verankerung, sondern ob und wie IT-Sicherheitsmaßnahmen tatsächlich umgesetzt werden. Zieht man den Vergleich zu BACnet/SC, stellt man fest, dass Zertifikate zwar im Standard gefordert werden, der Umgang damit aber nicht. So sind uns bereits Einstellungsoptionen wie „Ungültige Zertifikate erlauben“ und vorinstallierte Betriebszertifikate mit 25 Jahren Gültigkeit begegnet​ [2]​. Ein Beleg dafür, dass die richtige Handhabung von Sicherheitsmaßnahmen deutlich wichtiger ist als deren normative Verankerung in einem Standard, zumal diesem ein eigenes Kapitel dem Thema IT-Security gewidmet ist, das aber als non-normativ eingeordnet wird. „This Chapter is provided for guidance only and is Non Normative. However, it is strongly recommended that Server implementations that offer TLS SHOULD use TCP port 8883“​ [14]​. Ergänzend sind IT-Sicherheitsanforderungen im „MQTT and the NIST Cybersecurity Framework“ definiert und im Standard mehrfach referenziert ​[17]​. Das gilt sowohl für den OASIS-Standard als auch für die ISO/IEC-Version. MQTT darf also unsicher betrieben werden, sollte es aber selbstverständlich nicht. 

Die MQTT-Spezifikation definiert weder Verschlüsselung noch Authentifizierung als verpflichtende Bestandteile. Sicherheit muss durch zusätzliche Maßnahmen auf Transport-, Netzwerk- und Anwendungsebene erzwungen werden. Besonders in Multi-Trade-Environments erfordert dies eine durchgehende Sicherheitsarchitektur.

Bei MQTT handelt es sich um ein Client-Server-Protokoll, welches auf dem Publish-Subscribe-Prinzip mit zentralem Message-Broker basiert. Clients agieren entweder als Publisher (senden Nachrichten zu Topics) oder Subscriber (empfangen Nachrichten von Topics). Der Broker entkoppelt Publisher und Subscriber vollständig. Topics sind hierarchische UTF-8-Strings (z.B.: /////), die als Routing-Keys fungieren. Wildcards ermöglichen flexible Subscriptions: ‚+‘ für einzelne Hierarchieebenen, ‚#‘ für alle nachfolgenden Ebenen. MQTT 5.0 wurde um das sicherheitsrelevante Feature „Enhanced Authentication“ (AUTH-Pakete) erweitert. Dadurch erfolgt die Authentifizierung nicht nur einmalig in der CONNECT-Nachricht des Clients, bzw. der CONNACK-Nachricht des Servers, sondern es wird ein kontinuierlicher Authentifizierungs-Flow ermöglicht. 

Bedrohungsszenarien

In Multi-Trade-Environments mit MQTT existieren folgende Bedrohungen:  

1. unautorisierte Subscriptions auf fremde Topics führen zu Informationsabfluss,  
2. kompromittierte Clients können Schadsoftware über scheinbar legitime Payloads verbreiten, 
3. fehlkonfigurierte ACLs erlauben Wildcard-Subscriptions über Sicherheitsgrenzen hinweg, 
4. die Zentrale Broker-Architektur schafft einen Single-Point-of-Failure (SPOF), 
5. externe Software-Systeme ohne native MQTT-Integration umgehen möglicherweise Broker-Sicherheitskontrollen. 

Diese Bedrohungen erfordern mehrschichtige Gegenmaßnahmen, um MQTT sicher in dem gewerkeübergreifenden Konzept Gebäudebetrieb 4.0 zu verwenden. Defense-in-Depth-Prinzipien werden nachfolgend unter Berücksichtigung des BSI-IT-Grundschutzes und der IEC 62443-3-3 skizziert. An dieser Stelle ist es wichtig anzumerken, dass der MQTT-Standard für einen minimalen Overhead bewusst auf protokollseitige Sicherheitsfunktionen verzichtet. Für die nativen Anwendungsbereiche war der minimale Overhead funktionsentscheidend. Im Kontext des Konzepts Gebäudebetrieb 4.0 ist der Overhead irrelevant, die IT-Sicherheit ist dafür umso wichtiger.  

MQTT IT-Security: Defense-in-Depth-Sicherheitsarchitektur

Für eine vertrauenswürdige MQTT-Infrastruktur werden nachfolgend fünf Sicherheitsschichten empfohlen: 1) Netzwerksegmentierung mit VLANs und Firewalls, 2) Transportschicht-Verschlüsselung mit TLS-Zertifikaten, 3) Authentifizierung mit einer Public-Key-Infrastructure-(PKI)-basierten Identitätsbindung, 4) Autorisierung mit einer Access Control List (ACL) auf Broker-Ebene und 5) dem MQTT-Broker vorgeschaltet eine Security-Processing-Zone zwecks Payload-Validierung und Malware-Scanning. 

Zonierung und Netzwerksegmentierung

Es sollten Netzwerkzonen je Gewerk und je Third-Party-Anbindung definiert werden. Jede Zone erhält ein dediziertes IP-Subnetz/VLAN. Netzwerkverbindungen zwischen Zonen werden durch Firewalls kontrolliert, siehe auch Abbildung 1. Im Idealfall sind die Firewall-Regeln mit Default-Deny implementiert, sodass nur explizit erlaubte Verbindungen zugelassen sind. Für die MQTT-Zone muss der TCP-Port 8883 freigeschaltet werden. In einem Smart Building ist eine gewerkeübergreifende Kommunikation notwendig, um den holistischen Ansatz zu ermöglichen. Dabei darf aber nur die notwendige Kommunikation zugelassen werden, die anhand einer Kommunikationsmatrix festgelegt wird. 

Transport Layer Security und Public Key Infrastructure

Für alle MQTT-Verbindungen sollte die Nutzung der aktuellsten TLS-Version verpflichtend sein. Mutual TLS (mTLS) authentifiziert sowohl Client als auch Server mit X.509-Zertifikaten. Bei der Zertifikatsprüfung ist eine vollständige Chain-Validation durchzuführen, einschließlich der Prüfung der Parameter Extended Key Usage (EKU), Subject Alternative Name (SAN) und des Gültigkeitszeitraums. Um kompromittierte oder ungültige Zertifikate zeitnah sperren zu können, muss die Certificate Revocation List (CRL) aktuell gehalten werden. Entscheidend ist es, für das Projekt Vorgaben zum Zertifikatsmanagement und zur Zertifikatsgültigkeit zu definieren. Eine dedizierte Unternehmens-PKI stellt die Vertrauensbasis der Architektur dar. In der Gebäudebetrieb-4.0-Topologie ist darauf zu achten, Gateways einzusetzen, die für den Zertifikatsaustausch ausgelegt sind. Es sollten mindestens die nachfolgenden Attribute im Zertifikat hinterlegt sein: Subject Distinguished Name (eindeutige Geräte-ID), Subject Alternative Name (funktionale Rolle) und Extended Key Usage (Client Authentication). Für weitere Informationen zu Zertifikaten und PKI wird auf diese Beiträge verwiesen ​[18]​​ [2]​. 

MQTT-Broker-Härtung

Ähnlich wie bei der Firewall sollte auch beim Broker das Default-Deny-Prinzip implementiert werden. Somit sind alle PUBLISH- und SUBSCRIBE-Operationen initial verboten. Für jede Rolle muss also eine explizite Erlaubnis in der ACL definiert werden. So kann bei jeder PUBLISH- oder SUBSCRIBE-Anfrage beim Broker geprüft werden, ob die entsprechende ACL-Regel existiert. Ist dem nicht so, kann ein Security-Event protokolliert oder auch die Verbindung getrennt werden. Wildcards (‚#‘ und ‚+‘) sollten grundsätzlich verboten werden. 

In dieser Architektur wird die MQTT-Client-ID ausschließlich aus dem X.509-Zertifikat abgeleitet. Der Broker ignoriert dabei die Client-ID aus dem MQTT-Connect-Paket und identifiziert die ID aus dem SAN (Subject Alternative Name) im Zertifikat, der internen Client-ID und der zugeordneten Rolle gemäß ACL. Auf diese Weise kann das Angriffsszenario Identitäts-Spoofing verhindert werden. 

Für das Konzept ist eine gut strukturietre Semantik der Topics notwendig (/////). In Abbildung 2 ist auf der Feldebene der GLT ein Temperatursensor visualisiert. Dies könnte zum Beispiel so definiert sein: TGA/Gebäude1/Anlage1/Sensor/Out/Temp. Die Topic-Struktur ist dabei nicht nur eine reine Konvention, denn über die Semantik werden auch die Regeln definiert: 

ALLOW PUBLISH  TGA/+/+/+/out/Temp
ALLOW SUBSCRIBE  TGA/+/+/+/in/command
DENY  SUBSCRIBE  ELT/#,
DENY  SUBSCRIBE #,

Der TGA-Sensor kann somit ausschließlich die Temperaturwerte senden und eigene Kommandos empfangen. Fremde Gewerke wie zum Bespiel das Gewerk Elektrotechnik (ELT) sind nicht erreichbar. Weitere Härtungsmaßnahmen am Broker können der nachfolgenden Auflistung entnommen werden:

• Limitierung der Paketgröße, um Speicherangriffe zu verhindern, 
• Paketanzahl limitieren – eine maximale Anzahl an Publishes/Subscribes pro Client und Zeiteinheit definieren, um DDoS-Angriffe zu verhindern, 
• Verbindungs-Limits definieren, um die die maximale Anzahl simultaner Verbindungen einer Client-Rolle zu definieren, 
• Sitzungsdauer limitieren. 
  

  Tabelle 2: Vergleich API-Rolle und MQTT-Rolle

API-Gateway-Integration für externe Systeme

Viele zu integrierende Systeme aus dem Konzept Gebäudebetrieb 4.0 unterstützen nativ kein MQTT. Ein direkter API-Zugriff auf den MQTT-Broker sollte unbedingt vermieden werden, da sonst alle zuvor genannten Härtungsmaßnahmen umgangen werden können. Hier kommt ein dediziertes API-Gateway als separater Policy-Enforcement-Point (PEP) ins Spiel. Das API-Gateway ist kein MQTT-Client, sondern eine Abstraktionsschicht mit eigener Sicherheitslogik, auf der Authentifizierung, Autorisierung und Logging realisiert werden können. Bei der Definition der Regeln sollten die API- und die MQTT-Rollen strikt getrennt bleiben. 

Die API-Rolle definiert hier, welche Funktionen vom Client ausgeführt werden dürfen, während die MQTT-Rolle festlegt, auf welche Topics der Adapter PUBLISHEN/SUBSCRIBEN darf.  

Security-Processing-Zone

Als letztes Sicherheitselement der Defense-in-Depth-Architektur dient die Security-Processing-Zone. Diese wird insbesondere beim Übertragen von Dokumenten oder Binärdaten benötigt und ist logisch zwischen dem API-Gateway und dem MQTT-Broker anzusetzen. Dokumente werden natürlich nicht direkt über MQTT übertragen, doch kann über MQTT der entsprechende Alarm generiert werden, wenn in der Security-Processing-Zone zum Beispiel eine Maleware detektiert wird.  

Abgleich der Architektur mit BSI-IT-Grundschutz-Bausteinen und IEC 62443-3-3

Die Architektur adressiert folgende BSI-IT-Grundschutz-Bausteine ​[19]​. (siehe Tabelle 3) 

Zudem adressiert die Architektur folgende grundlegende Anforderungen (Fundamental Requirements – FR) und Sicherheitslevel (Security Level – SL) der IEC 62443-3-3 ​[20]. (siehe Tabelle 4)

Bei vollständiger und kontinuierlicher Umsetzung der Architektur kann somit ein hoher und anerkannter Sicherheitsgrad erreicht werden. Smart-Building-Systeme können komplex sein und müssen immer ganzheitlich betrachtet werden. Das bedeutet auch, dass die IT-Security von Beginn an berücksichtigt werden muss, denn mit jeder neuen Schnittstelle wächst auch die Angriffsfläche. Die gute Nachricht: Rein technisch können alle Werkzeuge für eine sichere Umsetzung von der IT bereitgestellt werden. Auf lange Sicht werden die meisten Nichtwohngebäude um eine Smartifizierung nicht herumkommen, da vieles zukünftig Stand der Technik sein wird. Wer IT-Security nicht von Anfang an mitdenkt und umsetzt, muss am Ende wahrscheinlich ein Vielfaches zahlen. 

Ausblick

Bei der IT-Sicherheitsarchitektur für MQTT hört die Arbeit nicht auf. Auch für die AAS sind noch Sicherheitsmaßnahmen umzusetzen. AASX-Dateien sind das standardisierte Austauschformat für die Verwaltungsschale. Ohne Signatur der AASX-Pakete können Vertraulichkeit und Integrität der Pakete de facto nicht gewährleistet werden. 

Wie es mit der Geschichte weitergeht, wird ein anderes Mal erzählt. 

Literaturverzeichnis 

​[1] ​D. J. Dams, „Moderne Gebäude: Eine Netzplanung für alle?,“ ComConsult Netzwerk Insider, September 2020.

​[2] ​D. A. Kaup, „Sichere Kommunikationsprotokolle in der Ge-bäudeautomation – im Fokus: BACnet Secure Connect.,“ ComConsult Netzwerk Insider, März 2024.

​[3] ​D. J. Dams, „ – Bauprojekte und die Planung des Netzes.,“ ComConsult Netzwerk Insider , Juli 2024.

​[4] ​D. A. Kaup, „GA-IT-Infrastruktur – Nachrüsten und Modernisierung der Gebäudeautomation gemäß GEG und EPBD.,“ ComConsult Netzwerk Insider, November 2024.

​[5] ​T. Steil, „ BSI-IT-Grundschutz für Gebäudeinfrastrukturen – wie soll man das denn umsetzen?,“ ComConsult Netzwerk Insider, Februar 2022.

​[6] ​T. Steil, „BSI-IT-Grundschutz für Gebäudeinfrastrukturen.,“ ComConsult Netzwerk Insider , Januar 2022.

​[7] ​T. S. Thomas Steil, „ IT-Infrastrukturen für das Gebäude der Zukunft.,“ ComConsult Netzwerk Insider , Januar 2019.

​[8] ​D. A. Kaup, „ Smart Building? – Aber sicher!,“ ComConsult Blog, Januar 2023.

​[9] ​DIN, DIN 276:2018-12 Kosten im Bauwesen, 2018.

​[10] ​„Projekt – Gebäudebetrieb 4.0,“ Hochschule Mainz, [Online]. Available: https://www.hs-mainz.de/studium/services/technik/labore-bauingenieurwesen/smart-building/projekte/. [Zugriff am 09 02 2026].

​[11] ​D. EN, DIN EN IEC 63278-1:2024-09 Verwaltungsschale für industrielle Anwendungen – Teil 1: Struktur der Verwaltungsschale (IEC 63278-1:2023); Deutsche Fassung EN IEC 63278-1:2024, 2024.

​[12] ​„AAS Specifications,“ [Online]. Available: https://industrialdigitaltwin.org/en/content-hub/aasspecifications. [Zugriff am 09 02 2026].

​[13] ​D. Obermaier, „Was ist MQTT.,“ 19 6 2018. [Online]. Available: https://www.embedded-software-engineering.de/was-ist-mqtt-a-725485/. [Zugriff am 09 02 2026].

​[14] ​OASIS, „MQTT Version 3.1.1 Plus Errata 01,“ 10 12 2015. [Online]. Available: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf. [Zugriff am 09 02 2026].

​[15] ​ISO/IEC, ISO/IEC 20922:2016 Information technology — Message Queuing Telemetry Transport (MQTT) v3.1.1, 2016.

​[16] ​OASIS, „MQTT Version 5.0,“ 07 03 2019. [Online]. Available: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf. [Zugriff am 09 02 2026].

​[17] ​O. NIST, „MQTT and the NIST Cybersecurity Framework,“ 28 03 2014. [Online]. Available: https://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html. [Zugriff am 09 02 2026].

​[18] ​J. Hermens, „BACnet/SC und PKI: Grundlagen für sichere Gebäudeautomation.,“ ComConsult Blog, November 2025.

​[19] ​B. f. S. i. d. Informationstechnik, IT-Grundschutz-Kompendium, BONN: Reguvis Fachmedien GmbH, 2023.

​[20] ​IEC, IEC 62443-3-3:2013 Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels, 2013.