Behavior Analytics zur Erkennung von Veränderungen in der OT-Umgebung

Im Anknüpfend an meinen letzten Blogbeitrag will ich nun einen genaueren Blick darauf werfen, wie Veränderungen in der OT-Umgebung eines Unternehmens erkannt werden können.

Zunächst einmal möchte ich das Purdue-Modell, auf das ich mich in diesem Artikel beziehe, näher erläutern:

Was beinhaltet das Purdue-Modell?

Das Purdue-Modell wurde ursprünglich als Grundlage für die Verwaltung von Datenströmen in der computergestützten Fertigung (CIM) konzipiert. Bei CIM spielen Computer eine zentrale Rolle für die Überwachung und Koordinierung der gesamten Fertigungsprozesse, was zu einer höheren Geschwindigkeit und geringeren Fehlerquoten führen soll. In der Folge entwickelte sich dieses Modell zum Maßstab für den Aufbau einer Netzwerkarchitektur für industrielle Kontrollsysteme (ICS) mit Schwerpunkt auf der OT-Sicherheit (Operational Technology). Das primäre Konzept dreht sich um die Aufteilung von Netzwerk-Layern, die einen strukturierten Datenfluss zwischen diesen Ebenen mit entsprechenden Zonen und Conduits ermöglichen.

Einführung in die Zoneneinteilung von OT-Netzen und das Purdue-Modell

Bei einem Standard-OT-Netz nach dem Purdue-Modell sind verschiedene Zonengrenzen Gegenstand der Datenverkehrsanalyse. Für einen typischen Energieversorger könnte dies das Kontrollzentrum sein, das z. B. von regulärem IT-Verkehr (Dateitransfers, Backups, Unternehmens- und Abrechnungsschnittstellen) bis hin zur IEC-104-Kommunikation über TCP/IP reicht.

Das Purdue-Modell selbst definiert 6 Netzwerkzonen (und zum Teil weitere Unterebenen) zur Differenzierung der verschiedenen Kontrollstufen. Basierend auf diesen Kontrollebenen können Vertrauensgrenzen mit Zonen und Conduits auf der Grundlage von Zugangskontrollmaßnahmen und/oder Firewalling zwischen den verschiedenen Zonen eingerichtet werden.

Die Zonen selbst sind in der nachstehenden Abbildung dargestellt, wobei zu beachten ist, dass die Ebene 3.5 in den meisten Fällen die DMZ (Demilitarisierte Zone) zwischen der IT- und der OT-Abteilung des Unternehmens definiert.

Überträgt man dieses Wissen über die Zonierung auf eine tatsächliche, auf OT ausgerichtete Ebene der Energiesteuerung, könnte eine schöne und saubere Zonierung etwa so aussehen wie in der folgenden Abbildung. In diesem Fall können Sie sehen, dass DMZ und Betrieb in einer separaten Firewall-Zone liegen, die sich von der Netzleitebene unterscheidet.

Je nach der Komplexität Ihrer Gesamtlösung kann dies der Fall sein oder auch nicht. Wichtig ist, dass der Bereich für den Umspannwerkbetrieb zwar getrennt ist, sich aber in derselben Firewall befindet wie die Netzleitebene und wiederum von der Feldebene getrennt ist.

Weiter unten auf den Purdue-Ebenen 0 und 1 sind die Netze der Feldebene in ein sicherheitskritisches und ein nicht sicherheitskritisches Netz getrennt.

Verhaltensanalytik für OT-Umgebungen und Unterschiede zur IT

In Bezug auf das allgemeine Verhalten unterscheidet sich die OT-Kommunikation von den klassischen IT-Kommunikationsmustern in dem Sinne, dass kontinuierlicher Datenverkehr für die Statusdaten der Betriebsgeräte (z. B. Schalter, Ventile, Motoren) übertragen wird und sich der Umfang des gesendeten und empfangenen Datenverkehrs nur dann signifikant ändert, wenn der Operator ein vollständiges Protokoll oder ein Status-Update anfordert.

Diese Änderungen können von einer Network Detection & Response (NDR)-Lösung, die mit maschinellem Lernen (ML) und Kommunikationsprofilen arbeitet, leicht entdeckt werden. Gleichzeitig wird durch das Erkennen, ob sich Ihr administratives Verhalten geändert hat (Logins von verschiedenen Standorten aus, neue administrative Clients für Ihren ModbusTCP-Verkehr), ein vollständiges Bild der Anomalieerkennung auf Netzwerkebene erstellt.

Zusätzlich zu den Verhaltensänderungen kann die NDR-Lösung ExeonTrace auch Logdateien von Ihrem Kontrollzentrum und sogar Ihren PLCs auswerten, wenn diese an unsere NDR-Lösung übermittelt werden. Durch das Parsen der Logs können zusätzliche Abweichungen vom Standardverhalten entdeckt werden. Dies kann von der Identifizierung und Alarmierung von widersprüchlichen Befehlen, die von bisher vertrauenswürdigen Clients in kurzen Abständen gesendet werden, bis hin zu kritischen Energieschaltprotokollen reichen, wie z. B. ein Leitungsschutzschalter, der nach der Verwendung seine interne Temperatur ändert.

Es sollte allerdings erwähnt werden, dass dies einen Entwicklungsaufwand darstellt, der in der Regel gut funktioniert, wenn verschiedene Protokolleinträge vorhanden sind und das Protokoll gut strukturiert ist. Sogenannte Brownfield-Installationen, bei denen neue Technologien oder Systeme in eine bestehende Infrastruktur integriert werden, haben manchmal eine gewisse Komplexität, da verschiedene Hersteller unterschiedliche Protokolle für ihre PLCs und ihre SCADA-Systeme verwenden. Wenn man über Subsystem- oder partielle Upgrades nachdenkt, z. B. von Profibus zu Profinet oder von Modbus RTU zu Modbus TCP, werden unterschiedliche Bedrohungsvektoren für die verschiedenen Protokolle sowie unterschiedliche Verhaltensweisen deutlich.

Aufgrund der Lebenszyklen von OT-Produkten, die manchmal mehr als 20 Jahre andauern, sind solche Parallelinstallationen viel häufiger als in normalen IT-Landschaften. Daher werden verhaltensbasierte Analysen und die Herausforderungen im Zusammenhang mit Legacy-Installationen weiterhin häufig vorkommen, während reine Greenfield-Installationen, bei denen mit einer völlig neuen und unberührten Infrastruktur begonnen werden kann, sehr viel seltener zu beobachten sind.

Integration bestehender Sicherheitsfunktionen aus Ihrem OT-Netzwerk

Wenn Sie in Ihrer OT-Umgebung bereits eine entsprechende Reihe von Sicherheitsmerkmalen einsetzen, lassen sich deren Kommunikationsmuster problemlos in Ihre NDR-Lösung aufnehmen. Ein Beispiel hierfür könnte die kontinuierliche Kommunikation Ihrer EDR-Lösung mit einem zentralen Konfigurations- und Orchestrierungsserver sein. Die Erkennung der fehlenden Kommunikation zu diesem Server von einem zuvor noch kommunizierenden Client könnte darauf hindeuten, dass entweder die EDR-Lösung abgestürzt ist oder von einem böswilligen Eindringling deaktiviert wurde.

Ein zweites Beispiel wäre die Verwendung eines zentralen PKI-Dienstes, der kontinuierlich Anfragen von Clients entweder über OCSP oder Zertifikatsregistrierungen etwa über PKCS#10 erhält. Wenn diese Anfragen protokolliert werden, können Abweichungen von Clients, die mit der CA kommunizieren, ebenso erkannt werden wie mögliche Angriffe von Eindringlingen. Auch dies ist durch die Verwendung des XLog-Moduls und mit geringem technischem Aufwand möglich, sobald die Logfiles zum Parsen verfügbar sind. Ein möglicher Ablauf zur Erkennung dieser Art von Angriffen ist in der folgenden Abbildung zu sehen.

Die Erkennung dieser Arten von Angriffen ist daran gebunden, dass die Zertifizierungsstelle aktiv Anfragen von Clients für unterschiedliches Verhalten protokolliert und diese Protokollmeldungen für ExeonTrace bekannt und verständlich macht.

DPI-Sensoren fügen eine zusätzliche Sichtbarkeitsebene hinzu, welche sich von den Netzwerk-Metadaten und der Protokollanalyse unterscheidet, und bei Protokolländerungen ausgelöst wird. Je nach Größe des Netzwerks kann es jedoch sein, dass ihnen der vollständige Überblick über das Netzwerk auf allen Ebenen fehlt, wie im Purdue-Modell dargestellt.

Schlussfolgerungen

Ich habe gezeigt, dass sowohl das Kommunikationsverhalten als auch die Protokollanalyse wichtige Bausteine sind, um ein vollständiges Bild Ihrer OT-Umgebung zu erstellen, selbst wenn kein DPI-Sensor vorhanden ist. Darüber hinaus sollten Sie sich bewusst sein, dass typische Brownfield-Installationen ein anderes Verhalten aufweisen als modernere Anlagen. Insgesamt schlägt der Beitrag vor, Ihre Detektionsmöglichkeiten durch den Einsatz von ML zu verbessern, um damit Verhaltens- und zeitbasierte Änderungen in Ihrem OT-Netzwerk zu erhalten.

Was denken Sie darüber? Ich würde gerne mehr über Ihre Herausforderungen und potenziellen Fragen erfahren.