Das Konzept von Zero Trust existiert seit 2010, als der Forrester-Research-Analyst John Kindervag das Zero-Trust-Sicherheitsmodell entwickelte. Doch zwei Jahre nach dem verheerenden Angriff auf die Colonial Pipeline und angesichts der nachdrücklichen Unterstützung durch die US-Regierung und andere Akteure sind wir der flächendeckenden Einführung einer Zero-Trust-Architektur noch immer keinen Schritt näher gekommen.
Die einzige Ausnahme scheinen Cloud-Service-Provider zu sein, die dank strenger Sicherheitspraktiken wie Googles kontinuierlichem Patchen einen beneidenswerten Rekord in Sachen Cybersicherheit vorweisen können.
Da es weiterhin stündlich zu Sicherheitsverletzungen kommt, werden Zero-Trust-Anforderungen früher oder später angesichts der Auswirkungen und Kosten für die Gesellschaft allen Organisationen auferlegt werden. Die Biden-Regierung drängt bereits auf ehrgeizige Cybersicherheitsgesetze, doch im derzeitigen Kongress dürften sie kaum weit kommen. Ich bin sehr überrascht, dass die Cyberversicherungsbranche noch keine Zero-Trust-Architektur vorgeschrieben hat. Vielleicht wird aber das Urteil gegen Merck über 1,4 Milliarden US-Dollar, das vergangene Woche gegen die Branche erging, daran etwas ändern.
Die zentrale Frage lautet: Kann eine Organisation einen vollständigen Zero-Trust-Stack implementieren, Hardware und Software verschiedener Anbieter kaufen und alles zusammenfügen – oder müssen wir alle zu Cloud-Service-Providern (CSPs) wechseln, um Zero-Trust-Sicherheit zu erhalten?
Alte Argumente, denen zufolge die Gewinnmargen der Cloud die On-Premises-IT-Infrastruktur irgendwann zur günstigeren Alternative machen würden, konnten eine Ära nicht vorhersehen, in der Sicherheit so schwierig werden würde, dass nur Cloud-Service-Provider sie richtig in den Griff bekommen. Das hat enorme Auswirkungen auf die Zukunft der IT, die wir im Folgenden untersuchen werden.
Die 7 Grundsätze von Zero Trust
Sowohl das NIST als auch das US-Verteidigungsministerium (DoD) haben Richtlinien zu den Anforderungen an Zero Trust veröffentlicht. Die NIST-Leitlinien finden sich hier.
Das NIST nennt 7 Grundsätze von Zero Trust. Wir gehen sie hier kurz durch; die Details finden sich auf Seite 16 des Dokuments.
- Alle Datenquellen und Computing-Dienste gelten als Ressourcen.
- Jede Kommunikation wird unabhängig vom Netzwerkstandort abgesichert. Der Netzwerkstandort allein bedeutet kein Vertrauen.
- Der Zugriff auf einzelne Unternehmensressourcen wird pro Sitzung gewährt. Das Vertrauen in den Anfragenden wird bewertet, bevor der Zugriff gewährt wird.
- Der Zugriff auf Ressourcen wird durch dynamische Richtlinien bestimmt – einschließlich des beobachtbaren Zustands der Identität des Clients, der Anwendung bzw. des Dienstes und des anfragenden Assets – und kann weitere Verhaltens- und Umgebungsmerkmale umfassen.
- Das Unternehmen überwacht und misst die Integrität und den Sicherheitsstatus aller eigenen und zugehörigen Assets. Kein Asset genießt von vornherein Vertrauen.
- Die Authentifizierung und Autorisierung für alle Ressourcen erfolgen dynamisch und werden strikt durchgesetzt, bevor der Zugriff erlaubt wird.
- Das Unternehmen sammelt so viele Informationen wie möglich über den aktuellen Zustand von Assets, Netzwerkinfrastruktur und Kommunikation und nutzt sie, um seinen Sicherheitsstatus zu verbessern.
Nachfolgend ist eine Abbildung des NIST-Stacks aus dem DoD-Dokument zu sehen:
Das DoD-Dokument ist sehr gut, da es konkrete Anforderungen und Implementierungsvorgaben definiert. Das Dokument findet sich hier. Ein gutes Beispiel für einen Workflow findet sich auf Seite 28:
Die US-Regierung hat bislang hervorragende Arbeit dabei geleistet, in diesem Bereich voranzugehen – ähnlich wie in den 1980er-Jahren, als sie die POSIX-Standards für gemeinsame Anwendungsschnittstellen maßgeblich vorantrieb.
Zero Trust ist „sehr komplex“
Es versteht sich von selbst, dass Zero Trust sehr komplex ist. Alles muss nachverfolgt und authentifiziert werden, angefangen bei den Benutzern – sowohl bei Standardbenutzern als auch bei Benutzern mit erweiterten Berechtigungen. Netzwerke müssen segmentiert und authentifiziert werden. Lieferketten müssen validiert werden. Die Umgebung muss verschlüsselt werden, und damit wird auch das Schlüsselmanagement zu einem weiteren äußerst komplexen Prozess.
All das muss nachverfolgt werden, und Richtlinien müssen dynamisch für Netzwerke und Systeme umgesetzt werden. Was passiert, wenn ein neuer Job ausgeführt wird, Ressourcen anders nutzt und das gesamte System lahmlegt, weil der Richtlinienmanager den neuen Job für einen Eindringling hält? Das kann leicht passieren. Hinzu kommt die Komplexität der Abhängigkeit von Drittanbietern: Was wäre etwa, wenn eines der Softwarepakete, die Sie beispielsweise für die Multi-Faktor-Authentifizierung verwenden, gehackt würde (denken Sie an Okta) und jemand dadurch in Ihr System gelangen und die Zero-Trust-Grenze umgehen könnte?
All das ist unglaublich komplex und erfordert in jedem größeren Unternehmen eine große IT-Belegschaft sowie eine Testumgebung. Vielleicht können sich große Banken und Gesundheitssysteme das leisten, weil sie es sich nicht leisten können, darauf zu verzichten. Kleinere Unternehmen und solche mit weniger kritischen IT-Anforderungen können sich das finanziell jedoch oft nicht leisten.
Zu den Organisationen, die Zero Trust benötigt hätten, gehören kritische Infrastrukturen wie Colonial Pipeline, verschiedene Schulsysteme sowie staatliche und kommunale Behörden weltweit, die gehackt wurden und uns alle beeinträchtigt haben. Selbst die öffentlichen Schulen in meiner Wohngegend wurden gehackt. Angesichts der Komplexität der Systeme, die für die Bewältigung der Arbeitslasten unserer komplexen Welt erforderlich sind: Wie soll sich eine kleine Organisation die IT-Mitarbeiter und Hardwareressourcen leisten können, um einen Zero-Trust-Stack zu implementieren?
Natürlich bestehen viele, wenn nicht die meisten, heutigen Hacks schlicht darin, dass jemand auf einen E-Mail-Link klickt, den er nicht hätte anklicken sollen. Aber auch das ist Teil von Zero Trust, und Hacker rüsten auf und werden täglich ausgefeilter. Wenn beispielsweise ein Schulsystem einen Zero-Trust-Stack aufbauen wollte, müsste es alle Grundsätze des Zero-Trust-Stacks für sämtliche Hard- und Software integrieren und Multi-Faktor-Authentifizierung in der gesamten Umgebung implementieren. Ich habe einen Cousin, der IT-Administrator eines Schulsystems ist. Er hat weder das Budget noch die Ressourcen, um das auch nur in Betracht zu ziehen – und glücklicherweise wurden seine Systeme bisher noch nicht gehackt.
Außerdem lesen: Eine ransomware-resiliente Architektur aufbauen
Was ist mit den Cloud-Service-Providern?
Cloud-Service-Provider (CSPs) haben aus mehreren Gründen einen enormen Vorteil gegenüber traditionellen Anbietern von Hardware (Servern und Netzwerken) und Software:
- Sie verfügen über einen einzigen Software-Stack, den sie kontrollieren und größtenteils selbst schreiben und der sich zur Überwachung integrieren lässt. Sie benötigen keine separate Netzwerküberwachung, Multi-Faktor-Überwachung, Betriebssystemüberwachung und so weiter, sondern integrieren, koordinieren und korrelieren all diese Dinge selbst.
- Der Hardware-Stack wird von den Cloud-Service-Providern kontrolliert. Die CSPs bauen größtenteils ihre eigene Hardware und inzwischen sogar ihre eigenen CPUs. Sie fertigen ihre eigenen Netzwerkgeräte, NVMe-SSDs und Mainboards. Sie kontrollieren die Firmware, die Signierung und die Lieferkette. Alles wird von den CSPs integriert.
- Die Zugangspunkte werden engmaschig überwacht. Wenn Sie eine Verbindung zu einem CSP herstellen, wird alles vom Cloud-Service-Provider überwacht. Bei einer Sicherheitsverletzung wissen sie möglicherweise vor Ihnen davon, denn bei anomalem Verhalten würden sie es zuerst bemerken.
Ja, Cloud-Service-Provider kosten wahrscheinlich mehr, als die eigene IT-Infrastruktur zu besitzen. Mit diesen Kosten geht jedoch eine weitaus höhere Sicherheit einher, als sich die meisten Organisationen leisten oder jemals erreichen könnten. Der Kostenunterschied ist daher möglicherweise nicht mehr so groß wie früher. Wurden CSPs gehackt? Ja, aber der letzte größere Angriff war der chinesische Hack von 2009 auf Google. Seitdem wurden keine größeren Hacks von CSPs öffentlich bekannt – abgesehen von Angriffen, die mit dem Eindringen in Kundensysteme und anschließend in den CSP begannen, oder von Datenbanken, die ein CSP-Kunde offen gelassen hatte. Natürlich könnte es Dinge geben, von denen wir nichts wissen, aber nach unserem Kenntnisstand hat es in CSP-Umgebungen keine Sicherheitsverletzungen wie bei der Colonial Pipeline gegeben.
Außerdem lesen: Eine ransomware-resiliente Architektur aufbauen
Was das alles bedeutet
Aus meiner Sicht – ich bin halb im Ruhestand und habe, wenn ich das anmerken darf, viel Zeit zum Nachdenken – bedeutet all das, dass eines von zwei Dingen geschehen muss.
- Die derzeitige Gruppe von Hardware- und Softwareanbietern muss sich zusammentun und eine integrierte und sichere Zero-Trust-Umgebung schaffen, die von allen und jedem implementiert werden kann – vom heimischen PC über kleine und mittlere Unternehmen bis hin zu Großkonzernen. Für Unternehmen und Organisationen muss es Testumgebungen geben, und Budgets müssen festgelegt werden, damit Upgrades und neue Arbeitslasten getestet werden können. Zu den schwierigsten Aufgaben wird die Entwicklung einer Testsuite für Arbeitslasten gehören, die die aktuellen und künftigen Arbeitslasten der Kunden simuliert und sicherstellt, dass die automatische Richtliniengenerierung nicht unnötig Systeme herunterfährt.
- Oder alle sollten zu den großen Cloud-Anbietern wechseln, die über Zero-Trust-Stacks, alle möglichen Arbeitslastgeneratoren und wahrscheinlich auch Richtlinienmanagementsysteme verfügen, die aktuelle und künftige Kundenarbeitslasten bereits gesehen haben.
Einen Mittelweg gibt es nicht – mit Verlaub vor dem Buddha. Der gegenwärtige Zustand kann nicht fortbestehen; irgendetwas wird nachgeben.
Wenn Zero Trust eine Anforderung der Zukunft ist – und ich glaube, dass es so ist –, müssen sich die traditionellen Anbieter kommerzieller Standardprodukte (COT) für On-Premises-Umgebungen zusammentun, um einen Zero-Trust-Stack zu entwickeln. Dazu gehören unter anderem Hardwareanbieter (Netzwerk, Server, Speicher, Firewall usw.), Betriebssystemanbieter (Linux und Windows) sowie Softwareanbieter (Multi-Faktor-Authentifizierung, Metriken, Richtlinien usw.). Das ist eine gewaltige Integrationsaufgabe; darüber hinaus muss ein System zur Emulation von Arbeitslasten geschaffen werden.
Einige große On-Premises-Organisationen wie Finanzdienstleister, Gesundheitsunternehmen und andere verfügen über die Anforderungen und Ressourcen, um dies selbst zu tun. Kleinere Organisationen können das jedoch nicht, und viele von ihnen wurden und werden angegriffen. Für mich ist die Alternative eindeutig: Wenn Zero Trust eine Anforderung ist, sind die CSPs den COT-Anbietern weit voraus. Die COT-Anbieter müssen zusammenarbeiten, um Standards und ein Framework zu entwickeln, das plattformübergreifend funktioniert. In diese große Investition haben die CSP-Anbieter offenbar bereits investiert.
Sicherheit gibt es nicht umsonst
Sicherheit gibt es nicht umsonst, und man bekommt, wofür man bezahlt. Ich bin etwas überrascht, dass Cloud-Service-Provider ihre Sicherheitsvorteile nicht stärker hervorheben. Ebenso überrascht mich, dass sich die COT-Anbieter nicht schneller zusammengeschlossen haben, um an Zero Trust zu arbeiten. Am meisten erstaunt mich jedoch, dass niemand größeren Druck ausübt, auf Zero Trust umzusteigen, gegenüber den aktuellen Angriffstechniken einen oder zwei Schritte Vorsprung zu gewinnen und die Angriffsfläche deutlich zu verkleinern. Ich warte darauf, dass die Versicherungsunternehmen Zero Trust für die von ihnen versicherten Organisationen vorschreiben. Vielleicht haben die Cyberversicherer durch das Merck-Urteil endlich den finanziellen Anreiz dazu erhalten.
Siehe die besten Zero-Trust-Sicherheitslösungen