SIEM CI/CD-Herausforderungen — Auf dem Weg zum Glücklichsein bis ans Ende

Als Nächstes in unserer Serie Detection-as-Code (DaC) schauen wir uns an, vor welchen Herausforderungen wir standen, als Jenkins mit der Verwaltung unserer Erkennungen in Panther. Wenn Sie es noch nicht getan haben, schauen Sie sich unsere früheren Blogs an DaC — Theorie in die Praxis umsetzen und Integration von SIEM mit CI/CD um ein Gefühl dafür zu bekommen, was wir tun.

Als Team konzentrieren wir uns darauf, alles, was wir können, per Code zu verwalten. Dieser Fokus hilft uns, so viel wie möglich zu automatisieren. So können wir weniger müde werden und uns mehr auf die unterhaltsamen Dinge konzentrieren, wie zum Beispiel die Suche nach Bedrohungen und das Vorantreiben unseres Programms. Panther in unsere CI/CD-Pipeline aufzunehmen, war ein großer Schritt in diesem Prozess. Es ging jedoch nicht ohne Wachstumsschmerzen.

Die wichtigsten Schmerzpunkte lassen sich wie folgt zusammenfassen:

1. Erforderliche Funktionen
2. Skalierbarkeitserweiterungen
3. Schulung

Erforderliche Funktionen

Der ursprüngliche Jenkins-Job hat das getan, was wir für die Verwaltung unserer benutzerdefinierten Erkennungen brauchten, aber es gab zwei zusätzliche Funktionen, die für die Einrichtung von DaC entscheidend waren.

Die erste war eine Möglichkeit, unsere Release-Version zu aktualisieren, da Panther Updates für Repo für Pantheranalysen. Wir haben unsere Lösung anfangs überdacht, um alle Dinge hochzuladen, anstatt nur unsere FloQast-Erkennungen. Mit ein wenig Versuch und Irrtum konnten wir einen Parameter (den Zielordner) im Jenkins-Job anpassen, und voilà, das Problem war gelöst.

Die andere wichtige Ergänzung bestand darin, sicherzustellen, dass benutzerdefinierte Schemas hochgeladen wurden. Zum Glück hatte das Python-basierte panther_analysis_tool bereits die Möglichkeit, Schemas hochzuladen, sodass mit ein paar Codezeilen auch diese Funktion behoben wurde. Es war wichtig, unsere benutzerdefinierten Schemas organisiert und leicht aktualisierbar zu halten, um mit unserer Notwendigkeit Schritt zu halten, benutzerdefinierte Protokollquellen aufzunehmen.

Nachdem diese beiden Probleme gelöst waren, funktionierte die CI/CD-Pipeline für Panther sehr gut. Also mussten wir natürlich schauen, was wir noch tun konnten.

Skalierbarkeitserweiterungen

Da Erkennungen per Code verwaltet wurden, konzentrierten wir uns auf benutzerdefinierte Protokolleingänge. Ich möchte hier ein wenig darauf eingehen, aber in Zukunft wird ein eigener Blog zum Thema Log-Ingestion erscheinen. Panther hat die Möglichkeit, Logs aus einer Vielzahl von Quellen aufzunehmen. Wir verwenden im Allgemeinen AWS S3-Buckets für unsere benutzerdefinierten Quellen. Zum Glück hat FloQast diese wirklich coole automatische Bereitstellung von Repos über Slack, die wir als Grundlage für unsere benutzerdefinierten Logquellen verwenden konnten. Mit Lambdas, das auf einem Repo von GRAIL (GitHub Repository Automation to Increase Legerity) und FloQasts Infrastructure-as-Code-Ansatz unter Verwendung von Terraform aufbaut, konnten wir unseren Aufnahmeprozess standardisieren und die Zeit bis zur Aufnahme verkürzen. Dieser Code befindet sich in einem eigenen Repo und verwendet einen Jenkins-Job, um die Lambdas in unsere Entwicklungs- oder Produktionsumgebung zu übertragen.

Benutzerdefinierte Quellen erfordern eine AWS-IAM-Rolle (Identity and Access Management) und SNS-Benachrichtigungen (Simple Notification Service) um die Logs zu Panther zu bringen. Diese können über die GUI eingerichtet werden, sofern Sie über ausreichenden Zugriff auf das AWS-Konto verfügen, können jedoch leicht zu einer Ausbreitung führen, da jede Quelle ihre eigene Rolle erhält. Die programmgesteuerte Verwaltung der Rollen ist ebenfalls keine Option über die GUI, daher müssen Sie sie manuell löschen. Außerdem musst du im Setup dreimal klicken, und wer will schon Dinge anklicken müssen? Panther stellt Infrastruktur-als-Code-Informationen im Panther-Auxiliary-Repo bereit. Auf dieser Grundlage haben wir Terraform eingesetzt, um die Rolle und das SNS-Thema zu erstellen. Wir haben uns für eine einzige IAM-Rolle pro Bucket entschieden, um die Anzahl der erstellten Rollen zu begrenzen. Da alles im Code enthalten ist, können wir die Rollen leicht verfolgen und löschen. Wir haben einen separaten Jenkins-Job für diese Funktionalität, aber der Code befindet sich im selben Repo wie unsere benutzerdefinierten Erkennungen.

Schulung

Die letzte Anpassung war die Ausbildung neuer Sicherheitsingenieure. FloQast schätzt Mitarbeiter mit unterschiedlichen Hintergründen, und unser Sicherheitsprogramm ist nicht anders. Wir müssen sicherstellen, dass das Onboarding Ingenieure mit weniger Entwicklungserfahrung mit dem Entwicklungszyklus vertraut macht und Ingenieure mit weniger SIEM-Erfahrung mit SIEM auf den neuesten Stand bringen. Jeder muss sich dem DaC-Ansatz anschließen und verstehen, wie die CI/CD-Pipeline für Panther funktioniert.

Wie Niko in seinem Blog zur CI/CD-Integration betonte, musste der Prozess leicht erlernbar sein. Für die Zusammenarbeit mit Panther benötigen wir Sicherheitsingenieure, die verstehen, was wir mit DaC machen und warum, genug von Jenkins zu Jenkins und Terraform zu Terraform lernen und verstehen, was vor sich geht, genug, um Fehler zu beheben. Wir haben unseren Onboarding-Prozess um spezielle Elemente erweitert, damit sich neue Ingenieure schneller eingewöhnen können. Wir haben Ressourcen über Jenkins und Terraform gesammelt, die einen Crashkurs darüber bieten, was vor sich geht. Wir haben auch strukturierte Tool-Einführungssitzungen. Ich denke, einer der besten Schritte bestand darin, schnelle Erfolge zu identifizieren, die neue Mitarbeiter durch die Pipeline ziehen können. Die Optimierung einer bestehenden Erkennung oder Aufnahme war eine großartige Möglichkeit, den Prozess zu erlernen, ohne sich so sehr auf den Inhalt konzentrieren zu müssen. Weitere hochrangige Teammitglieder stehen für Code-Reviews zur Verfügung und begleiten den Release-Prozess.

Jetzt können unsere neuen Sicherheitsingenieure schneller und mit mehr Selbstvertrauen Beiträge leisten. Wir bitten auch jeden neuen Mitarbeiter, auf Stellen hinzuweisen, an denen wir beim Onboarding besser abschneiden können. Wir dokumentieren sorgfältig, wie wir die Dinge mit CI/CD machen, und lassen eine Person die erste Dokumentation schreiben, wenn wir etwas durcharbeiten, und eine andere Person das nächste Mal, um die Dokumentation zu verfeinern. (Wir glauben fest daran, Urlaub zu nehmen, daher bedeutet die Dokumentation, dass wir tatsächlich weggehen und neue Energie tanken können.)

Glücklich bis ans Ende

Also, was kommt als Nächstes? An diesem Punkt erweitern wir die Grenzen dessen, wie viel Panther wir mit Code verwalten können. Während Panther ihnen neue Funktionen hinzufügt, werden wir weiter vorantreiben, was wir tun können. Wir haben im letzten Jahr große Fortschritte erzielt und suchen weiterhin nach Möglichkeiten, effizienter zu arbeiten. Wir wollen so viel Alltägliches wie möglich durch Automatisierung angehen, um die Skalierbarkeit zu erhöhen, damit wir uns auf die Dinge konzentrieren können, die Menschen tun müssen.