PEAK statt Bauchgefühl: Threat Hunting wird zur SOC-Pflicht
17.09.2026 threat-huntingsocpeak-frameworkmaturity-model
Threat Hunting galt lange als Kür für Teams mit Zeitüberschuss: ein erfahrener Analyst, eine Idee, ein paar Stunden im SIEM. 2026 ist dieses Bild überholt. Der 2026 CrowdStrike Global Threat Report verzeichnet einen Anstieg von 42 Prozent bei Zero-Day-Schwachstellen, die vor der öffentlichen Offenlegung ausgenutzt werden, während Statista die globalen Kosten der Cyberkriminalität bis 2028 auf 13,82 Billionen US-Dollar taxiert. Wer in dieser Lage weiterhin ohne Struktur hunted, verbrennt genau die Analystenstunden, die im SOC ohnehin knapp sind.
PEAK: Struktur statt Zufallstreffer
Als Antwort auf diese Lücke hat sich das von Splunk entwickelte PEAK-Framework als De-facto-Standard neben den älteren Sqrrl- und TaHiTI-Modellen etabliert. PEAK steht für “Prepare, Execute, and Act with Knowledge” und bringt drei unterschiedliche Hunt-Typen mit; jeder PEAK-Hunt folgt einem dreistufigen Prozess: Prepare, Execute und Act. Entscheidend ist dabei nicht nur die Reihenfolge, sondern die Rolle des Wissens: Jede Phase integriert Knowledge – organisatorisches oder Business-Fachwissen, Threat Intelligence, frühere Erfahrungen der Hunter oder Erkenntnisse aus dem laufenden Hunt. Anders als starre Checklisten versteht sich PEAK ausdrücklich als Baukasten: Hunter können Schritte in jeder Phase überspringen, umsortieren oder ergänzen, um ihren Ansatz an die jeweilige Situation anzupassen.
Für SOC-Leiter bedeutet das: PEAK liefert kein starres Ritual, sondern einen gemeinsamen Wortschatz, mit dem sich Hunts dokumentieren, vergleichen und in die Detection-Engineering-Pipeline zurückführen lassen – der entscheidende Unterschied zwischen einer einmaligen Fleißarbeit und einem Programm, das sich selbst verbessert.
Reifegrad ist kein Selbstzweck
Parallel zur Methodik braucht jedes Team einen Maßstab, wo es steht. Das von David Bianco geprägte Hunting Maturity Model bleibt hierfür Referenz. Das SANS-Reifegradmodell beschreibt fünf Stufen von HMM0 (initial, überwiegend reaktiv) bis HMM4 (führend, mit automatisierten Hunt-Workflows, die in den SOC-Betrieb integriert sind). Die meisten Organisationen starten deutlich unterhalb dieses Ziels: Die meisten Organisationen beginnen bei HMM1. Das Ziel ist nicht, HMM4 sofort zu erreichen, sondern stetig voranzuschreiten, indem Hunting zu einer konsistenten, dokumentierten Praxis statt einer gelegentlichen Übung wird. Wichtig für die IR-Schnittstelle: Hunting und Incident Response sind keine getrennten Silos. Hunts, die Bedrohungen aufdecken, münden in Incident-Response-Workflows. Incident-Response-Untersuchungen, die Lücken in der Detection-Abdeckung offenbaren, erzeugen wiederum Hypothesen für künftige Hunts.
Der eigentliche Engpass heißt Kapazität
Die eigentliche Erkenntnis 2026 ist unbequem: Methodik allein löst das Problem nicht. Die Ausführungskapazität begrenzt Programme heute stärker als das Methodendesign. Sqrrl, MITRE, TaHiTI und PEAK kodifizieren alle die Schleife aus Hypothese, Test, Urteil und Feedback, doch Hypothesenlisten bleiben unbearbeitet, weil Hunting mit Alert-Triage um dieselben erfahrenen Analysten konkurriert. Genau hier setzt der aktuelle Trend zu agentengestützter Ausführung an: KI-gestütztes Hunting beruht auf einer klaren Arbeitsteilung: Menschen definieren Hypothesen, Agenten führen die Untersuchungen aus. Erste Praxisberichte untermauern das Potenzial: Hunts, die bis zu 40 Stunden manueller Analystenarbeit verschlangen, verdichten sich auf etwa eine Stunde.
Für IR-Teams heißt das konkret: PEAK oder ein vergleichbares Framework einführen, den eigenen HMM-Stand ehrlich bewerten – und dann gezielt in Ausführungskapazität investieren, sei es durch Automatisierung oder durch klare Priorisierung, welche Hypothesen überhaupt bearbeitet werden. Wer nur die Methodik poliert, aber die Kapazitätsfrage ignoriert, bleibt bei HMM1 hängen, egal wie elegant das Framework an der Wand hängt.
← Zurück zur Übersicht