Detection Engineering als Prozess: vom Alarm-Backlog zum Regelbestand

Detection Engineering ist der Unterschied zwischen einem SOC, das Regeln sammelt, und einem, das Erkennung betreibt. Die meisten Teams fangen mit einzelnen Sigma-Regeln an: eine Idee, eine Regel, aktiviert, fertig. Nach einem Jahr haben sie hunderte Regeln, von denen niemand mehr weiß, welche noch greifen, welche nur Fehlalarme erzeugen und welche längst durch ein Infrastruktur-Update tot sind. Detection Engineering löst das, indem es die Erkennung wie Softwareentwicklung behandelt: mit einem Lebenszyklus, einem Repository, Tests und Kennzahlen. Dieser Beitrag beschreibt den Prozess von der Idee bis zur Außerdienststellung, das Prinzip Detection-as-Code und die Kennzahlen, an denen sich ablesen lässt, ob die Erkennung besser wird oder nur wächst.

Vom Alarm-Backlog zum Prozess

Der Auslöser für Detection Engineering ist meist der Schmerz: Das Team ertrinkt in Alarmen, von denen die meisten nichts bedeuten, und gleichzeitig gehen echte Angriffe durch, weil die richtige Regel fehlt oder längst nicht mehr funktioniert. Das ist die andere Seite der Alert Fatigue: Nicht nur zu viele Alarme, sondern ein Regelbestand ohne Pflege. Der Ausweg ist, jede Regel als Produkt mit einem Lebenszyklus zu behandeln, statt als einmaligen Eintrag. Eine Regel wird geboren, sie lebt und wird gepflegt, und irgendwann stirbt sie, weil die Technik veraltet oder eine bessere sie ersetzt. Wer diesen Lebenszyklus explizit macht, verhindert, dass der Bestand zur Halde wird.

Der Lebenszyklus einer Regel

1. Idee ableiten. Eine Erkennung entsteht nicht aus dem Nichts, sondern aus einer Bedrohung: einer Technik aus MITRE ATT&CK, einem Vorfall, einem Threat-Intelligence-Bericht, einer Lücke in der Abdeckungskarte. Die Quelle wird dokumentiert, damit später nachvollziehbar ist, warum die Regel existiert. Viele Regeln entstehen aus einem Threat Hunt, der ein tragfähiges Muster gefunden hat. Wie man die Abdeckung und den Reifegrad insgesamt misst, zeigt der Beitrag zu Purple-Team-Metriken und Reifegrad. Woher die Bedrohungen kommen, gegen die man Regeln schreibt, klärt das Threat Modeling.
2. Anforderungen klären. Welche Logquelle zeigt die Technik, welche Felder braucht die Regel, ist die Quelle überhaupt angebunden? Oft endet dieser Schritt mit der Erkenntnis, dass zuerst eine Logquelle ins SIEM muss, bevor die Regel Sinn ergibt.
3. Entwickeln. Die Regel wird geschrieben, herstellerneutral als Sigma-Regel, mit Beschreibung, ATT&CK-Tags, dokumentierten Fehlalarmquellen und einem Schweregrad. Die Selektion zielt auf das Verhalten, nicht auf den Indikator eines einzelnen Werkzeugs.
4. Testen. Zwei Ebenen. Syntaktisch: Die Regel besteht die Validierung gegen die Spezifikation. Funktional: Die Technik wird im Homelab mit Atomic Red Team ausgeführt, und die Regel muss treffen. Eine Regel, die nie durch einen Test ausgelöst wurde, ist eine Vermutung.
5. In Produktion nehmen. Zuerst im Beobachtungsmodus, zwei Wochen, um die Fehlalarmrate in der echten Umgebung zu messen. Erst wenn sie tragbar ist, wird die Regel zum Alarm mit Bearbeitungsweg.
6. Betreiben und tunen. Jeder Fehlalarm führt zu einer Anpassung des Filters, nicht zum Abschalten der Regel. Die Anpassungen werden dokumentiert, sodass nachvollziehbar bleibt, warum ein Filter existiert.
7. Messen. Wie oft löst die Regel aus, wie viele Treffer waren echt, wann zuletzt getestet? Diese Zahlen entscheiden über Pflege oder Außerdienststellung.
8. Außer Dienst stellen. Eine Regel, deren Technik veraltet ist, deren Logquelle verschwunden ist oder die eine bessere Regel ersetzt hat, wird bewusst entfernt, mit Begründung. Ein Regelbestand, aus dem nie etwas entfernt wird, verrottet.

Detection-as-Code

Das organisierende Prinzip ist, Erkennungsregeln wie Quellcode zu behandeln. Statt Regeln direkt in der SIEM-Oberfläche zu klicken, liegen sie als Dateien in einem Versionsverwaltungssystem, meist Git. Das bringt aus der Softwareentwicklung mehrere Dinge mit, die dem Regelbestand fehlen, solange er nur in der Konsole lebt.

• Historie. Jede Änderung ist nachvollziehbar: wer hat wann was geändert und warum. Wenn eine Regel plötzlich Fehlalarme erzeugt, zeigt die Historie, welche Änderung es war.
• Review. Eine neue Regel oder Änderung geht durch die Prüfung eines zweiten Analysten, bevor sie produktiv wird. Das fängt Fehler und teilt Wissen.
• Automatische Validierung. Bei jeder Änderung läuft automatisch die Prüfung gegen die Spezifikation, wie im Beitrag zu Sigma-Regeln beschrieben: fehlende Pflichtfelder, ungültige Modifikatoren, falsche Struktur werden abgefangen, bevor die Regel im SIEM landet.
• Automatische Ausrollung. Aus dem Repository werden die Regeln über eine Pipeline in die Abfragesprache des eigenen SIEM übersetzt und dort aktiviert. Eine Änderung im Repository wird so kontrolliert und wiederholbar produktiv, statt manuell geklickt.
• Ein Bestand, viele Ziele. Dieselbe Sigma-Regel lässt sich über Pipelines in verschiedene SIEMs übersetzen, was besonders für Dienstleister mit mehreren Kundenumgebungen zählt.

Detection-as-Code klingt nach großem Aufwand, lässt sich aber klein anfangen: ein Git-Repository mit den Regeln, ein Validierungslauf bei jeder Änderung, ein Review-Schritt. Alles Weitere, die automatische Ausrollung und die Anbindung mehrerer SIEMs, kommt, wenn der Bestand wächst.

Die Abdeckungskarte als Steuerung

Detection Engineering braucht eine Landkarte, damit man weiß, wo Erkennung fehlt und wo doppelt gearbeitet wird. Diese Landkarte ist der ATT&CK Navigator: Jede Regel wird einer Technik zugeordnet, und die Farbe zeigt den Reifegrad, von keiner Telemetrie über vorhandene Regel bis getestete Regel. So wird sichtbar, welche Techniken die für die eigene Branche relevanten Angreifer nutzen und dort keine Erkennung existiert. Die Prioritätenliste für neue Regeln kommt aus dieser Lücke, nicht aus dem Zufall. Weil die Zuordnung zu ATT&CK Teil jeder Regel ist, lässt sich die Karte aus dem Regelbestand automatisch erzeugen und bleibt aktuell.

Kennzahlen

• Fehlalarmrate pro Regel. Der Anteil der Alarme einer Regel, die sich als harmlos erweisen. Eine Regel mit dauerhaft hoher Rate wird getunt oder außer Dienst gestellt; sie kostet mehr Analystenzeit, als sie Sicherheit bringt.
• Abdeckung. Wie viele der relevanten Techniken haben eine getestete Regel? Die Veränderung über die Zeit zeigt, ob die Erkennung wächst.
• Alter des letzten Tests. Jede Regel, die länger nicht getestet wurde, ist ein Risiko, weil ein Infrastruktur-Update sie still außer Kraft gesetzt haben kann. Regeln nach Testalter zu sortieren zeigt, was als Nächstes in die Purple-Team-Übung gehört.
• Zeit von der Idee zur Produktion. Wie lange dauert es, aus einer neuen Bedrohung eine getestete Regel zu machen? Diese Zahl zeigt, wie schnell das Team auf Neues reagieren kann.

Diese Kennzahlen sind auch die Sprache gegenüber der Leitung: Sie zeigen, dass die Erkennung ein gepflegtes System ist und keine Sammlung, und sie begründen, warum Zeit für Pflege statt nur für neue Regeln nötig ist.

Wer das macht

Detection Engineering ist keine eigene Abteilung, die es erst ab einer bestimmten Größe gibt. In kleinen Teams ist es eine Rolle, die sich jemand neben der Alarmbearbeitung nimmt, und schon ein Git-Repository mit ein paar Dutzend gepflegten Regeln ist besser als hunderte ungepflegte in der Konsole. In größeren Teams wird daraus eine benannte Rolle oder ein kleines Team, oft besetzt mit Analysten, die aus der ersten Linie kommen und wissen, welche Alarme in der Praxis nerven und welche fehlen. Genau dieser Weg von der Triage zum Detection Engineering ist eine der Entwicklungen, die der Beitrag SOC-Analyst werden als Perspektive beschreibt. Wie der Übergang konkret gelingt, steht im Beitrag Vom SOC-Analyst zum Detection Engineer.

Fazit

Detection Engineering verwandelt Erkennung von einer Sammlung in ein System: ein Lebenszyklus, der jede Regel von der Idee bis zur Außerdienststellung führt, ein Repository, das sie wie Code versioniert und validiert, eine Abdeckungskarte, die die Lücken zeigt, und Kennzahlen, die Fortschritt messbar machen. Der Aufwand beginnt klein, mit einem Git-Repository und einem Validierungslauf, und wächst mit dem Bestand. Der Gewinn ist ein Regelbestand, dem das Team vertrauen kann, weil er getestet, gepflegt und nachvollziehbar ist. Für ein Blue Team ist Detection Engineering der Schritt von „wir haben Regeln“ zu „wir wissen, was unsere Regeln erkennen“, und das ist der Unterschied, der im Vorfall zählt.