Warum OT-Angriffe gültige Befehle senden, und wie man Mensch und Skript unterscheidet

Wer sich einen Angriff auf ein Kraftwerk vorstellt, denkt an einen Exploit: fehlerhafte Pakete, eine abgestürzte Steuerung, einen Bildschirm voller Code. Die Angriffe, die in Leitsystemen wirklich Schaden anrichten, sehen meist ganz anders aus. Sie senden Befehle, die die Steuerung annehmen soll, von einem Rechner, dem sie vertrauen soll.

Die Steuerung tut, was man ihr sagt

Eine SPS ist dazu da, Befehle auszuführen: dieses Ventil öffnen, jenen Sollwert ändern, diesen Leistungsschalter auslösen. Viele Industrieprotokolle wurden für geschlossene Netze entworfen und kennen keine Authentifizierung. Klassisches Modbus etwa nimmt einen Schreibbefehl von jedem Gerät an, das die Steuerung erreicht. Auch wo neuere Protokolle Sicherheitsfunktionen mitbringen, vertraut die Steuerung weiterhin dem HMI-Server und der Engineering-Station, denn dort arbeiten die Bediener.

Ein Angreifer braucht also keine Schwachstelle in der Steuerung. Es reicht, auf einem Rechner Fuß zu fassen, dem die Steuerung vertraut. Von dort ist jeder Befehl gültig: richtiges Protokoll, richtiger Funktionscode, richtiges Register, richtige Absenderadresse.

Wie das in der Praxis aussieht

Das am besten dokumentierte öffentliche Beispiel ist der Angriff auf Stromverteiler in der Ukraine im Dezember 2015. Die Angreifer waren monatelang in den Netzen der Unternehmen, und am Tag des Angriffs öffneten sie Leistungsschalter mit der Leitsoftware und den Fernzugängen der Betreiber selbst. Kunden waren stundenlang ohne Strom. Für die Umspannwerke unterschieden sich die Befehle nicht von denen eines Bedieners.

Im Kleinen wiederholt sich das Muster: Schadsoftware auf einem HMI-Server, die Sollwerte schreibt; eine Fernwartungssitzung, hinter der nicht der Hersteller sitzt; ein Skript eines Integrators, das nach Projektende weiterläuft. Im ICS-Sicherheitskurs zeichnet eine Laborübung Modbus-Verkehr auf und schreibt danach von einem anderen Rechner im Netz auf eine echte Steuerung. Die Teilnehmer sind meist überrascht, wie wenig dazu nötig ist.

Warum die üblichen Schutzmaßnahmen es übersehen

Firewalls lassen den HMI-Server mit den Steuerungen sprechen. Genau dafür sind sie konfiguriert.
Virenschutz fehlt auf HMI-Servern oft, ist veraltet oder durch die Supportbedingungen des Herstellers eingeschränkt. Ein Skript, das die Funktionen der HMI selbst nutzt, ist ohnehin keine Schadsoftware im klassischen Sinn.
Netzbasierte Angriffserkennung sieht einen gültigen Befehl von der üblichen Quelle. Sie kann ein neues Gerät, einen Portscan, ein Firmware-Update oder einen ungewöhnlichen Funktionscode melden, und sie gehört dazu. Ein einzelner Sollwert vom HMI-Server sieht trotzdem aus wie normaler Schichtbetrieb.
Protokolle halten fest, dass die HMI den Befehl gesendet hat. Wer oder was dahinterstand, halten sie nicht fest.

Die eigentliche Frage: Wer sitzt an der Bedienstation?

Wenn der Befehl selbst gültig ist, rückt die Frage, die Bedienung von Angriff trennt, einen Schritt zurück. Hat ein Bediener diesen Befehl an der HMI gegeben, oder hat eine Software ihn in seinem Namen erzeugt? Ein Mensch an der Bedienstation verhält sich anders als ein Skript. Allgemein gilt:

Ein Mensch handelt über die Oberfläche. Er öffnet ein Bild, wählt ein Objekt und bestätigt. Ein Skript kann den Befehl senden, ohne die Oberfläche zu berühren.
Ein Mensch arbeitet in menschlichem Tempo und Rhythmus. Ein Skript kann viele Befehle in Sekundenbruchteilen senden, oder um drei Uhr nachts, wenn niemand angemeldet ist.
Die Befehle eines Menschen passen zum Prozesszustand und zur Arbeit der Schicht. Die eines Skripts hat der Angreifer vorher festgelegt.

Kein einzelnes Merkmal ist für sich beweiskräftig, und ein Angreifer, der sie kennt, wird versuchen, sie nachzuahmen. Deshalb gehört die Prüfung dorthin, wo der Befehl entsteht, auf den HMI-Server, und sie muss mehrere Merkmale gemeinsam bewerten statt sich auf eine Regel zu verlassen.

Warum gerade dort? Im Netz ist der Befehl bereits ein fertiges Paket; woher er kam, ist nicht mehr zu erkennen. Auf dem HMI-Server dagegen ist der Zusammenhang noch sichtbar: welche Anwendung den Befehl erzeugt hat, was an der Oberfläche vorher geschah und ob das zum laufenden Betrieb passt.

Der Ansatz von SPARTA

SPARTA (SCADA Protection And Real-Time Alert) ist das Modul, das ICS Security, das von mir gegründete Unternehmen, für dieses Problem entwickelt hat. Es läuft als Softwaremodul auf dem HMI-Server und verbindet Angriffsverhinderung (IPS) und Angriffserkennung (IDS) mit Algorithmen und künstlicher Intelligenz. Seine zentrale Aufgabe ist, mit hoher Sicherheit zu bestätigen, dass eine Eingabe von einem menschlichen Bediener stammt und nicht von Schadsoftware.

Aus seiner Position ergeben sich weitere Eigenschaften:

Keine neuen Komponenten im Leitnetz, und die Herstellergarantie bleibt erhalten
Überwachung der Komponenten im Netz: SPS, RTU, HMI-Server und -Clients
Mehrschichtiger Schutz gegen Angriffe von außen und von innen
Der HMI-Server selbst wird daran gehindert, andere Komponenten im Netz anzugreifen
Zusammenarbeit mit GRAPHENE, unserer passiven Angriffserkennung im Netz, für eine stärkere Erkennung
Kompatibel mit NERC CIP und NIST sowie mit verschiedenen HMI-Plattformen und Steuerungen

SPARTA ist durch das US-Patent 11,621,972 B2 geschützt, erteilt am 4. April 2023; Erfinder sind Ilan Shaya, Shimon Zigdon und Avishay Savir. Der Hafen Ashdod hat SPARTA zum Schutz seines Leitsystems ausgewählt, wie TheMarker 2021 berichtete.

Was in jedem Fall hilft

Ob SPARTA für eine Anlage passt oder nicht, das Prinzip bleibt: Es soll schwer sein, den Prozess zu verändern, wenn nicht ein Mensch an der richtigen Bedienstation sitzt.

Festlegen, welche Rechner überhaupt auf Steuerungen schreiben dürfen; Beobachter erhalten reine Lese-Clients.
Die Engineering-Station getrennt halten und nur bei Bedarf verbinden.
Persönliche Bedienerkonten statt eines gemeinsamen Passworts am Monitor.
Die erwarteten Bedienhandlungen jeder HMI als Whitelist festlegen und bei Abweichungen alarmieren.
Grenzwerte in die Steuerungslogik einbauen, damit ein extremer Sollwert abgewiesen wird, und das sicherheitsgerichtete System von der Leittechnik unabhängig halten.
Das Netz passiv überwachen, damit der Scan oder das neue Gerät vor dem Befehl auffällt.
Üben, was Bediener tun, wenn der Bildschirm etwas zeigt, das sie nicht ausgelöst haben.

Der Vollständigkeit halber: SPARTA ist meine Erfindung. Die Sicherheitsarchitekturen, die ich plane, sind so beschrieben, dass jeder qualifizierte Anbieter darauf bieten kann. Von Betreibern kritischer Anlagen in Deutschland verlangt das BSIG ohnehin Systeme zur Angriffserkennung; mehr dazu unter OT-Sicherheit für KRITIS-Betreiber.