Welche Trends treiben die OT-Sicherheit im Jahr 2026 überall voran.

In diesem heutigen Blogbeitrag erläutere ich, wie die ersten vier Monate des Jahres 2026 die OT-Sicherheit für immer verändert haben.

Bis vor wenigen Monaten gab es in Industrieanlagen überall noch eine bestimmte Art von Gespräch. Man betrat eine Standortbewertung mit Laptop und Klemmbrett, fragte das Engineering-Team nach dem Inventar ihres Leitsystems und beobachtete, wie sich der Raum höflich zurückzog. Die Ingenieure hatten zuvor bereits Gespräche mit IT-Security-Leuten geführt. Sie hatten Firewall-Diskussionen, Demonstrationen von Vulnerability Scannern und Prüfungen von Netzdiagrammen über sich ergehen lassen, die absolut keine Ähnlichkeit mit der tatsächlichen Produktionsumgebung hatten, die sie betrieben. Sie waren weitgehend zur Zusammenarbeit bereit, weil die unternehmensweite Compliance es erforderte  und kehrten danach wieder zu der Arbeit zurück, die dafür sorgte, dass die Lichter anblieben, das Produkt floss und der Prozess sicher lief. Diese Gespräche gerieten bei OT-Ingenieuren vollständig in Vergessenheit.

Dieses Gespräch hat sich nun grundlegend verändert.

Bevor wir fortfahren, vergessen Sie nicht, die neueste Ausgabe unseres Berichts zur OT-Sicherheitsbedrohungslage von hier herunterzuladen.

Vor einigen Monaten war ich in einer Midstream-Erdgasanlage im Rahmen einer recht routinemäßigen Architekturprüfung. Bevor ich den Prozess einleiten konnte, rief der Werksleiter – jemand, der seit dreiundzwanzig Jahren dort arbeitete und jede Ventil- und Kompressoreinheit an diesem Standort am Klang erkannte – einen Nachrichtenartikel auf seinem Telefon über einen industriellen Cyberangriff in einem anderen Sektor auf. Er legte das Telefon auf den Tisch und fragte ruhig: „Wie lange dauert es, einen PLC wiederherzustellen, wenn jemand die Firmware löscht?“

Nicht „Erfüllen wir unsere Compliance-Vorgaben?“. Nicht „Hat unser SCADA-System Antivirus?“. Oder sogar „Bis wann sind Sie hier?“. Er wollte die Wiederherstellungszeit wissen, weil er verstand, dass dies zuerst ein Produktionsproblem und erst danach ein Cybersicherheitsproblem ist.

Solche Fragen zeigen, wie stark sich die Lage verändert hat.   

Die Compliance-Ära hinterließ blinde Flecken, für die wir bis heute zahlen

Um zu verstehen, wo wir heute stehen, müssen Sie verstehen, wie wir hierhergekommen sind. Über weite Strecken von zwei Jahrzehnten wurde OT-Sicherheit vor allem durch regulatorische Compliance getrieben. NERC CIP im Energiesektor. CFATS im Chemiesektor. Verschiedene API- und ISO-Standards in Öl und Gas. Diese Rahmenwerke leisteten wichtige Arbeit. Sie zwangen Organisationen dazu, Geräteinventare aufzubauen, Zugriffskontrollen zu definieren und über elektronische Sicherheitszonen nachzudenken. Ohne sie wäre die Ausgangsbasis noch niedriger gewesen als heute.

Doch Compliance-Rahmenwerke haben eine inhärente und grundlegende strukturelle Begrenzung. Sie definieren einen Boden, aber keine Decke. In der OT-Sicherheit wurden Boden und Decke viel zu oft verwechselt.

Eine Organisation, die jede Anforderung ihres NERC CIP-Audits erfüllte, galt nach der eigenen Definition des Frameworks als sicher. Doch NERC CIP CIP-007 fragt, ob Sie wissen, welche Ports und Dienste auf Ihren BES Cyber System-Komponenten aktiviert sind. Es fragt nicht, ob ein Angreifer mit gültigen Fernzugriffs-Zugangsdaten und Kenntnis Ihrer Netzwerktopologie – möglicherweise aus einem GPT gewonnen – von Ihrem Unternehmensnetzwerk zu Ihrem Turbinen-Steuerungssystem gelangen kann, ohne irgendeinen Teil der überwachten Grenze zu berühren. Genau in dieser Lücke zwischen Compliance und tatsächlichem Risiko florierten die Bedrohungsakteure jahrelang unentdeckt.  

Der Angriff auf die Colonial Pipeline im Mai 2021 wurde zu dem Wendepunkt, den die Branche gefürchtet hatte. Die Ransomware kompromittierte Colonials operative Technologie nicht direkt, stattdessen war der Angriff primär auf das IT-Netzwerk beschränkt. Doch die Betreiber von Colonial konnten nicht mit Sicherheit bestätigen, was auf der OT-Seite betroffen war oder nicht, und angesichts dieser Unsicherheit trafen sie die einzig vertretbare Entscheidung, die ihnen zur Verfügung stand: Sie legten 5.500 Meilen Pipeline still. Nahezu die Hälfte der Kraftstoffversorgung der Ostküste wurde gestoppt – nicht, weil die operative Technologie zweifelsfrei kompromittiert worden war, sondern weil niemand sicher sein konnte, dass dies nicht der Fall war, und niemand wusste, welche Systeme betroffen waren.

Diese Unsicherheit, genauer gesagt dieser grundlegende Mangel an verifizierter Sichtbarkeit, war die eigentliche Schwachstelle. Und sie kostete um Größenordnungen mehr als jede Lösegeldzahlung gekostet hätte.

Ein OT-Vorfall ist etwas völlig anderes

Das ist der Punkt, den IT-Security-Experten manchmal erst dann wirklich verinnerlichen, wenn sie einen echten OT-Vorfall miterlebt haben. Ein OT-Sicherheitsereignis ist nicht einfach nur ein Datenvorfall mit angeschlossener Produktion.

Wenn ein Krankenhaus einen Ransomware-Angriff erleidet, sind die unmittelbaren Folgen Betriebsstörungen, ein potenzielles Risiko für die Patientensicherheit und Datenverlust. Alles ernst zu nehmen und eine dringende Reaktion erforderlich. Das Krankenhaus kann das Problem jedoch oft umgehen, indem es papierbasierte Prozesse einführt, Patienten in andere Einrichtungen verlegt oder kritische Systeme aus sauberen Backups wiederherstellt. Doch das sind keine einfachen Schritte, besonders mitten in einer Krise, wenn die Hälfte der Teams bereits gebunden ist.

Wenn hingegen ein Chlorierungssystem in einer Wasseraufbereitungsanlage einen unautorisierten Befehl erhält, um die Chemikalienzufuhr zu verändern, gibt es kein Umgehen des Problems. Es gibt keine kontrollierte Degradation. Die Chemie ist das Produkt. Die Physik ist der Prozess.  

Als die Triton-Malware 2017 in einem petrochemischen Werk im Nahen Osten gegen Safety Instrumented Systems eingesetzt wurde, waren die Angreifer nicht hinter Daten her. Sie waren nicht hinter Geld her. Sie versuchten, die letzte Linie automatisierter Sicherheitsfunktionen zu deaktivieren – das System, das speziell dafür entwickelt wurde, einen gefährlichen Prozess in einen sicheren Zustand zu überführen, wenn alle anderen Kontrollen versagen, mit der offensichtlichen Absicht, einen Prozess bis zu einem katastrophalen physischen Ergebnis laufen zu lassen. Dieses Bedrohungsmodell hat kein Gegenstück im IT-Security-Playbook.

Und dann gibt es noch NotPetya. Der Angriff im Juni 2017, weithin russischen militärischen Nachrichtendiensten zugeschrieben, war nominell auf die ukrainische Finanzinfrastruktur ausgerichtet. Doch er breitete sich wahllos über globale Unternehmensnetzwerke aus. Maersk, das Schifffahrts- und Logistikunternehmen, verlor praktisch sein gesamtes globales Netzwerk, einschließlich der Systeme, die weltweit Hafenterminalbetriebe steuerten. Der geschätzte Schaden allein für Maersk lag in der Größenordnung von 300 Millionen US-Dollar. Merck, Mondelez und Dutzende von Herstellern stellten fest, dass ihre Betriebs- und Unternehmensumgebungen weit weniger isoliert waren, als ihre Architekturdiagramme sie hatten glauben lassen. Niemand hatte den Blast Radius modelliert.

Die stille Entwicklung: Von Asset-Transparenz zu Denken in Angriffspfaden

Hier hat das Fachgebiet tatsächlich in einer Weise an Reife gewonnen, die Anerkennung verdient, und hier findet derzeit die folgenreichste Arbeit statt.

Über Jahre war das erklärte Ziel der OT-Netzwerksicherheit die Asset-Transparenz. Wissen, welche Geräte in Ihrem Netzwerk existieren. Verstehen, welche Protokolle sie sprechen. Anomalien gegenüber einer Verhaltensbasis erkennen. Das war der Kernnutzen jeder passiven OT-Monitoring-Implementierung, jeder industriellen NDR-Plattform, jeder Asset-Discovery-Initiative. Und es bleibt grundlegende, unverzichtbare Arbeit. Sie können nicht schützen, was Sie nicht sehen.

Aber Asset-Transparenz allein ist nur passives Wissen. Sie sagt Ihnen, was existiert. Sie sagt Ihnen nicht, was ein Angreifer mit dem Vorhandenen tun würde oder wie er es angreifen wird.

Denken in Angriffspfaden stellt eine strukturell andere Frage: Ausgehend von jedem entdeckten Asset, jeder gemappten Netzwerkverbindung und jeder identifizierten Schwachstelle – welcher ist der tragfähigste Pfad von einem initialen Einstiegspunkt zum Ziel mit den höchsten Konsequenzen? Nicht „Habe ich einen PLC in meinem Netzwerk?“, sondern „Wenn ein Angreifer zunächst Zugriff auf meinen Historian-Server erlangt, welche Sequenz von lateralen Bewegungen, über welches Protokoll, über welche Vertrauensbeziehung, unter Ausnutzung welcher Authentifizierungsschwäche führt von diesem Historian zu meinem Controller des safety instrumented system?“

Das ist keine akademische Threat-Modelling-Übung. Es ist operative Sicherheitsgestaltung, und die Angreifer, die industrielle Umgebungen ins Visier nehmen, praktizieren sie seit Jahren diszipliniert.

Die Angreifergruppen, die sich auf Industrial-Control-System-Umgebungen spezialisieren und von Organisationen wie Shieldworkz sowie Regierungsbehörden einschließlich CISA verfolgt und charakterisiert werden, zeigen in ihren Taktiken ein vorab detailliertes Wissen über die Architekturen ihrer Ziele. Die gegen ukrainische Hochspannungs-Umspannwerke eingesetzte Industroyer2-Malware enthielt im April 2022 fest kodierte Zielerfassung für IEC 104-Kommunikation, ein spezifisches industrielles Automatisierungsprotokoll, das in Stromversorgungssystemen verwendet wird. Diese Fähigkeit entsteht nicht aus einem generischen Intrusion-Toolkit. Sie spiegelt Angreifer wider, die die Zielumgebung studiert, ihre Betriebsprotokolle verstanden und ihren Angriff um den bereits kartierten Angriffspfad herum aufgebaut haben.

Die CISA-Hinweise und gemeinsamen Regierungsveröffentlichungen zu Volt Typhoon im Verlauf des Jahres 2023 und bis 2024 beschrieben etwas ebenso Besorgniserregendes, aber in der Art Unterschiedliches: einen staatlich unterstützten chinesischen Akteur, der langfristig und bewusst eine Vorpositionierung innerhalb von Netzwerken kritischer US-Infrastruktur aufbaute und dabei gezielt Living-off-the-land-Techniken einsetzte, um keine anomalen Aktivitäten zu erzeugen, die konventionelles Monitoring markieren würde. Ziel war nicht die unmittelbare Störung. Ziel war der stille Aufbau dauerhafter Zugänge – als Reserve vorgehaltene Angriffspfade, die zu einem Zeitpunkt strategischer Wahl aktiviert werden konnten.

Wenn Ihr Sicherheitsprogramm primär auf Malware-Signaturen und Richtlinienverstöße ausgerichtet ist, werden Sie diese Angreiferklasse nicht erkennen. Wenn Ihr Programm umfassende OT-Asset-Transparenz, Verhaltensanalyse auf Protokollebene und – entscheidend – ein kartiertes Verständnis davon umfasst, welche Assets tragfähige Sprungbretter zu Ihrer kritischsten operativen Technologie darstellen, dann haben Sie eine echte Fähigkeit, sie zu erkennen und darauf zu reagieren.

Was Vorstände verstehen müssen

Die Vorstandsdiskussion hat sich verändert, aber nicht immer in die richtige Richtung. Ein neues Muster ist entstanden: Führungskräfte nehmen an einem Cybersecurity-Briefing teil, nehmen die Botschaft auf, dass OT-Angriffe real und folgenreich sind, und gehen mit einem vagen Auftrag hinaus, „etwas zu tun“. Budgets werden zugewiesen. Monitoring-Plattformen werden gekauft. Berater werden beauftragt. Und achtzehn Monate später hat die Organisation ein gut konfiguriertes Asset-Inventar, ein befülltes Dashboard und kein operationalisiertes Verständnis dafür, was um 2 Uhr morgens an einem Samstag zu tun ist, wenn dieses Dashboard einen kritischen Alarm auslöst.

Die richtige Frage des Vorstands lautet nicht „Haben wir ein OT-Sicherheitsprogramm?“. Die richtige Frage lautet: „Wenn unser primäres Steuerungssystem für den Kompressor an unserem größten Standort morgen früh nicht verfügbar wäre, wie lange dauert es bis zum sicheren Zustand, welche Produktionsauswirkung hat jede Ausfallstunde, und wie lange dauert es, bis wir mit verifizierter Sicherheit hinsichtlich der Integrität des Systems zum Vollbetrieb zurückkehren können?“

Wenn Ihre Sicherheitsleitung diese Frage nicht präzise beantworten kann, sollte den Vorstand das beunruhigen. Wenn Ihr Engineering-Team im Betrieb dieses Szenario nie in einer strukturierten Übung durchgespielt hat, weist Ihre Incident-Response-Fähigkeit eine Lücke auf, die kein Technologiekauf schließen wird.

Die Versicherungsbranche verstand diese Rechnung früher als weite Teile der Security-Community. Cyber-Versicherer, die OT-Umgebungen prüften, stellten mit zunehmender technischer Präzision Fragen wie: Wie sieht die Segmentierungsarchitektur zwischen Ihrem Unternehmensnetzwerk und Ihrem Level-2-Steuernetzwerk aus? Kann ein Bediener von einem privaten Gerät aus eine Remote-HMI-Sitzung initiieren? Wie läuft der Wiederherstellungsprozess für eine PLC-Konfiguration nach einem Firmware-Korruptionsereignis ab, und wie lange dauert er? Das sind keine generischen Cybersicherheitsfragen. Das sind Fragen zu Wiederherstellungszielen für die physische Prozesssteuerung, und die Antworten bestimmen direkt das versicherungsmathematische Risikomodell und damit die Prämie.

Die Organisationen, die diese Fragen mit Sicherheit und Präzision beantworten, sind diejenigen, die die harte, wenig glamouröse Arbeit geleistet haben – nicht nur Technologieeinsatz, sondern Konsequenzmodellierung und Recovery Engineering.

Die geopolitische Dimension, die Praktiker nicht länger ignorieren können

Ich möchte etwas ansprechen, was die technische Community manchmal nur widerwillig direkt anerkennt: OT-Sicherheit ist inzwischen ein explizites Thema der nationalen Sicherheit, und so zu handeln, als gehöre dieser Kontext nicht in Ihr Bedrohungsmodell, ist ein professioneller Fehler.

Die Angriffe auf die ukrainische Stromverteilungsinfrastruktur im Dezember 2015 und Dezember 2016 – ausgeführt mit BlackEnergy und anschließend mit der deutlich ausgefeilteren Industroyer-Plattform – waren keine kriminellen Kampagnen. Es waren militärische Operationen gegen zivile kritische Infrastruktur, die darauf ausgelegt waren, inmitten eines aktiven bewaffneten Konflikts physische Folgen für die Zivilbevölkerung zu verursachen. Die Angriffe auf US-Wasserversorger im Jahr 2023, die Akteuren mit Verbindung zum IRGC des Iran zugeschrieben wurden – und die Anlagen ins Visier nahmen, auf denen bestimmte Modelle von Unitronics PLCs liefen, wobei sichtbare Nachrichten auf den Bedienerbildschirmen hinterlassen wurden – waren kalibrierte Demonstrationen. Die Botschaft war eindeutig: Diese Infrastruktur ist erreichbar, wir kennen Ihre Ausrüstung, und wir entscheiden uns, Ihnen dies zu zeigen, statt Ihnen zu schaden. Es ist keineswegs garantiert, dass diese Zurückhaltung unter anderen geopolitischen Bedingungen Bestand haben wird.

Regierungen haben mit ungewöhnlicher Dringlichkeit reagiert. Die TSA Pipeline Security Directives, die im Zuge des Colonial-Pipeline-Angriffs erlassen wurden, verpflichteten Pipeline-Betreiber zu Netzwerksegmentierung, Monitoring und Incident-Response-Fähigkeiten auf eine Weise, die vor einem Jahrzehnt politisch undenkbar gewesen wäre. Die NIS2-Richtlinie der Europäischen Union erweiterte die verpflichtenden Cybersicherheitsanforderungen auf Betreiber essenzieller Dienste in den Bereichen Energie, Wasser, Fertigung und Verkehr in einer Weise, die OT-Sicherheitsprogramme unmittelbar betrifft. Die sektorübergreifenden OT-Sicherheitsleitlinien von CISA sind mit jeder Iteration technisch deutlich präziser geworden.

Das ist kein bürokratischer Mehraufwand. Das ist die formale Anerkennung durch Staaten, dass Produktionskapazitäten, Energieversorgungsinfrastrukturen und Wasserversorgung strategische nationale Vermögenswerte sind, deren Resilienz ebenso eine Verteidigungsfrage wie eine Frage der Geschäftskontinuität ist.

Für Praktiker vor Ort bedeutet das in der Praxis: Ihr Bedrohungsmodell kann nicht länger allein durch kriminelle Ransomware-Gruppen definiert werden, die auf finanziellen Gewinn aus sind. Sie befinden sich potenziell im Zielkalkül staatlich unterstützter Akteure mit langen operativen Zeithorizonten, dem Ziel dauerhafter Zugänge und dem Interesse, Optionen für physische Störungen in einer Größenordnung und zu einem Zeitpunkt ihrer strategischen Wahl bereitzuhalten. Ihre Architektur, Ihr Monitoring und Ihr Attack-Path-Modelling müssen für diese Realität ausgelegt sein – selbst wenn Sie Ihr gesamtes Berufsleben damit verbringen, zu hoffen, dass Sie es nie benötigen.

Wo die eigentliche Arbeit stattfindet

Die Technologie hat sich erheblich verbessert. Führende OT-Network-Detection-and-Response-Plattformen können heute Dinge tun, die vor einem Jahrzehnt bemerkenswert gewesen wären: passive, protokollnative Dekodierung industrieller Kommunikation über Modbus, DNP3, EtherNet/IP, PROFINET, IEC 61850, Siemens S7 und andere; Verhaltens-Anomalieerkennung, abgestimmt auf industrielle Prozesszyklen statt auf IT-Traffic-Muster; Korrelation von Schwachstellen mit spezifischen Firmware-Versionen anhand von ICS-CERT-Hinweisen und Hersteller-Sicherheitsbulletins; sowie Integration in Security-Operations-Center-Plattformen, die den Kontext der Kritikalität von Assets mitführen, sodass der Analyst, der einen Alarm erhält, versteht, um welche Art von Gerät es sich handelt und welche Konsequenz ein Ereignis auf diesem Gerät haben könnte.

Die Plattformen sind nicht das Problem.

Die Lücke liegt in der Operationalisierung. Ein OT-Monitoring-Sensor, der um 2 Uhr morgens an einem Feiertagswochenende einen Alarm für anomalen DNP3-Verkehr an einer Remote Terminal Unit auslöst, hilft Ihnen nicht, wenn Ihr SOC-Analyst nicht weiß, was DNP3 ist, Ihr Incident-Response-Verfahren lautet „an IT-Security eskalieren“, und niemand diese RTU dem physischen Prozess zugeordnet hat, den sie steuert, oder dokumentiert hat, wie eine unautorisierte Anweisung an sie in operativer Hinsicht aussehen würde.

Die Organisationen, die echte, nachhaltige Fortschritte erzielen, sind diejenigen, die die wenig glamouröse Arbeit erledigen. Fortlaufende physische Begehungen, um zu verifizieren, dass Netzwerk-Topologiediagramme dem entsprechen, was im Feld verkabelt ist – was fast nie der Fall ist, besonders nach Jahren inkrementeller Änderungen. Gemeinsame Tabletop-Übungen, in denen Steuerungssystem-Ingenieure und Security-Analysten dasselbe Angriffsszenario aus ihren unterschiedlichen Wissensbasen heraus bearbeiten und in einer risikofreien Umgebung entdecken, wie wenig sie jeweils von der Welt des anderen verstehen. Kritikalitäts-Mapping, das vom P&ID und der Engineering-Design-Dokumentation bis hin zu den Informationen reicht, die einem SOC-Analysten jetzt zu einem Alarm zur Verfügung stehen. Dokumentierte und getestete Wiederherstellungsverfahren – und nicht nur dokumentiert, sondern physisch getestet, weil es keinen Ersatz dafür gibt, vor einem aktiven Vorfall herauszufinden, dass Ihr PLC-Backup-Wiederherstellungsprozess vier Stunden statt fünfundvierzig Minuten dauert.

Dort liegt die Sicherheit tatsächlich. Nicht in der Plattform. In den Menschen, die sowohl den industriellen Prozess als auch den Angreifer gut genug verstehen, um auf die Informationen zu reagieren, die die Plattform sichtbar macht.

Der psychologische Wandel

Ich komme auf den Werksleiter mit dem Telefon zurück. Dreiundzwanzig Jahre im Job, verantwortlich für eine Anlage, die täglich Millionen Kubikfuß Erdgas verarbeitet, und er kennt seine Anlagen so, wie ein Chirurg die Anatomie kennt. Er fragt nach den Wiederherstellungszeiten von PLC.

Dieses Gespräch fand nicht statt, weil im letzten Quartal ein NDR-Sensor installiert wurde. Es fand statt, weil sich eine Kette von Ereignissen – sichtbare Pipeline-Stillstände in den nationalen Nachrichten, Vorfälle in der Wasserversorgung auf den Titelseiten, Produktionsanlagen, die durch Infektionen dunkel wurden, die im Rechnungswesen begannen, Regierungsanweisungen mit Durchsetzungskraft, Versicherungsverlängerungen, die Antworten auf unbequeme Fragen verlangten – so weit aufaddiert hatte, dass die psychologische Abstraktion von „Cyber-Risiko“ endlich in die operative Konkretheit von „mein Prozess, meine Ausrüstung, meine Leute, meine Verantwortung“ zusammenbrach.

Dieser Wandel ist strategisch wertvoller als jede Technologieeinführung. Sie können die leistungsfähigste OT-Monitoring-Plattform in einer Anlage installieren, in der der Betrieb nicht versteht, warum sie wichtig ist, und sie wird Alarme erzeugen, auf die niemand reagiert, Dashboards, die niemand liest, und Berichte, die bis zum jährlichen Compliance-Audit in einem SharePoint-Ordner liegen. Sie können hingegen eine Anlage haben, in der das Engineering-Team das Bedrohungsmodell wirklich verinnerlicht hat, und es wird technologische Grenzen kompensieren, Anomalien durch Prozessintuition erkennen und unter Druck bessere Entscheidungen treffen, als es jedes Tool anstoßen könnte.

Die Rolle des Security-Praktikers in diesem Umfeld ist nicht rein technisch. Sie besteht zu einem erheblichen Teil aus Übersetzungsarbeit zwischen der Threat-Intelligence-Community und der Betriebsingenieur-Community, zwischen der Compliance-Anforderung und dem tatsächlich zugrunde liegenden Risiko, zwischen dem Alarm, den die Plattform erzeugt, und dem menschlichen Urteilsvermögen, das er unterstützen muss.

Der Werksleiter, der nach den PLC-Wiederherstellungszeiten fragt, ist keine Managementherausforderung, die bearbeitet werden muss. Er ist eine Sicherheitsfähigkeit, die entwickelt werden muss.

Cultivieren Sie 2026 und darüber hinaus mehr davon.

Bereit für toolgestützte OT-Sicherheitsbewertungen? Sprechen Sie jetzt mit uns.