Zero-Trust-Sicherheit: Warum der Zero-Trust-Ansatz eine wichtige Rolle spielt (und zwar für mehr als nur den Zugang)

Eines der wichtigsten Themen im Bereich des Netz- und Anwendungszugangs war in den letzten Jahren das Konzept des „Zero Trust“. In diesem Beitrag zeigen wir, wie sich dieser Ansatz im Wesentlichen durch eine Reihe von einfachen Überzeugungen charakterisieren lässt, die sich nicht nur auf den Zugang, sondern auch allgemeiner auf den gesamten Bereich der Cybersicherheit anwenden lassen.

Dieses Dokument stellt einen Rahmen vor, der die weitreichenden Konzepte rund um Zero Trust umfasst und sie mit dem bestehenden geschäftlichen Hintergrund in Beziehung setzt, der heute Führungskräfte im Bereich der Anwendungssicherheit motiviert. Schließlich enthält dieses Dokument eine Charakterisierung des Zero-Trust-Glaubenssystems – die treibende Kraft für die Implementierung von Tools und Sicherheitslösungen zur Bewältigung der aktuellen und aufkommenden Bedrohungen, die im Fokus eines Folgedokument stehen werden.

Dieser Beitrag dient zweierlei Zielen: erstens der Vermittlung einer sicherheitsorientierten Denkweise, die Führungskräfte im Bereich der Anwendungen einnehmen sollten, und zweitens der Einführung eines Rahmens für Sicherheitsexperten, den wir in künftigen Whitepapers weiter ausbauen werden.

Der Begriff „Zero Trust“ wird mit einer Reihe unterschiedlicher Konzepte auf verschiedenen Abstraktionsebenen in Verbindung gebracht: Manchmal versteht man darunter eine spezifische Lösungsarchitektur, manchmal ein Rezept zur Anwendung bestimmter Technologien und manchmal eine Produkteigenschaft. Unserer Ansicht nach stellt Zero-Trust-Sicherheit im Kern eine Denkweise dar, ein Glaubenssystem, aus dem Techniken und Taktiken hervorgehen, die spezifische Technologien zum Einsatz bringen, die wiederum zur Bekämpfung eines breiten Spektrums an Sicherheitsbedrohungen genutzt werden können.

Das Glaubenssystem, das der Zero-Trust-Sicherheit (ZTS) zugrunde liegt, kann als nächster Schritt in einer Entwicklung des Sicherheitsdenkens betrachtet werden, die vor Jahren mit einer tiefgreifenden Verteidigungsstrategie begann. Diese tiefgreifende Verteidigungsstrategie basiert auf der Überzeugung, dass jeder einzelne Schutzschirm zwar eine geringe, aber reale Wahrscheinlichkeit eines Angriffs bietet, dass aber die Hinzufügung zusätzlicher Schutzschichten für wichtige Ressourcen diese Wahrscheinlichkeit verringert und die Angreifer bremst, während diese gleichzeitig gezwungen sind, mehr Ressourcen für einen erfolgreichen Angriff einzusetzen.

Der Zero-Trust-Ansatz stellt eine Weiterentwicklung dieser Denkweise in drei Dimensionen dar:

• Erstens wird die Prämisse, dass Schutz aus einer Reihe einfacher „Filter“ bestehe, die den Zugriff auf die Anwendung beschränken, dahingehend weiterentwickelt, dass eine ganze Reihe von Schutzmaßnahmen kontextbezogen auf alle Systemtransaktionen angewendet wird. Bei jeder Transaktion geht es darum, folgenden Faktoren auf den Grund zu gehen: Wer versucht, welche Aktion gegenüber wem durchzuführen. Das „Wer“ und das „Wem“ kann jeweils eine beliebige Komponente sein, die Teil des Systems ist oder dieses nutzt – ein Mensch, ein Automat oder ein Stück Code. Das Konzept der Identität ist der Schlüssel zum Wer und Wem, und das Konzept der einer Identität gewährten Rechte wird herangezogen, um festzulegen, was unternommen werden kann.
• Zweitens wird die Bewertung von Sicherheitsentscheidungen nicht als statisch und absolut angesehen, sondern als dynamisch und anpassungsfähig, weshalb im Lichte der beobachteten Verhaltensweisen ständig eine neue Bewertung vorzunehmen ist. Die Entscheidung über die Vorgehensweise bei jeder Transaktion – ob die Interaktion zugelassen oder blockiert werden soll, ob zusätzliches Vertrauen aufgebaut werden soll usw. – muss auch den breiteren geschäftlichen Kontext berücksichtigen und vor allem eine Abwägung zwischen Risiko und Nutzen umfassen.
• Zu guter Letzt wird davon ausgegangen, dass ein Angreifer, der hinreichend motiviert ist oder einfach Glück hat, die Schutzvorkehrungen entweder durchbricht oder umgeht, ganz gleich, wie viele Schutzvorkehrungen getroffen wurden. Daher muss die rechtzeitige Erkennung einer Kompromittierung und die Eindämmung von Exploits ebenfalls ein wichtiger Bestandteil der Gesamtstrategie sein.

Diese Entwicklung ist zum Teil das Ergebnis von Zeit und Erfahrung, wird aber zunehmend auch durch das Zusammentreffen zweier anderer Trends in der Anwendungssicherheit vorangetrieben. Insbesondere eröffnen die Anwendungsarchitekturen von heute einen viel größeren Raum für potenzielle Anwendungsschwachstellen – insbesondere Bedrohungen im „Inneren“ der Anwendungsinfrastruktur –, die von den immer raffinierter agierenden Angreifern ausgenutzt werden können. Glücklicherweise haben die gleichzeitig gemachten Fortschritte im Bereich der Sicherheitstools, insbesondere wenn diese in Verbindung mit modernen Datenerfassungs- und -analysefunktionen verwendet werden, die praktische Umsetzung der Kernkomponenten der Verteidigungsstrategie möglich gemacht.

Der Rest dieser Einleitung bietet einen Überblick über den Rahmen und Umfang unseres Zero-Trust-Sicherheitsansatzes. In den folgenden Abschnitten werden die Problemstellung und ihre Beziehung zu anderen aktuellen Zero-Trust-Ansätzen vertieft, was zu einer Erörterung der Grundüberzeugungen – dem „Warum“ – führt, die als Richtlinie bei der Wahl der Lösungstechnologien und ihrer Anwendung dienen sollte. Künftige Beiträge werden sich mit dem „Wie“ befassen – den Anforderungen an spezifische Technologien wie Authentifizierung, Zugriffskontrolle und KI-gestützte Analysen, die mit dem Zero-Trust-Reifegradmodell in Verbindung stehen.

Simon Sineks Ansatz „Beginnen Sie mit dem Warum“ ist ein wirksames Instrument zur Vermittlung des ZTS-Rahmens, wie Abbildung 1 unten verdeutlicht. Sie können diese Grafik von außen nach innen betrachten, beginnend mit den verschiedenen Bedrohungsklassen, gegen die ZTS vorgeht, dann die angewandten Sicherheitsmethoden untersuchen und schließlich alles zu gemeinsamen Grundsätzen zusammenfassen. Sie können sie aber auch von innen nach außen betrachten, wobei die Grundüberzeugungen als „Polarstern“ den Ausgangspunkt bilden, aus dem sich die entsprechenden Instrumente und Techniken ergeben, die Sie schließlich in die Lage versetzen, ein breites Spektrum an Bedrohungen zu bewältigen.

Abbildung 1 – Zero-Trust-Sicherheit: Glaubenssystem, Instrumente und Vorteile

In den folgenden Abschnitten werden die einzelnen konzentrischen Schichten dieses Diagramms detailliert erläutert, doch hier ein kurzer Überblick:

• Die Grundüberzeugungen des Ansatzes ergeben sich aus der Formulierung des Anwendungsfalls:
  „Wer versucht, was (welche Aktion) gegenüber wem durchzuführen?“
  • Um das Wer und Wem  zu bestimmen, verifizieren Sie explizit jede Identitätsbescheinigung.
  • Sobald Sie das Wer festgelegt haben, schränken Sie nach dem Prinzip der geringsten Berechtigung ein, was ausgeführt werden kann.
  • Bewerten Sie wiederholt und kontinuierlich alle drei Faktoren – Wer, Was und Wem – und validieren Sie sie fortlaufend anhand der Richtlinienvorgaben.
  • Gehen Sie stets davon aus, dass es zu Verstößen und Kompromittierungen kommen wird. Seien Sie darauf vorbereitet einzugreifen, wenn die Aktion (was gegenüber wem) auf der Grundlage einer Risiko-Nutzen-Analyse (die Wahrscheinlichkeit von Betrug bei der Authentifizierung, gewichtet nach den geschäftlichen Auswirkungen einer fehlerhaften Transaktionsgenehmigung) eine vorher festgelegte akzeptable Sicherheitsschwelle überschreitet.
• Angewandte Methoden:
  • Authentifizierung und Zugriffskontrolle, um das Wer mit einiger Gewissheit zu bestimmen und dann die Berechtigungen in Bezug auf das Was (Aktionen) einzuschränken, das von dieser Identität in Bezug auf ein bestimmtes Wem-Ziel zugelassen werden sollte.
  • Transparenz und ML-gestützte Analyse zur Beobachtung und kontinuierlichen Bewertung des vollständigen Zusammenhangs jeder Transaktion – wer unternimmt was gegenüber wem.
  • Automatisierte, risikobewusste Abhilfemaßnahmen, um in eine Transaktion einzugreifen, sobald das Risiko-Nutzen-Niveau die festgelegte Toleranzschwelle übersteigt.
• Mit diesen Methoden lässt sich ein breites Spektrum von Cyberangriffen abwehren:
  • Herkömmliche Angriffe wie Defacement (Verunstaltung) oder Datenexfiltration – Sie können gegen solche Angriffe vorgehen, indem Sie Identitätskompromittierungen oder Rechteausweitungen erkennen und die Techniken der Authentifizierungs- und Zugriffskontrolle nutzen, um anhand von Richtlinien einzuschränken, wer was unternehmen darf.
  • Angriffe auf die Verfügbarkeit/DDoS-Angriffe – Um diesen Angriffen zu begegnen, kombinieren Sie Authentifizierungs- und Zugriffskontrollen mit risikobewussten Abhilfemaßnahmen. Sie blockieren (oder beschränken) beispielsweise den Zugriff durch nicht oder nur unzureichend authentifizierte Akteure, die ressourcenintensive Transaktionen durchzuführen versuchen.
  • Hochentwickelte Bedrohungen wie Ransomware oder Angriffe auf die Lieferkette – Diesen Bedrohungen können Sie begegnen, indem Sie Änderungen und Anomalien im Verhaltensablauf von Wer unternimmt was gegenüber wem erkennen und risikobewusste Abhilfemaßnahmen treffen.

Zero-Trust-Sicherheit erstreckt sich ganzheitlich über den gesamten Anwendungs-, Infrastruktur- und Bereitstellungsstapel und sollte die ganze Entwicklungspipeline umfassen. Im Einzelnen sollten folgende Punkte abgedeckt sein:

• Kompletter Anwendungs- und Infrastrukturstapel von oben nach unten
  • Hardware-Rechensubstrat, einschließlich Servern, Netzwerkschnittstellenkarten, Koprozessoren und Systemplatinenkomponenten
  • Low-Layer-Firmware und BIOS für die Hardware
  • Das Betriebssystem der untersten Schicht, z. B. der Hypervisor oder die Laufzeitablaufsteuerung
  • Das Betriebssystem der Anwendungsebene bzw. des Containers
  • Importierte Anwendungskomponenten von Drittanbietern, entweder kommerziell oder Open Source
  • Jede intern entwickelte oder maßgeschneiderte Anwendungssoftware
• Vollständiger Anwendungsbereitstellungsstapel von links nach rechts
  • Die Lieferkette, die für die laufende Wartung und Aufrüstung der einzelnen Elemente des „Von oben nach unten“-Stapels verwendet wird
  • Alle Inline-Komponenten zur Anwendungsbereitstellung, wie Firewalls, Load Balancer, API-Gateways, Eingangs-/Ausgangs-/Mesh-Steuerung und Inline-Geräte zur Betrugsbekämpfung
  • Alle Komponenten für die Anwendungsbereitstellung, die sich indirekt auf die Abwicklung des Datenverkehrs auswirken, wie z. B. DNS-Resolver (Domain Name System), oder die indirekt Metadaten empfangen, wie z. B. SIEM-Lösungen (Security Information Event Management) oder gebündelte Identitätsdienste

Traditionell liegt der Schwerpunkt des Zero-Trust-Ansatzes auf den Teams für Anwendungsentwicklung und -bereitstellung, die oft als die Personas Dev, DevOps, DevSecOps und SRE bezeichnet werden. Wir weisen darauf hin, dass ein umfassender Zero-Trust-Ansatz idealerweise auch nichttraditionelle Personas und Infrastrukturen sowie zusätzliche Arbeitsabläufe, wie z. B. die Beschaffungsstrategie für die Lieferkette, einbeziehen sollte.

Eine der obersten Prioritäten für Informationstechnologieleiter (CIO) und Informationssicherheitsverantwortliche (CISO) ist die Modernisierung der Informationstechnologie zur Beschleunigung der Geschäftsabläufe. Sie spielen auch eine Schlüsselrolle bei der Steuerung der Unternehmensrisiken. Ihr Ziel ist es, das Unternehmen dabei zu unterstützen, Kunden mit neuen digitalen Erlebnissen zu begeistern, die betriebliche Effizienz durch digitale Vernetzung mit Dritten zu steigern und Mitarbeitern die Möglichkeit zu geben, von überall aus produktiv zu sein, während sie gleichzeitig die Geschäftsrisiken minimieren. Dies setzt voraus, dass die CIO- und CISO-Organisationen ihren Mitarbeitern die Möglichkeit geben, die neuesten Technologien, Architekturen und Best Practices für mehr Flexibilität zu nutzen, und gleichzeitig dieselben Leute damit beauftragen, angemessene Sicherheitsmaßnahmen zu ergreifen und Kontrollen über das Verhalten der Mitarbeiter, die Informationen, auf die sie zugreifen, und die Technologie, die sie verwenden, einzurichten, um Verluste zu vermeiden.

Unternehmen müssen die Risiken erkennen und kontrollieren, die im Zusammenhang mit Änderungen an den Markt- und makroökonomischen Bedingungen, dem Verbraucherverhalten, der Lieferkette und den Sicherheitsangriffsflächen entstehen. Eine korrekte Risikobewertung und die Fähigkeit, rasch risikomindernde Maßnahmen zu ergreifen, stellen für Unternehmen einen Wettbewerbsvorteil dar. In diesem Beitrag konzentrieren wir uns auf das Risiko von Sicherheitsangriffsflächen, die unter anderem den Verlust von geistigem Eigentum, die Unterbrechung von Geschäftsprozessen, den Verlust personenbezogener Daten und von Aufsichtsbehörden verhängte Geldstrafen nach sich ziehen können. Das Sicherheitsrisiko lässt sich berechnen, indem man die folgenden Aspekte einer zu betrachtenden Situation evaluiert:

1. Wert der beteiligten Vermögenswerte
   Vermögenswerte, die an Transaktionen beteiligt sind, sind von unterschiedlicher Bedeutung. So ist beispielsweise eine Datenbank mit personenbezogenen Daten wertvoller als eine Datenbank, in der Einzelhandelsstandorte aufgeführt sind, die Produkte des Unternehmens führen. Sicherheits- und IT-Teams können ein deterministisches Verfahren anwenden, um ein Inventar aller Vermögenswerte zu erstellen und diese durch eine Punktzahl zu kategorisieren, die den „Wert“ des Vermögenswerts darstellt.


2. Auswirkungen von Kompromittierungen
   Die Art der Kompromittierung bestimmt die damit verbundenen Auswirkungen. So ist beispielsweise die Auswirkung einer heimlichen Ausspähung von im Datenspeicher enthaltenen personenbezogenen Daten viel größer als eine Störung der Verfügbarkeit des Datenspeichers. Es ist zwar etwas vage, aber dennoch möglich, verschiedene Arten von Kompromittierungen aufzulisten und ihnen eine „Auswirkungspunktzahl“ zuzuweisen.


3. Kompromittierungswahrscheinlichkeit
   Die Wahrscheinlichkeit, dass eine Transaktion zu einer Kompromittierung eines Vermögenswerts führt, ist der am wenigsten kalkulierbare Faktor bei der Bewertung des mit der Transaktion verbundenen Risikos. Da Menschen allein nicht in der Lage sind, alle erforderlichen Beobachtungen allein zu bewältigen, setzen Unternehmen auf maschinelles Lernen und künstliche Intelligenz, um die Berechnung der Kompromittierungswahrscheinlichkeit zuverlässiger werden zu lassen.

Die Herausforderung besteht darin, das mit jeder einzelnen Transaktion verbundene Risiko annähernd in Echtzeit zu berechnen und geeignete Abhilfemaßnahmen zu ergreifen, um die Auswirkungen einer möglichen Gefährdung zu kontrollieren.

Abbildung 2 – Der geschäftliche Druck ist Auslöser für neue Praktiken, die zu einem erhöhten Risiko führen.

1. Der Wunsch nach beschleunigten Geschäftsabläufen
   1. Digitale Erlebnisse
      Die Verbraucher haben ein unstillbares Verlangen nach digitalen Erlebnissen und wünschen sich laufende Verbesserungen auf mehreren Plattformen (PC, Tablet, Mobiltelefon).
   2. Vernetzte Unternehmen
      Digitale Geschäftsprozesse erfordern die Vernetzung mit Partnern, Anbietern, Händlern und Dienstleistungen anderer Unternehmen.
   3. Mobile Belegschaft
      Um effizient arbeiten zu können, müssen Mitarbeiter von überall aus auf Geschäftsanwendungen zugreifen können.


2. Praktiken zur Erfüllung der Geschäftsanforderungen
   1. Agile Entwicklungsmethodik
      Unternehmen sind von einem fortlaufenden Wasserfallansatz, der sich auf die rechtzeitige Projektlieferung konzentriert, zu einem schrittweisen, iterativen agilen Entwicklungsansatz übergegangen, bei dem die Kundenzufriedenheit im Vordergrund steht.
   2. Nutzung gebrauchsfertiger Software
      Um neue digitale Erlebnisse so schnell wie möglich bereitzustellen, verwenden die Entwickler Code, der von Branchenkollegen als Open Source zur Verfügung gestellt wird.
   3. Vertraglich ausgelagerte Entwicklung
      Die Auslagerung von Arbeiten an beauftragte Entwickler hilft Unternehmen, ihre Belegschaft nach Bedarf zu skalieren.
   4. Nutzung der Cloud-Infrastruktur
      Die Agilität, Flexibilität und Skalierbarkeit der Cloud und ihre Benutzerfreundlichkeit ermöglichen es den Entwicklern, die benötigte Infrastruktur auf Abruf zu erhalten.
   5. Einführung von SaaS
      Software as a Service (SaaS) ist für betriebliche Anwendungen von Vorteil, da damit der Aufwand für die Beschaffung, Bereitstellung und Wartung solcher Anwendungen in privaten Rechenzentren erheblich reduziert wird.
   6. Microservices-Architektur
      Teams nutzen Microservices, um eine kontinuierliche Bereitstellung mit kürzeren Markteinführungszeiten zu erreichen.
   7. Verteilte Anwendungskomponenten
      Unternehmen erreichen Effizienz, indem sie Microservices in Infrastrukturen ausführen, die optimale Tools für die Entwicklung oder Bereitstellung der Dienstfunktionen bieten. Jüngste Erweiterungen von Legacy-Workflows werden mittels moderner Anwendungsarchitekturen durchgeführt, die mit den Legacy-Elementen kommunizieren müssen, und beide werden oft auf unterschiedlichen Infrastrukturen ausgeführt.
   8. Offene APIs
      Ein Ökosystem aus verschiedenen Diensten ist effizienter als ein Unternehmen, das alle Dienste selbst entwickelt.
   9. Vernetzung mit Dritten
      Unternehmen vernetzen sich über verschlüsselte Tunnel mit ihren Partnern, Anbietern und Händlern, um Geschäftsprozesse zu automatisieren und zu optimieren.


3. Erhöhtes Sicherheitsrisiko
   1. Vergrößerte Angriffsfläche
      Die Verwendung von Software von Drittanbietern und Open-Source-Bibliotheken schafft Möglichkeiten für Angriffe auf die Lieferkette, und alle Schwachstellen der extern entwickelten Software werden übernommen. Beauftragte Entwickler sind bestrebt, die verlangten Funktionen rechtzeitig bereitzustellen, und kümmern sich dabei nicht um die Sicherheit. Haben die externen Entwickler erst einmal ihren Auftrag erledigt und sich aus dem Projekt zurückgezogen, ist es für interne Teams schwierig und zeitaufwändig, den Code zu überprüfen und Sicherheitslücken aufzuspüren. Agile Sprints sind sehr effizient in der Bereitstellung von Funktionsmerkmalen, doch die temporeiche Entwicklung lässt nicht viel Zeit für eingehende Sicherheitsprüfungen und Tests. Ein einziger Microservice, der eine Sicherheitslücke aufweist und mit anderen Microservices kommunizieren kann, erhöht das Sicherheitsrisiko für das gesamte System.

      Obwohl die Vernetzung von Unternehmen die betriebliche Effizienz verbessert, besteht die große Gefahr, dass Sicherheitslücken in einem der Unternehmen Auswirkungen auf alle anderen haben. Angreifer suchen sich das schwächste Glied aus und übernehmen von dort aus die übrigen Bereiche. Eine Schwachstelle oder Sicherheitslücke in der SaaS-Plattform oder Cloud-Infrastruktur wird zu einem zusätzlichen Angriffsvektor, und das Modell der geteilten Verantwortung kann eine frühzeitige Erkennung und Behebung erschweren.

   2. Komplexere Architekturen
      Verteilte Anwendungselemente, die mit unterschiedlichen Architekturen entwickelt und auf verschiedenen Infrastrukturen eingesetzt werden, bringen unterschiedliche Sicherheits- und Compliance-Anforderungen mit sich. Dies macht es für Sicherheitsteams schwer, geeignete Mechanismen zur Sicherung von Unternehmensanwendungen und -daten zu entwerfen und zu implementieren und die gesetzlichen Anforderungen zu erfüllen.
      
   3. Finanziell gut ausgestattete, hochmotivierte und erfahrene Hacker
      Von der Operation Aurora im Jahr 2010 bis zu Solargate im Jahr 2020: Wir blicken auf ein Jahrzehnt voller raffinierter Cyberangriffe zurück, die erst entdeckt wurden, als sie bereits großen Schaden angerichtet hatten. Die Angriffe richteten sich gegen Unternehmen, die mit der besten, von hochqualifizierten Sicherheitsteams betriebenen Sicherheitstechnologie ausgestattet waren. Die Angreifer hielten sich lange Zeit in der IT-Infrastruktur dieser Unternehmen auf, bevor sie entdeckt wurden. Geistiges Eigentum wurde gestohlen, personenbezogene Daten wurden entwendet, Geschäftsabläufe wurden gestört, Unternehmen wurden mittels Ransomware erpresst, und das, obwohl die IT- und Sicherheitsteams alles unternahmen, um die Vorschriften zur Abwehr von Cyberangriffen einzuhalten.

Nach einer Flut von hartnäckigen Cyberangriffen auf verschiedene US-amerikanische Bundes-, bundesstaatliche und Kommunalbehörden sowie auf mehrere US-amerikanische Unternehmen erließ Präsident Joe Biden am 12. Mai 2021 eine Anordnung zur Verbesserung der nationalen Cybersicherheit. Eines der Schlüsselelemente dieser Anordnung bestand darin, dass die Regierungsbehörden die Grundsätze des Zero-Trust-Ansatzes anwenden sollten, um sich auf Cyberangriffe vorzubereiten. Die Biden-Regierung folgte dieser Anordnung am 26. Januar 2022 mit einem Memorandum des Office of Management and Budget (OMB), das sich an die Leiter der Exekutivabteilungen und -behörden richtete. Dieses Memorandum des OMB „legt eine Bundesstrategie für eine Zero-Trust-Architektur (ZTA) fest, die von den Behörden verlangt, bis zum Ende des Geschäftsjahres 2024 bestimmte Cybersicherheitsstandards und -ziele zu erfüllen, um die Abwehr der Regierung gegen immer ausgefeiltere und anhaltende Bedrohungskampagnen zu stärken.“¹ Sowohl die Anordnung des US-Präsidenten als auch das OMB-Memorandum beziehen sich auf die Zero-Trust-Architektur, die in der im August 2020 veröffentlichten Publikation SP 800-207 des National Institute for Standards and Technology (NIST) beschrieben ist, und verlangen von den Regierungsbehörden, diese zu befolgen.

Vordenker in Regierungsbehörden und im privaten Sektor haben Dokumente veröffentlicht, die die Zero-Trust-Architektur näher erläutern und Ratschläge bezüglich ihrer Einführung geben. Im Folgenden fassen wir die in diesen Beiträgen enthaltenen Ideen zusammen. Festzuhalten ist, dass die in diesen Papieren enthaltenen Ideen und Vorschläge sich darauf beziehen, alle Transaktionen dahingehend zu untersuchen, wer welche Aktion gegenüber wem ausführt, und in Echtzeit zu entscheiden, ob die Transaktion auf der Grundlage einer Berechnung des damit verbundenen Risikos zugelassen oder abgelehnt werden soll.

Das NIST-Team führt die Grundsätze des Zero-Trust-Ansatzes auf und definiert in dem Dokument NIST SP 800-207 eine abstrakte Zero-Trust-Architektur (ZTA).² Darüber hinaus werden verschiedene Varianten von Zero-Trust-Ansätzen und diverse Möglichkeiten zur Bereitstellung der abstrakten Architektur erörtert.

Die wichtigsten Abstraktionen, die in diesem Dokument behandelt werden, sind der Policy Decision Point (PDP) und der Policy Enforcement Point (PEP), die in Verbindung miteinander funktionieren. Der Policy Decision Point besteht aus der Policy Engine (PE) und dem Policy Administrator (PA). Die Policy Engine entscheidet anhand eines Vertrauensalgorithmus, ob einem Subjekt der Zugang zu einer Ressource gewährt werden soll. Diese Entscheidung wird vom Policy Administrator umgesetzt, der mit dem Policy Enforcement Point kommuniziert, um eine neue Sitzung zuzulassen oder zu verbieten und um eine bestehende Sitzung zu ändern oder zu beenden. Darüber hinaus werden Varianten des Vertrauensalgorithmus, Netzwerkkomponenten für eine Zero-Trust-Umgebung und verschiedene Anwendungsfälle oder Einsatzszenarien erörtert. Schließlich werden Möglichkeiten beleuchtet, wie die Zero-Trust-Architektur von Angreifern durchkreuzt werden kann, wodurch Implementierer sich der Bedrohung bewusst werden und geeignete Maßnahmen zum Schutz ihrer Zero-Trust-Architekturkomponenten ergreifen.

Mit dem Ziel, die Behörden bei der Entwicklung ihrer Zero-Trust-Pläne zu unterstützen, haben Vordenker der Cybersecurity and Infrastructure Security Agency (CISA) ein Zero-Trust-Reifegradmodell veröffentlicht.³ Die Arbeit baut auf der abstrakten Zero-Trust-Architektur auf, die in dem Dokument NIST SP 800-207 beschrieben wird. Die Autoren haben fünf Bereiche identifiziert und empfehlen den Unternehmen, die Zero-Trust-Prinzipien in allen Bereichen konsequent einzuhalten. Bei den Bereichen handelt es sich um (i) Identität, (ii) Gerät, (iii) Netzwerk, (iv) Anwendungsworkload und (v) Daten. Es wird empfohlen, in jedem der fünf Bereiche auf Transparenz und Analysen sowie auf Automatisierung und Orchestrierung zu setzen.

Das Dokument bietet ein überblicksartiges Reifegradmodell aller fünf zuvor genannten Grundpfeiler des Zero-Trust-Ansatzes und geht dann tiefer auf die einzelnen Bereiche ein. Unternehmen können das Reifegradmodell nutzen, um ihren aktuellen Status einzuordnen und einen iterativen Kurs in Richtung des optimalen Status einzuschlagen.

Nach der Entdeckung der SolarWinds-Angriffe gab die National Security Agency (NSA) mit ihrer Publikation „Einführung eines Zero-Trust-Sicherheitsmodells“ einen Leitfaden heraus, in dem sie Cybersicherheitsteams rät, ein Zero-Trust-Sicherheitsmodell einzuführen.⁴ Experten aus dem gemeinsamen Zero-Trust-Engineering-Team der Defense Information Systems Agency (DISA) und der National Security Agency verfassten das Dokument „Verteidigungsministerium (DOD): Zero-Trust-Referenzarchitektur“.⁵ Die Autoren bringen die Notwendigkeit der Einführung des Zero-Trust-Modells mit der folgenden Aussage zum Ausdruck: „Sicherheitslücken, die anlässlich von Datenschutzverletzungen innerhalb und außerhalb des Verteidigungsministeriums zutage getreten sind, zeigen die Notwendigkeit eines neuen und robusteren Cybersicherheitsmodells auf, das fundierte, risikobasierte Entscheidungen ermöglicht.“⁶

Die Empfehlungen im Zusammenhang mit dieser Referenzarchitektur basieren auf den Abstraktionen, die im Dokument NIST SP 800-207 „Zero-Trust-Architektur“ definiert sind. Das Dokument stellt ein umfassendes Betriebsmodell vor und geht detailliert auf die einzelnen Elemente ein. Es enthält auch ein überblicksartiges Reifegradmodell und ordnet Möglichkeiten zur Anwendung von Zero-Trust-Prinzipien verschiedenen relevanten Bereichen zu. Zusammen helfen diese Dokumente Unternehmen dabei, ihren aktuellen Status zu bewerten und einen Plan zu entwickeln.

Eine Einstellung, die von einer Sicherheitsverletzung ausgeht, und die Befolgung der Zero-Trust-Prinzipien können Unternehmen bei ihrem Risikomanagement und ihrer Führungspraxis helfen. Die Zero-Trust-Prinzipien der „kontinuierlichen Überwachung“ und „eindeutigen Verifizierung“ der an den Transaktionen beteiligten Akteure ermöglichen es Unternehmen, eine dynamische Risikobewertung für alle Akteure und deren Aktivitäten zu erstellen. Dies entspricht der Empfehlung von Gartner, die CARTA-Methode (Continuous Adaptive Risk and Trust Assessment – kontinuierliche, adaptive Risiko- und Vertrauenswürdigkeitsbewertung) zur Verbesserung der bestehenden Sicherheitsprogramme einzusetzen. Die Anwendung des Prinzips, einen Zugriff auf Ressourcen ausschließlich nach dem „Least Privilege“-Prinzip zuzulassen, verringert das Verlustrisiko auch im Falle einer Sicherheitsverletzung. Die durch kontinuierliche Überwachung und eindeutige Verifizierung gewonnenen Informationen sind auch für die Erstellung von Compliance-Berichten nützlich.

Dieser Abschnitt widmet sich der Denkweise – dem Glaubenssystem bzw. dem „Warum“, das hinter der Strategie und der Entscheidung für bestimmte Instrumente und Konzepte steht, die ein Unternehmen zur Erreichung der Zero-Trust-Sicherheit einsetzen sollte. De facto kann man den Antrieb für alle Methoden und Komponententechnologien, die von den heutigen Zero-Trust-Lösungen eingesetzt werden, auf vier einfache Schlüsselprinzipien herunterbrechen. Dieser Abschnitt beginnt mit einer Vorstellung dieser Prinzipien und setzt sich dann damit auseinander, wie sie im breiteren Kontext des Lebenszyklus der Anwendungsentwicklung angewandt werden können – wie also diese Prinzipien im Vorfeld, in der Designphase sowie operativ bei der Bereitstellung und Ausführung der Anwendung berücksichtigt werden können.

Versteht man Zero-Trust-Lösungen als Fundament für den Aufbau von Vertrauen in Systeminteraktionen – „Wer unternimmt was gegenüber wem?“ –, dann kann der Aufbau eines interaktionstauglichen Vertrauensniveaus in vier Komponenten heruntergebrochen werden.

Wie der Name schon sagt, folgt die Zero-Trust-Denkweise dem Ansatz „Niemals blind vertrauen, immer zuerst überprüfen“. Somit muss jeder Akteur im System – das Wer und das Wem in den Systeminteraktionen – folgende Voraussetzungen erfüllen:

1. Er muss seine Identität nachweisen bzw. seine „anonyme“ Identität in dem Sonderfall, dass das System Interaktionen zulässt, die von anonymen Identitäten ausgehen oder für anonyme Identitäten bestimmt sind, wie z. B. im Falle von anonymen Browsern in einem Flugbuchungssystem. Für alle anderen Identitäten gilt, dass der Akteur in der Lage sein muss, in einem vom System akzeptierten Namespace anzugeben, wer er ist.
2. Er muss „Nachweise“ für die bescheinigte Identität des Akteurs einholen und diese überprüfen (bei nicht anonymen bescheinigten Identitäten). Die Art des Nachweises – Kennwörter, Zertifikate, Verhaltensweisen usw. – kann ebenso wie die Beweiskraft dieses Nachweises variieren, doch das System muss in der Lage sein, der Bescheinigung ein gewisses Maß an Vertrauenswürdigkeit zuzubilligen. Einfache Systeme können eine binäre Ja/Nein-Ansicht bezüglich der Vertrauenswürdigkeit des Nachweises verwenden, während fortschrittlichere Systeme einen numerischen Vertrauenswert zuweisen können, auf den im Rahmen einer Risiko-Nutzen-Strategie ausdrücklich Bezug genommen werden kann. Zu beachten ist, dass das System die Einschätzung der Vertrauenswürdigkeit auch durch andere Mittel erhöhen oder verringern kann, z. B. als Reaktion auf eine aktive Aufforderung oder auch durch die passive Beobachtung eines Verhaltens des Akteurs.
3. Er muss die Vertrauenswürdigkeit der bescheinigten Identität auf Basis einer zusätzlichen Kontextualisierung des aktuellen Verhaltens im Vergleich zu früheren Verhaltensweisen bewerten und entsprechend anpassen. So kann das System beispielsweise historische Metadaten über den Akteur speichern, z. B. frühere und aktuelle Standortdaten des Akteurs, Hardware-Plattformen, IP-Adressen, Reputationsdaten usw., um das jeweilige Maß an Vertrauen in den „Identitätsnachweis“ zu erhöhen oder zu verringern.

Darüber hinaus lässt sich das Prinzip der eindeutigen Verifizierung nicht nur auf die Identität, sondern auch auf die Aktion – das „Was“ der Transaktion – anwenden. Oft kommt es vor, dass die Aktion in einem API-Aufruf besteht, z. B. im Fall einer API zur Durchführung einer Datenbankabfrage. In diesem Beispiel kann das Prinzip der eindeutigen Verifizierung nicht nur dazu verwendet werden, um Vertrauen in die Identität des Akteurs zu fassen, der die API aufruft, sondern auch, um die Korrektheit der Verwendung der API-Aktion zu überprüfen, wie z. B. um zu überprüfen, ob die an die API übermittelten Parameter die entsprechenden Vorgaben einhalten.

In einer ausgereiften Zero-Trust-Denkweise ist ein „Nachweis“ nahezu nie eine absolute Größe. Identitätsnachweise können gestohlen und Geräte kompromittiert werden; API-Parametervorgaben sind oft unvollständig. Daher sollte der Begriff „Vertrauen“ in einem Zero-Trust-Kontext eher als Hinweis darauf verstanden werden, wie wahrscheinlich es ist, dass die bescheinigte Identität oder die Transaktionsparameter legitim sind. Der „Grad der Vertrauenswürdigkeit“ sollte daher als ein wichtiger, jedoch nicht als der einzige Faktor bei der Entscheidung über die Zulassung, Sperrung oder weitere Prüfung einer Transaktion angesehen werden.

Sobald ein akzeptabler Grad an „Vertrauen“ in die an einer Transaktion beteiligten Akteure hergestellt ist, verlangt der Zero-Trust-Ansatz, dass dem Akteur (in der Regel dem Anfragenden, dem Wer) nur jene Mindestberechtigungen gewährt werden, die er benötigt, um das zu tun, was er in diesem System erreichen soll. Dieses Prinzip verkörpert ein sogenanntes „positives Sicherheitsmodell“ – einen Ansatz, bei dem alle Aktionen standardmäßig verboten sind und bestimmte Rechte nur dann gewährt werden, wenn sie für den Systembetrieb erforderlich sind. So kann es beispielsweise sein, dass ein Reservierungssystem anonymen Benutzern das Durchsuchen der Flugpläne gestattet, dass aber anonyme Benutzer nach den Anforderungen des Anwendungsentwurfs keinen Flug buchen dürfen.

Diese Berechtigungen können für einzelne Akteure oder Gruppen von Akteuren gelten. In der Regel sind Anwendungsnutzer entweder menschliche Akteure oder Proxys anstelle von Menschen, und sie werden in Klassen wie „anonyme Nutzer“, „Kunden“, „Partner“ oder „Mitarbeiter“ eingeteilt. Für die weniger vertrauenswürdigen Akteurklassen liegt die Schwelle der zu erreichenden Vertrauenswürdigkeit in der Regel niedriger, wenn es darum geht, die Authentifizierung zu bestehen, doch können sie auch auf weniger oder nur auf weniger sensible APIs zugreifen. „Interne“ Akteure, die zur Anwendung oder ihrer Infrastruktur gehören, wie z. B. bestimmte Dienste oder Container innerhalb einer Anwendung, verfügen oft über individuell angepasste Berechtigungen, wie z. B. „Nur Container und dürfen auf die Datenbank zugreifen, nur darf in den Objektspeicher schreiben, aber und dürfen darin lesen“.

Eine wichtige Überlegung bei der Umsetzung des „Least Privilege“-Prinzips ist das Bestreben, es auf maßgeschneiderte Weise und mit Voraussicht anzuwenden.⁷ Anstatt eine allgemeine Reihe von Berechtigungen für alle Akteure oder eine Klasse von Akteuren gelten zu lassen, sollte eine ausgereifte Zero-Trust-Implementierung das Augenmerk verstärkt darauf legen, welche Aktion durchgeführt werden soll. Sehr „grobkörnig“ betrachtet kann z. B. die Berechtigung „Zugriff auf Dateisystem“ gewährt werden, während „Lesezugriff auf das Dateisystem“ eine genauere Spezifikation des tatsächlich erforderlichen Rechts ist, was zu einer qualitativ hochwertigen Umsetzung des positiven Sicherheitsmodells führt.

Schließlich können anspruchsvollere Versionen des „Least Privilege“-Prinzips in Verbindung mit ausgereiften Implementierungen der „eindeutigen Verifizierung“ so funktionieren, dass die einem Akteur eingeräumten Rechte nicht als absolut betrachtet werden, sondern stattdessen als abhängig von der mit der Authentifizierung einhergehenden Vertrauenswürdigkeit. Somit werden Berechtigungen nur dann gewährt, wenn das Vertrauen in die bescheinigte Identität (Wer) einen Mindestschwellenwert erreicht, wobei die Schwellenwerte von der jeweils angestrebten Aktion abhängen. So kann beispielsweise eine besonders folgenreiche Aktion (z. B. das Herunterfahren des Systems) ein Vertrauen von 90 % oder mehr in die Tatsache erfordern, dass der Akteur ein Administrator ist. Falls in diesem Beispiel zu dem Zeitpunkt, zu dem die Abschaltung versucht wird, das Vertrauen des Systems in die Identität nur 80 % beträgt, würde das System eine zusätzliche Verifizierung verlangen, um das Vertrauen in die bescheinigte Identität zu erhöhen, bevor die Aktion zugelassen wird.

Die eindeutige Verifizierung und das „Least Privilege“-Prinzip sind Schlüsselkonzepte; der Grundsatz der kontinuierlichen Bewertung trägt jedoch dem Umstand Rechnung, dass diese Prinzipien kontinuierlich bewertet werden müssen:

1. Sämtliche Transaktionen erfordern eine Verifizierung und eine Berechtigung. Mit anderen Worten: Es darf nicht vorkommen, dass nur eine Teilmenge von Transaktionen einer Überprüfung unterzogen wird – etwa „die erste Transaktion in einer Benutzersitzung“ oder „jene Transaktionen, die über Docker-Container-Workloads initiiert werden“. Auch wenn dies selbstverständlich klingt, werden bei vielen Zero-Trust-Implementierungen entweder aufgrund eines schlechten Konzepts oder wegen mangelnder Transparenz nicht alle Transaktionen überprüft. Ein weit verbreitetes Manko in diesem Bereich entsteht dadurch, dass der Zero-Trust-Ansatz nur auf externe, nicht aber auf interne Akteure angewandt und/oder davon ausgegangen wird, dass ein Zero-Trust-Urteil über einen längeren Zeitraum hinweg korrekt bleibt.
2. Die Schlüsselfaktoren bei der Bewertung – das Vertrauen in die Identität des Akteurs und die diesem Akteur gewährten Rechte – müssen als dynamisch und veränderlich angesehen werden. So kann beispielsweise das Vertrauen in eine Identität im Laufe der Zeit aufgrund von beobachteten Verhaltensweisen und Seitenband-Metadaten zu- oder abnehmen, und jede vertrauensbasierte Richtlinie muss sich daher auch dynamisch an das sich ändernde Vertrauen anpassen. Darüber hinaus kann eine durch die Richtlinie gewährte Berechtigungsschwelle etwas später widerrufen werden, oder die für eine Aktion erforderliche Mindestvertrauenswürdigkeit kann sich ändern. Auch wenn der Zeitrahmen für Richtlinienänderungen variieren kann – sie können langsam (im der zeitlichen Größenordnung menschlicher Verfahrensabläufe) oder schnell (über automatisierte Steuerungsagenten) vonstatten gehen – sollte das System in der Lage sein, dynamisch zu reagieren und diese Änderungen zu berücksichtigen.

Das letzte Prinzip beruht auf der Annahme hoch motivierter Gegner vor dem Hintergrund einer gesunden Paranoia. Konkret lautet die Prämisse: „Gehen Sie davon aus, dass Ihre Sicherheit verletzt wurde“. „Sicherheitsverletzung“ wird dabei definiert als „Transaktion, die (bei perfekter Kenntnis und Ausführung) hätte verweigert werden müssen, stattdessen aber zugelassen wurde“. Die Ursache für dieses Versehen kann in lückenhaften Kenntnissen bestehen (z. B. einem fälschlicherweise zu hoher Vertrauenswert, der sich aus einer Authentifizierung ergibt und auf unentdeckt gebliebene betrügerische Anmeldedaten zurückzuführen ist), oder auf eine eingeschränkte Implementierung (z. B. nicht ausreichend feinkörnige Spezifität der gewährten Berechtigungen, wie z. B. die Berechtigung „Netzwerkverbindung öffnen“ ohne die Möglichkeit, anhand des geografischen Standorts des Netzwerkziels zu differenzieren), oder das Versehen kann aus einer unvollständigen Zero-Trust-Implementierung resultieren (z. B. keine Anwendung des Zero-Trust-Ansatzes auf intern verwendete Open-Source-Komponenten, die Sicherheitslücken aufweisen).

Daher muss sich die Zero-Trust-Denkweise auch mit der Frage befassen, wie die Auswirkungen solcher Sicherheitsverletzungen am besten bewältigt bzw. minimiert werden können.

Die Umsetzung dieses Prinzips weist stärkere Abweichungen auf als die der anderen Prinzipien, läuft jedoch im Allgemeinen folgendermaßen ab:

• Zunächst werden alle Transaktionen ermittelt, die zwar nach den Richtlinien technisch zulässig, aber verdächtig erscheint. Obwohl der Begriff „verdächtig“ sehr kontextabhängig sein kann, gibt es dafür einige gängige Interpretationen: (a) anomale Transaktionen, die sich stark von den in der Vergangenheit beobachteten Verhaltensweisen unterscheiden, (b) Gruppen von Transaktionen, die für sich genommen normal, aber in ihrer Gesamtheit ungewöhnlich sind – beispielsweise kann das Lesen und Schreiben einer Datei üblich sein, aber das Lesen und Schreiben von 1000 Dateien pro Sekunde kann ungewöhnlich sein, oder (c) Aktionen, die mit einer unerwünschten und zuvor nicht beobachteten Auswirkung auf das System verbunden sind – ein Beispiel wäre ein Muster, bei dem eine bestimmte Transaktion eine Netzwerkverbindung zu einem TOR-Knoten öffnet oder die CPU-Last des Systems erheblich erhöht.
• Anschließend wird eine tiefer gehende Analyse durchgeführt, entweder in Form eines vollständig automatisierten oder eines gemischten, teils menschengesteuerten, teils ML-unterstützten Workflows, um festzustellen, ob diese Transaktionen ungültig sind. Werden diese Transaktionen als ungültig eingestuft, so müssen Abhilfemaßnahmen ergriffen werden. Dies kann entweder in Form einer allgemeinen Richtlinienaktualisierung erfolgen oder – als zusätzliche Entschärfungsebene – als „Auffangnetz“ für die anderen richtliniengesteuerten Abhilfemaßnahmen.

Wird der Ansatz der richtlinienbasierten Anpassungen gewählt, können die Anpassungen mithilfe aller verfügbaren statischen Richtlinieninstrumente vorgenommen werden. Ein Beispiel für eine richtlinienbasierte Anpassung wäre die Einschränkung der Zugriffskontrollberechtigungen für einzelne Transaktionen (d. h. es wird nicht mehr zugelassen, dass wer was gegenüber wem unternimmt) oder die Anwendung eines strengeren „Nachweisstandards“ (also das Erfordernis einer MFA oder eines höheren Vertrauenswerts) auf einen Akteur (oder eine Akteurklasse) zur Durchführung einer bestimmten Aktion.

Wird stattdessen der Ansatz einer zusätzlichen „Auffangnetz“-Schicht gewählt, kann auch diese Strategie entweder feinkörnig oder grobkörnig umgesetzt werden. Die feinkörnigste Strategie bestünde darin, genau jene und nur jene Transaktionen zu blockieren, die ein bestimmtes Risiko-Nutzen-Verhältnis überschreiten, obwohl diese Lösung auch die Möglichkeit bietet, für einzelne zulässige Transaktionen unannehmbare Latenzzeiten festzulegen, wenn die Implementierung zusätzliche Analysen erfordert. Stattdessen können grobkörnigere Strategien angewandt werden, z. B. die Sperrung künftiger Transaktionen eines bestimmten Akteurs in einer Sandbox oder sogar der vollständige Ausschluss des Akteurs aus dem System. In extremen Fällen können sogar noch gröbere Abhilfemaßnahmen – wie das Deaktivieren der Datei-Eingabe und -ausgabe – angemessen sein.

Natürlich ist unter ansonsten gleichen Bedingungen eine feinkörnigere Abhilfemaßnahme mittels Auffangnetzes im Allgemeinen vorzuziehen. Allerdings müssen aufgrund von Einschränkungen bei den verfügbaren Lösungstechnologien oft Kompromisse eingegangen werden, und ein grobmaschiges Auffangnetz ist in der Regel besser als gar keines. Wenn beispielsweise die grobkörnige Reaktion zur Abwehr mutmaßlicher Ransomware darin besteht, die Dateieingabe und -ausgabe zu deaktivieren, sind die Nebenwirkungen dieser Reaktion u. U. immer noch der Alternative vorzuziehen, dem Akteur zu erlauben, weiterhin ungehindert im System zu operieren, wenn man davon ausgeht, dass das Ergebnis der Untätigkeit ein durch Ransomware verschlüsseltes Dateisystem wäre.

Der beste Startzeitpunkt für eine sichere Anwendungsentwicklung nach dem Zero-Trust-Prinzip ist – wenig überraschend – der Anfang. Die Grundprinzipien, die eine Anwendung von Zero-Trust-Grundsätzen ermöglichen, sollten bereits in der Designphase der Anwendungsentwicklungsprozesse berücksichtigt werden. Daher muss jede Diskussion über eine operative Zero-Trust-Lösung, die in die CI/CD-Pipeline integriert wird, mit einem Verständnis dieser grundlegenden Elemente beginnen, die zu den wichtigsten Designüberlegungen gehören sollten.

Der Kern dieser grundlegenden Elemente sollte das gewünschte/beabsichtigte Verhalten der Interaktion von Systemverhaltensweisen erfassen, gekoppelt mit ausreichender Transparenz und Kontrolle, um Abweichungen zu erkennen und darauf zu reagieren. Die beabsichtigten Interaktionen werden verwendet, um die gewünschte Reihe von Aktionen (was) für jeden Akteur (wer) gegenüber den einzelnen Zielen (wem) zu definieren. Allerdings kann es Szenarien und Umgebungen geben, in denen die beabsichtigten Interaktionsmuster unbekannt sind. In solchen Fällen kann ein Unternehmen verstärkt auf Transparenz setzen, um die Reihe von geeigneten Interaktionen zu „entdecken“⁸, die es dann in Richtlinien festlegen kann.

Bei den heutigen ZTNA-Lösungen, die sich auf eine identitätsgesteuerte Kontrolle des Zugriffs auf die externen APIs einer Anwendung konzentrieren, sind beispielsweise Transparenz und Kontrolle der Authentifizierungs-APIs erforderlich. Im Zusammenhang mit der Cloud Workload Protection Platform (CWPP) erfordert die Erkennung, dass eine Container-Workload kompromittiert wurde, einen Einblick in die Aktionen der einzelnen Container, und zwar in Echtzeit, falls eine Abhilfe in Echtzeit erforderlich ist.

Nachfolgend finden Sie eine Liste von übergeordneten Kategorien in Verbindung mit grundlegenden Überlegungen, die in den Designprozess einfließen sollten, und zusätzliche Fragestellungen im Zusammenhang mit den einzelnen Schlüsselpunkten:

• Was sind die Blackbox-Schnittstellen – Eingänge und Ausgänge – des Systems?
  • Welche Benutzerklassen – Administratoren, authentifizierte Benutzer, nicht authentifizierte Benutzer, Partner – interagieren mit der Anwendung, und was müssen sie tun?
  • Erfolgt die gesamte Kommunikation über eine definierte API, oder gibt es eine Netzwerkkommunikation auf Rohdatenebene oder eine Kommunikation über einen Datenspeicher, wie eine Datenbank oder einen Objektspeicher?
    • Wie gut ist die API-Kommunikation in Bezug auf die Benutzer, die mit der API interagieren können, und die Beschränkungen für diese Interaktionen (z. B. Parametervorgaben, Ratenbegrenzungen usw.) definiert?
    • Werden bei jeder Netzkommunikation alle Daten verschlüsselt übertragen?
    • Falls es Rohdatenschnittstellen gibt (z. B. wenn Informationen zwischen dem Client und der Anwendung über einen Objektspeicher oder eine Datenbank ausgetauscht werden), gibt es dann Audit Logs zur Nachverfolgung, wer wann auf welche Informationen zugegriffen hat?
• In ähnlicher Weise stellt sich auf der internen „White-Box“-Ebene folgende Frage: Aus welchen einzelnen Diensten (einschließlich aller extern bereitgestellten Dienste) bestehen die Gesamtanwendungen und wie kommunizieren sie?
  • Wie kommunizieren diese Dienste? Welche API wird verwendet und welche Vorgaben (Rollen, Zugangskontrollen, Ratenbegrenzungen, Parameter usw.) gelten für diese Interaktionen?
    • Ähnliche Fragen wie die oben genannten stellen sich in Bezug auf die Formalität der API und die für sie geltenden Vorgaben sowie die Verschlüsselung der Kommunikation.
    • Bei der „internen“ Kommunikation (z. B. zwischen Workloads und Containern) kommen eher Shared-Memory- und dateisystembasierte Schnittstellen zum Einsatz; solche Schnittstellen sollten identifiziert werden.
• Über welche Kontrollmechanismen verfügt das System, um den Zugriff auf die Blackbox-Schnittstellen und internen Kommunikationswege zu begrenzen?
  • Gibt es eine Richtlinie, die vorgibt, wer (welche Rollen) bestimmte APIs aufrufen kann und was geschieht, wenn gegen die Richtlinie verstoßen wird? Und welche Mittel gibt es, um jede Art von missbräuchlicher API-Verwendung zu erkennen und zu entschärfen, wie etwa ungültige Parameter oder zu häufige Aufrufe? Können diese Richtlinien dynamisch auf der Grundlage kontextbezogener Eingaben von anderen Systemen aktualisiert werden?
  • Gibt es analog dazu Richtlinien, die die anderen Formen der Kommunikation zwischen den Workloads – Dateisysteme, Objektspeicher, Datenbanktabellen – in Bezug darauf einschränken, wer auf welche Dateien/Speicher/Tabellen zugreifen darf, und eine missbräuchliche Verwendung dieser Ressourcen verhindern (z. B. „WÄHLEN * aus “)?
• Über welche Transparenztools (Dashboards, Protokolle, Statistiken) verfügt das System, um den Zugriff auf die Blackbox-Schnittstellen und internen Kommunikationswege zu begrenzen?
  • Kann das System feststellen, wer zu welchem Zeitpunkt welche API aufruft? Werden diese Daten gespeichert, und wenn ja, für wie lange? Wie schnell (in Echtzeit, stündlich usw.) werden diese Daten zur Verfügung gestellt? Wie verwertbar sind die Daten – handelt es sich um ein unstrukturiertes Dateiprotokoll, eine strukturierte JavaScript Object Notation (JSON), die an einen Dienst zur Verwaltung von Sicherheitsereignissen und -vorfällen (SEIM) gesendet werden kann, oder um Daten, die in einer Big-Data-Datenbanktabelle erfasst werden?
  • Wie lauten die Antworten auf diese Fragen, wenn es um andere Kommunikationswege wie Speicher, Dateien, Objekte oder Datenbanken geht? Wer unternimmt was? Wie werden diese Daten offengelegt?
• Welche anderen Kontrollen und Möglichkeiten zur Einsichtnahme bietet das System über die Kommunikationswege hinaus, um eine Überbelegung oder einen Überverbrauch von Ressourcen zu verhindern?
  • Gewährt das System einen Einblick in die Ressourcenverbrauchsmetriken (CPU, Speicher, Bandbreite, Pod-Skalierung usw.)? Wenn ja, mit welcher Granularität, und wie verwertbar sind diese Daten?
  • Verfügt das System über Kontrollen oder Leitplanken für den Ressourcenverbrauch – Speicher-/CPU-/Datei-E/A-Grenzwerte pro Workload, eine Nachverfolgung der Systemaufrufe zur Prozesserstellung, Grenzwerte für das Hochskalieren und horizontale Skalieren von Pods oder Ratenlimits für APIs, die andere Dienste aufrufen?

Indem Sie diese Fragen ausdrücklich stellen, können Sie Lücken im Zero-Trust-Fundament aufspüren. Oftmals führt die bloße Frage in einem frühen Stadium der Entwicklung dazu, dass die Lücke mit minimalem zusätzlichem Entwicklungsaufwand behoben wird. Und wenn eine Lücke fortbesteht, hilft schon die Kenntnis der Lücke dabei, zusätzliche Sicherheitsschwerpunkte zu setzen oder anfällige Angriffsflächen zu identifizieren.

Diese Art, die Entwicklung im Vorfeld auf ihre Sicherheit hin zu analysieren, ist ein wesentlicher Bestandteil der Zero-Trust-Denkweise. Dennoch liegt der Zero-Trust-Schwerpunkt von heute darauf, was nach dem ursprünglichen Design passiert, und die meisten Unternehmen konzentrieren sich auf jene Zero-Trust-Aspekte, die nach dem Design zum Tragen kommen. Wenn man sich jedoch bereits in der Entwurfsphase Gedanken über eine effektive Implementierung des Zero-Trust-Prinzips macht, kann man verhindern, dass nach der Bereitstellung der Anwendung ein viel größerer inkrementeller Aufwand zum „Flicken der Löcher“ erforderlich ist.

Wie die Prämisse „Annahme einer Sicherheitsverletzung“ zeigt, muss ein Sicherheitsexperte davon ausgehen, dass ein hinreichend motivierter Angreifer es schafft, eine bösartige Transaktion auszuführen. Dabei handelt es sich um einen Fall von „Wer unternimmt was gegenüber wem“, der den Regeln der Richtlinie entspricht, aber in einer perfekten Welt nicht hätte zulässig sein dürfen. In solchen Fällen verlagert sich der Schwerpunkt auf einen wirksamen Auffangnetzmechanismus, der solche Fälle – in der Regel anhand von Beobachtungen von Transaktionsmustern und Systemnebeneffekten – aufspüren kann, wie im Abschnitt „Annahme einer Sicherheitsverletzung“ beschrieben.

Wie bei der Identität wird jedoch auch hier das Wissen darüber, ob eine bestimmte Transaktion bösartig ist oder nicht, niemals lückenlos sein. Daher sollte eine ideale Zero-Trust-Lösung, genau wie bei der Identität, einen „Vertrauenswert“ für die Rechtmäßigkeit der Transaktion angeben. Wenn beispielsweise ein Hintergrundprogramm 10 Sekunden lang das 10-fache der normalen Dateirate liest und schreibt, könnte dies zu einem Vertrauenswert (der Bösartigkeit) von 70 % führen. Steigt jedoch die Rate über eine Minute hinweg um das 100-fache an, könnte sich der Vertrauenswert auf 95 % erhöhen. In diesem Beispiel besteht immer noch eine gewisse Wahrscheinlichkeit (30 % oder 5 %), dass die Abhilfemaßnahme, nämlich das Unterbinden künftiger Schreibvorgänge, die falsche Reaktion ist – ein „falsch positives Ergebnis“. Daher muss bei der Entscheidung, ob Abhilfemaßnahmen ergriffen werden sollen oder nicht, das Risiko von falsch positiven Ergebnissen gegenüber den potenziellen Auswirkungen der Zulassung des möglicherweise bösartigen Verhaltens abgewogen werden.

Das Beispiel soll verdeutlichen, dass jede Entscheidung, eine für den Benutzer sichtbare Abhilfemaßnahme zu ergreifen, in Wirklichkeit eine geschäftliche Entscheidung ist, bei der alle mit der verdächtigen Aktivität verbundenen Risiken, Kosten und Vorteile berücksichtigt werden. Wird die Transaktion zusätzlich erschwert, so steigt die Wahrscheinlichkeit, dass der Wert nicht erreicht wird. Wird jedoch nicht eingegriffen, steigt das Risiko einer Kompromittierung. Daher hängt die Entscheidung, in solchen Fällen zu handeln (oder nicht), von drei Faktoren ab:

1. Welches Risiko besteht, wenn man möglicherweise bösartige Transaktionen weiter zulässt?
   Dieses Risiko kann sich direkt monetär niederschlagen, wie z. B. bei einer Überweisung von Bankguthaben, oder es kann indirekte Kosten verursachen, die entweder betrieblicher Art sind (etwa wenn wichtige Datensätze verschlüsselt werden und Lösegeld gefordert wird) oder das Markenimage betreffen (z. B. bei Verunstaltung einer Website). Es können auch Prozess- oder Compliance-Kosten entstehen, z. B. durch das Bekanntwerden von personenbezogenen Kundendaten. Im Wesentlichen ist die Zuweisung von Risiken eine Frage der Unternehmensführung, und eine gute Unternehmensführung wird die Risiken, die für eine Anwendung bestehen, erkennen und quantifizieren.


2. Was sind die Nebenwirkungen der Abhilfemaßnahme?
   Die Nebenwirkungen lassen sich anhand der Dimensionen (a) aufgebaute Reibung und (b) Druckwellenzone beschreiben. Die Reibung gibt an, um wie viel schwieriger es ist, eine rechtmäßige Transaktion durchzuführen; sie kann von etwas unangenehmer (z. B. durch eine zusätzliche Authentifizierungsstufe) bis hin zu unmöglich (die Transaktion wird einfach nicht zugelassen) reichen. Die Druckwellenzone bezieht sich darauf, ob andere eigenständige Transaktionen ebenfalls betroffen sind und wenn ja, wie viele. Die Sperrung eines bestimmten Benutzers wirkt sich beispielsweise nur auf diesen Benutzer aus, während die Abschaltung eines Protokollierungsdienstes die Prüfbarkeit für alle Benutzer und Transaktionen beeinträchtigt.


3. Wie groß ist das Vertrauen in die Annahme, dass die Transaktion bösartig ist?
   Der Aufbau von Vertrauen bedeutet in der Regel, dass mehr Datenpunkte gesammelt und mehr Datenquellen korreliert werden müssen. Da beides Zeit in Anspruch nimmt, lautet der Kompromiss in der Praxis oft: „Wie lange soll ich zusehen, bevor ich handle?“

Während also eine Zero-Trust-Strategie die Tatsache einkalkulieren muss, dass es zu Sicherheitsverletzungen kommen wird, folgt eine durchdachte Herangehensweise bei der Entschärfung von Transaktionen, die zwar erlaubt sind, aber verdächtig erscheinen, einem Risiko-Nutzen-Ansatz. Dabei werden das Risikoniveau der verschiedenen Anwendungstransaktionen und die Folgen der Abhilfemaßnahmen berücksichtigt und Abhilfemaßnahmen nur dann getroffen, wenn das Risikoniveau den erwarteten geschäftlichen Nutzen übersteigt.

¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

² https://csrc.nist.gov/publications/detail/sp/800-207/final

³ https://www.cisa.gov/zero-trust-maturity-model

⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

⁵ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁶ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁷ Die Vorüberlegungen beginnen bereits in der Entwurfsphase, wie später beschrieben.

⁸ Oder zumindest die Reihe der „vermeintlich angemessenen“ Interaktionen, die das System zu erfordern scheint. Es besteht immer das Risiko, dass die aus der Beobachtung abgeleitete Reihe der Interaktionen unvollständig oder mit einem bereits bestehenden Risiko behaftet sein könnte. Daher ist eine vorausschauende Entwurfsplanung stets vorzuziehen.