Automatisierung des SOC: Phase 2

Es war ein langer Prozess, auf Phase 1 der Automatisierung des SOC aufzubauen, aber der Reifegrad des FloQast Detection and Incident Response Teams in den letzten neun Monaten seit unserem letzten Update war ein Sprung. Wenn Sie im Juni 2023 nicht mit uns Schritt gehalten haben, würde ich empfehlen, einen kurzen Blick darauf zu werfen durch Automatisierung des SOC: Phase 1 damit du weißt, wo wir als Team waren. Wenn Sie Security Operations noch nicht kennen, empfehle ich Ihnen dringend, nachzulesen über den ständigen Kampf gegen Alert Fatigue oder unsere Reise nach Werden Sie ein datengesteuertes SOC um dein Wissen über uns ein bisschen abzurunden. Aber wenn du nur hier bist, weil du geduldig darauf gewartet hast, von Phase 2 zu hören, lass uns loslegen!

Rip&Replace

Als wir über Phase 1 schrieben, entschieden wir uns für eine SaaS-Lösung, die uns eine schnelle, nahtlose Implementierung unserer SOAR-Workflows über eine praktische GUI-Oberfläche versprochen hatte. Eine Sache, die wir bei unserer Roadmap für Phase 2 nicht berücksichtigt haben, war, dass diese Lösung nicht so lief, wie wir es uns vorgestellt hatten. Ohne mit dem Finger auf die Lösung zu zeigen, für die wir uns entschieden hatten, stellten wir fest, dass das Produkt einfach nicht unseren Anforderungen entsprach. Als lösungsorientiertes Unternehmen haben wir unsere Verluste frühzeitig reduziert und uns für eine neue Lösung entschieden — eine, mit der wir zuvor gespielt hatten, aber dachten, sie wäre zu viel, um sie in Angriff zu nehmen.

Die Lösung, für die wir uns entschieden haben? Einfach durch eine maßgeschneiderte Lösung ersetzen.

Wir nutzten die bestehende AWS-Infrastruktur und Templates, um ein SOAR von Grund auf neu zu erstellen. Mithilfe von AWS Step Functions und Lambdas konnten wir Warnmeldungen von unserem SIEM an unser neues SOAR senden, um die anfängliche Triage all unserer Alerts zu automatisieren. Das war keine leichte Aufgabe, wie man sich vorstellen kann. Aber nach der vollständigen Implementierung vor etwa sechs Monaten haben wir nicht zurückgeschaut und könnten mit der Flexibilität, die uns dieses neue Tool bietet, nicht zufriedener sein.

Das Tool wurde in unserer Organisation als „PopDart“ bezeichnet und ist zum Frontsoldaten im Kampf gegen Alert Fatigue geworden.

Reife

Nachdem das Rip-and-Replace abgeschlossen war, befanden wir uns an einer ähnlichen Stelle wie vor Monaten, als das vorherige Tool lief — aber mit PopDart fühlten wir uns viel besser positioniert. So begannen unsere Bemühungen, die aktuellen Lösungen, die wir hatten, weiterzuentwickeln. Wir hatten zwei Hauptlösungen, die wir entwickeln mussten: SOAR und SIEM.

SOAR-Reife

Die SOAR-Reife zeigte sich in der Optimierung unserer Arbeitsabläufe für jeden Protokolltyp und jede Erkennung. Unsere Workflows haben zuerst eine Verzweigungslogik nach Log-Typ, danach folgt eine Verzweigungslogik, die auf der Erkennung basiert. Für die Reifung dieser Workflows sind zunächst Daten erforderlich, um zu verstehen, was funktioniert und was nicht vollständig. Nachdem unsere Workflows einige Wochen lang liefen, begannen wir, Anpassungen vorzunehmen.

Für diejenigen, die mit der Architektur in SOAR-Workflows nicht vertraut sind, hat jeder Protokolltyp Standardbereiche, in denen jede Warnung dieses Protokolltyps durchläuft. Bei diesen Aktionen handelt es sich um Aufgaben, die für jede eingehende Warnung gelten. Dann gibt es noch die Verzweigungslogik, bei der es sich um erkennungsabhängige Aufgaben handelt, die möglicherweise nur in bestimmten Situationen zutreffen. Dies war ein iterativer Prozess, aber auf der Grundlage unserer Daten können wir jetzt sagen, dass wir uns an einem Ort befinden, an dem die meisten unserer Benachrichtigungen mit nur einem Blick auf unsere PopDart-erweiterten Tickets überprüft werden können.

SIEM-Reife

Die SIEM-Reife nimmt kein Ende. Abgesehen von unseren benutzerdefinierten Erkennungserweiterungen und regelmäßigen Anpassungen, die wir wöchentlich durchführen, haben wir festgestellt, dass wir unsere Ausnahmen besser verwalten müssen. Damit begann unser Prozess der zentralen Verwaltung von Ausnahmen, die, wie Sie anhand unserer Produktauswahl erraten können, und frühere Blogbeiträge, werden per Code verwaltet. Dieser neue Prozess, den wir gestartet haben, war eine Gelegenheit für uns, sicherzustellen, dass Ausnahmen für Erkennungen nicht in der Logik verloren gehen, um sicherzustellen, dass wir einen zentralen Ort zur Überprüfung von Ausnahmen hatten und dass wir sie auf der Grundlage von Eigenschaften wiederverwenden konnten, um unsere Ausnahmen zu organisieren. Alles Nettogewinne. Dies erforderte einige Umgestaltungen, brachte uns aber das, was wir unseren FQGlobalHelper nennen, mit dem wir mit nur ein paar Codezeilen verschiedene Ausnahmen in unsere Erkennungen importieren können.

Eine weitere Ergänzung, die wir vorgenommen haben, um unseren Triage-Automatisierungsprozess zu vereinfachen, sind unsere standardisierten Warnkontexte. Alert-Kontextobjekte, die die wichtigen Werte der Protokolle enthalten, die die Warnung ausgelöst haben. Wir haben Methoden nach Protokolltyp erstellt, die wir bei unseren Erkennungen aufrufen, um die Felder, die an unser SOAR gesendet werden, zu standardisieren und sie demselben Modell anzupassen. Diese Warnungskontexte haben immer noch die Möglichkeit, dem Objekt zusätzliche Felder hinzuzufügen, wenn eine Erkennung dies erfordert, aber diese neuen Methoden ermöglichen es uns, die Basisschlüssel- und Wertepaare konsistent zu halten.

Automatisierung der Reaktion auf Vorfälle

Die Verbesserung unserer Incident Response (IR) -Prozesse war ein Punkt, den wir seit einiger Zeit in unserem Backlog hatten, aber aufgrund dringenderer Punkte (z. B. dem Rip-and-Replace) immer wieder verschoben wurden. Wir haben jedoch endlich unsere Automatisierung ausgebaut, und ihr Erfolg war sofort sichtbar. Zuvor hatten wir im Rahmen von Incident Response Investigations festgestellt, dass es notwendig war, die Zeit von der Meldung eines Befundes bis hin zur Bereitstellung der Dokumentation und Infrastruktur zu verkürzen, um den Befund ordnungsgemäß zu prüfen und zu untersuchen. Um eine Untersuchung einzuleiten, benötigten wir einen privaten Slack-Kanal, ein Jira-Ticket und einen Google Drive-Ordner mit Dokumentationsvorlagen. Darüber hinaus müssen die Benennungskonventionen konsistent sein, all diese Elemente mussten mit derselben Gruppe von Personen geteilt werden und alle Ressourcen mussten zum einfachen Nachschlagen miteinander verknüpft werden. Wir lösten unser Problem, indem wir ein einfaches Formular verwendeten, das ausgefüllt werden konnte, und PopDart nutzten, um den Arbeitsablauf zu automatisieren, wodurch unsere Zeit bis zur Eindämmung der Ermittlungen um 10 bis 15 wertvolle Minuten verkürzt wurde.

Erkennungsanfragen

Da unser Unternehmen weiter gewachsen ist, erhalten wir zunehmend Anfragen zur Erstellung neuer Erkennungen. Deshalb haben wir uns natürlich entschlossen, diesen Prozess zu automatisieren. Spürst du hier ein Thema? Wir haben ein Formular erstellt, das es anderen Mitgliedern der Organisation ermöglicht, Anfragen an das Detection and Incident Response Team zu senden. Dabei wird ein Format verwendet, das uns alles bietet, was wir für die Entwicklung dieser Erkennung benötigen. Unsere Automatisierung platziert diese neuen Anfragen auch direkt in unserem Backlog, was für uns ein nahtloses Erlebnis sorgt und es dem Einsender ermöglicht, den Artikel nach Belieben zu verfolgen.

Ich freue mich

Wie immer freut sich das Sicherheitsteam auf die nächsten Schritte. Zweifellos ist es Phase 3. Und ohne Frage werden Alert Fatigue und Gespräche über Reife immer noch auf dem Tisch liegen. Es gibt aber auch Gespräche darüber, wie wir bei unserem Vorhaben, ein führendes Unternehmen im Bereich Cyber- und Informationssicherheit zu werden, weiterhin modernste Technologien einsetzen können. Also, was passiert in Phase 3? Wir werden Sie so schnell wie möglich informieren. Aber hoffentlich dieses Mal viel, viel früher.