sims718718/unifiedthreathuntingDocumente une méthodologie de chasse aux menaces structurée et reproductible couvrant les déclencheurs, les hypothèses SMART, les critères de faisabilité, la délimitation du périmètre, les plans de chasse et la restitution des résultats pour les équipes de sécurité.
En tant que Lead Threat Hunter, j'ai été chargé de bâtir un programme de chasse aux menaces à partir de zéro. Cela a impliqué de nombreuses réflexions sur ce qu'est réellement la chasse aux menaces et sur la manière de la traduire en résultats significatifs. J'ai consacré de nombreuses heures à lire diverses méthodologies autour de la chasse aux menaces, de l'ingénierie de détection, du Cyber Threat Intelligence (CTI), de la forensique, et même à tirer parti de mon expérience au sein de l'United States Air Force. Cependant, en construisant un programme, j'ai réalisé que j'avais besoin d'un processus unique, un processus unifié de chasse aux menaces. J'ai développé ce processus pour offrir une manière structurée et définie de chasser et, en fin de compte, de produire des résultats significatifs pour l'organisation.
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
Le threat hunting est la recherche proactive de menaces qui ont contourné vos contrôles. Cette définition est établie ; la manière de le mener en tant que programme ne l'est pas. Ce processus est une synthèse, et le tableau en est la comptabilité honnête :
| Source | Ce qu'elle apporte ici |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | La boucle centrale et l'échelle de maturité utilisées dans Maturity & Metrics |
| TaHiTI | Le déclencheur comme véritable point de départ, et la passation aux processus adjacents à la clôture |
| PEAK | La typologie des hunts (hypothèse / baseline / assisté par modèle) et la clôture orientée résultats « agir avec connaissance » |
| AIMOD2 | Le postulat de la compromission présumée et les catégories de résultats typées |
| OTHF | Le cadrage opérationnel pour mener les hunts comme une fonction d'équipe reproductible |
| Ce processus ajoute | Étape 0 Contexte d'environnement · une porte de faisabilité stricte GO / NO-GO / CONDITIONNEL · Jira Epic/Story/Task avec des résultats typés · une hypothèse validée par rubrique et une passation de détection spécifiée |
Les différenciateurs sont la dernière ligne. Tout le reste repose sur le travail d'autres personnes, cité dans References.
Diverses méthodes sont décrites pour mener des opérations de hunt : structurée, non structurée, axée sur les TTP, axée sur le renseignement, pilotée par les données, etc. Bien que ce processus unifié de threat hunting puisse sembler structuré, cela ne signifie pas que votre hypothèse ne peut pas être guidée par les données de manière non structurée. Ce processus vise à intégrer divers types de threat hunting, permettant une approche modulaire. Nous utiliserions toutes ces techniques pour nous assurer de tester rigoureusement notre hypothèse.
L'objectif est une approche modulaire du threat hunting où il n'existe pas de solution unique. Utilisez toutes les techniques à votre disposition.
En pratique, le type de hunt que vous choisissez dépend de votre point de départ dans la chaîne DAIKI (Données → Information → Connaissance → Intuition) :
| Type de hunt | Point de départ | Caractéristiques |
|---|---|---|
| Exploratoire (EDA) | Données brutes | Établissement de baseline, compréhension de la forme des données, aucune hypothèse préalable |
| Basé sur une hypothèse (HBO) | Connaissance de la situation | Test de scénarios d'attaque crédibles fondés sur la connaissance de l'équipe |
| Guidé par le renseignement (TIO) | CTI exploitable | Piloté par le renseignement, axé sur un acteur ou un TTP connu |
| Opérations Purple (DPO) | Retour d'expérience de l'équipe rouge | Validation conjointe offensive/défensive |
En suivant les principes de la science des données, quel que soit le type de hunt, vous devriez chercher à explorer et comprendre les sources de données pertinentes pour votre hunt. Le dossier /Data_Analysis de ce dépôt contient des techniques de support et des notebooks pour cette phase d'exploration.
De plus, le renseignement sur les menaces, qu'il soit un point de départ ou non, est ancré dans l'ensemble du processus pour aider à piloter les opérations.Threat Intelligence
Remarque : Bien que vous souhaitiez généralement vous concentrer sur les comportements ou les TTP, les IoC ont leur mérite s'ils sont réellement exploitables et opportuns. Bien que la recherche d'IoC dans un environnement ne soit pas vraiment du threat hunting, ils peuvent tout de même fournir des informations utiles et un autre point de départ. Ils peuvent faire partie du cycle de hunt, mais pas constituer le hunt entier.
Avant qu'un hunt ne commence, capturez l'environnement afin que chaque artefact en aval (requêtes, noms de champs, décisions de périmètre) soit adapté à l'endroit où vous travaillez réellement plutôt qu'écrit de manière générique. J'ai ajouté cette étape explicite parce que je voyais sans cesse des plans de hunt qui référençaient des sources de données que personne ne possédait, ou des requêtes écrites dans un dialecte totalement erroné. Quelques minutes ici vous font gagner des heures plus tard.
Au minimum, documentez :
| Contexte | Pourquoi c'est important |
|---|---|
| SIEM / Plateforme de données | Splunk SPL, KQL, Elastic DSL et Chronicle façonnent chacun chaque requête que vous écrivez |
| Plateforme EDR | CrowdStrike, SentinelOne, Defender for Endpoint utilisent chacun des noms de champs de télémétrie différents |
| Type d'environnement | On-prem, cloud-native (AWS/Azure/GCP) ou hybride change quels journaux existent même |
| Secteur d'activité | Détermine quels acteurs de menace sont réalistement pertinents |
| Fenêtres de rétention des journaux | Détermine quelles plages temporelles sont réellement exploitables pour les requêtes |
| Niveau de maturité du hunt | Les hunters débutants ont besoin d'un échafaudage ; les équipes expérimentées veulent un squelette |
Documentez cela sous forme de bloc Environment Profile en haut de l'Epic. Si vous allez vite, le minimum absolu est la plateforme SIEM et le type d'environnement, en dessous de cela vos requêtes seront génériques.
Vous chassez à travers plusieurs organisations ? (MSSP/MDR, filiales fédérées, ou une plateforme SIEM partagée.) Conservez un profil par tenant dans un registre
tenants/<id>/profile.yamlet faites référencertenant: <id>par chaque Epic au lieu d'intégrer le profil. Avant la faisabilité, vérifiez l'autorisation : un tenant sans couverture RoE/contrat, ou une action planifiée en dehors de sesallowed_actions, est NON AUTORISÉ et s'arrête là. Les équipes mono-organisation peuvent ignorer ceci. Voir Multi-Tenant Operation.
En empruntant au framework TaHiTI, le threat hunting commence par un événement déclencheur. Ces événements justifient le lancement d'un hunt. Selon TaHiTI, les déclencheurs peuvent inclure :