In einer Zero-Trust-Umgebung ist Vertrauen nicht statisch. Das Verhalten muss sichtbar sein, damit das Vertrauen bestehen bleibt.
Einer der wichtigsten Unterschiede zwischen dem alten Denken über sichere Netzwerke und der Zero-Trust-Mentalität ist die Umkehrung des Denkens über Vertrauen. Vor der Zero-Trust-Methode galt folgende Prämisse: Wenn man einmal im Netz ist, geht man davon aus, dass man es nach Belieben nutzen kann, bis etwas Außergewöhnliches passiert, das die IT-Abteilung dazu zwingt, den Zugang abzuschalten und zu sperren. Es wird davon ausgegangen, dass die Benutzer weitgehend vertrauenswürdig sind. Daher ist es auch sehr selten, dass sich dieser Status ändert.
Mit der Umsetzung von Zero-Trust im Unternehmen wird diese Annahme umgedreht: Die Nutzung des Netzes hängt vollständig von richtigen Verhalten ab, und die Nutzer werden streng darauf beschränkt, mit wem und wie diese kommunizieren können. Mit anderen Worten: Die Benutzer können nur das tun, was das Unternehmen im Voraus genehmigt hat, und jedes schwerwiegende Fehlverhalten führt automatisch dazu, dass man aus dem Netzwerk ausgeschlossen wird.
Dem Wort „automatisch“ kommt dabei eine wichtige Rolle zu. Eine Zero-Trust-Architektur beinhaltet als integralen Bestandteil eine geschlossene Schleife zwischen dem aktuellen Verhalten eines Nutzers im Netzwerk und der aktuellen Erlaubnis, das Netzwerk zu nutzen. Dieses Vertrauen wird in einer Art Vertrauenskarte für den betreffenden Benutzer manifestiert und treibt die Policy-Engine der Zero-Trust-Umgebung an. Das heißt, Zero-Trust erfordert per Definition eine automatisierte und in Echtzeit erfolgende Rückkopplung zwischen dem beobachtbaren Netzwerkverhalten und den erteilten Netzwerkgenehmigungen.
Das Erkennen von „signifikantem Fehlverhalten“ erfordert Transparenz
Eine Zero-Trust-Implementierung erfordert also Daten darüber, wie jede Einheit im Netzwerk das Netzwerk nutzt (oder zu nutzen versucht). Das bedeutet, dass Informationen aus der Netzwerkinfrastruktur auf jeder Ebene protokolliert werden müssen, von den Core-Switches bis hin zu den Edge-Switches in den Zweigstellennetzen und zu den virtuellen Switches im Rechenzentrum. Natürlich geht es nicht nur um Switches, sondern auch um Router, Application-Delivery-Controller und Load-Balancer, Firewalls und VPNs und natürlich SD-WAN-Knoten. All diese Komponenten sollten das Verhalten von Entitäten an ein zentrales System melden.
Darüber hinaus werden bei allen hostbasierten Aspekten der Architektur (z. B. bei einer softwaredefinierten Perimeter-Implementierung) die Agenten, die auf Netzwerkeinheiten (PCs, virtuellen Servern, Containern, SDP-Gateways usw.) ausgeführt werden, ebenfalls Ereignisströme zur Analyse an eine zentrale Datenbank liefern.
Letztendlich müssen unzählige Ströme von Verhaltensdaten zusammengeführt, gefiltert, aufbereitet und korreliert werden, um eine zentrale Entscheidung zu treffen: Weicht dieser Knoten (oder der Benutzer oder das System darauf) vom vorgesehenen Verhalten ab?
Allein ein Blick auf diese Liste von Datenströmen ist erschöpfend. In einem Netzwerk beliebiger Größe ist es mehr als ein Jahrzehnt her, dass ein Mensch ohne Hilfe auch nur einen dieser Datenströme täglich verfolgen konnte (geschweige denn in nahezu Echtzeit). Und die ersten Generationen von Hilfsmitteln, wie ältere SIEM-Anwendungen, erweisen sich als unzureichend für den Umfang und die Reichweite dieser Art von Analyse in einer modernen Umgebung. Die fortlaufende Entwicklung des Bedrohungsuniversums hin zu mehr mehrkanaligen Angriffsmodellen in Verbindung mit der explosionsartigen Zunahme von Anwendungen, Geräten, VMs und Containern führt dazu, dass SIEMs alten Stils immer weniger in der Lage sind, die Bewertung „normal“ versus „anormal“ vorzunehmen, die den Kern der Zero-Trust-Anforderungen ausmacht.
Der Bedarf von Zero-Trust-Umgebungen an kontinuierlicher Verhaltensanalyse (Behavioral-Threat-Analytics, BTA) kann nur durch die Anwendung von KI-Techniken, in der Regel maschinelles Lernen, gedeckt werden. BTA-Systeme müssen in der Lage sein, Netzwerkentitäten zu verfolgen, ohne sich ausschließlich auf IP-Adressen und TCP- oder UDP-Portnummern zu verlassen, und ein gewisses Gespür für verschiedene Klassen von Entitäten im Netzwerk haben – z. B. Menschen, Software, Hardware -, um ihre Bewertung von Normalität und ihre Schwellenwerte für Anomalien zu steuern. Beispielsweise sollte ein solches System in der Lage sein, alles als anormal zu kennzeichnen, was erfordert, dass sich ein Mensch oder ein physisches Gerät wie ein Laptop an zwei Orten gleichzeitig oder an zwei physisch weit voneinander entfernten Orten in sehr kurzer Folge befindet.
Das Herzstück jeder Zero-Trust-Umgebung ist also die Notwendigkeit, das Verhalten jedes Geräts, jeder Person und jedes Systems, das das Netzwerk nutzt, genau zu kennen. Ohne diese Transparenz können Zero-Trust-Umgebungen nicht das dynamische Vertrauen erreichen, das eine radikalen Risikominderung zur Folge hat.
Von Mathias Hein, Consultant, Buchautor, Redakteur
