Gehackte Lichtsignalanlage – reine Fiktion?

Betriebstechnik – oder Neudeutsch Operational Technology, kurz OT – begleitet uns tagtäglich. Sie steuert physikalische Vorgänge wie das Pumpensystem einer städtischen Wasserversorgung, die Raumtemperatursteuerung in der Wohnung oder die Steuerung einer Lichtsignalanlage im Strassenverkehr. Meistens wird dazu eine speicherprogrammierbare Steuerung, SPS genannt, eingesetzt. Sie überwacht Prozesse und Zustände und steuert diese entsprechend den Vorgaben.

Die Lebenszyklen solcher Steuerungsgeräte sind wesentlich länger als bei Geräten in der IT oder der Heimelektronik. Je nach Einsatzgebiet betragen sie 15 Jahre oder mehr. Wegen dieser langen Lebenszyklen hat sich die Programmierung der Geräte im Kern nicht verändert. Genauer gesagt: Sie darf sich gar nicht ändern; denn Geräte, die vor zehn Jahren in Betrieb genommen wurden und Geräte, die jetzt in Betrieb genommen werden, müssen mit derselben Software konfiguriert und programmiert werden können. 

Als Standard für die Programmierung einer SPS hat sich die Norm IEC 61131 durchgesetzt. Die unterstützten Programmiersprachen sind:

Welche Sprache eingesetzt wird, hängt von mehreren Faktoren ab. In Nordamerika programmiert man grösstenteils in Ladder Diagram, während man hier in Europa vermehrt FBD in Kombination mit strukturiertem Text oder SFC verwendet. Anweisungsliste wird kaum noch eingesetzt. Dafür halten Programmiersprachen wie Python oder Blockly Einzug in neuere SPS Modelle.

In den standardisierten Programmiersprachen stellen die SPS-Hersteller oder ‑Systemintegratoren Bausteine und Bibliotheken zur Verfügung, um beispielsweise die Kommunikation zwischen Geräten zu ermöglichen oder die Anzeige auf einer Bedienoberfläche darzustellen.

Fehlende Security by Design

Die fünf Programmiersprachen und die unterstützenden Bibliotheken der Hersteller haben eines gemeinsam: Security-Funktionen sucht man vergeblich. Fairerweise ist zu erwähnen, dass es bis vor gut fünf Jahren so gut wie keine Security-Anforderungen an OT-Geräte und deren Software gab. Erst die Ransomware-Welle «NotPetya» im Jahr 2017 zeigte eindrücklich auf, dass die zunehmende Vernetzung der Firmen-IT und -OT dazu führen kann, dass Schadsoftware in den OT-Bereich überschwappt.

Seither bemühen sich die Hersteller, Security in ihre Produkte einzubauen. Aber auch hier ist der lange Lebenszyklus der Geräte ein Nachteil; denn Produkten, die aktuell nicht mehr verkauft werden, werden in der Regel keine Security Features nachgeliefert. Und bereits in Betrieb genommene Systeme werden nicht gerne verändert oder dürfen aus Zertifizierungsgründen nicht verändert werden.

Eine weitere Herausforderung, um Security in SPS-Programme zu integrieren, ist die Erstellung der SPS-Programme selbst. Nur selten wird für ein neues Projekt die SPS-Software von Grund auf erstellt. Soweit möglich, werden bereits getestete und in Betrieb genommene Programmbausteine wieder verwendet.

Top 20 SPS Programmierpraktiken

Um dennoch die Cyber-Resilienz von Steuerungsgeräten zu erhöhen, haben sich SPS-Programmierinnen und -Programmieren zusammengetan und in einem Gemeinschaftsprojekt die «Top 20 Secure PLC Coding Practices» zusammengestellt. Das sind 20 Programmierpraktiken zur Erhöhung der Cybersicherheit rund um SPS.

Der Anspruch des Projekts ist es, die 20 Praktiken mit vorhandenen Mitteln, der Programmiernorm IEC 61131 und möglichst kleinem Programmieraufwand umsetzen zu können. Die Praktiken sind von SPS-Programmierern für SPS-Programmiererinnen erstellt worden und öffentlich unter www.plc-security.com zugänglich. SWITCH-CERT hat die Beschreibung der Praktiken auf Deutsch übersetzt.

Interessant ist die Liste mit den Praktiken auch wegen der Querverweise auf die OT- / ICS-Sicherheitsnorm IEC 62443 und die «MITRE ATT&CK for ICS attack collection», eine Sammlung möglicher Cyber-Angriffe im Umfeld der Betriebstechnik.

Gerätekonfiguration ohne Login

Ein Beispiel: Eine Schwachstelle (Advisory-Nummer: CVE-2023-0053, https://www.cisa.gov/news-events/ics-advisories/icsa-23-012-05) ist umschreiben mit «ermöglicht die Ausführung von Konfigurations-Befehlen ohne Benutzeranmeldung». Das bedeutet, dass man Änderungen an der Gerätekonfiguration ohne Eingabe von Benutzername und Passwort vornehmen kann, wenn man Netzwerkzugriff auf das Gerät hat. Das tönt schlimm, ist jedoch in der Welt der Betriebstechnik Realität.

Praktik Nummer 13 hilft, sich gegen solche Schwachstellen zu wappnen: «Deaktivieren Sie nicht benötigte / unbenutzte Kommunikations-Ports und -protokolle.» Für das Beispiel sieht das in der Praxis so aus, dass sehr wahrscheinlich die Kommunikations-Ports auf dem Gerät, im vorliegenden Fall Telnet (TCP Port 23) und FTP (TCP Port 21), nicht deaktiviert werden können, da damit die Möglichkeit zur Konfiguration gesperrt wird. Sprich: Ich würde mich als Benutzer selber aussperren und könnte das Gerät nicht mehr konfigurieren. 

Als Nächstes gilt es, den Zugriff auf diese Ports im Netzwerk zu sperren, was man zum Beispiel mit einer Firewall konfigurieren kann. Ist keine Firewall vorhanden, bleibt noch die Überwachung des Netzwerkverkehrs und die Auslösung eines Alarms, falls ein unerlaubter Zugriff auf diese Ports erfolgt.

Für erfahrene SPS-Programmiererinnen und -Programmierer mögen einige Praktiken einfach erscheinen. Dies wurde bewusst so gewählt, um unerfahrenen SPS-Programmieren wertvolle Hilfe anzubieten. So zum Beispiel die Praktik Nummer 12, die Plausibilitätsüberprüfung von Benutzereingaben: «Stellen Sie sicher, dass die Bediener nur das eingeben können, was im Prozess praktisch oder physisch machbar ist. Setzen Sie einen Timer über die Dauer eines physischen Vorgangs. Erwäge eine Warnmeldung, wenn es Abweichungen gibt. Warne auch bei unerwarteter Inaktivität.»

Schreckensszenario gefällig?

Stellen Sie sich vor, Kriminelle verschaffen sich via Phishing E-Mails Zugang zum Netzwerk einer Strassenverkehrsanlage. Auf Linkedin findet man schnell heraus, welche Personen sich mit solchen Anlagen beschäftigen. Einmal im Netzwerk, gibt es praktisch keinen Schutz der Steuerungsanlagen mehr. Es findet keine Verschlüsselung der Daten statt. Sie glauben, das sei aus der Luft gegriffen? Hier ist ein echtes, aber anonymisiertes Beispiel aus meiner Praxis: Vor nicht allzu langer Zeit entdeckte ich im Internet die Steuerung einer Lichtsignalanlage von Fantasia. Ein grafischer Zugriff auf die Anlage war zwar eingeschränkt, der Zugriff über das Industrieprotokoll war jedoch offen zugänglich. Ich kenne dieses Protokoll, und so konnte ich mich durchklicken, bis ich auf die einzelnen Bits der Signallampen «rot / orange / grün» stiess. Ich hätte damit alle Lampen gleichzeitig auf grün stellen können. Ich meldete die Sache umgehend den zuständigen Behörden. Gemeinsam konnten wir sie korrigieren.

Dieses Beispiel lässt sich gedanklich problemlos auf andere Szenarien übertragen, wo manipulierte Steuerungsanlagen massiven Schaden anrichten können und in der Folge Angst und Schrecken verbreiten. Anders als in der IT funktioniert in der OT zum Glück jede Steuerungsanlage anders. Damit erhöht sich der Aufwand für Hackergruppen erheblich, solche Ziele anzugreifen.

Wie geht es mit dem Gemeinschaftsprojekt weiter?

Einerseits wollen wir das Projekt weiter bekannt machen. Eine beispielhafte Umsetzung der Praktiken mit der Programmierumgebung «Codesys» ist vom Autor auf Mitte dieses Jahres geplant.

Andererseits versuchen wir, die Hersteller von OT-Geräten für das Projekt zu begeistern, um mit ihnen gemeinsam sogenannte «Application Notes» zu erstellen. Also eine Hilfestellung für Programmiererinnen und Programmierer, wie die Praktiken mit der Programmierumgebung und den Hersteller-Bibliotheken umgesetzt werden können.