Zero Trust Network Access (ZTNA) ist ein Konzept und kein Produkt

Wenn wir von Zero Trust Network Access (ZTNA) sprechen, dann wird dies allzu oft auf ein Produkt heruntergebrochen. Viele Anfragen in der Richtung haben sich bei mir letztlich dann „nur“ um Zscaler Private Access (ZPA) Anfragen gehandelt. Das ist auch OK, da ZPA den ZTNA Ansatz durchaus innehat. Damit wird das Thema jedoch auf ein Produkt reduziert, was dem ZTNA Ansatz so nicht ganz gerecht wird.

Denn ZTNA ist kein einzelnes Produkt, sondern eine Architektur oder gar eine eigene Philosophie. Im Grunde genommen beschreibt ZTNA den Vorgang eines Zugriffs, wobei wir jede Interaktion als nicht vertrauenswürdig (Zero Trust) betrachten. Da ein einzelner Client heute nicht mehr für sich arbeiten kann und es dem User schlicht weg keinen Spass machen würde, nur für sich zu sein, sei dies ein interner Server oder ein Server im Internet (Network). Diesen Zugriff müssen wir betrachten, bewerten und schliesslich durch eine Action entsprechend steuern (Access).

Insofern ist ZTNA nicht nur ein Produkt, sondern ein Konzept.

Zscaler Inc. hat hierzu ein sehr gutes Grundkonzept. Dieses beinhaltet sieben Elemente kategorisiert in die drei Schichten „Verifikation“, „Control“ und „Enforce“.  Auf diese möchte ich im Nachfolgenden vertieft eingehen.

Hier geht es in drei Schritten (Who, Context, Where) darum, dass wir verstehen, wer oder was den Zugriff versucht und wohin diese Access stattfindet.

Who

Das klingt im ersten Moment recht simpel, birgt dennoch einige Herausforderungen. „Who“ oder «Wer» kann bedeuten, dass ein User einen Access verursacht. Dazu benötigen wir ggf. noch weitere Details wie den Usernamen, welcher Usergruppe der User oder welchem Department dieser angehört usw., um damit später granulare Regeln bauen zu können. Dies können wir durch Anbindung an eine andere Datenquelle ermitteln – zum Beispiel durch den Einsatz von SAML, bei welchem wir Userdaten aus unserem Active Directory herauslesen.

„Who“ kann auch bedeuten, dass ein Server (oft als „Workload“ bezeichnet) einen Zugriff versucht. Hierbei können wir dann unterteilen, welchem Netz oder welcher Gruppe dieser angehört, indem wir entsprechende Gruppierungen oder Schemata hinterlegen. Gleiches kann bedeuten, dass es sich beim „Who“ um ein IoT Gerät wie einen Drucker, Scanner oder Messfühler handelt.

Context

Im nächsten Schritt ist es wichtig zu verstehen, was der Kontext des Zugriffes ist. Wir müssen also verstehen:

Woher kommt der Zugriff? Ist der Zugriff in einer bestimmten Lokation oder kommt dieser Zugriff als Road Warrior aus dem Internet? In welche Richtung geht der Zugriff (z.B. Up- oder Download, Get oder Push)? Handelt sich es sich bei dem Zugriff um ein vertrauenswürdiges Gerät (durch Verwendung gewisse Endpoint Checks)?

Den Kontext zu verstehen ist essentiell, denn ein Zugriff eines Servers oder IoT Geräts aus einer nicht bekannten Location ist anders einzustufen, als jener eines Users, von einem Firmengerät aus.

Es geht auch darum Anomalien zu detektieren. So kann es zum Beispiel nicht sein, dass ein User innerhalb kürzester Zeit (z.B. weniger Stunden) einen Zugriff aus Europa und wenig später aus Amerika durchführen kann. Gegebenenfalls aus dem Kontext kann abgeleitet werden, ob der User sich nochmals mittels eines zweiten Faktors authentifizieren muss.

Where

Im letzten Schritt dieser Schicht gilt es zu verstehen, «where» oder «wohin «der Zugriff stattfindet – daher was die Destination ist.

Ist es ein interner Server? Ein SaaS Applikation? Ein Zugriff ins Internet? Eine Workload in unserem Datacenter? etc.

Nachdem wir nun verstanden haben, wer in welchem Kontext wohin zugreifen möchte, gilt es in dieser Schicht zu verstehen, welches Risiko besteht.

Access Risk Recognition

Als Erstes versuchen wir bei dieser Schicht zu verstehen, welches Risiko besteht und was die potenziellen Auswirkungen sein könnten. Dies könnte z.B. der Schutz von Malware sein, das Erkennen von Phishing-Attacken, die Verwendung von bestimmter Applikation oder Verwundbarkeit oder Attacken, um den Vektor entsprechend zu klassifizieren.

Compromise Recognition

Als nächstes geht es darum, eine Kompromittierung zu erkennen. Dabei können wir mittels Patterns oder Signaturen bestimmte bekannte Gefahren erkennen oder unbekannte Gefahren durch Analyse und Sandboxing entsprechend versuchen zu detektieren. Dies kann bei Daten im Transit inline oder, wenn die Daten ruhen, via API (z.B. out-of-band CASB) passieren.

Die Anbindung an mehrere Datenquellen durch Kooperationen über Threat Feeds oder das Sharing der gelernten Informationen sind ein essentieller Faktor, der sowohl die Security als auch die Experience erhöht.

Data Loss Recognition

Ebenfalls in dieser Schicht spielt nicht nur der Schutz durch Gefahren eine Rolle, sondern auch der Verlust von klassifizierten Daten. Sei dies durch generell bekannte Patterns (Exact Data Match – z.B. Kreditkarten Nummern), durch persönliche Patterns (Index Data Matching – Customer Data Set), individuelle Klassifizierungen der Daten (z.B. mittel Microsofts Azure Information Protection [AIP]) oder simplem Erkennen und Blockieren von File-Typen.

Hier sollte der File-Typ nicht nur anhand der File-Endung erkannt werden, sondern ebenfalls eine OCR Erkennung stattfinden, um die Data Loss Erkennung zu erhöhen.

Bei allen drei Elementen dieser Schicht kommen verschiedene Schnittstellen, Datenbanken und Technologien am besten zum Einsatz: AV-Scanner oder ATP-Lösungen, Verhaltenserkennungen wie Sandboxing und Anomalie Erkennung, Anbindung von APIs oder Newsfeed (z.B. CVE Databases oder Threat Feeds), sowie auch Datenklassifizierungen sind hier nur einige Stichpunkte, die ich als Beispiel anführen möchte.

In allen Schichten bisher haben wir nun verstanden, wer oder was einen Zugriff erzeugt und was passiert. Wir haben nun im besten Fall das Risiko und die Tragweite erkannt oder wissen optimalerweise exakt was passieren wird oder, ob es sich um eine unbekannte Aktion mit unbekanntem Risiko handelt. Nun müssen wir letztlich noch definieren was die daraus resultierende Aktion ist – doch welche ist das nun?

Jetzt kommt Ihnen sicherlich als erstes in den Sinn, dass man dieses simpel Erlauben oder Blockieren kann. Es gibt jedoch noch einige Aktionen, die vielleicht ebenfalls in Betracht kommen oder verschachtelt miteinander werden können.  Ich werde diese einfach mal in die Kategorien «Herkömmlich», «Conditional Allow» und «Conditional Block» definieren.

Wichtig hierbei ist, dass jede Policy per Session und per Zugriff geprüft und bewertet wird und nicht global eine Annahme getroffen wird.

Herkömmlich:

• • Allow: Bei der Aktion erlauben wir den Zugriff.
  • Block: Bei der Aktion verbieten wir den Zugriff.

Conditional Allow:

• • Warn: Bei dieser Aktion warnen wir den Nutzer vor einem Risiko, geben diesem die Möglichkeit weiter fortzufahren.
  • Prioritize / Deprioritize: Entsprechend können wir den Access priorisieren. So können wir business-kritischen Anwendungen erhöhte Ressourcen zuteilen.
  • Steer: Neben Prioritäten können wir auch vorgegebene Pfade definieren, auf welchen der Zugriff stattfinden kann (z.B. IP Source Anchoring)
  • Isolate: Die Cloud Browser Isolation ist hier zu nennen: Dabei wird die entsprechende Destination (z.B. eine Webseite) in der Cloud in einem Container ausgeführt und lediglich ein Pixel-Stream an den Client übermittelt. Schadware bleibt so in dem Container und wird beim Beenden entsprechend gelöscht.
  • Quarantine: hier wird der Zugriff limitiert erlaubt, jedoch geschützt (z.B. WAF)

Conditional Block:

• • Quarantine: hier wird der Zugriff verboten aber bewertet.
  • Deceive: Hier wird der Zugriff auf eine separate vorgetäuschte Umgebung (engl. deceive) umgeleitet – oft auch als Honeypot bezeichnet – und das Verhalten dort generell ausführen zu lassen und zu analysieren.

Abschliessend nachdem eine Aktion definiert wurde, muss unseres Zero Trust Exchange mit der entsprechenden Workload oder Applikation verbunden werden.

Externe Workloads

Dabei wird, wenn sich die Workloads im Internet oder in einer SaaS befinden, eine neue Verbindung im Namen des «who» (User, Server, IoT) aufgebaut – der Zero Trust Exchange agiert hier als Proxy. Dabei bleibt der einzelne User aus Sicht der Applikation anonym, was einen zusätzlichen Schutz vor «watering hole attacks» – eine Sicherheitslücke durch Analysieren des Verhaltens, bei der der Angreifer versucht, eine bestimmte Gruppe von Endbenutzern zu kompromittieren, indem er Websites infiziert – gibt.

Interne Workloads

Bei intern Workloads (z.B. im Datacenter, IaaS oder PaaS) werden diese Apps als einzelne Ziele betrachtet und nicht als Netzwerke (DMZ oder SaaS), was zudem den Schutz vor «lateral threat movement» begünstigt. Darüber hinaus sind diese für den Client generell unsichtbar und speziell für nicht authentifizierten Zugriff nicht detektierbar. Das Prinzip des inside-out Verbindungsaufbaus (wie z.B. bei ZPA) sorgt generell dafür, dass es keine eingehenden Verbindungen gibt und wir so von extern nicht angreifbar sind. Letztlich schützen wir Workloads auch dadurch, dass wir diese nicht durch Netzwerksegmente separieren, sondern als einzelne Apps betrachten und mittels des Zero Trust Exchange in Hinblick auf den Zugriff eine Microsegmentierung erreichen.

Microsegmentation – der letzte Schritt im ZTNA

Offen bleibt letztlich nur noch die Workload to Workload Segmentierung (reine Microsegmentierung auf Netzwerk oder gar Service Ebene) welche ebenfalls ein weiterer Baustein des Zero Trust Network Access bildet und ich an dieser Stelle noch nicht betrachtet habe…

Ich denke, dass wir hierzu in einem nachfolgenden Artikel etwas zu berichten haben. Also bleiben Sie nur interessiert – ich denke, es wird sich lohnen