Der Weg in ein Unternehmen führt heute über gültige Zugangsdaten, erbeutet aus einem Leak, abgefischt per Phishing oder beim Helpdesk erfragt. Was danach passiert, sieht aus wie normaler Betrieb: ein Konto meldet sich an, ein Administrator greift auf einen Server zu, ein Dienstkonto liest eine Freigabe. Deshalb greifen klassische Kontrollen zu spät. Es gibt keine Schadsoftware, die auffällt, und keinen Alarm, der eindeutig ist.
Bei diesem Tempo liegen zwischen erster Anmeldung und Domain-Admin-Rechten Minuten. Wer identitätsbasierte Angriffe erst im Report am Folgetag findet, ist zu spät dran.
Derselbe Angriff, dieselbe Lizenz, dieselben Erkennungen. Der Schalter wechselt zwischen zwei Zuständen: dem Modul direkt nach der Inbetriebnahme, aktiv, aber ohne durchgesetztes Regelwerk, und dem Modul so, wie wir es übergeben.
Beide Zustände zeigen dieselbe Plattform. Was sie unterscheidet, ist das Regelwerk dahinter und die Frage, ob nachts um drei jemand auf den Alarm reagiert.
CrowdStrike Falcon Identity Threat Protection ist das ITDR-Modul der Falcon-Plattform. Es prüft den Authentifizierungsverkehr in Active Directory und Entra ID in Echtzeit, bewertet jede Identität nach Risiko und kann bei verdächtigen Anmeldungen selbst eingreifen, bis hinunter auf Protokollebene.
Falcon Identity Protection räumt kein gewachsenes Berechtigungsmodell auf, ersetzt keine Privileged-Access-Lösung und nimmt Ihnen die Gruppenpflege nicht ab. Vor allem: Ohne konfiguriertes Regelwerk verhindert es nichts. Nach der Inbetriebnahme läuft das Modul beobachtend, es erkennt und protokolliert und wartet darauf, dass ihm jemand sagt, wann es eingreifen soll. Genau diese Arbeit ist das eigentliche Projekt.
Sie können an jeder Stelle einsteigen und an jeder Stelle aufhören. In der Praxis folgt aber eines auf das andere: Erst sehen, was da ist. Dann festlegen, was passieren soll. Dann dafür sorgen, dass jemand reagiert.
Wir binden Identity Protection an Ihr Verzeichnis an und werten aus, was dabei sichtbar wird: privilegierte Konten ohne erkennbare Notwendigkeit, Dienstkonten mit zu weiten Rechten, verwaiste und inaktive Konten, Passwörter aus bekannten Leaks, schwache Protokollnutzung sowie die Pfade, über die sich ein Angreifer von einem beliebigen Konto bis zu Domain-Admin-Rechten bewegen könnte. Der Aufwand auf Ihrer Seite bleibt gering; die Auswertung machen wir.
Wir übersetzen die Befunde in Policy-Regeln: welche Bedingung welche Reaktion auslöst, für welche Kontotypen, mit welchen Ausnahmen. Jede Regel läuft zuerst im Simulationsmodus gegen echten Anmeldeverkehr. So wird vor der Durchsetzung sichtbar, wen sie treffen würde und wie oft. Erst danach wird scharf geschaltet, stufenweise und beginnend bei privilegierten und Dienstkonten, wo der Sicherheitsgewinn am größten und der betroffene Kreis am kleinsten ist.
Unser Praxisleitfaden zu Identity Protection: Voraussetzungen, das Vorgehen beim Testen von Regeln und ausgearbeitete Anwendungsfälle aus echten Projekten, von der Härtung administrativer Konten bis zur Ransomware-Prävention auf Dateiservern. Geschrieben für Teams, die selbst Hand anlegen wollen.
Ein scharfes Regelwerk erzeugt Alarme. Jemand muss sie nachts um drei bewerten und darauf reagieren, bis hin zum Sperren eines Kontos oder zum Isolieren eines Systems. Das übernimmt unser Managed CSIRT: deutschsprachig, rund um die Uhr besetzt und mit einem BSI-gelisteten DFIR-Team im Rücken, falls aus dem Alarm ein Vorfall wird.
Eine Regel, die zu scharf steht, blockiert am Montagmorgen die Produktion. Eine, die zu weich steht, ändert nichts. Zwischen diesen beiden Fehlern liegt die eigentliche Arbeit, und sie lässt sich nicht aus einer Herstellerdokumentation abschreiben, weil sie von Ihrer Umgebung abhängt.
Welche Regeln in welcher Reihenfolge zu Ihrer Umgebung passen, steht nicht auf dieser Seite. Das ist der Teil, den wir mitbringen.
Identity Protection sichert das Verzeichnis, an dem die Anmeldung hängt. Falcon Shield sichert die Konten und Rechte innerhalb Ihrer SaaS-Anwendungen. Beides betrifft Identitäten, löst aber unterschiedliche Probleme und wird regelmäßig verwechselt.
Die meisten Unternehmen brauchen beides. Wer sich für eines entscheiden muss, fängt beim Verzeichnis an, denn dort hängt am Ende auch der Zugang zu den Anwendungen. Falcon Shield ansehen
MFA schützt die Anmeldewege, an denen es aktiviert ist, in der Praxis meist die Cloud-Anmeldung. Der interne Verkehr bleibt davon unberührt: RDP auf einen Server, ein Zugriff auf eine Dateifreigabe, eine Anmeldung über ein älteres Protokoll. Dort setzt Identity Protection an, und zwar risikobasiert, also nur bei auffälligen Anmeldungen. Eine Privileged-Access-Lösung ersetzt es dabei nicht, es beantwortet eine andere Frage.
Wir haben unsere Projekterfahrung mit Identity Protection in einen Praxisleitfaden geschrieben: Voraussetzungen, ein belastbares Testvorgehen und ausgearbeitete Anwendungsfälle mit Auslöser, Aktion und Bedingungen. Also das, was Teams beim Aufbau eines Regelwerks tatsächlich brauchen.
