SOC-Automatisierung: Phase 1

In Fortsetzung unserer Serie Detection-as-Code (DaC) arbeiten wir mit einer neuen Implementierungstechnologie und stellen fest, wie unsere erste Phase die Zeit für die Ticketsuche erheblich verkürzt hat. Aber lassen Sie uns zunächst zusammenfassen, was wir zuvor behandelt haben. Wir haben diese Serie gestartet von dAC in der Praxis umsetzen und Integration unseres SIEM mit CI/CD. Dies legte die Grundlage für unser Security Operations Center, brachte aber auch neue Herausforderungen mit sich, indem zwei sehr komplexe Teile miteinander verbunden wurden. Nachdem wir Probleme mit der Skalierbarkeit gelöst haben und das Team in der neuen Infrastruktur geschult war, begannen wir unseren kontinuierlichen Kampf gegen Alert Fatigue. Wir haben den ersten Schritt getan, als wir viele unserer Prozesse automatisiert haben, und den zweiten Schritt, indem wir unseren Erkennungszyklus verbessert haben, um ihn in ein Datenkontrollsystem einzubinden. Sicherheitsbetriebszentrum (SOC). Jetzt ist es an der Zeit, über Schritt 3 zu sprechen, und meine Meinung nach dem unterhaltsamen Teil: SOAR Automation.

Was ist ein SOAR?

Ein SOAR ist eine Abkürzung für Sicherheitsorchestrierung, Automatisierung und Reaktion Werkzeug. Kurz gesagt, mit diesen Tools können Sie automatisierte Workflows für praktisch jede Lösung erstellen. Die Hauptanwendung fällt in Phase 1 unserer SOAR-Initiative, aber darin enthalten automatisierte Workflows für jede unserer SIEM-Erkennungen, um den Zeitaufwand zu verkürzen, die Sicherheitsanalyse für den Test eines Tickets.

Erfassung von Informationen

Wie in unserem vorherigen Artikel Becoming a Data-Drive SOC erwähnt, haben wir begonnen, Kennzahlen zu unseren Erkenntnissen zu sammeln, um unseren Lebenszyklus zur Verbesserung der Erkennung zu fördern. Dies wäre möglich, um nach Wissen zu suchen, denn unsere Analysten haben viel Zeit für sie, um zu studieren und Optionen zu identifizieren, um Zeit zu sparen. Wenn Sie sich richtig erinnern, ist eine der Metriken, die wir erheben, „Verwendete Ressourcen“. Dies ist ein Feld „Alle auswählen“ auf unseren Tickets, in dem ein Analyst ein beliebiges Tool überprüft hat, mit dem von Anfang bis Ende ein Ticket angezeigt wird. Oben nach unten können wir sehen, welche Tools am häufigsten für Erkennungen verwendet werden. Sie dienen als Ausgangspunkt für die Automatisierung unseres Aufklärungsprozesses.

Architektur

Lass mich zunächst den genauen Effekt beschreiben, den wir erzielen wollen. Unser aktueller Arbeitsablauf sieht vor, dass unser SIEM eine Erkennung auf der Grundlage eines Logs auslöst. Anschliessend wird ein Ticket an Slack und an Jira gesendet. Diese Tickets enthalten einen Titel, ein Runbook und einen Warnkontext (wichtige Informationen). In Phase 1 unserer Bemühungen wollen wir, dass unser SOAR in der Mitte unseres SIEM und Slack läuft. Unser SIEM würde auch die Warnung an unser SOAR senden, wodurch ein automatisierter Workflow gestartet würde, der darauf basiert, welche Erkennung ausgelöst wurde, automatisch Informationen sammelt, die zum Schließen des Tickets erforderlich sind, und füllt dann das Slack-Ticket mit den erweiterten Informationen. Das bedeutet, dass in einer perfekten Welt des Sicherheitsanalysten, der ein Ticket durchsucht, alle Daten, die zum Schließen eines Tickets benötigt werden, an einem Ort in Slack sein würde. Einfach, oder?

Bauen Sie es aus

Der erste Schritt zu unseren automatischen Triage-Dateien besteht darin, einen Workflow zu entwickeln, um alle akzeptierten Tickets zu entwickeln und sie aus dem richtigen Unterprozess herauszufiltern. Unser SOAR arbeitet mit einem einzigen Webhook, die gesamte Warnung von unserem SIEM akzeptiert, extrahiert den LogType der Warnung und filtert ihn in einem Flow nach diesem spezifischen LogType ein. In diesem Fluss befindet sich dann der andere, der auf der Erkennung basiert. Sobald die Warnung sortiert ist, läuft ein Zweig des Unterflusses durch, der automatisch die APIs aufruft, die von uns gesammelten Metriken inspiriert wurden. Dies ist ein langer und iterativer Prozess, bei dem einige Anpassungen erforderlich sind, um sicherzustellen, welche Informationen den besten Kontext für die Erkennung bieten und überflüssiger Daten kürzen. Aber wenn es fertig ist, sind die Ergebnisse unglaublich.

Beispiel für einen Bewerbungsfall

Wir schauen uns ein Beispiel für eine Lösung an, an der jedes SOC praktisch täglich zu sehen ist: Ein Brute-Force-Alert. Lass uns zuerst darüber nachdenken, was wir herausfinden wollen, wenn eine dieser Benachrichtigungen erscheint: Hat der Benutzer tatsächlich sein Passwort vergessen oder versucht, jemanden mit brutaler Gewalt in sein Konto einzuziehen? Seien wir ehrlich: In 99% der Fälle sehen wir diese Warnung, der Benutzer hat einfach sein Passwort vergessen. Aber was ist mit diesen 1%? We want not want that our analyst these notifications, only because they often see, but we want not want, that they need to take same action, the activities of the users to abfragen, um herauszufinden, was wirklich vor ihnen liegt. Also haben wir es für sie getan: 1. VirusTotal: Der erste Schritt bei jeder Warnung, die eine IP enthält, ist da, eine Suche, um sicherzustellen, dass sie nicht von einer bekannten bösartigen IP stammen. Wir haben die Analysezeit gespart, wenn wir aus dem AlertContext extrahieren, automatisch für ihn durchgeführt und die Ergebnisse im Ticket. 2. SIEM-IndicatorSearch: Mal sehen, ob diese IP kürzlich in unseren Protokollen aufgetreten ist. Unser Workflow hat die Suche für die letzten drei Tage gestartet und ein einfacher Link hinzugefügt, über den Sie die Ergebnisse der Tickets einsehen können. 3. Automatisch ausgeführte Anfrage — Die erfolgreichen Anmeldeseiten (letzte 90 Tage): Wir haben diese Anfrage implementiert, um den Analysten anzuzeigen, wo die Nutzer in den letzten drei Monaten erfolgreich waren. Stimmt ein Hinweis auf diese IPs? Wenn ja, wir können dies schließen mit der Gewissheit, dass der Benutzer gerade sein Passwort vergessen hat. 4. Automatisch ausgeführte Anfrage — Letzte 5 erfolgreiche Anmeldungen: War die letzte Anfrage nicht gut genug? Nun, hier sind die letzten 5 Orte, an denen sich der Benutzer erfolgreich authentifiziert hat, und der Zeitstempel, an dem es passiert ist.

Ich freue mich

Wie Sie anhand des Beispiels sehen können, kann Phase 1 die Zeit reduzieren, die für die Auswahl eines Tickets benötigt wird. Unsere Analyse muss vor der manuellen Ausführung erfolgen, was manchmal einen langen wierigeren Prozess bedeuten kann, wenn Sie das Runbook nicht finden oder sich nicht an die Namen der gespeicherten Fragen erinnern können, die für eine bestimmte Warnung verwendet werden. Aber jetzt ist alles für uns erledigt. Jetzt schauen wir in die Zukunft und schauen, wie wir diesen Prozess weiter verbessern können. Wir nehmen dasselbe Beispiel wie oben und gehen davon aus, dass eine Warnung bei einem Brute-Force-Test und die IP-Adresse, von der aus Sie verwendet wurden, Ihr erfolgreicher Login in den letzten 90 Tagen. Dies ist eindeutig ein Fall, bei dem der Benutzer entweder das Passwort vergessen hat oder er möglicherweise ein Paar Mail mit einem Schwanzfinger hat. Was ist auch, wenn diese Warnung nicht wirklich ausgelöst und automatisch geschlossen wird?

Phase 2

Warteschlangenphase 2: Das automatische Schließen. In dieser Phase verwenden wir die Informationen, die wir aus Phase 1 erstellt haben, und erstellen eine Logik, um unsere Benachrichtigungen automatisch zu schließen. Das kann so einfach sein wie das IP-Matching, aber auch schwierige Anwendungsfälle mit. Dies wird sicherlich ein interaktiver Prozess sein, genau wie unser Erkennungszyklus. Bleib dran, waehrend we Alert Fatigue langsam ein für alle Männer ausschalten.