CrowdStrike erkennt ein Risiko auf einem Endgerät. Zscaler entscheidet, ob dieses Gerät auf Internetdienste oder private Anwendungen zugreifen darf. Technisch können beide Plattformen Kontext austauschen. Operativ beginnt damit erst die eigentliche Arbeit.
Denn ein Gerätesignal ist noch keine fertige Geschäftsentscheidung. Ein zu niedriger Schwellenwert kann riskante Geräte weiterarbeiten lassen. Ein zu strenger Wert kann legitime Nutzer aus kritischen Anwendungen aussperren. Und eine automatische Reaktion ohne Owner, Ausnahmeweg und Rückkehrkriterium erzeugt im Incident mehr Chaos als Schutz.
Eine gute Integration verbindet deshalb drei Ebenen: Signal, Policy und Betrieb.
Welche Signale tatsächlich nutzbar sind
Die Zscaler-CrowdStrike-Integration unterstützt mehrere Use Cases. Dazu gehören gerätebezogene Posture Checks, der Austausch von Bedrohungsinformationen, Sandbox- und Endpoint-Kontext, Telemetrie für Erkennung sowie koordinierte Reaktionen.
Für adaptive Zugriffsentscheidungen ist besonders der Gerätezustand relevant. Zscaler dokumentiert, dass ein CrowdStrike-ZTA-Score in Device-Posture-Profilen verwendet werden kann. Ein definierter Mindestwert entscheidet dann mit darüber, ob eine Posture-Prüfung besteht.
Das klingt einfach, wirft aber wichtige Fragen auf:
- Für welche Anwendungen ist der Score relevant?
- Welche Sensor- und Client-Versionen werden vorausgesetzt?
- Was passiert bei fehlendem oder verzögertem Signal?
- Gilt derselbe Schwellenwert für alle Nutzergruppen?
- Welche Handlung folgt auf ein Unterschreiten?
- Wie gelangt ein bereinigtes Gerät zurück in den Normalzustand?
Vom Score zur fachlichen Risikoklasse
Ein einzelner globaler Schwellenwert wird heterogenen Umgebungen selten gerecht. Ein Entwicklerzugang zu einem Quellcode-Repository, eine Verwaltungsanwendung und ein öffentliches Intranet haben unterschiedliche Schutzbedarfe.
Deshalb sollte die Architektur Anwendungen und Nutzergruppen in Risikoklassen einteilen. Für jede Klasse wird festgelegt:
- welche CrowdStrike-Signale erforderlich sind,
- welche Mindestwerte gelten,
- ob ein fehlendes Signal blockiert oder eingeschränkt behandelt wird,
- welche alternative Arbeitsmöglichkeit existiert,
- wer eine Ausnahme genehmigen darf,
- wann eine erneute Bewertung erfolgt.
So wird aus einem technischen Wert eine nachvollziehbare Access Policy.
Vier mögliche Reaktionen – nicht nur Blockieren
Eine Integration muss nicht jede Abweichung mit einer vollständigen Sperre beantworten. Je nach Risiko sind abgestufte Reaktionen sinnvoll.
Beobachten: Das Signal wird protokolliert und korreliert, ohne den Zugriff zu verändern. Diese Stufe eignet sich für Baselines und Tests.
Einschränken: Das Gerät erhält nur Zugriff auf definierte Dienste, beispielsweise Remediation, Helpdesk oder Softwareverteilung.
Zusätzlich prüfen: Eine stärkere Authentisierung, eine manuelle Freigabe oder ein zusätzlicher Kontext wird verlangt.
Blockieren oder isolieren: Bei hohem Risiko wird der Zugriff auf geschützte Anwendungen entzogen oder das Gerät in einen kontrollierten Zustand versetzt.
Die passende Reaktion hängt nicht nur vom Gerätescore ab. Identität, aktive Sicherheitsereignisse, Anwendungskritikalität und vorhandene Kompensationsmaßnahmen gehören in die Entscheidung.
Der Ausnahmeweg ist Teil der Sicherheitsarchitektur
Kein Signal ist unfehlbar. Sensorprobleme, Netzwerkstörungen, Versionsunterschiede oder ein verzögerter Status können zu Fehlentscheidungen führen. Ohne geplanten Ausnahmeweg entstehen informelle Umgehungen.
Ein sauberer Ausnahmeprozess enthält:
- eindeutigen Antragsteller und fachlichen Owner,
- dokumentierten Grund,
- begrenzten Geltungsbereich,
- Ablaufzeitpunkt,
- kompensierende Kontrollen,
- erneute technische Prüfung,
- vollständige Auditspur.
Ausnahmen sollten nicht als dauerhafte Benutzerliste enden. Sie sind zeitlich begrenzte Risikobehandlungen.
Das Runbook für den Moment der Sperre
Wenn ein Nutzer plötzlich keinen Zugriff mehr erhält, müssen Helpdesk, SOC und Plattformteam dieselbe Geschichte sehen.
Das Runbook sollte mindestens beantworten:
- Welches Signal hat die Entscheidung ausgelöst?
- Welcher Score oder Incident-Kontext lag vor?
- Welche Zscaler-Policy hat reagiert?
- Welche Anwendungen sind betroffen?
- Ist das Gerät in CrowdStrike bereits enthalten oder in Untersuchung?
- Wer darf die Einschränkung aufheben?
- Welcher Nachweis beendet den Vorgang?
Ohne diese Kette wird ein Security-Event zu einem gewöhnlichen „Zugriff geht nicht“-Ticket. Der Helpdesk sucht dann an der falschen Stelle, während das SOC den Nutzerkontext nicht kennt.
Erst beobachten, dann scharf schalten
Die Einführung sollte mit Telemetrie und Simulation beginnen. Welche Geräte würden einen geplanten Schwellenwert nicht erreichen? Welche Nutzergruppen wären betroffen? Welche Versionen oder Standorte liefern kein stabiles Signal?
Ein kontrollierter Pilot umfasst:
- technische Voraussetzungen und Lizenzen,
- kleine, repräsentative Nutzergruppe,
- definierte Anwendungen,
- anfänglichen Beobachtungsmodus,
- gemeinsam getestete Reaktionen,
- Helpdesk- und SOC-Runbooks,
- messbare Erfolgskriterien.
Erst wenn Signalqualität, Zuständigkeiten und Rückkehrprozess funktionieren, sollte die Policy breiter durchgesetzt werden.
Der Integrationswert liegt im gemeinsamen Betriebsmodell
Zscaler und CrowdStrike stellen technische Integrationsmöglichkeiten bereit. Der geschäftliche Nutzen entsteht jedoch nicht automatisch durch das Aktivieren einer API.
Er entsteht, wenn Security Architecture, Endpoint-Team, Access Management, SOC und Helpdesk dieselben Risikoklassen, Reaktionen und Nachweise verwenden. Dann wird aus isolierter Telemetrie eine kontrollierte Entscheidung: riskante Geräte verlieren gezielt Zugriff, bereinigte Geräte kehren nachvollziehbar zurück, und legitime Nutzer werden nicht durch undokumentierte Automatik ausgebremst.