Security-Analyse der Leittechnik im Bestand

Wer ein Rechenzentrum betreibt, denkt bei Sicherheit zuerst an Firewalls, Zugangskontrolle und IT-Systeme. Die Gebäude- und Energieleittechnik gerät dabei oft in den Hintergrund, obwohl sie Kühlung, Stromversorgung und Klimatisierung steuert und damit unmittelbar die Verfügbarkeit des Rechenzentrums beeinflusst. In unserer Erfahrung ist die OT-Sicherheit in bestehenden Rechenzentren selten systematisch bewertet worden. Viele Anlagen sind über Jahre gewachsen, Zugänge wurden eingerichtet und nie wieder entfernt, Firmware wurde nicht aktualisiert, und Netzwerke wurden nie segmentiert.

Dieser sechste Teil der Serie «Rechenzentrum im Bestand: Analyse, Optimierung, Sicherheit» beschreibt, wie wir bei einer Security-Analyse der Leittechnik vorgehen. Am Anfang steht immer ein vollständiges Inventar. Darauf folgen das Zonen- und Conduit-Modell nach IEC 62443, eine strukturierte Gap-Analyse und ein Massnahmenplan mit klaren Prioritäten. Erst dann werden einzelne Komponenten ausgetauscht oder Konfigurationen geändert. Dieses Vorgehen schützt den laufenden Betrieb und liefert der Revision eine nachvollziehbare Grundlage.

Warum die Leittechnik ein eigenes Sicherheitsthema ist

Gebäudeautomation und Energieleittechnik in Rechenzentren sind keine klassischen IT-Systeme, aber sie sind längst mit IP-Netzwerken verbunden. Automationsstationen, Managementsysteme, Energiezähler und Kühlregler kommunizieren über Ethernet, oft über dasselbe Netz wie die IT-Infrastruktur. Gleichzeitig stammen viele dieser Geräte aus einer Zeit, in der Netzwerksicherheit für OT-Systeme kein Thema war. Standardpasswörter wurden nie geändert, Firmware wurde seit Jahren nicht aktualisiert, und Fernzugänge wurden für Wartungszwecke eingerichtet, ohne dass jemand geprüft hat, ob sie noch gebraucht werden.

Das Risiko ist real. Ein Angreifer, der Zugang zu einer Automationsstation erhält, kann Sollwerte verändern, Alarme unterdrücken oder Kühlsysteme ausser Betrieb setzen. Das muss kein gezielter Angriff auf das Rechenzentrum sein. Oft reicht eine schlecht gesicherte Verbindung zu einem Lieferanten, der seinerseits kompromittiert wurde. Wir behandeln dieses Thema im siebten Teil der Serie, «Fernzugänge und Lieferanten: das unterschätzte Einfallstor», ausführlicher.

Die IEC 62443 ist der international anerkannte Rahmen für die Sicherheit industrieller Automatisierungssysteme und Steuerungssysteme. Sie gilt auch für die Gebäudeautomation und liefert die Begriffe und Methoden, die wir in der Analyse verwenden. Das Nationale Zentrum für Cybersicherheit (NCSC) der Schweiz empfiehlt für Betreiber kritischer Infrastrukturen, zu denen Rechenzentren ab einer bestimmten Grösse und Bedeutung zählen können, eine strukturierte Risikobeurteilung und Segmentierung der OT-Systeme.

Schritt 1: Vollständiges Inventar aller Geräte und Verbindungen

Ohne vollständiges Inventar ist jede Security-Analyse wertlos. Wir beginnen deshalb immer mit einer systematischen Bestandsaufnahme aller Geräte, die zur Gebäude- und Energieleittechnik gehören. Das umfasst Managementsysteme und Bedienoberflächen, Automationsstationen und Feldgeräte mit IP-Anschluss, Energiezähler und Unterverteilungen mit Kommunikationsmodul, Kühlregler, USV-Systeme mit Netzwerkkarte und alle Gateways zwischen verschiedenen Protokollen oder Netzsegmenten.

Für jedes Gerät erfassen wir Hersteller, Modell, Firmware-Version, IP-Adresse, MAC-Adresse, Protokoll und Kommunikationspartner. Wo vorhanden, ziehen wir Bestandsdokumentationen, Netzwerkpläne und Konfigurationsdateien bei. In der Praxis stimmen diese Unterlagen selten vollständig mit dem überein, was tatsächlich im Netz aktiv ist.

Wichtig ist dabei die Methode des Scannens. Im laufenden Betrieb eines Rechenzentrums ist aktives Netzwerkscanning mit aggressiven Werkzeugen gefährlich. Ältere OT-Geräte können auf unerwartete Anfragen mit Absturz oder Neustart reagieren, was im schlimmsten Fall eine Kühlanlage oder USV kurzzeitig ausser Betrieb setzt. Wir setzen deshalb auf passives Scanning: Wir hören den Netzwerkverkehr mit, ohne selbst Anfragen zu senden, und ergänzen die Ergebnisse mit manuellen Abfragen an bekannte Geräte über deren native Protokolle. Dieses Vorgehen ist langsamer, aber betriebssicher.

Das Ergebnis ist ein Inventar, das als Grundlage für alle weiteren Schritte dient. Es zeigt auch sofort erste Auffälligkeiten: Geräte, die niemand mehr kennt, IP-Adressen ohne Dokumentation oder Verbindungen, die in keinem Netzwerkplan eingezeichnet sind.

Schritt 2: Zonen- und Conduit-Modell nach IEC 62443

Sobald das Inventar vollständig ist, strukturieren wir die Anlage nach dem Zonen- und Conduit-Modell der IEC 62443-3-2. Eine Zone ist eine Gruppe von Geräten und Systemen mit ähnlichem Schutzbedarf und ähnlichen Kommunikationsanforderungen. Ein Conduit ist ein kontrollierter Kommunikationskanal zwischen zwei Zonen.

Für ein Rechenzentrum ergibt sich typischerweise eine Zoneneinteilung entlang der Leittechnik-Ebenen. Die Feldebene mit Sensoren, Aktoren und einfachen Reglern bildet eine Zone. Die Automationsebene mit Automationsstationen und Feldbus-Gateways bildet eine weitere. Die Managementebene mit dem Gebäudemanagementsystem und den Bedienoberflächen bildet eine dritte Zone. Hinzu kommen Zonen für externe Zugänge, für die Verbindung zur IT-Infrastruktur und für Energiemesssysteme, wenn diese separat betrieben werden.

Für jede Zone legt IEC 62443-3-2 einen Security Level Target fest, kurz SL-T. Dieser beschreibt, gegen welche Angreiferklasse die Zone geschützt sein soll. Für die Managementebene eines Rechenzentrums ist in der Regel ein höherer Security Level angemessen als für einfache Feldgeräte ohne Netzwerkverbindung. Die Norm IEC 62443-3-3 definiert die System Requirements, die für jeden Security Level erfüllt sein müssen.

Die Conduits zwischen den Zonen werden dokumentiert und bewertet. Jeder Conduit sollte kontrolliert sein, das heisst, der Datenfluss sollte auf das Notwendige beschränkt und überwacht werden. In der Praxis finden wir häufig flache Netze ohne Segmentierung: Alle Geräte der Leittechnik hängen im selben IP-Subnetz, manchmal sogar im selben Netz wie die IT-Systeme. Ein Angreifer, der einen Zugang findet, kann sich in diesem Fall ungehindert bewegen.

Das Zonen- und Conduit-Modell ist kein theoretisches Konstrukt. Es ist die Grundlage für alle technischen Massnahmen, die danach folgen. Ohne dieses Modell weiss man nicht, welche Segmentierung sinnvoll ist, welche Firewall-Regeln gebraucht werden und wo Monitoring ansetzen soll.

Schritt 3: Gap-Analyse gegen den Ziel-Security-Level

Mit dem Inventar und dem Zonen-Modell in der Hand führen wir die eigentliche Gap-Analyse durch. Wir vergleichen den aktuellen Zustand jeder Zone mit dem Ziel-Security-Level, den wir gemeinsam mit dem Betreiber festgelegt haben. Die IEC 62443-3-3 liefert dafür einen strukturierten Anforderungskatalog, der sieben grundlegende Anforderungen definiert: Identifikation und Authentifizierung, Nutzungskontrolle, Systemintegrität, Vertraulichkeit der Daten, eingeschränkter Datenfluss, zeitnahe Reaktion auf Ereignisse und Ressourcenverfügbarkeit.

In der Praxis zeigen sich dabei immer wieder dieselben Schwachstellen. Wir beschreiben die häufigsten, ohne Anspruch auf Vollständigkeit.

Standardpasswörter und fehlende Authentifizierung

Viele Automationsstationen und Managementsysteme werden mit Standardpasswörtern ausgeliefert und nie geändert. In einigen Fällen gibt es gar keine Authentifizierung: Wer die IP-Adresse kennt, hat vollen Zugriff. Das ist in Systemen, die vor zehn oder fünfzehn Jahren installiert wurden, keine Ausnahme, sondern die Regel.

Veraltete Firmware ohne Sicherheits-Patches

Firmware-Updates für OT-Geräte werden im Betrieb oft nicht eingespielt, weil der Aufwand hoch ist und das Risiko eines Ausfalls während des Updates gescheut wird. Das Ergebnis sind Geräte mit bekannten Schwachstellen, für die Patches längst verfügbar wären. In der Gap-Analyse erfassen wir für jedes Gerät die aktuelle Firmware-Version und prüfen, ob bekannte Sicherheitslücken dokumentiert sind.

Flache Netze ohne Segmentierung

Wie oben beschrieben, fehlt in vielen bestehenden Anlagen jede Netzwerksegmentierung. Leittechnik und IT teilen sich ein Netz, oder alle Leittechnik-Geräte sind in einem einzigen Subnetz zusammengefasst. Das widerspricht dem Conduit-Prinzip der IEC 62443 und erleichtert laterale Bewegungen im Netz nach einem ersten Zugang.

Nicht dokumentierte und nicht kontrollierte Fernzugänge

Fernzugänge für Lieferanten und Wartungsdienstleister sind in Rechenzentren verbreitet und oft notwendig. Problematisch wird es, wenn diese Zugänge dauerhaft offen sind, nicht protokolliert werden und niemand mehr weiss, wer Zugang hat. Wir erfassen alle Fernzugänge im Inventar und bewerten, ob sie dem Prinzip der minimalen Rechte entsprechen und ob sie überwacht werden.

Fehlende Protokollierung und kein Monitoring

Viele Leittechnik-Systeme erzeugen keine Logs, die für eine Sicherheitsanalyse nutzbar wären. Oder die Logs werden erzeugt, aber nicht zentral gesammelt und nicht ausgewertet. Ein Angriff oder eine Fehlkonfiguration bleibt dann unbemerkt, bis er sich in einem Betriebsproblem äussert.

Die Gap-Analyse mündet in einer strukturierten Liste von Abweichungen, geordnet nach Zone und Anforderungskategorie. Diese Liste ist die Grundlage für den Massnahmenplan.

Schritt 4: Massnahmenplan mit Prioritäten

Ein Massnahmenplan, der alle Lücken gleichzeitig schliessen will, ist in der Praxis nicht umsetzbar. Wir priorisieren deshalb nach zwei Kriterien: dem Risiko, das eine Lücke darstellt, und dem Aufwand, sie zu schliessen. Massnahmen mit hohem Risiko und geringem Aufwand stehen ganz oben.

Typische Sofortmassnahmen sind das Ändern von Standardpasswörtern, das Deaktivieren nicht mehr benötigter Fernzugänge und das Einrichten einer minimalen Netzwerktrennung zwischen Leittechnik und IT. Diese Massnahmen sind oft ohne grossen Eingriff in die Anlage möglich und reduzieren das Risiko sofort.

Mittelfristige Massnahmen umfassen die Firmware-Aktualisierung der Geräte, die Einführung einer zentralen Protokollierung und die Umsetzung des vollständigen Zonen- und Conduit-Modells mit entsprechender Netzwerksegmentierung. Hier ist eine sorgfältige Planung notwendig, weil Eingriffe in die Netzwerkstruktur den Betrieb beeinflussen können.

Langfristige Massnahmen betreffen Geräte, die grundsätzlich nicht mehr sicher betrieben werden können, weil der Hersteller keine Patches mehr liefert oder weil die Hardware keine modernen Sicherheitsfunktionen unterstützt. Für diese Geräte ist ein geordneter Ersatz zu planen. Wir empfehlen, diesen Ersatz mit ohnehin geplanten Sanierungen zu verbinden, um den Betriebsunterbruch zu minimieren.

Der Massnahmenplan enthält für jede Massnahme eine klare Zuständigkeit, einen realistischen Zeitrahmen und ein Erfolgskriterium. Nur so kann die Revision nachvollziehen, was umgesetzt wurde und was noch offen ist.

BACnet/SC als Baustein der sicheren Kommunikation

Ein konkretes Beispiel für eine technische Massnahme, die aus einer solchen Analyse folgen kann, ist die Migration auf BACnet/SC. Das klassische BACnet/IP überträgt Daten ohne Verschlüsselung und ohne gegenseitige Authentifizierung. Jedes Gerät im selben Netz kann Nachrichten mitlesen oder im schlimmsten Fall einschleusen. BACnet/SC, das in der SN EN ISO 16484-5 (SIA 386.155) beschrieben ist, fügt eine TLS-basierte Transportverschlüsselung und eine zertifikatsbasierte Authentifizierung hinzu.

Wir haben BACnet/SC als Sicherheitsmassnahme für die Kühlungsleittechnik in Teil 2 der Serie «Leittechnik im Rechenzentrum» ausführlich beschrieben, im Beitrag «BACnet/SC als Schutz für die Kühlung». Dort erläutern wir auch, was für eine Migration technisch notwendig ist und welche Geräte BACnet/SC heute unterstützen. Wir verweisen an dieser Stelle darauf, um Doppelspurigkeiten zu vermeiden.

Wichtig im Kontext der Security-Analyse ist: BACnet/SC ist kein Allheilmittel. Es sichert die Kommunikation zwischen BACnet-Geräten, ersetzt aber keine Netzwerksegmentierung und keine Zugangskontrolle. Es ist ein Baustein im Gesamtkonzept, nicht das Gesamtkonzept selbst.

Rollen und Verantwortung in der Analyse

Eine Security-Analyse der Leittechnik berührt mehrere Verantwortungsbereiche gleichzeitig. Die OT-Sicherheit liegt in der Schnittmenge zwischen Gebäudetechnik, IT und Betrieb. In der Praxis führt das oft zu Unklarheiten: Die IT fühlt sich nicht zuständig für Automationsstationen, die Gebäudetechnik hat keinen Zugang zu den Netzwerkinfrastrukturen, und der Betrieb weiss nicht, wer welche Entscheidungen treffen darf.

Wir empfehlen, zu Beginn der Analyse eine klare Rollenverteilung festzulegen. Wer ist für die OT-Systeme verantwortlich? Wer hat Zugang zu den Netzwerkgeräten? Wer entscheidet über Firmware-Updates und Konfigurationsänderungen? Wer ist Ansprechpartner für externe Dienstleister? Diese Fragen sind keine technischen Fragen, aber ohne ihre Beantwortung kommt die Analyse nicht voran.

Das NCSC Schweiz empfiehlt für Betreiber von Systemen mit erhöhtem Schutzbedarf, Verantwortlichkeiten für OT-Sicherheit explizit zu benennen und in der Organisation zu verankern. Die Revision erwartet zunehmend, dass nicht nur technische Massnahmen dokumentiert sind, sondern auch die organisatorischen Strukturen dahinter.

Die KBOB-Sicht auf IKT-Sicherheit in der Gebäudeautomation und die regulatorischen Anforderungen für Schweizer Betreiber haben wir in unserem Beitrag «KBOB IKT-Sicherheit in der Gebäudeautomation: Was die neue Empfehlung für Planer und Betreiber bedeutet» ausführlich behandelt. Die Norm IEC 62443 selbst, ihre Struktur und ihre Anforderungen erklären wir in einem separaten Beitrag ausserhalb dieser Serie.

Was die Analyse nicht leistet und was danach kommt

Eine Security-Analyse der Leittechnik ist kein Penetrationstest. Wir suchen nicht aktiv nach Wegen, in Systeme einzudringen, und wir führen keine Angriffssimulationen durch. Das wäre im laufenden Betrieb eines Rechenzentrums unverantwortlich. Was wir liefern, ist eine strukturierte Bestandsaufnahme der Schwachstellen auf Basis von Inventar, Konfigurationsprüfung und Netzwerkanalyse, ergänzt durch die Bewertung nach IEC 62443.

Die Analyse ist auch kein einmaliges Ereignis. Systeme ändern sich, neue Geräte kommen hinzu, Firmware wird aktualisiert oder eben nicht, und neue Schwachstellen werden bekannt. Wir empfehlen, das Inventar laufend zu pflegen und die Gap-Analyse in regelmässigen Abständen zu wiederholen, mindestens wenn grössere Änderungen an der Anlage vorgenommen werden.

Der nächste Schritt nach der Analyse ist die Umsetzung des Massnahmenplans. Dabei ist die Reihenfolge entscheidend: Zuerst die organisatorischen Grundlagen klären, dann die Netzwerksegmentierung umsetzen, dann die Geräte-Konfigurationen anpassen und zuletzt die Firmware aktualisieren oder Geräte ersetzen. Wer mit dem Geräteaustausch beginnt, ohne das Netz zu segmentieren, hat am Ende neue Geräte in einer unsicheren Umgebung.

Der siebte und letzte Teil dieser Serie, «Fernzugänge und Lieferanten: das unterschätzte Einfallstor», greift einen Aspekt auf, der in der Gap-Analyse regelmässig als kritisch bewertet wird, aber oft unterschätzt wird: die Zugänge externer Dienstleister zur Leittechnik.

Der rote Faden zu unseren Fachbeiträgen

Dieser Beitrag ist Teil 6 der Serie «Rechenzentrum im Bestand: Analyse, Optimierung, Sicherheit». Den Einstieg in die Bestandsanalyse bietet Teil 1, «Leittechnik-Check im bestehenden Rechenzentrum». Wie Trenddaten Hinweise auf Schwachstellen in der Kühlung liefern, zeigt Teil 2, «Was die Trenddaten über Ihre Kühlung verraten». Die Redundanzprüfung behandelt Teil 4, «Ist N+1 noch N+1? Redundanz im Bestand prüfen», und das Alarmmanagement Teil 5, «Alarmflut im Leitstand: Alarmmanagement im Rechenzentrum». Den Abschluss der Serie bildet Teil 7, «Fernzugänge und Lieferanten: das unterschätzte Einfallstor».

Aus der parallelen Serie «Leittechnik im Rechenzentrum» ist besonders Teil 2, «BACnet/SC als Schutz für die Kühlung», relevant, weil er die technische Umsetzung von BACnet/SC als Sicherheitsmassnahme beschreibt. Teil 5, «BMS und EPMS trennen und trotzdem verbinden», behandelt die Systemarchitektur, die auch für die Zoneneinteilung nach IEC 62443 relevant ist.

Wer die regulatorische Einordnung sucht, findet sie in unserem Beitrag «KBOB IKT-Sicherheit in der Gebäudeautomation: Was die neue Empfehlung für Planer und Betreiber bedeutet». Die Grundlagen der BACnet-Sicherheit und Migration beschreibt die Serie «BACnet/SC: Sicherheit & Migration», insbesondere Teil 5, «Standards & Schweizer Regulatorik».

Fazit

Die Security-Analyse der Gebäude- und Energieleittechnik in einem bestehenden Rechenzentrum folgt einem klaren Ablauf: Inventar, Zonen- und Conduit-Modell, Gap-Analyse, Massnahmenplan. Dieser Ablauf ist nicht beliebig, sondern notwendig. Wer mit dem Geräteaustausch beginnt, ohne das Gesamtbild zu kennen, löst einzelne Probleme und übersieht andere. Wer aktiv scannt, ohne die Betriebssicherheit zu bedenken, riskiert genau das, was er verhindern will.

In unserer Erfahrung ist der grösste Gewinn einer solchen Analyse nicht die Liste der Schwachstellen, sondern das vollständige Inventar und das Zonen-Modell. Beides fehlt in den meisten bestehenden Anlagen, und beides ist die Grundlage für jeden weiteren Schritt, ob technisch oder organisatorisch. Die Revision bekommt damit erstmals eine nachvollziehbare Grundlage, und der Betrieb weiss, was er hat und wie es zusammenhängt.

Sie haben Fragen dazu?

Sie möchten wissen, wie eine Security-Analyse der Leittechnik in Ihrem Rechenzentrum konkret aussehen würde? Wir besprechen das gerne mit Ihnen und zeigen, welche Schritte in Ihrer Situation sinnvoll sind. Schreiben Sie uns unter info@wenget.ch oder besuchen Sie wenget.ch.

Quellenverzeichnis

• IEC 62443-3-2: Security risk assessment for system design (Zonen- und Conduit-Modell, Security Level Target)
• IEC 62443-3-3: System security requirements and security levels (Systemanforderungen nach Security Level)
• NCSC Schweiz: Empfehlungen zur OT-Sicherheit und zum Schutz kritischer Infrastrukturen (ncsc.admin.ch)
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet, inkl. BACnet/SC (Anhang)
• KBOB Empfehlung IKT-Sicherheit in der Gebäudeautomation, Version 1.0, Juli 2025
• Eigene Projekterfahrung der WENGET GmbH aus Leittechnik-Analysen, Security-Assessments und Betriebsbegleitung in Rechenzentren