sims718718/unifiedthreathuntingDocumenta una metodologia strutturata e ripetibile di threat hunting che copre trigger, ipotesi SMART, gate di fattibilità, definizione dell'ambito, piani di hunt e reportistica dei risultati per i team di sicurezza.
In qualità di Lead Threat Hunter, mi è stato affidato il compito di costruire un Programma di Threat Hunting da zero. Ciò ha comportato molte riflessioni su cosa sia effettivamente il threat hunting e su come tradurlo in risultati significativi. Sono state dedicate molte ore alla lettura di varie metodologie relative al threat hunting, all'ingegneria del rilevamento, alla Cyber Threat Intelligence (CTI), alla forense e persino all'esperienza maturata durante il mio servizio nella United States Air Force. Tuttavia, costruendo un programma, ho capito che avevo bisogno di un unico processo, un Processo Unificato di Threat Hunting. Ho sviluppato questo processo per fornire un modo strutturato e definito di cacciare e, in ultima analisi, di produrre risultati significativi per l'organizzazione.
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
Il threat hunting è la ricerca proattiva di minacce che hanno aggirato i tuoi controlli. Quella definizione è consolidata; come gestirlo come programma non lo è. Questo processo è una sintesi, e la tabella ne è il resoconto onesto:
| Fonte | Cosa contribuisce qui |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | Il ciclo principale e la scala di maturità usata in Maturity & Metrics |
| TaHiTI | Il trigger come vero punto di partenza, e il passaggio di consegne ai processi adiacenti alla chiusura |
| PEAK | La tipizzazione delle cacce (ipotesi / baseline / assistita da modello) e la chiusura orientata ai risultati "agire con conoscenza" |
| AIMOD2 | La premessa dell'assumed breach e le categorie tipizzate di esito |
| OTHF | L'inquadramento operativo per gestire le cacce come funzione di team ripetibile |
| Questo processo aggiunge | Step 0 Contesto dell'Ambiente · un gate di fattibilità rigido GO / NO-GO / CONDITIONAL · Jira Epic/Story/Task con esiti tipizzati · un'ipotesi vincolata da rubric e un handoff di detection specificato |
I differenziatori sono l'ultima riga. Tutto il resto poggia sul lavoro di altri, citato in References.
Esistono vari metodi descritti per condurre operazioni di caccia: strutturato, non strutturato, focalizzato sulle TTP, focalizzato sull'intel, data-driven e così via. Sebbene questo Unified Threat Hunting Process possa sembrare strutturato, ciò non significa che la tua ipotesi non possa essere guidata dai dati in modo non strutturato. Questo processo mira a incorporare vari tipi di threat hunting, consentendo un approccio modulare. Useremmo tutte queste tecniche per assicurarci di testare a fondo la nostra ipotesi.
L'obiettivo è un approccio modulare al threat hunting in cui non esiste una soluzione valida per tutti. Usa tutte le tecniche a tua disposizione.
In pratica, il tipo di caccia che scegli dipende da dove parti nella catena DAIKI (Data → Information → Knowledge → Insight):
| Tipo di Caccia | Punto di Partenza | Caratteristiche |
|---|---|---|
| Esplorativa (EDA) | Dati grezzi | Baselining, comprensione della forma dei dati, nessuna ipotesi pregressa |
| Basata su Ipotesi (HBO) | Situational awareness | Test di scenari di attacco credibili basati sulla conoscenza del team |
| Threat-Informed (TIO) | CTI azionabile | Guidata dall'intelligence, focus su attore o TTP noti |
| Purple Operations (DPO) | Insight del red team | Validazione congiunta offensiva/difensiva |
Seguendo i principi della data science, indipendentemente dal tipo di caccia, dovresti mirare a esplorare e comprendere le fonti dati rilevanti per la tua caccia. La cartella /Data_Analysis in questo repo contiene tecniche di supporto e notebook per quella fase di esplorazione.
Inoltre, la Threat Intelligence, che sia un punto di partenza o meno, è radicata nell'intero processo per aiutare a guidare le operazioni.Threat Intelligence
Nota: Sebbene tu voglia tipicamente concentrarti su comportamenti o TTP, gli IoC hanno il loro merito se sono davvero azionabili e tempestivi. Sebbene cacciare IoC in un ambiente non sia realmente threat hunting, possono comunque fornire informazioni utili e un altro punto di partenza. Possono essere parte del ciclo di caccia, ma non l'intera caccia stessa.
Prima che inizi qualsiasi caccia, cattura l'ambiente in modo che ogni artefatto a valle (query, nomi dei campi, decisioni di scoping) sia adattato a dove lavori effettivamente anziché scritto in modo generico. Ho aggiunto questo come step esplicito perché continuavo a vedere piani di caccia che facevano riferimento a fonti dati che nessuno aveva, o query scritte nel dialetto completamente sbagliato. Qualche minuto qui fa risparmiare ore dopo.
Come minimo, documenta:
| Contesto | Perché È Importante |
|---|---|
| SIEM / Piattaforma Dati | Splunk SPL, KQL, Elastic DSL e Chronicle plasmano ciascuno ogni query che scrivi |
| Piattaforma EDR | CrowdStrike, SentinelOne, Defender for Endpoint usano ciascuno nomi di campo di telemetria diversi |
| Tipo di Ambiente | On-prem, cloud-native (AWS/Azure/GCP) o ibrido cambia quali log esistono persino |
| Settore Industriale | Determina quali threat actor sono realisticamente rilevanti |
| Finestre di Retention dei Log | Determina quali intervalli temporali sono effettivamente fattibili da interrogare |
| Livello di Maturità della Caccia | I cacciatori alle prime armi hanno bisogno di impalcature; i team esperti vogliono uno scheletro |
Documenta questo come blocco Environment Profile in cima all'Epic. Se stai andando veloce, il minimo assoluto è piattaforma SIEM e tipo di ambiente, qualsiasi cosa in meno e le tue query saranno generiche.
Cacciare attraverso più organizzazioni? (MSSP/MDR, sussidiarie federate, o una piattaforma SIEM condivisa.) Mantieni un profilo per tenant in un registro
tenants/<id>/profile.yamle fai in modo che ogni Epic faccia riferimento atenant: <id>invece di incorporare il profilo. Prima della fattibilità, verifica l'autorizzazione: un tenant senza copertura RoE/contrattuale, o un'azione pianificata al di fuori delle sueallowed_actions, è NOT AUTHORIZED e si ferma lì. I team mono-organizzazione possono saltare questo. Vedi Multi-Tenant Operation.
Prendendo in prestito dal framework TaHiTI, il threat hunting inizia con un evento scatenante. Questi eventi giustificano l'avvio di una caccia. Secondo TaHiTI, i trigger possono includere:
Per la nostra organizzazione, usiamo questi insieme ad alcuni trigger aggiuntivi come requisiti diretti dagli stakeholder e divulgazioni di vulnerabilità che interessano l'ambiente.
Alcuni framework iniziano il threat hunt con l'Ipotesi iniziale (step 2 qui), ma io chiedo: come arrivi a quell'ipotesi in primo luogo?