Anlagensicherheit Log4Shell: Auch für OT-Systeme eine große Gefahr

Ein Gastbeitrag von Patrick Latus*

Eine Sicherheitslücke in der Java-Logging-Bibliothek Log4j beschäftigt seit Wochen IT-Experten in aller Welt. Die operative Technologie ist für Angriffe ebenso empfindlich. Unternehmen müssen deshalb stärker in die Sicherheit ihrer Anlagen investieren.

Anbieter zum Thema

Mit Log4Shell haben Angreifer Möglichkeiten, Systeme zu infiltrieren, Hintertüren und Remotezugänge einzubauen und Daten zu manipulieren.
Mit Log4Shell haben Angreifer Möglichkeiten, Systeme zu infiltrieren, Hintertüren und Remotezugänge einzubauen und Daten zu manipulieren.
(Bild: gemeinfrei / Pixabay )

Die Abkürzung Log4j steht für Logging for Java. Hierbei handelt es sich um eine Open-Source-Bibliothek von Java, die kostenlos genutzt werden kann und inzwischen in unzähligen Produkten weltweit eingesetzt wird, beispielsweise im Apache Webserver. Log4j dient dem Sichern und Wegschreiben von Logfiles, die Programme ausgeben können. Die Ende vergangenen Jahres öffentlich gewordene Lücke kann genutzt werden. Mit einem simplen Zeichensatz können Informationen von weiteren verbundenen Servern abgefragt und Kommandozeilenfenster erzeugt werden. Diese Kommandozeilenfenster werden Shells genannt. Daraus leitet sich der Name der Sicherheitslücke ab, die seit Mitte Dezember die IT-Welt in Atem hält: Log4Shell.

Viele Hersteller sind betroffen

Mit einer Shell haben Angreifer alle Möglichkeiten, Systeme zu infiltrieren, Hintertüren und Remotezugänge einzubauen und Daten zu manipulieren. Viele OT-Systeme haben solche Komponenten ebenfalls verbaut und sind damit anfällig für Angriffe von innen und außen, darunter auch viele IoT-Geräte, die in der Industrie 4.0 eingesetzt werden. Da Systeme für operative Technologien (kurz: OT) standardmäßig noch keine Netzwerküberwachung wie Intrusion Detection Systeme haben und die Patchzyklen erst deutlich nach der Veröffentlichung freigegeben werden, stellen Log4Shell und andere Sicherheitslücken eine sehr große Gefahr dar. Dazu kommt, dass bis heute niemand genau sagen kann, wie lange es Log4Shell bereits gibt und vor allem wie lange die Lücke schon ausgenutzt wird. Die Liste der Unternehmen, die betroffen sind beziehungsweise waren ist inzwischen lang.

Dabei sind zwei Arten von Worst-Case-Szenario üblich: Ein Angreifer greift auf die OT-Systeme zu und manipuliert Werte, fährt die Umgebung herunter oder zerstört sie ganz. Oder aber er lässt über Wochen und Monate unbemerkt Daten abfließen und bietet sie zum Weiterverkauf an. Letzteres fällt in den Bereich der Industriespionage. Ersteres war früher die verbreitetere Variante, da bis vor wenigen Jahren praktisch keine speziellen Programme für OT-Systeme existierten, die für diesen Fall kontrollieren, welche Daten manipuliert wurden. IT-Programme mussten umständlich und aufwendig konfiguriert werden. Heute entscheiden sich Angreifer jedoch häufig dafür, Daten abfließen zu lassen und zu verkaufen.

Die erste große Herausforderung liegt bereits darin, herauszufinden, welche Systeme überhaupt betroffen sind. Bei vielen OT-Betreibern scheitert es hier schon am Asset Management: Die allerwenigsten OT-Betreiber haben genau auf dem Schirm, wie viele Systeme es im Netzwerk gibt und welche davon die Log4j-Bibliothek nutzen und somit anfällig sind. Viele OT-Anlagen sind historisch und komplex gewachsen und selten nachdokumentiert. Die verantwortlichen Techniker müssen daher zunächst einmal die betroffenen Systeme identifizieren.

Patches teils erst Wochen später freigegeben

Daraufhin erfolgt das Updaten mit den Patches der Hersteller. Hier ergibt sich ein weiteres Problem: Die Hersteller geben diese Patches im besten Fall erst Tage oder Wochen nach Erscheinen frei. Wenn der Anlagenbetreiber oder der OT-Verantwortliche vorher ohne Freigabe des Herstellers patchen möchte, verliert er im Falle eines Fehlers oftmals den Anspruch auf technische Unterstützung. Niemand kann also die Verantwortung für einen Ausfall auf sich nehmen, weil er nicht freigegebene Software in einem OT-System installiert hat. Somit bleiben diese Systeme oft wochenlang ungepatcht und weiterhin angreifbar. Ein Teufelskreis. In diesem Fall helfen ausgeklügelte Update- und Patchzyklen, bei denen zum Beispiel nur ein Teil der Systeme Updates bekommt. Der Rest der Maschinen folgt dann ein paar Tage nach fehlerfreiem Betrieb.

Das Scannen auf Schwachstellen erfolgt mit speziellen Programmen wie Tenable.ot. Ein normaler Schwachstellenscan kann nicht direkt auf den Prozessoren geschehen, da diese sonst ausfallen würden und den Betrieb erheblich stören oder gar komplett unterbrechen. Ein Scanner wie Tenable.ot versteht das Protokoll und spricht die Sprache der Controller. Er kann so den Zustand dieser Controller ganz speziell und vorsichtig abfragen. Dabei erkennt er Modifikationen, zum Beispiel über etwaige ungewollte Veränderungen wie das Anpassen von Grenzwerten am Wochenende oder ein ungeplantes Hochfahren der Turbinenlast.

Spezialisierte Angriffe auf OT-Anlagen zu erwarten

Zukünftig kann davon ausgegangen werden, dass Sicherheitslücken noch gnadenloser ausgenutzt werden. Auch Angriffe mit Ransomware dürften zudem immer spezieller auf OT-Systeme ausgerichtet werden, da die Angreifer deutlich mehr finanziellen Druck auf industrielle Anlagen ausüben können und die Systeme beim Patchen erfahrungsgemäß hinterherhängen werden.

Die Hersteller werden darauf reagieren müssen oder sie tun es bereits. So liefert Siemens von vornherein eine Verschlüsselung zum Controller aus. Das erschwert die direkte Kommunikation und das unautorisierte Verändern von Prozesswerten deutlich. Firmen wie Microsoft optimieren ihre Firewall-Lösungen, sodass zum Beispiel keinen Netzwerken mehr vertraut wird. Jedes Gerät wird für sich isoliert und behandelt jedes andere Gerät als Bedrohung. Es werden zum Beispiel nur Firewall-Ports geöffnet, wenn eine Anwendung diese braucht, und danach wieder geschlossen. So kann ein Gerät, falls es infiziert ist, nur sehr schwer weitere Geräte infizieren. Auch andere Hersteller gehen diesen Weg und etablieren ein Zero-Trust-Modell. Sicherheitszonen beziehen sich nicht mehr auf Standorte, sondern auf einzelne, kleinere Bereiche oder einzelne Geräte. In der IT werden diese Konzepte sehr zügig und bald umgesetzt, in der OT wird es Jahre dauern. Dadurch sind diese Systeme noch lange verwundbar, auch wenn es schon Lösungen gibt.

Auf den Worst Case vorbereitet sein

Desaster-Szenarien sollten getestet und geübt werden. Bei Bekanntwerden einer Schwachstelle können zum Beispiel Firewall-Verbindungen zwischen IT und OT gekappt werden, um einen Angriff zu unterbinden, um eine Ausbreitung zu stoppen oder schon vorhandene Verbindungen zu schließen, bis weitere Ressourcen organisiert werden können. Das alles gehört zu den bereits lange bekannten Anforderungen an die IT-Sicherheit und wird speziell in Bereichen wie Business Continuity Management (kurz: BCM) und Incident Management beschrieben. Es mangelt nur an der Umsetzung.

Deshalb versucht zum Beispiel das IT-Sicherheitsgesetz 2.0 auch von Gesetzes Seite her Druck zu machen. Weitere Normen wie die ISO 27001, und darin insbesondere KRITIS für kritische Infrastrukturen, oder die IEC 62443 für industrielle Sicherheit fordern schon lange einen besonderen Schutz für produzierende Unternehmen. Speziell ausgebildete und zertifizierte Experten können bei der Umsetzung dieser Vorgaben unterstützen. OT-Systeme dürfen auch nicht davon ausgehen, dass eine Selbstanzeige beim BSI oder aber das Hinzuziehen von externer Hilfe etwas Schlimmes ist. Aus Vorfällen können andere lernen und sich besser schützen.

Ein essenzielles Mittel, um OT-Sicherheit zu gewährleisten, sind auch ethische Hacks. IT-Partner scannen dabei die Systeme und decken Lücken auf, bevor es andere tun. Gefundene Schwachstellen werden evaluiert, beurteilt und behoben, idealerweise mit Support des Herstellers, notfalls aber auch ohne. Ethical Hacking sollte deshalb zum Standard werden.

OT-Sicherheit muss Priorität auf höchster Ebene werden

Unternehmen, die OT betreiben, kommen um Folgendes nicht herum: Dunkle Netzwerkflecken müssen so schnell wie möglich identifiziert werden. Know-how muss aufgebaut und Kompetenzen müssen gebündelt werden. Für schwierige Themen sollten sich OT-Betreiber auf externe Hilfe verlassen. OT-Partner können sich zum Beispiel bei Bekanntwerden einer Schwachstelle proaktiv bei Kunden melden, Lösungen vorschlagen und auch direkt umsetzen. An vielen Stellen vor Ort fehlen das Know-how und die Zeit dafür. Für den Bereich OT-Sicherheit müssen daher endlich Budgets freigegeben werden.

* Patrick Latus arbeitet als OT-Experte bei Mod IT Services GmbH.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:47972497)