4:37 Uhr morgens. Jemand versuchte, sich zum sechsten Mal in neunzig Sekunden in Sarah Chens Konto anzumelden.
MFA-Fatigue-Kampagnen funktionieren nach einem einfachen Prinzip: Irgendwann tippt jemand auf „Genehmigen“, nur um die Benachrichtigungen zum Stoppen zu bringen. Es funktionierte. Der Angreifer war drin.
Der erste Schritt war unauffällig – SMS-Authentifizierung deaktivieren, eine kleine Einstellungsänderung, die leicht zu übersehen ist, wenn man eine lange Warteschlange hat, und genau das, was Raum zum Arbeiten schafft, ohne einen Alarm auszulösen. Dann kam die eigentliche Arbeit: AWS-Anmeldedaten aus einem System, SSH-Schlüssel aus einem anderen und ein langsames und methodisches Abrufen von internem Quellcode.
All das geschah, während Sarah schlief, während die Nachtschicht eine Warteschlange überwachte, die dies noch nicht als dringend kennzeichnete, während niemand mit dem Kontext, um „SMS deaktiviert“ mit „Anmeldedaten abgerufen“ mit „Quellcode zugegriffen“ zu verbinden, wach war, um es in Echtzeit zu sehen.
Als die Sonne aufging, war es vorbei. Der Angreifer hatte, was er wollte.
Schauen wir uns zwei Möglichkeiten an, wie dies ablaufen könnte.
Die alte Methode: Vier Stunden Warteschlangen, Handoffs und Browser-Tabs
4:39 Uhr morgens. Sumo Logic Cloud SIEM korrelierte diese Ereignisse zu einem einzigen Insight.
5:00 Uhr morgens. Das SOC-Team nimmt die Warteschlange auf, die diesen Alert und Dutzende andere enthält.
5:21 Uhr morgens. Edwin, ein Analyst der Stufe eins, öffnet den Alert und überprüft die Grundlagen: Hat sich dieses Konto von hier aus schon mal angemeldet? Hat MFA schon mal so reagiert? Nichts schließt es aus, also geht es in den Stapel „genauer ansehen“, während der Analyst zum nächsten Alert übergeht.
7:08 Uhr morgens. Am Vormittag ist es endlich an der Reihe, genauer hinzuschauen. Untersuchen bedeutet, zwischen Tools zu wechseln, die nicht miteinander kommunizieren: der Identitätsanbieter für MFA-Verlauf, das SIEM für korrelierte Ereignisse, ein Chat-Tool, um zu überprüfen, was ein Dateiname tatsächlich sagte, und eine separate Suche für die beteiligten IPs. Der Analyst ist die Integrationsstufe. Sie kopieren Werte von einem Bildschirm, fügen sie in einen anderen ein und verfolgen, was übereinstimmt, von Hand. Nur das Ausschließen von „der Benutzer hat sein Passwort einfach vergessen“ kann leicht eine Stunde dauern.
Wenn die SMS-Authentifizierungsänderung erkannt wird, und in einer vollen Warteschlange ist eine Einstellungsänderung genau das, was durchrutscht, wird das Ticket normalerweise an Stufe zwei weitergeleitet. Ein Handoff, ein Warten auf Warteschlangen-Platz, dann Bestätigung der Exfiltration, Verfolgung, welche Anmeldedaten offengelegt wurden, und Verfassen des Incident Reports von Hand, größtenteils aus dem Gedächtnis, was überprüft wurde und in welcher Reihenfolge.
8:48 Uhr morgens. Mehrere Stunden, mehrere Handoffs und viele Browser-Tabs später ist die Untersuchung abgeschlossen. Der Job, richtig gemacht, dauert so lange. Genau deshalb gab es Triage: um sicherzustellen, dass nur die Alerts, die so viel Aufmerksamkeit überstehen konnten, sie bekamen.
KI führt uns direkt zur vollständigen Untersuchung
Erkennen, Triage, Untersuchen. Diese Pipeline führt seit einem Vierteljahrhundert Sicherheitsabläufe, aus einem einfachen Grund: tiefe Untersuchung war teuer, und Analysten waren knapp. Also baute die Branche einen schnellen Filter, um den teuren Schritt zu schützen. Das machte damals Sinn. Triage ist qualifizierte Arbeit, und die Ebenen und Warteschlangen, die um sie herum aufgebaut wurden, holten echten Wert aus der verfügbaren Aufmerksamkeit.
Aber Agenten werden um vier Uhr morgens nicht müde, und sie gehen nicht am Ende einer Schicht aus. Die Knappheit, die Rationierung notwendig machte, ist weg. Also, als Sumo Logic seinen ersten KI-Agenten für das SOC baute, den SOC Analyst Agent, zielten wir nicht darauf ab, die Triage zu beschleunigen. Wir wollten die Notwendigkeit dafür beseitigen.
Die DojoAI-Methode: Vier Minuten bis zum Urteil, vierzehn Minuten bis zum tieferen Verständnis und einem Report
4:39 Uhr morgens. Sumo Logic Cloud SIEM korrelierte diese Ereignisse zu einem einzigen Insight, und der SOC Analyst Agent begann automatisch mit seiner Untersuchung.
Er arbeitet wie ein erfahrener Analyst: beginnend mit einer Hypothese, entscheidend, welche Erklärung zuerst getestet werden soll, dann nach Beweisen suchend, die sie ausschließen würden. Jeder Test wird gegen Ihre Daten und gegen das gemessen, was für dieses Konto normal ist. Erklärungen, die fehlschlagen, werden verworfen, und der Agent sagt Ihnen, welche fehlgeschlagen sind und warum. Das Urteil ist nicht die erste Geschichte, die zu den Fakten passt, sondern die, die noch steht, nachdem die anderen eliminiert wurden.
Jeder wichtige Fund trägt seinen Beweis mit sich, sodass die Aussage über die MFA-Deaktivierung direkt auf das Deaktivierungsereignis selbst verweist. Was passiert ist, wird regeneriert, wenn Signale hinzugefügt oder entfernt werden, sodass sich die Geschichte bewegt, wenn sich die Beweise bewegen.
4:43 Uhr morgens. In weniger als fünf Minuten erreichte der SOC Analyst Agent ein Urteil: Die Aktivität war bösartig.
Edwin könnte die Untersuchung jetzt beenden, entscheidet sich aber stattdessen, ein paar zusätzliche Minuten zu nehmen, um die Ergebnisse des Agenten zu überprüfen, ein wenig tiefer zu graben und einen Report zu erstellen.
4:45 Uhr morgens. Zuerst das Wichtigste: den Explosionsradius verstehen.
Edwin, der zugewiesene Analyst, klickt auf Mobot, um tiefer einzusteigen. Der Kontext ist bereits geladen, daher setzt er dort an, wo der Agent aufgehört hat, nicht am Anfang.
Bevor er etwas fragt, schaut sich Edwin an, was der Agent bereits getan hat, und überfliegt die ausgeführten Abfragen und die dahinter stehenden Daten. Er könnte sie bearbeiten oder erneut ausführen, entschließt sich aber stattdessen, eine neue Suche zu starten.
Prompt eins: Nach verwandten Erkenntnissen suchen
4:47 Uhr „Nach verwandten Erkenntnissen suchen“
Um herauszufinden, ob dies schon einmal vorgekommen ist, kann er leicht pivotieren: gleiche Entität, gleicher Angriffsname, gleiche Signalregeln, gleiche MITRE-Taktiken oder Erkenntnisse, die im gleichen Zeitfenster aktiv sind. Die gleiche Entität zeigt, was der Angreifer als Nächstes getan hat. Gleiche Taktiken zeigen, ob jemand anderes die gleiche Behandlung erfährt.
Bei jeder Entscheidung, die Edwin trifft, zeigt sein Agent-Teamkollege weitere Züge auf, die es wert sind, erkundet zu werden.
Prompt zwei: Jeden Indikator auf einmal überprüfen
4:49 Uhr „Überprüfe jeden Indikator in dieser Erkenntnis gegen Threat Intelligence und sag mir, was übereinstimmt, was nicht, und warum es wichtig ist“
Anstatt sich durch Suchergebnisse einen Indikator nach dem anderen zu arbeiten, stellt Edwin die übergeordnete Frage und führt alle auf einmal aus. Mobot schlüsselt es auf: Welche Artefakte in dieser Erkenntnis zählen als Indikatoren, und welche Feeds – wie die von Sumo Logic vorkonfigurierten sowie alle benutzerdefinierten Ergänzungen – können tatsächlich darauf ansprechen. Dann berichtet es über jeden einzelnen, einschließlich derjenigen, die niemand überprüfen kann.
Prompt drei: Den Anmeldedaten folgen
4:52 Uhr „Zeige mir alle Authentifizierungsversuche mit den AWS-Service-Anmeldedaten in diesen Dateien.“
Mobot erfindet keine Antwort auf die wörtliche Frage. Slack hat die Dateinamen protokolliert, nicht die darin enthaltenen Anmeldedaten, daher kann kein Protokoll einen Login auf diese Datei zurückführen. Anstatt zu raten, sagt es das, bietet dann aber an, was es testen kann: AWS-Aktivität auf dem Konto nach der Exfiltration, Anmeldungen von unbekannten Adressen, Konsolen-Anmeldungen vom Proxy.
Bei jedem Schritt erhält Edwin auch eine Empfehlung. Hier lautet sie, die Anmeldedaten unabhängig davon als kompromittiert zu behandeln und sie heute zu rotieren.
Prompt vier: Einen Bericht erstellen
4:53 Uhr „Erstelle einen Bericht der Untersuchung.“
Was Mobot zurückgibt, ist eine Zusammenfassung für die Geschäftsleitung, eine Zeitleiste mit einer MITRE-Technik in jeder Zeile und jedem Signal, das ausgelöst wird. Dies ist ein Bericht, den Edwin an einen IR-Leiter oder einen Auditor übergeben kann.
Er verfolgt Sackgassen und dokumentiert die ausgeschlossenen Indikatoren, sodass ein Leser in sechs Monaten sieht, was verworfen wurde, nicht nur zu welchem Ergebnis man kam. Er zitiert auch seine Quellen und trennt, was Oktas eigener Sicherheitskontext ihm sagte, von dem, was ein Threat Feed ihm sagte, damit nichts so aussieht, als wäre es bestätigt, wenn es nicht ist. Und es endet mit einer nach Priorität geordneten Aktionsliste: Konto sperren, jeden Anmeldedaten in diesen Dateien rotieren, Rechts- und Compliance-Abteilung benachrichtigen – ein Kundenbank-Export ist erfolgt, und das bringt eine Benachrichtigungspflicht mit sich.
MTTR mit KI beschleunigen, der Sie vertrauen können
Das obige Beispiel ist hypothetisch, aber es ist bezeichnend für das, was Sumo Logic-Kunden (und unser eigenes SOC) jeden Tag erleben.
Mit dem SOC Analyst Agent sind Vertrauen und Transparenz eingebaut, da er auf den SIEM-Daten arbeitet, denen Sie bereits vertrauen:
- Jeder Schritt ist nachvollziehbar. Tool-Aufrufe landen im Audit-Event-Index, Erkenntnisse verlinken zurück zu ihren Quellsignalen, und jede Abfrage, die Mobot ausführt, öffnet sich direkt in der Log-Suche. Verdikt und Erkenntnisse sind auch über die Sumo Logic SIEM API verfügbar.
- Es argumentiert über mehr als eine Erkenntnis vor sich. Normalisierte Datensätze und Signale, die über Ihre Quellen hinweg korrelierten Entitäten, Ihre Threat-Intel-Feeds plus unsere, und Anreicherung wie Geolokalisierung, Benutzerverhalten und Asset-Details.
- Es handelt niemals von selbst, absichtlich. Ein Konto sperren, einen Schlüssel rotieren, einen Host isolieren – diese Entscheidungen bleiben bei Ihnen.
- Sie kontrollieren, was es automatisch untersucht, und es gibt eine Richtlinie für das, was passiert, sobald Sie Ihr zugesichertes Volumen erreichen.
Überzeugen Sie sich selbst
Bereit, den SOC Analyst Agent auszuprobieren? Melden Sie sich für unsere kostenlose Testversion an.
