Die Wurzelursachenanalyse im ICS-Kontext verstehen

Industrielle Steuerungssysteme (Industrial Control Systems, ICS) bilden das Rückgrat kritischer Infrastrukturen – Stromnetze, Wasseraufbereitungsanlagen, Ölraffinerien und chemische Produktionsanlagen. Da diese Umgebungen digitale Konnektivität und IIoT-Geräte (Industrial Internet of Things) umfassen, dehnt sich die Angriffsfläche dramatisch aus. Im Gegensatz zu typischen IT-Verstößen kann ein Kompromiss in einem ICS zu physischen Schäden, Umweltkatastrophen oder zum Verlust von Menschenleben führen. Die Ursachenanalyse (Root Cause Analysis, RCA) in diesem Bereich ist nicht nur eine Übung nach einem Vorfall; es ist eine proaktive Ingenieurdisziplin, die unmittelbare Symptome hinter sich lässt, um die systemischen Schwächen aufzudecken, die einen Verstoß ermöglicht haben.

RCA in ICS unterscheidet sich von IT-Sicherheitsforensik, weil es Betriebstechnologie (OT) Einschränkungen berücksichtigen muss: Legacy-Protokolle, die keine Verschlüsselung haben, Echtzeit-Kontrollschleifen, die Latenzzeiten nicht tolerieren können, und Sicherheitslebenszyklen, die durch Sicherheitspatches gestört werden können. Eine gründliche RCA schließt die Lücke zwischen IT-Forensik-Methodik und OT-Engineering-Realität und hilft Unternehmen zu erkennen, ob ein Verstoß auf einen technischen Fehler, eine Verfahrenslücke oder eine Fehlausrichtung zwischen Sicherheitsprioritäten zurückzuführen ist.

Häufige Ursachen für ICS Cybersecurity-Verstöße

Obwohl jeder Vorfall einzigartig ist, treten Muster bei ICS-Verstößen auf. Das Verständnis dieser gemeinsamen Ursachen hilft Unternehmen, ihre defensiven Ressourcen zu konzentrieren.

Schwache Passwörter und unzureichende Authentifizierung

Viele ICS-Systeme sind immer noch auf Standardanmeldeinformationen angewiesen, die über mehrere Geräte hinweg geteilt werden, oder auf fest codierte Passwörter in programmierbaren Logiksteuerungen (PLCs). Der Angriff auf Ransomware in der Colonial Pipeline im Jahr 2021, obwohl er in erster Linie ein IT-Kompromiss ist, hat gezeigt, wie schwache Authentifizierung bei Remote-Access-Tools zu lateralen Bewegungen in OT-Umgebungen führen kann. Die Ursache ist oft nicht nur das Passwort selbst, sondern ein Mangel an Richtlinien, die starke, eindeutige Anmeldeinformationen und Multi-Faktor-Authentifizierung (MFA) erfordern für alle ICS-Zugangspunkte.

Unpatched Software und Firmware-Schwachstellen

Industrielle Systeme laufen häufig auf veralteten Betriebssystemen wie Windows 7 oder XP, und Patch-Zyklen können sich aufgrund von Kompatibilitätstests mit Steuerungsanwendungen über Monate oder Jahre erstrecken. Dies schafft ein Expositionsfenster für bekannte Schwachstellen. Der Triton/Trisis-Angriff auf eine saudische petrochemische Anlage im Jahr 2017 nutzte Sicherheitslücken in der Triconex-Sicherheitssteuerung von Schneider Electric aus - ein Gerät, das nicht gepatcht wurde, weil die Betreiber eine Störung der Sicherheitsfunktionen befürchteten. Die Ursache war ein Bereitstellungsprozess, der die Verfügbarkeit über die Sicherheitshygiene stellte, ohne eine kompensierende Kontrollstrategie.

Fehlende Netzwerksegmentierung zwischen IT und OT

Flache Netzwerke sind die größte strukturelle Schwäche in ICS-Umgebungen. Wenn Unternehmens-IT und Steuerungsnetzwerke nicht richtig über Firewalls, DMZs oder Einwegdioden segmentiert werden, kann eine Phishing-E-Mail, die ein Geschäftssystem kompromittiert, Angreifern erlauben, sich in das Steuerungsnetzwerk zu bewegen. Der Angriff auf das ukrainische Stromnetz 2015 war teilweise erfolgreich, weil die Angreifer das IT-Netzwerk nutzten, um das ICS-Netzwerk zu erreichen, eine direkte Folge unzureichender Segmentierung. Die Ursache ist oft ein Topologie-Design, das das Unternehmensnetzwerk als vertrauenswürdig behandelt und die Realität ignoriert, dass Angreifer jeden verfügbaren Weg ausnutzen werden.

Insider-Drohungen: Böswillig und zufällig

Insider-Bedrohungen in ICS können von einem verärgerten Ingenieur, der eine SPS so umprogrammiert, dass sie eine Fehlfunktion verursacht, bis hin zu einem Auftragnehmer reichen, der versehentlich einen mit Malware infizierten Laptop mit dem OT-Netzwerk verbindet. Eine Studie des Ponemon Institute aus dem Jahr 2019 ergab, dass Insider für fast 25% der ICS-Vorfälle verantwortlich sind. Die Ursache ist häufig eine Kombination aus unzureichenden Zugriffskontrollen, fehlender Verhaltensanalyse und einer Kultur, die Komfort über die Sicherheit stellt.

Unzureichende Überwachungs- und Erkennungsmöglichkeiten

Viele ICS-Umgebungen haben keine Endpunkterkennung und -antwort (EDR), Netzwerküberwachung oder SIEM-Systeme (Sicherheitsinformations- und Ereignismanagement), die auf OT-Protokolle abgestimmt sind. Ohne Sichtbarkeit des Netzwerkverkehrs wie Modbus, DNP3 oder PROFINET kann sich ein Angreifer Wochen oder Monate vor der Entdeckung seitlich bewegen. Der NotPetya-Angriff 2017 betraf zahlreiche ICS-Organisationen, aber in vielen Fällen war die Malware bereits in internen Netzwerken vorhanden, bevor die Wischkomponente aktiviert wurde. Die Ursache war eine Überwachungslücke, die den ursprünglichen Kompromiss nicht erkannte. Wie SANS ICS-Umfragen durchweg zeigen, erkennen Organisationen, die in OT-spezifische Überwachung investieren, Verstöße dreimal schneller als diejenigen, die allein auf IT-Tools angewiesen sind.

Methoden zur Durchführung der Wurzelursachenanalyse in ICS

RCA ist ein strukturierter Prozess. Während IT Incident Response Frameworks einen Ausgangspunkt bieten, beinhalten ICS-spezifische Methoden den operativen Kontext. Die folgenden Ansätze werden in industriellen Umgebungen weit verbreitet eingesetzt.

Die 5 Whys

Ursprünglich von Toyota entwickelt, ist die 5 Whys-Technik täuschend einfach: Fragen Sie "Warum" wiederholt, bis die zugrunde liegende Ursache auftritt. Zum Beispiel, warum ist das Sicherheitssystem ausgefallen? Weil eine veraltete Firmware es einem Angreifer ermöglichte, sie zu umgehen. Warum war die Firmware veraltet? Weil der Patch nicht für die spezifische Sicherheitsfunktion getestet worden war. Warum wurde der Test verzögert? Weil es keinen automatisierten Testgurt gab. Warum gab es keinen Testgurt? Weil das Budget neue Geräte über Validierungswerkzeuge priorisierte. Die Ursache könnte eine Entscheidung über Ressourcenzuweisung sein, kein technischer fehlender Patch. Die 5 Whys funktionieren gut für Single-Thread-Vorfälle, können aber systemische Interaktionen verpassen.

Fischgräten (Ishikawa)

Auch bekannt als Ursache-Wirkungs-Analyse organisiert das Fischgrätendiagramm mögliche Ursachen in Kategorien wie Personen, Prozesse, Technologien, Umgebung und Verfahren. Für einen ICS-Verstoß können Kategorien Folgendes umfassen: Menschen (Training, Bewusstsein, Insideraktionen), Prozess (Änderungsmanagement, Patching-Zyklen, Incident Response Playbooks), Technologie (Authentifizierung, Segmentierung, Backend-Design) und Externe Faktoren (Verkäufer-Schwachstellen, regulatorische Lücken). Ein Team bildet jeden beitragenden Faktor ab und verfolgt ihn zurück zum Rückgrat des Diagramms (der Verstoß). Diese Methode ist ideal für komplexe Vorfälle mit mehreren ineinandergreifenden Fehlern.

Fehlerbaumanalyse (FTA)

FTA ist eine in der Sicherheitstechnik häufig verwendete deduktive Methode von oben nach unten, die jedoch gleichermaßen auf Sicherheitsverletzungen anwendbar ist. Beginnend mit dem unerwünschten Ereignis (dem Verstoß) arbeiten Analysten rückwärts mit Logikgattern (UND, OR), um Kombinationen von Fehlern zu identifizieren, die das Ereignis verursachen könnten. FTA ist besonders nützlich in ICS, weil es die Sicherheitsanalyse widerspiegelt, die Ingenieure bereits durchführen. Zum Beispiel kann ein Verstoß auftreten, wenn (A) die Firewall falsch konfiguriert ist UND (B) das Antivirus veraltet ist UND (C) das Anomalieerkennungssystem nicht überwacht wird. Diese Strenge hilft, Korrekturmaßnahmen zu priorisieren, die die kritischsten Logikpfade unterbrechen.

Der RCA-Prozess in fünf Phasen

  1. Phase 1: Datenerfassung und -erhaltung — Forensische Bildgebung von Controllern, Historikern, Engineering-Arbeitsplätzen und Netzwerkprotokollen. In OT muss dies sorgfältig erfolgen, um kritische Prozesse nicht zu stören. Verwenden Sie nach Möglichkeit Lesezugriff und konsultieren Sie Betriebsingenieure, bevor Sie die Stromversorgung von Geräten beziehen.
  2. Phase 2: Event Timeline Reconstruction — Korrelierende Protokolle sowohl aus IT- als auch aus OT-Quellen. ICS-Umgebungen haben oft Zeitsynchronisationsprobleme (verschiedene Geräte mit unterschiedlichen NTP-Servern oder gar keine), daher ist die Zeitnormalisierung entscheidend. Tools wie Wireshark mit OT-Dissektoren können bei der Rekonstruktion von Paketsequenzen helfen.
  3. Phase 3: Vulnerability Identification — Zuordnung des Angriffspfads zu spezifischen Schwachstellen, die nicht nur technische Schwachstellen (CVEs) umfassen, sondern auch verfahrenstechnische Lücken, wie z. B. fehlende Hintergrundüberprüfungen für Auftragnehmer oder das Fehlen eines formellen Change Review Boards.
  4. Phase 4: Root Cause Determination — Anwendung einer oder mehrerer Methoden (5 Whys, Fishbone, FTA), um den grundlegenden Grund zu konvergieren. Oft ist die Ursache eine Kombination aus einer technischen Schwachstelle und einem Prozessfehler.
  5. Phase 5: Entwicklung und Verifizierung von Korrekturmaßnahmen — Durchführung von Maßnahmen, die die Ursache, nicht nur die Symptome, angehen. Gemeinsame Maßnahmen umfassen das Neugestalten der Netzwerkarchitektur, das Härten von Gerätekonfigurationen, das Implementieren automatisierter Patch-Management-Sandboxen und die Einführung einer OT-bewussten Intrusion Detection. Jede Aktion sollte vor dem Einsatz in der Produktion in einer Staging-Umgebung getestet werden.

Einzigartige Herausforderungen von RCA in ICS-Umgebungen

Die Durchführung von RCA in einem industriellen Steuerungssystem stellt Hürden dar, die in der IT-Sicherheit selten anzutreffen sind.

Legacy Technology und proprietäre Protokolle

Viele ICS-Geräte sind seit 15-30 Jahren in Betrieb und laufen mit Firmware, die nicht gepatcht oder sogar protokolliert werden kann. Proprietäre Protokolle von Anbietern wie Siemens, Rockwell oder ABB haben möglicherweise keine nativen Sicherheitsfunktionen oder standardisierte Protokollierung. Analysten benötigen oft fundiertes technisches Wissen, um das Geräteverhalten zu interpretieren. Tools wie CISAs ICS-CERT-Beratungen bieten Anleitung zu bekannten Schwachstellen, aber das RCA-Team muss auch den operativen Kontext verstehen - wie zum Beispiel welche Register ein Ventil steuern oder welche Leiterlogik eine Pumpe steuert.

Sicherheit über Sicherheitsbeschränkungen

Eine RCA darf keinesfalls eine Korrekturmaßnahme empfehlen, die gegen Sicherheitsprotokolle verstößt. So kann es sicher erscheinen, wenn ein Ingenieur während eines Notfallabschaltungsverfahrens gesperrt wird, könnte jedoch das Leben von Menschen gefährdet sein. Die Ursachenanalyse muss Sicherheitsingenieure und Referenznormen wie ISA-62443 (IEC 62443) einbeziehen, die Sicherheit mit funktionaler Sicherheit in Einklang bringen.

Begrenzte forensische Fähigkeiten

Im Gegensatz zu IT-Servern verfügen viele SPS und RTUs nicht über dauerhaften Speicher für Protokolle. Ereignisdaten können in flüchtigen Speichern gespeichert werden, die beim Neustart verschwinden. Forensische Tools, die für ICS entwickelt wurden, wie z. B. von Dragos oder Nozomi Networks, können Zustandsinformationen erfassen, sind aber nicht universell einsetzbar. RCA stützt sich daher häufig auf indirekte Beweise - Betreiberinterviews, Schiebeprotokolle und historische Daten -, was eine sorgfältige Bestätigung erfordert.

Regulierungs- und Compliance-Druck

Industriezweige wie Energie, Wasser und chemische Fertigung unterliegen Vorschriften (NERC CIP, NIST SP 800-82, EU NIS-Richtlinie), die spezifische RCA-Verfahren vorschreiben können. Die Analyse muss einen Bericht erstellen, der die Auditoren zufrieden stellt, ohne dass sensible Schwachstellen aufgedeckt werden, die ausgenutzt werden könnten. Transparenz und Vertraulichkeit sind eine Fähigkeit, die RCA-Teams entwickeln müssen.

Aufbau eines effektiven RCA-Programms für ICS

RCA sollte keine einmalige Übung nach jedem Verstoß sein, sondern in die Sicherheits-Governance der Organisation integriert werden.

Vorbereitung vor dem Vorfall

Bevor ein Verstoß eintritt, definieren Sie das RCA-Team: eine Mischung aus IT-Sicherheitsexperten, OT-Ingenieuren, Steuerungssystembetreibern und Management. Vorautorisieren Sie den schreibgeschützten Zugriff auf Schlüsselsysteme und erstellen Sie eine Verwahrkette für forensische Beweise. Dokumentieren Sie die Netzwerkarchitektur, den Bestand an Vermögenswerten und bekannte Abhängigkeiten. Organisationen, die eine Baseline des normalen Betriebs haben, können Anomalien während einer RCA schneller erkennen.

Toolauswahl und Integration

Investitionen in Tools, die Transparenz in OT-Umgebungen bieten. Netzwerküberwachungs-Appliances, die Modbus, DNP3 und OPC-UA-Datenverkehr analysieren können, sind unerlässlich. Endpoint-Agenten, die für eingebettete Systeme (wie die von Microsoft Defender für IoT oder Armis) entwickelt wurden, können Telemetrie sammeln, ohne die Steuerung zu destabilisieren. Zentralisiertes Logging mit zeitsynchronisierten Datenfeeds ermöglicht eine Korrelation zwischen IT- und OT-Ereignissen. Eine gute RCA sollte in der Lage sein zu antworten: "Wie hat der Angreifer zuerst auf das OT-Netzwerk zugegriffen, welche Befehle wurden gesendet und welche Assets wurden betroffen?"

Lernen nach Zwischenfällen und kontinuierliche Verbesserung

Nachdem ein RCA-Bericht veröffentlicht wurde, verfolgen Sie die Umsetzung von Korrekturmaßnahmen. Erstellen Sie eine vierteljährliche Überprüfung, in der bewertet wird, ob die Maßnahmen das Risiko tatsächlich reduziert haben. Wenn die Ursache beispielsweise in einer mangelnden Segmentierung liegt, überprüfen Sie, ob die neuen Firewall-Regeln durchgesetzt wurden und dass keine Ausnahmen stillschweigend hinzugefügt wurden. Teilen Sie anonymisierte Lektionen in der gesamten Branche durch Informationsaustauschgruppen wie CISAs Automated Indicator Sharing (AIS) für ICS oder das ISA Security Compliance Institute. Dieses kollektive Lernen hilft dem gesamten Sektor, seine Sicherheitsbasis zu erhöhen.

Illustrative Fallstudie: Lehren aus einem hypothetischen ICS-Verstoß

Hinweis: Das folgende Beispiel wird aus gemeinsamen Mustern aufgebaut, die von Sicherheitsforschern beobachtet werden. Es stellt keinen spezifischen Vorfall dar, sondern synthetisiert typische Ursachen.

Ein mittelgroßes Wasserversorgungsunternehmen erlebte einen Verstoß, der dazu führte, dass Pumpen mit unsicheren Geschwindigkeiten betrieben wurden, was zu Notausfällen führte. Erste Symptome wiesen auf eine bösartige Nutzlast in der HMI-Software (Human Machine Interface) hin. Ein RCA-Team verwendete die Fischgrätenmethode und identifizierte beitragende Faktoren: Das HMI führte Windows 7 ohne Sicherheitsupdate aus, das Remote Access VPN verwendete eine Einzelfaktor-Authentifizierung, die von 12 Betreibern geteilt wurde, und Netzwerkprotokolle zeigten den Datenverkehr vom Unternehmens-IT-Segment zum Steuerungsnetzwerk, der nicht von der IT-Firewall markiert worden war (da es nur den Nord-Süd-Verkehr überwachte, nicht Ost-West). Die Ursache war der Mangel an Segmentierung in Kombination mit einer unsicheren Fernzugriffsrichtlinie. Korrekturmaßnahmen beinhalteten die Bereitstellung einer DMZ mit einer Einweg-Datendiode, die Implementierung von MFA für alle Fernverbindungen und die Einrichtung einer automatisierten Patch-Sandbox für HMI-Updates. Die RCA enthüllte auch, dass kein Verfahren zur Überprüfung von Fernzugriffssitzungen existierte - eine Prozesslücke, die anschließend behoben

Dieser Fall zeigt, dass die Ursache nicht eine einzelne Schwachstelle war, sondern eine Kombination aus Technologielücken und Prozessausfällen. Durch die Adressierung beider Aspekte konnte das Dienstprogramm nicht nur von dem Vorfall erholt werden, sondern auch eine belastbarere Steuerungsumgebung aufbauen.

Fazit: Einbettung von RCA als kontinuierlicher Prozess

Die Ursachenanalyse ist kein postmortales Ritual; sie ist eine strategische Fähigkeit, die Vorfälle in Lernmöglichkeiten verwandelt. In industriellen Kontrollsystemen, in denen die Kosten des Versagens physische Schäden und öffentliche Sicherheitsrisiken beinhalten, ist die Fähigkeit, Ursachen systematisch aufzudecken und zu beseitigen, unerlässlich. Durch die Einführung strukturierter Methoden, die Achtung der einzigartigen Einschränkungen von OT-Umgebungen und den Aufbau eines dedizierten Programms können Unternehmen von der reaktiven Brandbekämpfung zu proaktiver Widerstandsfähigkeit übergehen. Das ultimative Ziel ist es, jeden Verstoß - wie schmerzhaft er auch sein mag - als Sprungbrett für eine sicherere und zuverlässigere industrielle Infrastruktur zu dienen.