Sematicon war in diesem Jahr auf der Automatica, einer OT-Messe, vertreten. Was war das Erschreckendste, was Sie gehört haben?

Michael Walser: Für viele ist Cybersecurity noch ein offenes Buch. Wir haben mit vielen Produktionsleitern gesprochen und deren oberste Priorität ist, dass Roboter und Maschinen laufen und produzieren. Security ist nicht in ihrem Fokus. Erschreckend war die Überraschung, wenn sie einmal gesehen haben, wie schnell eine Anlage lahmgelegt werden kann. Jetzt muss man dazu sagen, wir hacken auf unserem Stand nicht, wir nutzen nur legitime Features, um Systeme auszuhebeln. Wir zeigen Interessenten Risiken auf und wie man diese vermeiden kann. Vielen ist das einfach neu. Viele wissen zwar, dass Cybersecurity notwendig ist, dass Maschinen gefährdet sind, aber sie wissen nicht genau, wie die Gefährdung aussieht, welche Form sie hat und wie sie darauf reagieren sollen. Und das ist ein Riesenproblem!

Aufklärung ist massiv wichtig, um den Leuten das passende Werkzeug an die Hand zu geben und zu verstehen, wie sie auf eine Gefährdung reagieren müssen. Cybersecurity ist kein reines Produktthema: Hersteller bewerben gerne Steuerungen mit Security-Zertifizierung. Das ist schön, aber es gibt auch Vorgängerversionen, die das nicht sind: Es sind Bestandsanlagen am Netz, die älter als 20 oder 30 Jahre sind. Auch diese müssen abgesichert werden. Und eine Sicherheits-Zertifizierung heißt nicht per se, dass das System sicher ist. Sicherheit kann nur gewährleistet werden, wenn das Gesamtsystem als solches, die Anlage als Ganzes, allen Anforderungen entspricht.

Cybersecurity erreiche ich nicht dadurch, ein Produkt zu installieren und zu aktivieren, sondern auch durch organisatorisch technische Maßnahmen. Wenn Sie jetzt einfach Systeme komplett zu nageln, dann müssen Sie natürlich auch sicherstellen, wie Wartung später möglich ist. Möchten Sie Systeme ins Internet stellen, müssen Sie genau überlegen, wie die Rückwirkung aussehen kann. Also nicht nur, welche Informationen Sie ins Internet liefern, sondern welche Informationen zurückkommen und welchen Einfluss diese auf die Anlage haben. Dieses Risikoverständnis zu schaffen, das ist ungemein wichtig. Wir müssen mit Cybersecurity auf ein Niveau bringen, auf dem wir mit der pyhsikalischen Maschinensicherheit, sprich Safety, schon sind – denn das eine gibt es nicht mehr ohne das andere.

Beim Thema Cybersecurity in OT-Umgebungen werden gerne Ideen aus dem IT-Bereich herangezogen. Wie tückisch ist dieses Vorgehen?

Walser: Hier gilt es, zwei Aspekte zu unterscheiden. Zum einen werden in der IT die Systeme durch Virenscanner, Endpoint Security Systeme und Patches geschützt. Dieser klassische IT-Ansatz fällt in der OT oft weg, obwohl es auch hier Windows-Systeme und Linux-Rechner gibt. Aber in der OT wird oftmals argumentiert, dass keine Virenscanner oder Patches installiert werden können, da sich sonst das System nicht reibungslos betreiben lässt.

Zum anderen gibt es sehr gute Lösungen zur Netzwerküberwachung, die Intrusion Detection machen, also auf Veränderungen im Netzwerk, der Software oder des Codes achten, und auf untypische Vorfälle reagieren. Das Problem für die OT-Seite: ähnliche Lösungen müssen aufgrund ihrer Natur in der Regel den kritischen Wartungszugriff ausklammern. Es gibt also Lösungen, deren Ansatz in der IT reibungslos funktioniert, welche aber aufgrund ihrer Produkteigenschaften in der OT schnell zum Problem werden können.

Ein Beispiel: Anlagen sind meist nicht so gebaut, dass sich Personen eindeutig identifizieren müssen, damit sie daran arbeiten dürfen. Die Techniker haben meist einen (argumentativ) notwendigen Vollzugriff. Außerdem muss gewährleistet sein, das während des Betriebs Parameter verändert werden können. Das heißt, Sie können Einstellungen, Software und Code an der Anlage im laufenden Betrieb ändern. Das ist auch notwendig, um Stillstände in der vernetzten Fertigung zu vermeiden. Aus meiner Sicht ist die Problematik daher besonders bei Wartungszugriffen gegeben, wenn Fremdsysteme wie Techniker-PCs oder -Notebooks eingebracht werden, die wiederum auf irgendeine Art und Weise die Software verändern. Die angesprochenen automatisch schützende Systeme können einen Angriff schwer verhindern: Woher soll das System denn wissen, ob das beispielsweise ein erfahrener oder ein unerfahrener Mensch ist, der Probleme anders löst. Auch wenn er nur Funktionen nutz, die für die Wartung vorgesehen sind, lässt sich das missbräuchlich verwenden. Oder ist es ein Angreifer, der sich eben nicht nur die sogenannten ‚Sicherheitslücken‘, sondern auch die legitimen Produkteigenschaften zu nutzen macht, um den Betrieb zu stören?

Michael Walser, CTO bei Sematicon in München

© Sematicon

Betrifft das nur die Wartung beziehungsweise Fernwartung?

Walser: Egal ob Wartung oder Fernwartung – sobald ein Fremdsystem angebunden wird, welches in der Lage ist, etwas am System zu verändern. Aufgrund der meist fehlenden Authentifizierung kann das jedes System sein. Ich behaupte: Sofern keine externen Geräte oder externer Content in die Systeme gebracht werden, ist ein Virenscanner vermutlich nicht notwendig. Ein Sicherheitspatch ist auch nicht notwendig, solange ein System vollständig isoliert betrachtet wird. Das Problem mit der Isolation: ‚Die Anlage ist getrennt‘ ist nur insoweit richtig, als dass niemals ein Fremdsystem eingebracht wird. Wird aber ein Notebook eines Technikers eingebracht, das in der Vergangenheit mit dem Internet oder einem nicht vertrauenswürdigen Datenträger verbunden war, kann man diesem Gerät nicht mehr vertrauen. Außerdem kann man bei externen Notebooks von externem Techniker nie mit Sicherheit feststellen, ob diese Geräte mit den aktuellen Updates und Sicherheitspatches versorgt werden.

Vertrauen ist in diesem Kontext als Definition zu verstehen: Alle Geräte, die nicht Teil der Anlage sind, dürfen keinesfalls Vertrauen genesen. Diesen Ansatz nennt man in der Fachsprache auch ‚Zero-Trust‘. Ein Prädikat, das auch den Ansatz unsere Hausiegenen Lösungen auszeichnet.

»Viele wissen nicht, wie eine Gefährdung aussieht« - Teil 2: Von Stuxnet und Open-Source-Software

Zwar ist ein 100-prozentiger Schutz nicht möglich, doch gilt es, die Hürden für potenzielle Angreifer so hoch wie möglich zu setzten, so dass ein Angriff den Aufwand nicht wert ist.

© Melinda Nagy/stock.adobe.com

Wie aber kann man sicherstellen, dass ein in die Anlage neu eingebrachter Code dem ihm zugedachten Zweck dient?

Walser: Mit Validierung und ‚Zero-Trust‘. Das bedeutet, das regelmäßig überprüft werden muss, ob der Code der Anlage noch jener ist, der eingebracht wurde. Nehmen wir das Beispiel Stuxnet: Die Malware wurde an verschiedenen Rechner installiert, ist dort aber nicht in Erscheinung getreten, sondern hat gewartet, bis genug Rechner infiziert waren, sodass letztendlich einer mit Zielanlage verbunden wurde. Sobald dieser Rechner mit der Anlage verbunden war, hat die Malware angefangen, Daten in die Anlage einzuspeisen und das Netzwerk zu manipulieren – es hat seinen Schadcode bei Verlassen angehängt und beim Laden der Daten von der Anlage bei der Prüfung wieder entfernt. Das heißt, die Programmierer haben nur den Code in ihrer Software gesehen, der auch auf der Anlage sein sollte. Was bedeutet das nun? Ganz einfach: Mit den klassischen Programmierwerkzeugen auf dem PC können wir heute nicht Anlagenübergreifend sicherstellen, dass der Quellcode in Ordnung ist. Wir brauchen ein drittes System, das validiert und in der Lage ist, den Code zu vergleichen. Dem Techniker dürfen wir ja per se nicht vertrauen, sprich: Zero Trust.

Stuxnet gilt als staatlicher Angriff. Dahinter steckt ein enormer Aufwand. Ein kleines oder mittelständisches Unternehmen wird wohl kaum Ziel eines solchen Angriffs werden.

Walser: Stuxnet wurde einen bestimmten Zweck entwickelt: Man wollte offensichtlich Anlagen manipulieren, ohne dass es die Techniker merken. Das heißt, auf den Instrumenten wurden andere Werte angezeigt, um die Anlage im Hintergrund über die Zeit hinweg so zu betreiben, dass eine unbemerkte Zerstörung stattfinden konnte. Die Instrumente zeigten aber keinen Fehler an. Ein Cyberkrimineller wird in der Regel nicht den Mittelständer, sondern gezielt eine Produktserie eines Automatisierungsherstellers angreifen und dort eine Schwachstelle ausnutzen.

Nehmen wir eine Steuerung als Beispiel: Der Angreifer hat zwar kein explizites Wissen über die Funktionsweise, aber er kann einfach mal die Ein- und Ausgang  der SPS zusammenschalten oder alle SPS-Ausgänge schließen. Vielleicht gehen überall die Lichter an und aus, vielleicht wird aber auch ein Gasventil geöffnet und dadurch eine Produktionslinie zerstört oder ein Mensch verletzt. Daher muss man unterscheiden zwischen einem klaren Angriff wie Stuxnet, der einem gezieltem Zweck diente, oder einfach nur einem blinden Angriff, bei dem es um blinde Zerstörung beziehungsweise um das Erlangen von Aufmerksamkeit geht.

Dann sind die Angreifer am gefährlichsten, die eigentlich keine Ahnung vom Zielsystem haben?

Walser: Das würde ich so nicht sagen. In erster Linie geht es darum, Menschen und Unternehmen zu sensibilisieren. Ein Beispiel: Ein Ingenieur baut sich seine Lösung gern selbst. Er nutzt dafür den beworbenen, einfach zu verwendenden mini PC für die Hutschiene auf Basis eines Linux-Betriebssystems, mit denen man schnell und einfach loslegen kann und setzt das entstandene System in seinem Unternehmen ein. In diesem Moment wird er zum Hersteller, der aber nicht wirklich die Kontrolle über sein System hat und auch nicht weiß, wie man Sicherheitslücken erkennt und schließt. Somit ergeben sich viel mehr mögliche Einfallstore für Angreifer.

Was meinen Sie damit »ein Ingenieur wird zum Hersteller seiner eigenen Systeme«? Gehen damit bestimmte Plichten einher?

Walser: Rechtliche Pflichten momentan eher weniger, aber eine moralische Verpflichtung: Ich muss Verantwortung für meine Produkte übernehmen und mich wie ein Hersteller verhalten; das wird meisten außer Acht gelassen. Als Hersteller muss ich aber einerseits sicherstellen, dass die verwendeten Komponenten immer Up-to-Date sind und außerdem für die korrekte (Security)-Konfiguration eintreten. Was viele nämlich auch vergessen: Wir sprechen im Moment über Security, aber Safety und Security gehören zusammen: Ein Security-Vorfall kann natürlich auch die Safety gefährden. Safety ist der Schutz des Menschen. Security beschreibt den Schutz der Anlage.

Wie wird Security in Hardware und Software abgebildet?

Walser: Software-Security ist eigentlich eher die Frage danach, welche Prozesse auf der Hardware laufen. Hardware wird auch mit Software betrieben. Das nennt man dann Firmware. Sie können sich das so vorstellen: Möchte ich heute eine Software oder Firmware schreiben, dann ist diese keine komplette Eigenentwicklung, sondern die Software wird unterstützt durch externe Bibliotheken, sprich Programmbausteine, die bestimmte Aufgaben erledigen. Kein Techniker wird heute Netzwerk-Kommunikation selbst schreiben, sondern sich eine entsprechende Bibliothek organisieren. Kein Hersteller wird heute ein GUI, also eine grafische Nutzerschnittstelle, entwickeln, sondern sich dafür ein Framework holen. Das heißt: Framework plus Bibliotheken plus mein eigener Code bilden das eingesetzte Software-Produkt. Die Herausforderung ist, festzustellen, in welchem Zustand meine verwendete Bibliothek ist.

Was will ich damit sagen? Als Beispiel möchte ich das Framework beziehungsweise die Softwarebibliothek ‚Log4j‘ nennen, das kürzlich durch alle Medien ging. Dabei handelt es sich um eine kleine Bibliothek, die von einem Open-Source-Maintainer in seiner Freizeit gepflegt wurde. Viele Großkonzerne nutzten das Open-Source-Framework für das Logging von Anwendungsmeldungen. Als die Sicherheitslücke offensichtlich wurde, übten alle einen enormen Druck auf den Entwickler aus, den Code zu fixen. Doch mit welcher Rechtfertigung? Dass ein Entwickler in seiner Freizeit zum Spaß eine offene Software entwickelt, die Großkonzerne freiwillig einsetzen? Das Beispiel zeigt, wie hier der Open-Source-Gedanke missbraucht wird: Ich kann niemanden verpflichten, denn ich habe ihn nicht dafür bezahlt, ein bestimmtes Produkt zu liefern – ich nutzte einfach seine Bibliothek. Und dabei wird oft unterschätzt, wie viele freie Bibliotheken ein Sicherheitsproblem haben, dass bekannt und üblicherweise unter einer CVE-Nummer dokumentiert wird. Das heißt: entdecken Hacker oder Security-Spezialisten in Open-Source-Bibliotheken Sicherheitslücken, gibt er oder sie dem Hersteller in der Regel zwei bis vier Wochen Zeit, um den Fehler zu beheben. Danach wird das Sicherheitsproblem veröffentlicht – dann gibt es eine bekannte Sicherheitslücke für Teile meiner Software und Ich weiß eventuell gar nicht, dass mich das betrifft beziheungsweise das ich eine solche Komponente einsetze.

Das meinte ich vorhin mit Herstellerplicht: Es ist meine Pflicht als Hersteller, zu wissen, welche Software-Bibliotheken ich einbinde und wie ich sicherstellen kann, dass mein Software-Produkt – Framework plus Bibliotheken plus mein eigener Code – zum Zeitpunkt der Verwendung beziehungsweise im regelmäßigen Betrieb sicher ist. Wenn ich eine Bibliothek im Internet suche, die meine Anmeldung an einem selbstgebauten Portal übernimmt, dann ist meine ganze Software nur so lange „sicher“, solange diese Bibliothek sicher ist. Wenn ich die Anmeldung und den Passwortschutz durch einen Fehler in der Komponente umgehen kann, dann ist mein System auch nicht mehr geschützt. Das heißt: Es müssen alle Bausteine zusammenstehen und ich muss in der Lage sein, für jedes einzelne Modul meiner Software herauszufinden, ob es gefährdet ist oder nicht.

»Viele wissen nicht, wie eine Gefährdung aussieht« - Teil 3: Auf Sicherheitslücken reagieren

Lässt sich dieser Prozess automatisieren?

Walser: Ein klassisches Beispiel dafür sind sogenannten SBOMs – ‚Software Bill of Materials‘ also eine Art ‚Zutatenliste‘ für Softwareprodukte. Diese muss alle eingesetzten Komponenten eines Produktes enthalten. Zu diesem Zweck gibt es Standard-Formate, die maschinenlesbar sind, zum Beispiel SPDX oder Cyclon DX. So kann ein Security-Verantwortlicher eine Software-Liste in seinem Security Management-System integrieren und regelmäßig nach entsprechenden CVEs, sprich bekannten Sicherheitslücken, suchen. So ist er in der Lage, auf eine Sicherheitslücke entsprechend zu reagieren, bevor diese vielleicht von Angreifern ausgenutzt werden können. Das heißt, ich kann schnell auf Bekanntwerden einer Lücke reagieren, entsprechende Software offline nehmen oder andere Maßnahmen ergreifen.

Das wird in der OT heute einfach nicht gemacht haben viele Hersteller einfach keine Listen zur Verfügung oder man will die Inhalte geheim halten. Es wird eine Steuerung oder Software ausgeliefert, Punkt. Gerade im Industriebreich wird zudem argumentiert, dass man eine Software nicht patchen darf – auch ein großer Fehler, denn warum sollte ein Linux- oder Windows-System, das beispielsweise eine Datenbank in einem OT-System hostet, nicht gepatcht werden?

Diese Argumentation führt dazu, dass ich weder Kontrolle über das eingesetzte System, noch über die Eigenentwicklung habe und somit habe ich eine relativ hohe Wahrscheinlichkeit, in ein Problem zu laufen, dass mich kompromittiert. Besonders dann, wenn ein Wartungszugang über VPN erfolgt. VPN ist nichts anderes als ein verlängertes Netzwerkkabel. Das heißt, der VPN-Tunnel ist geschützt, doch woher weiß ich, was durch den Tunnel kommt? Ein VPN erfüllt auch nicht die Prinzipien von ‚Zero-Trust‘.

Grundsätzlich gefragt: Mit welchem Ziel sollten Security-Maßnahme getroffen werden?

Walser: Sich die Frage zu stellen, wovor ich mich schützen möchte, ist schon ganz gut. Ich betreibe Risikomanagement: Was sind meine Gefährdungspotenziale? Wo habe ich Probleme? Jede Steuerung, jedes Anlagensystem ist ‚per Definition immer‘ unsicher. Das heißt, mein Gefährdungspotenzial ist der direkte Zugriff auf die Anlage. In dem Moment, in dem ein Techniker auf die Anlage zugreift, habe ich ein Gefährdungspotenzial. Kommuniziert eine Anlage mit dem Internet, wie sicher ich ab, dass der Vorgang Rückschlussfrei passiert? Nutze ich eine IoT-Plattform, sende ich Daten dorthin. Ist es aber eine gute Idee, die Daten wieder zurückzuholen? Denn damit habe ich wieder ein Einfallstor. Oder Ein Mitarbeiter steck einen fremden USB-Stick an einen Rechner oder lädt sein Smartphone an der USB-Buchse der Anlagensteuerung. All das sind Gefahrenpotenziale.

Cyberangriffe passieren immer dann, wenn externe Systeme oder Menschen in ein System eingreifen. Ich muss mir also überlegen, wo sind meine größten Risiken und wie sichere ich mich vor diesen Gefahrenpotenzialen ab? Ein 100-prozentiger Schutz ist nicht möglich, aber ich kann die Hürden so hoch gestalten, dass der klassische Random-Angreifer oder sogenannte ‚Script-Kiddies‘ der Mühe nicht wert findet, da drüber zu klettern.

Gezielte Angriffe auf spezielle Unternehmen, Industriespionage sind auch eine nicht zu unterschätzende Gefahr. Da es sich hier um einen gerichteten Angriff und kein 0815-Szenario handelt, ist es schwieriger, dagegen etwas zu unternehmen. Aber auch hier gibt es Lösungen und Methoden, die man im Einzelfall bewerten muss.

Eine weitere IT-Technologie in der Industrie sind Container. Wie sicher ist die Technologie?

Walser: Aus Sicht des Herstellers sind Container toll, denn ich kann alle benötigten Komponenten mitliefern und innerhalb meines Containers ausführen. Auch hier ist wieder das Problem, dass Unternehmen, wenn sie einen Container bauen, auch auf fertige Komponenten zurückgreifen und sie in ihre Software integrieren. Ein Beispiel: Sie schreiben eine Software in Java und der Container liefert die passende Java-Runtime gleich mit. Es gibt fertige Container auch von Open-Source-Quellen, die aber meist auch viele Komponenten mitliefern, die ich für die Entwicklung aber später für den Betrieb nicht benötigte. Klassische Beispiele dafür sind Paket Manager (für das nachinstallieren beliebiger Software), entsprechende Editoren und „sudo“-Programme, die es mir ermöglichen, Befehle mit maximal möglichen Rechten auszuführen. Das bedeutet: Wenn ich einen Container baue, habe ich als Hersteller die Verantwortung, nur jene Komponenten in den Container zu legen, die der Anwender auch wirklich für den Betrieb benötigt. Und wie beim vorangegangenen Beispiel muss ich mir vorher überlegen, ob es Verwundbarkeiten gibt, die mich als Hersteller betreffen – zum Beispiel Funktionen einer Bibliothek, die als unsicher gilt. Ein Container ist kein Freifahrtschein.

Eine weitere Herausforderung bei Container ist die Konfiguration: Ein unprivilegierter Container, der keine besonderen Rechte im Hochsystem hat, ist meist einfacher zu isolieren als ein privilegierter Container mit Zugriff auf das Hochsystem. Wie bei allen Technologien gibt es Vorteile und Risiken, ich muss nur wissen, wie ich mit dem Risiko umgehe.

Im Moment ist ChatGPT in aller Munde und wird auch als Programmierhilfe eingesetzt. Wie sehen Sie diese Entwicklung?

Walser: Die Frage ist schwer zu beantworten. In der Entwicklung ist es manchmal schwierig, auseinanderzuhalten, wer etwas programmiert. Sind das erfahrene Entwickler oder Berufsanfänger oder Hobby-Programmierer ohne Ausbildung? Jeder Techniker sucht im Netz nach Ideen und Lösungsvorschlägen. Ist eine Lösung gefunden ist die Frage, ob der Weg dorthin der richtige ist. Kann ich einschätzen, ob der Beispielcode so aus dem Forum übernommen werden kann oder nicht? Brauche ich noch Optimierungen? Ist die Ausführung sicher?

Natürlich träumen wir davon ein intelligentes System zu haben, das genau diese letzte Frage beantworten kann und uns bei der Arbeit unterstützt. ChatGPT erweckt den Eindruck genau jenes Tool zu sein. Wir sprechen hier gerne von „Künstlicher Intelligenz“, doch es ist am Ende auch nur ein komplexer Algorithmus. Ich vertrete folgendes Dogma: Es gibt Stand heute keine menschenähnliche künstliche Intelligenz. Was wir heute kennen, ist in der Fachwelt als „Machine Learning“ bekannt. Das heißt, das System sammelt Informationen, gewichtet diese und stellt sie gemäß einer Anfrage zur Verfügung.

Und genauso arbeitet auch ChatGPT: Ich stelle dem Tool eine Frage über ein bestimmtes Thema, ChatGPT antwortet sehr selbstsicher scheinbar moderiert und untermauert die Antwort mit offensichtlich korrekt scheinenden Fakten. Dazu nutzt es das Internet und alle Informationen die dort zugänglich sind sind ungefiltert. Daher auch rassistische oder feindliche Begriffe. Woher soll denn ChatGPT wissen, welche Informationen gut oder schlecht recherchiert sind? Woher soll es wissen, was moralisch korrekt ist? Nur weil eine Behauptung durch viele Quellen geteilt und häufig repliziert wird, ist das kein Garant für den Anspruch auf Richtigkeit.

Bei der Programmierung gibt es das gleiche Problem: ChatGPT übernimmt Programmierschnipsel aus dem Internet, aus Foren et cetera. Woher soll das Tool wissen, welcher Code gut oder schlecht ist? Programmieren ist mehr als das aneinanderreihen von Codeschnipsel. Ein Entwickler sollte schon wissen, was er tut. ChatGPT ist wie jedes Werkzeug eine gute Unterstützung, wenn ich weiß, wie ich es einsetzen und bewerten kann, was dabei rauskommt. Aber die Verantwortung für das Ergebnis liegt einzig und allein bei dem, der das Werkzeug einsetzt.

Videotipp: Im Videointerview erläutert Michael Walser verschiedene Angriffsszenarien für OT-Umgebungen.