sims718718/unifiedthreathuntingDokumentiert eine strukturierte, wiederholbare Threat-Hunting-Methodik, die Trigger, SMART-Hypothesen, Machbarkeitsprüfungen, Scoping, Hunt-Pläne und Ergebnisberichterstattung für Sicherheitsteams abdeckt.
Als Lead Threat Hunter wurde ich damit beauftragt, ein Threat-Hunt-Programm von Grund auf aufzubauen. Dies erforderte umfangreiche Überlegungen dazu, was Threat Hunting eigentlich ist und wie man es in aussagekräftige Ergebnisse übersetzt. Viele Stunden flossen in das Studium verschiedener Methodologien rund um Threat Hunting, Detection Engineering, Cyber Threat Intelligence (CTI), Forensik und sogar in Erfahrungen aus meiner Zeit bei der United States Air Force. Beim Aufbau eines Programms wurde mir jedoch klar, dass ich einen einzigen Prozess brauchte – einen einheitlichen Threat-Hunting-Prozess. Ich entwickelte diesen Prozess, um eine strukturierte und klar definierte Vorgehensweise für die Jagd zu schaffen und letztlich aussagekräftige Ergebnisse für die Organisation zu liefern.
graph LR
Z[Step 0: Environment Context] --> A[Triggering Event]
A --> B[Hypothesis Development]
B --> C[Initial Assessment]
C --> D[Feasibility Assessment]
D --> E[Define Scope & Objectives]
E --> F[Formalize Hunt Plan]
F --> G[Execute Hunt]
G --> H[Document Outcomes]
H --> I[Report & Iterate]
I --> A
Threat Hunting ist die proaktive Suche nach Bedrohungen, die Ihre Kontrollen umgangen haben. Diese Definition ist etabliert; wie man es als Programm betreibt, ist es nicht. Dieser Prozess ist eine Synthese, und die Tabelle ist die ehrliche Abrechnung damit:
| Quelle | Was sie hier beiträgt |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | Die Kernschleife und die Reifegradleiter, die in Maturity & Metrics verwendet werden |
| TaHiTI | Den Trigger als den eigentlichen Ausgangspunkt und die Übergabe an angrenzende Prozesse beim Abschluss |
| PEAK | Die Hunt-Typisierung (Hypothese / Baseline / modellgestützt) und den ergebnisorientierten Abschluss „act with knowledge" |
| AIMOD2 | Die Assumed-Breach-Prämisse und die typisierten Ergebnis-Kategorien |
| OTHF | Den operativen Rahmen für die Durchführung von Hunts als wiederholbare Teamfunktion |
| Dieser Prozess fügt hinzu | Schritt 0 Umgebungskontext · ein hartes Machbarkeits-GO / NO-GO / CONDITIONAL-Gate · Jira Epic/Story/Task mit typisierten Ergebnissen · eine rubrikengesteuerte Hypothese und eine spezifizierte Detection-Übergabe |
Die Unterscheidungsmerkmale sind die letzte Zeile. Alles andere baut auf der Arbeit anderer auf, zitiert in References.
Es gibt verschiedene beschriebene Methoden zur Durchführung von Hunt-Operationen: strukturiert, unstrukturiert, TTP-fokussiert, intel-fokussiert, datengetrieben und so weiter. Obwohl dieser Unified Threat Hunting Process strukturiert erscheinen mag, bedeutet das nicht, dass Ihre Hypothese nicht auf unstrukturierte Weise datengetrieben sein kann. Dieser Prozess zielt darauf ab, verschiedene Arten des Threat Hunting zu integrieren und einen modularen Ansatz zu ermöglichen. Wir würden all diese Techniken einsetzen, um sicherzustellen, dass wir unsere Hypothese gründlich testen.
Das Ziel ist ein modularer Ansatz für Threat Hunting, bei dem es keine Einheitslösung gibt. Nutzen Sie alle Techniken, die Ihnen zur Verfügung stehen.
In der Praxis hängt der gewählte Hunt-Typ davon ab, wo Sie in der DAIKI-Kette (Data → Information → Knowledge → Insight) starten:
| Hunt-Typ | Ausgangspunkt | Merkmale |
|---|---|---|
| Exploratory (EDA) | Rohdaten | Baselining, Verständnis der Datenform, keine vorherige Hypothese |
| Hypothesis-Based (HBO) | Situationsbewusstsein | Testen glaubwürdiger Angriffsszenarien basierend auf Teamwissen |
| Threat-Informed (TIO) | Umsetzbare CTI | Intelligence-getrieben, Fokus auf bekannte Akteure oder TTPs |
| Purple Operations (DPO) | Red-Team-Erkenntnisse | Gemeinsame offensive/defensive Validierung |
Nach Data-Science-Prinzipien sollten Sie unabhängig vom Hunting-Typ darauf abzielen, die für Ihre Hunt relevanten Datenquellen zu erkunden und zu verstehen. Der Ordner /Data_Analysis in diesem Repo enthält unterstützende Techniken und Notebooks für diese Explorationsphase.
Darüber hinaus ist Threat Intelligence, ob als Ausgangspunkt oder nicht, in den gesamten Prozess eingebettet, um Operationen voranzutreiben.Threat Intelligence
Hinweis: Während Sie typischerweise auf Verhaltensweisen oder TTPs fokussieren möchten, haben IoCs ihre Berechtigung, wenn sie wirklich umsetzbar und zeitnah sind. Während die Jagd nach IoCs in einer Umgebung nicht wirklich Threat Hunting ist, können sie dennoch nützliche Informationen und einen weiteren Ausgangspunkt bieten. Sie können Teil des Hunt-Zyklus sein, aber nicht die gesamte Hunt selbst.
Bevor eine Hunt beginnt, erfassen Sie die Umgebung, damit jedes nachgelagerte Artefakt (Abfragen, Feldnamen, Scoping-Entscheidungen) auf Ihren tatsächlichen Arbeitsbereich zugeschnitten ist und nicht generisch geschrieben wird. Ich habe dies als expliziten Schritt hinzugefügt, weil ich immer wieder Hunt-Pläne sah, die Datenquellen referenzierten, die niemand hatte, oder Abfragen, die im völlig falschen Dialekt geschrieben waren. Ein paar Minuten hier sparen später Stunden.
Dokumentieren Sie mindestens:
| Kontext | Warum es wichtig ist |
|---|---|
| SIEM / Datenplattform | Splunk SPL, KQL, Elastic DSL und Chronicle prägen jeweils jede Abfrage, die Sie schreiben |
| EDR-Plattform | CrowdStrike, SentinelOne, Defender for Endpoint verwenden jeweils unterschiedliche Telemetrie-Feldnamen |
| Umgebungstyp | On-Prem, Cloud-nativ (AWS/Azure/GCP) oder hybrid verändert, welche Logs überhaupt existieren |
| Branche | Bestimmt, welche Bedrohungsakteure realistischerweise relevant sind |
| Log-Aufbewahrungsfenster | Bestimmt, welche Zeiträume tatsächlich abfragbar sind |
| Hunt-Reifegrad | Erstmalige Hunter brauchen Gerüste; erfahrene Teams wollen ein Skelett |
Dokumentieren Sie dies als Environment Profile-Block oben im Epic. Wenn Sie schnell unterwegs sind, ist das absolute Minimum SIEM-Plattform und Umgebungstyp; alles darunter und Ihre Abfragen werden generisch.
Hunting über mehrere Organisationen hinweg? (MSSP/MDR, föderierte Tochtergesellschaften oder eine gemeinsame SIEM-Plattform.) Führen Sie ein Profil pro Mandant in einem
tenants/<id>/profile.yaml-Register und lassen Sie jedes Epictenant: <id>referenzieren, anstatt das Profil einzubetten. Prüfen Sie vor der Machbarkeit die Autorisierung: Ein Mandant ohne RoE-/Vertragsabdeckung oder eine geplante Aktion außerhalb seinerallowed_actionsist NOT AUTHORIZED und stoppt dort. Single-Org-Teams können dies überspringen. Siehe Multi-Tenant Operation.
In Anlehnung an das TaHiTI-Framework beginnt Threat Hunting mit einem auslösenden Ereignis. Diese Ereignisse rechtfertigen die Initiierung einer Hunt. Laut TaHiTI können Trigger Folgendes umfassen:
Für unsere Organisation verwenden wir diese zusammen mit einigen zusätzlichen Triggern wie direkten Anforderungen von Stakeholdern und Schwachstellenoffenlegungen, die die Umgebung betreffen.
Einige Frameworks beginnen die Threat Hunt mit der initialen Hypothese (hier Schritt 2), aber ich frage: Wie kommen Sie überhaupt zu dieser Hypothese?