Grundsätze von Detection-as-Code

Detection-as-Code (DaC) überträgt die Disziplin der Softwareentwicklung auf Sicherheits-Detections. Statt dass Analysten Regeln manuell in einer SIEM-Konsole bearbeiten, liegen Detections als Textdateien in der Versionsverwaltung und werden über eine Pipeline ausgerollt.

Die Vorteile sind konkret:

• Überprüfbare Änderungen über Pull Requests
• Reproduzierbare Bereitstellungen über Umgebungen hinweg
• Testbare Logik, bevor sie die Produktion erreicht
• Auditierbare Historie darüber, wer was und warum geändert hat

Eine Detection wird zu einem Artefakt, dessen Unterschiede Sie vergleichen, das Sie zurückrollen und über das Sie wie über jeden anderen Code nachdenken können.

Jede Detection wird als eigenständige Datei gespeichert, typischerweise in YAML oder einer Abfragesprache des Anbieters, und in ein Git-Repository eingecheckt. Der Aufbau des Repositorys bildet ab, wie Sie Ihre Abdeckung organisieren.

Eine gängige Struktur trennt Regeln nach Plattform und Taktik:

Jede neue oder geänderte Detection wird über einen Pull Request eingebracht. Ein zweiter Engineer überprüft die Logik, das Risiko von Fehlalarmen und die ATT&CK-Zuordnung, bevor der Pull Request zusammengeführt wird.

Reviewer fragen:

• Entspricht die Logik der beschriebenen Bedrohung?
• Welche legitime Aktivität könnte dies auslösen?
• Sind Schweregrad und ATT&CK-Referenz korrekt?
• Decken die Tests echte und falsch-positive Treffer ab?

So werden Fehler erkannt, die einem einzelnen Analysten beim Bearbeiten des SIEM um 2 Uhr morgens entgehen würden.

Eine Pipeline für Continuous Integration wird bei jedem Push automatisch ausgeführt. Sie erzwingt Qualitätsschranken, bevor eine Regel zusammengeführt werden kann.

Typische CI-Phasen für ein Sigma-basiertes Repository:

Nach dem Merge wandelt ein Deployment-Job die portablen Regeln in die Abfragesprache des Zielsystems um und überträgt sie per API an das SIEM oder EDR.

Für Sigma führen Sie typischerweise einen Konverter wie sigma convert mit einem Backend aus, das zu Ihrer Plattform passt (Splunk, Elastic, Microsoft Sentinel). Die Pipeline lädt anschließend die erzeugten gespeicherten Suchen oder Analytics-Regeln hoch.

Kein Mensch fügt Abfragen in eine Konsole ein. Der bereitgestellte Zustand entspricht immer dem, was in main steht.

Eine Detection ohne Tests ist eine Vermutung. DaC verbindet jede Regel mit Testdaten: Protokollbeispielen, die sie auslösen sollten (echte positive Treffer), und harmlosen Beispielen, die sie nicht auslösen sollten (Fehlalarme).

Tests laufen in CI, sodass eine Änderung, die die Abdeckung beeinträchtigt oder erneut zu Fehlalarmen führt, den Build vor dem Merge fehlschlagen lässt. Dies ist die wichtigste Vertrauensbasis, wenn Regeln in großem Maßstab umstrukturiert werden.

Behandeln Sie Metadaten als gleichwertigen Bestandteil. Jede Detection speichert ihren Status, während sie den Lebenszyklus durchläuft:

• experimental — neu geschrieben, eng überwacht
• test — wird ausgeführt, ist aber noch nicht vertrauenswürdig genug für das Alerting
• stable — bewährt, geringe Fehlalarmrate
• deprecated — ersetzt oder außer Betrieb genommen

Durch die Statusverfolgung in der Datei können Sie Regeln bewusst hochstufen, zurückstufen und außer Betrieb nehmen, statt veraltete Logik in der Produktion weiterbestehen zu lassen.

Ein zentraler Vorteil von DaC besteht darin, die Detection-Logik einmal in einem anbieterneutralen Format zu schreiben und sie dann für viele Backends zu kompilieren. Sigma ist der De-facto-Standard für protokollbasierte Detections.

Dieselbe Regeld atei kann über pipelinespezifische Feldzuordnungen auf Splunk SPL, Elastic Lucene/EQL, Microsoft Sentinel KQL und andere Ziele ausgerichtet werden. Sie vermeiden, dieselbe Idee fünfmal neu zu schreiben, und vermeiden eine Anbieterbindung.

Verschiedene Protokollquellen benennen dieselben Daten unterschiedlich. Ein Sysmon-Ereignis zur Prozesserstellung verwendet Image; ein Windows-Sicherheitsprotokoll kann NewProcessName verwenden. Verarbeitungspipelines überbrücken diese Lücke.

Pipelines wandeln generische Sigma-Feldnamen in die exakten Felder um, die Ihre Daten verwenden, sodass eine logische Regel sauber auf das Schema abgebildet wird, das Ihr SIEM aufnimmt. Wenn Sie Pipelines zentral pflegen, muss eine Schemaänderung nur einmal statt für jede Regel behoben werden.

Wie Anwendungscode durchlaufen Detections Umgebungen, bevor sie die Produktion erreichen. Ein typischer Ablauf führt von Dev über Staging nach Prod.

• Dev — Regeln erstellen und Unit-Tests in CI ausführen
• Staging — gegen eine Kopie echter Telemetriedaten im Audit-Modus bereitstellen
• Prod — hochstufen, sobald die Fehlalarmrate akzeptabel ist

Das Hochstufen ist ein bewusster, überprüfter Schritt, der an den Lebenszyklusstatus der Regel gebunden ist, und kein zufälliger Nebeneffekt des Mergings. Diese stufenweise Einführung entspricht der Disziplin „erst alarmieren, dann blockieren“, die bei Inline-Detections verwendet wird.

Da Detektionen Code sind, können Sie ihre Abdeckung programmgesteuert messen. Verknüpfen Sie jede Regel mit MITRE-ATT&CK-Techniken und erstellen Sie eine Heatmap darüber, was Sie abdecken und was nicht.

Nützliche Metriken, die Sie im Zeitverlauf verfolgen sollten:

• Abgedeckte Techniken im Vergleich zur Gesamtzahl in Ihrem Bedrohungsmodell
• Fehlalarmrate pro Regel
• Durchschnittliche Zeit von der Regelidee bis zum Produktiveinsatz
• Anzahl der Regeln in den einzelnen Lebenszyklusstatus

Diese Zahlen machen aus Detection Engineering ein gesteuertes Programm statt einer Sammlung von Anekdoten.

Testen Sie Ihr Verständnis der Grundlagen von Detection-as-Code.

Detection-as-Code bringt die Strenge der Softwareentwicklung in die Detektionen:

• Regeln werden als versionierte Dateien in Git gespeichert
• Änderungen durchlaufen ein Review von Pull Requests
• CI führt automatisch Linting, Validierung und Tests aus
• Zusammengeführte Regeln werden über eine Pipeline deployt, sodass prod mit main synchron bleibt
• Tests schützen vor Fehlalarmen und Regressionen
• Portabilität (Sigma + Pipelines) ermöglicht es, eine Regel auf viele Backends anzuwenden
• Metadaten, Lebenszyklus und Metriken machen die Detektion zu einem gesteuerten Programm

Als Nächstes schreiben Sie die portablen Regeln selbst mit Sigma.