Ryan Cox (Security)
December 20, 2022
In unserer sich ständig weiterentwickelnden Erkennung als Code (dAC) Serien, die wir behandelt haben Theorie in die Praxis umsetzen, Integration von SIEM mit CI/CD, und SIEM CI/CD-Herausforderungen. Aber heute werden wir den Fokus auf ein großes Problem in jedem Security Operations Center (SOC) verlagern: Automatisierung gegen Alermüdung. Jeder SOC-Analyst weiß, dass die Anzahl der Warnmeldungen, die während seiner Schicht eingehen, überwältigend sein kann, und es kann manchmal schwierig sein, zu entscheiden, welche Warnungen Vorrang vor anderen haben. Warteschlange „Alert Fatigue“ — Desensibilisierung gegenüber Alarmen aufgrund einer immensen Menge, die ausgelöst wird. Jedes SOC leidet unter Alarmmüdigkeit, und es ist ein sich ständig weiterentwickelnder Kampf, sie abzuwehren. Von der Optimierung von Erkennungen bis hin zur Erstellung von Automatisierungen gibt es viele Möglichkeiten, dem entgegenzuwirken. In letzter Zeit haben wir jedoch unsere Ticketing-Prozesse automatisiert, um den Zeitaufwand für das Dokumentieren und Schließen einer Warnung zu verringern. Hier ein Blick auf unser letztes Gefecht mit Alert Fatigue.
In einer Minute
Wenn bei FloQast eine Sicherheitsregel in unserem Security Incident Event Manager (SIEM) ausgelöst wird und eine Warnung ausgelöst wird, wird sie in drei Hauptwarteschlangen verschoben: Slack, Jira und Panther. Wir verwenden Slack als unsere erste Benachrichtigungswarteschlange. Jira ist unsere primäre Dokumentationsquelle für Warnmeldungen und bietet uns eine schnelle und einfache Möglichkeit, in der Vergangenheit nach Audits, Untersuchungen und anderen Tickets zu suchen (über JQL). Schließlich wird Panther (unser SIEM) verwendet, um die Ereignisprotokolle einzusehen und einen ganzheitlicheren Überblick nicht nur darüber zu erhalten, warum die Warnung ausgelöst wurde, sondern auch den Kontext rund um das Ereignis. Das bedeutet, dass unsere Analysten in Slack auf Alerts achten, die entsprechende Warnung in Jira öffnen, Panther öffnen müssten, um die zugehörigen Logs einzusehen, zurück zu Jira navigieren müssten, um zu dokumentieren, und dann die Warnung nach der Triage auf jeder Plattform schließen — FÜR ALLE. SINGLE. WARNEN. Dies war nicht nur überflüssig und widerlich, sondern konnte auch zu Diskrepanzen zwischen den drei Quellen führen, die durch Alarmmüdigkeit verursacht wurden. Dies könnte erhebliche Auswirkungen auf das Geschäft haben. Es besteht ein höheres Risiko für menschliches Versagen, da ein Analyst vergessen könnte, eine Warnung in einem der drei Kanäle zu schließen, nachdem er den ganzen Tag über viele Warnmeldungen geprüft hat. Und nicht nur das, es nimmt auch unschätzbare Zeit in Anspruch, die für die Arbeit an einem anderen Projekt aufgewendet werden könnte.
Bekämpfe die Müdigkeit
Da an einem Tag mehr als 30 Warnmeldungen eintreffen, war unserem Team klar, dass unser Warnmeldungsprozess ineffizient war und ein Upgrade erforderte. Wer hat Zeit, dieselbe Aufgabe an drei verschiedenen Orten auszuführen? Darüber hinaus, welche Warnungswarteschlange würden wir als unsere Informationsquelle verwenden? Um unsere Probleme zu lösen, haben wir uns an Jira Automations gewandt. Die Idee hinter diesem Automatisierungsablauf wäre, dass, wenn ein Alert auf gesetzt ist geschlossen in Jira würde der entsprechende Alert dann auf gesetzt Gelöst im Panther. Also, wie haben wir das hingekriegt?
Jira-Automatisierungen - Wenn ein Analyst einen Alert auf geschlossen, unser Automatisierungsablauf startet und extrahiert die „AlertID“ aus der Ticketbeschreibung. Anschließend wird eine POST-Anfrage erstellt und an unsere auf AWS gehostete API gesendet.
ALS LABOR - Ein Application Load Balancer (ALB) wurde so konfiguriert, dass er über eine API aufgerufen werden kann. Dieser Endpunkt empfängt die POST-Anfrage von Jira, authentifiziert die Anfrage und leitet den Hauptteil der Anfrage an unser Lambda weiter.
AWS Lambda - Sobald das Lambda die Ereignisdaten übergeben hat, extrahiert es die AlertID-Variable und formatiert sie in einer GQL-Abfrage. Diese Abfrage wird an die Panther-API übergeben, die die entsprechende Warnung auf setzt Gelöst.
Panther-API - Das Panther SIEM hat einen GraphQL-Endpunkt, der eine GQL-Abfrage als Eingabe akzeptiert. Das Lambda leitet eine Mutationsabfrage an den Endpunkt weiter, um den Status der Warnung anhand der ID zu bearbeiten.
** Authentifizierung- Wir verwenden einige Token, um unsere Anfragen zu authentifizieren, die sicher in AWS SSM gespeichert sind. Unser erstes Token wird von Jira an unser Lambda weitergegeben, wodurch sichergestellt wird, dass unsere Anfrage von unserer eigenen Jira-Instanz stammt. Wir überprüfen auch die IP, von der die Anfrage gesendet wurde. Das zweite Token wird verwendet, um den Aufruf der Panther-API von unserem Lambda aus zu authentifizieren. Dies gewährleistet eine sichere Lieferung unserer Daten.
Oberste Priorität
Unsere neue Automatisierung wird seit etwa 6 Monaten in unserer Umgebung eingesetzt, und wir haben festgestellt, dass die Teammitglieder aufgrund der freien Zeit jetzt mehr vierteljährliche Aufgaben übernehmen können. Wir haben nicht nur eine Zunahme der Projekte festgestellt, die übernommen werden, sondern auch eine Zunahme der Komplexität. Mit dieser neuen Automatisierung verwenden wir jetzt Jira als Dokumentationsquelle und Slack als Warteschlange für die Statusverfolgung. Panther dient immer noch als unser Ort, um Ereignisse zu untersuchen, aber ihre Alert-Warteschlange muss nicht für jedes Ticket aktualisiert werden, da sich Jira jetzt darum kümmert. In Kombination mit unserem kontinuierlichen Prozess der Feinabstimmung unserer Regeln und Erkennungen ist die Alarmmüdigkeit des Teams so niedrig wie nie zuvor. Wir werden unsere Event-Triaging-Prozesse weiterhin erweitern und ausbauen, um der Übermüdung durch Warnmeldungen entgegenzuwirken.
Nicht fertig
Obwohl wir einige unserer Prozesse automatisiert haben, sind wir noch lange nicht fertig! Was kommt als Nächstes für unser Corporate Security-Team? Wir sind bestrebt, unsere Alerting-, Ticket- und Triaging-Prozesse weiter zu verbessern, indem wir mehr Automatisierungen erstellen! Unser Verbesserungsprozess ist ein iterativer Prozess, und wir freuen uns darauf, im neuen Jahr SOAR (😉) zu beginnen...
