Updates und Firmware: Wie viel Aktualität braucht die Gebäudetechnik?

Wer die ersten drei Teile dieser Serie gelesen hat, kennt die Grundlagen: ein vollständiges Inventar der Geräte, geregelte Fernzugänge und individuelle Konten statt Standardpasswörter. Doch selbst wer all das umgesetzt hat, steht früher oder später vor einer Frage, die in der Gebäudetechnik besonders heikel ist: Was machen wir, wenn der Hersteller ein Firmware-Update für unsere Automationsstation veröffentlicht? Einspielen und riskieren, dass die Anlage danach anders reagiert? Oder warten und riskieren, dass eine bekannte Sicherheitslücke offen bleibt?

Diese Spannung ist real. In der Büro-IT gilt oft die Regel: Updates so schnell wie möglich. In der Gebäudeautomation gilt eine andere Logik. Controller, Bedienstationen und Managementserver sind eng mit physischen Prozessen verknüpft. Ein Neustart zur falschen Zeit, eine veränderte Parameterstruktur nach dem Update oder ein Kompatibilitätsproblem zwischen Firmware und Feldbusprotokoll kann den Betrieb stören. Trotzdem ist Nichtstun keine Antwort. Dieser Artikel zeigt, wie ein strukturierter Patchprozess aussieht, der beide Anforderungen ernst nimmt: Sicherheit und Betriebsstabilität.

Warum Patchmanagement in der Gebäudetechnik anders ist

In der klassischen IT wird ein Patch eingespielt, der Rechner startet neu, und nach wenigen Minuten läuft alles wieder. In der Gebäudeautomation ist das Bild komplexer. Eine Automationsstation steuert vielleicht gleichzeitig die Heizungsregelung, die Lüftungsanlage und die Brandschutzklappen eines Gebäudes. Ein unkontrollierter Neustart mitten im Betrieb kann Komfortprobleme verursachen, im schlimmsten Fall aber auch sicherheitsrelevante Funktionen kurzzeitig unterbrechen.

Dazu kommt die Heterogenität der Systeme. In einem typischen Gebäude finden sich Controller verschiedener Hersteller, Managementserver mit proprietären Betriebssystemen, Bedienstationen auf Windows-Basis und Feldgeräte mit eingebetteter Firmware, die seit Jahren keine Updates mehr erhalten hat. Jedes dieser Systeme hat seinen eigenen Update-Mechanismus, seine eigene Dokumentation und seinen eigenen Risikoprofil. Eine einheitliche Patchstrategie muss all das berücksichtigen.

Die Norm IEC 62443-2-3 widmet sich genau diesem Thema: dem Patchmanagement in industriellen und gebäudetechnischen Umgebungen. Sie beschreibt, wie Betreiber und Dienstleister gemeinsam einen Prozess aufbauen, der von der Bekanntgabe eines Updates bis zur dokumentierten Umsetzung oder bewussten Ablehnung reicht. Auch die KBOB-Empfehlung «IKT-Sicherheit in der Gebäudeautomation» (2025) hält fest, dass Betreiber einen geregelten Umgang mit Firmware- und Softwareständen sicherstellen müssen. Die Verantwortung dafür liegt beim Betreiber, auch wenn die operative Arbeit an einen Dienstleister delegiert wird.

Jedes Update muss bewertet werden, aber nicht jedes muss sofort eingespielt werden

Der erste Schritt ist die Bewertung. Nicht jedes Update trägt das gleiche Gewicht. Ein Firmware-Update, das eine kritische Sicherheitslücke schliesst, über die ein Angreifer aus der Ferne Kontrolle über einen Controller übernehmen könnte, hat eine andere Dringlichkeit als ein Update, das die Darstellung eines Menüs verbessert oder eine neue Protokollvariante ergänzt.

Für die Bewertung braucht es zunächst die Information. Hersteller kommunizieren Updates auf unterschiedlichen Wegen: über Kundendienst-Newsletter, über Sicherheitshinweise auf ihren Webseiten oder über automatische Benachrichtigungen in der Managementsoftware. Wer kein Inventar führt, weiss oft nicht einmal, welche Geräte er betreibt und ob ein Hinweis des Herstellers überhaupt relevant ist. Das ist einer der Gründe, warum das Inventar, das wir in Teil 1 dieser Serie beschrieben haben, die Grundlage für alles Weitere bildet.

Ist die Information vorhanden, folgt die Einschätzung entlang einiger Leitfragen: Welche Schwachstelle wird geschlossen? Ist das betroffene Gerät von aussen erreichbar oder im abgeschotteten Segment? Gibt es bereits bekannte Angriffe auf diese Lücke? Welche Risiken bringt das Update selbst mit sich, etwa durch veränderte Konfigurationsstrukturen oder neue Abhängigkeiten? Und: Gibt es kompensierende Massnahmen, die das Risiko überbrücken, bis ein Update sicher eingespielt werden kann?

Diese Bewertung muss dokumentiert werden. Wer später nachweisen muss, dass er verantwortungsvoll gehandelt hat, braucht eine schriftliche Entscheidungsgrundlage. Das gilt besonders für Betreiber kritischer Infrastrukturen, für die seit dem 1. April 2025 eine Meldepflicht für Cyberangriffe gemäss dem Informationssicherheitsgesetz (ISG) gilt.

Testumgebung oder Testanlage: Warum man nicht direkt in die Produktion geht

Ein Update, das als sinnvoll eingestuft wurde, sollte nicht direkt auf der laufenden Anlage eingespielt werden. Das klingt selbstverständlich, ist in der Praxis aber oft nicht umgesetzt. Der Grund ist einfach: Viele Betreiber haben keine Testumgebung für ihre Gebäudetechnik.

In der Büro-IT gibt es Testrechner, Staging-Umgebungen und automatisierte Testläufe. In der Gebäudetechnik fehlt das häufig. Trotzdem gibt es Wege, das Risiko zu reduzieren. Eine Möglichkeit ist die Testanlage: Ein Gerät gleichen Typs, das nicht produktionskritisch ist, erhält das Update zuerst. Wenn es sich um einen Controller handelt, der eine weniger kritische Zone steuert, kann dieser als Testkandidat dienen. Verhält er sich nach dem Update wie erwartet, kann das Update schrittweise auf weitere Geräte ausgerollt werden.

Eine andere Möglichkeit ist die Simulation. Manche Hersteller bieten virtuelle Instanzen ihrer Controller oder Managementsoftware an, auf denen Updates getestet werden können, ohne physische Geräte zu berühren. Das ist nicht für alle Systeme verfügbar, aber wo es existiert, sollte es genutzt werden.

Was in jedem Fall gilt: Vor dem Update auf einem Produktivsystem muss ein vollständiges Backup der Konfiguration vorhanden sein. Das schliesst die Parametrierung der Controller, die Datenpunktlisten, die Regelungslogik und die Konfiguration der Managementebene ein. Wer kein Backup hat, kann nach einem fehlgeschlagenen Update nicht auf den vorherigen Zustand zurückkehren. Das ist kein theoretisches Risiko. In unserer Erfahrung sind Konfigurationsverluste nach Updates eine der häufigsten Ursachen für ungeplante Betriebsunterbrüche in der Gebäudetechnik.

Wartungsfenster: Wann ist der richtige Zeitpunkt?

Selbst wenn ein Update getestet und freigegeben ist, bleibt die Frage des Zeitpunkts. In der Gebäudetechnik gibt es keine Zeit, zu der ein Eingriff völlig ohne Auswirkungen ist. Aber es gibt Zeitfenster, in denen die Auswirkungen minimiert werden können.

Ein Wartungsfenster sollte so geplant werden, dass die betroffenen Anlagen in einem unkritischen Betriebszustand sind. Für eine Heizungsanlage bedeutet das typischerweise ausserhalb der Heizperiode oder in den frühen Morgenstunden eines Werktags, wenn die Nutzung gering ist. Für eine Lüftungsanlage in einem Spital oder Rechenzentrum gibt es möglicherweise gar kein Fenster ohne Nutzung. Dann braucht es eine andere Strategie: redundante Systeme, manuelle Überbrückung oder eine abgestimmte Abschaltsequenz.

Das Wartungsfenster muss im Voraus kommuniziert werden. Nutzer, Facility Manager und allenfalls die Sicherheitsverantwortlichen müssen wissen, wann ein Eingriff stattfindet, was davon betroffen ist und wie lange er dauert. Und es muss einen Rückfallplan geben: Was passiert, wenn das Update fehlschlägt? Wer entscheidet, ob auf die gesicherte Konfiguration zurückgegangen wird? Wer ist erreichbar, wenn ausserhalb der Bürozeiten etwas schiefläuft?

Diese Fragen klingen nach Bürokratie, sind aber der Kern eines funktionierenden Patchprozesses. Ohne klare Antworten darauf wird jedes Update zum Glücksspiel.

End of Life erkennen: Was tun, wenn keine Updates mehr kommen?

Ein besonderes Problem in der Gebäudetechnik ist das End-of-Life-Gerät. Controller, die vor zehn oder fünfzehn Jahren installiert wurden, erhalten oft keine Firmware-Updates mehr. Der Hersteller hat den Support eingestellt, die Entwicklungsumgebung existiert nicht mehr, und Sicherheitslücken bleiben offen, weil es schlicht keine Patches gibt.

Das ist kein Randproblem. In vielen Bestandsanlagen sind Geräte im Einsatz, die technisch noch funktionieren, aber aus Sicherheitssicht nicht mehr vertretbar sind. Wer sein Inventar kennt, kann diese Geräte identifizieren. Wer kein Inventar hat, weiss es nicht.

Der erste Schritt ist die Erkennung. Welche Geräte haben kein aktives Supportende mehr? Welche erhalten seit mehr als zwei Jahren keine Updates? Welche laufen auf Betriebssystemversionen, die der Hersteller nicht mehr pflegt? Diese Informationen gehören ins Inventar und müssen regelmässig aktualisiert werden.

Der zweite Schritt ist die Risikobewertung. Ein End-of-Life-Gerät, das in einem vollständig abgeschotteten Segment ohne Verbindung nach aussen betrieben wird, hat ein anderes Risikoprofil als ein Gerät, das direkt mit dem Unternehmensnetz verbunden ist. Das bedeutet nicht, dass das erste Gerät kein Problem ist, aber die Dringlichkeit des Handlungsbedarfs ist unterschiedlich.

Der dritte Schritt sind kompensierende Massnahmen. Wenn ein Gerät nicht sofort ersetzt werden kann, weil das Budget fehlt, weil der Ersatz technisch komplex ist oder weil ein Sanierungsprojekt erst in zwei Jahren geplant ist, dann müssen andere Massnahmen das Risiko reduzieren. Die wichtigste ist die Segmentierung: Das Gerät wird in ein eigenes Netzwerksegment verschoben, das vom Rest der Anlage und vom Unternehmensnetz getrennt ist. Kommunikation ist nur über definierte, überwachte Wege möglich. Das schränkt die Angriffsfläche erheblich ein, auch wenn die Firmware veraltet bleibt.

Wir haben in Teil 1 dieser Serie beschrieben, wie ein vollständiges Inventar aufgebaut wird. Und in Teil 2 haben wir erklärt, wie Fernzugänge geregelt werden. Beides ist Voraussetzung dafür, dass kompensierende Massnahmen für End-of-Life-Geräte überhaupt greifen können.

Der Rückfallplan: Was passiert, wenn ein Update schiefläuft?

Jeder Patchprozess braucht einen Rückfallplan. Das ist keine Frage des Misstrauens gegenüber dem Hersteller oder dem Dienstleister, sondern eine Grundregel des verantwortungsvollen Betriebs. Updates können Probleme verursachen, die im Test nicht aufgetreten sind, weil die Produktivumgebung immer etwas anders ist als die Testumgebung.

Der Rückfallplan beginnt mit dem Backup. Vor jedem Update auf einem Produktivsystem muss die vollständige Konfiguration gesichert sein, und es muss getestet sein, dass das Backup tatsächlich eingespielt werden kann. Ein Backup, das nie zurückgespielt wurde, ist kein Backup, sondern eine Hoffnung.

Dann braucht es eine klare Entscheidungsregel: Bis wann nach dem Update wird entschieden, ob alles funktioniert? Wer trifft diese Entscheidung? Und was sind die Kriterien? Wenn nach dem Update eine bestimmte Regelzone nicht mehr korrekt reagiert, ist das ein Rückfallkriterium. Wenn die Managementebene keine Verbindung mehr zu einem Controller aufbaut, ebenfalls.

Der Rückfallplan muss schriftlich vorliegen und den beteiligten Personen bekannt sein. Das schliesst den Dienstleister ein, der das Update einspielt, aber auch den Facility Manager oder die Betriebsverantwortlichen, die im Notfall erreichbar sein müssen. Wer erst im Fehlerfall herausfindet, wer zuständig ist, verliert wertvolle Zeit.

Dieser Aspekt hängt eng mit dem Notfallplan zusammen, den wir in Teil 5 dieser Serie behandeln. Dort gehen wir auf den umfassenderen Umgang mit Sicherheitsvorfällen ein, vom Erkennen bis zur Wiederherstellung.

Der Servicevertrag als Grundlage des Patchprozesses

Ein strukturierter Patchprozess funktioniert nicht ohne klare Vereinbarungen zwischen Betreiber und Dienstleister. Wer ist dafür zuständig, neue Updates zu erkennen und zu melden? Wer bewertet sie? Wer führt den Test durch? Wer spielt das Update ein, und wer dokumentiert das Ergebnis?

Diese Fragen müssen im Servicevertrag geregelt sein. Ein Vertrag, der nur die Reaktionszeit bei Störungen und die Anzahl der Wartungsbesuche pro Jahr definiert, deckt das Patchmanagement in der Regel nicht ab. Das führt dazu, dass Updates entweder gar nicht eingespielt werden, weil niemand zuständig ist, oder ohne Prozess direkt auf der Produktivanlage landen, weil der Dienstleister es «schnell erledigt» hat.

Wir empfehlen, im Servicevertrag mindestens folgende Punkte zu regeln: die Pflicht des Dienstleisters, Sicherheitshinweise der Hersteller zu verfolgen und dem Betreiber zu melden; den Prozess für Bewertung, Test und Freigabe; die Verantwortung für Backups vor Updates; die Dokumentation jedes eingespielten oder bewusst zurückgestellten Updates; und den Umgang mit End-of-Life-Geräten, einschliesslich der Meldepflicht, wenn ein Gerät keinen Support mehr erhält.

Ein guter Servicevertrag schafft Klarheit auf beiden Seiten. Der Betreiber weiss, was er bekommt. Der Dienstleister weiss, was er schuldet. Und im Streitfall gibt es eine Grundlage, die nicht auf Erinnerungen basiert.

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel ist Teil 4 der Serie «OT-Security für Betreiber: fünf Schritte». Die anderen Teile behandeln die Grundlagen, die für einen funktionierenden Patchprozess vorausgesetzt werden. Teil 1 der Serie, «Was steht eigentlich im Netz? Das Inventar der Gebäudetechnik», zeigt, wie man überhaupt weiss, welche Geräte vorhanden sind und welche Firmware-Versionen sie tragen. Ohne dieses Inventar ist Patchmanagement nicht möglich. Teil 2, «Fernzugänge im Griff: Wer kommt von aussen auf unsere Anlagen?», erklärt, wie Fernzugänge so gestaltet werden, dass ein kompromittiertes Gerät nicht als Einfallstor für den Rest der Anlage dient. Teil 3, «Passwörter und Konten: Schluss mit admin/admin», behandelt die Kontenverwaltung, die auch beim Einspielen von Updates relevant ist, weil Update-Prozesse oft mit erhöhten Rechten laufen. Teil 5, «Wenn es doch passiert: Der Notfallplan für die Gebäudetechnik», schliesst die Serie mit dem Umgang mit Sicherheitsvorfällen ab, einschliesslich der Frage, wie man nach einem fehlgeschlagenen Update oder einem Angriff den Betrieb wiederherstellt.

Wer sich für die technischen Grundlagen von BACnet/SC und dessen Sicherheitsarchitektur interessiert, findet in der Serie «BACnet/SC, Sicherheit & Migration» weiterführende Informationen, insbesondere in Teil 5, «BACnet/SC, Sicherheit & Migration, Teil 5: Standards & Schweizer Regulatorik». Und wer verstehen möchte, was die KBOB-Empfehlung für Planer und Betreiber konkret bedeutet, findet das im Artikel «KBOB IKT-Sicherheit in der Gebäudeautomation: Was die neue Empfehlung für Planer und Betreiber bedeutet».

Fazit

Patchmanagement in der Gebäudetechnik ist kein Selbstläufer. Die Spannung zwischen Sicherheitsanforderungen und Betriebsstabilität ist real, und sie lässt sich nicht durch eine einfache Regel auflösen. Was sie auflöst, ist ein strukturierter Prozess: Informationen sammeln, Updates bewerten, testen, im richtigen Zeitfenster einspielen, dokumentieren und einen Rückfallplan bereithalten.

Nicht jedes Update muss sofort eingespielt werden. Aber jedes muss bewertet werden, und diese Bewertung muss schriftlich vorliegen. Geräte ohne Support müssen erkannt und mit kompensierenden Massnahmen abgesichert werden, bis ein Ersatz möglich ist. Und der Servicevertrag mit dem Dienstleister muss all das abdecken, sonst bleibt der Patchprozess eine Absichtserklärung ohne Umsetzung.

Die Verantwortung für den sicheren Betrieb liegt beim Betreiber. Das bedeutet nicht, dass er alles selbst tun muss. Es bedeutet, dass er weiss, was getan wird, von wem und nach welchem Prozess.

Sie haben Fragen dazu?

Sie möchten wissen, ob Ihre Gebäudetechnik einen strukturierten Patchprozess hat, oder Sie suchen Unterstützung beim Aufbau eines solchen Prozesses? Wir helfen Ihnen dabei, den Ist-Zustand zu bewerten und einen pragmatischen Weg zu entwickeln, der zu Ihrem Portfolio und Ihren Ressourcen passt. Schreiben Sie uns unter info@wenget.ch oder besuchen Sie wenget.ch.

Quellenverzeichnis

• KBOB Empfehlung «IKT-Sicherheit in der Gebäudeautomation», Version 1.0, 2025 (Patchmanagement, Rollen und Verantwortung der Betreiberorganisation, kompensierende Massnahmen)
• IEC 62443-2-3: Security for industrial automation and control systems, Patch management in the IACS environment (Prozess für Bewertung, Test und Dokumentation von Updates)
• Informationssicherheitsgesetz (ISG), Schweiz: Meldepflicht für Cyberangriffe auf kritische Infrastrukturen, in Kraft seit 1. April 2025
• Bundesamt für Cybersicherheit (BACS), ehemals NCSC: Empfehlungen zum Umgang mit Schwachstellen und Sicherheitsupdates in industriellen Steuerungssystemen
• IKT-Minimalstandard des Bundes (BWL): Grundanforderungen an das Patch- und Schwachstellenmanagement
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet, inkl. BACnet/SC mit TLS und Zertifikaten
• Eigene Projekterfahrung der WENGET GmbH aus GA-Analysen, Sicherheitsbewertungen und Betriebsbegleitung in der Gebäudeautomation