Sicherheitstools für OT-Systeme können zwar wichtige Signale erkennen, doch ein Alarm gibt selten Aufschluss über den dahinterstehenden Produktionsprozess. Eine effektive Untersuchung setzt voraus, dass Netzwerkdaten, Anlagenkenntnisse und Sicherheitsfachwissen in einer einheitlichen operativen Übersicht zusammengeführt werden.
OT Sicherheit Sicherheitswarnungen Bedarf operativ Kontext. Erfahren Sie warum OT Teams, SOCs und Sicherheitsteams Tools müssen gemeinsam genutzt werden Informationen um zu untersuchen industrielle Unfälle effektiv.
OT Teams verstehen die Produktion Prozess. SOC Teams verstehen die Bedrohung. Ein wirksame Ermittlung erfordert sowohl Ansichten gleichzeitig benötigt.
Viele Industrieunternehmen haben im Bereich der OT-Sicherheit erhebliche Fortschritte erzielt.
Sie haben die Erfassung von Systemressourcen, die Erkennung industrieller Angriffe, verbesserte Firewalls und einen besser kontrollierten Fernzugriff eingeführt. Sicherheitszentralen erhalten zunehmend Informationen aus Produktionsumgebungen, während spezialisierte OT-Sicherheitsplattformen Einblicke in industrielle Protokolle, anfällige Systemressourcen und ungewöhnliches Netzwerkverhalten bieten.
Das Ergebnis ist, dass heute mehr Informationen vorliegen als noch vor einigen Jahren in den meisten Organisationen.
Wenn jedoch ein Vorfall untersucht werden muss, tauchen immer wieder die gleichen Fragen auf: Ist die Kommunikation vorgesehen? Welcher Produktionsprozess hängt von dem betroffenen System ab? Wurden Wartungsarbeiten durchgeführt? Wem gehört die Anlage? Kann sie sicher isoliert werden?
Das Problem besteht nicht unbedingt darin, dass eine weitere Erkennungsfunktion fehlt. Häufiger ist es so, dass die relevanten Informationen zwar bereits vorliegen, jedoch auf verschiedene Tools und Teams verteilt sind, die jeweils unterschiedliche Aspekte der Situation im Blick haben.
Eine Warnmeldung kann technisch korrekt sein und dennoch in der Praxis schwer zu interpretieren sein.
Zwei Perspektiven auf dasselbe Ereignis
Stellen Sie sich einen Pharmastandort vor, an dem ein Rechner zur Steuerung und Konfiguration von Produktionsanlagen mit einer Maschinensteuerung ausserhalb seines üblichen Produktionsbereichs kommuniziert.
Für das Security Operations Center (SOC) ist die Verbindung auffällig: Sie überschreitet eine erwartete Grenze und weicht vom bisherigen Kommunikationsmuster ab.
Aus Sicht des Anlageningenieurs kann sich ein anderes Bild ergeben. Eine Verpackungslinie wird nach Wartungsarbeiten wieder in Betrieb genommen und die Workstation wurde vorübergehend verlegt, um Tests durchzuführen. Die Kommunikation könnte legitim sein.
Möglich ist aber auch, dass genehmigte Arbeiten über einen nicht freigegebenen Pfad stattfinden, die Firewall-Regel zu weit gefasst ist oder ein Hersteller-Account nach dem Wartungsfenster weiterhin aktiv bleibt.
Geplante Wartung macht beobachtete Aktivität nicht automatisch unbedenklich. Ebenso beweist ungewöhnliches Netzwerkverhalten noch keinen Angriff.
Für eine verlässliche Bewertung werden beide Perspektiven benötigt:
- Das SOC muss Zweck und operative Rolle der beteiligten Systeme verstehen.
- Das OT-Team muss nachvollziehen können, warum das Verhalten aus Security-Sicht relevant ist.
- Beide benötigen eine gemeinsame Timeline der Änderungen, Verbindungen und betroffenen Systeme.
Ohne diesen Kontext läuft die Security-Incident-Untersuchung Gefahr, in eines von zwei Extremen zu kippen: Entweder wird der Alert ohne ausreichendes Prozessverständnis eskaliert, oder er wird vorschnell als Wartungsaktivität abgetan.
Leistungsfähige Tools, fragmentierte Incident-AnalyseLeistungsfähige Tools, fragmentierte Incident-Analyse
Industrielle Security-Umgebungen stützen sich selten auf eine einzige Datenquelle.
Eine OT-Security-Plattform liefert Informationen zu Assets und Protokollen. Firewalls protokollieren den Verkehr zwischen Zonen. Remote-Access-Lösungen zeigen, welcher Anbieter wann verbunden war. Switch-Telemetrie hilft, Kommunikationspfade nachzuvollziehen. Das SOC ergänzt Endpoint-, Identity- und Threat-Intelligence-Daten aus der IT.
Jede Quelle beantwortet eine andere Frage.
Die Schwierigkeit beginnt, wenn ein Analyst diese Antworten für eine Incident-Analyse zusammenführen muss. Typischerweise sind mehrere Schritte nötig:
- Ermitteln Sie die beteiligten Systeme und deren Funktionen in der Produktion.
- Geplante Wartungs- oder Engineering-Arbeiten prüfen.
- Remote Sessions und aktuelle Netzwerkänderungen nachvollziehen.
- Feststellen, ob die Kommunikation neu ist oder früher bereits auftrat.
- Die betrieblichen Folgen eines Containments mit dem Werk klären.
- Ausreichende Nachweise für Eskalation und Reporting sichern.
Ein internes SOC verfügt möglicherweise über etablierte Integrationen und lokales Wissen, aber ein externer Analyst kennt den Standort, den Prozess und den Anlagenhersteller meist weniger genau.
Der Alert erreicht das SOC, der für dessen Bewertung notwendige Prozesskontext jedoch nicht automatisch.
OT und Security zusammenbringen
OT- und SOC-Teams verwenden oft unterschiedliche Begriffe, weil sie unterschiedliche Risiken verantworten.
Das SOC betrachtet Threat Activity, betroffene Systeme, Lateral Movement, Containment und verfügbare Nachweise. Das Werk konzentriert sich auf Prozesszustand, Anlagenabhängigkeiten, Safety, Produktqualität und Verfügbarkeit.
Keine der beiden Perspektiven reicht für sich allein aus.
Wenn das SOC empfiehlt, eine Rechner zur Anlagenkonfiguration zu isolieren, muss das OT-Team wissen, ob dadurch eine Produktionslinie stillsteht oder ein Safety-relevanter Prozess beeinträchtigt wird. Wenn das Werk eine Hersteller-Verbindung offenhalten möchte, muss das SOC wissen, welche Systeme erreichbar sind, wie der Zugriff authentifiziert wird und ob sich die Aktivität später rekonstruieren lässt.
Wenn das SOC empfiehlt, eine Rechner zur Anlagenkonfiguration zu isolieren, muss das OT-Team wissen, ob dadurch eine Produktionslinie stillsteht oder ein Safety-relevanter Prozess beeinträchtigt wird. Wenn das Werk eine Hersteller-Verbindung offenhalten möchte, muss das SOC wissen, welche Systeme erreichbar sind, wie der Zugriff authentifiziert wird und ob sich die Aktivität später rekonstruieren lässt.
Im Rahmen einer Untersuchung kann dieser Kontext Folgendes umfassen:
- die Produktionsfunktion des Assets
- ihre Netzwerkzone und üblichen Kommunikationspartner
- aktuelle Wartungsarbeiten
- den verantwortlichen Asset Owner
- Kommunikation vor und nach der Warnmeldung
- bekannte Remote Sessions
- die operativen Folgen einer Isolierung
Nicht jede Information muss in jedem Alert stehen. Entscheidend ist, dass OT und SOC ein gemeinsames Lagebild aufbauen können, ohne die Situation jedes Mal manuell aus getrennten Systemen zu rekonstruieren.
SOC fragt:
Ist es bösartig, wie weit hat es sich ausgebreitet und wie können wir es eindämmen?
OT fragt:
Welcher Prozess ist betroffen, ist ein Eingriff unbedenklich und wie wirkt sich dies auf die Produktion aus?
Warum nicht alle OT-Daten ins SIEM gehören
Die klassische Antwort auf fragmentierte Security-Daten ist Zentralisierung: Logs und Alerts werden an das SIEM weitergeleitet, Korrelationsregeln erstellt und Incident-Analysen vom SOC aus geführt.
Für manche Organisationen ist das der richtige Ansatz: Eine ausgereifte SIEM-Umgebung mit OT-Integrationen, angemessener Retention und OT-erfahrenen Analysten kann einen erheblichen Mehrwert schaffen.
Das bedeutet jedoch nicht, dass jede verfügbare OT-Datenquelle ungefiltert an das SIEM übertragen werden sollte.
Industrielle Umgebungen umfassen oft viele Standorte, Netzwerkgeräte und spezialisierte Security-Systeme. Die vollständige Erfassung aller Logdaten kann Kosten erhöhen, ohne die Analysen entsprechend zu verbessern. Mehr Alerts ersetzen einen fehlenden Produktionskontext nicht.
Die bessere Frage lautet deshalb nicht: „Können wir diese Daten an das SIEM senden?“ sondern: „Welche Informationen helfen den verantwortlichen Personen, eine bessere Entscheidung im Rahmen einer Incident-Bewertung zu treffen?“
Manchmal genügt ein priorisierter Alert mit ausreichendem Asset-, Netzwerk- und historischem Kontext. In anderen Fällen benötigt das OT-Team eine verknüpfte eigene Sicht auf die Kommunikation. Auch externe Anbieter können Zugriff auf relevante Nachweise benötigen, jedoch nicht zwingend auf jedes System.
Zentralisierung kann helfen, eine wahllose Datensammlung löst das Problem der Zusammenarbeit jedoch nicht.
Welche Informationen helfen jemandem dabei, eine bessere Entscheidung zu treffen?
Kontext vor der Korrelation
Security Teams korrelieren Events, um zusammenhängende Aktivitäten zu erkennen. In OT-Umgebungen setzt sinnvolle Korrelation voraus, dass die Systeme und Prozesse hinter diesen Events verstanden werden.
Ein Maschinenhersteller verbindet sich beispielsweise während einer geplanten Stilllegung per Remote Access. Kurz darauf kommuniziert eine Engineering Workstation mit mehreren Steuerungen, eine neue Verbindung entsteht zwischen Produktionsbereichen und eine Firewall-Policy wird geändert.
Jedes Event kann im Rahmen der Wartung zulässig sein. Gemeinsam bilden sie jedoch eine Aktivitäts-Sequenz, die geprüft werden sollte:
- Lag die Verbindung innerhalb des genehmigten Zeitfensters?
- Wurde der erwartete Hersteller-Account verwendet?
- Erreichte der Techniker nur die im Auftrag genannten Systeme?
- War die Firewall-Änderung genehmigt und ausreichend eingeschränkt?
- Endete die Kommunikation nach Abschluss der Arbeiten?
- Wurde der temporäre Zugriff wieder aufgehoben?
Der Mehrwert entsteht durch die Verbindung technischer Events mit dem betrieblichen Zweck. Der Hinweis “Wartung geplant” reicht nicht aus. Die Untersuchung muss zeigen, ob die beobachtete Aktivität tatsächlich zum genehmigten Umfang passt.
Historische Netzwerkdaten machen sichtbar, wann Verbindungen entstanden, wie sich das Verhalten während der Arbeiten änderte und was nach dem Wartungsfenster bestehen blieb.
Anstatt zu entscheiden, ob eine einzelne Warnmeldung normal oder verdächtig ist, kann das Team beurteilen, ob die gesamte Abfolge aus betrieblicher Sicht sinnvoll ist.
Ein gemeinsames Lagebild ohne bestehende Tools zu ersetzen
Bessere OT-Incident-Untersuchungen erfordern weder das Ersetzen aller bestehenden Plattformen noch die Zusammenführung jeder Funktion in einem einzigen System.
Spezialisierte OT-Security-Tools bleiben wichtig für Asset Discovery, Protokollanalyse und OT-spezifische Detection. Firewalls und Remote-Access-Plattformen liefern eigene relevante Logs. SIEM- und SOC-Prozesse ergänzen Bedeutungskontext und etablierte Eskalationswege.
Das Ziel ist, die Informationen dieser Systeme teamübergreifend nutzbar zu machen.
OT-Ingenieure, SOC-Analysten und externe Dienstleister sollten dieselben Assets, Kommunikationspfade und dieselbe Timeline betrachten können und ihre jeweilige Expertise einbringen.
Netzwerk-Metadaten, Infrastruktur-Telemetrie und Security-Informationen können dafür konsolidiert werden, ohne vorhandene Speziallösungen zu ersetzen. Es geht nicht um eine weitere isolierte Alert-Quelle, sondern um eine einfachere gemeinsame Untersuchung und Bewertung bestehender Signale.
Die Technologie ist zwar wichtig, doch noch wichtiger ist ein gemeinsames Verständnis.
Von mehr Alerts zu besseren Entscheidungen
Der Reifegrad von OT Security wird häufig anhand der überwachten Standorte, erfassten Assets oder ans SOC gesendeten Alerts bewertet. Diese Kennzahlen sind nützlich, zeigen aber nicht, ob eine Organisation bei einem relevanten Event tatsächlich handlungsfähig ist.
Ein aussagekräftigerer Test verfolgt einen aktuellen oder repräsentativen Alert durch den gesamten Analyseprozess:
- Konnte der Analyst die betriebliche Funktion der Assets bestimmen?
- War die historische Kommunikation schnell verfügbar?
- Verstand das OT-Team die Security-Relevanz der Aktivität?
- Konnten genehmigte Arbeiten von Aktivitäten ausserhalb des vorgesehenen Umfangs unterschieden werden?
- Reichten die Nachweise für eine Containment- oder Eskalationsentscheidung aus?
Wenn die Antworten eine langwierige manuelle Rekonstruktion verlangen, werden zwar viele Daten erfasst, es fehlt jedoch ein wirksames Betriebsmodell für deren gemeinsame Bewertung.
Der nächste Schritt bei der OT-Sicherheit besteht nicht einfach darin, mehr Informationen zu generieren. Vielmehr geht es darum, Sicherheitsnachweise mit den Personen zu verknüpfen, die verstehen, wie die Systeme funktionieren und was bei Änderungen auf dem Spiel steht.
Ein OT Security Alert schafft dann Wert, wenn er eine Entscheidung unterstützt. Dafür benötigen OT und SOC ein gemeinsames, verlässliches Lagebild.
Die wichtigsten Erkenntnisse
- OT-Security-Tools, Firewalls, Remote-Access-Systeme und SOC-Plattformen liefern jeweils einen Teil des erforderlichen Kontexts.
- Ungewöhnliche Kommunikation lässt sich nur mit Kenntnis des Prozesses, der Wartungsarbeiten und der betrieblichen Abhängigkeiten zuverlässig bewerten.
- Geplante Arbeiten liefern Kontext, sind aber kein Grund, ungewöhnliche Aktivität ungeprüft auszuschliessen.
- Mehr OT-Daten im SIEM lösen das Problem nicht, wenn Analysten weiterhin der operative Kontext fehlt.
- Ein gemeinsames Lagebild hilft OT, SOC und externen Partnern, Entscheidungen auf Basis derselben Fakten zu treffen.
Weiterlesen
OT-Security ohne zusätzlichen Aufwand
Wie können Unternehmen OT-Sicherheitsinformationen, Netzwerkdaten und betriebliches Fachwissen miteinander verknüpfen, ohne dabei unnötige SIEM-Komplexität zu verursachen?
Laden Sie das Whitepaper „OT-Security ohne Mehraufwand“ herunter, um einen praktischen Ansatz für die Erstellung eines gemeinsamen Lagebildes zwischen OT-Teams, Sicherheitsabteilungen und externen Anbietern kennenzulernen.
OT Security Evaluation Guide
Der „OT Security Evaluation Guide“ enthält praktische Fragen, anhand derer Sie feststellen können, ob Ihre derzeitigen Tools und Prozesse ausreichend Kontext für Untersuchungen, Zusammenarbeit und die Reaktion auf Vorfälle bieten.
