BACnet/SC: Was ist das, und warum ist es ein Paradigmenwechsel?

Gebäudeautomation galt lange als geschlossene Welt: ein Netzwerk im Technikraum, das kaum jemand von aussen sah. Diese Zeiten sind vorbei. Heute hängen Automationsstationen, Leitsysteme und Cloud-Dienste am selben IP-Netz wie Bürorechner und Fernwartungszugänge. Damit wird die Kommunikation zwischen den Geräten zum Sicherheitsthema, und genau hier setzt BACnet/SC an.

Diese Serie «BACnet/SC: Sicherheit & Migration» ergänzt unsere Serien «BACnet Objekte verstehen» und «BACnet Planung: Das Fundament». Ging es dort um Objektmodell, Vorgaben und Planungsprozess, dreht sich hier alles um eine Frage: Wie wird die Kommunikation einer Gebäudeautomation sicher, ohne dass Interoperabilität, Wartbarkeit und Herstellerunabhängigkeit verloren gehen?

Dieser erste Teil legt das Fundament: Was ist BACnet/SC überhaupt, welche technischen Bausteine stecken dahinter, und warum ist es kein blosses Update, sondern ein echter Paradigmenwechsel für Planer, Betreiber und IT?

Warum klassisches BACnet/IP ein Sicherheitsproblem ist

BACnet ist ein offener Kommunikationsstandard nach ISO 16484-5. In der verbreiteten Variante BACnet/IP werden die Nachrichten als Klartext über UDP verschickt. Das war praktisch, solange die Gebäudeautomation in einem physisch getrennten Netz lief. Sobald sie aber Teil der IP-Infrastruktur wird, entstehen konkrete Risiken.

Wer Zugriff auf das Netzsegment hat, kann den Datenverkehr mitlesen, Werte verändern oder Geräte gezielt stören. Ein Angreifer könnte Sollwerte manipulieren, Alarme unterdrücken oder mit gefälschten Broadcast-Nachrichten das ganze Netz durcheinanderbringen. Da BACnet/IP weder Verschlüsselung noch eine echte Authentifizierung kennt, gibt es keine technische Hürde, die das verhindert.

Dazu kommt die Broadcast-Problematik: Klassisches BACnet/IP arbeitet mit Broadcasts, und über Subnetzgrenzen hinweg braucht es sogenannte BBMDs (BACnet Broadcast Management Devices). Diese Konstruktion ist fehleranfällig, schwer durch Firewalls zu führen und aus IT-Sicht ein Fremdkörper. Genau diese Schwächen adressiert BACnet/SC.

Ein konkretes Beispiel macht das Risiko greifbar. In einem grösseren Bürogebäude teilt sich die Gebäudeautomation das Netz mit der Bürokommunikation, weil es die Verkabelung vereinfacht hat. Ein kompromittierter Laptop im selben Segment genügt, um mit frei verfügbaren Werkzeugen den BACnet-Verkehr aufzuzeichnen. Aus den Klartext-Nachrichten lassen sich Sollwerte, Belegungszeiten und Anlagenstrukturen ablesen, wertvolle Informationen für einen gezielten Angriff. Mit wenig Aufwand liessen sich Heizkurven verstellen, Lüftungen abschalten oder Störmeldungen unterdrücken, ohne dass das Leitsystem etwas davon bemerkt. Nicht, weil BACnet schlecht konstruiert wäre, sondern weil BACnet/IP für eine geschlossene Welt entworfen wurde, die es so nicht mehr gibt.

Was BACnet/SC eigentlich ist

BACnet/SC (Secure Connect) ist eine neue, gesicherte Datenverbindungsschicht für BACnet. Wichtig zum Verständnis: BACnet/SC ändert nicht das Objektmodell. Analog- und Binärobjekte, Properties wie Present_Value oder Priority_Array, Dienste wie ReadProperty oder COV, all das bleibt exakt gleich. Was sich ändert, ist ausschliesslich die Art, wie diese Nachrichten transportiert werden.

Statt Klartext über UDP nutzt BACnet/SC zwei etablierte IT-Standards:

• WebSocket (RFC 6455) als Transportkanal. Damit läuft die Kommunikation über eine stehende, bidirektionale Verbindung statt über verbindungslose Broadcasts.
• TLS 1.3 (RFC 8446) für Verschlüsselung, Integrität und gegenseitige Authentifizierung. Jede Verbindung ist damit ein gesicherter Tunnel, in dem beide Seiten ihre Identität per Zertifikat nachweisen.

Das Ergebnis: Die Gebäudeautomation spricht weiterhin BACnet, aber über denselben Sicherheitsmechanismus, den auch modernes Online-Banking verwendet. Für die IT ist BACnet/SC damit kein exotisches Protokoll mehr, sondern verschlüsselter WebSocket-Verkehr über einen einzigen, gut kontrollierbaren Port.

Der Paradigmenwechsel: vom offenen Bus zum gesicherten Tunnel

Der eigentliche Wandel liegt nicht in einer einzelnen Funktion, sondern in einer neuen Denkweise. Klassisches BACnet/IP folgt der Logik eines offenen Busses: Alle hören mit, Vertrauen entsteht durch die Netzwerktrennung. BACnet/SC dreht das um. Vertrauen entsteht nicht mehr durch die Topologie, sondern durch Kryptografie. Nur wer ein gültiges, von einer vertrauenswürdigen Stelle signiertes Zertifikat besitzt, darf mitreden.

Drei Konsequenzen machen diesen Wechsel greifbar:

Verschlüsselung als Grundzustand. Jede Nachricht ist verschlüsselt, nicht als Zusatzoption, sondern by Design. Mitlesen oder Manipulieren wird technisch verhindert, nicht nur organisatorisch erschwert.

Identität statt Adresse. In BACnet/IP genügt die richtige IP-Adresse im richtigen Segment. In BACnet/SC muss ein Gerät seine Identität kryptografisch nachweisen. Eine gefälschte oder nicht autorisierte Station kommt gar nicht erst in die Kommunikation.

IT-Kompatibilität als Grundlage. Weil BACnet/SC auf WebSocket und TLS aufsetzt und ohne Broadcasts auskommt, passt es sauber in moderne, segmentierte IT-Netze. Es braucht keine BBMDs mehr und lässt sich über einen definierten Port durch Firewalls führen.

Die technische Grundlage im Detail

Damit die Serie ein solides Fundament hat, lohnt ein genauerer Blick auf die Bausteine.

WebSocket als Transport. Ein WebSocket ist eine dauerhafte Verbindung zwischen zwei Endpunkten, die in beide Richtungen offen bleibt. Anders als beim klassischen Broadcast weiss jedes Gerät genau, mit wem es verbunden ist. Das erleichtert die Kontrolle des Datenverkehrs erheblich und macht das Verhalten im Netz vorhersehbar.

TLS 1.3 als Sicherheitsschicht. TLS sorgt für drei Dinge gleichzeitig: Vertraulichkeit (niemand kann mitlesen), Integrität (niemand kann Nachrichten unbemerkt verändern) und Authentizität (beide Seiten sind sicher, mit wem sie sprechen). BACnet/SC verlangt gegenseitige Authentifizierung (mutual TLS): Nicht nur der Server weist sich aus wie beim Webbrowsing, sondern auch jeder Client. Damit ist ausgeschlossen, dass sich ein unbekanntes Gerät einfach in die Kommunikation einklinkt, ein zentraler Unterschied zum offenen BACnet/IP, wo die blosse Netzwerkzugehörigkeit genügt.

Ein einziger, kontrollierbarer Port. Weil die gesamte Kommunikation über gesicherte WebSocket-Verbindungen läuft, reduziert sich der Datenverkehr auf einen definierten Port statt auf das breite Spektrum an Broadcast- und Unicast-Verkehr des klassischen BACnet/IP. Das vereinfacht die Firewall-Konfiguration erheblich und macht den GA-Verkehr für die IT nachvollziehbar und überwachbar. Netzwerksegmentierung, Monitoring und Zugriffskontrolle greifen nun genauso wie bei jedem anderen modernen Dienst.

Zertifikate und Cipher Suite. Jedes Gerät besitzt einen privaten Schlüssel und ein signiertes Betriebszertifikat (Operational Certificate). Das Addendum cd zur ASHRAE 135-2020 legt für die Interoperabilität ein verbindliches TLS-1.3-Profil fest, unter anderem die Cipher Suite «TLS_AES_128_GCM_SHA256» sowie definierte Verfahren für Signatur und Schlüsselaustausch. Dass ein solches Profil vorgeschrieben ist, ist entscheidend: Nur so verstehen sich Geräte verschiedener Hersteller auch auf der Sicherheitsebene.

Die neuen Netzwerkrollen

Mit BACnet/SC kommt eine neue Topologie ins Spiel. Statt des flachen Broadcast-Netzes gibt es eine sternförmige Struktur (Hub-and-Spoke) mit klaren Rollen:

• Primary Hub: die zentrale Vermittlungsstelle, über die der Datenverkehr zwischen den Knoten läuft. Pro Netz ist genau ein Primary Hub aktiv.
• Failover Hub: ein optionaler Ersatz-Hub, der automatisch übernimmt, wenn der Primary Hub ausfällt oder gewartet wird. Damit wird die zentrale Rolle ausfallsicher.
• Nodes (Knoten): die eigentlichen BACnet/SC-Geräte, die sich mit dem Hub verbinden.
• Direct Connections: zusätzlich können Knoten direkte Verbindungen untereinander aufbauen, etwa für hohen, dauerhaften Datenverkehr, ohne den Hub zu belasten.

Ein wichtiger Nebeneffekt: BBMDs entfallen vollständig. Die gesamte Broadcast-Verwaltung, die in klassischen BACnet/IP-Netzen für viel Aufwand und Fehler sorgt, wird durch die Hub-Logik ersetzt. Die konkrete Auslegung dieser Architektur ist das Thema von Teil 2.

Was sich für die Beteiligten ändert

BACnet/SC betrifft nicht nur Techniker. Es verschiebt Zuständigkeiten und Kompetenzen, und es zwingt Gewerke an einen Tisch, die früher getrennt gearbeitet haben. Wo die Gebäudeautomation früher ihr eigenes Netz betrieb, braucht es jetzt eine Abstimmung zwischen GA-Planung, Betrieb und IT-Abteilung. Diese Zusammenarbeit ist kein Nebenschauplatz, sondern der eigentliche Erfolgsfaktor: Ein technisch perfektes BACnet/SC-Konzept scheitert in der Praxis, wenn niemand die Verantwortung für die Zertifikate übernimmt oder die Firewall-Regeln nicht abgestimmt sind.

Für Planer heisst das: Sicherheit wird zum festen Bestandteil der GA-Planung. Wer heute ausschreibt, muss BACnet/SC-Fähigkeit, Zertifikatskonzept und Hub-Architektur mitdenken, nicht als Kür, sondern als Teil der Grundausstattung. Die reine Protokollangabe «BACnet/IP» genügt nicht mehr.

Für Betreiber bedeutet es mehr Sicherheit, aber auch neue Pflichten. Zertifikate haben eine Laufzeit und müssen erneuert werden. Läuft ein Zertifikat unbemerkt ab, fällt ein Gerät aus der Kommunikation. Der Betrieb einer BACnet/SC-Anlage umfasst deshalb ein Stück Zertifikatsverwaltung, das es vorher nicht gab.

Für die IT wird die Gebäudeautomation endlich anschlussfähig. Verschlüsselter WebSocket-Verkehr über einen definierten Port, keine Broadcasts, saubere Authentifizierung, das ist Sprache, welche die IT versteht. Zugleich muss die IT Ressourcen bereitstellen: eine Zertifizierungsstelle (CA) oder deren Anbindung, Namensauflösung und die passende Firewall-Konfiguration. Wo genau die Grenze zwischen GA und IT verläuft, klärt Teil 2.

Häufige Missverständnisse

Gerade weil BACnet/SC neu ist, kursieren einige Fehlannahmen. Die vier häufigsten:

• «BACnet/SC ist ein neues Protokoll, das alles ersetzt.» Falsch. Es ist eine neue Transportschicht. Das Objektmodell und die Dienste bleiben identisch, bestehendes BACnet-Wissen bleibt vollständig gültig.
• «Wenn das Netz getrennt ist, brauche ich BACnet/SC nicht.» Physische Trennung ist heute selten wirklich vollständig und schützt nicht vor internen Bedrohungen oder Fernwartungszugängen. Verschlüsselung wirkt zusätzlich, nicht ersatzweise.
• «BACnet/SC ist einfach eine Firewall-Regel.» Nein. Es ist eine kryptografisch abgesicherte Kommunikation mit Zertifikaten und Hub-Architektur, nicht eine reine Netzwerkfilterung.
• «Das erledigt der Integrator schon nebenbei.» Zertifikatskonzept, Hub-Auslegung und Migrationsweg sind Planungsleistungen. Ohne klare Vorgaben entstehen dieselben Abhängigkeiten und Lücken, die wir aus schlecht geplanten BACnet/IP-Projekten kennen.

Kurz erklärt: BACnet/SC verschlüsselt und authentifiziert die BACnet-Kommunikation über WebSocket und TLS 1.3. Es ersetzt nicht das Objektmodell, sondern nur den Transportweg, vom offenen Broadcast-Netz zum gesicherten, sternförmigen Tunnelnetz mit Primary- und Failover-Hub.

Warum gerade jetzt der richtige Zeitpunkt ist

BACnet/SC ist verfügbar, standardisiert und bei den führenden Herstellern in aktuellen Geräten und Firmware-Ständen angekommen. Damit stellt sich für jedes neue oder zu sanierende Projekt die Frage nicht mehr, ob man auf gesicherte Kommunikation setzt, sondern wann. Drei Entwicklungen machen den Umstieg dringlich.

Erstens verschmelzen Gebäudeautomation und IT unumkehrbar. Fernwartung, Energiemonitoring, Cloud-Anbindung und übergreifende Dashboards setzen voraus, dass die GA im IP-Netz erreichbar ist. Ein separates, physisch getrenntes Automationsnetz ist in der Praxis die Ausnahme geworden. Zweitens steigen die regulatorischen Anforderungen: Betreiber öffentlicher und kritischer Bauten müssen Cybersicherheit zunehmend nachweisen, nicht nur behaupten. Drittens sind Gebäudeautomationen langlebig. Wer heute plant, legt den Kommunikationsweg für die nächsten 15 bis 20 Jahre fest. Eine Anlage, die jetzt noch ausschliesslich auf ungesichertes BACnet/IP setzt, wird schon in wenigen Jahren als Altlast dastehen und teuer nachgerüstet werden müssen.

Der normative Rahmen

BACnet/SC ist kein Herstellervorschlag, sondern standardisiert. Die Grundlage bildet das Addendum bj zur ASHRAE 135, das die gesicherte Datenverbindungsschicht eingeführt hat. Das spätere Addendum cd zur Ausgabe 135-2020 präzisiert das verbindliche TLS-1.3-Profil und stellt so die herstellerübergreifende Interoperabilität sicher. Da ISO 16484-5 den BACnet-Standard international verankert, fügt sich BACnet/SC nahtlos in den bestehenden normativen Rahmen ein, den wir schon in der Serie «BACnet Planung: Das Fundament» beschrieben haben.

Für die Schweiz kommt die Governance-Ebene hinzu: Betreiber kritischer und öffentlicher Bauten bewegen sich zunehmend in einem Umfeld aus IKT-Minimalstandard, ISO 27001 und OT-Sicherheitsanforderungen. Wie BACnet/SC in diesen regulatorischen Rahmen passt, ist das Thema von Teil 5.

Fazit

BACnet/SC ist mehr als ein technisches Update. Es verändert die Grundlage, auf der Vertrauen in einer Gebäudeautomation entsteht: weg von der Annahme «das Netz ist ja getrennt», hin zu «jede Verbindung ist verschlüsselt und jede Identität ist nachgewiesen». Das Objektmodell bleibt, der Transportweg wird sicher.

Für Planer, Betreiber und IT bedeutet das neue Aufgaben, aber auch eine echte Chance: Gebäudeautomation wird endlich IT-tauglich, ohne ihre Offenheit und Herstellerunabhängigkeit aufzugeben. Wer diesen Wandel früh mitgeht, sichert seine Anlagen für die nächsten 15 bis 20 Jahre ab und vermeidet teure Nachrüstungen unter Zeitdruck. Der Umstieg ist damit weniger eine Frage der Technik als eine Frage der rechtzeitigen Planung.

Diese Serie ergänzt «BACnet Objekte verstehen» (Mechanik der Objekttypen) und «BACnet Planung: Das Fundament» (Planungsprozess). Wer alle drei kennt, versteht BACnet vom einzelnen Objekt über die Planung bis zur sicheren Kommunikation. Teil 2 zeigt als Nächstes, welche Infrastruktur eine BACnet/SC-Installation wirklich braucht, und was nicht.

Sie haben Fragen dazu?

Sprechen Sie uns an, wir unterstützen Betreiber, Planer und IT-Verantwortliche bei Konzeption, Migration und Abnahme sicherer BACnet/SC-Infrastrukturen.

WENGET GmbH E-Mail: info@wenget.ch Telefon: +41 44 552 34 88

Quellenverzeichnis

• ASHRAE, «Standard 135-2016, Addendum bj (BACnet/SC)», ASHRAE
• ASHRAE, «Standard 135-2020, Addendum cd (TLS-1.3-Cipher-Suite-Profil)», ASHRAE
• BACnet International, «BACnet Secure Connect: A Secure Infrastructure for Building Automation (White Paper)»
• ISO 16484-5, «Building automation and control systems: Part 5: Data communication protocol (BACnet)»
• IETF RFC 8446, «The Transport Layer Security (TLS) Protocol Version 1.3»
• IETF RFC 6455, «The WebSocket Protocol»
• NIST, «Cybersecurity Framework»