Konvergenz von ITDR, PAM und IGA. Welcher der drei ist präsent, wenn der Angriff kommt?

Aber wie wird die Arbeit aufgeteilt? Privilegierte Zugriffsverwaltung und Identitätsgovernance und Administration kümmern sich um die Prävention: Sie entscheiden, wer Privilegien hält und wann diese verwendet werden dürfen. Die Aufgabe Identitätsbedrohungserkennung und Reaktion ist anders. Sie beobachtet und teilt Ihnen mit, wenn etwas bereits schiefgelaufen ist. Bündeln Sie alle drei in einer Konsole und darunter haben Sie immer noch drei separate Aufgaben.

Wir fanden heraus, wo diese Aufteilung zusammenbricht, indem wir Fremde bezahlten, um uns anzugreifen.

Was echte Angreifer erreicht haben

Wir führten ein verwaltetes Bug-Bounty-Programm über Bugcrowd gegen ein moderat gehärtetes Active Directory durch. Angriffe wurden von Personen eingereicht, die für Ergebnisse bezahlt wurden, anstatt eine Checkliste zu vervollständigen. DCSync, LSASS-Prozessdump und NTDS.dit-Zugriffssperrumgehung waren darunter. Wir stellten fest, dass 100% der von Standardbenutzern und IT-Administratorkonten durchgeführten Angriffe erkannt und verhindert wurden.

Aber in Fällen, in denen ein Hacker mit gültigen Domain-Admin-Anmeldedaten begann, waren die Angriffe erfolgreich, weil die Anfragen von diesem Konto die Anfragen waren, die ein Domain-Admin stellt. Dieser Fall gehört zu PAM. Herauszufinden, welche Konten zunächst versteckte Macht halten, gehört zu IGA.

Die Rollback-Wette zahlt sich nicht immer aus

Wir stoppten alles auf dieser Liste, während es noch versucht wurde, nicht hinterher. Dieser Unterschied ist wichtiger, als es klingt. Ein Angriff, der mittendrin gestoppt wird, wird nie zu einem Zwischenfall, den jemand untersuchen muss; es bringt den Namen Ihres Unternehmens niemals in die Schlagzeilen von Verstößen.

Einiges davon kann rückgängig gemacht werden: Eine Gruppenmitgliedschaft wiederherstellen, ein Passwort zurücksetzen, eine Delegierung entfernen, und Sie sind mehr oder weniger zurück am Anfang.

Aber bei einigen Angriffen funktioniert es nicht mehr. Nehmen Sie Certificate Services zum Beispiel. Eine Vorlage, mit der der Anforderer seinen eigenen alternativen Antragstellernamen angeben kann, stellt ein Zertifikat aus, das den Anforderer als jemand anderes benennt. Melden Sie sich an, benennen Sie ein privilegiertes Konto und gehen Sie mit einer Anmeldeinformation weg, die sich als solche authentifiziert.

Keiner der üblichen Fixes berührt das. Setzen Sie das Passwort zurück und das Zertifikat funktioniert immer noch. Beheben Sie die Vorlage und Sie haben nur den nächsten Angreifer gestoppt, nicht denjenigen, der bereits eine gültige Anmeldeinformation hält. Setzen Sie das Verzeichnis zurück und Sie haben es immer noch nicht berührt, weil das Privileg nie im Verzeichnis war. Es sitzt in einem Zertifikatspeicher, gültig bis zum Ablauf oder bis jemand dieses spezifische Zertifikat manuell widerruft.

An diesem Punkt sagt eine Warnung Ihnen nur, wo Sie graben müssen. Das Blockieren der Registrierung ist das Einzige, das es zuverlässig stoppt.

Wo jeder Teil seine Arbeit machen muss

PAM, IGA und ITDR sind nur in einem bestimmten Moment eines Angriffs wichtig. Wenn niemand jemals ein Konto als privilegiert gekennzeichnet hat, liegt das an IGA. Wenn für dieses Konto bereits eine dauerhafte Anmeldeinformation vorhanden war, war PAM das Einzige, das hätte stoppen können, was als nächstes kam. Wenn die Kompromittierung an beiden vorbeigegangen ist und begann, sich wie ein Angreifer zu verhalten, war ITDR die letzte Gelegenheit, sie zu fassen, bevor sie sich weiter fortbewegte.

Wie Netwrix hilft

Netwrix PingCastle und 1Secure bewerten die Identitätssicherheitslage, ordnen Ergebnisse MITRE ATT&CK zu und ordnen sie nach Risiko, sodass die Behebung damit beginnt, was tatsächlich schaden würde. Auf der Protokollebene blockiert patentierte Bedrohungsprävention NTDS.dit-Lesevorgänge, LSASS-Dumps und nicht autorisierte Replikationsanfragen direkt am Domain Controller, bevor sie erfolgreich sind. Netwrix Threat Manager erkennt und reagiert auf Bedrohungen, die nicht blockiert werden können. Und wenn etwas durchkommt, automatische AD-Gesamtstruktur-Wiederherstellung und granulare Rollback-Funktionen in AD, Entra ID und Okta stellen die Dinge wieder her, bis zum spezifischen Objekt, das geändert wurde.

Wenn Sie es gegen Ihr eigenes Verzeichnis sehen möchten, können wir das arrangieren. Kontaktieren Sie uns für eine Demo.