OT-Sicherheit für Energieversorger und Netzbetreiber
Wir prüfen Leitstellen, Umspannwerke und Fernwirkarchitekturen technisch und nicht-disruptiv, bauen die Erkennung dafür auf und bereiten Ihre Teams auf den Ernstfall vor. Für Stadtwerke, Verteilnetzbetreiber und Erzeuger.
Netzleitstellen, Umspannwerke, Fernwirkstationen und Engineering-Systeme bilden das Rückgrat der Energieversorgung und zusammen eine Angriffsfläche, die über Jahrzehnte gewachsen ist. Wir bewerten sie technisch, nicht-disruptiv und mit Blick auf die Nachweise, die Aufsicht und Betreiber tatsächlich brauchen.
Angriffe auf Stromnetze sind dokumentiert, nicht hypothetisch
Im Dezember 2015 fiel bei drei ukrainischen Verteilnetzbetreibern der Strom aus. Angreifer schalteten Leistungsschalter über die Fernwirktechnik, während die Störungsannahme durch einen Telefon-Flood blockiert war. Rund 225.000 Haushalte waren betroffen.
Ein Jahr später folgte Industroyer. Diese Schadsoftware brauchte keinen Bediener mehr: Sie sprach die Fernwirkprotokolle selbst, IEC 60870-5-101 und -104 sowie IEC 61850 und kommunizierte direkt mit Schutz- und Leitgeräten. 2022 tauchte eine überarbeitete Fassung wieder auf, fest auf ein Umspannwerk konfiguriert.
Beides waren Operationen mit erheblichem Aufwand. Der wichtigere Teil der Lage ist ein anderer: Das polnische CERT dokumentierte 2024 eine Reihe von Zugriffen auf kleinere Wasser- und Wärmeversorger, bei denen Steuerungen und Bedienoberflächen direkt aus dem Internet erreichbar waren, teils ohne oder mit voreingestellten Zugangsdaten. Dort wurde keine Schadsoftware entwickelt und keine Lücke ausgenutzt. Es genügte, ein erreichbares Gerät zu finden und einen Sollwert zu ändern.
Das ist der Punkt für einen deutschen Betreiber. Für Industroyer braucht es einen staatlichen Akteur. Für den zweiten Fall genügt eine Suchmaschine für exponierte Geräte. Und die Protokolle sind in beiden Fällen dieselben, die auch in deutschen Umspannwerken und Netzleitstellen laufen.
Sechs Ergebnisse, die in fast jeder Prüfung auftauchen
Das ist der Zustand, auf den solche Angriffe treffen würden. Vorfälle, die uns im Energieumfeld regelmäßig begegnen. Die Ursachen liegen in langen Lebenszyklen, gewachsenen Architekturen und einer über die Zeit komplex gewordenen Dienstleisterstruktur.
Verbindungen, die im Netzplan fehlen
Office-IT und Leitstelle sind direkt oder über Zwischenstationen auf Layer 3 verbunden. Im Plan steht ein kontrollierter Übergang, im Netz liegt ein zweiter daneben.
Fernwartung ohne zweite Stufe
VPN-Zugänge externer Dienstleister, häufig über gemeinsam genutzte Konten. Wer wann was gemacht hat, lässt sich hinterher selten rekonstruieren.
Engineering-Workstations ohne Härtung
Der Rechner, der Steuerungen programmiert und Projektstände hält, läuft ohne Härtung und ohne Monitoring, hat aber Zugriff auf alles, was er programmiert.
Historian und SCADA auf altem Stand
Betriebssysteme bleiben auf dem Stand der Abnahme. Patch-Fenster gibt es, sie reichen aber nicht für den Rückstand aus Jahren.
Segmentierung dokumentiert, nicht durchgesetzt
Zwischen Leitebene und prozessnahen Systemen steht ein Zonenkonzept auf dem Papier. Ob die Regelwerke der Firewalls es abbilden, ist eine andere Frage.
Protokolle laufen unbeobachtet
IEC 60870-5-104 zur Leitstelle, IEC 61850 im Stationsnetz, Modbus und DNP3 in der Verteilung. Übertragen wird alles, ausgewertet nichts. Ein untypischer Befehl fällt niemandem auf, weil niemand hinsieht.
Was wir im Energiesektor gemacht haben
Penetrationstests an Kraftwerks- und Umspannwerksstandorten, Sicherheitsanalysen in Netzleitstellen, Segmentierungsbewertungen und die Absicherung von Fernwirkarchitekturen. Dazu der Aufbau von Security Operations Centern, deren Use Cases IT- und OT-Datenquellen zusammenführen, seit 2019 im laufenden Betrieb.
Ein Beispiel unten auf dieser Seite ist eine Prüfung in einem Kraftwerksumfeld: eine Woche vor Ort, zwei OT-Spezialisten, Befunde mit Reproduktionsschritten statt einer Scanliste.
Vorbereitet wird das im eigenen Labor. Dort steht eine Modellstadt mit echter Fernwirk- und Stationstechnik bis hin zu IEC 61850 mit GOOSE und MMS. Prüfvorgehen, das dort nicht sauber läuft, kommt nicht in eine Kundenanlage.
Wie ein OT-Penetrationstest im Energieumfeld abläuft
Ein Schwachstellenscan, der in einem Büronetz unauffällig bleibt, kann in einer Leitstelle eine Störung auslösen. Verfügbarkeit und Safety stehen vor Vertraulichkeit und danach richtet sich das Vorgehen.
Passive Verfahren zuerst: Architekturanalyse, Konfigurationsprüfung und die Auswertung mitgeschnittener Kommunikation auf IEC 60870-5-104, IEC 61850 mit MMS und GOOSE, Modbus und DNP3. Das liefert den größten Teil der Aussage im laufenden Betrieb. Aktive Tests laufen nur in abgestimmten Fenstern, an Ersatz- oder Laboraufbauten, mit vorher festgelegten Abbruchkriterien.
Am Ende steht eine Karte der realen Kommunikationspfade, ein Zonen- und Conduit-Modell nach IEC 62443-3-2 und eine Befundliste, die zwischen sofort, Wartungsfenster und akzeptablem Restrisiko trennt.
Wie ein OT-SOC für Energieumgebungen aufgebaut wird
Ein IT-SOC sieht die oben beschriebenen Angriffe nicht. Es erkennt Schadsoftware auf einem Server, nicht einen Schaltbefehl zu einer Zeit, zu der niemand schaltet. Solche Ereignisse sind protokollkonform und werden erst vor dem Hintergrund des Normalbetriebs auffällig.
Der Aufbau beginnt deshalb passiv am Spiegelport, ohne Rückkanal in den Prozess und mit einer Baseline des Normalbetriebs.
Wo die Sensorik hängt, entscheidet sich am Protokoll. IEC 60870-5-104 läuft über TCP/IP zwischen Leitstelle und Stationsgateway und ist an der Weitverkehrsstrecke greifbar. IEC 61850 zerfällt in zwei Welten: MMS als Client-Server-Verkehr zwischen Stationsleittechnik und Schutzgeräten und GOOSE als Multicast auf Schicht 2 zwischen den Geräten selbst. GOOSE wird nicht geroutet, deshalb muss ein Sensor dafür in der Station stehen, nicht im Rechenzentrum. Auf dem Prozessbus kommen Sampled Values dazu. In der Verteilung und an kleineren Stationen finden sich Modbus und DNP3. OPC UA kommt dort dazu, wo Leittechnik an übergeordnete Systeme angebunden wird. Es ist damit häufig die eigentliche Brücke zwischen OT und IT.
Die Use Cases entstehen aus dem Taktik- und Technikmodell für industrielle Umgebungen, aus öffentlich analysierter Schadsoftware und aus unserer eigenen Prüfpraxis. Erkannt werden soll der Schaltbefehl zur falschen Zeit, das unbekannte Gerät auf dem Stationsbus, die GOOSE-Nachricht mit unplausibler Sequenznummer und die Verbindung nach draußen, die es nicht geben dürfte.
Wie Training und Notfallübung aussehen
Wer im Ernstfall zwischen Abschaltung und Weiterbetrieb abwägen muss, sollte diese Abwägung nicht zum ersten Mal treffen.
Für Verantwortliche geht es um Verständnis: Aufbau einer Leitstelle, Unterschied zwischen Steuerung und Server, konkrete Forderungen aus IEC 62443. Für technisches Personal um Handwerk: Protokolle lesen, Anomalien erkennen, Erkennungsregeln schreiben, an echten Steuerungen.
Geübt wird an unserer Modellstadt: echte Steuerungen, echte Fernwirk- und Stationsprotokolle und ein Angriff, dessen Wirkung im Modell sichtbar wird, während ein SIEM daneben mitschreibt. Die Szenarien sind aus den oben genannten Vorfällen abgeleitet.
Den Abschluss bildet eine moderierte Notfallübung mit verteilten Rollen. Solche Übungen führen wir auch in bestehenden Security Operations Centern durch, also mit den Teams, die im Ernstfall tatsächlich am Bildschirm sitzen.
Was gefordert ist und was der Nachweis beantworten muss
KRITIS-Verordnung, NIS2, IT-Sicherheitsgesetz und IEC 62443 treffen im Energiesektor zusammen und verlangen Unterschiedliches. Der praktische Konflikt liegt selten im Text der Normen, sondern in ihrer Gleichzeitigkeit: Eine erfüllte Anforderung aus einem Regelwerk beantwortet nicht automatisch die Nachweispflicht aus dem nächsten.
Spätestens in einer Prüfung reicht ein Netzplan als Nachweis nicht aus. Gefragt wird nach der technischen Realität und die lässt sich auf vier Fragen zusammenziehen: Ist die Trennung zwischen IT und OT tatsächlich durchgesetzt oder nur dokumentiert? Sind Fernzugänge nachvollziehbar eingeschränkt? Gibt es Transparenz über die realen Kommunikationspfade? Und sind sicherheitsrelevante Ereignisse in der OT überhaupt erkennbar und auswertbar?
Wie ein Einstieg konkret aussieht
Der übliche Anfang ist eine fokussierte Architektur- und Segmentierungsprüfung.
Erstgespräch, etwa eine Stunde
Wir klären Architekturrahmen, regulatorische Einordnung und zeitliche Randbedingungen. Danach wissen beide Seiten, ob und in welchem Zuschnitt das sinnvoll ist.
Was Sie bereitstellen
Vorhandene Netzpläne und Anlagendokumentation, Ansprechpartner aus OT und IT und die Möglichkeit, an einem Übergang passiv mitzuschneiden. Unvollständige Dokumentation ist kein Hindernis, sie ist der Normalfall.
Fokussierte Prüfung, wenige Wochen
Architektur, Segmentierung und reale Kommunikationspfade an einem definierten Ausschnitt. Verteilte Umgebungen mit vielen Standorten entsprechend länger.
Ergebnis und Priorisierung
Management Summary, dokumentierte Befunde mit technischer Einordnung, Beschreibung der realen Pfade und eine priorisierte Maßnahmenliste. Danach entscheiden Sie, was als Nächstes kommt.
Was Energieversorger uns vorher fragen
Nein. Passive Analyse, Konfigurationsprüfung und Auswertung der Segmentierung laufen im Betrieb. Aktive Tests gehören in ein abgestimmtes Wartungsfenster oder an einen Laboraufbau, mit definierten Abbruchkriterien.
Ja und das ist der Normalfall. Energieumgebungen sind historisch gewachsen. Ein Teil der Arbeit besteht gerade darin, die reale Architektur sichtbar zu machen.
Nicht sofort. Ein Assessment liefert erst das Asset-Inventar und die Topologie, die für Sensorplatzierung und Use-Case-Entwicklung gebraucht werden. Monitoring ohne diese Grundlage erzeugt Rauschen statt Erkennung.
Vor einer regulatorischen Prüfung, nach Architekturänderungen, bei Einführung neuer Fernwartungskonzepte, bei zunehmender IT/OT-Vernetzung, oder wenn Unsicherheit darüber besteht, ob die Segmentierung tatsächlich greift.
IEC 60870-5-104 zwischen Leitstelle und Station, IEC 61850 mit MMS und GOOSE im Stationsnetz, Sampled Values auf dem Prozessbus, dazu Modbus und DNP3 in der Verteilung und OPC UA an den Übergängen zu übergeordneten Systemen. Welche davon bei Ihnen laufen, ergibt sich aus dem Mitschnitt, nicht aus der Dokumentation.
Gerade dann. Die dokumentierten Zugriffe auf kleinere Versorger richteten sich gegen alles, was aus dem Internet erreichbar war. Der Einstieg ist entsprechend klein: eine abgegrenzte Prüfung der Übergänge und der Fernzugänge.
Das hängt an Umfang und Anzahl der Standorte und wir nennen die Größenordnung im Erstgespräch, nicht danach. Eine fokussierte Segmentierungs- und Architekturprüfung an einem Standort liegt deutlich unter dem, was ein verteiltes Projekt über mehrere Umspannwerke erfordert.
