Zero Trust – Der Perimeter wankt

Status Quo

Das Perimeter Modell ist die etablierte Architektur, um Daten und Systeme vor externen Bedrohungen zu schützen. Allerdings wird diese nun schon sehr lange genutzt und immer weiter verfeinerte Architekturen in einem Spannungsfeld aus raffinierteren Cyber-Angriffen, neuartigen IT-Diensten, Regulatorik, Usability-Aspekten und insbesondere der Einsatz von Cloud-Services, die das klassische Perimeter Modell obsolet machen, unter Druck gesetzt. Die größte Bedrohung, die auf geschlossene Infrastrukturen wirken, sind auf Angriffe zurückzuführen, die von externen, böswilligen Institutionen und Individuen durchgeführt werden. Beispiele hierfür aus der jüngsten Zeit sind Angriffe auf eine Vielzahl innerdeutscher Institutionen mittels der Schadsoftware Emotet oder aber auch sogenannte Advanced-Persistant-Thread-Angriffe (APT) bedingt durch Sicherheitslücken in populären Applikationen wie im IT-Management-Tool der Firma SolarWinds. (Die Lage der IT-Sicherheit in Deutschland. 2019 & 2020. Bundesamt für Sicherheit in der Informationstechnik. | heise.de. Cyberangriffe gegen US-Ministerien – Moskau unter Verdacht. https://heise.de/-4988355. 2020) Es können eine Vielzahl weiterer Angriffsvektoren aufgezählt werden, deren Gemeinsamkeit es ist, die Mauern des Perimeter Modell zu durchdringen, um in den vulnerablen Bereich der Infrastrukturen zu gelangen und dort Daten zu stehlen oder andere Schäden zu verursachen. Begünstigt werden diese Angriffe zudem durch die Integration von Cloud-Infrastrukturen, IoT-Plattformen oder aber auch der externe Zugriff über VPN-Lösungen, dessen Bedeutung in COVID-19 geprägten Zeiten enorm zugenommen hat. Für diese Lösungen, die externe Zugriffe erfordern, sind an den gehärteten Außengrenzen der geschützten Infrastrukturen Ausnahmen erforderlich, die eine Kommunikation ermöglichen aber zugleich auch wiederum als Einfallsvektor für Angriffe dienen können.

Das Kernproblem am Perimeter Modell ist die Tatsache, dass, sobald die gut gesicherten Außenschichten der Infrastruktur überwunden sind – zum Beispiel durch einen erfolgten Phishing-Angriff eines Mitarbeiter-Clientsystems –es für einen Angreifer sehr einfach ist, sich im Netzwerk des Opfers frei zu bewegen und Schaden zu verursachen. Somit wird diese Art der Absicherung sogar zum Single-Point-of-Failure. Begünstigt wird dieser Umstand, dass dem internen Datenverkehr mehr Vertrauen entgegengebracht wird als dem externen.

Schema Voraussetzungen


Dem entgegenstehen soll das Modell der Zero Trust Infrastructure.

Zero Trust als Antwort auf aktuelle Sicherheitsprobleme

Das Konzept von Zero Trust wurde erstmals 2010 durch John Kindervag, damals für Forrester Research tätig, in einigen Abhandlungen thematisiert. Seitdem wurde diese Philosophie verfeinert und ist auch von renommierten Unternehmen wie z.B. Google in eigenen Implementationen adaptiert worden. Hierbei sollte zunächst betont werden, dass es sich bei Zero Trust Stand heute eher um eine Philosophie handelt und nicht um eine etablierte Referenzarchitektur wie das Perimeter-Modell. Dort haben sich gewisse Standards etabliert, die sich in jeder Implementierung wieder finden. Klassisch im Perimeter-Modell ist der Aufbau einer demilitarisierten Zone (DMZ), die Systeme und Dienste beinhaltet, die vom Internet erreicht werden müssen. Geschützt von Paketfiltern wird das interne Netzsegment von der DMZ und auch vom Internet getrennt. Externe Kommunikation kann für die Teilnehmer im internen Segment nur indirekt z.B. über Proxy-Dienste stattfinden.

Die interne Vertrauensebene des Perimeter-Modells wird mit der Kernphilosophie von Zero Trust aufgehoben: „Grundsätzlich wird keinem Netzwerkverkehr vertraut, solange dessen Vertrauenswürdigkeit nicht nachgewiesen wurde.“ (John Kindervag. Building security into your network’s DNA: The Zero Trust Network Architecture. 2010)
Als Erweiterung zu dieser Grundannahme ist der Gedanke zu betrachten, dass jeder Dienst und jeder Client der Umgebung so behandelt wird, als würde er direkt im Internet betrieben. Daraus ergibt sich grundsätzlich auch eine andere Sichtweise in der Absicherung einzelner betriebener Systeme. Systemhärtung muss dadurch in der Designphase neuer Dienste unmittelbar integriert werden. Auf den Schutz umgebener Systeme darf nicht vertraut werden. (Evan Gilman und Dough Barth. Zero Trust Networks. O’Reilly. 2017)

Schema Voraussetzungen

Im Gegensatz zum Perimeter-Modell, dass den Schutzgrad aus der externen Sicht des Angriffsvektors betrachtet, geht Zero Trust mit dem datenzentrischen Ansatz vor. D.h. die Kritikalität der zu schützenden Ressource gibt das benötigte Vertrauen in den Kommunikationspartner und das daraus resultierende Maß der Schutzmaßnahmen vor. (John Kindervag. No more chevy centers: The Zero Trust Model of Information Security. 2016).

Zero Trust tritt in einer Umgebung vollkommen diskret bei vollem Schutz der Information auf. Dies schlägt sich unter anderem in der Implementation von Google, die unter dem Namen BeyondCorp firmiert, nieder. Ein Hauptantrieb von Google war es, ein einheitliches Nutzererlebnis beim Systemzugriff zu schaffen und dies unabhängig vom jeweiligen Standort. Damit einher ging auch der Ausschluss von VPN-Zugängen. Dies mit dem etablierten Perimeter-Model zu erreichen schien Google nicht erreichbar. (Google BeyondCorp. https://cloud.google.com/beyondcorp) Ergebnisse aus diesem Ansatz sind auch bereits in die Cloudprodukte von Google eingeflossen.

Neben den Grundlagendokumenten von John Kindervag und der BeyondCorp-Implementation von Google veröffentlichte das amerikanische National Institute of Standards and Technology (NIST) eine Definition des Zero Trust-Ansatzes (Special Publication 800-207 – Zero Trust Architecture). Allen vorgenannten Publikationen eint der grundsätzliche Aufbau einer Zero Trust-Umgebung. Ein zentrale Steuerungsebene regelt die Zugriffe auf die zu schützenden Daten und Ressourcen. Hierbei muss zunächst die Vertrauenswürdigkeit der vier Einzelaspekte der beteiligten Nutzer, Einzelsystemen, Applikationen und die Datenübertragung ermittelt werden. Dazu wird ein möglichst großer Datenpool mit unterschiedlichen Informationen zu den genannten Einzelaspekten vorgehalten und auf deren Basis ein Vertrauenswert ermittelt. Das ermittelte Vertrauen wird darauf gegen ein Regelwerk abgeglichen, dass den erforderlichen Vertrauenswert für den Zugriff auf eine Ressource vorgibt. Nach dieser Evaluierung entscheidet die Steuerungsebene, ob der Zugriff auf die angeforderte Ressource in der Datenebene gestattet wird. In der Datenebene befinden sich sowohl die datenführenden Systeme als auch Systeme, die die Entscheidung der Steuerungsebene durchsetzen. Auf Grund der enormen Relevanz der Steuerungsebene in einer Zero Trust Umgebung ist es notwendig, diese besonders gegen Angriffe abzusichern. Dazu ist u.a. auch die physikalische Trennung von Steuerungs- und Datenebene erforderlich. (Evan Gilman und Dough Barth. Zero Trust Networks. O’Reilly. 2017)
Aus Sicht der IT-Sicherheit sind die Sicherheit-schaffenden Komponenten nun nichtmehr an den Grenzen der Netzwerksegmente platziert, sondern allumfassend in der Architektur integriert. In welcher Art die Steuerungsebene und die Datenebene gestaltet sind und in welcher Weise deren Interaktion stattfindet, richtet sich an den individuellen Anforderungen der zu schützenden Ressourcen aus.

Vertrauenswürdigkeit

Zunächst wird grundsätzlich keiner Kommunikation in Zero Trust vertraut. Die Vertrauenswürdigkeit addiert sich aus einer Vielzahl einzelner Bestandteile, die durch die Steuerungsebene zusammengeführt werden und auf deren Grundlage die Zulassung oder Verweigerung des Datenverkehrs erfolgt. Offensichtliche Bestandteile, um einen vertrauenswürdigen Netzteilnehmer zu ermitteln, können eine authentische Nutzerkennung, ein dem Nutzer zugehöriges Zugriffsgerät, Anwendungen und ein zugelassener verschlüsselter Kommunikationskanal sein. Ergänzende Attribute in diesem Kontext können z.B. biometrische Merkmale, die Aktualität der Systemumgebung des Nutzers, Standorte der Anmeldung oder sonstige Attribute des Nutzerverhaltens sein. Die tatsächlichen Zustände dieser Attribute werden mit den Datenbanken der Steuerungsebene abgeglichen und auf dessen Basis ein Vertrauenswert ermittelt. Über- oder unterschreitet dieser Wert festgelegte Schwellen so kann der Zugriff auf eine Ressource erteilt oder verweigert werden. Die Steuerungsebene setzt die Entscheidungen in den Datenverkehr-kontrollierenden Komponenten wie Firewalls o.Ä. in der Datenebene durch. Somit werden Datenkanäle nur zu Ressourcen eröffnet, die dem Nutzer z.B. in Kombination mit seinem Gerät einer spezifischen Geräteklasse freigegeben wurde. Für einen korrekten Nutzer mit einem falschen oder gar fremden Gerät wird die Ressource nicht offenbart. Dies erschwert vor allem Angriffe, bei denen einzelne Attribute einer Identität erbeutet werden. Der Aufwand, alle Attribute zu erfüllen, ist bedeutend höher als im Perimeter-Modell, bei dem es häufig schon ausreichend ist, die Anmeldedaten des Nutzers zu erbeuten und damit in ein System zu gelangen.

Technologien

Auch wenn Zero Trust eine neue Philosophie der Sicherheit darstellt, fußt die Architektur auf etablierten Technologien, die auch schon im Perimeter-Modell angewandt werden. Der Unterschied hier ist, dass diese Technologien viel enger miteinander verzahnt werden und über die Steuerungsebene gemeinsam orchestriert werden. Grundlage für das Bilden von Vertrauen ist das Anwenden von X.509-Zertifikaten zur konsequenten Identifikation von Nutzern, Diensten und Geräten. Diese wiederum sind durch eine private Zertifizierungsstelle auszustellen. Dazu ist eine selbstgemanagte Public Key Infrastruktur (PKI) zu implementieren. Netzwerkverkehr ist grundsätzlich zu verschlüsseln. Dies erfolgt durch IPSec im Transport Modus oder mittels TLS auf Applikationsebene. Um den allgemeinen Netzwerkverkehr nur für vertrauenswürdige Teilnehmer zuzulassen, bietet sich der Einsatz von Verfahren nach IEEE 802.1X-Standard an. Der logische Datenverkehr in der Datenebene wird durch Paketfilter, Firewalls, Proxies und Intrusion Detection Systemen gesteuert sowie protokolliert und analysiert. Die eindeutige Identität eines Netzclients kann durch ein Trusted Platform Module festgestellt und in die Ermittlung der Vertrauenswürdigkeit einbezogen werden. Da die Steuerungsebene möglichst viele Informationen zur Entscheidungsfindung benötigt, sind diese in einem Nutzerinventar und einem Geräteinventar innerhalb der Steuerungsebene vorzuhalten. Hierunter fallen klassische Verzeichnisdienste wie LDAP und CMDB-Systeme. (Evan Gilman und Dough Barth. Zero Trust Networks. O’Reilly. 2017). Starke Authentifizierung ist ein kritischer Sicherheitsmechanismum in einer Zero Trust Architektur, daher ist insbesondere bei Benutzer-Authentifizierung Multi-Faktor-Authentifizierung essentiell.

Transition zu Zero Trust

In den seltensten Fällen besteht heute die Möglichkeit eine Infrastruktur out of the dust aufzubauen. Vielmehr werden in gewachsenen, heterogenen Infrastrukturen eine Vielzahl an Systemen betrieben, die auf unterschiedlichen Technologien aufgebaut wurden. Die Überführung einer Infrastruktur nach Zero Trust oder auch einzelne Aspekte davon bedarf somit einer wohl geplanten Strategie, um diese Systeme nahtlos zu integrieren. Ein diskreter Weg zur Implementierung von Zero Trust kann die Integration der Zero Trust-Umgebung als Subsystem einer bestehenden Architektur darstellen, die zunächst weniger priorisierte Dienste aufnimmt und nach und nach mit geschäftskritischen Diensten angefüllt wird. Über die Zeit wird das System iterativ verbessert und trainiert und ersetzt zum Abschluss die bisherige Architektur nach dem Perimeter-Modell.

Planen Sie mit ihrem Unternehmen den Umstieg auf Zero Trust um eine zukunftssichere und robuste Infrastruktur für ihre Dienste einzusetzen, so sprechen Sie mit uns um die optimale Strategie für den Übergang und ihre neue Sicherheitsarchitektur zu entwerfen.

 

 

Ansprechpartner Andreas Marlow

Ihr Ansprechpartner:

Andreas Marlow

Senior Manager

Mobil: +49 151 11726118
andreas.marlow@insentis.com

Ansprechpartner Valeri Milke

Ihr Ansprechpartner:

Valeri Milke

Senior Manager

Mehr als 15 Jahre Erfahrung in IT-Security
Whitehat-Hacker & Penetrationtester
Incident Response & Forensics
Application Security & DevSecOps
ISMS ISO 27001 Lead Auditor
Betrieblicher Datenschutzbeauftragter (IHK)

Mobil: +49 151 20016884
valeri.milke@insentis.com

 

 

scroll to top
bdu Logo
Bitkom Logo
IT Security Logo