Gastbeitrag von LC Systems
Data Gateways: Dolmetscher für Logs und Analysen
Fortsetzung des Artikels von Teil 1
Hochregal spricht Klartext
Ein Fallbeispiel mag die Situation verdeutlichen: Ein Hersteller für landwirtschaftliche Maschinen betreibt in jedem seiner international verteilten Werke ein automatisiertes Lagersystem, das Komponenten aus verschiedenen Produktionsstraßen temporär aufnimmt und dann – auf Abruf – der Endfertigung zur Verfügung stellt. Für das Unternehmen sind diese Lager hochkritische Anlagen. Funktionieren sie nicht, muss auf der einen Seite die Komponentenherstellung rechtzeitig stoppen, um Staus zu vermeiden, und auf der anderen Seite kommt binnen kürzester Zeit die Just-in-Time-Fertigstellung der Endprodukte zum Stehen. Aus diesem Grund überwachen die OT- und IT-Security, die lokalen Leitstände sowie die Werksleitung ihr jeweiliges Lager mit hoher Priorität, um Störungen schnell erkennen, untersuchen und abfedern zu können.
Gleichzeitig stellt das Lager eine wichtige Quelle für geschäftliche Informationen dar: Seine Prozesse geben beispielsweise Auskunft darüber, welche Endprodukte in welchem Land im Trend liegen und welche nicht mehr, welche Lagerbereiche und Produktionsstraßen wie stark ausgelastet sind, was all dies für die Zuliefersituation bedeutet, welche Anlagen zuverlässig funktionieren und welche nicht etc.
Mageren Informationsgehalt anreichern
Das Steuerungssystem des Lagers speichert anhand von Artikel- und Seriennummern, welche Komponenten es wann erfasst, an welcher Lagerposition es sie nach welcher Regel wie lange einlagert und an welchen internen Empfänger es sie dann schließlich weitergibt. Diese Informationen kann es auch in Dateiform extern weitergeben. Darüber hinaus hält es in Log-Dateien Störungen fest, und zwar in Form von Störungsnummern mit Zeitstempeln. Änderungen an einem Programm seiner Fördergeräte dokumentiert es selbst nicht im Detail – diese Informationen finden sich in einem extern zugeschalteten Verwaltungswerkzeug für SPS-Programme und Konfigurationsdateien.
Für Business-Zwecke wäre es – neben eventuellen Format-Anpassungen – zum Beispiel sinnvoll, die Aktionsdaten vor der Weitergabe mit Informationen darüber anzureichern, welche Gegenstände sich hinter den Produktnummern verbergen und aus welchem Produktionsprozess sie kommen. Je nach Auswertungsziel könnten aber auch ganz andere Kontextinformationen von Interesse sein.
Das gleiche gilt für die Security-Logs: Verfügt das Unternehmen über ein Security-Operations-Center, das die Vorgänge im Produktions- und Büronetz auf Anzeichen von Angriffen hin überwacht, dürfte man sich dort dafür interessieren, ob Störungsmeldungen der Lagersteuerung möglicherweise mit anderen Anomalien in der IT-Umgebung zusammenhängen. Dazu wäre es allerdings sinnvoll, dem Fehler-Code eine Beschreibung des Störungsfalls hinzuzufügen, die den SOC-Analysten und ihren Werkzeugen den Vorfall verständlich macht. Die Ergänzung erleichtert es außerdem, die Störung beispielsweise mit Änderungen an der Lagersystemsoftware abzugleichen, über die das Softwareverwaltungssystem Auskunft gibt. Wieder ist somit nicht nur eine Normalisierung notwendig, sondern auch eine Anreicherung.
Lässt man diese von den SOC-Werkzeugen selbst ausführen – etwa, indem man eine SIEM-Regeln schreibt, die die Fehler-Codes der Anlage um Klartext ergänzen - hat dies gleich zwei unangenehme Folgen: Die mühevolle Anpassung geht immer dann verloren, wenn das Security-Team ein neues Korrelationswerkzeug anschafft oder die SOC-Tätigkeit an einen Dienstleister mit anderen Tools übergibt, und das Monitoring-Tool selbst ist mit Tätigkeiten und Code belastet, die nicht zu seinen Hauptaufgaben gehören. Abgesehen davon haben Störungsmeldungen, die auf purem Hardwareversagen beruhen, nichts im SOC zu suchen – sie müssen stattdessen dem Werksleitstand oder das Wartungsteam gemeldet sein.
- Data Gateways: Dolmetscher für Logs und Analysen
- Hochregal spricht Klartext
- Übersetzungs- und Transferaufgaben erledigen
Lesen Sie mehr zum Thema
