Sicherheitsteams beginnen oft mit dem Schreiben von Regeln. Doch mit der Zeit vervielfachen sich diese Regeln, driften auseinander und verlieren an Konsistenz. Was als einige wenige Detections beginnt, wird schnell zu einer operativen Herausforderung: überlappende Logik, uneinheitliche Namen und eingeschränkte Nachvollziehbarkeit, wer Änderungen vorgenommen hat.
Detection Engineering ändert das. Durch die Verwaltung von Detections als Code können Teams SIEM-Inhalte versionieren, prüfen, testen und bereitstellen – genau wie Software.
Dieser Leitfaden zeigt Ihnen, wie Sie:
- Sumo Logic Cloud SIEM-Regeln in einem GitHub-Repository speichern
- Terraform für konsistente Bereitstellungen nutzen
- GitHub Actions für Validierung und Automatisierung einsetzen
- Terraform-State sicher in AWS S3 mit OIDC speichern
Ziel: Bringen Sie die Disziplin von DevOps in Ihr SOC. Jede Detection wird versioniert, testbar und wiederholbar.
Warum Detection-as-Code wichtig ist
| Herausforderung | Was Detection-as-Code löst |
| Regelabweichungen und Inkonsistenzen | Zentrale Versionskontrolle sorgt für Konsistenz |
| Manuelle Bereitstellung und menschliche Fehler | Automatisierte CI/CD-Pipelines sorgen für einen vorhersehbaren Rollout |
| Begrenzte Zusammenarbeit | Pull Requests machen jede Regel prüfbar und überprüfbar |
| Schwieriges Rollback oder Testen | Der Versionsverlauf ermöglicht eine sichere Veröffentlichung und ein sofortiges Rollback |
Detection-as-Code verwandelt Ihr SIEM von einer statischen Konfiguration in ein lebendiges System, das mit technischer Disziplin entworfen, getestet und eingesetzt wird.

Was Sie aufbauen werden
Sie erstellen ein GitHub-Repository, das:
- Cloud-SIEM-Detections als Code speichert (in YAML- oder JSON-Format)
- Terraform verwendet, um Änderungen in Ihrer Sumo Logic-Umgebung anzuwenden.
- Bereitstellungen über GitHub Actions automatisiert.
- Terraform-State in einem AWS-S3-Bucket mit OIDC speichert (ohne statische Zugangsdaten).
Diese Architektur eliminiert manuelle Fehler, beschleunigt Iterationen und bietet Ihrem SOC vollständige Nachvollziehbarkeit über alle Umgebungen hinweg.
Einrichtungsschritte
Wir empfehlen, dass das Github-Repository für das Regelmanagement unter dem Konto einer Organisation eingerichtet wird. Wir empfehlen, dass das Regelmanagement-Repository nicht mit anderen Funktionen oder Produkten geteilt wird.
Voraussetzungen
- AWS-Konto mit S3-Bucket für die Statusverwaltung
- Github-Konto und Repository – Ein neues Repository anlegen – GitHub Docs
- Sumo Logic-Konto
Zugangsdaten
AWS-Zugangsdaten und Sumo Logic-Zugangsdaten werden in GitHub Secrets gespeichert. Terraform verwendet diese Anmeldedaten, um sich bei AWS und Sumo Logic zu authentifizieren.
Sumo API-Zugangsdaten
Hier finden Sie Anweisungen, wie Sie Ihre Sumo Logic-Zugangsdaten für Sumo Logic abrufen können
AWS-Einrichtung
Die Erstellung des Buckets und die Anmeldeinformationen für AWS können über die folgenden Schritte durchgeführt werden:

- Öffnen Sie in der AWS-Konsole die S3-Seite (indem Sie im Suchfeld nach „S3“ suchen) und klicken Sie auf „Create bucket“.
- Geben Sie Ihren bevorzugten Namen für den Bucket ein und lassen Sie die restlichen Optionen auf den Standardwerten, dann erstellen Sie den Bucket.
- Gehen Sie zur Seite IAM > Policies und klicken Sie auf Create Policy.
- Wechseln Sie im Policy-Editor in die JSON-Ansicht und ersetzen Sie das Feld „Statement“ durch das unten angegebene – ersetzen Sie dabei „bucket-name“ durch den Namen des in Schritt 2 erstellten Buckets – und klicken Sie auf „Next“.
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::bucket-name",
"Condition": {
"StringEquals": {
"s3:prefix": "terraform-state"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state.tflock"
}
]
- Auf der nächsten Seite geben Sie einen beliebigen Namen für die Richtlinie ein und klicken Sie auf Create Policy.
- FFügen Sie einen Identity Provider zu AWS hinzu, indem Sie den Schritten unter folgendem Link folgen: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-console
- Für die Provider-URL: Verwenden Sie https://token.actions.githubusercontent.com
- Für die Audience: Verwenden Sie sts.amazonaws.com
- Gehen Sie zur Seite IAM > Roles und klicken Sie auf Create Role.
- Unter Trusted entity type klicken Sie auf Web Identity und wählen Sie als Identity Provider token.actions.githubusercontent.com und als Audience sts.amazonaws.com. Geben Sie den Namen Ihrer GitHub-Organisation ein, zu der dieses Repository geforkt wurde, und klicken Sie auf „Next“.
- Auf der Seite Add Permissions wählen Sie die in Schritt 5 erstellte Richtlinie aus.
- Geben Sie einen geeigneten Rollennamen ein und klicken Sie auf „Create Role“.
- Im GitHub-Repository unter Settings > Secrets and variables – Actions > Variables ersetzen bzw. ergänzen Sie die Variablen
AWS_ROLE_ARN, BUCKET_NAME, BUCKET_REGIONmit der ARN der Rolle, dem Bucket-Namen und der Region des gerade erstellten Buckets. - GitHub Actions Secrets
- Die Zugangsdaten für Sumo Logic (Personal Access Keys) werden in den Repository Secrets gespeichert und von der Terraform GitHub Action verwendet. Ebenso werden die AWS-Rolle, die für den Zugriff auf das S3-Backend verwendet wird, sowie der Bucket-Name und die Region im Abschnitt Repository Variables gespeichert. Diese Secrets und Variablen können Sie in den Repository-Einstellungen unter Secrets and variables > Actions aktualisieren.
SUMOLOGIC_ACCESSID
SUMOLOGIC_ACCESSKEY
AWS_ROLE_ARN
BUCKET_NAME
BUCKET_REGION
Lokal ausführen
Bei der lokalen Ausführung funktioniert die oben beschriebene AWS-Konfiguration nicht. Stattdessen müssen AWS-Zugangsdaten verwendet werden, die über die folgenden Schritte erstellt werden können (diese Schritte setzen voraus, dass Sie bereits einen S3-Bucket und eine Richtlinie erstellt haben; falls nicht, befolgen Sie die Schritte 1–5 im Abschnitt AWS-Einrichtung):
- Gehen Sie zu IAM > User und klicken Sie auf „Create User“.
- Geben Sie einen geeigneten Benutzernamen ein und klicken Sie auf „Next“.
- Auf der Seite Berechtigungen festlegen klicken Sie auf „Richtlinien direkt anhängen“ und wählen Sie anschließend die zuvor erstellte Richtlinie aus. Klicken Sie auf der nächsten Seite auf „Create User“.
- Gehen Sie zurück zu IAM > User und klicken Sie auf den neu erstellten Benutzer.
- Unter dem Reiter Sicherheitsanmeldeinformationen klicken Sie im Abschnitt Zugriffsschlüssel auf „Create Access Key“.
- Wählen Sie als Anwendungsfall CLI, aktivieren Sie das Kontrollkästchen und klicken Sie auf „Next“
- Fügen Sie bei Bedarf ein Tag hinzu und klicken Sie anschließend auf „Next“. Dieser Schritt erstellt einen AWS-Zugangsschlüssel und einen geheimen Zugangsschlüssel. Exportieren Sie diese als Umgebungsvariablen mit den Namen
AWS_ACCESS_KEY_IDundAWS_SECRET_ACCESS_KEY.
Fördern und Testen von Detections
Verwenden Sie Branches und isolierte Umgebungen, um die Freigabe von Regeln zu steuern:
- Feature branches → development and validation
- Pull requests → peer review and plan approval
- Main branch → automatic deployment to dev
- Manual workflow trigger → promote to test or prod

Fügen Sie YAML-Linting, Policy-Tests oder Metadaten-Validierungen hinzu, um die Qualität sicherzustellen.
Dieser DevSecOps-Workflow reduziert Fehlalarme, beschleunigt Iterationen und stärkt das Vertrauen in Ihre Erkennungsregeln.
Operative Disziplin
Jedes ausgereifte Erkennungsprogramm beruht auf operativer Konsistenz.
Führen Sie Standards ein, wie z. B.:
- Einbindung von Metadatenfeldern wie
Owner, Use CaseundRunbook URL. - Verwendung von
enabled: falsefür vorübergehend deaktivierte Regeln. - Durchsetzung von Namenskonventionen und Wartungsfenstern.
- Nächtliche Driftprüfungen mit
Terraform Plan.
Strikte Prozessdisziplin verwandelt das Regelmanagement von einem reaktiven Feintuning-Ansatz in einen kontinuierlichen Verbesserungsprozess der Erkennung.

Fehlerbehebung und Wiederherstellung
Häufige Probleme:
- Unerwartete Löschungen: Überprüfe Sie die State-Backend-Konfiguration.
- Authentifizierungsfehler: Überprüfen Sie OIDC und API Secrets.
Drift-Warnungen: Stellen Sie sicher, dass keine manuellen Änderungen in der Sumo Logic UI vorgenommen wurden.
Rollback: Setzen Sie einen Commit zurück und wenden Sie ihn erneut an; der Terraform-Status gewährleistet eine vollständige Wiederherstellung.
Wert: Diese Schutzmechanismen machen Detection Engineering widerstandsfähig – Fehler werden zu Lerngelegenheiten statt zu Krisen.
Wichtiger Hinweis
Sumo Logic ist nur für den Support und die Wartung des Cloud SIEM Service, der APIs sowie der veröffentlichten Terraform-Ressourcen verantwortlich, die sich auf Regeln und andere Konfigurationen innerhalb des Cloud SIEM Service beziehen. Sie, der Kunde, sind für Ihr eigenes GitHub-Repository sowie für den Support, die Sicherheit und die Wartung der dortigen Prozesse verantwortlich. Diese Anleitung wird ohne Garantie bereitgestellt. Sie sind dafür verantwortlich, dass die Einrichtung und der Betrieb des Repositories allen relevanten organisatorischen Anforderungen entsprechen.
Vom Prozess zur Praxis
Das Verwalten von Cloud-SIEM-Regeln in GitHub markiert einen wichtigen Wendepunkt – den Übergang von manueller Feinabstimmung zu messbarem Fortschritt. Mit Versionskontrolle, Automatisierung und CI/CD wird jede Erkennung Teil eines lebenden Systems, das lernt, sich anpasst und verbessert.
Angetrieben von Sumo Logic Cloud SIEM entwickelt sich dieses System zu Intelligent Security Operations, indem es Erkennungen mit dem Kontext, den Kontext mit der Aktion und die Aktion mit den Ergebnissen verbindet.
Erleben Sie SIEM in Aktion mit unserer aufgezeichneten Demo.