Berücksichtigung von Techniken und Technologien zur Einführung von Zero Trust

Ausweitung des „Warum“ – die Leitprinzipien¹ – von Zero Trust ist die nächste Sorge das „Wie“ – die Techniken und Technologien, die zur Umsetzung dieser Prinzipien verwendet werden.

Aus einer breiteren Perspektive können Zero-Trust-Prinzipien auf den gesamten Lebenszyklus der Anwendungsentwicklung angewendet werden, einschließlich des Systemdesigns, der verwendeten Hardwareplattformen und der Beschaffungsverfahren.² In diesem Dokument werden jedoch die betrieblichen Aspekte der Implementierung von Zero Trust zum Schutz von Anwendungen und Daten zur Laufzeit erörtert. 

Im Großen und Ganzen werden bei der Zero-Trust-Sicherheit Technologien eingesetzt, um eines von drei unterschiedlichen Zielen zu erreichen:

1. Transaktionale Einschränkungen durchsetzen: Wer kann was wem antun ?
2. Verschaffen Sie dem menschlichen Systembediener Situationsbewusstsein.
3. Führen Sie erweiterte Risikominderungs-/Behebungsmaßnahmen durch, die auf den durch maschinelles Lernen (ML) unterstützten Verdachtsindikatoren und dem Risiko-Ertrags-Profil der betreffenden Transaktion(en) basieren.

Die folgende Grafik zeigt dieses allgemeine Zero-Trust-Sicherheitstransaktionsmodell, wobei in den folgenden Abschnitten detaillierter auf die einzelnen Technologieklassen eingegangen wird.

Die ersten beiden Technologien – Authentifizierung und Zugriffskontrolle – sind eng miteinander verknüpft und basieren direkt auf den Prinzipien der „expliziten Überprüfung“ und der „geringsten Privilegien“, da diese Technologien die Grundlage für die Durchsetzung der Regelung „ Wer darf was? “ bilden. Anspruchsvollere Implementierungen der Authentifizierung beobachten das fortlaufende Verhalten eines Akteurs und erfassen dabei die Denkweise einer „kontinuierlichen Bewertung“. 

Bei Authentifizierungstechnologien geht es darum, Vertrauen in eine bestätigte Identität aufzubauen: Wer ist an einer Transaktion beteiligt? Der Authentifizierungsprozess besteht aus drei Komponenten: 

1. Es liegt eine Bescheinigung oder Behauptung des Schauspielers vor, in der seine Identität angegeben ist.
2. Es gibt einige Daten, die in der Regel vom Akteur bereitgestellt werden und die die Richtigkeit der Bescheinigung belegen.
3. Das System fällt ein Urteil oder eine Entscheidung über die Wahrscheinlichkeit, dass die Bescheinigung korrekt ist – der Akteur also der ist, der er vorgibt zu sein. Die folgende Grafik zeigt die verschiedenen Aspekte der Authentifizierung und die jeweiligen Reifegradmodelle. Anschließend werden die einzelnen Aspekte ausführlicher erläutert. 

Die grundlegendste Form der Bescheinigung wird häufig als „Benutzer“ bezeichnet – ein Mensch oder ein im Auftrag eines Menschen handelnder Agent, der eine Transaktion durchführen möchte. Beim Zero-Trust-Ansatz innerhalb einer Anwendung kann es sich bei einem Akteur jedoch auch um eine Arbeitslast (z. B. einen Prozess, einen Dienst oder einen Container) handeln. Daher sollte das allgemeine Identitätskonzept solche Akteure einschließen. In anderen Fällen umfasst der Begriff „ Wer“ nicht nur den Menschen oder die Arbeitsbelastung, sondern zusätzliche Überlegungen oder Dimensionen der Identität. Aus dieser Perspektive könnten zusätzliche Dimensionen der Identität das Gerät oder die Plattform des Benutzers/der Arbeitslast oder das für die Interaktion verwendete Ökosystem oder den Standort des Agenten umfassen. Beispielsweise kann sich die Benutzerin „Alice“ auf einem PC mit der Bezeichnung „ABC-0001“ befinden und eine bestimmte, per Fingerabdruck erfasste Browserinstanz verwenden, die von der IPv4-Adresse 10.11.12.13 stammt. 

Einige Systeme gestatten nicht authentifizierten Benutzern (manchmal auch als „Gäste“ oder „anonyme“ Benutzer bezeichnet) die Durchführung einer begrenzten Anzahl von Transaktionen. Für solche Systeme sind die zusätzlichen Schritte des Identitätsnachweises und der Urteilsfindung durch das System nicht relevant. Für jede bestimmte bestätigte Identität werden jedoch üblicherweise die folgenden Methoden verwendet, um diese Bestätigung zu unterstützen:

• Kenntnis eines gemeinsamen Geheimnisses, beispielsweise eines Passworts.
• Eine Art Anmeldeinformation von einem vertrauenswürdigen Dritten, beispielsweise ein signiertes Zertifikat.
• Abfrage – entweder automatisiert (z. B. Geräte-Fingerprinting) oder aktiv (z. B. Captcha-Challenge) – des Benutzers, der Arbeitslast oder der Plattform.
• Mit dem Akteur in Zusammenhang stehende Metadaten, wie etwa Geolokalisierung, IP-Reputation oder Zugriffszeit.
• Verhaltensanalysen, wie etwa passive biometrische Analysen oder Arbeitsablaufmuster der Anwendungsinteraktion. 

Wenn ein hohes Maß an Vertrauen erforderlich ist, werden häufig mehrere Methoden verwendet. Dies zeigt sich im Modell von Google BeyondCorp.³ das eine Multi-Faktor-Authentifizierung (MFA) erfordert, bevor Transaktionen mit höherem Wert zugelassen werden. Die ausgefeilteren Authentifizierungslösungen verknüpfen mit jeder Identität ein „Vertrauen“ und legen für jede Art von Transaktion ein Mindestvertrauensniveau fest, das auf dem Wert und dem Risiko der Transaktion basiert.

Beachten Sie abschließend, dass einige dieser Methoden keine statischen, einmaligen Aktionen sind, sondern gemäß dem Grundsatz der „kontinuierlichen Bewertung“ fortlaufend durchgeführt werden können und sollten. In solchen Fällen kann sich der der Identitätsbestätigung zugewiesene Vertrauenswert im Laufe der Zeit nach oben oder nach unten ändern. Beispielsweise kann sich der Browser-Fingerabdruck oder die IP-Adresse innerhalb einer einzigen Benutzersitzung ändern, was als verdächtig angesehen werden und das Vertrauen mindern könnte; oder wenn mehr Daten über das Verhalten des Akteurs in einer Sitzung gesammelt werden, kann der Vertrauenswert entweder steigen oder fallen, je nachdem, wie das aktuelle Verhalten im Vergleich zu früheren Beobachtungen ausfällt.

In fortgeschritteneren Systemen kann die dynamische Authentifizierung Hand in Hand mit der Zugriffskontrolle arbeiten. Als erste Ebene dieser Interaktion kann die Zugriffskontrollrichtlinie, wie bereits erwähnt, einen Mindestvertrauenswert für verschiedene Transaktionsklassen festlegen. Auf der nächsten Interaktionsebene kann das Zugriffskontrollsubsystem dem Authentifizierungssubsystem Feedback geben und in der Regel eine zusätzliche Authentifizierung anfordern, um den Vertrauenswert auf den Mindestschwellenwert zu erhöhen.

Nachdem mithilfe von Authentifizierungstechniken ermittelt wurde, wer an einer Transaktion beteiligt ist, lauten die nächsten Fragen: Was darf dieser Schauspieler? Und wem ? Dies fällt in den Zuständigkeitsbereich von Zugangskontrolltechnologien.

Um eine Analogie zur physischen Sicherheit zu verwenden, stellen Sie sich vor, Sie wollten einen Militärstützpunkt besuchen. Nachdem die Wachen sicher festgestellt haben, ob Sie Zivilist, Politiker oder Soldat sind, entscheiden sie auf Grundlage dieser Feststellung, welche Gebäude Sie betreten dürfen und ob Sie in jedes Gebäude, das Sie betreten dürfen, eine Kamera mitbringen dürfen. Die für diese Entscheidungen geltenden Richtlinien können sehr grob sein und für alle Gebäude gelten (z. B. „Politiker dürfen jedes Gebäude betreten“), aber auch detaillierter sein (z. B. „Politiker dürfen nur die Gebäude <A> und <B> betreten, dürfen aber nur Kameras in <A> mitbringen“).

Im Kontext der Cybersicherheit sollten Zugriffskontrolltechniken das Zero-Trust-Prinzip der „geringsten Privilegien“ verkörpern. Mit anderen Worten: Die optimale Zugriffskontrollrichtlinie würde nur genau die Berechtigungen zulassen, die der Akteur benötigt, und alle anderen Berechtigungen untersagen. Darüber hinaus wäre eine ideale, robuste Richtlinie von einem bestimmten Mindestmaß an Vertrauen in die Authentizität der Identität des Akteurs abhängig, wobei die Vertrauensschwelle auf der Granularitätsebene jedes zulässigen Privilegs angegeben wäre.

Der Wert einer Zutrittskontrolllösung kann daher daran gemessen werden, wie sehr sie diesen Idealen entspricht. Insbesondere muss eine Zero-Trust-Sicherheitslösung eine Zugriffskontrolle umfassen und sollte die Zugriffskontrolltechnologie anhand der unten dargestellten und nachfolgend beschriebenen Dimensionen bewerten. 

1. Wie feinkörnig sind die Zugriffskontrollrechte?

1. Wie detailliert ist die Aktion – das Was in der Transaktion? Ist es:

1. Binär : Erlauben Sie „alle“ Transaktionen oder „keine“. In der Analogie zum Militärstützpunkt entspräche dies: „Alle Soldaten können jedes Gebäude betreten und tun, was sie wollen“ und „Zivilisten dürfen kein Gebäude betreten.“
2. Grob : Granular bis zum API-Endpunkt oder „Typ“ der Transaktion (wie etwa Datei-E/A, Netzwerkkommunikation und Prozesssteuerung). In unserem Beispiel würde dies eine gewisse Nuancierung der zulässigen Aktionen ermöglichen, etwa: „Politiker dürfen Gebäude betreten, aber keine Fotos machen.“ 
3. Bußgeld: An der untergeordneten API (d. h. abhängig von den Parametern oder der Version der API) oder am „Untertyp“ der Transaktion (z. B. Datei-E/A nur lesend oder TCP nur empfangend). Um noch einmal bei unserer Analogie zu bleiben: Dies würde feinere Kontrollen ermöglichen, wie etwa: „Zivilisten dürfen Gebäude nur in Begleitung eines Soldaten betreten.“ 

2. Gibt es detaillierte Informationen zum Ziel der Aktion – also zum „Wen“ der Transaktion? Ist es:

1. Nicht zielgranular: Die Zugriffskontrollrichtlinie berücksichtigt nicht das Ziel der Aktion. In unserem Beispiel würde dieser Ansatz dazu führen, dass der Zutritt zu manchen Gebäuden erlaubt ist, zu anderen jedoch nicht – wobei die Gebäude das Ziel der Aktion „Betreten“ sind.
2. Zielgranular, Infrastrukturebene: Die Zugriffskontrollrichtlinie kann das Ziel der Aktion enthalten, verwendet jedoch ein infrastrukturspezifisches Tag/Label, beispielsweise die IP-Adresse, den DNS-Namen oder den Kubernetes (K8S)-Containernamen für das Ziel. Dadurch könnte die Richtlinie gebäudegranular sein, aber jeder Militärstützpunkt könnte eine andere Benennungskonvention für Gebäude haben.
3. Zielgranular, identitätsbewusst: Die Zugriffskontrollrichtlinie kann das Ziel der Aktion umfassen und das Ziel mithilfe desselben Identitätsnamensraums (z. B. SPIFFE) identifizieren, der für den Akteur (das „Wer“) verwendet wird. Der Vorteil gegenüber dem vorherigen Ansatz besteht darin, dass alle Militärstützpunkte ein einheitliches Schema zur Identifizierung von Gebäuden verwenden würden, wodurch die Richtlinie übertragbarer wird.

2. Wie geht die Zugriffskontrolllösung mit dem Konzept von weniger bzw. risikoreicheren Aktionen um?

1. Nicht risikobewusst: Die Zugriffskontrolllösung behandelt alle Zugriffskontrollberechtigungen hinsichtlich der Entscheidung, die Aktion zuzulassen oder zu untersagen, identisch.
2. Risikomanagement mittels MFA: Mit der Zugriffskontrolllösung wird das Risiko gemanagt, indem in der Richtlinie festgelegt werden kann, dass für einige zulässige Transaktionen je nach Akteur ( Wer ), Aktion ( Was ) oder Ziel ( Wer ) der Transaktion noch immer die Multi-Faktor-Authentifizierung verwendet werden muss.
3. Risikomanagement durch Vertrauen: Mit der Zugriffskontrolllösung wird das Risiko gemanagt, indem in der Richtlinie festgelegt werden kann, dass für jede Transaktion basierend auf der Aktion ( Was ) und dem Ziel ( Wer ) der Transaktion weiterhin ein Mindestmaß an Vertrauen in die Authentizität des Akteurs erforderlich sein kann. MFA kann das Vertrauen erhöhen, es können jedoch auch andere Mittel zum Einsatz kommen; in anderen Fällen wird die Transaktion möglicherweise überhaupt nicht zugelassen, wenn es sich um eine Transaktion mit hohem Wert handelt und die Authentizität des Akteurs ausreichend ungewiss ist.

Unter Beachtung des Grundsatzes der „kontinuierlichen Bewertung (und Neubewertung)“ sollte sich der Glaube an die Authentizität des Schauspielers mit der Zeit anpassen. Bei einer einfachen Lösung kann es sich lediglich um eine Zeitüberschreitung handeln. Bei komplexeren Systemen kann die Zuverlässigkeit aufgrund von Beobachtungen des Verhaltens des Akteurs im Laufe der Zeit variieren.

Wenn Authentifizierung und Zugriffskontrolle Implementierungen der Denkweise „immer überprüfen“ und „geringste Privilegien“ sind, dann sind Sichtbarkeit und Kontextanalyse die Grundlage der Prinzipien „kontinuierlich bewerten“ und „Verstoß annehmen“.

Sichtbarkeit ist die notwendige Voraussetzung für die Analyse – ein System kann nicht abschwächen, was es nicht sieht. Daher ist die Wirksamkeit der Zero-Trust-Sicherheitslösung direkt proportional zur Tiefe und Breite der Telemetriedaten, die aus Systemvorgängen und dem externen Kontext gesammelt werden können. Eine moderne Sichtbarkeitsinfrastruktur kann jedoch weitaus mehr potenziell nützliche Daten, Metadaten und Kontexte bereitstellen, als ein vernünftiger Mensch ohne Hilfe rechtzeitig verarbeiten könnte. Aufgrund des Wunsches nach mehr Daten und der Fähigkeit, diese Daten schneller in Erkenntnisse umzuwandeln, besteht eine zentrale Anforderung in der maschinellen Unterstützung der menschlichen Bediener.

Diese Unterstützung wird normalerweise mithilfe automatisierter Algorithmen implementiert, die das Spektrum von regelbasierten Analysen über statistische Methoden bis hin zu fortgeschrittenen Algorithmen des maschinellen Lernens abdecken. Diese Algorithmen sind dafür verantwortlich, die Flut an Rohdaten in verwertbare und operationalisierbare Situationsinformationen zu übersetzen, die von den menschlichen Bedienern zur Bewertung und, falls erforderlich, zur Abhilfe verwendet werden können. Aus diesem Grund geht die ML-gestützte Analyse Hand in Hand mit der Sichtbarkeit.

Unten sehen Sie die allgemeine Pipeline von den Rohdaten (Sichtbarkeit) bis zur Aktion (Behebung): 

Sichtbarkeit ist die Umsetzung – das „Wie“ – des Zero-Trust-Prinzips der „kontinuierlichen Bewertung“. Dazu gehört die Bestandsaufnahme der verfügbaren Dateneingaben (Katalog) und die Echtzeit-Telemetrie sowie die Speicherung historischer Daten (Sammeln).

Bei der Reife einer Zero-Trust-Transparenz-Implementierung sollten vier Faktoren berücksichtigt werden: 

1. Latenz : Wie nah sind die Daten an Echtzeit?

Die Latenz stellt eine Untergrenze dafür dar, wie schnell auf eine potenzielle Bedrohung reagiert werden kann. Die Latenz einer Zero-Trust-Lösung sollte im Sekundenbereich oder darunter gemessen werden. Andernfalls ist es sehr wahrscheinlich, dass jede noch so genaue Analyse zu spät kommt, um die Auswirkungen des Exploits, wie z. B. Datenexfiltration/-verschlüsselung oder Nichtverfügbarkeit aufgrund erschöpfter Ressourcen, zu verhindern. Anspruchsvollere Systeme ermöglichen möglicherweise sowohl synchrone als auch asynchrone Schadensbegrenzung. Eine synchrone Schadensbegrenzung würde den Abschluss der Transaktion verhindern, bis die vollständige Transparenz und Analyse gewährleistet ist. Da die synchrone Schadensbegrenzung wahrscheinlich zu einer längeren Latenz der Transaktion führt, wäre dieser Betriebsmodus für besonders anomale oder riskante Transaktionen reserviert, während alle anderen Transaktionen Telemetriedaten senden und asynchron analysiert werden könnten.

2. Verbrauchbarkeit : Wie leicht können die Daten genutzt werden?
   

Dieses Problem ist relevant, wenn Daten aus mehreren Quellen oder Datensensortypen eingehen, was ein häufiges Szenario ist. Dieser Faktor lässt sich im Allgemeinen in zwei Unteraspekte unterteilen. 

• Auf syntaktischer Ebene, wie die Daten extrahiert und dargestellt werden können. Wenn beispielsweise die Reputation einer Quell-IP aus einer Quelle als Textfeld (wie „böswillig“, „verdächtig“, „unbekannt“ usw.) in einer Syslog-Meldung eintrifft und aus einer anderen Quelle als numerisches, binär codiertes Feld in einer Datendatei, sollte eine kanonische Darstellung identifiziert werden. Um die eingehenden Daten zu extrahieren und in diese Darstellung zu transformieren, ist eine Datenserialisierung erforderlich. 

• Auf der semantischen Ebene können sich verschiedene Quellen nicht nur in ihrer Syntax und ihrem Transport unterscheiden, sondern auch in der Semantik. Um noch einmal das Beispiel der IP-Reputation zu verwenden: Ein Anbieter kann einen Bedrohungswert als Zahl bereitstellen, während ein anderer Anbieter die IP in einen Bucket wie „TOR-Knoten“, „DNS-Kontrolle“ oder „Phishing“ einordnet. Die Sichtbarkeitslösung muss außerdem einen Mechanismus zur Normalisierung der eingehenden Daten in eine konsistente Syntax bereitstellen. 

3. Vollständigkeit: Wie breit und umfangreich sind die verfügbaren Daten?

Ein zentraler Vorteil einer hochwertigen Transparenzlösung besteht in der Möglichkeit, verdächtige Aktivitäten als Hinweis auf einen möglichen Verstoß zu erkennen. Damit dies effektiv gelingt, muss die Lösung Telemetriedaten aus allen relevanten „Schichten“ der Anwendungsbereitstellung empfangen: natürlich von der Anwendung selbst, aber auch von der Anwendungsinfrastruktur, der Netzwerkinfrastruktur, von allen auf die Anwendung angewendeten oder von ihr verwendeten Diensten und sogar von den Ereignissen auf dem Client-Gerät. So ist es beispielsweise möglicherweise schon an sich leicht verdächtig, einen Benutzer zu identifizieren, der sich von einem neuen, noch nie gesehenen Gerät aus anmeldet. In Kombination mit Netzwerkinformationen (wie etwa einer GeoIP-Zuordnung aus dem Ausland) steigt der Verdacht jedoch noch stärker. Dieser Grad des Misstrauens äußert sich in einem niedrigeren Vertrauenswert hinsichtlich der Identität des Benutzers. Wenn dieser Akteur im Rahmen einer Zero-Trust-Sicherheitsrichtlinie eine Transaktion mit hohem Wert versucht (z. B. die Überweisung von Geldern auf ein ausländisches Konto), kann die Zugriffskontrolllösung die Transaktion aufgrund der geringen Vertrauenswürdigkeit blockieren.

Im Hinblick auf die Zero-Trust-Mentalität gilt: Je umfassender und umfassender die Transparenzlösung ist, desto effektiver kann das System Transaktionen begrenzen und Verstöße erkennen.

4. Führung: Inwieweit werden gesetzliche und lizenzbedingte Anforderungen an die Datennutzung unterstützt?

Schließlich muss jede Datenerfassung den gesetzlichen und lizenzrechtlichen Anforderungen in Bezug auf die Sicherheit, Aufbewahrung und Verwendung der Daten entsprechen. Daher muss eine robuste Sichtbarkeitslösung alle diese Anforderungen erfüllen. Das Verständnis der durch die Governance bedingten Einschränkungen der Datennutzung muss in eine Zero-Trust-Transparenzlösung einbezogen werden. Wenn eine IP beispielsweise als personenbezogene Information (PII) gilt, muss die Nutzung und langfristige Speicherung von IP-Adressen für Analysen der zulässigen Verwendung der IP-Adressen Rechnung tragen. 

Neben der Sichtbarkeit sind für die Umsetzung einer „kontinuierlichen Bewertung“ auch die Analysetools erforderlich, die für eine aussagekräftige Bewertung erforderlich sind. Das heißt, es muss eine Bewertung vorhanden sein, die mit einer Zero-Trust-Lösung umgesetzt werden kann.

Bei der Analyse müssen Umfang und Breite der Eingabedaten berücksichtigt werden. Die Eingaben für die Analysealgorithmen können auf einen einzigen Datenstrom aus einer einzigen Quelle beschränkt sein oder mehrere Ströme berücksichtigen, darunter verschiedene Datenquellen und alle Ebenen der Infrastruktur und Anwendung. 

• Die grundlegendste Kontextualisierung erfolgt im Rahmen eines einzelnen „Typs“ oder „Stroms“ von Daten (wie etwa ein Strom von „Benutzeranmeldeinformationen mit Zeit und Quell-IP-Adresse“-Ereignissen), typischerweise mit historischem Kontext und/oder Daten über mehrere Benutzer hinweg. Aus dieser Analyse können einige grundsätzliche Erkenntnisse hervorgehen, wie etwa „Dieser Benutzer <X> hat sich zu dieser Tageszeit noch nie angemeldet“ oder „Dieser Benutzer <X> scheint sich immer unmittelbar nach dem anderen Benutzer <Y> anzumelden.“ Ersteres kann das Vertrauen in die Identität verringern; Letzteres kann auf ein übergeordnetes, möglicherweise bösartiges Muster hinweisen.
• Eine erweiterte Kontextualisierung berücksichtigt den zeitbasierten und mehrinstanzbezogenen Umfang nicht nur für einen einzigen „Typ“ von Daten, sondern führt auch eine zeitliche Korrelation zwischen verschiedenen „Typen“ oder „Streams“ von Daten durch. Ein Beispiel wäre die Korrelation der Benutzeranmeldedaten mit bestimmten Aktionen auf der Anwendungsebene (wie Geldüberweisungen oder E-Mail-Kontaktaktualisierungen) oder auf der Netzwerkebene (wie eine IP-basierte Geolokalisierungssuche). 

Ein zweiter besonders relevanter Analyseaspekt im Zero-Trust-Framework betrifft den Umgang mit dem Volumen und der Geschwindigkeit der aufgenommenen Daten, die die Verarbeitungskapazität eines jeden Menschen übersteigen. Daher ist eine Art maschineller Unterstützung zur Gewinnung von für den Menschen verständlichen Erkenntnissen erforderlich. Auch hier kann die Verfeinerung der Unterstützung als Fortschritt bezeichnet werden.

• Nur Visualisierung: Der erste Schritt besteht in der bloßen Darstellung von Statistiken und Ereignissen, typischerweise über Dashboards, die auf einem Verwaltungsportal verfügbar sind. Die dargestellten Daten basieren auf gesammelten Datenströmen (normalerweise entweder eine Zeitreihe oder ein Längsschnitt über Benutzer/Transaktionen innerhalb eines festen Zeitfensters). Fortgeschrittenere Dashboards bieten die Möglichkeit zum Sortieren und Gruppieren der Daten sowie zum Drilldown durch Filtern. In diesem Modell übernimmt der Mensch die gesamte Datenerkundung, Ereignispriorisierung, Analyse und Behebung, wobei die Automatisierung in erster Linie bei der Datenerkundung hilft.
• Visualisierung plus konfigurierbare statische Regeln: Die am häufigsten verwendete nächste Erweiterung der Visualisierung besteht in der Möglichkeit, dem Menschen das Definieren statisch festgelegter Regeln zu ermöglichen, entweder zur Warnung oder zur Behebung. Beispiele für solche Regeln wären „Menschen benachrichtigen <John> wenn <Die CPU-Auslastung übersteigt 5 Minuten lang 80 %>“ oder „erfordern <MFA per E-Mail> wenn <API [Y] wird aufgerufen und das Land ist nicht [USA]>”. Diese Regeln können auf vordefinierte Regeln beschränkt sein, die vom Lösungsanbieter angegeben werden. Fortgeschrittenere regelbasierte Subsysteme können auch benutzerdefinierte Regeln zulassen, die von einem SecOps-Ingenieur geschrieben wurden. In beiden Fällen werden alle angewendeten Regeln normalerweise über die Konfiguration gesteuert (und bei Bedarf definiert). 
• Visualisierung plus ML-Unterstützung: Auf der nächsten Ebene kommen fortgeschrittenere Techniken zum Einsatz, die Verhaltensanomalien und/oder Transaktionen erkennen, die mit den Mustern zuvor identifizierter bösartiger Transaktionen übereinstimmen. Obwohl viele Techniken zum Einsatz kommen (und eine ausführliche Diskussion der technischen und geschäftlichen Vor- und Nachteile über den Rahmen dieses Dokuments hinausgeht), sollten einige wichtige Punkte berücksichtigt werden: 

• Erforderlicher menschlicher Aufwand: Einige ML-Techniken erfordern „Training“ (auch als überwachtes Lernen bezeichnet), was bedeutet, dass ein angemessen großer Datenkorpus mithilfe eines vertrauenswürdigen, zuverlässigen „Klassifikators“ vorab kategorisiert werden muss. Um eine vertrauenswürdige Kategorisierung zu gewährleisten, ist der „Klassifizierer“ häufig ein Mensch oder eine Gruppe von Menschen. In diesen Fällen sollte der erforderliche menschliche Aufwand berücksichtigt werden. Andere Techniken (auch unüberwachtes Lernen genannt) erkennen Anomalien und/oder Muster selbstständig und ohne menschliches Zutun. 
• Erklärbarkeit: Die Ausgabe(n) eines maschinellen Lernsystems resultieren aus der Auswertung der Eingabedaten anhand eines Modells. Dieses Modell kann auf einer Reihe einfacher, leicht zu beantwortender Fragen basieren, wie etwa: „Wurde dieser Benutzer im letzten Monat auf diesem Gerät gesehen?“ Es könnte auch auf einer leicht erklärbaren Ähnlichkeit beruhen, wie etwa: „Dieser Benutzer entspricht dem allgemeinen Muster, das ich bei Benutzern beobachtet habe, die sich während der Arbeitszeit nie anmelden.“ In anderen Fällen basiert das Modell möglicherweise auf der Anwendung einer komplexen Reihe von Vektoralgebra-Operationen auf die Eingabedaten, ohne dass eine leicht erkennbare Logik auf höherer Ebene vorliegt. Dieser letzte Fall ist eindeutig weniger erklärbar – eher eine „Black Box“ – als die beiden vorherigen Beispiele. In manchen Fällen ist die Erklärbarkeit ein wichtiger Faktor für das menschliche Verständnis oder die Überprüfbarkeit. In diesen Fällen ist ein erklärbares Modell einem unergründlichen deutlich vorzuziehen. 
• Verfügbarkeit des Konfidenzscores: Wie bereits erwähnt, ist eine Metrik, die angibt, wie zuverlässig das Modell bei einer Entscheidung ist – mit anderen Worten, ein Gefühl für die relative Wahrscheinlichkeit eines falsch positiven oder falsch negativen Ergebnisses – oft sehr nützlich. Bei manchen Algorithmen ergibt sich automatisch eine Ausgabe einer Konfidenzmetrik. Bei anderen, z. B. regelbasierten, müsste ein Konfidenzniveau explizit als eine der Ausgaben angegeben werden. In beiden Fällen sind Algorithmen, die einen Vertrauenswert liefern können, robuster als solche, die dies nicht können. 

Wie beim regelbasierten Ansatz kann die ML-Unterstützung nur der Erkennung dienen oder mit einer automatischen Behebung verknüpft sein. Darüber hinaus kann ML-Unterstützung in Verbindung mit einem regelbasierten System verwendet werden, bei dem das ML-„Urteil“ (oder die Meinung oder Zuversicht) als Eingabe für eine Regel verwendet werden kann, z. B. „Aktion <X> ausführen, wenn <ML-Evaluator [Bot-Detektor_A] Bot mit einer Zuversicht von über 90 % meldet>.“ 

Der letzte Grundsatz der Zero-Rost-Mentalität besteht darin, „von einem Verstoß auszugehen“. Um es klar zu sagen und eine Perspektive zu schaffen: Richtig implementierte Authentifizierungs- und Zugriffskontrollmethoden können die überwiegende Mehrheit böswilliger Transaktionen wirksam verhindern. Man sollte jedoch aus purer Paranoia davon ausgehen, dass die Durchsetzungsmechanismen der Authentifizierung und Zugriffskontrolle von einem ausreichend motivierten oder glücklichen Gegner umgangen werden können . Das Erkennen von Sicherheitsverletzungen, das für eine rechtzeitige Reaktion auf diese Ausbrüche erforderlich ist, erfordert Transparenz und maschinengestützte Analyse. Da die anderen Durchsetzungsmechanismen gelegentlich außer Kraft gesetzt werden, sind die Technologien zur Sichtbarkeit, die die ML-gestützte Kontextanalyse speist, von entscheidender Bedeutung, um die Zero-Trust-Sicherheits-Backstop-Lösung zur risikobasierten Behebung zu unterstützen. 

In den Fällen eines „falsch-negativen“ Ergebnisses, in denen eine tatsächlich böswillige Transaktion die Authentifizierung und Zugriffskontrolle umgangen hat, sollte der Mechanismus der automatisierten, risikobasierten Abhilfe als Sicherheitsmaßnahme verwendet werden. Da diese Technologie jedoch als Sicherheitsmaßnahme gegen Transaktionen eingesetzt wird, die die vorherigen Durchsetzungsprüfungen bestanden haben, besteht ein größeres Problem hinsichtlich der irrtümlichen Kennzeichnung einer in Wahrheit „echt negativ“ (eine gültige, erwünschte Transaktion) in eine „falsch positiv“ (fälschlich als böswillig gekennzeichnete Transaktion) umgewandelten Transaktion. Um diese Bedenken auszuräumen, sollten alle Abhilfemaßnahmen, die durch den Verdacht einer möglichen Böswilligkeit ausgelöst werden, die aus irgendeinem Grund nicht durch die Authentifizierung oder Zugriffskontrolle erkannt wurde, auf den folgenden drei Faktoren basieren:⁴

• Geschäftswert der Transaktion: Unterschiedliche Transaktionen sind mit unterschiedlichen Risiken und Erträgen verbunden. Beispielsweise ist eine Transaktion mit Zugriff auf ein Bankkonto weniger riskant als eine Transaktion, bei der Geld auf ein ausländisches Konto überwiesen wird. Für eine Fluggesellschaft ist es beispielsweise wahrscheinlicher, dass der Kauf eines Tickets eine Transaktion mit höherer geschäftlicher Rendite darstellt als eine Transaktion, bei der aktuelle Flugverspätungen aufgeführt werden. Der Geschäftswert ist der Nutzen des potenziellen Geschäftserfolgs im Vergleich zum Risikoprofil der Transaktion. Bei Transaktionen mit geringer Rendite und hohem Risiko ist es akzeptabler, etwaige „falsch positive“ Effekte aus spekulativen Sanierungsmaßnahmen zu tolerieren als bei Transaktionen mit hoher Rendite und geringem Risiko, die einen hohen Geschäftswert haben. 
• Vertrauen in den Glauben an „Boshaftigkeit“: Natürlich sind nicht alle Vorschläge zur spekulativen Sanierung gleich. Neben dem oben genannten Risiko-Ertrags-Verhältnis ist der andere Schlüsselfaktor insbesondere das Vertrauen in die Überzeugungen rund um die Transaktion, wie etwa das Vertrauen in die bestätigte Identität des Akteurs. Grob gesagt ist die Wahrscheinlichkeit eines „falsch-negativen“ Ergebnisses – also die Wahrscheinlichkeit, dass Durchsetzungsmechanismen nicht ausgelöst wurden, obwohl sie hätten ausgelöst werden sollen – umgekehrt proportional zum Vertrauen in den Akteur. Und da die Reduzierung von „falsch-negativen“ Ergebnissen das Ziel einer risikobasierten Sanierung ist, gilt: Je geringer die Zuverlässigkeit, desto eher sollte das System bei der Sanierung voreingenommen sein.
• Auswirkungen der Sanierung: Und schließlich handelt es sich bei Abhilfemaßnahmen nicht immer um binäre Entscheidungen (Zulassen oder Blockieren). Tatsächlich sind verschiedene Techniken zur Risikominderung möglich: von einigen, die für den Benutzer sichtbar sind (z. B. das Anfordern zusätzlicher Anmeldeinformationen/MFA, das Bereitstellen einer Herausforderung wie etwa eines Captchas), bis zu anderen, die für den Benutzer größtenteils unsichtbar sind (durchführen einer gründlicheren Verkehrsprüfung wie etwa DLP oder Durchführen einer fortgeschritteneren/rechenintensiveren Analyse). Daher ist die Auswirkung dieser zusätzlichen Formen der Risikominderung – gemessen an der vom Benutzer wahrgenommenen Reibung und den Betriebskosten für die Anwendung (beispielsweise für DLP oder rechenintensive Analysen) – der dritte zu berücksichtigende Faktor. Abhilfemaßnahmen mit geringer Auswirkung und für den Kunden transparenter Natur sind gegenüber schwerwiegenderen, für den Kunden sichtbaren Herausforderungen vorzuziehen, und die völlige Blockierung der Transaktion ist die am wenigsten attraktive Option. Eine Sperrung kann jedoch angebracht sein, wenn das Vertrauen hoch ist oder wenn es sich um riskante Transaktionen handelt, bei denen das Vertrauen durch andere Mechanismen zur Risikominderung nicht ausreichend erhöht werden kann. 

Zero-Trust-Sicherheit ist eine modernere Version früherer Sicherheitsansätze, wie z. B. Defense in Depth. Sie erweitert den Stand der Technik um eine transaktionszentrierte Sicht auf die Sicherheit – „ Wer versucht, wem was anzutun?“. Mit diesem Ansatz können Sie nicht nur den externen Zugriff auf eine Anwendung sichern, sondern auch die internen Komponenten der Anwendung schützen.⁵ Ausgehend von dieser grundlegenden transaktionalen Sichtweise basiert die Zero-Trust-Sicherheit auf einer Reihe von Kernprinzipien, die zum Schutz von Anwendungen in der heutigen, komplexeren und anspruchsvolleren Umgebung verwendet werden. Diese Prinzipien werden dann auf eine Reihe von Lösungen oder Methoden auf Subsystemebene abgebildet, die diese Prinzipien verkörpern. Die Kernprinzipien und ihre Umsetzung in Lösungsmethoden sind nachfolgend zusammengefasst. 

Diese Tools – die Methoden zur Authentifizierung, Zugriffskontrolle, Sichtbarkeit, Kontextanalyse und risikobewussten Behebung – sind notwendig und ausreichend, um eine Vielzahl von Angriffsarten zu verhindern.

Laden Sie den Bericht herunter