Werden Sie ein datengesteuertes SOC

In unserer vorherigen Installation des Serie Detection-as-Code, wir haben das Problem eingeführt Ermüdung warnen im Security Operations Center (SOC) und wie das Sicherheitsteam hier bei FloQast vorhatte, dagegen anzukämpfen. Zur Erinnerung: Bei Alert Fatigue kommt es im Wesentlichen darauf an, dass ein Sicherheitsanalyst müde und von der Flut von Warnmeldungen überfordert wird, bis er einen tatsächlichen Sicherheitsvorfall möglicherweise als Fehlalarm verwechselt, weil er aufgrund der schieren Anzahl von täglich eingehenden Warnmeldungen überfordert ist. Unsere ersten Schritte zur Bekämpfung von Alert Fatigue bestanden, wie im vorherigen Artikel erwähnt, darin, unsere Tools zu automatisieren, um den Prozess zum Schließen von Tickets erheblich zu vereinfachen. Diese Automatisierungen waren jedoch nur Schritte zur Verbesserung unserer Prozesse und beinhalteten keine Änderungen an unserer SIEM-Erkennungsinfrastruktur.

Ein Schuss ins Dunkle

Wenn Sie versuchen, Ihre Erkennungen zu verbessern, kann es schwierig sein, herauszufinden, worauf Sie sich konzentrieren sollten. Wenn Sie beginnen, mehr Logs aufzunehmen, wächst die Liste der LogTypes und damit auch die Liste der Funde. Darüber hinaus ist es immer noch wichtig, die bereits vorhandenen LogType-Erkennungen nicht zu vergessen. Also wo fängst du überhaupt an?

Bei der Entscheidung, was im Rahmen der monatlichen Verbesserungen des Erkennungszyklus verbessert werden sollte, stellten wir uns dieselbe Frage. Wir haben zunächst einen einfachen Ansatz gewählt: Jeden Monat die Anzahl anhand der Erkennung abfragen, in absteigender Reihenfolge sortieren und uns auf die Top 10 konzentrieren. Dann war da noch der anekdotische Ansatz: „Ich erinnere mich, dass diese Tickets lange gedauert haben; vielleicht sollten wir die auch in die Liste aufnehmen?“ Sicher, das mag zunächst funktionieren, aber wenn der nächste Monat vorbei ist, werden Sie wieder am Anfang stehen, wenn Sie feststellen, dass dieselben Erkennungen immer noch mit der gleichen Frequenz wie im Vormonat ausgelöst werden. Dann stellen Sie sich vielleicht dieselbe Frage wie wir: Was nun?

Ein Schuss ins Licht

Metriken zur Warteschlangenerkennung. Dies sind Kennzahlen, die wir in unsere Tickets integriert haben, damit wir nicht nur raten. Wir haben einen Schritt in Richtung datengetriebener Arbeit gemacht. Vorbei sind die Zeiten von „Ich denke, wir sollten diese Erkennung verbessern“, und jetzt sind die Zeiten von „Die Zahlen sagen, dass wir diese Erkennung verbessern sollten“. Aber wie haben wir das erreicht? Wir haben es mit nur FÜNF Feldern gemacht.

1. EventType/LogType klassifizieren: Klassifizieren Sie Ihre Tickets ganz einfach nach ähnlichen Datentypen
   • Finden Sie eine Möglichkeit, dies mit Regex automatisch zu extrahieren. In unserem Workflow konnten wir dies mit Jira Automations erreichen, wann immer ein Ticket geöffnet wurde.
2. Erkennung klassifizieren: Klassifizieren Sie Ihre Tickets nach der Erkennung, die sie ausgelöst hat
   • Sie können auch eine Möglichkeit finden, Regex zu verwenden, um diese Informationen zu extrahieren.
3. Untersuchungszeit: Finden Sie heraus, bei welchen Tickets die Suche am längsten dauert. Nur weil ein Ticket eine Stunde lang als „In Bearbeitung“ gekennzeichnet ist, heißt das nicht, dass es tatsächlich eine Stunde gedauert hat (zum Beispiel: Der Analyst könnte einfach auf eine Benutzerantwort warten). Dies gibt ein genaueres Bild von dem, was vor sich geht, indem die Zeit gemessen wird, in der der Analyst tatsächlich Maßnahmen ergriffen hat. Wir haben uns für fünf Optionen entschieden: a) < 5 minutes b) 5-15 mins c) 15-30 mins d) 30-60 mins e) > 1 Stunde
4. Klassifizierung: Geben Sie an, was das Ergebnis der Warnung ist. Dies wird uns helfen, herauszufinden, wie wir die Erkennung verbessern sollten. Gibt es zum Beispiel viele falsch positive Ergebnisse? Wie können wir Logik implementieren, um diese herauszufiltern? Wir haben uns für fünf verschiedene Klassifizierungen entschieden: a) Richtig positiv — Ein aktuelles Ereignis, das untersucht werden müsste. b) Falsch positiv — Es gab kein aktuelles Ereignis, das eine weitere Eskalation erforderte. c) Erwartete Aktivität — Für Routinekonten und Aktivitäten, die wir immer noch überwachen müssen, um die Möglichkeit zu vermeiden, dass etwas Schlimmes passiert. d) Bestätigte Aktivität — Ein Benutzer hat bestätigt, dass er die Aktivität ausgeführt hat, und einen Geschäftsszenario für seine Aktionen angegeben. e) Sicherheitstests — Ein Mitglied des Teams testete eine Aktion.
5. Verwendete Ressourcen: Eine Liste der verschiedenen Tools oder Ressourcen, die zur Auswahl des Tickets verwendet wurden. Auf diese Weise können wir herausfinden, wie wir den Triage-Prozess automatisieren können, und die Automatisierung um Tools herum aufbauen, die häufig zur Erkennung erscheinen.

Verwendung der Daten

Jetzt, wo wir schon eine Weile Daten sammeln, mussten wir herausfinden, wie wir sie verwenden können. Da wir Jira für unser Ticketing verwenden, haben wir begonnen, Abfragen nach Erkennung durchzuführen und einfache Visualisierungen für unsere Daten zu erstellen. Die Dashboard-Funktionen von Jira waren jedoch nicht dynamisch oder robust genug, um wirklich gezielte Maßnahmen für unsere Daten zu ergreifen, denn, seien wir ehrlich, dafür ist Jira nicht da. Also mussten wir in eine andere Richtung schauen: SuperBlocks. Dieses Tool hat das Spiel für uns verändert. Jetzt könnten wir komplexe/benutzerdefinierte Dashboards erstellen, um unsere Daten in Echtzeit zu verwenden und zu bearbeiten. Dies haben wir erreicht, indem wir für jede Erkennung vergleichbare Dashboards erstellt haben, in denen wir die Daten auf einen Blick erfassen konnten. Wir haben es einfacher gemacht, indem wir einfache Möglichkeiten zum Filtern nach Datumsbereich geschaffen haben.

Ein Ziel auswählen

Jetzt, da wir unsere Daten gesammelt, aufgenommen und für unsere Sicherheitsingenieure lesbar gemacht haben, ist es an der Zeit, diese Daten zu nutzen. Um die richtige Erkennung auszuwählen, möchten wir nach dem letzten Monat filtern und zunächst nach Erkennungen suchen, die eine hohe Anzahl von Warnmeldungen aufweisen, deren Untersuchungszeiten nicht dem Typ „< 5 Minuten“ entsprechen. Indem wir uns auf Erkennungen konzentrieren, deren Prüfung im Durchschnitt länger dauert, könnten wir unseren Analysten schnell mehr Zeit zurückgeben, indem wir ihre Prozesse besser automatisieren. Wir haben uns für diesen Weg entschieden, weil wir der Meinung waren, dass die „leichte Frucht“ zunächst darin bestand, die Untersuchungszeit auf der ganzen Linie zu verkürzen, was bedeutet, dass wir alle notwendigen Informationen sammeln, um Tickets in unserer Automatisierung zu schließen. Als nächstes schauen wir uns die Klassifikation an. Gibt es Erkennungen mit einer hohen Anzahl falsch positiver Ergebnisse? Was ist mit der erwarteten Aktivität — könnten wir diesbezüglich Ausnahmen erstellen? Wenn die Liste nicht ausreichend eingegrenzt wurde, schauen wir uns danach die verwendeten Ressourcen an. Gibt es einige Erkennungen, bei denen unsere Analysten viele verschiedene Tools zur Triage verwenden müssen? Könnten wir das automatisieren?

Ergebnisse verifizieren

Der letzte Teil der Gleichung bestätigt, dass das, was Sie tun, tatsächlich funktioniert. Und genau wie der Rest dieses Artikels nahelegt, möchten wir, dass die Zahlen zeigen, dass es funktioniert, und nicht nur sagen: „Ich glaube, ich habe im letzten Monat einen Rückgang der Erkennungsrate festgestellt; es muss funktioniert haben!“ Also haben wir ein spezielles Dashboard namens Detection Comparer entwickelt. Dieses Dashboard ermöglicht es uns, anhand einer Erkennung die Daten zweier verschiedener Datumsbereiche zu vergleichen, sodass wir überprüfen können, ob unsere Verbesserungen tatsächlich funktionieren. Wir zeigen alle oben aufgeführten Metriken zusammen mit der Gesamtzahl der ausgelösten Erkennungen und der durchschnittlichen Zeit für die erste Antwort. Wir haben den Vergleich vereinfacht, indem wir nicht nur Visualisierungen, sondern auch Tabellen verwendet haben, die nebeneinander angeordnet sind, sodass alle unsere Daten in einer Linie stehen. Jetzt wissen wir, dass unsere Änderungen funktionieren.

Wie fühlt es sich an, datengetrieben zu sein?

Nachdem wir erst seit etwa sechs Monaten Daten sammeln und unser Dashboard nur etwa zwei Monate lang weiterentwickelt haben, können wir nun mit Zuversicht sagen, dass unsere Bemühungen durch die datengestützte Arbeitsweise viel zielgerichteter und effizienter geworden sind. Jetzt können wir uns wirklich mit den Erkennungen befassen, die für unser Team übermäßig viel Zeit in Anspruch nehmen, wodurch die Zeit, die für die Suche nach Tickets aufgewendet wird, insgesamt reduziert und die Zeit, die für die Verbesserung unserer Sicherheitslage aufgewendet wird, erhöht wird. Wir freuen uns auch sehr, unsere Zukunftspläne für die Automatisierung auf der Grundlage unserer neuen Analysen zu besprechen. Aber das hebe ich mir für einen anderen Tag auf.