Unsere ganzheitliche Lösung für Sicherheitsvorfälle und funktionelle Fehler

Ausgehend vom GridOps Alarme Dashboard untersuchen wir einen Alarm, der vom StationGuard IDS-Sensor im Umspannwerk mit dem Namen “UW München Nord” gemeldet worden ist.

Ein integraler Bestandteil unserer StationGuard-Lösung ist das GridOps Alarme Dashboard. Sein Zweck ist es, zusammenzufassen, was genau in Ihrem System passiert ist.

Wir verwenden die Ansicht auf Sensorebene, um den spezifischen Alarm und seine Netzwerkumgebung weiter zu untersuchen, wie unten dargestellt.

Innerhalb des Dashboards können Sie von der Übersicht auf Stromnetzebene bis hinunter zum Netzwerk Ihrer Anlage, Umspannwerk oder Leitstelle gehen. Auf diese Weise erhalten Sie ein klares Bild von einem bestimmten Alarm.

Jeder Alarm wird in einen bestimmten Kontext gesetzt, damit Sie die Art des Ereignisses verstehen und den Vorfall eindämmen können.

Das StationGuard IDS hat eine anomale Aktivität erkannt und gemeldet. Die HMI sendete unerwarteten 'Socks'-Netzwerkverkehr über den Router in der Station an einen externen Datenbankserver, der zum Speichern von Ereignislisten verwendet wird. Aus der Perspektive des Umspannwerks sehen wir die Kommunikation zwischen der HMI und dem Router zum WAN. Der Datenbankserver befindet sich hinter dem Router. Von hier betrachtet, ist der Router also der Akteur.

Sie können Sicherheits- und Funktionsprobleme in Echtzeit untersuchen, indem Sie das IDS-Sensor-Dashboard auf Netzwerkebene und unsere einzigartige Netzwerkvisualisierung betrachten, die sowohl für IT- als auch für OT-Expert:innen nützlich ist. Die Details im Ereignisprotokoll liefern weitere Informationen, z. B. über das/die betroffene(n) Gerät(e), MAC/IP-Adressen, verwendete Anwendungen, Protokolle usw.

Hinweis: Es ist durchaus üblich, dass eine Verbindung zwischen der HMI und einer externen Datenbank besteht. In diesem System basiert diese Verbindung auf MySQL und daher wurde eine MySQL-Verbindung für die HMI zugelassen. Nun wurde diese Erlaubnis verletzt, da die Kommunikation in eine Socks-Verbindung mit denselben Portnummern umgewandelt wurde. Die Ursache hierfür könnte eine bösartige Anwendung auf der HMI und/oder der externen Datenbank sein. Jedes Mal, wenn StationGuard Informationen über einen Akteur (Router) oder ein Ziel (HMI) in einer Warnmeldung anzeigt, wird der aktuelle Name des Geräts und die oberste identifizierte OSI-Schicht in der Warnmeldung angezeigt. Hier wurde die Anwendung "Socks" identifiziert. "Socks" ist eine Proxy-Anwendung, die dazu dient, die Kommunikation über ein Gerät eines Drittanbieters umzuleiten, um die Kommunikation durch eine Firewall zu erleichtern. Dies kann in der IT-Umgebung nützlich sein, wird aber auch von Angreifer:innen verwendet, um einen Tunnel zu erstellen, um Daten zu exfiltrieren oder eine Verbindung zu einem Command-and-Control-Server herzustellen. Es ist wahrscheinlich, dass diese Technik auch bei dem "Industroyer"-Cyberangriff 2016 in der Ukraine verwendet wurde. 

Jede Alarmmeldung enthält den ungefähren Zeitpunkt des Ereignisses und den Zeitpunkt der letzten Aktualisierung mit zusätzlichen Informationen über die Aktivität. Der letztgenannte Zeitstempel spiegelt also in der Regel die Dauer der Aktivität wider. Diese kann von Mikrosekunden für die Kommunikation zwischen Geräten bis zu Dutzenden von Sekunden für z. B. Schaltbefehle reichen.

Die Alarmmeldung in unserem System erfolgte am 2022-05-10 um 19:43.   

Häufig werden Alarme ausgelöst, wenn Techniker:innen vor Ort sind und Wartungsarbeiten oder Routineprüfungen durchführen. Die Details geben auch an, ob ein Alarm während des normalen Betriebs oder während der Wartung entdeckt wurde.
  
Die hier beschriebene Aktivität fand während des normalen Betriebs statt. Es war kein Technikteam vor Ort, als dies geschah. Daher ist "Occurred during maintenance" auf "No" gesetzt.  

GridOps bietet uns vor allem ein Dashboard für das Betriebsmittel-Inventar, das die Transparenz im gesamten Netz maximiert. Das Netzwerkdiagramm zeigt uns, dass sowohl der Akteur als auch das Opfer auf der Stationsleittechnik-Ebene („Station control level“) zu finden sind, was der Purdue-Ebene 2 entspricht. 

Jeder Alarm, der auf dem Dashboard von GridOps Alerts angezeigt wird, enthält Informationen über die Quelle des Ereignisses und den Standort, an dem das Ereignis aufgetreten ist, und stützt sich auf die Echtzeit-Betriebsmittelinventarisierung und die Topologiezuweisung.

Da StationGuard einen "Allowlist"-Ansatz verwendet, um verdächtigen oder verbotenen Datenverkehr zu erkennen, haben wir im Vorfeld jede Kommunikation von allen Geräten im Umspannwerk definiert und genehmigt.
  
Diese Informationen können in StationGuard importiert werden. Entweder …
...aus der IEC 61850 SCD (Substation Configuration Description), die Sie aus Engineering-Tools exportieren können, oder
...aus Tabellenkalkulationen, die das Anlagennetzwerk dokumentieren.

Der Alarm zeigt uns, dass der Verkehr nicht genehmigt ist. Wir finden einen internen Akteur, der mit dem Vorfall in Verbindung steht. Die IP-Adresse des Akteurs ist 192.168.1.123 und die IP-Adresse des Ziels ist 192.168.1.200. 

Um eine effiziente Kommunikation zwischen den IT-Sicherheitsbeauftragten und den Schutz- und Leitstellen-Techniker:innen zu ermöglichen, zeigt GridOps die echten Gerätenamen gemäß der Schutz- und Leittechnik anstelle bloßer IP-Adressen an. Diese Namen können z.B. aus den Datenpunktlisten oder SCL-Dateien importiert werden.
 
Jeder Alarm, der von StationGuard ausgelöst wird, hebt die Instanzen hervor, die das Ereignis verursachen oder zu ihm beitragen, welche Art von Betriebsmitteln beteiligt sind, wer der Akteur ist und wer als Ziel identifiziert wurde.
  
Wir können jetzt ganz einfach die Spannungsebene, den Abzweig und die Gerätenamen auslesen, die an dem Ereignis beteiligt waren. 

Wir stellen fest, dass die angreifende Partei versucht hat, eine Socks-Proxy-Verbindung über denselben Port herzustellen, der für die MySQL-Verbindung verwendet wird (TCP-Port 3306).

Jeder Alarm, der von StationGuard ausgelöst wird, gibt Aufschluss über die Art der Aktion, die Art und Weise, wie die Aktivität durchgeführt wurde und was der Akteur getan hat, um sie zu verursachen. Ein Vorfall wird durch mindestens eine Aktion verursacht, aber die meisten umfassen mehrere Aktivitäten.

Es bleiben einige Fragen offen:  

• Warum hat das IDS hier einen Alarm ausgelöst?
• Welche Kommunikationsberechtigungen oder Richtlinien wurden verletzt? Warum wurden die Kommunikationsberechtigungen auf diese Weise festgelegt?
• Warum handelte es sich nicht um eine rechtmäßige Kommunikation des Quellgeräts?

 

StationGuard zeigt an, welche Kommunikation erlaubt ist; alles andere ist standardmäßig verboten. Wir sehen, dass eine Verbindung zwischen dem HMI und dem Datenbankserver über den Router erlaubt ist. Außerdem war die Anwendung "MySQL" für diese Verbindung zugelassen; der Alarm wurde ausgelöst, weil es sich nicht mehr um MySQL handelt.
 
Die StationGuard-Hilfe gibt uns schließlich Hinweise auf mögliche Probleme, die den Vorfall verursacht haben. Sie bietet uns eine Schritt-für-Schritt-Anleitung, um alle oben genannten Fragen nach dem Warum zu beantworten. Der Alarm ist unser Ausgangspunkt für die Untersuchung. Was uns an dieser Stelle am meisten interessiert, sind die folgenden Fragen:
F: Handelt es sich um eine andere Verbindung zu einem Dienst mit einer neuen (serverseitigen) Portnummer oder hat sich die Anwendung derselben Verbindung geändert? 
A: Wir stellen fest, dass Letzteres der Fall ist. Die Zielportnummer war die gleiche, aber die Anwendungsschicht wechselte von MySQL zu Socks. Dieser Vorgang erscheint verdächtig.
F: Haben alle entsprechenden Geräte die richtigen Rollen zugewiesen bekommen? Gibt es eine Funktion dieses Geräts, die bisher noch nicht verwendet wurde? 
A: Diese Frage erfordert OT-Wissen über das Gerät und seinen Zweck. Die beteiligten Leittechniker bestätigten, dass von der HMI keine ausgehende Verbindung erwartet wird, außer einer Datenbankverbindung.

Es bleibt nun der Verdacht, dass das Verhalten durch Malware auf der HMI verursacht werden könnte. StationGuard zeichnet eine Netzwerkaufzeichnung von jedem Ereignis auf. Wir erfassen diese Beweise und wenden uns an den HMI-Hersteller. 

Der Kontext des Alarms hilft Ihnen, herauszufinden, warum der Vorfall überhaupt möglich war. Solche Informationen sind auf vielen Ebenen hilfreich - zum Beispiel bei der Bewertung von Schwachstellen in der Sicherheitskontrolle und bei der Ermittlung von Vermeidungsstrategien.