Identitäten spielen heute eine zentrale Rolle in modernen Angriffen. Techniken wie Credential Theft, Privilege Escalation, Lateral Movement und Missbrauch legitimer Konten spielen bei nahezu allen fortgeschrittenen Angriffsszenarien eine entscheidende Rolle. Entsprechend wichtig ist es, Anmeldeverhalten sichtbar zu machen, diese zu überwachen und Leitplanken zu definieren innerhalb derer sich Nutzer bewegen können.
Bevor wir tiefer in die Möglichkeiten von Falcon Identity Protection eingehen, ist es wichtig das Thema “Identity Security” einzuordnen, da je nach Hersteller und Produkt unterschiedliche Lösungen angeboten und Erwartungshaltungen geweckt werden.
Typischerweise geht es um die drei folgenden Begriffe, welche unterschiedliche Schwerpunkte haben. Kurz gesagt:
Falcon Identity Protection kann der letzten Kategorie zugeordnet werden, da hier der Fokus auf der Überwachung und dem Schutz von Identitäten liegt.
Zum Schutz von Active Directory Umgebungen wird der Falcon Sensor auf mindestens einem, im besten Fall aber auf allen Domain Controllern installiert. Für Enforcement-Regeln und volle Visibilität des Authentication-Traffics ist die Installation auf allen DCs erforderlich.
Kurz nach der Installation sollten sich die Dashboards mit Daten füllen und einen ersten Einblick in die AD-Hygiene ermöglichen. Interessant ist dann zunächst einmal die Konfiguration des Active Directories selbst, oftmals lässt sich eine gewachsene Active Directory Umgebung bereits durch kleine Anpassungen härten, was über einen niedrigeren Risk-Score messbar wird. Diese Metriken sind unter “Domain Security Overview” abrufbar:
Die Konfiguration der Domäne ist jedoch relativ statisch und große Veränderungen des Risk Scores werden in der Regel nur durch fehlende Patches verursacht. Bei den Usern hingegen entstehen Risiken deutlich dynamischer, da ohne Identity Security Lösung oftmals die Sichtbarkeit und Kontrollmechanismen fehlen.
Nach der Sensor-Installation werden die Risiken sehr schnell transparent, wir bekommen vordefinierte Reports zu den typischen Identity-Risiken der “normalen”, “Service-” und privilegierten Accounts, sowie der Endpoints:
Bis hierhin ist außer der Sensor-Installation noch keine weitere Konfiguration nötig gewesen. Für einen tieferen Einblick in das Verhalten der Nutzer ist es notwendig die Identity Security Policy anzupassen. Die Default-Policy ist bereits automatisch allen Domain Controllern zugewiesen. Bevor Änderungen an der Policy vorgenommen werden, gibt es zwei wichtige Punkte, die geprüft werden müssen:
NSX-Treiber können in Kombination mit der Traffic Inspection zu Problemen führen. Wir haben in einigen Umgebungen beobachtet, dass NSX-Treiber im Rahmen der Installation von VMware Tools mitinstalliert wurden. Daher sollte das System auf NSX-Treiber geprüft werden, auch wenn NSX nicht im Einsatz ist. Mehr Informationen dazu finden sich in diesem CrowdStrike KB Artikel. NSX Treiber lassen sich schnell mit einer Falcon SIEM Query identitfizieren:
event_platform=/Win/i #event_simpleName=/DriverLoad/i
| in(field=FileName,values=["vnetwfp.sys", "vnetflt.sys"],ignoreCase=true)
| join({$falcon/investigate:aid_master()}, field=aid, key=aid, include=[ProductType])
| ProductType=2
| "Domain Controller":=ComputerName
| LocalIP:=LocalAddressIP4
| Drivers:=FileName
| groupBy([aid,"Domain Controller",LocalIP,Drivers],function=[])Weiterhin sollten die Domain Controller nicht am CPU- und Memory Limit sein. CrowdStrike Identity Protection hat geringe Ressourcen Anforderungen, jedoch sollten auf dem Domain Controller genügend Reserven verfügbar sein. Überprüfen lässt sich das z.B. über Falcon Discover, unter “System Insights”:
Wenn die oben genannten Voraussetzungen erfüllt sind, kann die Identity Protection Policy angepasst werden. Hier ist es sinnvoll, schrittweise vorzugehen und die Änderungen nicht für alle Domain Controller gleichzeitig vorzunehmen.
Die folgenden Anpassungen sollten zunächst in einer Testumgebung umgesetzt werden. Falls es keine Testumgebung gibt, ist es empfehlenswert einen Domain Controller auszuwählen, der eine niedrigere Priorität in der Infrastruktur hat. Die Policy sollte immer nur für 1–2 Domain Controller pro Domäne angepasst werden. So kann über die kommenden Tage überprüft werden, ob es zu Performance Problemen oder Anmeldefehlern kommt. Nachdem der Pilotbetrieb erfolgreich verlaufen ist, können die übrigen DCs in eine Host-Gruppe aufgenommen werden und die selbe Policy erhalten.
Wir passen die Policy typischerweise in vier Phasen an:
Dabei ist es sinnvoll, die vier Policies zusätzlich zur Default-Policy zu erstellen und folgendermaßen zu konfigurieren:
Den Domain Controllern kann dann über die Host-Gruppe Schritt für Schritt eine restriktivere Policy zugewiesen werden. Sofern im Testbetrieb keine Probleme aufkommen, ist der Idealzustand mit Phase 4 erreicht. Phase 4 sollte dann auf allen Domain Controllern angewendet werden, um die volle Sichtbarkeit und Kontrolle zu gewährleisen.
Im nächsten Teil dieser Serie gehen wir auf die Erstellung von Enforcement-Policies ein, also dem Regelwerk, welches definiert, wie sich Identitäten verhalten dürfen.
Mit einem kostenlosen Identity Security Risk Review können wir unverbindlich die Mehrwerte von CrowdStrike ITP zeigen und mögliche Risiken in Ihrer Umgebung aufdecken.
Termin auswählen
Vom Exploit bis zur Defense: Echte Security-Insights aus unserem SOC und Research-Lab
