Blog

Integration von SIEM mit CI/CD

Niko Raisanen
April 18, 2022

Wir bei FloQast haben einen auf Skalierbarkeit ausgerichteten Sicherheitsausblick. Wir sind Automatisierungsfanatiker und Jenkins wird bereits überall eingesetzt, um alltägliche Aufgaben zu automatisieren. Warum also nicht diese Automatisierung auf unser SIEM (Panther) ausdehnen?

Eine kurze Definition, um sicherzustellen, dass wir auf derselben Seite sind, Ein SIEM ist ein Tool, das Daten aus vielen Quellen abruft, analysiert diese Daten und löst auf der Grundlage definierter Regelsätze Warnmeldungen oder Korrekturmaßnahmen aus. Oft werden sie verwendet, um verdächtige Aktivitäten zu identifizieren und zu untersuchen.

Eine kurze Anmerkung: Panther hat eine offizielle Dokumentation zur Einrichtung von CI/CD mit CircleCI; Wir haben jedoch bereits eine glückliche Beziehung zu Jenkins, also haben wir beschlossen, uns auf den Weg zu machen und unsere eigene Lösung zu entwickeln.

Unabhängig von der genauen Ausstattung bietet eine CI/CD-Pipeline für Ihr SIEM unzählige Vorteile. Ein Aspekt, der uns sehr am Herzen liegt, sind die Vorteile der Nutzung von „Erkennungen als Code“. Page hat einen großartigen Blogbeitrag über DaC geschrieben, der hier zu sehen ist. Darüber hinaus ist ein standardisierter Prozess für die Interaktion mit Systemen von großem Wert. Die Standardisierung sorgt für eine sauberere Umgebung mit weniger menschlichen Fehlern, was das Verständnis und die Verwendung des Systems zum Kinderspiel macht. Als Automatisierungsfreak finde ich die Aussicht, dass wir die Automatisierung noch weiter verbessern können, noch aufregender. Wenn alle Eingaben einer bestimmten Konvention folgen, können wir nach Bedarf immer mehr Automatisierungsebenen hinzufügen. Das ist der Traum — Anfang, aber für Automatisierung.

briefcase inside a briefcase

Was ist der Sinn?


Bevor wir darauf eingehen, wie wir Panther in Jenkins integriert haben, ist ein Verständnis unserer gewünschten Ergebnisse erforderlich. Wir hatten die folgenden Kriterien für eine Integration, die wir als würdig erachten würden:

  1. Jede Hinzufügung oder Änderung von Erkennungen wird vor dem Einsatz in der Produktion von einem anderen Sicherheitsmitarbeiter überprüft.
  2. Alle zutreffenden Erkennungen werden getestet
  3. Der Versionsverlauf zeigt an, welche Erkennungen zu einem beliebigen Zeitpunkt aktiviert wurden
  4. Der Prozess muss benutzerfreundlich und leicht erlernbar sein

Quelle der CI/CD-Pipeline

Panther enthält einige nette vorgefertigte Erkennungen in seinem öffentlichen Panther-Analyse-Repo. Wir haben einen privaten Fork dieses Repositorys erstellt und ein Verzeichnis namens floqast erstellt, in dem wir beginnen können, unsere eigenen Erkennungen hinzuzufügen. Das Forken des Repos ist wichtig, da wir so regelmäßig nach Änderungen im Upstream-Repo suchen können, um über die großartigen Erkennungen, die Panther bietet, auf dem Laufenden zu bleiben.

Dieses private Repo ist quasi die „Quelle“ unserer CI/CD-Pipeline. Dann haben wir diesem Repo Webhooks hinzugefügt, die Jenkins-Jobs unter bestimmten Bedingungen auslösen:

  • Wenn ein Pull-Request für den Hauptzweig geöffnet wird und der Feature-Branch mit -security-eng endet, dann...
    • Trigger-Job in Dev Jenkins, der alle Erkennungen testet, die in der PR auftauchen
  • Wenn ein Pull-Request mit dem Haupt-Branch zusammengeführt wird, dann...
    • Einen Job in Prod Jenkins auslösen, um alle Erkennungen auf unsere Panther-Instanz hochzuladen
    • Slack-Alert senden, um zu bestätigen, dass der Upload erfolgreich war

Hier sind die Phasen unserer Pipeline, in denen Erkennungen und Schemas getestet oder hochgeladen werden, die auf dem ausgelösten Webhook basieren

stage("upload schemas") {
when {
expression {
env.FQ_JENKINS_ENV == 'production'
}
}
steps {
script {
sh("panther_analysis_tool update-custom-schemas --path floqast-schemas")
}
}
}
    stage("upload or test detections") {
        steps {
            script {
                pwd
                if (env.FQ_JENKINS_ENV == 'production') {
                    sh("${WORKSPACE}/jenkins/test-or-upload.sh ${params.FOLDER} upload")
                } else if (env.FQ_JENKINS_ENV == 'development') {
                    sh("${WORKSPACE}/jenkins/test-or-upload.sh ${params.FOLDER} test")
                } else {
                    sendNotifications('FAILURE')
                }
            }            
        }
    }

Das gibt eine Vorstellung davon, wann die Automatisierung ausgelöst wird, aber wie sieht sie aus der Sicht eines Sicherheitsingenieurs aus?
Als Ingenieur erstellen Sie Ihre Erkennungen in einem Feature-Branch, der mit -Sicherheits-DE und öffne eine PR. Die Aufgabe, Tests gegen die Erkennungen durchzuführen, wird automatisch gestartet, und Sie fügen die erfolgreiche Ausgabe in die PR-Vorlage ein. Ingenieure haben auch die Möglichkeit, die Testphase in Jenkins manuell auszulösen, ohne eine PR zu öffnen.

Dies ist hilfreich, wenn Sie große Änderungen vornehmen oder eine neue Klasse von Erkennungen einführen. Mit den vorliegenden Testnachweisen bitten Sie dann ein anderes Mitglied des Sicherheitsteams, zu bestätigen, dass die Erkennungen gut aussehen und dass die Tests bestanden wurden. Wenn alles in Ordnung ist, wird der Kollege die PR genehmigen und zusammenführen — der Prod-Jenkins-Job wird ausgelöst und die neuen Erkennungen werden in Panther hochgeladen!

Jenkins Jobs (Erstellen, Testen und Bereitstellen)

Webhooks und so sind cool, aber was cooler ist, sind die Jobs, die die Webhooks auslösen! Panther bietet ein eigenes panther_analysis_tool, das zum Testen und Hochladen von Erkennungen in Panther verwendet wird. Wir haben ein benutzerdefiniertes AMI gebacken, auf dem dieses Tool vorinstalliert ist, und hat dann dieses AMI zugewiesen an den Jenkins-Agenten, der all unsere Panther-Jobs erledigt.

Die Herausforderung bestand darin, dass für den Upload verschiedener Ressourcentypen unterschiedliche Befehlszeilenargumente erforderlich sind. Erkennungen erfordern beispielsweise den Upload-Befehl, während Schemas update-custom-schemas erfordern. Davon abgesehen haben wir diese Hürde leicht überwunden, indem wir Ressourcen nach ihrem Typ organisiert haben (intelligent arbeiten, nicht hart).

Intelligent—nicht schwer

Das panther_analysis_tool ist auch großartig, weil Sie Tests für Erkennungen innerhalb des Tools selbst mit dem --Mindesttests Flagge, das bedeutet, dass wir diese Logik nicht selbst entwickeln mussten! Am Ende schrieben wir ein Drehbuch namens test-or-upload.sh das wird in den ausgelösten Jenkins-Jobs aufgerufen (siehe Codeausschnitt im vorherigen Abschnitt). Hier sehen Sie den Inhalt des Skripts:

# Usage:
# ./test-or-upload <param.FOLDER> <TODO>
# In above, replace <TODO> with "upload" or "test"
dirlist=$(find $1 -mindepth 1 -maxdepth 1 -type d)
echo "Subdirectories detected: $dirlist"
uploadOrTest=$2
for dir in $dirlist
do
  panther_analysis_tool $uploadOrTest --path $dir --minimum-tests $MINIMUM_TESTS
  echo "Testing/Uploading files in $dir"
done

Nachdem all das geklärt ist, können Sie sehen, dass unsere Jenkins-Jobs im Grunde genommen nur noch das panther_analysis_tool enthalten. Alle Funktionen für die Interaktion mit unserer Panther-Instanz sind in das Tool integriert. Sie müssen lediglich die entsprechenden Befehlszeilenargumente verwenden.

Wenn eine PR geöffnet wird, übergeben wir nur die entsprechenden Dateien mit dem Testargument an das Tool. Und wenn ein PR mit main zusammengeführt wird, übergeben wir auch die Dateien, aber mit etwas zusätzlicher Logik, um sicherzustellen, dass wir für jede Ressource das entsprechende Upload-Argument verwenden.

Es ist auch wichtig zu beachten, dass Panther uns eine AWS-Rolle gegeben hat, die wir übernehmen können, um unsere Erkennungen programmgesteuert hochzuladen. Mit dieser Rolle, dem panther_analysis_tool und etwas Bash-Skripting konnten wir eine CI/CD-Pipeline für Panther erstellen, mit der wir nachts ruhig schlafen können