OT Sicherheitstools können zwar wertvolle Signale erkennen, doch ein „ Warnmeldung “ (Anomaliebericht) gibt selten Aufschluss über den dahinterstehenden Produktionsprozess. Eine effektive „Untersuchung “ (Anomalieerkennung) hängt davon ab, dass Netzwerkinformationen, Anlagenkenntnisse und Sicherheitsfachwissen in einer einheitlichen operativen Sicht zusammengeführt werden.
OT Sicherheit Warnmeldungen Bedarf operativ Kontext. Erfahren Sie warum OT Teams, SOCs und Sicherheitsfachleute Tools müssen gemeinsam genutzt werden Informationen um zu untersuchen industrielle Unfälle effektiv.
OT Teams verstehen die Produktion Prozess. SOC Teams verstehen das Bedrohung. Ein wirksame Untersuchung erfordert beides Ansichten gleichzeitig.
Viele Industrieunternehmen haben erhebliche Fortschritte im Bereich der Sicherheit von „ OT “ erzielt.
Sie habenasset discovery , industrielle Einbruchserkennung, verbesserte Firewalls und einen besser kontrollierten Fernzugriff eingeführt. Sicherheitszentralen erhalten zunehmend Informationen aus Produktionsumgebungen, während spezialisierte Sicherheitsplattformen OT Einblicke in industrielle Protokolle, Schwachstellen assets 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 bekannten Fragen auf: Ist diese Kommunikation zu erwarten? Welcher Produktionsprozess hängt von dem betroffenen System ab? Wurden Wartungsarbeiten durchgeführt? Wem gehört das „ asset “? Kann es sicher isoliert werden?
Das Problem besteht nicht unbedingt darin, dass ein weiteres Erkennungs Fähigkeit t fehlt. Häufiger ist es so, dass die relevanten Informationen zwar bereits vorhanden sind, jedoch über verschiedene Tools und Teams, die unterschiedliche Aspekte der Situation betrachten, verteilt verteilt sind.
Ein „ Warnmeldung “ mag zwar technisch korrekt sein, ist aber in der Praxis möglicherweise schwer zu interpretieren.
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.
Für einen „ Untersuchung “ kann dieser Kontext Folgendes umfassen:
- Die Produktionsfunktion des betroffenen Unternehmens assets.
- Ihre Netzwerkzone und ihre üblichen Kommunikationspartner.
- Kürzlich durchgeführte Wartungsarbeiten, Inbetriebnahmen oder Konfigurationsänderungen.
- Der für die Anlage oder den Prozess verantwortliche Eigentümer.
- Historische Kommunikation vor und nach dem „ Warnmeldung “.
- Bekannte Fernzugriffssitzungen.
- Die operativen Folgen der Isolation.
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.
Eine Zentralisierung kann zwar helfen, doch eine wahllose Datenerfassung löst in der Regel nicht das zugrunde liegende Problem der Zusammenarbeit.
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 ein isoliertes „ Warnmeldung “ normal oder verdächtig ist, kann das Team beurteilen, ob die gesamte Sequenz aus betrieblicher Sicht Sinn ergibt.
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 Sicherheit von „ OT “ 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 auf dem Spiel steht, wenn sich diese ändern.
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 Informationen zur „ OT “-Sicherheit, Netzwerkdaten und operatives Fachwissen miteinander verknüpfen, ohne dabei unnötige Komplexität bei der „SIEM “ zu verursachen?
Laden Sie das Whitepaper „ OT Security Without the Overhead“ herunter, um einen praktischen Ansatz für die Erstellung eines gemeinsamen Lagebildes über die Teams von „OT “, den Sicherheitsbetrieb und externe Anbieter hinweg kennenzulernen.
OT Security Evaluation Guide
Der Leitfaden zur Sicherheitsbewertung „ OT “ enthält praktische Fragen, anhand derer Sie feststellen können, ob Ihre derzeitigen Tools und Prozesse ausreichend Kontext für die „ Untersuchung “, die Zusammenarbeit und die „ Vorfall “-Reaktion bieten.
