Zero-Trust-Sicherheit: Warum Zero Trust wichtig ist (und zwar nicht nur für den Zugriff)

Eines der wichtigsten Themen im Netzwerk- und Anwendungszugriff der letzten Jahre war das Konzept „Zero Trust“.  In diesem Dokument zeigen wir, wie Zero Trust im Kern durch eine Reihe einfacher Überzeugungen charakterisiert werden kann, die nicht nur auf den Zugang, sondern auch im gesamten Bereich der Cybersicherheit angewendet werden können. 

Dieses Dokument stellt einen Rahmen vor, der die allgemeinen Konzepte rund um Zero Trust umfasst und sie mit dem bestehenden Geschäftshintergrund in Beziehung setzt, der die heutigen Führungskräfte im Bereich Anwendungssicherheit motiviert.  Abschließend liefert dieses Dokument eine Charakterisierung des Zero-Trust-Glaubenssystems – der treibenden Kraft für die Tools und Sicherheitsimplementierungen zur Bewältigung der aktuellen und aufkommenden Bedrohungen, die im Mittelpunkt eines Folgedokuments stehen werden.

Dieses Dokument verfolgt zwei Ziele: Erstens möchte ich die Sicherheitsmentalität vermitteln, die sich Führungskräfte im Anwendungsgeschäft aneignen sollten, und zweitens möchte ich einen Rahmen für Sicherheitsexperten einführen, auf den wir in zukünftigen Whitepapers näher eingehen werden. 

Der Begriff „Zero Trust“ wird mit einer Reihe verschiedener Konzepte auf unterschiedlichen Abstraktionsebenen in Verbindung gebracht: manchmal als bestimmte Lösungsarchitektur, manchmal als Vorschrift zur Anwendung bestimmter Technologien und manchmal auch, wenn er sich auf eine Eigenschaft eines Produktes bezieht.  Wir sind davon überzeugt, dass Zero-Trust-Sicherheit im Kern eine Geisteshaltung – ein Glaubenssystem – ist, aus dem Techniken und Taktiken hervorgehen und bestimmte Technologien nutzen, die dann zur Bewältigung eines breiten Spektrums von Sicherheitsbedrohungen eingesetzt werden können.

Das Glaubenssystem, das Zero Trust Security (ZTS) zugrunde liegt, kann als nächster Schritt in der Entwicklung einer Sicherheitsmentalität angesehen werden, die vor Jahren mit der „Defense in Depth“ begann.  Die tiefgreifende Verteidigung basiert auf der Annahme, dass jede einzelne Verteidigungsbarriere zwar eine gewisse kleine, aber reale Wahrscheinlichkeit eines Durchbruchs birgt, das Hinzufügen zusätzlicher Schutzebenen für wichtige Ressourcen diese Wahrscheinlichkeit jedoch verringert. Dadurch werden die Angreifer verlangsamt und sind gleichzeitig gezwungen, für einen erfolgreichen Angriff mehr Ressourcen aufzuwenden.

Zero Trust ist eine Weiterentwicklung dieser Denkweise in drei Dimensionen:

• Erstens entwickelt es das Schutzkonzept von einer Reihe einfacher „Filter“, die den Zugriff auf die Anwendung beschränken, zu einem Satz von Schutzmechanismen weiter, die besser auf die einzelnen Assets abgestimmt sind und kontextbezogen auf alle Systemtransaktionen angewendet werden .  Die Grundhaltung bei jeder Transaktion besteht darin, zu verstehen:  Wer versucht welche Aktion bei wem ?  Das „Wer“ und „Wen“ kann jede beliebige Komponente innerhalb des Systems oder die das System verwendende Komponente sein, sei es menschlich, automatisiert oder ein Codestück.  Das Konzept der Identität ist entscheidend für das Wer und Wen , und das Konzept der einer Identität gewährten Privilegien wird verwendet, um zu kodifizieren, was getan werden kann.
• Zweitens wird die Bewertung der Sicherheitsentscheidungen nicht als statisch und absolut betrachtet, sondern als dynamischer und anpassungsfähiger , der im Lichte beobachteter Verhaltensweisen kontinuierlich neu bewertet werden muss.  Bei der Entscheidung über die Handhabung der einzelnen Transaktionen – ob die Interaktion zugelassen, blockiert oder das Vertrauen gestärkt werden soll usw. – muss auch der breitere Geschäftskontext und insbesondere das Verhältnis von Risiko und Ertrag berücksichtigt werden.
• Und schließlich wird davon ausgegangen, dass ein ausreichend motivierter oder glücklicher Angreifer die Schutzmechanismen entweder durchbrechen oder umgehen wird , egal wie viele Schutzebenen vorhanden sind. Deshalb müssen auch die rechtzeitige Erkennung jeglicher Kompromittierung und die Eindämmung von Angriffsversuchen ein zentraler Bestandteil der Gesamtstrategie sein.

Diese Entwicklung ist zum Teil das Ergebnis von Zeit und Erfahrung, wird jedoch zunehmend durch das Zusammentreffen zweier anderer Trends in der Anwendungssicherheit vorangetrieben.  Insbesondere eröffnen die heutigen Anwendungsarchitekturen einen viel größeren potenziellen Raum für Anwendungsschwachstellen – vor allem Bedrohungen „innerhalb“ der Anwendungsinfrastruktur –, die von den immer raffinierteren Angreifern von heute ausgenutzt werden können.  Glücklicherweise haben gleichzeitige Fortschritte bei Sicherheitstools – insbesondere in Verbindung mit modernen Datenerfassungs- und Analysefunktionen – die praktische Umsetzung wichtiger Komponenten der Verteidigungsstrategie ermöglicht.

Der Rest dieser Einführung bietet einen Überblick über das Framework für unseren Ansatz zur Zero-Trust-Sicherheit sowie dessen Umfang.  Von dort aus werden in den folgenden Abschnitten die Problemstellung und ihre Beziehung zu anderen zeitgenössischen Ansätzen für Zero Trust vertieft und es kommt zu einer Diskussion der Grundüberzeugungen – des „Warum“ –, die die Auswahl der Lösungstechnologien und ihre Anwendung leiten sollten.  Zukünftige Beiträge werden sich mit dem „Wie“ befassen – den Anforderungen, die an bestimmte Technologien wie Authentifizierung, Zugriffskontrolle und KI-gestützte Analytik im Zusammenhang mit dem Zero-Trust-Reifegradmodell gestellt werden.

Der „Start with Why“-Ansatz von Simon Sinek ist ein wirksames Tool zur Kommunikation des ZTS-Frameworks, wie in Abbildung 1 unten dargestellt.  Sie können diese Grafik von außen nach innen betrachten, indem Sie mit den Bedrohungsklassen beginnen, die ZTS behandelt, dann tiefer in die verwendeten Sicherheitsmethoden einsteigen und schließlich alles auf gemeinsame Prinzipien herunterbrechen.  Oder Sie betrachten das Ganze von innen nach außen und sehen dabei die Grundüberzeugungen als Nordstern, aus dem sich die entsprechenden Tools und Techniken ergeben, die Sie dann in die Lage versetzen, ein breites Spektrum an Bedrohungen anzugehen.

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

Spätere Abschnitte befassen sich mit den einzelnen konzentrischen Schichten dieses Diagramms, aber kurz zusammengefasst:

• Die Grundüberzeugungen dieses Ansatzes ergeben sich aus der Formulierung des Anwendungsfalls wie folgt:
  „Wer versucht was (Handlung) bei wem?“
  • Um das Wer und Wen festzustellen, müssen Sie sämtliche Identitätsnachweise explizit überprüfen .
  • Nachdem Sie festgelegt haben, wer ausgeführt werden kann, verwenden Sie das Prinzip der geringsten Privilegien, um einzuschränken, was ausgeführt werden kann.
  • Bewerten Sie alle drei Faktoren ( Wer, Was und Wem) kontinuierlich und bewerten Sie sie erneut, und validieren Sie sie fortlaufend hinsichtlich der Richtlinienbeschränkungen.
  • Gehen Sie immer davon aus, dass es zu Verstößen und Kompromissen kommen wird . Seien Sie darauf vorbereitet, einzugreifen, wenn die Aktion ( Was für wen ) basierend auf einer Risiko-Nutzen-Analyse (der Wahrscheinlichkeit eines Betrugs bei der Authentifizierung, gewichtet nach den geschäftlichen Auswirkungen einer fehlerhaften Transaktionsgenehmigung) einen vorab festgelegten akzeptablen Sicherheitsschwellenwert überschreitet.
• Die verwendeten Methoden sind:
  • Authentifizierung und Zugriffskontrolle, um mit einer bestimmten Vertrauensebene das „Wer“ zu bestimmen und dann die Berechtigungen hinsichtlich der „Was“ (Aktionen) einzuschränken, die dieser Identität in Bezug auf ein bestimmtes „Wer“ -Ziel gestattet werden sollten.
  • Sichtbarkeit und ML-gestützte Analyse zur Beobachtung und kontinuierlichen Bewertung des vollständigen Kontexts jeder Transaktion – Wer tut was mit wem?
  • Automatisierte, risikobewusste Abhilfemaßnahmen zur Intervention bei einer Transaktion wenn das Risiko-Ertrags-Niveau über die angegebene Toleranzschwelle steigt.
• Bekämpfen Sie ein breites Spektrum an Cyberangriffen mit diesen Methoden:
  • Traditionelle Angriffe wie Defacement oder Datenexfiltration – Sie können Diese Angriffe können durch Erkennung von Identitätsdiebstählen oder Rechteausweitungen verhindert werden, indem Authentifizierungs- und Zugriffskontrolltechniken eingesetzt werden, um per Richtlinie einzuschränken, wer was tun darf.
  • Verfügbarkeits-/DDoS-Angriffe : Bekämpfen Sie diese Angriffe, indem Sie Authentifizierung und Zugriffskontrolle mit risikobewusster Abhilfe kombinieren.  Beispielsweise blockieren Sie den Zugriff für nicht oder unzureichend authentifizierte Akteure, die ressourcenintensive Transaktionen versuchen (oder begrenzen die Zugriffsrate).
  • Erweiterte Bedrohungen wie Ransomware oder Angriffe auf die Lieferkette : Sie können diesen Bedrohungen begegnen, indem Sie Änderungen und Anomalien im Verhalten der Personen erkennen , die was wem antun. Auch hier können Sie entsprechende risikobewusste Abhilfemaßnahmen ergreifen.

Die Zero-Trust-Sicherheit erstreckt sich ganzheitlich auf die gesamte Anwendung, Infrastruktur und den Bereitstellungsstapel und sollte die komplette Entwicklungspipeline umfassen. Genauer gesagt sollte dies Folgendes umfassen:

• Vollständiger Anwendungs- und Infrastruktur-Stack von oben bis unten
  • Hardware-Rechnersubstrat, einschließlich Server, Netzwerkschnittstellenkarten, Co-Prozessoren und Systemplatinenkomponenten
  • Low-Layer-Firmware und BIOS für die Hardware.
  • Das Betriebssystem der untersten Schicht, beispielsweise der Hypervisor oder die Runtime Executive.
  • Das Anwendungsebenen-/Container-Betriebssystem .
  • 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 wird für die laufende Wartung und Aktualisierung jedes einzelnen Stapelelements „von oben nach unten“ verwendet.
  • Alle Inline-Komponenten zur Anwendungsbereitstellung, wie Firewalls, Lastenausgleichsmodule, API-Gateways, Ingress-/Egress-/Mesh-Controller und Inline-Geräte zur Betrugsbekämpfung.
  • Alle Anwendungsbereitstellungskomponenten, die sich indirekt auf die Datenverkehrsabwicklung auswirken, z. B. DNS-Resolver (Domain Name System), oder die indirekt Metadaten empfangen, z. B. SIEM-Lösungen (Security Information Event Management) oder föderierte Identitätsdienste.

Traditionell richtet sich der Schwerpunkt von Zero Trust auf Anwendungsentwicklungs- und Bereitstellungsteams, die oft als die Personas von Dev, DevOps, DevSecOps und SRE erfasst werden.  Wir weisen in erster Linie darauf hin, um das Gesamtbild zu berücksichtigen; nämlich dass ein umfassender Ansatz für Zero Trust idealerweise nicht-traditionelle Personas und Infrastrukturen sowie zusätzliche Arbeitsabläufe, wie etwa die Beschaffungsstrategie für die Lieferkette, umfassen sollte.

Eine der obersten Prioritäten für CIOs und CISOs besteht darin, die Informationstechnologie zu modernisieren, um das Geschäft voranzutreiben.  Darüber hinaus spielen sie eine Schlüsselrolle bei der Risikosteuerung von Unternehmen.  Ihr Ziel besteht darin, dem Unternehmen dabei zu helfen, die Kunden mit neuen digitalen Erlebnissen zu begeistern, die Betriebseffizienz durch digitale Konnektivität mit Drittanbietern zu steigern und den Mitarbeitern ortsunabhängige Produktivität zu ermöglichen, bei gleichzeitiger Minimierung des Geschäftsrisikos. Dies erfordert von den CIO- und CISO-Organisationen, ihren Mitarbeitern die Möglichkeit zu geben, die neuesten Technologien, Architekturen und Best Practices für mehr Agilität zu nutzen, und sie gleichzeitig mit der Aufgabe zu beauftragen, geeignete Sicherheitsmaßnahmen zu ergreifen und Kontrollen über das Verhalten der Benutzer, die von ihnen abgerufenen Informationen und die von ihnen verwendete Technologie einzurichten, um Verluste zu vermeiden. 

Organisationen müssen die Risiken verstehen und kontrollieren, die mit Veränderungen der Markt- und makroökonomischen Bedingungen, des Verbraucherverhaltens, der Lieferkette und der Sicherheitsrisiken verbunden sind.  Eine genaue Risikobewertung und die Fähigkeit, rasch Maßnahmen zur Risikominderung zu ergreifen, sind für Unternehmen ein Wettbewerbsvorteil.  In diesem Dokument konzentrieren wir uns auf die Risiken von Sicherheitslücken, die unter anderem zum Verlust geistigen Eigentums, zur Unterbrechung von Geschäftsprozessen, zum Verlust personenbezogener Daten und zu Geldbußen durch Aufsichtsbehörden führen können.  Das Sicherheitsrisiko kann durch die Bewertung der folgenden Aspekte einer betrachteten Situation berechnet werden:

1. Wert der beteiligten Vermögenswerte
   Die an den Transaktionen beteiligten Vermögenswerte haben unterschiedliche Bedeutungsgrade. Beispielsweise ist eine Datenbank mit personenbezogenen Daten wertvoller als eine Datenbank mit Einzelhandelsstandorten, die Produkte des Unternehmens führen.  Sicherheits- und IT-Teams können mithilfe eines deterministischen Prozesses ein Inventar aller Vermögenswerte erstellen und diese anhand einer Punktzahl kategorisieren, die den „Wert“ des Vermögenswerts darstellt.


2. Auswirkungen eines Kompromisses
   Die Art des Kompromisses bestimmt die damit verbundenen Auswirkungen.  Beispielsweise sind die Auswirkungen des Diebstahls von Informationen im Datenspeicher, die personenbezogene Daten enthalten, weitaus schwerwiegender als eine Unterbrechung der Verfügbarkeit des Datenspeichers.  Obwohl dies etwas nebulöser ist, ist es möglich, verschiedene Arten von Kompromissen aufzulisten und ihnen einen „Auswirkungs“-Score zuzuweisen.


3. Wahrscheinlichkeit eines Kompromisses
   Die Wahrscheinlichkeit, dass eine Transaktion zur Gefährdung eines Vermögenswerts führt, ist der am wenigsten deterministische Faktor bei der Beurteilung des mit der Transaktion verbundenen Risikos.  Menschen sind nicht in der Lage, den Umfang der erforderlichen Beobachtungen zu bewältigen. Daher setzen Unternehmen maschinelles Lernen und künstliche Intelligenz ein, um die Zuverlässigkeit ihrer Berechnungen zur Wahrscheinlichkeit eines Kompromisses zu erhöhen.

Die Herausforderung besteht darin, das mit jeder einzelnen Transaktion verbundene Risiko nahezu in Echtzeit zu berechnen und geeignete Risikominderungsmaßnahmen zu ergreifen, um die Auswirkungen eines möglichen Kompromisses zu kontrollieren.

Abbildung 2 – Geschäftsdruck führt zu neuen Vorgehensweisen, was wiederum zu erhöhten Risiken führt.

1. Anforderungen an die Geschäftsbeschleunigung
   1. Digitale Erlebnisse
      Verbraucher haben ein unstillbares Verlangen nach digitalen Erlebnissen und fordern häufige Verbesserungen auf mehreren Plattformen (PC, Tablet, Mobiltelefone).
   2. Vernetztes Geschäft
      Digitale Geschäftsprozesse erfordern die Konnektivität mit Partnern, Anbietern, Distributoren und Diensten anderer Unternehmen.
   3. Mobile Mitarbeiter
      Um eine effiziente Ausführung zu gewährleisten, müssen Mitarbeiter von überall auf Geschäftsanwendungen zugreifen können.


2. Vorgehensweisen zur Erfüllung geschäftlicher Anforderungen
   1. Agile Entwicklungsmethodik
      Unternehmen wechselten vom sequentiellen Wasserfallansatz, bei dem die pünktliche Projektlieferung im Mittelpunkt steht, zu einem inkrementellen, iterativen Agile-Entwicklungsansatz mit starkem Fokus auf Kundenzufriedenheit.
   2. Einsatz vorgefertigter Software
      Um möglichst schnell neue digitale Erlebnisse bereitzustellen, verwenden Entwickler Code erneut, der von ihren Kollegen in der Branche als Open Source bereitgestellt wurde.
   3. Auftragsentwicklung
      Durch das Outsourcing von Arbeit an Vertragsentwickler können Unternehmen ihre Belegschaft je nach Bedarf skalieren.
   4. Nutzung der Cloud-Infrastruktur
      Die Agilität, Flexibilität und Skalierbarkeit der Cloud sowie ihre Benutzerfreundlichkeit ermöglichen es Entwicklern, bei Bedarf auf die benötigte Infrastruktur zuzugreifen.
   5. Einführung von SaaS
      Software as a Service (SaaS) ist für Geschäftsbetriebsanwendungen vorteilhaft, da dadurch 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 schnellerer Markteinführung zu erreichen.
   7. Verteilte Anwendungskomponenten
      Organisationen erreichen Effizienz, indem sie Microservices in einer Infrastruktur ausführen, die die besten Tools zum Entwickeln oder Bereitstellen der Servicefunktionalität bietet. Aktuelle Erweiterungen älterer Workflows erfolgen mithilfe moderner Anwendungsarchitekturen, die mit den älteren Elementen kommunizieren müssen. Beide laufen häufig auf unterschiedlicher Infrastruktur.
   8. Offene APIs
      Ein Ökosystem aus verschiedenen Diensten ist effizienter als ein Unternehmen, das alle Dienste selbst entwickelt.
   9. Netzwerkkonnektivität mit Drittanbietern
      Unternehmen vernetzen sich über verschlüsselte Tunnel mit ihren Partnern, Anbietern und Distributoren, um Geschäftsprozesse zu automatisieren und zu optimieren.


3. Erhöhtes Sicherheitsrisiko
   1. Größere Angriffsfläche
      Die Verwendung von Software von Drittanbietern und Open-Source-Bibliotheken schafft Möglichkeiten für Supply-Chain-Angriffe und sämtliche Schwachstellen extern entwickelter Software werden übernommen.  Vertragsentwickler sind motiviert, die Funktionalität rechtzeitig fertigzustellen und kümmern sich nicht um die Sicherheit.  Darüber hinaus ist es für interne Teams nach der Auslieferung der Software und dem Beenden des Projekts schwierig und zeitaufwändig, den Code durchzugehen und Sicherheitslücken zu finden. Agile Sprints sind bei der Bereitstellung von Funktionsfunktionen sehr effizient, die erhöhte Entwicklungsgeschwindigkeit lässt jedoch nicht viel Zeit für detaillierte Sicherheitsprüfungen und Tests.  Ein anfälliger Microservice, der mit anderen Microservices kommunizieren kann, erhöht das Sicherheitsrisiko für das gesamte System.

      Zwar verbessern vernetzte Unternehmen ihre Betriebseffizienz, doch eine schwerwiegende Konsequenz kann sein, dass Sicherheitslücken in einem dieser Unternehmen sich auf alle auswirken.  Angreifer finden das schwächste Glied und breiten sich dann über die übrigen Glieder aus. 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. Erhöhte architektonische Komplexität
      Verteilte Anwendungselemente, die mit unterschiedlichen Architekturen entwickelt und auf mehreren Infrastrukturen bereitgestellt werden, haben unterschiedliche Sicherheits- und Compliance-Anforderungen.  Dies erschwert den Sicherheitsteams die Entwicklung und Bereitstellung geeigneter Mechanismen zur Sicherung von Unternehmensanwendungen und -daten sowie zur Einhaltung gesetzlicher Compliance-Anforderungen.
      
   3. Gut finanzierte, hoch motivierte und erfahrene Hacker
      Von der Operation Aurora im Jahr 2010 bis zum Solargate-Skandal im Jahr 2020 haben wir ein Jahrzehnt hochentwickelter Cyberangriffe erlebt, die erst entdeckt werden, wenn sie bereits großen Schaden angerichtet haben.  Die Sicherheitsverletzungen ereigneten sich in Organisationen, die mit der besten Sicherheitstechnologie ausgestattet waren und von hochqualifizierten Sicherheitsteams bedient wurden.  Angreifer konnten sich lange Zeit in der IT-Infrastruktur dieser Organisationen festsetzen, bevor sie entdeckt wurden.  Geistiges Eigentum und personenbezogene Daten wurden gestohlen, der Geschäftsbetrieb wurde gestört und Unternehmen gerieten in die Schusslinie von Ransomware, obwohl die IT- und Sicherheitsteams weit über die Einhaltung der Vorschriften zur Abwehr von Cyberangriffen hinausgingen.

Nach einer Flut anhaltender Cyberangriffe auf verschiedene US-Bundes-, Landes- und Kommunalbehörden sowie mehrere US-Unternehmen erließ Präsident Joe Biden am 12. Mai 2021 eine Durchführungsverordnung zur Verbesserung der Cybersicherheit des Landes .  Eines der Kernelemente dieser Anordnung besteht darin, dass Regierungsbehörden das Zero-Trust-Prinzip anwenden, um sich auf Cyberangriffe vorzubereiten. Die Biden-Administration folgte dieser Anordnung mit einem Memorandum des Office of Management and Budget (OMB) für die Leiter der Exekutivministerien und -behörden am 26. Januar 2022.  Dieses Memorandum des OMB „legt eine Strategie für eine bundesstaatliche Zero-Trust-Architektur (ZTA) fest, die von den Behörden verlangt, bis zum Ende des Haushaltsjahres (FY) 2024 bestimmte Standards und Ziele im Bereich Cybersicherheit zu erfüllen, um die Abwehrmaßnahmen der Regierung gegen zunehmend ausgefeilte und hartnäckige Bedrohungskampagnen zu stärken.“¹  Sowohl die Executive Order als auch das OMB-Memorandum beziehen sich auf die in der im August 2020 veröffentlichten Veröffentlichung SP 800-207 des National Institute for Standards and Technology (NIST) beschriebene Zero-Trust-Architektur und verpflichten Regierungsbehörden, diese einzuhalten.

Vordenker in Regierungsbehörden und im privaten Sektor haben Dokumente veröffentlicht, die die Zero-Trust-Architektur erklären und Ratschläge für ihre optimale Einführung geben. Nachfolgend fassen wir die in diesen Dokumenten enthaltenen Ideen zusammen. Wir weisen darauf hin, dass der entscheidende Kern der in diesen Dokumenten enthaltenen Ideen und Vorschläge darin besteht, jede Transaktion zu untersuchen, um zu ermitteln, wer welche Aktion bei wem versucht, und auf Grundlage der Berechnung des mit der Transaktion verbundenen Risikos in Echtzeit zu entscheiden, ob die Transaktion zugelassen oder verboten wird.

Das NIST-Team zählt die Grundsätze von Zero Trust auf und definiert eine abstrakte Zero-Trust-Architektur (ZTA) in seinem Dokument NIST SP 800-207.² Darüber hinaus diskutieren sie Variationen von Zero-Trust-Ansätzen und beschreiben unterschiedliche Möglichkeiten zur Bereitstellung der abstrakten Architektur.

Die wichtigsten Abstraktionen, die in diesem Dokument erörtert werden, sind der Policy Decision Point (PDP) und der Policy Enforcement Point (PEP), die zusammenarbeiten.  Der Policy Decision Point besteht aus der Policy Engine (PE) und dem Policy Administrator (PA).  Die Policy Engine verwendet einen Vertrauensalgorithmus, um zu entscheiden, ob einem Subjekt Zugriff auf eine Ressource gewährt werden soll.  Diese Entscheidung wird vom Richtlinienadministrator ausgeführt, der mit dem Richtliniendurchsetzungspunkt kommuniziert, um eine neue Sitzung zuzulassen oder zu untersagen bzw. eine bestehende Sitzung zu ändern oder zu beenden. Darüber hinaus werden in dem Dokument Variationen des Vertrauensalgorithmus, Netzwerkkomponenten für eine Zero-Trust-Umgebung sowie verschiedene Anwendungsfälle bzw. Bereitstellungsszenarien diskutiert.  Abschließend wird über Möglichkeiten nachgedacht, wie Angreifer die Zero-Trust-Architektur vereiteln können, sodass die Implementierer sich der Bedrohungen bewusst sind und geeignete Maßnahmen zum Schutz ihrer Zero-Trust-Architekturkomponenten ergreifen.

Mit dem Ziel, Agenturen 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 im Dokument NIST SP 800-207 beschrieben wird.  Die Autoren haben fünf Bereiche identifiziert und empfehlen, dass Organisationen in jedem dieser Bereiche konsequent Fortschritte bei der Umsetzung der Zero-Trust-Prinzipien machen.  Die Bereiche sind (i) Identität, (ii) Gerät, (iii) Netzwerk, (iv) Anwendungsarbeitslast und (v) Daten.  Sie empfehlen den Einsatz von Sichtbarkeit und Analyse sowie Automatisierung und Orchestrierung in jedem der fünf Bereiche.

Das Dokument bietet ein Reifegradmodell auf hoher Ebene für alle fünf zuvor identifizierten Grundpfeiler von Zero Trust und geht dann tiefer auf jeden Bereich ein.  Organisationen können das Reifegradmodell verwenden, um ihren aktuellen Zustand zu verstehen und einen iterativen Kurs in Richtung des optimalen Zustands festzulegen.

Nach der Entdeckung der SolarWinds-Angriffe veröffentlichte die National Security Agency (NSA) in ihrem Dokument „Embracing a Zero Trust Security Model“ Richtlinien, in denen sie Cybersicherheitsteams rät, ein Zero-Trust-Sicherheitsmodell einzuführen.⁴  Experten des gemeinsamen Zero-Trust-Engineering-Teams der Defense Information Systems Agency (DISA) und der National Security Agency haben die Zero-Trust-Referenzarchitektur des Department of Defense (DOD) entwickelt.⁵  Die Autoren drücken die Notwendigkeit der Einführung von Zero Trust mit der folgenden Aussage aus: „Durch Datenschutzverletzungen innerhalb und außerhalb des US-Verteidigungsministeriums aufgedeckte Schwachstellen zeigen, dass ein neues und robusteres Cybersicherheitsmodell erforderlich ist, das gut informierte, risikobasierte Entscheidungen ermöglicht.“⁶

Die Empfehlungen dieser Referenzarchitektur basieren auf den im Dokument „Zero Trust Architecture“ NIST SP 800-207 definierten Abstraktionen.  Das Dokument stellt ein allgemeines Betriebsmodell vor und beschreibt dessen Elemente im Detail.  Es umfasst außerdem ein Reifegradmodell auf hoher Ebene und die Abbildung von Möglichkeiten zur Anwendung von Zero-Trust-Prinzipien auf verschiedene Interessensbereiche.  Zusammen helfen diese Dokumente den Organisationen, ihren aktuellen Zustand einzuschätzen und einen Plan zu entwickeln.

Eine Haltung, die „von Verstößen ausgeht“ und die Befolgung von Zero-Trust-Prinzipien kann Organisationen bei ihren Risikomanagement- und Governance-Praktiken helfen.  Die Zero-Trust-Prinzipien der „kontinuierlichen Überwachung“ und „expliziten Überprüfung“ der an Transaktionen beteiligten Akteure ermöglichen es Organisationen, einen dynamischen Risiko-Score für alle Akteure und ihre Aktivitäten zu erstellen. Dies steht im Einklang mit der Empfehlung von Gartner, zur Verbesserung bestehender Sicherheitsprogramme die Methode der „kontinuierlichen adaptiven Risiko- und Vertrauensbewertung“ (CARTA) zu verwenden.  Durch die Umsetzung des Prinzips, nur den Zugriff auf Ressourcen mit den geringsten Privilegien zuzulassen, verringert sich das Verlustrisiko selbst im Falle einer Sicherheitsverletzung.  Durch kontinuierliche Überwachung und explizite Überprüfung generierte Informationen sind auch für die Erstellung von Compliance-Berichten hilfreich.

Dieser Abschnitt konzentriert sich auf die Denkweise – das Glaubenssystem, das „Warum“ –, die die Strategie und Entscheidungen in Bezug auf die Tools und das Design motiviert, die ein Unternehmen für Zero-Trust-Sicherheit übernehmen sollte.  Tatsächlich kann man die Impulse für alle Methoden und Komponententechnologien, die von heutigen Zero-Trust-Lösungen eingesetzt werden, auf vier einfache Schlüsselprinzipien reduzieren.  Dieser Abschnitt beginnt mit einer Aufzählung dieser Prinzipien, gefolgt von einer Diskussion darüber, wie sie im breiteren Kontext des Anwendungsentwicklungslebenszyklus angewendet werden können, das heißt, wie diese Prinzipien im Vorfeld, in der Entwurfsphase, sowie operativ, bei der Bereitstellung/Laufzeit der Anwendung, berücksichtigt werden können.

Versteht man Zero-Trust-Lösungen als grundlegenden Aufbau von Vertrauen bei Systeminteraktionen – „ Wer tut was mit wem ?“ –, dann lässt sich der Aufbau eines interaktionsgerechten Vertrauensniveaus in vier Komponenten unterteilen.

Wie der Name schon sagt, besteht die Zero-Trust-Mentalität aus „Vertraue nicht blind, sondern überprüfe immer alles.“  Daher muss jeder Akteur im System – das Wer und Wen in Systeminteraktionen – in der Lage sein:

1. Bestätigen Sie seine Identität, einschließlich des Sonderfalls einer „anonymen“ Identität, wenn das System Interaktionen zulässt, die von anonymen Identitäten stammen oder für diese bestimmt sind – wie z. B. anonyme Browser in einem Flugreservierungssystem.  Bei allen anderen Identitäten muss der Akteur in der Lage sein, in einem vom System akzeptierten Namespace anzugeben, wer er ist.
2. Erhalten und validieren Sie zusätzliche „Beweise“ für die bestätigte Identität des Akteurs (für jede nicht anonyme bestätigte Identität).  Die Art des „Nachweises“ – Passwörter, Zertifikate, Verhaltensweisen usw. – kann unterschiedlich sein, ebenso wie seine Aussagekraft. Das System muss jedoch in der Lage sein, ein gewisses Maß an Vertrauen in die Bestätigung herzustellen.  Einfache Systeme können eine binäre Ja/Nein-Ansicht des Vertrauens in den Beweis haben, während fortgeschrittenere Systeme einen numerischen Vertrauenswert haben können, auf den im Rahmen einer auf Risiko und Ertrag basierenden Richtlinie explizit verwiesen werden kann.  Beachten Sie, dass das System das Vertrauen auch auf andere Weise erhöhen oder verringern kann, beispielsweise durch eine Reaktion auf eine aktive Herausforderung oder sogar durch passive Beobachtung des Verhaltens des Akteurs.
3. Bewerten und passen Sie das Vertrauen in die bestätigte Identität an, basierend auf einer zusätzlichen Kontextualisierung des aktuellen Verhaltens im Verhältnis zu früheren Verhaltensweisen.  Das System kann beispielsweise historische Metadaten über den Akteur verwalten, etwa dessen früheren und aktuellen Standort, Hardwareplattformen, IP-Adressen, Reputation usw., um das Vertrauen in den „Identitätsnachweis“ zu erhöhen oder zu verringern.

Darüber hinaus kann das Prinzip der expliziten Überprüfung nicht nur auf die Identität, sondern auch auf die Aktion angewendet werden – das Was der Transaktion.  Ein häufiger Anwendungsfall ist, wenn die Aktion als API-Aufruf ausgedrückt wird, beispielsweise eine API zum Ausführen einer Datenbankabfrage.  In diesem Beispiel kann das Prinzip der expliziten Überprüfung nicht nur verwendet werden, um Vertrauen in die Identität des Akteurs zu haben, der die API aufruft, sondern auch, um die Richtigkeit der Verwendung der API-Aktion zu überprüfen, etwa um zu prüfen, ob die an die API übergebenen Parameter den entsprechenden Einschränkungen entsprechen.

In einer ausgereiften Zero-Trust-Denkweise ist der „Beweis“ fast nie absolut.  Identitätsnachweise können gestohlen und Geräte kompromittiert werden; API-Parameterbeschränkungen sind oft unvollständig. Daher sollte der Begriff „Vertrauen“ im Zero-Trust-Kontext eher als Hinweis darauf interpretiert werden, wie wahrscheinlich es ist, dass die bestätigte Identität oder die Transaktionsparameter legitim sind.  Daher sollte das „Vertrauensniveau“ als ein Schlüsselfaktor betrachtet werden, jedoch nicht als der einzige bei der Entscheidung, eine Transaktion zuzulassen, zu blockieren oder genauer zu prüfen.

Sobald ein akzeptables Maß an „Vertrauen“ gegenüber den an einer Transaktion beteiligten Akteuren hergestellt ist, erfordert der Zero-Trust-Ansatz, dass dem Akteur (normalerweise dem Anforderer, dem „ Wer“ ) nur die Mindestberechtigungen gewährt werden, die erforderlich sind, damit er in diesem System seine Aufgaben erfüllen kann.  Dieses Prinzip verkörpert das, was auch als „positives Sicherheitsmodell“ bezeichnet wird – ein Ansatz, bei dem standardmäßig alle Aktionen untersagt sind und bestimmte Berechtigungen nur bei Bedarf für den Systembetrieb gewährt werden.  Beispielsweise kann ein Reservierungssystem anonymen Benutzern das Durchsuchen von Flugplänen ermöglichen, einem anonymen Benutzer jedoch – gemäß den Anforderungen des Anwendungsdesigns – nicht die Möglichkeit geben, Flüge zu buchen.

Diese Privilegien können für einzelne Schauspieler oder für Schauspielerklassen gelten.  Normalerweise sind Anwendungskonsumenten entweder menschliche Akteure oder Stellvertreter für Menschen und werden in Klassen wie „anonyme Benutzer“, „Kunden“, „Partner“ oder „Mitarbeiter“ gruppiert.  Für die weniger vertrauenswürdigen Akteurklassen ist zum Bestehen der Authentifizierung normalerweise eine niedrigere Vertrauensschwelle erforderlich, sie haben jedoch auch Zugriff auf weniger oder weniger sensible APIs.  Akteure innerhalb der Anwendung oder ihrer Infrastruktur, wie etwa bestimmte Dienste oder Container innerhalb einer Anwendung, verfügen häufig über stärker angepasste Berechtigungen, wie etwa „nur die Container <X> und <Y> können auf die Datenbank zugreifen, nur <X> kann in den Objektspeicher schreiben, aber <Y> und <Z> können daraus lesen.“

Eine wichtige Überlegung bei der Implementierung des Prinzips der geringsten Privilegien besteht darin, eine gezieltere und vorausschauendere Anwendung anzustreben.⁷ Konkret sollte eine ausgereifte Zero-Trust-Implementierung nicht darauf abzielen, einen allgemeinen Satz von Berechtigungen auf alle Akteure oder eine Klasse von Akteuren anzuwenden, sondern eine detailliertere Ansicht der jeweils versuchten Aktion bieten.   Beispielsweise kann in sehr grober Form das Privileg „Dateisystemzugriff“ gewährt werden, „Dateisystem lesen“ stellt jedoch eine engere Spezifikation des tatsächlich erforderlichen Privilegs dar, was zu einer qualitativ hochwertigen Implementierung des positiven Sicherheitsmodells führt.

Und schließlich können ausgefeiltere Ausführungsformen des Prinzips der geringsten Privilegien mit ausgereiften Implementierungen der „expliziten Überprüfung“ zusammenarbeiten, indem die autorisierten Privilegien eines Akteurs nicht als absolut angesehen werden, sondern als auf der durch die Authentifizierung bereitgestellten Vertrauenswürdigkeit beruhend.  Daher werden Berechtigungen nur gewährt, wenn das Vertrauen in die bestätigte Identität ( Wer ) einen Mindestschwellenwert erreicht, wobei die Schwellenwerte spezifisch für die versuchte Aktion sind. Beispielsweise kann bei manchen Aktionen mit besonders großer Wirkung (z. B. Herunterfahren des Systems) eine Sicherheit von 90 % oder mehr erforderlich sein, dass es sich bei dem Akteur um einen Administrator handelt.  Wenn in diesem Beispiel das Vertrauen des Systems in die Identität beim Herunterfahrenversuch nur 80 % beträgt, würde das System eine zusätzliche Überprüfung verlangen, um den Vertrauenswert in die bestätigte Identität zu erhöhen, bevor die Aktion zugelassen wird.

Explizite Verifizierung und geringste Privilegien sind Schlüsselkonzepte. Das Prinzip der kontinuierlichen Bewertung spiegelt jedoch die Tatsache wider, dass diese Prinzipien kontinuierlich evaluiert werden müssen, und zwar in dem Sinne, dass:

1. Alle Transaktionen müssen einer Überprüfung und Berechtigung unterliegen.  Mit anderen Worten: Es sollte nicht der Fall sein, dass nur eine Teilmenge der Transaktionen einer Prüfung unterzogen wird – wie etwa „die erste Transaktion in einer Benutzersitzung“ oder „die Transaktionen, die über die Workload des Docker-Containers initiiert werden“.  Obwohl dies selbstverständlich klingt, validieren viele Zero-Trust-Implementierungen nicht alle Transaktionen, entweder aufgrund eines schlechten Designs oder mangelnder Transparenz.  Häufige Mängel in diesem Bereich entstehen dadurch, dass Zero Trust nur auf externe Akteure angewendet wird, nicht aber auf interne, und/oder davon ausgegangen wird, dass ein Zero-Trust-Urteil über einen längeren Zeitraum hinweg wahr bleibt.
2. Die Schlüsselfaktoren bei der Bewertung – das Vertrauen in die Identität des Akteurs und die diesem Akteur zugestandenen Rechte – müssen als dynamisch und veränderlich betrachtet werden.  Beispielsweise kann das Vertrauen in eine Identität im Laufe der Zeit aufgrund beobachteter Verhaltensweisen und Sideband-Metadaten steigen oder fallen. Jede auf Vertrauen basierende Richtlinie muss sich daher auch dynamisch an das sich ändernde Vertrauen anpassen.  Darüber hinaus kann eine zuvor durch eine Richtlinie gewährte Berechtigungsschwelle etwas später widerrufen werden, oder die für eine Aktion erforderliche Mindestvertrauensstufe kann sich ändern.  Auch wenn die Zeiträume für Richtlinienänderungen unterschiedlich sind – sie können sich langsam (im Zeitrahmen menschlicher Betriebsprozesse) oder schnell (über automatisierte Governance-Agenten) ändern –, sollte das System in der Lage sein, dynamisch zu reagieren und diese Änderungen zu berücksichtigen.

Das letzte Prinzip wurzelt in der Annahme hochmotivierter Gegner vor dem Hintergrund gesunder Paranoia.  Konkret lautet die Prämisse: „Gehen Sie davon aus, dass es zu einem Verstoß gekommen ist“, wobei „Verstoß“ definiert wird als „eine Transaktion, die (mit vollem Wissen und in voller Ausführung) hätte verweigert werden müssen, stattdessen aber zugelassen wurde.“  Die eigentliche Ursache für dieses Entkommen kann unvollständiges Wissen sein (z. B. ein fälschlicherweise hoher Vertrauenswert bei der Authentifizierung aufgrund unentdeckter betrügerischer Anmeldeinformationen), oder es können Implementierungsbeschränkungen sein (z. B. eine nicht ausreichend feine Spezifität der gewährten Berechtigungen, wie etwa das Recht „Netzwerkverbindung öffnen“, aber ohne die Möglichkeit, basierend auf der Geolokalisierung des Netzwerkziels zu differenzieren), oder es kann durch eine unvollständige Implementierung von Zero Trust verursacht werden (z. B. wenn Zero Trust nicht auf anfällige Open-Source-Komponenten angewendet wird, die intern verwendet werden).

Daher muss sich die Zero-Trust-Mentalität auch mit der Frage befassen, wie die Auswirkungen solcher Verstöße am besten gehandhabt bzw. minimiert werden können.

Die Umsetzung dieses Prinzips variiert stärker als die der anderen Prinzipien, äußert sich aber im Allgemeinen wie folgt:

• Identifizieren Sie zunächst alle Transaktionen, die zwar technisch gesehen durch die Richtlinien erlaubt, aber verdächtig sind.  „Verdächtig“ ist oft stark kontextabhängig, gängige Interpretationen sind jedoch: (a) anomale Transaktionen, die sich stark von in der Vergangenheit beobachteten Verhaltensweisen unterscheiden, (b) Gruppen von Transaktionen, die einzeln normal, in ihrer Gesamtheit jedoch ungewöhnlich sind – beispielsweise kann das Lesen und Schreiben einer Datei normal sein, aber eine Lese- und Schreibrate von 1000 Dateien pro Sekunde kann ungewöhnlich sein, oder (c) Aktionen, die mit einer unerwünschten und bisher nicht beobachteten Auswirkung auf das System in Zusammenhang stehen – ein Beispiel wäre ein Muster, bei dem eine bestimmte Transaktion eine Netzwerkverbindung zu einem TOR-Knoten öffnet oder dazu führt, dass die CPU-Last des Systems erheblich steigt.
• Führen Sie dann eine tiefergehende Analyse durch, entweder einen vollständig automatisierten oder einen hybriden, von Menschen gesteuerten/ML-gestützten Workflow, um festzustellen, ob diese Transaktionen ungültig sind.  Wenn sich herausstellt, dass diese Transaktionen ungültig sind, wenden Sie eine Schadensbegrenzung an.  Dies kann entweder die Form einer allgemeinen Richtlinienaktualisierung oder, als zusätzliche Schadensbegrenzungsebene, eines „Sicherheitsnetzes“ für die anderen richtliniengesteuerten Schadensbegrenzungsmaßnahmen annehmen.

Wenn der gewählte Ansatz darin besteht, richtlinienbasierte Anpassungen zu verwenden, können die Anpassungen durch Nutzung aller verfügbaren statischen Richtlinientools angewendet werden.  Beispiele für richtlinienbasierte Anpassungen wären etwa die Einschränkung der transaktionsgranularen Zugriffskontrollrechte (also nicht mehr zuzulassen, wer was mit wem machen darf) oder stattdessen einen strengeren „Beweisstandard“ anzuwenden (also etwa MFA oder einen höheren Konfidenzwert zu verlangen), damit ein Akteur (oder eine Klasse von Akteuren) eine bestimmte Aktion ausführen kann. 

Wenn stattdessen der Ansatz der Verwendung einer zusätzlichen „Backstop“-Schicht gewählt wird, kann diese Strategie auch als feinkörnig oder grobkörnig implementiert werden.  Die detaillierteste Strategie wäre, genau diejenigen Transaktionen zu blockieren, die ein bestimmtes Risiko-Ertrags-Verhältnis überschreiten. Allerdings besteht bei dieser Lösung auch die Möglichkeit, dass bei einigen zulässigen Transaktionen inakzeptable Latenzzeiten auftreten, wenn für die Implementierung zusätzliche Analysen erforderlich sind.  Stattdessen könnten gröbere Strategien verwendet werden, etwa die Ausgrenzung künftiger Transaktionen dieses Akteurs in einer Sandbox oder sogar das vollständige Ausschließen des Akteurs aus dem System.  In extremen Fällen können sogar gröbere Abwehrmaßnahmen angebracht sein, etwa das Herunterfahren des Datei-E/A. 

Natürlich ist, wenn sonst alles unverändert bleibt, eine feinkörnigere Abschwächung der Gefahren im Allgemeinen vorzuziehen. Allerdings müssen aufgrund der Einschränkungen der verfügbaren Lösungstechnologien oft Kompromisse eingegangen werden, und ein grobkörniger Backstop ist in der Regel besser als gar kein Backstop.  Wenn beispielsweise die Deaktivierung der Datei-E/A die einfachste Reaktion zum Verhindern eines mutmaßlichen Ransomware-Angriffs ist, sind die Nebenwirkungen dieser Reaktion möglicherweise immer noch vorzuziehen gegenüber der Alternative – dem Akteur zu ermöglichen, weiterhin ungehindert im System zu agieren – vorausgesetzt, das Ergebnis der Untätigkeit wäre ein mit Ransomware verschlüsseltes Dateisystem. 

Der beste Ausgangspunkt für eine sichere Anwendungsentwicklung mit Zero Trust liegt, wenig überraschend, am Anfang. Die grundlegenden Prinzipien, die die Operationalisierung von Zero-Trust-Prinzipien ermöglichen, sollten in die Entwurfsphase von Anwendungsentwicklungsprozessen integriert werden.  Daher muss jede Diskussion über eine betriebsbereite Zero-Trust-Lösung, die in die CI/CD-Pipeline integriert ist, mit einem Verständnis dieser grundlegenden Elemente beginnen, die bei der Konzeption vorrangig berücksichtigt werden sollten.

Der Kern dieser grundlegenden Elemente sollte das gewünschte/beabsichtigte Verhalten der Interaktion von Systemverhalten erfassen, gekoppelt mit ausreichender Sichtbarkeit und Kontrolle, um Abweichungen zu erkennen und darauf zu reagieren.  Die beabsichtigten Interaktionen werden verwendet, um den gewünschten Aktionssatz ( Was ) für jeden Akteur ( Wer ) gegenüber jedem Ziel ( Wer ) zu definieren.  Allerdings kann es Szenarien und Umgebungen geben, in denen die beabsichtigten Interaktionsmuster unbekannt sind. In solchen Fällen kann eine Organisation tiefere Einblicke nutzen, um die richtigen Interaktionen zu „entdecken“,⁸ die es dann in der Politik kodifizieren kann.

Beispielsweise sind in den heutigen ZTNA-Lösungen, die sich auf eine identitätsbasierte Zugriffskontrolle auf die externen APIs einer Anwendung konzentrieren, Transparenz und Kontrolle der Authentifizierungs-APIs erforderlich.  Oder im Kontext der Cloud Workload Protection Platform (CWPP): Die Erkennung einer kompromittierten Container-Workload erfordert Einblick in die Aktionen, die jeder Container ausführt, und zwar in Echtzeit, wenn eine Echtzeit-Korrektur erforderlich ist.

Nachfolgend finden Sie eine Liste der wichtigsten „Buckets“ im Zusammenhang mit grundlegenden Überlegungen, die Teil des Designprozesses sein sollten, mit zusätzlichen Drilldowns, um spezifische Fragen bereitzustellen, über die Sie zu jedem der wichtigen Punkte nachdenken sollten:

• Was sind die Black-Box-Schnittstellen – Ein- 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 „rohe“ Netzwerkkommunikation oder Kommunikation über einen Datenspeicher, beispielsweise eine Datenbank oder einen Objektspeicher?
    • Wie gut ist die API für die API-Kommunikation definiert? Wie klar ist definiert, welche Benutzer mit ihr interagieren können und welche Einschränkungen für diese Interaktionen gelten (z. B. Parameterbeschränkungen, Ratenbegrenzungen usw.)? 
    • Werden bei jeglicher Netzwerkkommunikation alle Daten verschlüsselt übertragen?
    • Wenn es „Rohdatenschnittstellen“ gibt (z. B. werden Informationen über einen Objektspeicher oder eine Datenbank zwischen dem Client und der Anwendung ausgetauscht), gibt es Prüfprotokolle, um nachzuverfolgen, wer wann auf welche Informationen zugegriffen hat?
• Und was sind auf der internen „White-Box“-Ebene die Komponentendienste, aus denen sich die Gesamtanwendungen zusammensetzen (einschließlich aller extern bereitgestellten Dienste), und wie kommunizieren diese miteinander?
  • Wie kommunizieren diese Dienste, welche API wird verwendet und welche Einschränkungen (Rollen, Zugriffskontrollen, Ratenbegrenzungen, Parameter usw.) gelten für diese Interaktionen?
    • Ähnliche Fragen wie die oben genannten stellen sich hinsichtlich der Formalität der API und ihrer Einschränkungen sowie der Verschlüsselung der Kommunikation.
    • Bei der „internen“ Kommunikation (z. B. zwischen Workloads/Containern) werden eher gemeinsam genutzte Speicher- und dateisystembasierte Schnittstellen verwendet. Alle derartigen Schnittstellen sollten identifiziert werden.
• Welche Kontrollmechanismen stellt das System zur Verfügung, um den Zugriff auf die Blackbox-Schnittstellen und internen Kommunikationswege zu beschränken?
  • Gibt es eine Richtlinie, die angibt, wer – welche Rollen – bestimmte APIs aufrufen kann und was passiert, wenn die Richtlinie verletzt wird?  Und welche Möglichkeiten gibt es, einen Missbrauch der APIs, etwa durch ungültige Parameter oder eine zu hohe Aufrufrate, zu erkennen und zu verhindern?  Können diese Richtlinien basierend auf kontextbezogenen Eingaben aus anderen Systemen dynamisch aktualisiert werden?
  • Gibt es analog dazu Richtlinien, die die anderen Formen der Kommunikation zwischen Workloads – Dateisysteme, Objektspeicher, Datenbanktabellen – in Bezug darauf einschränken, wer auf welche Dateien/Speicher/Tabellen zugreifen kann, und die einen Missbrauch dieser Ressourcen verhindern (z. B. „SELECT * from <table>“)?
• Welche Sichtbarkeit (Dashboards, Protokolle, Statistiken) stellt das System zur Verfügung, um den Zugriff sowohl auf die Black-Box-Schnittstellen als auch auf die internen Kommunikationspfade zu beschränken?
  • Kann das System erkennen, wer wann welche API aufruft?  Werden diese Daten gespeichert und wenn ja, wie lange?  Wie schnell (Echtzeit, stündlich usw.) werden solche Daten bereitgestellt?  Inwieweit sind die Daten nutzbar – handelt es sich um ein unstrukturiertes Dateiprotokoll, eine strukturierte JavaScript Object Notation (JSON), die an einen Dienst für das Sicherheitsereignis- und Vorfallmanagement (SEIM) gesendet werden kann, oder um in einer Big-Data-Datenbanktabelle aufgezeichnete Daten?
  • Wie lauten die Antworten auf dieselben Fragen, wenn es um andere Kommunikationspfade geht – Speicher, Dateien, Objekte, Datenbanken?  Wer macht was?  Wie werden diese Daten offengelegt?
• Welche anderen Kontrollen und Transparenzen bietet das System außer den Kommunikationspfaden, um eine Überbelegung oder einen übermäßigen Verbrauch von Ressourcen zu verhindern ?
  • Verfügt das System über Einblick in die Kennzahlen zum Ressourcenverbrauch – CPU, Speicher, Bandbreite, Pod-Skalierung usw.?  Wenn ja, in welcher Granularität liegen diese Daten vor und wie nutzbar sind sie?
  • Verfügt das System über Kontrollen oder Leitplanken für den Ressourcenverbrauch – Speicher-/CPU-/Datei-E/A-Grenzwerte pro Workload, Verfolgung von Systemaufrufen zur Prozesserstellung, Grenzwerte für das Hoch-/Herausskalieren von Pods, Ratenbegrenzungen für APIs, die andere Dienste aufrufen?

Wenn Sie diese Fragen explizit stellen, können Sie Lücken in der Grundlage für die Ermöglichung von Zero Trust entdecken.  Oftmals führt allein das Nachfragen zu Beginn der Entwurfsphase dazu, dass die Lücke mit minimalem zusätzlichen Entwurfsaufwand geschlossen wird.  Und wo möglicherweise weiterhin eine Lücke besteht, reicht allein das Bewusstsein für diese Lücke aus, um den Fokus stärker auf die Sicherheit zu lenken oder Schwachstellen zu identifizieren.

Die Durchführung dieser Art von sicherer Entwicklungsanalyse im Vorfeld ist ein entscheidender Teil der Zero-Trust-Mentalität.  Trotz dieser Tatsache konzentriert sich der Fokus bei Zero Trust heute stark darauf, was nach der ersten Konzeption geschieht, und die meisten Unternehmen konzentrieren sich auf die Aspekte von Zero Trust nach der Konzeption.  Wenn Sie sich jedoch bereits in der Entwurfsphase Gedanken über die Anforderungen für eine wirksame Implementierung von Zero Trust machen, können Sie nach der Bereitstellung der Anwendung einen wesentlich größeren inkrementellen Aufwand vermeiden, der zum „Ausbessern der Lücken“ erforderlich ist.

Wie die „Annahme eines Verstoßes“-Prämisse dieser Denkweise besagt, muss ein Sicherheitsexperte davon ausgehen, dass es einem ausreichend motivierten Gegner gelingen wird, eine böswillige Transaktion durchzuführen – ein Beispiel dafür, wer was wem antut, und das den Richtlinienregeln entspricht, in einer perfekten Welt aber nicht hätte erlaubt sein dürfen.  In solchen Fällen liegt der Schwerpunkt dann auf der Verfügbarkeit eines effektiven „Backstop“-Mechanismus, mit dem sich diese Fälle aufdecken lassen. Dieser basiert normalerweise auf der Beobachtung von Transaktionsmustern und Systemnebeneffekten, wie im Abschnitt „Angenommener Verstoß“ weiter oben beschrieben.

Allerdings wird es, ebenso wie beim Konzept der Identität, nie hundertprozentige Gewissheit darüber geben, ob eine bestimmte Transaktion böswilliger Absicht dient oder nicht.  Daher sollte eine ideale Zero-Trust-Lösung, genau wie bei der Identität, einen „Vertrauenswert“-Wert hinsichtlich der Legitimität der Transaktion melden. Wenn Sie beispielsweise sehen, dass ein Daemon 10 Sekunden lang das Zehnfache der normalen Dateirate liest und schreibt, liegt dies möglicherweise in einem Vertrauenswert (für Bösartigkeit) von 70 %. Wenn sich die Rate jedoch 100 Mal erhöht und dies über 1 Minute anhält, kann dies die Sicherheit auf 95 % erhöhen. In diesem Beispiel besteht bei der Abhilfemaßnahme, zukünftige Dateischreibvorgänge zu verhindern, immer noch eine gewisse Wahrscheinlichkeit (30 % bzw. 5 %), dass es sich um eine falsche Reaktion – ein „Falschpositiv“ – handelt.  Daher muss bei der Entscheidung zur Behebung des Problems das Risiko falscher Positivergebnisse gegenüber den möglichen Auswirkungen einer Zulassung möglicherweise böswilligen Verhaltens abgewogen werden.

Der Sinn des Beispiels besteht darin, hervorzuheben, dass jede Entscheidung, eine für den Benutzer sichtbare Abhilfemaßnahme zu ergreifen, ist in Wirklichkeit eine Geschäftsentscheidung, bei der alle Risiken, Kosten und Vorteile der verdächtigen Aktivität berücksichtigt werden.  Durch die Einführung zusätzlicher Reibungspunkte bei der Transaktion steigt die Wahrscheinlichkeit, dass der Wert nicht empfangen wird. Wenn jedoch nicht eingegriffen/Reibungspunkte hinzugefügt werden, besteht das Risiko einer Gefährdung. Daher ist die Entscheidung, in solchen Fällen zu handeln (oder nicht), eine Funktion von drei Faktoren:

1. Wie groß ist das Risiko, dass möglicherweise böswillige Transaktionen weiterhin zugelassen werden?
   Dieses Risiko kann direkt monetärer Natur sein, etwa bei der Überweisung von Bankmitteln, oder es können indirekte Kosten entstehen, entweder betrieblicher Natur (z. B. die Verschlüsselung von Schlüsseldatensätzen, die als Lösegeld einbehalten werden) oder Branding-bedingter Natur (z. B. die Verunstaltung einer Website). Darüber hinaus können Rechts- oder Compliance-Kosten entstehen, etwa durch die Weitergabe persönlicher Kundendaten. Im Wesentlichen ist die Risikozuweisung eine Frage der Governance. Eine gute Governance erkennt und quantifiziert die Risiken für die Anwendung.


2. Welche Nebenwirkungen können durch die Abhilfemaßnahme entstehen?
   Die Nebenwirkungen können anhand der Dimensionen (a) verursachte Reibung und (b) Explosionszone ausgedrückt werden. Die Reibung ist, wie viel schwieriger es ist, eine legitime Transaktion durchzuführen; dies kann von geringfügig umständlicher (z. B. eine zusätzliche Authentifizierungsebene) bis unmöglich (die Transaktion ist schlicht nicht zulässig) reichen. Die Explosionszone bezieht sich darauf, ob und wie viele andere unabhängige Transaktionen ebenfalls betroffen sind.  Wenn Sie beispielsweise einen bestimmten Benutzer sperren, wirkt sich dies nur auf diesen Benutzer aus. Durch die Abschaltung eines Protokollierungsdienstes wird jedoch die Überprüfbarkeit aller Benutzer und Transaktionen beeinträchtigt. 


3. Wie hoch ist die Wahrscheinlichkeit, dass die Transaktion böswillig ist? 
   Um Vertrauen aufzubauen, müssen normalerweise mehr Datenpunkte gesammelt und mehr Datenquellen korreliert werden. Beides braucht Zeit. In der Praxis lautet die Abwägung daher oft: „Wie lange sollte ich abwarten, bevor ich mich zum Handeln entscheide?“

Während eine Zero-Trust-Strategie also die Tatsache berücksichtigen muss, dass es zu Verstößen kommen wird, wird bei einem durchdachten Ansatz bei der Behebung von Transaktionen, die zwar zulässig sind, aber verdächtig erscheinen, ein Risiko-Ertrags-Verhältnis verfolgt.  Bei diesem Kompromiss werden das Risikoniveau verschiedener Anwendungstransaktionen und die Folgen einer Abhilfemaßnahme berücksichtigt. Außerdem werden Abhilfemaßnahmen nur dann angewendet, 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 Vorausplanung beginnt bereits in der Entwurfsphase, wie später beschrieben.

⁸ Oder zumindest die Reihe der „als angemessen erachteten“ Interaktionen, die das System offenbar erfordert.  Es besteht immer das Risiko, dass die aus der Beobachtung abgeleiteten Interaktionen unvollständig sind oder bereits ein gewisses Risiko bergen.  Aus diesem Grund ist eine vorausschauende Planung stets vorzuziehen.