Wenn Sie ein regelmäßiger Leser dieser Seite sind, wissen Sie bereits, dass sich mangelnde IT-Sicherheit negativ auf die Finanzen eines Industrieunternehmens auswirken kann. Auch bei Schäden am Unternehmens-Image oder unzureichender Erfüllung regulatorischer Anforderungen handelt es sich eher um abstrakte Bedrohungen, die zunächst eher auf dem Papier existieren, als im echten Leben. Doch die Schadsoftware TRISIS fällt in eine andere Kategorie.

Im Dezember 2017 kam ein Angriff ans Tageslicht, der es gezielt auf die Safety in einer petro-chemischen Anlage in Saudi Arabien abgesehen hatte. Dieser TRISIS getaufte Schädling hatte dort die funktionalen Sicherheitssysteme befallen und wurde nur durch Zufall entdeckt, bevor es zu tatsächlichen Schäden kommen konnte. In den folgenden Zeilen erfahren Sie mehr zum Hergang, potenziellen Auswirkungen und möglichen Schutzmaßnahmen.

TRISIS – was ist passiert?

Im Sommer 2017 gab es einen durch die Safety-Systeme ausgelösten Fehler im Produktionsprozess eines Chemiewerks in Saudi-Arabien. Nach dessen Untersuchung durch Sicherheitsexperten stand fest, dass es sich dabei um keinen normalen Fehler handelte, sondern um einen durch Schadsoftware ausgelösten Effekt. Diese Schadsoftware befand sich auf den TRICONEX Safety-Systemen der Firma Schneider Electric und konnte dort Safety-relevante Aktionen steuern oder manipulieren.

Der Weg für den Befall war eine Kombination verschiedener Faktoren. Aus einem Bericht von Dragos Security geht hervor, dass sich der Schlüsselschalter der TRICONEX Systeme im „Programmiermodus“ befand, was eine externe Konfiguration über das Netzwerk ermöglichte. Außerdem waren die Safety-Systeme nicht ordentlich vom Rest des Automatisierungsnetzwerks abgeschottet. Der Angreifer konnte vermutlich über das normale Netzwerk Zugang zur Engineering Station erlangen, die auch zur Programmierung des Safety-Systems verwendet wurde.

Aufgrund des Namens „TRICONEX“ und dem englischen Begriff für funktionale Sicherheitssysteme „Safety Instrumented Systems“, kurz „SIS“, setzt sich der Name TRISIS zusammen.

An dieser Stelle ist hervorzuheben, dass dieser Beitrag kein Fingerzeig auf Schneider Electric oder eine Aussage über die Qualität ihrer Produkte sein soll. Jede hinreichend komplexe Software hat Fehler, egal aus welcher Quelle sie stammt. An den Hunderten Schwachstellen, die jedes Jahr in Windows, Linux, MacOS entdeckt werden, sieht man, dass selbst sauberste Programmierung und beste Qualitätssicherungsprozesse nicht ausreichen, dies ganz zu verhindern. Die Kernaussage ist viel eher: Auch nach einem hohen SIL entwickelte Safety-Systeme können anfällig für Schadsoftware oder digitale Angriffe sein! Darunter fallen jegliche Hersteller am Markt.

Zurück zum Thema: Sicherheitsforscher fanden heraus, dass es diese Schadsoftware präzise auf die TRICONEX-Systeme abgesehen hatte, um im weiteren Verlauf wahrscheinlich einen Safety-relevanten Zwischenfall auszulösen oder nicht abzufangen. Diese Art von Angriff gab es so vorher noch nicht im Umfeld der digitalen Industrie und deshalb werden einige neue Fragen und Sorgen aufgeworfen.

Keine finanzielle Motivation, sondern physischer Schaden

Da der Befall glücklicherweise durch den Fehler im Code der Schadsoftware gefunden wurde, bevor es zu einem schadhaften Ereignis kam, hatte dieser Zwischenfall keine direkten negativen Auswirkungen. Dennoch zeigt er wieder einmal mit Nachdruck, dass finanzielle Motivation, z.B. durch Kriminelle die Bitcoin erpressen wollen, nicht die einzige Ursache für digitale Angriffe mit Schadsoftware ist. Vielmehr hat die Entwicklung einer so komplexen Software wie TRISIS umfassende finanzielle Ressourcen eingefordert. Zudem bedürfen Safety-Systeme einem speziellen Fachwissen, um diese zu konfigurieren und jede funktionale Sicherheitsfunktion, bestehend aus Sensor, Logik und Aktor, ist anders aufgebaut.

Diese Aspekte zusammen betrachtet legen nahe, dass es sich bei diesem Angriff um eine staatlich finanzierte Aktion handelte, vermutlich im Zuge von kriegerischer Sabotage. Durch die sehr präzise und spezielle Programmierung von TRISIS ist es außerdem unwahrscheinlich, dass sie sich außerhalb des kleinen Zielkreises verbreitete. Die möglichen Auswirkungen hätten jedoch unter Umständen schwere physische Schäden an Mensch und Umwelt zur Folge haben können.

Wie im vergangenen Beitrag zu NotPetya, soll auch an dieser Stelle darauf hingewiesen werden, dass eine korrekte Zuordnung eines raffinierten Angriffs zu einem bestimmten Urheber schwierig bis unmöglich ist. Ein Bericht der New York Times schreibt diesen Vorfall allerdings dem eskalierenden Konflikt zwischen Saudi-Arabien und dem Iran zu. Zumindest kann dieser Vorfall als ein Indiz dafür gewertet werden, dass die Anzahl staatlicher Angriffe durch digitale Mittel steigt.

Welche Security-Maßnahmen die Safety schützen können

Safety-Systeme übernehmen kritische Funktionen im industriellen Automatisierungsumfeld. Daher sollte man sie bei der Integration in die Gesamtinfrastruktur auch so behandeln. Systeme dieser Art sollten nicht ungeschützt mit dem Rest des Automatisierungsnetzes verbunden werden, sondern mindestens über strikte Firewalls davon abgeschottet werden oder gänzlich physisch getrennt betrieben werden. Es empfiehlt sich, nach einem Zonierungskonzept vorzugehen. Lesen Sie hierzu mehr in unserem Beitrag zu Zones & Conduits.

Sind Einstellungsmöglichkeiten am System selbst zur Regelung des externen Zugriffs und der Programmiermöglichkeiten vorhanden, sollten diese nach der Fertigstellung der Inbetriebnahme umgehend in den „Read-Only“ Modus versetzt werden. Die Häufigkeit der Änderungen an den Safety-Systemen sollte gering genug sein, bei Bedarf die Systeme in den Schreibmodus zu versetzen, ohne dadurch regelmäßig viel Zeit zu verlieren.

Auch Virenscanner und Intrusion Detection Systeme können dabei helfen, Schadsoftware oder Angreifer im Netzwerk zu erkennen und diese an der Ausbreitung zu kritischen Systemen zu hindern.

Bei der Entwicklung von Safety-Systemen sollte neben der reinen Safety ebenfalls auf Security geachtet werden. Security-By-Design ist hier ebenso angesagt, wie in anderen sicherheitskritischen Systemen. Außerdem sollte in regelmäßigen Zyklen durch eine Bedrohungsanalyse geprüft werden, ob die Systeme durch neue Schwachstellen über externe Verbindungen angreifbar geworden sind. In diesem Fall sollte entweder ein Update eingespielt werden oder der Angriffsvektor durch andere Maßnahmen abgesichert werden.

Fazit

Dieser Vorfall hat gezeigt, dass moderne Safety-Systeme ebenfalls angreifbare IT-Systeme darstellen. Diese Aspekte müssen unbedingt bei der Entwicklung und Integration in Betracht gezogen werden. Auch die IEC 61508 weist an einer Stelle bereits auf die Security-Risiken hin, die auch für die Safety-Betrachtung relevant sind. Verwiesen wird dort auf die IEC 62443, eine der wichtigsten Normen, wenn es um Security im Automatisierungsumfeld geht.

Wenn fehlende Security negative Auswirkungen auf die Safety haben kann, gibt es nicht nur Geld und andere „weiche Faktoren“ zu verlieren, sondern im schlimmsten Fall Leib und Leben. Bei der Implementierung und Integration von Safety-Systemen die Security außer Acht zu lassen halten wir für verantwortungslos, gerade auch in Bezug auf den zukünftig weiter ansteigenden Vernetzungsgrad industrieller Netzwerke.

Zum Schluss noch eine Frage an Sie als Leser: Wie lange wird es wohl dauern, bis die Security in Bezug auf Safety verpflichtend wird, um negative Beeinträchtigungen zu verhindern? Diskutieren Sie mit, entweder in den Kommentaren unter dem Beitrag oder auf unserer LinkedIn Seite.

Nachtrag 13.03.2019: Auf Youtube findet sich inzwischen ein Konferenzvortrag vom Analysten der Malware: https://youtu.be/XwSJ8hloGvY

Sehen Sie sich die Integration Ihrer Safety-Systeme nochmal mit einem skeptischen Auge im Detail an. Sind diese wirklich gut vom Rest der IT-Infrastruktur abgeschottet?