Quelle: Maxam & Davis (2024), "An Interview Study on Third-Party Cyber Threat Hunting Processes in the U.S. Department of Homeland Security", arXiv:2402.12252
Die DHS-Teams haben elf erfahrene Threat Hunter befragt. Zwei Herausforderungen tauchten am häufigsten auf. Die erste: Expertise zuverlässig einschätzen. Die zweite: Automation entwickeln und aktuell halten.
Die zweite überrascht mehr als die erste. Automation klingt nach einem technischen Problem mit technischer Lösung. In der Praxis ist sie beides nicht.
Was Automation im Threat Hunting eigentlich bedeutet
Threat Hunting läuft nach dem Modell der Studie in zwei parallelen Schleifen: einer manuellen und einer automatisierten. Die manuelle Schleife ist der Analyst, der Baseline analysiert, Anomalien interpretiert, Kontext aufbaut. Die automatisierte Schleife läuft daneben, Sensoren, Alerts, IOC-Prüfungen, Triage-Workflows.
Beide sind notwendig. Keine ersetzt die andere.
Automation im Threat-Hunting-Kontext bedeutet konkret: SIEM-Regeln, EDR-Policies, automatische Anreicherung von Indikatoren, strukturierte Alert-Triage. Nicht "KI übernimmt die Analyse". Sondern: bekannte Muster werden automatisch erkannt, damit der Analyst seine Zeit für das investieren kann, was kein Algorithmus erkennt.
Das ist ein anderer Anspruch als Compliance-Automation. Ein Compliance-Tool zeigt, was konfiguriert ist. Threat-Hunting-Automation sucht aktiv nach Verhalten, das dort nicht sein sollte, und das regelmäßig angepasst werden muss, weil Angreifer ihre Methoden ändern.
Warum Automation so schwer zu halten ist
Das Problem ist nicht, Automation zu bauen. Das Problem ist, sie am Leben zu halten.
Personalwechsel alle zwei bis drei Jahre. In IT-Sicherheitsteams ist das keine Ausnahme, sondern die Regel. Wer eine SIEM-Regel gebaut hat, ist nach zwei Jahren meist nicht mehr da. Wer sie dann anfassen muss, weiß nicht, warum sie so geschrieben wurde, was sie abdecken soll und was sie im aktuellen Zustand der Umgebung noch leistet.
Angreifer ändern ihre Methoden. Eine Signatur, die im Januar 2023 einen bestimmten Angriff erkannt hätte, erkennt im Januar 2025 möglicherweise nichts mehr. Taktiken, Techniken und Prozeduren entwickeln sich. Automation, die nicht regelmäßig überprüft und angepasst wird, wird zu Lärm, oder schlimmer: zu einer falschen Sicherheit.
Automation ohne Dokumentation ist technische Schuld. Eine Regel ohne Kommentar, ohne Kontext, ohne Begründung ist nach dem Personalwechsel eine Black Box. Niemand traut sich, sie anzufassen. Sie bleibt drin, läuft weiter, und ob sie noch funktioniert, weiß keiner.
Das häufigste Problem in der Praxis
In vCISO-Projekten habe ich das immer wieder gesehen. Viele mittelgroße Organisationen haben ein SIEM. Sie haben auch Regeln, manchmal Hunderte davon, mitgeliefert vom Hersteller, importiert aus irgendwelchen Community-Paketen, irgendwann konfiguriert und seitdem nicht angerührt.
Das ist keine Automation. Das ist Lärm.
Wenn ein SOC jeden Tag 3.000 Alerts bekommt und 2.800 davon False Positives sind, entsteht Alert Fatigue. Analysten hören auf, genau hinzuschauen. Und genau in diesem Rauschen verstecken sich echte Angriffe.
Eine Sammlung veralteter Regeln, die niemand versteht und niemand pflegt, ist nicht besser als gar keine Automation, sie ist aktiv schädlich.
Was funktioniert: weniger, aber besser
Der Ausweg ist nicht mehr Automation. Er ist bessere Automation.
Wenige, gut gepflegte Regeln schlagen viele schlechte. Zehn Regeln, die jemand versteht, die dokumentiert sind und die regelmäßig geprüft werden, leisten mehr als hundert Regeln, die niemand mehr versteht.
Dokumentation von Anfang an. Jede Regel braucht einen Zweck, eine Beschreibung, einen Ansprechpartner und ein Datum. Das klingt nach Overhead, es ist Grundlage für Betrieb über Personalwechsel hinweg.
Versionskontrolle für Detektionsregeln. Das Sigma-Format ermöglicht es, SIEM-Regeln wie Code zu behandeln: versioniert, nachvollziehbar, peer-reviewed. Wer Regeln in einem Git-Repository pflegt, weiß, wer wann was warum geändert hat. Das ist kein Entwicklerprojekt, das ist Wissensmanagement für Sicherheitsteams.
Regelmäßige Review-Zyklen. Mindestens einmal im Quartal: Welche Regeln lösen wie viele Alerts aus? Wie viele davon waren True Positives? Was hat sich in der Umgebung geändert? Was hat sich in der Bedrohungslandschaft geändert? Diese Fragen brauchen keine halbe Stelle, aber sie brauchen einen festen Rhythmus.
Die eigentliche Botschaft
Die DHS-Teams haben genug Budget, Werkzeuge und Personal. Trotzdem nennen sie Automation als eine der größten Herausforderungen.
Das ist kein Hinweis auf Versagen. Das ist ein ehrlicher Befund: Automation in der Sicherheit ist kein einmaliges Projekt. Sie ist laufende Arbeit. Sie veraltert. Sie braucht Pflege.
Wer das akzeptiert, hört auf, Automation als abgeschlossene Aufgabe zu behandeln. Er fängt stattdessen an, sie als Teil des Betriebsmodells zu denken, mit klaren Verantwortlichkeiten, Dokumentation und Review-Zyklen.
Das ist unbequem, weil es bedeutet: die Arbeit hört nicht auf. Aber es ist ehrlicher als zu glauben, man hat das Problem einmal gelöst.
Der vollständige Paper: arXiv:2402.12252
Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.