Bei den meisten modernen Sicherheitsprogrammen stellt sich die Frage nach den Logs bereits in einem frühen Stadium. Bei der Einrichtung eines SIEM ist es von entscheidender Bedeutung, wie die operative Technologie (OT) in die vorherrschende IT-Infrastruktur integriert werden kann.
In den meisten Fällen ist es ratsam, alle Log-Einträge zu sammeln und zu versuchen, eine Art von Bedeutung aus ihnen abzuleiten, sofern dies möglich ist. Für viele Unternehmen stellt die Integration von OT-Logs in ihr SIEM lediglich eine zusätzliche Checkbox dar, die bei den Anforderungen für NIST oder andere Rahmenwerke angekreuzt werden muss. Dieser Ansatz ist jedoch nicht gut skalierbar, da eine falsche Konfiguration zu Tausenden von Ereignissen pro Unterstation und Woche führen kann.
OT-Logs können bei korrekter Handhabung einen unschätzbaren Mehrwert bieten. Wie bei der IT ist es nicht erforderlich, sich auf die Sammlung und Speicherdauer der Logs zu fokussieren. Stattdessen sollten Logs als hilfreiches Instrument betrachtet werden. Sie ermöglichen das Verständnis von Zusammenhängen und die automatische Markierung von Änderungen.
Visualisierung der Netzwerkverbindung von der Station zu SOC und SCADA
Gezielte Sammlung von Protokollen in einer zentralisierten Datenbank pro Standort
Wie entscheidet man, was man loggt?
Nachdem die Grundlagen geklärt sind, lassen sich die relevanten Fragen wie folgt definieren:
- Welche Informationen werden benötigt und sollen mitgeteilt werden?
- Welcher Dringlichkeitsgrad ist für die Benachrichtigung erforderlich?
- Wie lange nach dem Ereignis sind die Informationen nützlich und wie lange muss die Historie zurückreichen, um Probleme zu beheben oder zu lösen?
Es ist es von entscheidender Bedeutung, strukturierte Bedingung zu erstellen, beispielsweise in Bezug auf „Anwendungsfälle“ oder, allgemeiner, „Alarme“. Diese sollten von SIEM oder anderen Arten von Logverwaltungssoftware/-geräten verwendet werden können.
Bei der Identifizierung wertvoller Warnmeldungen können grundsätzlich zwei gängige Ansätze unterschieden werden:
- Bottom-Up: Durchsicht der verfügbaren Logs, um wertvolle Warnmeldungen zu identifizieren.
- Top-Down: Definition einer Reihe von Anwendungsfällen und Versuch, die relevanten Umstände in einem maschinenverständlichen Format zu beschreiben.
Ein weiterer wesentlicher Unterschied zwischen der IT- und der OT-Sicherheit besteht darin, dass das primäre Ziel der IT-Sicherheit die Sicherheit von Daten und Systemen (=security) ist, während das übergeordnete Ziel der OT-Sicherheit die Gewährleistung der Sicherheit von Personen (=safety) und Anlagen ist. Die Datensicherheit steht bei der OT also nicht im Vordergrund, sondern ist vielmehr ein Mittel, um eine mögliche physische Gefährdung zu vermeiden.
Es wird daher empfohlen, die Mehrzahl der Sicherheitslogs für die Überwachung von Prozessen in der OT zu verwenden, da dies ein notwendiger und wirksamer Ansatz ist. Einige spezialisiertere Security Operation Center (SOC) schlagen auch bei Prozessverletzungen Alarm, da eine Abweichung vom Standardprozess auch ein Hinweis auf einen Angriff aus internen oder externen Quellen sein kann. Letztendlich liegt diese Entscheidung bei der Organisation und hängt davon ab, ob sie über die erforderlichen Fähigkeiten verfügt, um die Kritikalität der Umstände zu bestimmen. Als erster Schritt kann die MITRE ATT&CK ICS-Matrix als Bezugspunkt für die Identifizierung potenzieller Angriffe und Prozessverletzungen dienen, die überwacht und gemeldet werden müssen. Diese Matrix bietet eine Zusammenfassung von Methoden, die in der Vergangenheit verwendet wurden, und bietet Einblicke in potenzielle Schwachstellen.
Alle OT-spezifischen Intrusion Detection Systeme (IDS) bieten gemeinsame Warnstrukturen, einschließlich neuer Verbindungen über gängige IT-Protokolle wie IP, TCP, UDP, SNMP und DHCP. Des Weiteren generieren sie Alarme, die auf Abweichungen oder ungewöhnliches Verhalten von Prozessautomatisierungsgeräten wie RTUs hinweisen. Dazu zählt beispielsweise das Hochladen eines neuen Befehlssatzes auf die Steuergeräte. In bestimmten Fällen kann dies so weit gehen, dass eine genaue Beschreibung der Umgebung vorliegt, wobei Abweichungen von dieser Beschreibung gekennzeichnet werden. Dies ist ein wesentlicher Vorteil von IEC-61850-Umgebungen.
Um auf die ursprüngliche Frage zurückzukommen: „Was sollte dokumentiert werden und wie lange sollte es aufbewahrt werden?“
Die Antwort ist sowohl einfach als auch, wie so oft, vielschichtig. Sie lässt sich wie folgt zusammenfassen: „Es kommt darauf an.“
Wie bedeutet dies für Ihre OT Logs?
Um eine optimale Ressourcennutzung zu erreichen, ist eine Zusammenarbeit der IT- und der OT-Abteilung erforderlich, um festzulegen, welche Alarmierungsfunktionen vom SOC und welche von den OT-Ingenieur:innen verwaltet werden sollen. Sobald diese Entscheidung getroffen ist, können die relevanten Logs für die Sammlung identifiziert werden.
Im Allgemeinen sind die folgenden Arten von Logs für die OT von Bedeutung [1]:
- Lokale Ereignisse, z. B. von den Betriebssystemen
- Ereignisse von Domain Controller
- Firewall-/Router-/Switch-/Server-Ereignisse
- Ereignisse von Malware-Schutzsoftware
- Ereignisse von Intrusion Detection Systemen (IDS) oder Intrusion Prevention Systemen (IPS)
Zusätzlich zu den oben genannten Ereignissen sind folgende Daten zu dokumentieren:
- Datum und Uhrzeit
- Beschreibung des Ereignisses
- Kritikalität
- Quelle des Ereignisses (z. B. Anwendung, Betriebssystem)
- Betroffenes OT-System/Prozess
Zur Bewältigung dieser Herausforderung empfehlen wir den Einsatz hochspezialisierter Überwachungstools, die den Filterungsprozess automatisch durchführen. Ein solches Tool ist unsere auf den Energiesektor zugeschnittene StationGuard-Lösung. Sie leitet den gesamten Netzwerkverkehr weiter, analysiert ihn und generiert automatisch Warnmeldungen. Dies hilft bei der Überwachung von Geräten und Prozessen, ohne dass eine umfangreiche Logerfassung erforderlich ist.
News und Aktuelles
