Betrachtung von Techniken und Technologien zur Einführung des Zero-Trust-Ansatzes

Ausgehend von dem „Warum“ – den Leitprinzipien¹ des Zero-Trust-Ansatzes – geht es nun um das „Wie“ – die Techniken und Technologien, die zur Umsetzung dieser Prinzipien eingesetzt werden.

Im weitesten Sinne können Zero-Trust-Prinzipien auf den gesamten Lebenszyklus der Anwendungsentwicklung angewendet werden, einschließlich des Systemdesigns, der verwendeten Hardware-Plattformen und der Beschaffungsverfahren.² In diesem Beitrag werden jedoch die operativen Aspekte der Implementierung des Zero-Trust-Konzepts zum Schutz von Anwendungen und Daten während der Laufzeit erörtert.

Allgemein formuliert, werden bei der Zero-Trust-Sicherheit Technologien eingesetzt, mit denen eines von drei verschiedenen Zielen erreicht werden soll:

1. Durchsetzung von Transaktionsbeschränkungen: Wer kann was gegenüber wem unternehmen?
2. Schaffung eines Lagebewusstseins beim menschlichen Systembediener
3. Durchführung fortschrittlicherer Risikominderungs-/-beseitigungsmaßnahmen anhand von durch maschinelles Lernen (ML) unterstützten Verdachtsindikatoren und des Risiko-Nutzen-Profils der betreffenden Transaktion(en)

Die folgende Grafik zeigt das allgemeine Transaktionsmodell der Zero-Trust-Sicherheit, wobei in den folgenden Abschnitten auf die einzelnen Technologiekategorien näher eingegangen wird.

Die ersten beiden Technologien – Authentifizierung und Zugriffskontrolle – sind eng miteinander verbunden und werden direkt durch die Grundsätze der „expliziten Überprüfung“ und des „Least Privilege“-Ansatzes motiviert, da diese Technologien den Kern der Durchsetzung des Prinzips „Wer kann was unternehmen“ bilden. Anspruchsvollere Methoden der Authentifizierungsumsetzung setzen auf die Beobachtung des kontinuierlichen Verhaltens eines Akteurs und tragen dem Gedanken der „kontinuierlichen Bewertung“ Rechnung. 

Bei Authentifizierungstechnologien geht es darum, Vertrauen in eine bestätigte Identität zu schaffen: Wer ist an einer Transaktion aktiv beteiligt. Der Authentifizierungsprozess besteht aus drei Komponenten: 

1. Es liegt eine Bestätigung bzw. Behauptung des Akteurs vor, in der seine Identität angegeben wird.
2. Es liegen ein paar in der Regel vom Akteur zur Verfügung gestellte Daten vor, die die Richtigkeit der Bestätigung belegen.
3. Das System fällt ein Urteil bzw. eine Entscheidung über die Wahrscheinlichkeit, dass die Bestätigung der Wahrheit entspricht und der Akteur der ist, der er vorgibt zu sein. In der nachstehenden Grafik sind die verschiedenen Aspekte der Authentifizierung und die jeweiligen Reifegradmodelle dargestellt, und es folgt eine eingehende Erörterung der einzelnen Aspekte. 

Die einfachste Form der Bestätigung wird oft als „Benutzer“ bezeichnet – ein Mensch oder ein im Namen eines Menschen handelnder Vertreter, der eine Transaktion durchführen möchte. Da im Falle des Zero-Trust-Konzepts innerhalb einer Anwendung ein Akteur jedoch auch eine Workload sein kann (z. B. ein Prozess, ein Dienst oder ein Container), sollte das generalisierte Identitätskonzept auch solche Akteure umfassen. In anderen Fällen umfasst der Begriff Wer nicht nur einen Menschen oder eine Workload, sondern zusätzliche Überlegungen oder Dimensionen der Identität. Aus dieser Perspektive könnten zusätzliche Dimensionen der Identität das Gerät oder die Plattform des Benutzers bzw. der Workload oder das für die Interaktion verwendete Ökosystem bzw. den Standort des Vertreters umfassen. So kann beispielsweise die Benutzerin „Alice“ einen PC unter der Bezeichnung „ABC-0001“ nutzen und eine bestimmte, mit Fingerabdrücken versehene Browserinstanz verwenden, die von der IPv4-Adresse 10.11.12.13 stammt.

Manche Systeme erlauben es nicht authentifizierten Benutzern, die manchmal als „Gäste“ oder „anonyme“ Benutzer bezeichnet werden, eine limitierte Anzahl von Transaktionen durchzuführen. Für solche Systeme sind die zusätzlichen Schritte des Identitätsnachweises und der Urteilsfällung durch das System nicht relevant. Für eine bestimmte bestätigte Identität werden jedoch in der Regel folgende Methoden zur Untermauerung der Bestätigung herangezogen:

• Kenntnis eines gemeinsamen geheimen Schlüssels, z. B. eines Kennworts
• Eine Art Berechtigungsnachweis von einer vertrauenswürdigen dritten Partei, wie z. B. ein signiertes Zertifikat
• Automatische Abfrage (z. B. Gerätefingerabdruck) oder aktive Abfrage (z. B. Captcha-Abfrage) der Identität des Benutzers, der Workload oder der Plattform
• Metadaten, die sich auf den Akteur beziehen, wie z. B. die Standortdaten, die IP-Reputation oder die Uhrzeit des Zugriffs
• Verhaltensanalyse, z. B. passive biometrische Analyse oder Workflow-Muster der Anwendungsinteraktion

Wenn ein hohes Maß an Vertrauen erforderlich ist, werden oft mehrere Methoden eingesetzt. Dies kommt im Google BeyondCorp-Modell³ zum Ausdruck, das eine Multi-Faktor-Authentifizierung (MFA) verlangt, bevor es höherwertige Transaktionen zulässt. Anspruchsvolle Authentifizierungslösungen ordnen jeder Identität ein bestimmtes Maß an „Vertrauen“ zu und legen für jede Art von Transaktion einen Mindestvertrauenswert fest, der sich nach dem Wert und dem Risiko der Transaktion richtet.

Schließlich ist zu beachten, dass es sich bei einigen dieser Methoden nicht um statische, einmalige Aktionen handelt, sondern dass sie nach dem Prinzip der „kontinuierlichen Bewertung“ fortlaufend durchgeführt werden können und sollten. In solchen Fällen kann sich der der Identitätsbestätigung zugewiesene Vertrauenswert im Laufe der Zeit nach oben oder unten hin verändern. So kann sich beispielsweise der Fingerabdruck des Browsers oder die IP-Adresse innerhalb einer einzigen Benutzersitzung ändern, was als verdächtig und vertrauensmindernd angesehen werden könnte. Werden in einer Sitzung weitere Daten zum Verhalten des Akteurs gesammelt, kann der Vertrauenswert steigen oder sinken, je nachdem, wie das aktuelle Verhalten im Vergleich zu früheren Beobachtungen ausfällt.

Bei fortschrittlichen Systemen kann die dynamische Authentifizierung mit der Zugriffskontrolle Hand in Hand gehen. Auf der ersten Ebene dieser Interaktion kann die Zugriffskontrollrichtlinie für verschiedene Transaktionsklassen einen Mindestvertrauenswert festlegen, wie bereits erwähnt. Auf der nächsten Ebene der Interaktion kann das Zugriffskontrollsubsystem dem Authentifizierungssubsystem eine Rückmeldung geben und in der Regel eine zusätzliche Authentifizierung verlangen, um den Vertrauenswert auf den Mindestwert zu erhöhen.

Nachdem mit Hilfe von Authentifizierungsmethoden festgestellt wurde, wer an einer Transaktion beteiligt ist, stellen sich die nächsten Fragen: Was darf dieser Akteur unternehmen? Und wem gegenüber? Dies ist der Aufgabenbereich der Zugriffskontrolltechnologien.

Stellen Sie sich als Analogie zur physischen Sicherheit vor, Sie wollten einen Militärstützpunkt besuchen. Nachdem die Wachen festgestellt haben, ob Sie ein Zivilist, Politiker oder Soldat sind, würden sie anhand dieser Feststellung entscheiden, welche Gebäude Sie betreten dürfen und ob Sie eine Kamera in die jeweiligen Gebäude mitnehmen dürfen. Die Richtlinien für diese Entscheidungen können sehr grob gehalten sein und für alle Gebäude gelten (z. B. „Politiker dürfen jedes Gebäude betreten“) oder sie können feiner unterteilt sein (z. B. „Politiker dürfen die Gebäude und betreten, dürfen jedoch nur in Gebäude eine Kamera mitnehmen“).

Auf den Cybersicherheitskontext übertragen, sollten die Zugriffskontrollmethoden das Zero-Trust-Prinzip der geringsten Rechte („Least Privilege“-Prinzip) verkörpern. Mit anderen Worten: Die optimale Zugriffskontrollrichtlinie würde nur genau jene Rechte zubilligen, die der Akteur benötigt, und alle anderen Rechte verweigern. Darüber hinaus würde sie idealerweise ein bestimmtes Mindestmaß an Vertrauen in die Identität des Akteurs voraussetzen, wobei der Vertrauensschwellenwert anhand der Granularität des jeweils zugebilligten Rechts festgelegt wird.

Der Wert einer Zugriffskontrolllösung kann somit danach beurteilt werden, wie sehr sie diesen Idealen entspricht. Konkret muss eine Zero-Trust-Sicherheitslösung eine Zugriffskontrolle beinhalten, und sie sollte die Zugriffskontrolltechnologie anhand der unten dargestellten und nachfolgend beschriebenen Dimensionen evaluieren. 

1. Wie fein abgestuft sind die Zugriffskontrollrechte?

1. Was ist die Granularität der Aktion – das Was der Transaktion? Ist sie:

1. Binär: Es sind „alle“ oder „keine“ Transaktionen erlaubt. In Analogie zur Militärbasis würde dies bedeuten: „Alle Soldaten können jedes Gebäude betreten und alles tun, was sie möchten“ und „Zivilisten können kein Gebäude betreten.“
2. Grob: Gilt granular für den API-Endpunkt oder den „Typ“ der Transaktion (z. B. Datei-E/A, Netzwerkkommunikation und Prozesssteuerung). In unserem Beispiel würde dies eine Abstufung der erlaubten Aktion ermöglichen, z. B. „Politiker dürfen Gebäude betreten, aber keine Fotos machen“. 
3. Fein: Auf der Ebene der Sub-API (d. h. abhängig von den Parametern oder der Version der API) oder des „Untertyps“ der Transaktion (z. B. nur Lesezugriff für Datei-E/A oder nur TCP-Empfang). Um unsere Analogie noch einmal aufzugreifen, würde dies detailliertere Kontrollen ermöglichen, z. B. „Zivilisten dürfen Gebäude nur in Begleitung eines Soldaten betreten“. 

2. Ist bezüglich des Ziels der Aktion – des Gegenüber wem der Transaktion – eine Granularität gegeben? Ist sie:

1. Nicht zielgerichtet granular: Die Zugriffskontrollrichtlinie berücksichtigt nicht das Ziel der Aktion. In unserem Beispiel würde dieser Ansatz der Granularität entsprechen, den Zutritt zu einigen Gebäuden zu gestatten, zu anderen jedoch nicht – Gebäude sind die Zielobjekte der Aktion „Betreten“.
2. Zielgerichtet granular, auf Infrastrukturebene: Die Zugriffskontrollrichtlinie kann das Ziel der Aktion enthalten, verwendet aber eine infrastrukturspezifische Markierung/Kennzeichnung, z. B. die IP-Adresse, den DNS-Namen oder den Kubernetes-Containernamen (K8S) für das Ziel. Auf diese Weise kann die Richtlinie gebäudegranular sein, und doch kann jede Militärbasis eine andere Namenskonvention für Gebäude anwenden.
3. Zielgerichtet granular, identitätsorientiert: Die Zugriffskontrollrichtlinie kann das Ziel der Aktion beinhalten, wobei das Ziel durch denselben Identitäts-Namespace (z. B. SPIFFE) identifiziert wird, der für den Akteur (das „Wer“) verwendet wird. Der Vorteil gegenüber dem früheren Ansatz besteht darin, dass hier alle Militärbasen ein einheitliches Schema zur Identifizierung von Gebäuden heranziehen, was die Übertragbarkeit der Richtlinie erleichtert.

2. Wie geht die Zugriffskontrolllösung mit dem Konzept der Risikoabstufung von Aktionen um?

1. Nicht risikobewusst: Die Zugriffskontrolllösung behandelt bei der Entscheidung, ob eine Aktion erlaubt oder verboten ist, alle Zugriffskontrollrechte gleich.
2. Risikomanagement über MFA: Die Zugriffskontrolllösung steuert das Risiko, indem sie es ermöglicht, in der Richtlinie festzulegen, dass für einige zugelassene Transaktionen dennoch eine Multi-Faktor-Authentifizierung erforderlich ist, und zwar nach Maßgabe des an der Transaktion beteiligten Akteurs (wer), der Aktion (was) oder des Ziels (gegenüber wem).
3. Risikomanagement anhand des Vertrauenswerts: Die Zugriffskontrolllösung steuert das Risiko, indem sie die Möglichkeit bietet, in der Richtlinie festzulegen, dass für eine Transaktion ein Mindestmaß an Vertrauen in die Authentizität des Akteurs erforderlich ist, basierend auf der Aktion (dem Was) und dem Ziel (dem Gegenüber wem) der Transaktion. Die MFA kann das Vertrauen erhöhen, obwohl auch andere Mittel eingesetzt werden können. In anderen Fällen kann die Transaktion überhaupt nicht erlaubt werden, wenn sie einen hohen Wert hat und an der Authentizität des Akteurs berechtigte Zweifel bestehen.

Nach dem Prinzip der „kontinuierlichen Bewertung (und Neubewertung)“ sollte sich das Vertrauen in die Authentizität des Akteurs im Laufe der Zeit anpassen. Bei einer einfachen Lösung könnte es sich einfach um eine Zeitüberschreitung handeln; bei komplexeren Systemen könnte sich der Vertrauenswert aufgrund von Beobachtungen des Akteurverhaltens im Laufe der Zeit ändern.

Wenn Authentifizierung und Zugriffskontrolle eine Umsetzung des Grundsatzes „immer überprüfen“ und des „Least Privilege“-Prinzips sind, dann sind Transparenz und kontextbezogene Analyse die Grundlage für die Prinzipien „kontinuierliche Bewertung“ und „Annahme einer Sicherheitsverletzung“.

Transparenz ist die notwendige Vorstufe zur Analyse – ein System kann nicht abwehren, was es nicht erkennt. Daher verhält sich die Wirksamkeit der Zero-Trust-Sicherheitslösung direkt proportional zur Tiefe und Breite der Telemetriedaten, die aus dem Systembetrieb und dem externen Kontext gewonnen werden können. Eine moderne transparenzorientierte Infrastruktur ist jedoch in der Lage, viel mehr potenziell nützliche Daten, Metadaten und Kontexte zu liefern, als ein Mensch ohne Hilfe zeitnah verarbeiten kann. Aufgrund des Wunsches nach mehr Daten und der Fähigkeit, diese Daten schneller in Erkenntnisse umzuwandeln, ist eine maschinelle Unterstützung für menschliche Bediener eine wichtige Voraussetzung.

Diese Unterstützung erfolgt in der Regel durch automatisierte Algorithmen, die von der regelbasierten Analyse über statistische Methoden bis hin zu hochentwickelten Algorithmen für maschinelles Lernen reichen. Diese Algorithmen sind dafür verantwortlich, den Schwall der Rohdaten in ein verwertbares und operationalisiertes Lagebewusstsein zu übersetzen, das von menschlichen Bedienern zur Bewertung und, falls erforderlich, zur Abhilfe genutzt werden kann. Aus diesem Grund geht die ML-gestützte Analyse Hand in Hand mit der Transparenz.

Die generalisierte Pipeline von den Rohdaten (Transparenz) zu den Maßnahmen (Abhilfe) ist unten dargestellt: 

Transparenz ist die Umsetzung – das „Wie“ – des Zero-Trust-Prinzips der „kontinuierlichen Bewertung“. Sie umfasst eine Bestandsaufnahme der verfügbaren Dateneingaben (Katalogisieren) sowie die Speicherung von Echtzeit-Telemetriedaten und historischen Daten (Sammeln).

Der Reifegrad einer Zero-Trust-Transparenz-Implementierung hängt von vier Faktoren ab: 

1. Latenzzeit: Wie nah kommen die Daten an Echtzeit-Daten heran?

Die Latenzzeit ist eine Untergrenze dafür, wie schnell auf eine potenzielle Bedrohung reagiert werden kann. Die Latenzzeit einer Zero-Trust-Lösung sollte in Sekunden oder weniger gemessen werden. Andernfalls ist es sehr wahrscheinlich, dass jede noch so genaue Analyse zu spät kommt, um die Auswirkungen des Angriffs, z. B. eine Datenexfiltration/Verschlüsselung oder eine Nichtverfügbarkeit infolge einer Ressourcenerschöpfung, verhindern zu können. Komplexere Systeme können sowohl synchrone als auch asynchrone Abwehrmaßnahmen zulassen. Eine synchrone Abwehr würde den Abschluss der Transaktion bis zur Herstellung einer vollständigen Transparenz und dem Abschluss der Analyse verhindern. Da die synchrone Abwehr aller Wahrscheinlichkeit nach zu einer Verzögerung der Transaktion führt, wäre diese Vorgehensweise vor allem anomalen oder riskanten Transaktionen vorbehalten, während alle anderen Transaktionen Telemetriedaten senden und asynchron analysiert werden können.

2. Verwertbarkeit: Wie leicht können die Daten verwertet werden?
   

Dieses Problem ist von Bedeutung, wenn Daten aus verschiedenen Quellen stammen oder von verschiedenen Arten von Datensensoren herrühren, was häufig der Fall ist. Dieser Faktor lässt sich in der Regel in zwei Teilaspekte unterteilen. 

• Auf syntaktischer Ebene, wie die Daten extrahiert und dargestellt werden können. Wenn beispielsweise eine Quell-IP-Reputation als Textfeld (z. B. „bösartig“, „verdächtig“, „unbekannt“ usw.) in einer Syslog-Nachricht aus einer Quelle und als numerisches, binär verschlüsseltes Feld in einer Datendatei aus einer anderen Quelle eingeht, sollte eine kanonische Darstellung ermittelt werden. Um die eingehenden Daten in diese Darstellung zu extrahieren und umzuwandeln, ist eine Datenserialisierung erforderlich. 

• Auf semantischer Ebene können sich verschiedene Quellen nicht nur in ihrer Syntax und ihrem Transport, sondern auch in der Semantik unterscheiden. Um noch einmal das Beispiel der IP-Reputation aufzugreifen: Ein Anbieter kann einen Bedrohungswert als Zahl angeben, während ein anderer Anbieter die IP in Kategorien wie „TOR-Knoten“, „DNS-Steuerung“ oder „Phishing“ einordnet. Die Transparenzlösung muss auch einen Mechanismus zur Normalisierung der eingehenden Daten in eine einheitliche Syntax bieten. 

3. Vollständigkeit: Wie umfassend und tiefgreifend sind die verfügbaren Daten?

Ein wichtiger Vorteil einer hochwertigen Transparenzlösung ist die Fähigkeit, verdächtige Aktivitäten als Indikator für eine mögliche Sicherheitsverletzung zu erkennen. Damit dies effektiv möglich ist, muss die Lösung Telemetriedaten von allen relevanten „Schichten“ der Anwendungsbereitstellung erhalten: natürlich der Anwendung selbst, aber auch der Anwendungsinfrastruktur, der Netzwerkinfrastruktur, allen Diensten, die auf die Anwendung angewendet oder von ihr genutzt werden, und sogar den Ereignissen auf dem Client-Gerät. Die Identifizierung eines Benutzers, der sich von einem neuen, noch unbekannten Gerät aus anmeldet, mag für sich genommen schon etwas verdächtig sein, doch in Kombination mit Netzwerkinformationen (z. B. GeoIP-Mapping aus einem fremden Land) steigt der Verdacht noch weiter an. Dieser Verdacht äußert sich in einem niedrigeren Vertrauen in die Identität des Benutzers. Im Zusammenhang mit einer Zero-Trust-Sicherheitsrichtlinie bedeutet dies, dass die Zugriffskontrolllösung, wenn der Akteur versucht, eine hochwertige Transaktion durchzuführen (z. B. eine Überweisung auf ein ausländisches Konto), auf der Grundlage des geringen Vertrauenswerts diese Transaktion blockieren kann.

In Bezug auf den Zero-Trust-Ansatz gilt: Je tiefgreifender und vollständiger die Transparenzlösung ist, desto effektiver kann das System Transaktionen angemessen einschränken und Sicherheitsverletzungen aufdecken.

4. Governance: Wie gut werden die gesetzlichen und lizenzrechtlichen Anforderungen an die Datennutzung unterstützt?

Und schließlich muss jede Datenerfassung den gesetzlichen und lizenzrechtlichen Anforderungen an die Sicherheit, Aufbewahrung und Verwendung von Daten entsprechen. Eine solide Transparenzlösung muss daher all diese Anforderungen erfüllen. Bei einer Zero-Trust-Transparenzlösung sind die Datennutzungsvorgaben, die sich aus der Governance ergeben, zu berücksichtigen. Werden beispielsweise IP-Adressdaten als personenbezogene Daten angesehen, so müssen die Verwendung und die langfristige Aufbewahrung von IP-Adressen für Analysen der zulässigen Verwendung der IP-Adressen entsprechen. 

Neben der Transparenz sind für die Umsetzung der „kontinuierlichen Bewertung“ zur Durchführung einer aussagekräftigen Bewertung auch Analysetools erforderlich. Die Bewertung muss also von einer Zero-Trust-Lösung operationalisiert werden können.

Eine Überlegung bei der Analyse ist der Rahmen und Umfang der Eingabedaten. Die Eingaben für die Analysealgorithmen können sich auf einen einzigen Datenstrom aus einer einzigen Quelle beschränken oder mehrere Datenströme aus verschiedenen Datenquellen und allen Schichten der Infrastruktur und Anwendung umfassen. 

• Die grundlegendste Kontextualisierung erfolgt im Rahmen eines einzelnen „Typs“ oder „Stroms“ von Daten (z. B. eines Strom von „Benutzeranmeldeinformationen mit Zeit und Quell-IP-Adresse“), in der Regel mit historischem Kontext und/oder Daten zu mehreren Benutzern. Diese Analyse kann zu einigen grundlegenden Erkenntnissen führen, wie z. B. „Benutzer hat sich nie zu dieser Tageszeit angemeldet“ oder „Benutzer scheint sich immer unmittelbar nach Benutzer anzumelden“. Ersteres kann das Vertrauen in die Identität mindern, letzteres kann ein Hinweis auf ein übergeordnetes, vielleicht bösartiges Muster sein.
• Eine weiterreichende Kontextualisierung berücksichtigt den zeitlichen und instanzenübergreifenden Rahmen nicht nur für einen einzelnen „Typ“ von Daten, sondern setzt die verschiedenen „Typen“ oder „Ströme“ von Daten auch in einen zeitlichen Zusammenhang. Ein Beispiel wäre es, die Benutzeranmeldedaten mit bestimmten Aktionen auf Anwendungsebene (z. B. Geldtransfer oder Aktualisierung von E-Mail-Kontakten) oder Netzwerkebene (z. B. eine IP-basierte Geolokalisierung) in Beziehung zu setzen. 

Ein zweiter, besonders relevanter Aspekt der Analyse im Rahmen des Zero-Trust-Konzepts ist der Umgang mit der Menge und Geschwindigkeit der eingehenden Daten, die die Fähigkeit eines jeden Menschen übersteigen, sie zu verarbeiten. Um für Menschen verwertbare Erkenntnisse zu gewinnen, ist daher eine Art von maschineller Unterstützung erforderlich. Auch hier kann die Ausgereiftheit der Unterstützung als Fortschritt bezeichnet werden.

• Nur Visualisierung: Der erste Schritt besteht in einer bloßen Darstellung von Statistiken und Ereignissen, in der Regel über Dashboards auf einem Verwaltungsportal. Die dargestellten Daten basieren auf erfassten Datenströmen (in der Regel entweder eine Zeitreihe oder ein Längsschnitt aus Benutzern/Transaktionen innerhalb eines festen Zeitfensters). Komplexere Dashboards bieten die Möglichkeit, die Daten zu sortieren und zu gruppieren sowie durch Filterung Drilldowns vorzunehmen. In diesem Modell übernimmt der Mensch die gesamte Datenexploration, die Priorisierung von Ereignissen, die Analyse und die Behebung von Problemen, wobei die Automatisierung hauptsächlich bei der Datenexploration hilft.
• Visualisierung und konfigurierbare statische Regeln: Die am häufigsten vertretene nächste Erweiterung der Visualisierung ist die Möglichkeit, statische Regeln festzulegen, die entweder der Warnung oder der Abhilfe dienen. Beispiele für solche Regeln wären etwa „Benachrichtige Menschen <John>, wenn gilt: <CPU-Last steigt für einen Zeitraum von 5 Minuten über 80 %>“ oder „Fordere <MFA per E-Mail> an, wenn gilt: <API [Y] wird aufgerufen und das Land ist nicht [Vereinigte Staaten]>“. Diese Regeln können sich auf vordefinierte Regeln beschränken, die vom Lösungsanbieter vorgegeben werden; komplexere regelbasierte Subsysteme können auch benutzerdefinierte Regeln zulassen, die von einem SecOps-Ingenieur verfasst werden. In jedem Fall werden die angewandten Regeln in der Regel über die Konfiguration gesteuert (und bei Bedarf definiert).
• Visualisierung und ML-Unterstützung: Auf der nächsten Stufe werden komplexere Techniken eingesetzt, um Verhaltensanomalien und/oder Transaktionen aufzuspüren, die den Mustern von zuvor identifizierten bösartigen Transaktionen entsprechen. Obwohl viele Methoden zum Einsatz kommen (und eine ausführliche Diskussion der technischen und geschäftlichen Kompromisse den Rahmen dieses Beitrags sprengen würde), gibt es einige wichtige Punkte, die zu beachten sind:

• Menschlicher Einsatz erforderlich: Manche ML-Techniken erfordern eine „Schulung“ (auch bekannt als überwachtes Lernen). Das bedeutet, dass ein Datenkorpus von angemessener Größe mit Hilfe eines vertrauenswürdigen, zuverlässigen „Klassifizierers“ vorkategorisiert werden muss. Um eine verlässliche Kategorisierung zu erhalten, ist der „Klassifizierer“ oft ein Mensch oder eine Gruppe von Menschen. In solchen Fällen muss der erforderliche menschliche Aufwand berücksichtigt werden. Bei anderen Techniken (auch bekannt als unüberwachtes Lernen) werden Anomalien und/oder Muster von selbst, also ohne menschlichen Einsatz, erkannt.
• Erklärbarkeit: Die Ausgaben eines maschinellen Lernsystems ergeben sich aus der Auswertung der Eingabedaten anhand eines Modells. Dieses Modell kann auf einer Reihe einfacher, leicht zu beantwortender Fragen beruhen, z. B. „Wurde dieser Benutzer im letzten Monat auf diesem Gerät angetroffen?“ Es könnte auch auf einer einfach zu erklärenden Ähnlichkeit beruhen, z. B. „Dieser Benutzer fällt unter das allgemeine Muster, das ich bei Benutzern beobachtet habe, die sich nie während der Arbeitszeit anmelden“. In anderen Fällen kann das Modell auf einer komplexen Reihe von Vektoralgebra-Abläufen beruhen, die auf die Eingabedaten angewendet werden, ohne dass eine leicht erkennbare Logik auf hoher Ebene vorliegt. Dieser letzte Fall ist eindeutig schwerer zu erklären und entspricht eher einer „Blackbox“ als die beiden vorherigen Beispiele. In einigen Fällen ist die Erklärbarkeit ein wichtiger Faktor für das menschliche Verständnis oder die Nachvollziehbarkeit. In diesen Fällen ist ein erklärbares Modell einem undurchschaubaren Modell vorzuziehen. 
• Verfügbarkeit von Vertrauenswerten: Wie bereits erwähnt, ist eine Metrik, die angibt, wie sicher das Modell bei der Entscheidungsfällung ist (mit anderen Worten, wie hoch die relative Wahrscheinlichkeit eines falsch positiven oder falsch negativen Ergebnisses ist), oft sehr nützlich. Einige Algorithmen sind so beschaffen, dass automatisch eine Vertrauensmetrik als Nebenprodukt ausgegeben wird; bei anderen, z. B. regelbasierten, müsste ein Vertrauensniveau explizit als eine der Ausgaben festgelegt werden. In jedem Fall sind Algorithmen, die einen Vertrauenswert liefern können, zuverlässiger als solche, die dies nicht können. 

Wie beim regelbasierten Ansatz kann die ML-Unterstützung nur der Erkennung dienen oder mit einer automatischen Abhilfemaßnahme verbunden sein. Darüber hinaus kann die ML-Unterstützung in Verbindung mit einem regelbasierten System verwendet werden, wobei das maschinell gefällte „Urteil“ (bzw. die Meinung oder das Vertrauen) als Eingabe für eine Regel herangezogen werden kann, z. B. „Führe Aktion aus, wenn gilt: .“ 

Der letzte Grundsatz des Zero-Trust-Ansatzes ist die „Annahme einer Sicherheitsverletzung“. Um es klar und deutlich zu formulieren: Fachmännisch implementierte Authentifizierungs- und Zugriffskontrollmethoden verhindern die allermeisten böswilligen Transaktionen. Allerdings sollte man im Sinne einer gesunden Paranoia davon ausgehen, dass die Durchsetzungsmechanismen der Authentifizierung und Zugriffskontrolle von einem Angreifer, der ausreichend motiviert ist oder Glück hat, überwunden werden können. Die Erkennung von Verstößen – eine Voraussetzung für eine rechtzeitige Reaktion auf begangene Sicherheitsverletzungen – erfordert Transparenz und maschinengestützte Analysen. Da die anderen Durchsetzungsmechanismen gelegentlich überwunden werden, sind die Transparenztechnologien, die die ML-unterstützte kontextbezogene Analyse speisen, von entscheidender Bedeutung, wenn es darum geht, die Zero-Trust-Sicherheitslösung der risikobasierten Abhilfemaßnahmen zu unterstützen. 

Für „falsch negative“ Fälle, in denen eine tatsächlich bösartige Transaktion die Authentifizierung und Zugriffskontrolle unterlaufen hat, sollte der Mechanismus der automatischen risikobasierten Abhilfe als Rückhalt genutzt werden. Da diese Technologie jedoch nur bei Transaktionen zum Einsatz kommt, die die vorherigen Kontrollen bestanden haben, besteht das Risiko, dass eine in Wahrheit „richtig negative“ Transaktion (eine gültige, erwünschte Transaktion) fälschlicherweise als „falsch positiv“ (fälschlicherweise als bösartige Transaktion) eingestuft wird. Um dieses Risiko zu verringern, sollten alle Abhilfemaßnahmen, die durch die Annahme einer möglichen Bösartigkeit ausgelöst werden, die nicht im Rahmen der Authentifizierung oder Zugriffskontrolle erkannt wurde, auf folgenden drei Faktoren beruhen⁴:

• Geschäftswert der Transaktion: Verschiedene Transaktionen sind mit unterschiedlichem Risiko und Nutzen verbunden. So ist beispielsweise eine Transaktion, bei der ein Bankkonto eingesehen wird, weniger riskant als eine Transaktion, bei der Geld auf ein ausländisches Konto überwiesen wird. Ebenso ist für eine Fluggesellschaft der Kauf eines Flugtickets wahrscheinlich mit einem größeren geschäftlichen Nutzen verbunden als eine Transaktion, bei der aktuelle Flugverspätungen aufgelistet werden. Der Geschäftswert ist der Nutzen des potenziellen Geschäftsertrags, der gegen das Risikoprofil der Transaktion abgewogen wird. Es ist akzeptabler, „falsch positive“ Auswirkungen von spekulativen Abhilfemaßnahmen bei Transaktionen mit geringem Nutzen und hohem Risiko zu tolerieren, als bei Transaktionen mit hohem Nutzen und geringem Risiko, die einen hohen Geschäftswert verkörpern. 
• Vertrauen in den Glauben an die „Bösartigkeit“: Natürlich sind nicht alle Vorschläge für spekulative Abhilfemaßnahmen gleich. Neben dem oben erwähnten Risiko-Nutzen-Verhältnis ist der andere Schlüsselfaktor das Vertrauen in die Vorstellungen im Zusammenhang mit dieser Transaktion, z. B. das Vertrauen in die bestätigte Identität des Akteurs. Allgemein formuliert, verhält sich die Wahrscheinlichkeit eines „falsch negativen“ Falls – d. h. die Wahrscheinlichkeit, dass Durchsetzungsmechanismen nicht ausgelöst wurden, obwohl sie hätten ausgelöst werden müssen – umgekehrt proportional zum Vertrauen in den Akteur. Da das Ziel risikobasierter Abhilfemaßnahmen darin besteht, die Zahl der „falsch negativen“ Fälle zu verringern, sollte das System umso eher Abhilfemaßnahmen ergreifen, je geringer das Vertrauen ist.
• Auswirkungen der Abhilfemaßnahmen: Letztendlich geht es nicht bei allen Abhilfemaßnahmen um binäre Entscheidungen – also um das Zulassen oder Blockieren. Tatsächlich sind unterschiedliche Risikominderungstechniken möglich: Einige sind für den Benutzer erkennbar (z. B. die Anforderung zusätzlicher Berechtigungsnachweise bzw. eine MFA oder die Stellung einer Aufgabe wie bei einem Captcha), andere sind für den Benutzer meist nicht wahrnehmbar (die Durchführung einer tiefgreifenden Datenverkehrsprüfung wie DLP oder die Durchführung einer komplexeren/rechenintensiveren Analyse). Daher ist der dritte zu berücksichtigende Faktor die Auswirkung dieser zusätzlichen Risikominderungsformen – gemessen an den Reibungspunkten für den Benutzer und den Betriebskosten für die Anwendung (z. B. für DLP oder rechenintensive Analysen). Für den Kunden transparente Abhilfemaßnahmen mit geringer Auswirkung sind den für den Kunden sichtbaren Herausforderungen mit größerer Auswirkung vorzuziehen, und eine völlige Blockierung der Transaktion ist die am wenigsten attraktive Option. Eine Blockierung kann jedoch bei einem hohen Vertrauenswert oder bei risikoreichen Transaktionen angebracht sein, bei denen das Vertrauen durch die anderen Risikominderungsmechanismen nicht ausreichend erhöht werden kann. 

Die Zero-Trust-Sicherheit ist eine modernere Variante früherer Sicherheitsansätze wie der tiefgreifenden Abwehr, die den bisherigen Stand der Technik um eine transaktionsorientierte Sichtweise auf die Sicherheit erweitert – wer versucht, was gegenüber wem zu unternehmen? Dieser Ansatz ermöglicht es, nicht nur den externen Zugriff auf eine Anwendung zu sichern, sondern auch die internen Komponenten der Anwendung zu schützen.5 Angesichts dieser grundlegenden transaktionalen Sichtweise basiert die Zero-Trust-Sicherheit auf einer Reihe von Kernprinzipien, die zur Verteidigung von Anwendungen in der heutigen komplexen und anspruchsvollen Umgebung verwendet werden. Die Kernprinzipien und ihre Zuordnung zu den Lösungsmethoden sind im Folgenden zusammengefasst. 

Diese Werkzeuge – Authentifizierungsmethoden, Zugriffskontrolle, Transparenz, kontextbezogenen Analyse und risikobewussten Abhilfemaßnahmen – sind notwendig und ausreichend, um eine Vielzahl von Angriffsarten zu verhindern.

Den Bericht herunterladen