In vCISO-Projekten habe ich immer wieder mittelgroße Organisationen mit einem SIEM und vielen Regeln gesehen. Ein Teil kam vom Hersteller, ein Teil aus Community-Paketen, anderes war irgendwann intern gebaut worden. Für etliche Regeln konnte niemand mehr erklären, warum sie existierten.
Das ist der unangenehme Teil von Automation. Das Bauen ist sichtbar. Die dauerhafte Pflege verschwindet im Betrieb.
Eine Regel ohne Herkunft ist kein fertiges Produkt
Bei der Bestandsaufnahme war nicht die Zahl der Regeln das größte Problem. Es fehlte die Herkunft. Welches Verhalten sollte eine Regel erkennen? Welche Datenquelle setzte sie voraus? Wer hatte sie zuletzt gegen einen bekannten Fall geprüft?
Ohne diese Antworten wird eine Anpassung riskant. Eine laute Regel bleibt aktiv, weil niemand ihre Absicht kennt. Eine stille Regel gilt als unauffällig, obwohl ihre Datenquelle längst verändert wurde.
Maxam und Davis nennen Entwicklung und Wartung von Automation als eine häufige Herausforderung der interviewten Teams. Die Studie liefert keine allgemeine Ausfallquote. Sie beschreibt denselben Betriebsdruck.
Die Definition of Done liegt im Betrieb
Für eine neue Detection würde ich mindestens Zweck, Datenquellen, Owner, erwartete Treffer, bekannte Fehlalarme, einen Testfall und ein nächstes Review-Datum festhalten. Das sind keine Schmuckfelder. Sie bilden den Übergang von einer Abfrage zu einer betreibbaren Kontrolle.
Der Testfall muss später erneut laufen können. Eine Regel, die nur am Tag ihrer Erstellung funktionierte, ist nicht verifiziert. Änderungen an Parsern, Feldnamen, Agentenversionen oder Normalisierung können sie brechen, ohne dass ihre Syntax ungültig wird.
Formate wie Sigma erleichtern Versionierung und Austausch. Sie liefern aber weder den lokalen Owner noch die Garantie, dass die benötigte Telemetrie im eigenen SIEM gleich abgebildet ist.
Ein Review braucht mehr als Trefferzahlen
Viele Treffer können auf eine wichtige Detection oder auf eine schlechte Schwelle hinweisen. Keine Treffer können Ruhe bedeuten oder eine tote Datenquelle. Eine reine Mengenmetrik entscheidet das nicht.
Im Review würde ich deshalb drei Dinge verbinden. Zuerst die tatsächlichen Treffer und Fehlalarme. Danach einen bekannten Testtrace. Zuletzt die Frage, ob Datenquelle, Bedrohungsannahme und zuständiger Owner noch gelten.
Der Rhythmus hängt von Risiko und Veränderung ab. Eine Regel an einem stabilen internen Dienst braucht vielleicht seltener Aufmerksamkeit als eine internetnahe Detection auf häufig wechselnder Telemetrie. Ein pauschales Quartal ist kein Ersatz für diese Entscheidung.
Automation Debt wird sichtbar
Eine Regel ist nicht deshalb Schuld, weil sie alt ist. Problematisch wird sie, wenn niemand ihre Herkunft erklären, ihren Test wiederholen oder ihre Wirkung bewerten kann.
Diese Merkmale lassen sich erfassen. Kein Owner, kein reproduzierbarer Test, unbekannte Datenquelle oder überzogenes Review-Datum sind konkrete Wartungssignale. So entsteht aus dem diffusen Gefühl eines überfüllten SIEM eine priorisierbare Arbeitsliste.
Kurz gesagt
Eine Detection ist nicht fertig, wenn sie erstmals auslöst. Sie ist betreibbar, wenn Herkunft, Owner, Test und Reviewweg erhalten bleiben. Automation spart wiederholbare Arbeit. Ihre Wartung bleibt menschliche Verantwortung.
Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.