Irgendwie anders: Notfallvorsorge in der OT

OT ist anders als IT!

Diese Wahrheit ist mittlerweile allgemein anerkannt, wobei wir in der Security trotzdem sehr oft den Versuch sehen, Lösungen, die eigentlich für IT-Umgebungen entwickelt wurden auf OT-Umgebungen anzuwenden. Oft funktioniert das auch und man findet viele Synergieeffekte zwischen IT und OT. In diesem Blog geht nun um das Themenfeld, in dem dies meiner Meinung nach am schlechtesten funktioniert: Notfallvorsorge.

Was ist Business Continuity Management (BCM)?

Hier ein kurzer Exkurs darüber, was ich damit meine: Die DIN EN ISO/IEC 27002:2024 ist in Kap. 5.30 von einer „IKT-Bereitschaft für Business Continuity“ die Rede.

Was bedeutet das? „Business Continuity“ bedeutet (wie der Name impliziert), dass die Geschäftsprozesse einer Organisation auch unter sehr widrigen Umständen (in Notfällen) weitergeführt werden. Zum Beispiel wenn das komplette Unternehmensnetz durch Ransomware verschlüsselt wird, sollte aus dem Business Continuity Plan (BCP) hervorgehen, wie die wichtigsten Geschäftsprozesse ohne die betroffenen Computersysteme weiterbetrieben werden können.

Ein solcher BCP ist aber nicht nur für Cybervorfälle bzw. Notfälle zu entwickeln. Notfälle können z.B. auch Brände von wichtigen Gebäuden oder ein flächendeckender Personalausfall aufgrund einer sich ausbreitenden Krankheit sein, also Dinge, die völlig unabhängig von IT oder OT sind. Das Business Continuity Management (BCM) kann also grundsätzlich unabhängig von Informationssicherheitsmanagement gesehen werden. Es gibt jedoch Schnittmengen, die u.a. im oben erwähnten Kapitel der ISO/IEC 27002 adressiert werden.

Standards, die helfen sollen

Die wichtigste Schnittmenge zwischen den beiden Themengebieten ist die Vorbereitung auf einen Wiederanlauf von IT bzw. OT-Systemen nach deren Ausfall (oder Wiederherstellung nach Verschlüsselung, o. Ä.). Ich schaue nun im Folgenden auf zwei Standards, die beim BCM helfen sollen und versuche, sie auf OT-Umgebung anzuwenden:

· BSI-Standard 200–4

· NIST SP800–34

Diese Standards beschäftigen sich ganzheitlich mit dem Thema BCM im Kontext IT (dies wird vom BSI „IT-Service Continuity Management“ genannt). Ich beschäftige mich im Folgenden nur mit einem Teilaspekt davon, nämlich den Wiederanlaufvorbereitungen. In der Incident Response kommt irgendwann der Punkt, an dem man auf diese Vorbereitungen zurückgreifen muss!

Die Business Impact Analyse (BIA) in der OT

Ziel der Business Impact Analyse ist es, die Ausfallkritikalität (den „Business Impact“) eines Systems zu bestimmen. Letztendlich bestimmt man dadurch die Verfügbarkeitsanforderungen des Systems in mehreren Dimensionen. Laut BSI 200–4 geht man dabei wie folgt vor:

Das Untragbarkeitsniveau

Es soll bestimmt werden, wie lange ein IT-Service ausfallen darf, bevor ein bestimmtes Untragbarkeitsniveau erreicht ist. Idealerweise ist dieses Niveau quantifiziert, z.B. „…bis wir 20% unseres Jahresumsatzes verloren haben“. Betrachtet man nun z.B. den Geschäftsprozess „Scheiben von Rechnungen“ mit den dahinterliegenden IT-Systemen unter der Frage stellen „Wie lange darf das Ausfallen, bis wir 20% unseres Umsatzes verloren haben?“, kommt man z.B. zu dem Schluss, dass ohne Rechnungen der Cashflow sehr schnell unterbrochen wird. So kann man ausrechnen, wann das Untragbarkeitsniveau erreicht ist.

Bei Betrachtung eines begrenzten OT-Scopes ist es oft gar nicht nötig, so genau auf einzelne Services zu schauen: in der Regel gibt es nur den Zustand „Anlage läuft, es wird produziert“ oder „Anlage läuft nicht, es wird nicht produziert“ (oder je nach Branche „Abwasser wird nicht geklärt“, „Stromnetz fällt aus“ o.Ä.). Man sollte vermeiden (insbesondere, wenn man die Analyse mit Fachingenieuren durchführt, die für diese Anlage verantwortlich sind), dass der Zustand „Anlage aus“ sofort und ohne weiteres Hinterfragen als Untragbarkeitsniveau festgelegt wird! Stattdessen muss der zu analysierende Scope im Unternehmenskontext betrachtet werden: Wie viel finanzieller Verlust bedeutet ein Anlagenstillstand pro Tag? Müssen andere Anlagen bei Ausfall ebenfalls abgeschaltet werden (und nach welcher Ausfallzeit tritt dies ein)? Kommt es bei Ausfall der Anlage zu einer Unterversorgung am Markt oder in der Bevölkerung (Stichwort: kritische Dienstleistung)? Ab wann drohen Vertragsstrafen?

Wenn man diese Fragen stellt, kommt man bei den meisten Anlagen zu dem Ergebnis, dass eine gewisse Zeit an Stillstand tolerierbar ist. Das ist auch gut so, denn schließlich müssen Produktionsanlagen auch mal routinemäßig ausgeschaltet (und wieder hochgefahren werden). Diese „gewisse Zeit“ gilt es zu quantifizieren als Grundläge für die nächsten Schritte. Das „Untragbarkeitsniveau“ in der OT lautet i.d.R. also immer „Anlage steht für [füge quantifizierte „gewisse Zeit“ ein]“.

Exkurs zu NIST-SP800–34: Dieser Standard kennt kein „Untragbarkeitsniveau“, sondern geht davon aus, dass man vorher eine Risikoanalyse durchgeführt hat und daher die Unternehmensprioritäten bzgl. Verfügbarkeit einzelner Systeme bereits bekannt sind. Wenn diese Voraussetzung erfüllt ist, ist natürlich schon eine sehr gute Grundlage für die BIA vorhanden. In einer guten Risikoanalyse sollten das „Untragbarkeitsniveau“ also schon mit drinstecken.

Die Recovery-Time Objective (RTO)

Zurück zu der “gewissen Zeit“ nach der ein Anlagenausfall „untragbar“ wird: Diese Zeit gibt uns also an, wie lange es maximal dauern darf, bis die betrachtete Anlage nach einem ungeplanten Ausfall wieder zur Verfügung stehen muss.

Wenn man nun einzelne Services bzw. einzelne OT-Komponenten betrachtet, stellt man i.d.R. fest, dass es Komponenten gibt

1) bei deren Ausfall die Anlage sofort ausfällt oder nach kurzer Zeit manuell abgeschaltet werden muss. Das gilt z.B. für die SPSen, die in der Anlage verbaut sind. Wenn die Anlage über ein Leitsystem verfügt, sollte man betrachten, ob die Anlage bei Ausfall dieses Systems noch sicher betrieben werden kann oder ob aus Sicherheitsgründen manuell abgeschaltet werden muss.

2) deren Ausfall zunächst keinen Einfluss auf den Anlagenbetrieb hat. D.h. man geht i.d.R. davon aus, dass der Ausfall dieser Komponenten behoben werden kann, bevor dies einen Einfluss auf den Prozess hat. Das könnte z.B. die Betriebsdatenerfassung oder „normale“ IT-Dienste wie der Verzeichnisdienst oder der Backup-Service sein, denn idealerweise hat man seine OT-Umgebung so aufgebaut, dass ein Ausfall dieser Services nicht zu einem Ausfall der Anlage führt.

Diese Erkenntnisse helfen uns beim nächsten Schritt der BIA, nämlich bei der Bestimmung der Recovery Time Objectives (RTO). Wie oben erwähnt fragen wir uns dabei für jede Komponente, wie lange es maximal dauern darf, bis diese nach einem Ausfall wiederhergestellt ist.

Am interessantesten sind dabei natürlich die Komponenten aus Kategorie 1). Wenn der Ausfall dieser Komponenten zum Ausfall der Anlage führt, bedeutet das im Umkehrschluss, dass diese Komponenten vor dem Wiederanlauf der Anlage wieder zur Verfügung stehen müssen. Die maximale RTO dieser Komponenten ist also die oben erwähnte „gewisse Zeit“, nach der die gesamte Anlage wieder laufen muss. Oft ist sie kürzer, weil noch Tests durchgeführt werden sollen oder weil noch Abhängigkeiten zu anderen Komponenten bestehen (siehe folgendes Kapitel).

Die Komponenten der Kategorie 2) kann man in der BIA fast schon vernachlässigen, da diese vermutlich erst nach dem Wiederanlauf der Anlage und damit nach Wiederanlauf des Produktionsbetriebes stattfindet. Man sollte allerdings sicherstellen, dass man es wirklich mit einer Komponente der Kategorie 2) zu tun hat, indem man diese Komponenten in die Abhängigkeitsanalyse integriert.

Exkurs Definitionen: Maximum Tolerable Downtime (MTD) vs. Recovery Time Objective (RTO): Neben der RTO definiert die NIST SP800–34 noch die MTD. Dies ist die Zeit, die ein einzelner Geschäftsprozess maximal ausfallen darf. Wenn man den Betrieb der Anlage im Scope unserer Betrachtung also als einzelnen Geschäftsprozess auffasst, entspricht unsere oben definierte „gewisse Zeit“ der MTD dieses Geschäftsprozesses. Das ist aber nicht immer der Fall, weswegen ich in diesem Blog auf die Einführung und Nutzung der MTD verzichte. Beim BSI 200–4 wird übrigens von Maximum Tolerable Period of Disruption (MTPD) gesprochen, was m.E. identisch zur MTD ist. Achtung: Die RTO wird beim BSI leicht anders definiert: So fängt die RTO hier erst an, nachdem ein Notfall als solcher erkannt und ausgerufen wurde. Dies ist ggf. später als der Zeitpunkt des Systemausfalls, sodass die RTO beim BSI kürzer ausfällt. Im Folgenden wird die o.g. Definition der RTO verwendet, welche der Definition nach NIST entspricht.

Die Abhängigkeitsanalyse

Es ist nicht ausreichend, die Verfügbarkeitsanforderungen der Geschäftsprozesse und Komponenten nur für sich allein zu betrachten. In der Realität sind diese voneinander abhängig.

Ein typisches OT-Beispiel ist eine Chemieanlage, die ein flüssiges Produkt produziert. Dieser Produktionsprozess kann nur durchgeführt werden, wenn mittelfristig ein Tanklager zur Verfügung steht um das Produkt aufzunehmen; oder wenn das Produkt in Kesselwagen oder auf Schiffe o.Ä. verladen werden kann. Hierbei besteht also eine Abhängigkeit zwischen zwei Prozessen.

Auch zwischen einzelnen OT-Komponenten oder OT-Services bestehen Abhängigkeiten: Z.B. ist eine Überwachung des Prozesses im Leitsystem so lange nicht möglich, bis das Controller-Netzwerk wiederhergestellt ist.

Diese Abhängigkeiten müssen natürlich in der Reihenfolge des Wiederanlaufes berücksichtigt werden. Die Abhängigkeitsanalyse zwischen OT-Komponenten fällt aber oft sehr ähnlich aus: Zunächst muss die Steuerungsebene wiederhergestellt werden. Dazu braucht man i.d.R. eine Art Engineering-PC. Um die Steuerung zu erreichen, braucht man entweder Netzwerk (also Switche) oder physischen Zugang. Daher sollte man zunächst das Netzwerk wiederherstellen, dann einige wenige Engineering-PCs aufsetzen, um die Steuerungen wieder mit Programmen bespielen zu können. Im Anschluss kann man sich der Wiederherstellung des Leitsystems und der HMIs widmen, welche wiederum Input-Daten aus den Steuerungen brauchen.

Der Notbetrieb

Dies ist kein Teil der BIA, birgt aber dennoch OT-spezifische Besonderheiten: Die Frage, ob während des Systemausfalls ein (möglicherweise auch nur eingeschränkter) Notbetrieb stattfinden kann wird in der OT oft diametral anders beantwortet als in der IT.

In der IT gibt es das Konzept der „Hot Site“ oder „Warm Site“: D.h. wenn ein Standort nicht mehr verfügbar ist wird ein zweiter Standort bereitgehalten, an dem die IT-Services dann laufen können. „Hot Site“ bedeutet dabei, dass die Umstellung sogar automatisch erfolgt; „Warm Site“ bedeutet, dass diese bereit steht, aber noch in Betrieb genommen werden muss. „Hot Sites“ oder „Warm Sites“ sind oft in der Cloud angesiedelt. Ich habe schon oft Unternehmen erlebt, die bei Cyberangriffen die wichtigsten Systeme in der Cloud schnell wieder in Betrieb nehmen konnten um zumindest einen Notbetrieb zu gewährleisten, während die On-Prem Systeme von Incident Respondern untersucht und wiederhergestellt wurden.

In der OT sind die Konzepte „Hot Site“ bzw. „Warm Site“ i.d.R. unbrauchbar, da man für die eigentlichen Produktionsanlagen ja keine Redundanzen in der Cloud oder sonstwo schaffen kann. Was nützt es einem also, wenn man z.B. bei einem Brand das Leitsystem einer Anlage schnell in an einem Standort wiederherstellt, die eigentliche Produktionsanlage aber beschädigt ist und daher sowieso ausfällt? Ausnahmen sind natürlich dezentrale „Anlagen“, wie z.B. Stromnetze oder Pipelines, bei denen sich die OT nicht zwangsläufig am gleichen Standort wie die physischen Anlagen befindet.

Stattdessen sollte man sich pragmatische Workarounds überlegen: Kann uns beim Ausfall der Anlage ein anderer Unternehmensstandort aushelfen, damit wir die nachgelagerten Prozesse weiter betreiben können? Ist ein Handbetrieb oder (je nach dem, welche Systeme genau ausgefallen sind) ein Betrieb via HMI (ohne Leitsystem) möglich? Wenn ja, wie lange können die Workarounds aufrechterhalten werden? Welche zusätzlichen Ressourcen sind dafür erforderlich?

Die Wiederanlaufreihenfolge

Wenn man also für jede Komponente und für jeden Service eine RTO bestimmt hat und zudem eine Abhängigkeitsanalyse durchgeführt hat, kann man die Komponenten bzw. Services in eine sinnvolle Wiederanlaufreihenfolge bringen. Dabei ist zu beachten, dass keine RTO überschritten wird und das keine Abhängigkeit unberücksichtigt bleibt.

Wenn man bei der BIA eines OT-Scopes an diesem Punkt ankommt, stellt man oft fest, dass bei vielen Komponenten die Reihenfolge gar nicht so wichtig ist. Wichtig ist nur, dass bestimmte Komponenten (siehe Kategorie 1 weiter oben) zur Verfügung stehen, wenn die Anlage wieder anlaufen soll. In welcher Reihenfolge sie vorher wiederhergestellt wurden ist oft irrelevant, schließlich muss alles notwendige laufen, damit man den Betrieb sicher wieder aufnehmen kann.

Außerdem ist es an dieser Stelle extrem wichtig sich klar zu machen, auf welches Szenario man sich eigentlich vorbereitet. In einer BIA für IT-Umgebungen ist es relativ einfach sich Szenarien eines Totalausfalls vorzustellen: z.B. Verschlüsselung aller Systeme mit Ransomware. In der OT muss man sich dabei immer fragen: „betrifft dieses Szenario wirklich alle meine Systeme?“. Ob eine Ransomware in einer OT-Umgebung wirklich alle Steuerungen und smarten Feldgeräte mitverschlüsselt ist stark zu bezweifeln. Eine Wiederherstellung der Feldebene ist in diesem Fall also vielleicht gar nicht nötig. Beim Szenario eines Stromausfalls sieht der Wiederanlauf wiederum anders aus: hier kann davon ausgegangen werden, dass die Systeme zwar wieder in Betrieb genommen werden müssen, aber keine Daten wiederhergestellt werden müssen.

Es lohnt sich in der OT also umso mehr, die Wiederanlaufreihenfolge so flexibel zu gestalten, dass sie für verschiedene Notfallszenarien passend ist.

Wer führt den Wiederanlauf eigentlich durch?

Bei OT-Systemen ist die Antwort auf diese Frage oft schnell klar: Der Systemhersteller muss das machen, schließlich hat man einen Wartungsvertrag mit einer festgelegten Reaktionszeit.

Das ist gut so! Nach der BIA sollte man als erstes prüfen, ob die RTO sich mit dieser Reaktionszeit deckt. Aber aufgepasst: Reaktionszeit bedeutet nicht, dass nach dieser Zeit das System auch wiederhergestellt ist! Stattdessen sollte man mit dem Systemhersteller in den Dialog gehen und sicherstellen, dass die RTOs bei der Wiederherstellung eingehalten werden können.

Hinzukommt, dass man in einem Notfallszenario ja meist Systeme verschiedener Hersteller wiederherstellen muss. D.h. verschiedene Teams von verschiedenen Herstellern müssen sich abstimmen und ihre Abhängigkeiten voneinander beachten!

Zusammenfassung

Wie in kaum einer anderen Disziplin der Informationssicherheit unterscheidet sich die Notfallvorsorge für eine OT Umgebung drastisch von derjenigen einer IT-Umgebung. Bei der Durchführung einer BIA sollte auf die folgenden Aspekte geachtet werden:

· Das „Untragbarkeitsniveau“ ist in der OT oft schwieriger zu bestimmen. Und es sollte auf keinen Fall sofort festgelegt werden, dass „Anlage aus“ gleich „untragbar“ bedeutet.

· Es gibt diejenigen Komponenten, die vor dem Wiederanlauf der Anlage wiederhergestellt sein müssen; und es gibt diejenigen Komponenten, die erst später wiederhergestellt werden können. Dies beeinflusst die RTO massiv.

· Die Abhängigkeitsanalyse von OT-Komponenten fällt oft leichter. Dafür darf man die Abhängigkeiten der Prozesse aber nicht vernachlässigen!

· Die Wiederanlaufreihenfolge sollte modular und flexibel für verschiedenen Szenarien gestaltet werden. Z.B. ist nicht immer eine Wiederherstellung aller Systeme erforderlich.

· Es sollte festgelegt werden, wer die Wiederherstellung welches Systems durchführt. Oft ist man auf die Hilfe von Systemherstellern angewiesen.