SSV Software Systems
Transparente und sichere Verbindungspunkte
Verbindungen zwischen OT- und IT-Netzwerken erfordern geeignete Methoden und Prozesse, um die notwendige Nutzungstransparenz zu schaffen. Des Weiteren sollten mögliche Angriffsversuche frühzeitig erkannt, umgehend unterbunden und der Wiederholungsfall ausgeschlossen werden.
Die Anzahl möglicher OT/IT-Verbindungen ist in den meisten Anwendungen relativ statisch. Neue Verbindungen entstehen durch Konfigurationsveränderungen innerhalb der OT-Umgebung, etwa durch die Neuinstallation einer OT-Baugruppe beziehungsweise eines ICS (Industrial Control Systems). Insofern lässt sich mit den folgenden beiden Maßnahmen der cybersichere Betrieb der Verbindungspunkte optimieren.
1. Initiale Datenverkehrsanalyse
In die physikalische Verbindung zwischen OT- und IT-Netzwerk wird ein zusätzlicher Ethernet-Switch mit einem SPAN- beziehungsweise Mirror-Port geschaltet (SPAN = Switch Port Analyzer). Ein solcher Spezialport dient dazu, den Netzwerkverkehr zwischen anderen LAN-Switch-Ports für Überwachungsaufgaben zu spiegeln, also nach entsprechender Vorkonfiguration beispielsweise jeweils einen Port in Richtung OT- und IT-Netzwerk (siehe Bild). Die Ausgangsdaten dieses Mirror-Ports werden an einen geeigneten Datenlogger weitergeleitet, zum Beispiel an einen Netzwerksensor für Intrusion-Detection-Systeme (IDS). Solche Netzsensoren bieten vielfältige Konfigurationsmöglichkeiten und lassen sich daher an die individuelle Aufgabenstellung anpassen.
| Feldname | Beschreibung | Beispiel |
|---|---|---|
| cid | Connection identifier. Eindeutige ID der jeweiligen Sitzungsdaten. | 1 |
| cstime | Connection start time. Zeitpunkt des Verbindungsaufbaus bzw. des ersten Datenpakets einer Sitzung (z. B. Unix Time Stamp-Format). | 1699529071 |
| cetime | Connection end time. Zeitpunkt des Verbindungsabbaus bzw. des letzten Datenpakets der Sitzung. | 1699529123 |
| proto | IP payload identifier. Protokollkennzeichen, z. B. TCP = 6. Siehe die „Assigned Internet Protocol Numbers“ der IANA. | 6 |
| saddr | Source IP address. IPv4-Adresse des Systems, das die Sitzung durch den Versand des ersten Datenpakets startet (Quellsystem bzgl. eines Verbindungsaufbaus). | 192.168.0.1 |
| sport | Source port number. TCP- oder UDP-Portnummer des Quellsystems | 55202 |
| spkts | Source-to-destination packet count. Anzahl der IP-Pakete, die innerhalb der gesamten Sitzung vom Quellsystem an das Zielsystem übertragen wurden. | 1 |
| sbytes | Source-to-destination byte count. Anzahl der Bytes, die innerhalb der gesamten Sitzung vom Quellsystem an das Zielsystem übertragen wurden. | 44 |
| daddr | Destination IP address. IPv4-Adresse des Systems, mit dem Sitzung gewünscht wird (also das Zielsystem bzgl. eines Verbindungsaufbau durch das erste Datenpaket des Quellsystems). | 192.168.0.126 |
| dport | Destination port number. TCP- bzw. UDP-Portnummer des Dienstes auf dem Zielsystems, zu dem eine Verbindung aufgebaut werden soll bzw. dessen Dienste in Anspruch genommen werden sollen. | 7777 |
| dpkts | Destination-to-source packet count. Anzahl der IP-Pakete, die innerhalb der gesamten Sitzung vom Zielsystem an das Quellsystem übertragen wurden. | 6 |
| dbytes | Destination-to-source byte count. Anzahl der Bytes, die innerhalb der gesamten Sitzung vom Zielsystem an das Quellsystem übertragen wurden. | 264 |
Für die initiale Datenverkehrsanalyse werden Log-Daten mit den jeweiligen Verbindungsdaten der typischen Dialoge zwischen möglichst allen OT- und IT-Anwendungen benötigt. Solche Connection Logs oder auch Transaction Logs enthalten allerdings nicht jedes einzelne Ethernet-LAN- beziehungsweise IP-Datenpaket einer Verbindung, sondern lediglich repräsentative Kennzahlen der einzelnen TCP- oder UDP-Sitzungen – jede Sitzung erzeugt praktisch ein einziges Datenelement. Mit anderen Worten: Für die TCP-Sitzung zwischen einem Webbrowser und einem Webserver, bei der auf Grund von Multimedia-Inhalten etliche zig Megabyte an Daten in beide Richtungen übertragen wurden, fallen in Abhängigkeit vom jeweils gewählten Log-Datenformat zwischen 50 und 250 Bytes an (siehe Beispiel in der Tabelle). Um solche kompakten Sitzungs-Logs erzeugen zu können, benötigt der Netzsensor allerdings spezielle Fähigkeiten, wie sie beispielsweise in der Open-Source-Software Netfilter (Conntrack) oder auch im Zeek Network Security Monitor zu finden sind. Als Datenformat für die Log-Datenspeicherung eignen sich CSV-Datenstrukturen (Comma-Separated Values) oder auch JSON-Objekte, die sich direkt in einer NoSQL-Datenbank speichern lassen. Das weit verbreitete PCAP-Format (Packet Capture) ist mit Blick auf die folgende Datenanalyse und die effiziente Nutzung der Daten für eine spätere Angriffserkennung weniger geeignet.
In der dann folgenden Datenanalyse durch einen IT-Experten mit zusätzlichem Fachwissen zu den gängigen Automatisierungsprotokollen – Modbus, Profinet, OPC UA – müssen sich auf jeden Fall die Datenmuster der typischen Dialoge zwischen allen OT- und IT-Anwendungen eindeutig bestimmen lassen. Wird bei der Datenanalyse deutlich, dass auch noch spezielle UDP-basierte Serviceprotokolle wie Apple, Bonjour oder UPnP über den OT/IT-Verbindungspunkt im OT-Netzwerk nach entsprechenden Geräten suchen, so sollte zunächst die Firewall des betreffenden Verbindungsprozesses entsprechend konfiguriert werden. Insgesamt sind in der Praxis mehrere Iterationsschleifen aus Datenerfassung und Datenanalyse erforderlich, bevor zu jedem OT/IT-Anwendungsdialog ausreichend Beispieldaten und Datenanalyse-Ergebnisse vorliegen.
Die Angriffserkennung
Für den cybersicheren Betrieb sollten alle OT/IT-Verbindungen über definierte und dokumentierte Prozesse erfolgen (oben). Zu jedem Verbindungsprozess gehört auch eine initiale Datenverkehrsanalyse, um die typischen Datenmuster der Kommunikationsdialoge zu bestimmen und bei Bedarf die Firewall-Regeln zu optimieren (unten). Die dabei anfallenden Daten eignen sich auch zur Angriffserkennung.
© SSVEine solide und umfassende Wissensbasis über die Details möglicher Angriffe, die sich in der Praxis effektiv zur Verhinderung erfolgreicher Attacken einsetzen lässt, ist auf Grund der Komplexität nach wie vor eine sehr große Herausforderung. Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt daher in dem Dokument Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (BSI-OZA) allen Organisationen, die sich der kritischen Infrastruktur zuordnen lassen, die Orientierung an der MITRE ATT&CK-ICS-Matrix. Das „ATT&CK“ steht in diesem Fall für „Adversarial Tactics, Techniques and Common Knowledge” (siehe Web-Tipp). Es findet sich dort eine verlinkte matrixförmige Übersicht zu TTPs – Technik, Taktik und Prozeduren – mit zwölf Spalten, von denen jede eine bestimmte Taktik repräsentiert. Diesem Teilziel des Angreifers sind dann jeweils bestimmte Subtechniken mit einzelnen alphanumerischen Identifikatoren zugeordnet. Klickt man beispielsweise in der Spalte „Persistence“ auf „Module Firmware“ (ID = T0839), erscheint eine umfangreiche Erklärung, wie ein Angreifer eine schadhafte Firmware dauerhaft im ICS-Angriffsziel verankern könnte. Will oder muss man sich intensiver mit der Angriffserkennung in der eigenen OT auseinandersetzen, ist es schon hilfreich, sich einmal intensiver mit der MITRE ATT&CK-ICS-Matrix zu befassen. Organisationen, die unter die Neufassung des IT-Sicherheitsgesetzes „IT-SiG 2.0“ fallen, sind seit dem 1. Mai dieses Jahres praktisch gesetzlich dazu verpflichtet.
Relativ unabhängig von möglichen Angriffsdetails bietet eine saubere OT/IT-Netzwerktrennung (siehe den Verbindungsprozess im Bild) innerhalb der organisationsweiten Netzwerkinfrastruktur einen effektiven Kontrollpunkt für eine kommunikationsdatenbasierte OT-Cyberangriffserkennung. Als Ergebnis der initialen Datenverkehrsanalyse existiert darüber hinaus ein transparenzschaffendes (Log-) Datenmodell mit Beispieldaten zur normalen OT/IT-Kommunikation. Desweiteren ist von der Annahme auszugehen, dass durch die Konfiguration der Verbindungsprozess-Firewall jeglicher überflüssiger Netzwerkverkehr unterbunden wird. Also praktisch alles, was für die Dialoge zwischen OT- und IT-Anwendungen nicht nötig ist. Insofern wäre der nächste Schritt eine Auswahl der technischen Möglichkeiten zur Angriffserkennung und deren Integration in den eigenen Verbindungsprozess. Die wichtigsten zur Auswahl stehenden Bausteine wären:
Die Anomalie-Erkennung: Dafür wird der gesamte Datenverkehr am OT/IT-Verbindungspunkt – möglichst in Echtzeit – mit einem geeigneten Machine-Learning-Algorithmus überwacht, um an Hand der Kommunikationsdaten von der normalen OT/IT-Kommunikation abweichende Muster zu identifizieren und zu melden. Für die erforderliche ML-Konfiguration und Trainingsphase lassen sich die Datenstrukturen und Ergebnisse der Datenverkehrsanalyse nutzen.
IDS beziehungsweise IPS: Bei einem Intrusion Detection System (IDS) handelt es sich um eine Softwarefunktion, die den Datenverkehr einer Kommunikationsverbindung nach bekannten Angriffsmustern durchsucht, um verdächtige Aktivitäten zu melden. Der Abgleich der Verkehrsdaten mit den Fingerprints bekannter Angriffe kann in Echtzeit oder zeitversetzt über die Auswertung von Logdateien erfolgen. Wird bei der Angriffserkennung automatisch eine Abwehrmaßnahme in die Wege geleitet – zum Beispiel das Sperren eines Ports in einer Firewall –, spricht man von einem Intrusion Prevention System (IPS).
SIEM-System: Ein SIEM-System (Security Information and Event Management) ist in der Regel eine zentralisierte, organisationsweite Sicherheitslösung, in der möglichst viele korrelierende Sensordaten aus unterschiedlichen Messpunkten zu einem Gesamtbild beziehungsweise Kontext zusammengefügt und aussagefähige Alarmmeldungen erzeugt werden. Sie signalisieren mögliche Sicherheitsbedrohungen und helfen dabei, Schwachstellen rechtzeitig zu erkennen und zu beheben.
SOC: Die 24/7-Rund-um-die-Uhr-Überwachung an 365 Tagen im Jahr durch ein IT-Expertenteam als zentrale Sicherheitsinstanz wird im Allgemeinen als Security Operation Center (SOC) bezeichnet. Die Aufgabentiefe ist von der jeweiligen Organisation und den individuellen Zielen abhängig. Neben der Überwachung und Abwehr von IT-Sicherheitsvorfällen gehören vielfach auch Vorbeuge- und Compliance-Management-Maßnahmen zu den SOC-Aufgaben.















