Fehlalarme bei Okta-Erkennungen: VPN, Mobilfunk, Tuning

TL;DR. Identitätserkennungen sind Heuristiken. Die häufigsten Fehlalarme stammen von Firmen-VPNs und Sicherheits-Gateways, die über Cloud-Netze ausgehen (Befunde zu Hosting-Anbietern und Sitzungen aus mehreren Netzen), von Telefonen, die zwischen WLAN und Mobilfunk wechseln (eine Sitzung, zwei ASNs) und von echten Helpdesk-Zurücksetzungen. Die häufigsten übersehenen Angriffe entstehen durch unvollständige Exporte, über viele IPs verteilte Angriffe und Techniken, die die Regeln noch nicht abdecken. Prüfen Sie jeden Befund mit den beteiligten Personen und lesen Sie ein sauberes Urteil als „nichts hat angeschlagen“, nie als „nichts ist passiert“.

Mir ist lieber, Sie vertrauen dem Analyzer etwas weniger und nutzen ihn gut. Diese Seite listet Regel für Regel, was er nicht sieht und wo er überreagiert.

Grenzen der Daten

90 Tage Aufbewahrung. Die System-Log-API liefert keine Ereignisse, die älter als 90 Tage sind (Okta Developer). Ein vor vier Monaten angelegter IdP oder die ersten Schritte eines langsamen Einbruchs sind im Export einfach nicht enthalten.
Gefilterte Exporte. Ein auf einen Benutzer eingeschränkter Export verpasst den Helpdesk-Mitarbeiter, der ihn zurückgesetzt hat, und den Admin, der ihn befördert hat. Exportieren Sie die gesamte Organisation.
Verspätete Ereignisse. Okta weist darauf hin, dass manche Ereignisse eines jüngeren Zeitraums verspätet eintreffen können. Exportieren Sie die letzten Stunden bei einem laufenden Vorfall später erneut.
Genauigkeit von CSV. Abgeflachte CSV-Dateien verlieren oder benennen Felder um. Der Analyzer liest Kopfzeilen mit LogEvent-Pfaden und _raw-Spalten; die abgeflachten Okta_CL-Spalten von Sentinel werden noch nicht abgebildet. Bevorzugen Sie API-JSON.
debugData ist kein Vertrag. Felder wie privilegeGranted, behaviors, risk, threatSuspected und tunnels unterscheiden sich zwischen Organisationen und Releases. Regeln, die sie lesen, können verstummen, wenn ein Feld umbenannt wird.
Kurze Historie, schwache Baselines. „Neues Netz für diesen Benutzer“ wird aus dem Export selbst berechnet. Bei zwei Tagen Historie ist jedes Netz neu.

Grenzen der Erkennungen

Die 25 Regeln sind mit ihren Schweregraden auf der Startseite aufgeführt. Was sie (noch) nicht leisten:

Nicht abgedeckt	Ausweg
Verteiltes Spraying über viele IPs (gruppiert wird pro IP)	Fehlschläge von Hand nach ASN und User-Agent gruppieren, siehe Password Spraying
Unmögliche Reisen / neues Land pro Benutzer	die Anmeldungen eines Benutzers in der Ereignistabelle nach Zeit sortieren
`risk = HIGH` oder `behaviors` als Erkennung	in den Ereignisdetails sichtbar; nach Benutzer filtern
Zustimmung zu OAuth-Apps und Missbrauch von Client Credentials	nach `app.oauth2.*`-Ereignissen suchen
Änderungen an Gruppen- und Routing-Regeln	die Admin-Sitzung des Angreifers vollständig prüfen
Neuer Benutzer angelegt und sofort zum Admin gemacht	`user.lifecycle.create` neben Befunden zu Admin-Vergaben prüfen
Jede Anmeldung über einen eingehenden IdP	`user.authentication.auth_via_IDP` für jeden neuen IdP auflisten
Was in nachgelagerten Apps geschah	die Logs der jeweiligen App verwenden

Fehlalarme, Regel für Regel

Anmeldungen von Hosting-Anbietern und Anonymisierern

access.hosting_provider sucht Schlüsselwörter in securityContext.asOrg und isp (Hosting, VPS, Rechenzentrum sowie die Namen großer Cloud- und Hosting-Anbieter). Die Regel schlägt an, wenn:

Ihr Firmen-VPN oder Secure Web Gateway über einen Cloud-Anbieter ausgeht;
Mitarbeitende ein privates VPN oder einen Datenschutz-Relay nutzen;
ein CI-System oder Skript sich interaktiv aus der Cloud anmeldet (was selbst ein Befund ist, den man beheben sollte).

access.anonymizer liest securityContext.isProxy und die tunnels-Daten in debugData. Aus Sicht von Okta sind kommerzielle VPNs Anonymisierer.

Feinabstimmung: Erfassen Sie die Ausgangs-IPs und -ASNs Ihres VPN und Ihrer Gateways vor dem Vorfall und gleichen Sie jeden Hosting-Befund zuerst damit ab. Zur Vorbeugung können Oktas erweiterte dynamische Zonen Anonymisierer-Kategorien blockieren und Ihre bekannten Netze zulassen.

Eine Sitzung, mehrere Netze oder Browser

session.multi_asn (hoch) und session.multi_user_agent (mittel) gruppieren Ereignisse über 12 Stunden nach externalSessionId. Legitime Ursachen:

Mobilgeräte, die zwischen WLAN und Mobilfunknetz wechseln (zwei ASNs, gleicher User-Agent);
VPN-Verbindung mitten in der Sitzung;
automatische Browser-Updates während einer langen Sitzung (zwei User-Agent-Kennungen, die sich nur in der Version unterscheiden);
Dual-Stack-Anbindung IPv4/IPv6, bei der beide Wege von unterschiedlichen ASNs angekündigt werden.

Feinabstimmung: Prüfen Sie, ob die zweite ASN ein Mobilfunkbetreiber oder Ihr VPN ist und ob sich die User-Agents nur in der Version unterscheiden. Ein anderes Betriebssystem oder eine andere Browserfamilie in einem Hosting-Netz ist der ernste Fall, wie in Session Hijacking erklärt. Denken Sie außerdem daran, dass externalSessionId nach Faktor-Lifecycle-Ereignissen neu erzeugt werden kann (Okta Security); eine wiederverwendete Sitzung kann also unter einer anderen Kennung erscheinen als die ursprüngliche Anmeldung. Pivotieren Sie auf authenticationContext.rootSessionId im rohen JSON oder in Ihrem SIEM.

MFA-Fatigue

mfa.push_fatigue zählt Sendungen ebenso wie Ablehnungen: fünf Pushes in 15 Minuten. Ein Benutzer mit mehreren Geräten oder mit Anmeldungen bei vielen Apps, die jeweils MFA verlangen, kann das erreichen. Prüfen Sie die Ergebnisse (alle bestätigt?) und das Quellnetz der auslösenden Anmeldungen. Details unter MFA-Fatigue erkennen.

Helpdesk-Zurücksetzen, dann Registrierung

mfa.helpdesk_reset_then_enroll schlägt auch bei jedem echten Ticket „Telefon verloren“ an; deshalb ist der Grundschweregrad hoch und nicht kritisch. Kritisch wird er, wenn die Registrierung aus einem Netz kommt, das der Benutzer vor dem Zurücksetzen nicht genutzt hat, von einem Proxy oder einem Hosting-Anbieter. Ein Benutzer, der sein neues Telefon von zu Hause aus registriert (wo er sich schon angemeldet hat), bleibt bei hoch. Ein Benutzer im Urlaub im Ausland wird hochgestuft: bestätigen Sie mit ihm. Siehe Social Engineering am Helpdesk.

Password Spraying und Passwort-Raten

access.password_spray braucht 8 oder mehr verschiedene Benutzer mit Fehlschlägen von einer IP innerhalb einer Stunde, bei durchschnittlich höchstens 3 Fehlschlägen pro Benutzer. Ein gemeinsames Büro-NAT nach einer Welle abgelaufener Passwörter kann in die Nähe kommen; die Erfolgsquote trennt beides. access.brute_force (10 Fehlschläge eines Benutzers in 15 Minuten) schlägt bei Skripten mit veralteten Zugangsdaten an, etwa einem alten Mail-Client, der es immer wieder versucht.

Änderungen an Admins, Richtlinien und IdPs

Rollenvergaben, API-Tokens, Richtlinienänderungen, IdPs und Sicherheitseinstellungen werden unabhängig vom Urheber gemeldet, weil das Log eine geplante Änderung nicht von einer bösartigen unterscheiden kann. Die Schweregrade niedrig und mittel spiegeln das wider. Feinabstimmung: Gleichen Sie jede Änderung mit Ihren Change-Tickets ab. Eine Super-Administrator-Vergabe oder ein neuer IdP ohne Ticket ist ein Vorfall, bis er erklärt ist.

Eine Prüfroutine für jeden Befund

Wer ist der Akteur, und ist es wirklich diese Person? Rufen Sie unter einer bekannten Nummer an.
Von wo? ASN, Land und User-Agent im Vergleich zur Historie des Benutzers.
Was folgte? Die Ereignisse nach dem Befund: Admin-Aktionen, Registrierungen, SSO.
Gibt es einen Nachweis? Ticket, Änderungsantrag, Dienstreise.
Entscheiden und dokumentieren Sie im Bericht, mit den uuids der Ereignisse.

Wenn das Urteil sauber ist

Gleichen Sie Zeitraum, Anzahl der Ereignisse und Benutzer in der Statistikzeile mit Ihren Erwartungen ab. Wirkt etwas zu knapp, korrigieren Sie den Export und starten Sie erneut. Ist er vollständig und sauber, ist das eine nützliche Information, aber keine Garantie. Bewahren Sie den Export auf und prüfen Sie Oktas HealthInsight-Empfehlungen für Ihre Organisation.

FAQ

Warum erscheint mein Firmen-VPN als Hosting-Anbieter?

Viele VPN-Dienste und Secure Web Gateways gehen über Cloud- oder Rechenzentrumsnetze ins Internet. Der Organisationsname ihrer ASN trifft dieselben Schlüsselwörter wie ein VPS-Anbieter. Ermitteln Sie Ihre Ausgangs-ASNs und prüfen Sie diese zuerst.

Kann der Analyzer einen Angriff übersehen?

Ja. Er sieht nur die exportierten Ereignisse, nutzt feste Schwellenwerte und deckt noch nicht jede Technik ab. Ein sauberes Urteil bedeutet, dass keine seiner Regeln zutraf, nicht dass nichts passiert ist.