Kontinuierliches Zero-Trust-Modell

Die Zero-Trust-Architektur basiert auf dem Prinzip „Nie vertrauen, immer überprüfen“. In der Praxis überprüfen die meisten Zero-Trust-Implementierungen die Identität am Zugriffspunkt: Wenn sich ein Benutzer anmeldet, werden seine Anmeldedaten und der Sicherheitsstatus seines Geräts überprüft, und der Zugriff wird auf der Grundlage dieser momentanen Bewertung gewährt oder verweigert. Die Lücke besteht in allem, was zwischen den Anmeldevorgängen geschieht. Ein Mitarbeiter, der sich um 9 Uhr morgens mit einwandfreien Anmeldedaten erfolgreich authentifiziert, könnte genau diese Anmeldedaten bereits um 8 Uhr morgens durch Infostealer-Malware gestohlen bekommen haben. Die Policy-Engine weiß davon nichts, da sie die Identität nur bei der Anmeldung bewertet hat. Ein Angreifer, der um 10 Uhr morgens das gestohlene Sitzungs-Cookie dieses Mitarbeiters auf einem kriminellen Marktplatz erwirbt, kann es in einer authentifizierten Sitzung wiederverwenden, die die Zero-Trust-Richtlinie niemals als verdächtig einstuft, da die ursprüngliche Authentifizierung legitim war. NIST 800-207 definiert Zero Trust als eine Anforderung an die kontinuierliche Validierung, nicht nur an die Validierung zum Zeitpunkt der Anmeldung. Die meisten Implementierungen erfüllen diese Anforderung nicht, da sie über keinen Mechanismus für Anzeichen einer Kompromittierung nach der Anmeldung verfügen. SpyCloud schließt diese Lücke, indem es kontinuierlich aus dem Darknet stammende Informationen zu Anmeldedaten, Cookies und Malware-Infektionen in die Policy-Engine einspeist, sodass Zugriffsentscheidungen in Echtzeit an das angepasst werden können, was Kriminelle tatsächlich in ihren Händen halten.

SpyCloud lässt sich direkt in die drei führenden Identitätsplattformen für Unternehmen integrieren. In Okta-Umgebungen nutzt Okta Workforce Guardian Okta Workflows, um die Passwörter der Mitarbeiter kontinuierlich mit den von SpyCloud wiedergewonnenen Darknet-Daten abzugleichen und bei bestätigter Gefährdung automatisch Passwort-Resets, die Aufhebung aktiver Sitzungen, die Deaktivierung von Konten oder Änderungen an den adaptiven Authentifizierungsrichtlinien auszulösen. In Microsoft Entra ID-Umgebungen läuft Entra ID Guardian in einem Azure-Container und lässt sich in Microsoft Defender und Sentinel integrieren, um die Sicherheit von Anmeldedaten zu gewährleisten und neben den bestehenden Telemetriedaten von Entra ID Protection auch Signale für Malware-bezogene Sicherheitsrisiken aufzudecken. Für lokale Active-Directory-Umgebungen läuft „Active Directory Guardian“ lokal auf einem Domänencontroller oder Mitgliedsserver, überprüft AD-Anmeldedaten anhand des von SpyCloud zurückgewonnenen Datensatzes – einschließlich IDLink-Analysen, die die Wiederverwendung von Passwörtern aus dem privaten und beruflichen Bereich aufdecken – und löst innerhalb von fünf Minuten nach einer bestätigten Übereinstimmung automatische erzwungene Zurücksetzungen aus. Alle drei Integrationen leiten die Risikoindikatoren von SpyCloud als kontinuierlichen Input und nicht als einmalige Warnmeldung an die Richtlinien-Engine weiter – dies entspricht der operativen Definition der kontinuierlichen Überprüfung in einer Zero-Trust-Architektur.

Die kontinuierliche Identitätsüberwachung von SpyCloud erfüllt die Anforderungen mehrerer Rahmenwerke, die eine fortlaufende Überprüfung von Anmeldedaten und Identitäten vorschreiben. NIST SP 800-207 (Zero-Trust-Architektur) definiert einen Vertrauensalgorithmus, der die Identität des Benutzers und den Sicherheitsstatus des Geräts kontinuierlich bewerten muss, anstatt die anfängliche Authentifizierung als ausreichend anzusehen – SpyCloud liefert die Darknet-Telemetriedaten, die den meisten Zero-Trust-Implementierungen in diesem Algorithmus fehlen. NIST SP 800-63B, Abschnitt 5.1.1.2, schreibt eine kontinuierliche Überwachung anhand regelmäßig aktualisierter Listen kompromittierter Anmeldedaten mit automatisierten erzwungenen Zurücksetzungen vor – Identity Guardians erfüllt diese Anforderung direkt mit exportierbarer Audit-Dokumentation für Compliance-Bewertungen. Die Funktionen „Govern“ und „Detect“ des NIST CSF 2.0 erfordern eine kontinuierliche Überwachung von Bedrohungen und Sicherheitslücken – die Datenfeeds von SpyCloud zu Sicherheitsverletzungen, Malware und Phishing erfüllen diese Anforderung. Die CIS-Kontrollen v8, Kontrolle 5 (Kontoverwaltung) und Kontrolle 6 (Zugriffskontrollmanagement), verlangen von Organisationen, unbefugten Zugriff zu unterbinden und von Malware betroffene Konten zu sanieren – SpyCloud automatisiert beides. Sowohl DORA als auch NIS2 verlangen von regulierten Unternehmen im EU-Finanzdienstleistungssektor und im Bereich kritischer Infrastrukturen den Nachweis einer kontinuierlichen Bedrohungsüberwachung und einer schnellen Behebung identitätsbezogener Sicherheitslücken.

SpyCloud ersetzt weder ZTNA-Anbieter noch Identitätsanbieter oder bestehende Komponenten einer Zero-Trust-Architektur. Es stellt die Ebene für Informationen zur Identitätsgefährdung bereit, die diese Systeme als Eingabe benötigen, aber nicht selbst generieren können. ZTNA-Plattformen (Zscaler, Cloudflare, Palo Alto Prisma Access und andere) treffen Entscheidungen zu Zugriffsrichtlinien auf der Grundlage der Benutzeridentität, des Gerätestatus und von Signalen aus dem Netzwerkkontext. Identitätsanbieter (Okta, Entra ID, Ping Identity) authentifizieren Benutzer und verwalten den Lebenszyklus der Zugriffsrechte. Keine der beiden Kategorien hat Einblick in die kriminelle Unterwelt, in der gestohlene Anmeldedaten, Sitzungs-Cookies und Malware-Protokolle zirkulieren, bevor Angriffe stattfinden. Die Aufgabe von SpyCloud besteht darin, Echtzeit-Nachweise für Identitätskompromittierungen aus dieser kriminellen Unterwelt in die Richtlinien-Engine einzuspeisen, damit Zugriffsentscheidungen widerspiegeln, worüber Angreifer tatsächlich verfügen – und nicht nur, was die internen Systeme des Unternehmens beobachten können. Eine Zero-Trust-Architektur ohne diese externen Kompromittierungssignale arbeitet auf der Grundlage unvollständiger Informationen. SpyCloud schließt genau diese Lücke, während alle anderen Zero-Trust-Komponenten unverändert bestehen bleiben.

Eine Kompromittierung auf Session-Ebene ist der Angriffsvektor, der die Lücke bei reinen Anmeldeverfahren in Zero-Trust-Implementierungen am direktesten ausnutzt. Wenn durch eine Infostealer-Malware-Infektion oder einen AitM-Phishing-Angriff die aktiven Session-Cookies und Refresh-Token eines Mitarbeiters gestohlen werden, verfügt der Angreifer über eine gültige, authentifizierte Sitzung, die von der Zero-Trust-Policy-Engine als legitim angesehen wird, da sie aus einer erfolgreichen Anmeldung stammt. Das Gerät des Mitarbeiters besteht weiterhin die Sicherheitsüberprüfungen. Die Anmeldedaten sind nach wie vor gültig. Nichts in der internen Umgebung deutet auf ein Problem hin. SpyCloud erkennt die Kompromittierung der Sitzung extern, von der Seite der Kriminellen aus: indem es die gestohlenen Sitzungsartefakte aus kriminellen Märkten und Vertriebskanälen für Infostealer-Malware vor oder während des Zeitfensters, in dem der Angreifer sie besitzt, wiedererfasst. Wenn eine Übereinstimmung bestätigt wird, weist SpyCloud den Identitätsanbieter an, das Aktualisierungstoken zu widerrufen, die SSO-Sitzung auf IdP-Ebene zu beenden (was sich auf alle nachgelagerten Anwendungen in der SSO-Instanz auswirkt) und eine erneute Authentifizierung zu erzwingen. Dies ist der einzige Abhilfepfad, der einen Angreifer, der Token nach der Authentifizierung erbeutet hat, vollständig entfernt, und er erfordert eine externe Intelligence-Ebene, über die Zero-Trust-Richtlinien-Engines von Haus aus nicht verfügen.