Fernwartung in einem OT-Netz kontrolliert absichern

Eine Wartung soll helfen, ohne die Anlage zu öffnen

Die Klarstrom Werktechnik GmbH betreibt die automatische Reinigungszelle RZ-4. Eine Prozesssteuerung regelt Pumpen, Ventile und die Temperatur des Reinigungsbads. Eine Bedienoberfläche zeigt den Zustand. Eine Engineering-Station hält die freigegebene Steuerungskonfiguration. Ein getrenntes Sicherheitssystem überwacht Schutztür und Not-Halt.

Der Anlagenhersteller soll bei einer Störung aus der Ferne Diagnosewerte lesen und bei Bedarf gemeinsam mit dem Betrieb eine freigegebene Konfigurationsänderung einspielen. Sein erster Vorschlag klingt bequem: ein dauerhaft aktives VPN, ein gemeinsam genutztes Konto und Zugriff auf das gesamte Produktionsnetz.

Damit wäre zwar ein technischer Weg vorhanden. Der Betrieb könnte aber kaum beantworten, wer wann auf welches Ziel zugreift, welche Änderung erlaubt ist und wie sich der Weg bei einer Auffälligkeit kontrolliert schließen lässt.

Die Grundidee dieser Lektion lautet: Du leitest einen OT-Zugriff vom physischen Prozess und den wirklich benötigten Handlungen ab. Erst danach legst du Zonen, Verbindungen, Identitäten und Kontrollen fest.

Nach dieser Lektion kannst du:

• Verfügbarkeit, Informationssicherheit und funktionale Sicherheit sauber unterscheiden,
• Komponenten zu OT-Zonen zusammenfassen und Übergänge begründen,
• einen zeitlich begrenzten Fernwartungsweg mit persönlichen Konten planen,
• notwendige Kommunikationsflüsse von pauschalen Freigaben trennen,
• Überwachung, Änderungen und Reaktionen mit dem Anlagenbetrieb abstimmen.

Du solltest bereits wissen, wie IP-Netze, Firewalls und Benutzerkonten grundsätzlich funktionieren. Die Lektionen “Ein Netzwerk nach Vertrauensgrenzen segmentieren” und “Einen öffentlichen Dienst in einer DMZ absichern” erklären VLANs, Routing und allgemeine Firewall-Regeln. Hier geht es bewusst um die OT-spezifische Entscheidung: Welche Maßnahme trägt den Betrieb, ohne Safety-Anforderungen oder Anlagenverfügbarkeit zu übergehen?

Alle Namen, Adressen und Ereignisse in dieser Lektion sind neu erstellt. Konkrete Freigaben einer realen Anlage leitest du aus ihrer Risikobeurteilung, ihren Herstellerangaben, dem Sicherheitskonzept und den betrieblichen Verfahren ab.

Security, Verfügbarkeit und Safety lösen verschiedene Aufgaben

Operational Technology, kurz OT, überwacht oder verändert physische Prozesse. Dadurch kann eine Sicherheitsmaßnahme nicht nur Datenverkehr beeinflussen. Sie kann auch einen Produktionsablauf verzögern oder eine Bedienhandlung verhindern.

Für RZ-4 sind drei Blickrichtungen wichtig:

• Informationssicherheit begrenzt unberechtigte Zugriffe und Veränderungen. Sie unterstützt außerdem die Nachvollziehbarkeit von Handlungen.
• Anlagenverfügbarkeit beschreibt, ob die benötigte Funktion zum vorgesehenen Zeitpunkt nutzbar ist. Ein ungeplanter Neustart kann hier ebenso schaden wie ein Angriff.
• Funktionale Sicherheit, häufig mit dem englischen Wort Safety bezeichnet, sorgt mit festgelegten Sicherheitsfunktionen dafür, dass ein gefährlicher Zustand vermieden oder in einen definierten sicheren Zustand überführt wird.

Das getrennte Sicherheitssystem der Zelle verarbeitet Schutztür und Not-Halt. Seine Funktion wird nicht durch eine normale Firewall-Regel ersetzt. Umgekehrt macht ein vorhandenes Sicherheitssystem den Fernzugriff nicht automatisch sicher.

NIST SP 800-82 Revision 3 ordnet Safety als übergreifende Priorität ein und warnt davor, IT-Maßnahmen ungeprüft auf OT zu übertragen. Ein Patch, ein aktiver Scan oder eine neue Zugriffskontrolle kann Zeitverhalten und Verfügbarkeit beeinflussen. Deshalb arbeiten OT-Betrieb, Safety-Verantwortliche und Informationssicherheit bei Änderungen zusammen.

Zonen fassen Systeme mit ähnlichen Anforderungen zusammen

IEC 62443-3-2 beschreibt, dass ein industrielles Automatisierungs- und Steuerungssystem in Zonen und Conduits aufgeteilt wird. Eine Zone fasst Komponenten mit gemeinsamen Sicherheitsanforderungen zusammen. Ein Conduit ist ein kontrollierter Kommunikationsweg zwischen Zonen.

Für die Reinigungszelle entstehen vier betriebliche Zonen. Die externe Wartungsumgebung liegt außerhalb der eigenen OT und wird als zusätzliche Quelle betrachtet.

Die Zonenbezeichnung allein schützt noch nichts. Sie hilft zuerst beim Denken: Welcher Übergang ist für den Betrieb wirklich nötig, welche Wirkung hätte eine falsche Nachricht, und welche Kontrolle gehört genau an diese Grenze?

Conduits beginnen mit einer erlaubten Handlung

Für jeden Übergang beschreibst du zuerst die berufliche Handlung. “Hersteller darf ins OT-Netz” ist dafür zu breit. “Benannte Wartungsperson darf im freigegebenen Zeitfenster Diagnosewerte der Zelle RZ-4 über die Engineering-Station lesen” lässt sich dagegen in technische und organisatorische Kontrollen übersetzen.

NIST SP 800-82 empfiehlt, benötigte Datenflüsse zu erfassen und zwischen Segmenten nur ausdrücklich erlaubte Kommunikation zuzulassen. Für die Übung gilt die folgende Matrix. Die Adressen und Ports sind Szenariowerte, keine allgemeine Vorgabe für jedes Produkt.

Nicht aufgeführte Übergänge bleiben gesperrt. Dazu gehören im Szenario:

• ein direkter Weg vom Internet zur Engineering-Station,
• ein direkter Herstellerzugriff auf die Prozesssteuerung,
• ein Fernwartungsweg zur Safety-Zone,
• ein pauschaler Zugriff der Engineering-Station auf andere Produktionszellen,
• ein dauerhaft aktives gemeinsames Herstellerkonto.

Die Matrix ist absichtlich genauer als “Port freigeben”. Sie verbindet den Datenweg mit Identität, Zweck, Zeit und Nachweis. Ein VPN verschlüsselt den Transport, entscheidet aber nicht allein, ob die angemeldete Person die konkrete Handlung ausführen darf.

Identität und Freigabe gelten für jede Sitzung

Das BSI behandelt OT-Fernwartung als Zusammenspiel aus Technik, Organisation und Kontrolle. Für Klarstrom besteht eine Sitzung deshalb aus sechs Schritten:

1. Der Hersteller nennt Person, Anlass, Ziel, gewünschte Handlung und Zeitraum im Wartungsticket.
2. OT-Betrieb und Anlagenverantwortung prüfen den aktuellen Prozesszustand. Eine Schreibänderung erhält eine eigene Freigabe.
3. Der Betrieb aktiviert das persönliche Konto für das begrenzte Zeitfenster. Die Anmeldung verlangt einen zweiten Faktor.
4. Die Wartungsperson arbeitet über Gateway und Sprungserver. Der Betrieb weiß, dass die Sitzung läuft.
5. Nach Abschluss prüft der Betrieb den vereinbarten Anlagenzustand und die dokumentierten Änderungen.
6. Das Konto oder seine Berechtigung wird deaktiviert. Ticket, Protokolle und Ergebnis werden zusammengeführt.

Ein persönliches Konto hilft nur, wenn die Identität nicht für mehrere Personen geteilt wird. Auch technische Dienste erhalten eigene Identitäten. Das Dienstkonto der Prozesssteuerung darf beispielsweise Zustandsdaten schreiben, aber keine Konten verwalten und keine Engineering-Sitzung öffnen.

Monitoring braucht einen bekannten Normalzustand

Überwachung soll eine Handlung ermöglichen. “Alles protokollieren” reicht dafür nicht. Für den Fernzugriff sind mindestens diese Ereignisse relevant:

• erfolgreiche und fehlgeschlagene Anmeldungen mit persönlicher Identität,
• Freigabe, Beginn und Ende der Sitzung,
• Zielsysteme und verwendete Wartungswege,
• Änderungen an Konfiguration, Rollen und Regeln,
• Versuche, ein nicht freigegebenes Ziel zu erreichen,
• Zustand des Fernzugangs nach Ablauf des Zeitfensters.

NIST unterscheidet unter anderem Netzwerk- und Systemüberwachung. Ein passiver Netzwerksensor kann ungewöhnliche Kommunikationsbeziehungen erkennen, ohne die Steuerung aktiv abzufragen. Systemprotokolle können zusätzlich zeigen, welche Identität eine Konfiguration geändert hat. Beide Sichten beantworten unterschiedliche Fragen.

Damit Alarme brauchbar bleiben, braucht das Team eine Baseline, also eine dokumentierte Beschreibung des üblichen Datenverkehrs und Prozessverhaltens. In Klarstrom ist eine RDP-Verbindung vom Sprungserver zur Engineering-Station während eines genehmigten Fensters erwartbar. Dieselbe Verbindung um 03:12 Uhr ohne Ticket ist auffällig. Eine Verbindung vom Sprungserver zur Safety-Zone ist zu jeder Zeit außerhalb des beschriebenen Solls.

Aktive Scans und Agenten sind nicht pauschal ausgeschlossen. Sie werden aber vorab in einer geeigneten Umgebung auf Last, Zeitverhalten und Geräteverträglichkeit geprüft. Wenn diese Prüfung fehlt oder die Steuerung empfindlich reagiert, kann eine passive oder manuelle Kontrolle angemessener sein.

Patches sind geplante Anlagenänderungen

Eine bekannte Schwachstelle einfach offen zu lassen ist keine nachhaltige Strategie. Ein Patch ohne Prüfung kann in OT aber ebenfalls ein neues Betriebs- oder Safety-Risiko einführen. NIST empfiehlt deshalb einen dokumentierten OT-Patchprozess mit Beobachtung neuer Schwachstellen, Tests, geplantem Wartungsfenster und Ersatzmaßnahmen, falls ein Patch verschoben wird.

Für die Engineering-Station der Zelle gilt dieser Ablauf:

1. Betroffenheit klären: Inventar, Softwarestand, Herstellerhinweis und tatsächlich genutzte Funktion vergleichen.
2. Risiko bewerten: mögliche Ausnutzung, vorhandene Zugangswege, Prozesswirkung und Safety-Abhängigkeiten gemeinsam betrachten.
3. Kompatibilität prüfen: Freigabe des Herstellers einholen und Patch in einer geeigneten Offline- oder Testumgebung prüfen. Dazu gehören Regressionstests der Engineering-Funktionen.
4. Änderung planen: Wartungsfenster, verantwortliche Personen, Sicherung, Rückfallplan, erwartete Nichtverfügbarkeit und Abbruchkriterien festhalten.
5. Änderung freigeben und umsetzen: nur im abgestimmten Anlagenzustand und mit nachvollziehbarer Versions- und Konfigurationskontrolle.
6. Wirkung prüfen: Anmeldung, Diagnose, Verbindung zur Prozesssteuerung, Protokollierung und vorgesehene Betriebsfunktion testen. Safety-relevante Abhängigkeiten folgen zusätzlich ihrem Validierungsverfahren.
7. Ergebnis dokumentieren: neue Version, Testergebnisse, Abweichungen und offene Ersatzmaßnahmen festhalten.

Wenn der Patch im Moment nicht tragfähig ist, bleibt die Schwachstelle sichtbar im Risikoregister. Mögliche Ersatzmaßnahmen sind eine engere Zugriffsbegrenzung, ein deaktivierter Dienst, zusätzliche Überwachung oder ein verkürztes Fernwartungsfenster. Welche Maßnahme ausreicht, hängt vom konkreten Risiko ab. “Kann gerade nicht patchen” bedeutet nicht “braucht keine Entscheidung”.

Auf eine Auffälligkeit kontrolliert reagieren

Um 03:12 Uhr meldet die Überwachung eine Anmeldung des persönlichen Herstellerkontos vendor.lenz. Es gibt kein offenes Ticket. Sekunden später versucht der Sprungserver, eine Verbindung zur Safety-Zone aufzubauen. Die Firewall verwirft den Versuch. Der Prozess der Zelle läuft laut Bedienoberfläche weiter.

Die Reaktion beginnt nicht mit einem unkoordinierten Neustart aller Systeme. Ein solcher Eingriff könnte Protokolle verlieren und den Anlagenzustand verändern. Die Reaktion folgt dem vorbereiteten OT-Ablauf:

1. Der Bereitschaftsdienst bestätigt Alarm, Identität, Zeit, Quelle, Ziel und Firewall-Ergebnis.
2. OT-Betrieb und Safety-Verantwortliche werden nach dem Reaktionsplan einbezogen. Der lokale Anlagenzustand wird über vorgesehene Anzeigen geprüft.
3. Der Fernzugang wird am kontrollierten Übergang beendet: Konto sperren, Sitzung am Gateway trennen und den betroffenen Conduit geschlossen halten.
4. Die Zelle wird gemäß betrieblichem Notfallplan weiterbetrieben oder in den dafür vorgesehenen sicheren Zustand überführt. Diese Entscheidung folgt dem Prozesszustand und den lokalen Verantwortlichkeiten.
5. Relevante Protokolle, Ticketstand, Gateway- und Firewall-Ereignisse werden gegen Veränderung gesichert. Danach wird der Umfang untersucht.
6. Wiederanlauf und erneute Fernzugangsfreigabe erfolgen erst nach Ursachenklärung, Prüfung und dokumentierter Entscheidung.

NIST weist darauf hin, dass Eindämmung in OT selbst Prozessunterbrechungen auslösen kann. Die Wirkung einer Trennung muss deshalb vorab verstanden und im Reaktionsplan festgelegt sein. Im Szenario ist das Gateway der vorgesehene Abschaltpunkt für die externe Sitzung. Der Safety-Pfad der Zelle bleibt davon unberührt.

Transfer: Eine zweite Zelle anbinden

Was du aus dem Szenario mitnehmen kannst

• OT-Security unterstützt sicheren und verlässlichen Betrieb, ersetzt aber keine funktionale Sicherheitsfunktion.
• Zonen fassen Komponenten mit gemeinsamen Anforderungen zusammen. Conduits beschreiben die ausdrücklich benötigten Übergänge.
• Ein tragfähiger Fernzugriff verbindet persönliche Identität, Mehrfaktor-Authentisierung, Freigabe, Zeitfenster, Zielbegrenzung und Nachweis.
• Monitoring braucht einen dokumentierten Normalzustand und eine geplante Reaktion. Aktive Werkzeuge werden vor ihrem OT-Einsatz auf Auswirkungen geprüft.
• Patches und Konfigurationsänderungen sind kontrollierte Anlagenänderungen mit Risikoentscheidung, Test, Rückfall und Wirksamkeitsprüfung.
• Eine Eindämmung darf den physischen Prozess nicht ausblenden. Betrieb, Safety und Informationssicherheit handeln nach einem vorbereiteten Plan zusammen.

Quellenbasis und Abgrenzung

Die Zuordnung zu Lernfeld 11d folgt dem KMK-Rahmenlehrplan: Schutzbedarf und Risiken ermitteln, Maßnahmen planen und umsetzen, das erreichte relative Sicherheitsniveau prüfen und dokumentieren. Die Fachinformatikerausbildungsverordnung trägt den Bezug zum Errichten, Ändern, Prüfen und Betreiben vernetzter Systeme. Der Prüfungskatalog stützt die Themenbreite, garantiert aber kein Thema in einem konkreten Prüfungstermin.

IEC 62443-3-2 trägt das Modell aus Zonen und Conduits. NIST SP 800-82 Revision 3 trägt die OT-spezifischen Aussagen zu Safety und Verfügbarkeit, minimalen Datenflüssen, Fernzugriff, Patchplanung, Überwachung und Reaktion. Der BSI-Baustein IND.3.2 konkretisiert die organisatorische und technische Kontrolle industrieller Fernwartung. Der BSI-Baustein IND.2.7 stützt die getrennte Betrachtung von Safety-Systemen.

Diese Lektion ist keine vollständige Risikobeurteilung einer realen Anlage, keine Produktkonfiguration und keine Safety-Validierung. Sie vertieft auch nicht die allgemeine VLAN-, DMZ- oder Firewall-Technik. Ihr Schwerpunkt ist die OT-spezifische Ableitung eines kontrollierten Fernwartungswegs aus Prozess, Verfügbarkeit und Safety-Abgrenzung.

Belegmatrix