Mit Pragmatismus zu Cyber-Resilienz

Das etablierte NIST-Framework bietet eine Grundlage, an der sich der IKT-Minimalstandard des Bundesamts für wirtschaftliche Landesversorgung, das Handbuch «Grundschutz für Operational Technology in der Stromversorgung» des VSE und viele andere Standards orientieren. Das Framework definiert fünf Handlungsfelder: Identify, Protect, Detect, Respond und Recover. Im Kern geht es primär darum, sicherzustellen, dass ein potenzieller Angriff möglichst geringe Erfolgschancen hat. Vorzubeugen ist dabei immer effektiver, als zu reagieren. Der Fokus liegt daher zu Beginn auf der Schaffung von Transparenz («Identify») und der geordneten Prävention («Prevent»). Detektion («Detect») und Reaktion («React») sind ergänzend und erst ab einem gewissen Reifegrad richtig effektiv. Diese Prioritäten werden offensichtlich, wenn man sich den Ablauf eines Angriffs anschaut.

Wie läuft ein Angriff ab?

Hat ein Angreifer – egal ob durch Phishing, ungepatchte Systeme, Zero-Day-Sicherheitslücken oder mit dem Brecheisen an der Trafostation – Zutritt zum Netzwerk erlangt, verschafft er sich als Erstes einen Überblick. Auf der Suche nach ungeschützten Geräten und attraktiven Zielen bewegt er sich vorsichtig und unbemerkt im Netzwerk. Systembetreiber benötigen durchschnittlich 280 Tage, um eine Lücke zu lokalisieren und zu schliessen. Das heisst, dass sich ein Angreifer zu diesem Zeitpunkt schon seit über sechs Monaten im Netzwerk aufhalten könnte. Er hat Zeit, kann den Angriff in Ruhe vorbereiten und dabei sehr vorsichtig vorgehen, sodass seine Kommunikation nur schwer durch Systeme detektiert werden kann.

Wenn er dann zuschlägt, dauert es meist nur wenige Minuten. Wer also sein eigenes Netzwerk und die Assets darin nicht genau kennt («Identify») und geregelte Prävention («Prevent») aufgebaut hat, ermöglicht Angreifern während langer Zeit, sich frei im Netzwerk zu bewegen, diese wertvollen Assets zu finden und auf sie zuzugreifen. Ein Angreifer gelangt zum Beispiel über die IT in die OT und sucht dort nach vulnerablen Systemen. Selbst wenn der eigentliche Angriff – sobald er gestartet wird – detektiert wird, sind die Erfolgsaussichten einer hektischen, reaktiven Brandbekämpfung («Detect» und «React») ohne vorgelagerte Schritte begrenzt.

Erster Schritt: Visibilität schaffen («Identify»)

Man kann nicht schützen, was man nicht kennt. Es gilt also zuerst, Daten und Wissen über die eigene Infrastruktur aufzubauen. Wie sieht das Netzwerk aus, und welche Systeme leben darin? Welches sind die Angriffsvektoren und Risiken? Eine saubere Dokumentation des Netzwerks wird in allen gängigen Standards (BSI, ISO etc.) gefordert und ist die Basis für weitergehende Analysen und Präventionsmassnahmen mit klaren Prioritäten. Manuelle Dokumentationen und Listen sind jedoch sehr aufwendig, und es bleibt immer unklar, was davon (noch) stimmt. Glücklicherweise lässt sich das heutzutage automatisieren. Gerade beim Netzausbau im Energiebereich mit der laufenden Anbindung von Trafostationen ist eine automatisierte Dokumentation notwendig. Die gewonnene Visibilität kann zudem laufend ausgebaut und mit Daten (Log-Daten, GIS-Daten usw.) angereichert werden. So erhält man nach und nach eine ganzheitliche Sicht des Netzwerks, was Betreibern erlaubt, ihr Denken in technische und organisatorische Silos aufzubrechen.

Zweiter Schritt: Sichere Architektur aufbauen («Prevent»)

Die gewonnene Visibilität bietet die Grundlage, um den präventiven Schutz aufzubauen: Wie wird das Netzwerk sicher aufgebaut, und wie können die Systeme darin geschützt werden? Sobald sich ein Betreiber auf Basis der Visibilität vertieft mit der eigenen Infrastruktur auseinandersetzt, entdeckt er vulnerable Geräte und setzt sich mit konkreten Angriffswegen und möglichen Schutzmechanismen auseinander.

Die ganzheitliche Sicht erlaubt, sich dem Thema infrastrukturzentriert (Schwachstellen, Architektur usw.) statt bedrohungszentriert zu nähern. Die Arbeit wird dadurch konkreter und ist auf die spezifische Netzwerklandschaft statt auf generische Bedrohungsmuster fokussiert. Die meisten Attacken sind ohnehin nicht sehr komplex – weil das schlicht nicht nötig ist. Angreifer suchen einfache Schwachstellen, Geräte mit alter Software oder Legacy-Betriebssystemen (Windows 7), Anlagen, die am Internet hängen, sowie flache Netzwerke ohne Segmentierung.

Genau diese Themen müssen zuerst angegangen werden. «Eine sichere und robuste ICS-Netzwerkarchitektur stellt einen der wichtigsten Grundsätze für einen erfolgreichen Schutz gegen Angriffe dar», steht im VSE Handbuch «Grundschutz für Operational Technology in der Stromversorgung». Die Netzwerkarchitektur ist insbesondere im OT-Bereich historisch gewachsen. Sie folgt zum Teil geografischen Gegebenheiten und es gibt Aussenstellen, die speziell angebunden sind.

Was aber ist eine sichere und robuste Architektur? Die Basis ist eine saubere Netzwerksegmentierung, das heisst die Unterteilung des Netzwerks in Sicherheitszonen und -segmente. So kann die Kommunikation von und zu diesen Teilnetzen geregelt werden, und es wird verhindert, dass sich Angreifer frei im Netzwerk bewegen können, selbst wenn sie an einer Stelle Zutritt erlangt haben. Für die Netzwerksegmentierung werden die einzelnen Systeme im Netzwerk und die Kommunikation zwischen diesen Systemen beziehungsweise den Sicherheitszonen und -segmenten, in denen sie sich befinden, genauer betrachtet. In diesem Zuge gilt es auch, einen klaren Umgang mit ungepatchten und vulnerablen Systemen zu entwickeln (Mikrosegmentierung und Patch-Management) sowie Fernzugriffe (zum Beispiel durch Lieferanten) zu vereinheitlichen und abzusichern.

Man kann die Aufgaben nicht umgehen, aber einfacher machen

Diese Themen sind anspruchsvoll, weil man sie nicht von heute auf morgen mit einem neuen Tool lösen kann und weil verschiedene Stakeholder am Tisch sitzen müssen. Viele Lösungen implizieren zwar, dass die notwendigen Schritte mittels «Fabric», «Software defined Networking» oder einem anderen Schlagwort übersprungen werden können. In der Realität müssen sich Betreiber aber – unabhängig davon, welche Security-Lösungen sie sich kaufen – damit auseinandersetzen, was sie wie schützen können und wie die Netzwerkarchitektur sicher aufgebaut werden kann. Das erledigt kein System.

Doch wie könnte ein pragmatischer Ansatz lauten? Wie kommt man in einem sinnvollen Zeitrahmen und mit realistischen personellen Ressourcen von A nach B? Wo kann die Veränderung vielleicht sogar genutzt werden, um Ressourcen freizusetzen? Hier hilft es, mit Templates und konzeptionellen Vorlagen zu arbeiten. Für Organisationen mit OT liefert hierzu zum Beispiel das Purdue-Modell Orientierung. Im Zuge der Entwicklung einer neuen Architektur kann auch die Netzwerk- und Security-Automatisierung vorangetrieben werden. Mit einer guten Automatisierungsbasis lassen sich bei der Umsetzung und beim späteren Betrieb beträchtliche personelle Ressourcen einsparen. Gleichzeitig können konkrete Alltagsprobleme wie versehentliche Fehlkonfigurationen, nicht autorisierte Konfigurationsänderungen usw. behoben werden, was den Betrieb langfristig entlastet. Insgesamt ist es gut möglich, zunächst übergeordnete Verbesserungen einzuführen und dann granularer zu werden. So wird die Organisation nicht überlastet und der Betreiber kann Erfahrungen sammeln und lernen.

Mehr Technologie vs. organisatorischer Wandel

Die beschriebenen Aspekte zeigen, dass Resilienz ein organisationaler Zustand und keine Sammlung von technischen Features ist. Es braucht technische Anpassungen, doch diese sind eine Konsequenz der Veränderung und nicht deren Ursprung. Zudem benötigen zusätzliche Tools auch zusätzliche Expertinnen und Experten, um sie sinnvoll zu nutzen und zu bedienen. Angesichts des akuten Fachkräftemangels im Security- und Infrastrukturbereich ist auch diese Anforderung nicht ohne Weiteres lösbar. Ein externes Security Operations Center (SOC) stellt hier eine sinnvolle Ergänzung, jedoch keinen Ersatz dar. Damit das Geld für ein SOC auch sinnvoll eingesetzt wird, braucht die eigene Organisation einen gewissen Reifegrad.

Sinnvoller ist, das Mindset und die Arbeitsweise mehr in Richtung kontinuierliche Verbesserung, Vereinfachung und Automatisierung weiterzuentwickeln. Die datenbasierte, ganzheitliche Sicht ermöglicht, dass IT-, OT- und Security-Verantwortliche gemeinsam am Tisch sitzen und die Themen diskutieren. So werden nach und nach die konzeptionellen Grundlagen geschaffen, und es wird greifbarer und einfacher, wie man von A nach B kommt. Dieses Vorgehen ist möglicherweise ungewohnt, weil nicht nur technische, sondern auch organisatorische Silos aufgebrochen werden. Gelingt es, alle Mitarbeiterinnen und Mitarbeiter auf diesen neuen Weg mitzunehmen, kann eine starke positive Dynamik daraus entstehen.

Verlockendes Schlangenöl vs. echte Prävention

Man kann also viel Geld für neue Hard- und Software ausgeben – zum Beispiel, um hypothetische Bedrohungen zu identifizieren und Angriffe zu erkennen, die vielleicht gar nie stattfinden. Dann hat man aber am Ende immer noch vulnerable Systeme und eine unzureichend sichere Gesamtarchitektur. Die Schaffung von Visibilität und präventive Veränderungen an der Architektur erfordern demgegenüber personelle Ressourcen, die ohnehin schon knapp sind. Doch mit diesen Massnahmen wird die Sicherheit effektiv und nicht nur hypothetisch erhöht. Die Konsequenz sollte deshalb sein, den Verlockungen, sich von diesem Aufwand freizukaufen, zu widerstehen und stattdessen vorsichtig zu planen, zu priorisieren und sich sehr genau zu überlegen, wie dieser Aufwand als Chance genutzt werden kann. Wird Prävention mit Vereinfachung, Automatisierung und organisatorischen Veränderungen verbunden, entstehen viele positive Nebeneffekte, welche die Teams entlasten.