OT Security Made Simple Podcast: Pragmatismus im OT SOC

Bei „OT Security Made Simple" habe ich mit Klaus Mochalski über den Aufbau von OT-SOCs gesprochen. Einen Punkt daraus greife ich hier auf. Im OT Security Monitoring schaffen die Security-Lösungen vor allem Sichtbarkeit. Auf dieser Basis treffen Security-Team und OT-Team gemeinsam die Entscheidungen.

Während im IT-SOC das Isolieren eines Hosts oder das Sperren eines Accounts üblich ist, hat man diese Optionen in der OT oft nicht, weil sie technisch nicht möglich oder betrieblich nicht erlaubt sind. Eine Steuerung, die einen laufenden Prozess fährt, schaltet man nicht ab, weil ein Alarm aufleuchtet. Taucht ein neues Asset im Netz auf, kann das ein Angreifer mit einem Raspberry Pi sein oder eine nicht angemeldete Wartung. Die erste Handlung ist dann, den Wartungskalender zu prüfen, den Kunden zu kontaktieren und parallel das neue Gerät auf verdächtige Aktivitäten zu beobachten. Ein fremdes Gerät, das nicht zum Prozess gehört, lässt sich gefahrlos vom Netz nehmen, wenn Portscans, Brute-Force und Exploits zusammenkommen und das mit dem Kunden abgestimmt ist. Eine prozessführende Steuerung nicht.

OT-SOC-Aufbau rückwärts beginnen

Der Ausgangspunkt ist die Incident Response. Welche Vorfälle sollen erkannt werden, wofür braucht es Playbooks, für welches Asset, welcher Befund, welche Handlung, wer entscheidet. Daraus ergeben sich die Use Cases. Viele Use Cases, die Alarme erzeugen, auf die am Ende niemand reagiert, bringen nichts. Erst aus den Use Cases ergibt sich der Datenbedarf, welche Log-Quellen relevant sind und angebunden werden müssen, auf Host-Ebene wie im Netzwerk. In der OT läuft diese Kette aber nicht nur in eine Richtung. Was an Daten überhaupt erreichbar ist, entscheidet mit, welche Use Cases sich umsetzen lassen.

An diese Daten zu kommen, ist in der Praxis aufwendig. Oft fehlen Logdaten ganz, oder sie entstehen, werden aber nicht eingesammelt, weil bei der Planung nie ein Log-Kollektor vorgesehen war. Manche Switches beherrschen kein Port Mirroring, und manche Protokolle werden von der Sensorik gar nicht erkannt oder geloggt.

Passives Monitoring auf der Feldebene ist der Normalfall. Wir installieren keinen Agenten auf einer SPS oder einem Schutzgerät, überwachen aber deren Netzwerkverkehr. Im IEC-61850-Umspannwerk laufen MMS und GOOSE auf dem Stationsbus, Sampled Values auf dem Prozessbus. GOOSE und Sampled Values sind Layer-2-Multicast und verlassen den lokalen Bus nicht. Wer den Sensor nur oben in der DMZ aufhängt, sieht die schnelle Schutzkommunikation nicht.

Erst prüfen, dann handeln

Angriffserkennung in der OT lebt von zwei Dingen, Signaturen und einer Baseline des Normalzustands. Warum beides zusammengehört, hat mir ein Vorfall gezeigt. Unsere Sensorik meldete massenhaft Exploits und Malware. Im Team hieß es zuerst, die Anlage sei komplett infiziert und müsse vom Netz. Bei der Analyse zeigte sich, dass es der Backup-Job war, der die Signatur-Updates für die Sensorik selbst heruntergeladen hatte. Der Sensor hatte sich an seinen eigenen Signaturen erkannt.

In der IT ist ein Fehlalarm nicht schwerwiegend. In der OT wiegt die Reaktion schwerer als der Fehlalarm. Wenn im Playbook steht „bei Massenalarm abschalten" und man handelt stur nach Plan, richtet man über einen False Positive echten Schaden an. Geholfen hat der Kontext. Die Baseline kannte diesen Host als regelmäßigen Update-Bezieher, und wir konnten das PCAP herunterladen und selbst nachsehen. Genau das meint Sichtbarkeit, prüfen zu können, bevor man handelt. Eine Sensorik, die nur „Angriff X detektiert" meldet und keine Rohdaten herausgibt, ist in diesem Moment wertlos.

Klein anfangen

Wer eine Bestandsanlage betreibt und das Monitoring nachrüsten will, sollte nicht versuchen, alles auf einmal zu lösen. Der wirksamste erste Schritt ist der kleinste. Wenige Systeme onboarden, wenige Use Cases schreiben, die ersten Playbooks aufsetzen. Dazu die Prozessfragen klären, die im Ernstfall zählen. Wer darf was? Wer eskaliert an wen? Was passiert nach 18 Uhr, wenn die Tagschicht weg ist?

Und dann üben. Tabletop vor Red Team. SOC und Anlagenbetrieb brauchen dasselbe Bild davon, was möglich, erlaubt und sinnvoll ist. Kommt es zum Vorfall, wissen die Wenigsten, was sie isolieren dürfen und was zuerst mit dem Kunden abzustimmen ist. Das erlebe ich immer wieder. Diese Entscheidung trifft man besser nicht zum ersten Mal, während es brennt.

Das ganze Gespräch mit Klaus Mochalski gibt es in der aktuellen Folge von „OT Security Made Simple".

https://www.rhebo.com/de/podcasts/pragmatismus-im-ot-soc-wie-anlagen-monitoring-in-der-praxis-funktioniert