Detection as Code: Wenn SOC-Regeln zum Softwareprodukt werden
09.09.2026 detection-engineeringsocthreat-huntingci-cd
Vom Bauchgefühl zur Pipeline
In vielen SOCs entstehen Detektionsregeln immer noch so, wie sie es seit 15 Jahren tun: ein Analyst klickt sich durch die SIEM-Oberfläche, tippt eine Query zusammen, speichert sie – fertig. Wer die Regel geschrieben hat, warum sie existiert und ob sie noch funktioniert, weiß oft niemand mehr genau. Genau dieses Problem adressiert “Detection as Code” (DaC): Detektionslogik wird wie Software behandelt – versioniert in Git, mit automatisierten Tests versehen und über CI/CD-Pipelines ausgerollt. Detection as Code (DaC) verändert dieses Modell und behandelt Detektionen wie Software: versioniert, mit klaren Verantwortlichkeiten, testbar und von Anfang an automatisiert. Statt manueller, UI-getriebener Workflows kommen Code, Versionskontrolle und automatisierte Pipelines zum Einsatz, damit Regeln zuverlässig, auditierbar und wartbar bleiben.
Der Treiber ist nicht akademischer Natur, sondern schlicht Alarmmüdigkeit. Teams, die KI-gestützte Anreicherung nutzen, berichten, dass etwa 60-70 % der bearbeiteten Alerts als harmlos eingestuft werden – ein Rauschpegel, den klassisches, ad-hoc geschriebenes Regelwerk nicht mehr bewältigen kann. Führende SOCs zeigen, dass es anders geht: Weltklasse-SOCs halten Falsch-Positiv-Raten unter 10 % durch MITRE-ATT&CK-ausgerichtete Detektionslogik, ML-Klassifikationsmodelle und automatisierte Anreicherung. Der Sicherheitsdienstleister Expel etwa berichtete, dass 75,6 % der von Expel überwachten Detektionen 2025 von Expel selbst geschrieben oder verbessert wurden – gezielt gebaute Logik für hochwertige Alerts statt Volumenmaximierung.
Zwei Rollen, ein Regelkreis
Entscheidend ist die organisatorische Konsequenz: Detection Engineering entwickelt sich zur eigenständigen Disziplin, getrennt von der klassischen SOC-Analyse und vom Threat Hunting. Security Operations konzentriert sich auf Monitoring, Triage und Reaktion auf Alerts in Echtzeit – SOC-Analysten bearbeiten die Alert-Queue, untersuchen Vorfälle, containen Bedrohungen und koordinieren Remediation. Detection Engineering ist dagegen eine Entwicklungsdisziplin, die die Detektionsinhalte baut und pflegt, auf die sich das SOC verlässt. Reifere Programme etablieren dafür ein konkretes Personalverhältnis: etwa ein Detection Engineer pro fünf bis sieben SOC-Analysten, mit mindestens zwei Engineers für Redundanz – ein 20-köpfiges SOC sollte drei bis vier dedizierte Detection Engineers haben.
Wichtig ist, dass Detection Engineering und Threat Hunting keine Konkurrenz sind, sondern sich gegenseitig füttern. Detection Engineering konzentriert sich auf das Erstellen und Verbessern von Regeln, die bekannte und neue Bedrohungen erkennen, während Threat Hunting eine eher manuelle, proaktive Suche nach verdächtiger Aktivität ist. Beide sind essenziell, aber Detection Engineering ermöglicht es den Verteidigern, in großem Maßstab zu operieren – erfolgreiche Hunts sollten Detektionen hervorbringen, sodass beide Disziplinen in einem Feedback-Loop stehen. Praktisch heißt das: Threat Hunting wird in den Detection-Entwicklungszyklus integriert – erfolgreiche Hunts müssen innerhalb von zwei Wochen eine Detektionsregel hervorbringen.
Was das für Incident Response bedeutet
Für die Incident-Response-Praxis zahlt sich DaC an mehreren Stellen aus. Erstens Geschwindigkeit: Mit einer DAC-CI/CD-Pipeline können Security-Teams schnell auf neue Bedrohungen reagieren, indem sie Detektionsregeln erstellen oder ändern und diese mit minimalem manuellem Aufwand testen und ausrollen lassen. Zweitens Nachvollziehbarkeit während eines laufenden Vorfalls: Versionskontrolle beantwortet die Frage, wer welche Regel wann geändert hat – ein Detail, das in Krisensituationen und bei späteren Meldepflichten zählt. Drittens Disziplin gegen Regel-Verfall: Ein “Zero-Hit-Lifecycle”-Prinzip sorgt dafür, dass Regeln ohne echte Treffer oder Beinahe-Treffer nach drei Monaten entweder belassen, angepasst, an Threat Hunting eskaliert oder mit Owner-Zuweisung und Review-Datum deaktiviert werden.
Wer als IR-Team noch komplett auf manuell gepflegte SIEM-Regeln setzt, sollte DaC nicht als reines Tooling-Upgrade verstehen, sondern als organisatorischen Umbau: klare Rollen, CI/CD-Infrastruktur und ein enger, dokumentierter Rückkanal von Incidents und Hunts in den Regel-Code. Genau dort entscheidet sich, ob das nächste 3-Uhr-morgens-Alert-Chaos ein Routinevorgang bleibt oder zur echten Krise eskaliert.
← Zurück zur Übersicht