Was Hollywood mich über Zero Trust gelehrt hat

F5-Ökosystem | 05. Mai 2022

Sollte ich jemals – in einer alternativen Realität oder einer fantastischen Zukunft – die Gelegenheit haben, die Computersysteme der Sternenflotte zu entwerfen, würde ich auf jeden Fall dafür sorgen, dass die Waffensysteme nicht mit den Subroutinen der Lebenserhaltung verbunden sind. Oder sollte ich der Befehlshaber einer außerirdischen Invasionsstreitmacht sein, die den Auftrag hat, die Erde zu erobern – einen Planeten, der wohlgemerkt von einer völlig anderen Spezies bewohnt wird –, würde ich auf einer biometrischen Authentifizierung statt eines Passcodes oder Tokens bestehen. Und falls schließlich einer meiner Offiziere oder eines meiner Raumschiffe allen Widrigkeiten zum Trotz auf wundersame Weise seinen Entführern „entkommen“ sollte, würde ich natürlich als Erstes überprüfen, ob dabei nicht etwa ein Trojanisches Pferd eingeschleust wurde.

Was hat das also mit Zero Trust zu tun? Wie Sie sich inzwischen wahrscheinlich schon gedacht haben, liebt Hollywood Geschichten, in denen die dramatischen Folgen ausgespielt werden, die entstehen, wenn man auf eine gesunde Portion anfänglichen Misstrauens verzichtet. Und aus meiner Sicht als Cybersicherheitsexperte ist genau diese Haltung – ein gesundes Misstrauen zu bewahren – der Kern dessen, worum es bei Zero Trust wirklich geht.

Warum also konzentriere ich mich ausgerechnet auf Zero Trust? Meine Motivation beruht auf einem Trend bei der heutigen Verwendung des Begriffs „Zero Trust“. Dazu eine weitere Anekdote aus der Filmproduktion, diesmal aus den späten 80er-Jahren: Damals vollzog Hollywood den Übergang von herkömmlichen analogen Technologien zu digitalen Standards für Audio, Video und die Bearbeitung in der Postproduktion. Zu jener Zeit verstanden viele der technisch weniger versierten Mitglieder der Filmbranche nicht, was „digital“ eigentlich bedeutete, und es interessierte sie auch nicht sonderlich. Stattdessen war der Begriff „digital“ für sie praktisch gleichbedeutend mit „erstklassig“. Daher begannen Produzenten und Regisseure – sehr zum Leidwesen meiner technikaffinen Freunde, die mit ihnen zusammenarbeiteten – zu fragen, ob die Beleuchtung oder der Kulissenbau „digital“ sei, obwohl sie eigentlich wissen wollten: „Ist das die bestmögliche Lichtgestaltung beziehungsweise der bestmögliche Kulissenbau?“ Zurück in der Gegenwart höre ich in der CSO-Community allzu oft, wie „Zero Trust“ ganz ähnlich verwendet wird wie „digital“ von Filmproduzenten im Jahr 1990.

Unabhängig davon wurde ich kürzlich mit Simon Sineks „Start With Why“-Modell vertraut gemacht. Dieses Modell half mir – zusammen mit den Erinnerungen daran, wie Hollywood über die Anfänge des „Digitalen“ dachte und wie Filme Geschichten rund um gute wie schlechte Sicherheitspraktiken entwickelten –, einige meiner Gedanken zu Zero Trust auf den Punkt zu bringen. Im Kern von Zero Trust steht die Moral der eingangs erwähnten Hollywood-Handlungsstränge: Wer bei der Konzeption und beim Betrieb eines kritischen Systems auf ein wenig durchdachte Cyberprävention verzichtet, muss später mit umso schwerwiegenderen Sicherheitsverletzungen und schmerzhaften Folgen rechnen. Entsprechend lässt sich Zero Trust auf der zentralen „Warum“-Ebene des Modells als die folgende Reihe von Überzeugungen formulieren:

A. Immer ausdrücklich überprüfen ‚wer‘: Das heißt, den Akteur, der versucht, mit Ihrem System zu interagieren.

B. Standardmäßig nur die mindestens erforderlichen Berechtigungen gewähren: Sobald die Identität festgestellt wurde, gewähren Sie diesem Akteur nur so viele Berechtigungen, wie für die Interaktion mit dem System im Rahmen der jeweiligen Geschäftstransaktion erforderlich sind. Die dafür notwendigen Berechtigungen müssen im Entwurf einzeln aufgeführt sein.

C. Kontinuierlich überwachen und (neu)bewerten: Die Identitätsprüfung und die Berechtigungen sollten nicht statisch und einmalig sein. Stattdessen müssen diese Entscheidungen kontinuierlich überprüft und neu bewertet werden.

D. Und gehen Sie dennoch davon aus, dass Ihr System kompromittiert wurde: Gehen Sie schließlich trotz der Umsetzung der drei oben genannten Punkte davon aus, dass ein versierter Angreifer die Schutzmaßnahmen überwunden hat. Daher muss das System auch berücksichtigen, wie kompromittierte Komponenten oder Identitäten erkannt und isoliert werden können, und eine Strategie zur Eindämmung und/oder Behebung ihrer Auswirkungen auf das System vorsehen.

Einfach ausgedrückt: Vertrauen Sie nicht blind, sondern überprüfen Sie stets. Vertrauen Sie nur so weit wie nötig. Bewerten Sie kontinuierlich. Und gehen Sie nicht davon aus, dass Sie alle Angreifer erkennen werden. Das ist das „Warum“ hinter Zero Trust.

Natürlich ist das „Warum“ nur ein Teil der Geschichte. Das „Wie“ – also die Techniken und Werkzeuge, mit denen die durch das „Warum“ hervorgerufene Denkweise in die Praxis umgesetzt wird – ist eine weitere für Praktiker relevante Perspektive; es ergibt sich als Konsequenz aus den zuvor genannten Überzeugungen. Auch hier werde ich konkret und beziehe mich dabei auf die derzeit verfügbaren Werkzeuge, die heutigen Cybersicherheitsfachleuten zur Verfügung stehen:

Authentifizierung: Jeder Akteur, der mit dem geschützten System interagiert, muss eine bestimmte Identität oder in manchen Fällen eine Kombination von Identitäten nachweisen – etwa eine Identität für den Menschen oder das automatisierte System sowie eine Identität für das Gerät oder die Plattform, auf dem bzw. der sich der Mensch oder das System befindet, und möglicherweise sogar eine Identität für den Browser oder das Tool, über den bzw. das der Zugriff erfolgt. Der Zero-Trust-Ansatz setzt voraus, dass jeder derartige Nachweis auf eine oder mehrere Arten überprüft bzw. „authentifiziert“ wird: durch ein gemeinsames Geheimnis, ein Token oder Zertifikat und in moderneren Systemen zusätzlich durch die Beobachtung und Überprüfung des Verhaltensmusters dieses Akteurs.
Zugriffskontrolle: Sobald die Identität festgestellt wurde, sollte ihr eine Vertrauensstufe zugewiesen werden, die sich in den für diese Identität gewährten Zugriffsrechten widerspiegelt. Die Zugriffskontrollrichtlinie sollte dem Prinzip der geringsten Rechte folgen, wonach nur die minimalen Rechte gewährt werden, die der Akteur benötigt, um seine Rolle innerhalb des Systems zu erfüllen. Ideale Implementierungen der Zugriffskontrolle sollten eine detaillierte Festlegung der gewährten Rechte ermöglichen, zum Beispiel: Rolle <X> ermöglicht den Zugriff auf die APIs <1>, <3> und <4> sowie Lesezugriff auf Objekte der Klassen <Y> und <Z>. Als Best Practice gilt, dass komplexe Zugriffskontrollszenarien für Anwendungsressourcen hinter APIs abstrahiert werden sollten, anstatt direkten Zugriff auf Objekte, Dateien und Netzwerkressourcen zu gewähren.
Transparenz: Kommen wir nun zum Aspekt der „Überwachung“ – einer Voraussetzung für die „kontinuierliche Neubewertung“: Das System muss fortlaufend und in Echtzeit Einblick in das Systemverhalten jedes Akteurs bieten. In diesem Zusammenhang gilt der Grundsatz: „Was nicht beobachtet wurde, ist nicht geschehen.“ Darüber hinaus müssen die erfassten „Telemetriedaten“ nicht nur sichtbar, sondern auch nutzbar sein. Das bedeutet, dass sie in einem Rahmen vorliegen müssen, der den Austausch und die Kontextualisierung der gemeldeten Informationen ermöglicht. So können Daten aus mehreren Quellen sinnvoll zusammengeführt und korreliert werden, was eine robustere und wirksamere Risikobewertung ermöglicht.
Kontextbezogene Analyse mit ML-Unterstützung: Die zuvor beschriebene Sichtbarkeit soll die Umsetzung des Prinzips der „kontinuierlichen Neubewertung“ ermöglichen. In der Praxis erfordert dieser Grundsatz nicht nur Sichtbarkeit, sondern auch Analysen – üblicherweise nahezu in Echtzeit und über mehrere Datenquellen hinweg (wofür das zuvor erwähnte Framework zum einfachen Datenaustausch erforderlich ist). Dabei sind für die kontinuierliche Bewertung häufig KI-gestützte Systeme für maschinelles Lernen erforderlich, die ungewöhnlich agierende Akteure erkennen und so mögliche Kompromittierungen des Systems identifizieren. Schließlich sollte eine leistungsfähige Analyse-Engine differenziertere Antworten als ein einfaches binäres Ja oder Nein liefern können – idealerweise eine Risikobewertung mit einem zugehörigen Konfidenzwert.
Automatisierte risikobewusste Abhilfemaßnahmen: Da außerdem davon ausgegangen wird, dass es einigen hoch entwickelten Angreifern dennoch gelingen wird, in das System einzudringen, muss das System handlungsfähig sein, um solche Aktionen oder Akteure genauer zu überwachen und sie bei Bedarf einzudämmen und/oder zu blockieren. Die Reaktion des Systems – von der bloßen Protokollierung über eine eingehendere Prüfung und das Blockieren der versuchten Aktion bis hin zur Täuschung des mutmaßlichen Angreifers – muss im übergeordneten geschäftlichen Kontext betrachtet werden. Dabei sind die Wahrscheinlichkeit und die Auswirkungen falsch positiver oder falsch negativer Ergebnisse sowie das mit der Maßnahme verbundene Geschäftsrisiko zu berücksichtigen. So könnte das Blockieren des Zugriffs auf einen Produktkatalog nur dann angemessen sein, wenn mit sehr hoher Sicherheit feststeht, dass es sich bei dem Akteur um einen böswilligen Website-Scraper handelt. Bei einer Banktransaktion kann hingegen bereits bei einem geringeren Sicherheitsgrad eine zusätzliche Authentifizierung angebracht sein. Aufgrund der Komplexität und Geschwindigkeit moderner Cyberangriffe muss die operative Abhilfemaßnahme zudem automatisierbar sein, wobei die vom Menschen festgelegte Richtlinie in Form absichtsbasierter Ziele beschrieben wird.

Der letzte Aspekt des „Warum, Wie, Was“-Rahmens ist das „Was“ – nämlich, dass sich die Ziele mithilfe der oben genannten Werkzeuge und Techniken erreichen und die verschiedenen Angriffsklassen verhindern oder eindämmen lassen. Eine vollständige Taxonomie sämtlicher Cyberangriffe wird Gegenstand eines künftigen Artikels sein. Als kleiner Ausblick sei jedoch erwähnt, dass das hier beschriebene „Warum“ und „Wie“ das gesamte Spektrum ausgefeilter „Advanced Threats“ abdeckt. So kann der Zero-Trust-Ansatz beispielsweise Ransomware-Bedrohungen begegnen, selbst wenn diese von „vertrauenswürdigen“ Softwarekomponenten ausgehen (sogenannte „Supply-Chain-Angriffe“). Konkret sollte das in der Zugriffskontrollrichtlinie verankerte Prinzip der geringsten Rechte angewendet werden, um Lese- und Schreibberechtigungen für Dateien auf diejenigen Akteure zu beschränken, die diese Rechte tatsächlich benötigen. Dadurch wird die Verschlüsselung von Dateiressourcen verhindert. Sollte darüber hinaus ein Akteur – etwa eine vorhandene Softwarekomponente mit Schreibberechtigungen für Dateien – kompromittiert werden (über den zuvor erwähnten Supply-Chain-Angriffsvektor) und versuchen, zahlreiche Dateien in hoher Geschwindigkeit zu verschlüsseln, sollten eine kontinuierliche Neubewertung und Analyse das ungewöhnliche Verhalten rasch erkennen, indem der Umfang der aufgerufenen Dateien und die Zugriffsgeschwindigkeit erfasst werden. In Verbindung mit automatisierten Gegenmaßnahmen kann diese Erkennung dazu dienen, solche Aktivitäten schnell zu blockieren.

Kehren wir also zu den alternativen Welten zurück, mit denen ich begonnen habe ... Wenn alle Computersubsysteme der Sternenflotte nach dem Prinzip der geringsten Rechte arbeiten würden, dürfte die API zum Abfeuern von Photonentorpedos nicht vom Schwerkraftkontrollsystem aufgerufen werden können. Und die Steuerung des außerirdischen Mutterschiffs würde nicht nur eine biometrische MFA durchführen; die Sicherheitskontrollen des Mutterschiffs würden zudem davon ausgehen, dass es zu Sicherheitsverletzungen kommen wird – und daher fortlaufend überwachen und neu bewerten, die Anomalie einer Kampfdrohne erkennen, die durch das Schiff fliegt, und die Bedrohung abwehren, falls diese ungewöhnliche Drohne auf den Reaktorkern zusteuert. Dieses kleine, aber entscheidende Quäntchen Prävention würde eine Menge daraus resultierender Dramatik verhindern – schlecht für Hollywood, aber gut für Cybersicherheitsfachleute.

Weitere Informationen über das Framework, das die umfassenden Konzepte rund um Zero Trust im Kontext der bestehenden Geschäftslandschaft und der Sicherheitsmentalität beschreibt, die Führungskräfte im Anwendungsbereich verinnerlichen sollten, finden Sie in unserem Whitepaper „Zero-Trust-Sicherheit: Warum Zero Trust wichtig ist (und zwar nicht nur für den Zugriff)“.