Agentic Threat Hunting Framework (ATHF)

Quick Start • Installation • Documentation • Examples

Donnez à votre programme de threat hunting de la mémoire et de l'autonomie.

L'Agentic Threat Hunting Framework (ATHF) est la couche de mémoire et d'automatisation de votre programme de threat hunting. Il donne à vos chasses une structure, une persistance et un contexte - rendant chaque investigation passée accessible aussi bien aux humains qu'à l'IA.

ATHF fonctionne avec n'importe quelle méthodologie de chasse (PEAK, TaHiTI, ou votre propre processus). Ce n'est pas un remplacement ; c'est la couche qui rend votre processus existant prêt pour l'IA.

Qu'est-ce qu'ATHF ?

ATHF fournit une structure et une persistance pour les programmes de threat hunting. C'est un framework basé sur Markdown qui :

• Documente les chasses en utilisant le pattern LOCK (Learn → Observe → Check → Keep)
• Maintient un dépôt consultable des investigations passées
• Permet aux assistants IA de référencer votre environnement et vos travaux précédents
• Fonctionne avec n'importe quelle plateforme SIEM/EDR
• NOUVEAU : Inclut des agents de recherche et de génération d'hypothèses propulsés par l'IA (v0.3.0+)

Le Problème

La plupart des programmes de threat hunting perdent un contexte précieux dès qu'une chasse se termine. Les notes vivent dans Slack ou des tickets, les requêtes sont écrites une fois puis oubliées, et les leçons apprises n'existent que dans la tête des analystes.

Même les outils d'IA repartent de zéro à chaque fois, sans accès à votre environnement, vos données ou vos chasses passées.

ATHF change cela en donnant à vos chasses une structure, une persistance et un contexte.

En savoir plus : docs/why-athf.md

Le Pattern LOCK

Chaque threat hunt suit la même boucle de base : Learn → Observe → Check → Keep.

• Learn : Rassembler le contexte à partir du renseignement sur les menaces, des alertes ou des anomalies
• Observe : Formuler une hypothèse sur le comportement de l'adversaire
• Check : Tester les hypothèses avec des requêtes ciblées
• Keep : Consigner les conclusions et les leçons apprises

Pourquoi LOCK ? Il est suffisamment simple à utiliser et suffisamment strict pour que les agents puissent l'interpréter. En capturant chaque chasse dans ce format, ATHF permet aux assistants IA de se rappeler des travaux antérieurs et de suggérer des requêtes affinées basées sur les résultats passés.

En savoir plus : docs/lock-pattern.md

Méthode GATES : Validation de la Promotion Hunt-vers-Détection

Après avoir complété la phase KEEP d'une chasse, la méthode GATES valide si vos conclusions doivent être promues en détections de production, chasses récurrentes ou avis.

Generalizable (Généralisable), Additive (Additif), Tunable (Ajustable), Exposure-tested (Testé en exposition), Sustainable (Durable)

Note : GATES est conçu pour fonctionner avec le framework ATHF et a été largement testé dans ce contexte. Bien que la méthodologie (5 critères BASE, types de verdicts) soit conceptuellement portable, nous recommandons de l'utiliser dans le cadre du workflow ATHF complet pour de meilleurs résultats. Voir .claude/skills/gates/ pour l'intégration complète.

Installation : GATES est actuellement disponible uniquement via git clone. Les utilisateurs ayant installé via pip install doivent cloner le dépôt pour accéder à GATES. Nous travaillons à inclure GATES dans la distribution pip (suivi sous l'Issue #21).

GATES évalue les détections issues de chasses en utilisant un framework à deux niveaux : 5 critères BASE (évalués à partir des données de chasse) identifient les candidats au déploiement, tandis que 5 critères ADVANCED (validés en production) garantissent des détections résilientes avec de faibles taux de faux positifs et de faux négatifs :

Gate	Question	Détecte
G - Generalizable	Est-ce reproductible ?	Règles basées sur des IOC qui expirent rapidement
A - Additive	Comble-t-il une lacune de couverture ?	Détections dupliquées ou redondantes
T - Tunable	Pouvons-nous distinguer une attaque d'un comportement normal ?	Inadéquation du bruit de référence (principale cause de FP)
E - Exposure-tested	Avons-nous couvert les évasions ?	Détections unidimensionnelles
S - Sustainable	Pouvons-nous maintenir cela ?	Règles à fort volume et faible TP

Les verdicts sont basés sur les scores BASE (/5). Voir .claude/skills/gates/ pour les méthodes de validation ADVANCED.

Quick Start — tapez ceci à votre assistant ; /gates est une skill, pas une commande shell :

/gates --hunt H-0001

Types de verdict :

• ✅ PROMOTE (4.0-5.0) - Déployer comme détection permanente
• ⚠️ CONDITIONAL (3.0-3.9) - Déployer après avoir rempli les prérequis
• ❌ HOLD (0.0-2.9) - Préserver la logique, ne pas déployer
• ⏱️ TIME_BOX - Spécifique à une campagne, rafraîchissement tous les 90 jours
• 🔄 RECURRING_HUNT - Exécution trimestrielle, pas en 24/7
• 🚫 DROP - Ne vaut pas la peine d'être détecté ; enregistré pour ne pas être reproposé

Un échec de gate prime sur la bande de score, et lorsque deux gates échouent, la première correspondance dans cet ordre l'emporte : A→DROP, G→TIME_BOX, E→HOLD, S→RECURRING_HUNT, T→CONDITIONAL. Les bandes ci-dessus ne s'appliquent que lorsqu'aucun gate n'a échoué. Règle complète : .claude/skills/gates/SKILL.md Step 4.

Remarque : Le verdict « PROMOTE » de GATES signifie déployer une règle de détection. Cela est distinct de athf hunt promote, qui déplace les fichiers de hunt entre les répertoires.

Intégration avec ADEF (Detection Engineering Framework) :

Après la validation GATES, passer à ADEF pour l'ingénierie de détection en production :

ATHF Workspace                    ADEF Workspace
──────────────                    ──────────────
Hunt (LOCK)                       
   ↓
GATES Validate                    
   ↓
H-XXXX_GATES.yaml  ────────────→  FORGE (F-O-R-G-E)
                                     ↓
                                  Production Rule

Flux de travail complet :

1. Dans l'espace de travail ATHF, validez la chasse — saisie de l'assistant, pas une commande shell :

   /gates --hunt H-0903