TP Bonus — Threat hunting assisté par IA

Acte 2 · SIEM Bonus · Synthèse Ollama · Wazuh MCP · threat hunting

---

1. Objectif & contexte

📡 Poste SOC · La Réunion — Acte 2, Détecter : vous armez Alfred Faure (Crozet), 2 810 km. Liaison SATCOM nominale.

Vous savez détecter. Vous savez alerter. Reste le travail qui prend le plus de temps dans un vrai SOC : la chasse — fouiller les données quand aucune règle n’a sonné, parce qu’un doute suffit à justifier de regarder.

Ce TP de synthèse met un LLM local entre vous et les données Wazuh. Pas pour remplacer l’analyste : pour raccourcir la boucle entre « j’ai une intuition » et « voilà la preuve ». Et pour vous faire buter, en trois heures, sur la question que tout le monde évite — jusqu’où laisse-t-on une IA agir sur la production ?

🔴 Au fil de l’enquête

Il est 2 h 40 à Crozet. Un pic de connexions sortantes, aucune règle Sigma ne couvre le motif. L’analyste d’astreinte a quinze ans de métier et douze minutes de disponibilité. Il pose la question à voix haute — et cette fois, quelque chose répond, en citant ses sources.

Objectifs pédagogiques

• Déployer un LLM local avec Ollama et comprendre pourquoi, sur une base australe, le cloud n’est pas une option.
• Comparer deux architectures d’IA sur SIEM : le RAG (le modèle lit des logs vectorisés) et le MCP (le modèle appelle des outils).
• Mesurer la différence — pas la ressentir : traçabilité, reproductibilité, fraîcheur, coût.
• Mener cinq chasses en langage naturel et documenter chacune comme une enquête, pas comme un chat.
• Distinguer l’anomalie scientifique bénigne de l’attaque réelle, sur un terrain qui produit les deux.
• Décider quels scopes on accorde à l’IA sur la réponse active — et savoir refuser.

Architecture du TP

flowchart TB
  subgraph BASE["🏔️ Alfred Faure — Crozet"]
    AG["Agents Wazuh<br/><small>Linux · Windows</small>"]
    WM["Wazuh Manager<br/><small>API + Indexer</small>"]
    AG --> WM
  end

  subgraph IA["🧠 Poste de chasse — 100 % local"]
    OL["Ollama<br/><small>Llama 3 / Qwen / Gemma</small>"]
    RAG["Approche A — RAG<br/><small>FastAPI + LangChain + FAISS</small>"]
    MCP["Approche B — Serveur MCP<br/><small>54 outils · :3000/mcp</small>"]
    CLI["Client<br/><small>mcphost · Open WebUI</small>"]
  end

  WM -->|archives.json| RAG
  WM -->|API REST + Indexer| MCP
  RAG --> OL
  MCP <--> CLI
  CLI --> OL

  classDef base fill:#dcfce7,stroke:#15803d,color:#14532d
  classDef ia fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  class BASE base
  class IA ia

Ce TP remplace l’ancien TP SOAR

Même intention — automatiser la réponse — mais l’outil a changé d’époque. Là où Shuffle exécutait un workflow que vous aviez écrit ligne à ligne, le LLM choisit lui-même quels outils appeler. Le gain est réel. Le risque aussi, et il porte un nom : vous ne relisez plus le workflow avant qu’il s’exécute.

---

2. Prérequis

Élément	Version / contrainte	Vérification
Wazuh Manager	4.8.0 → 4.14.4 (hors de cette plage, le serveur MCP refuse)	/var/ossec/bin/wazuh-control info
API Wazuh	activée, compte dédié en lecture seule pour commencer	curl -k -u user:pass https://<wazuh>:55000/security/user/authenticate
Wazuh Indexer	requis pour les outils d’alertes et de vulnérabilités	curl -k -u user:pass https://<indexer>:9200/_cluster/health
Docker	20.10+ avec Compose v2	docker compose version
Ollama	16 Go RAM et 4 vCPU minimum pour un modèle 8B	ollama list

Le mur de la RAM — lisez ceci avant de lancer quoi que ce soit

Votre VM SAE tourne avec 8 à 12 Go. Un Llama 3 8B en demande environ 8 à son seul usage, en plus de Wazuh, de l’Indexer et de Docker. Vous allez saturer.

Trois issues, dans cet ordre :

1. L’instance Ollama partagée de l’instructeur — c’est le mode nominal du TP. Vous pointez OLLAMA_HOST dessus.
2. Un modèle plus petit sur votre VM (qwen2.5:3b, llama3.2:3b) — la chasse fonctionne, la qualité des synthèses baisse. Notez-le dans votre rendu, c’est une observation valable.
3. Découpler : Wazuh sur la VM, Ollama sur votre machine hôte.

Ce n’est pas un détail d’intendance. Le dimensionnement d’un LLM est une contrainte d’architecture — exactement comme le lien satellite. Une base australe n’aura pas de GPU.

---

3. Étape 1 — Le LLM reste à la maison

3.1 — Pourquoi pas le cloud

Posez-vous la question avant d’installer : envoyer des logs de sécurité d’une base souveraine à une API tierce, c’est envoyer la cartographie de vos faiblesses à un tiers. Noms d’hôtes, comptes, versions logicielles, horaires de connexion, échecs d’authentification. Un attaquant paierait pour ce corpus.

Ajoutez la contrainte du terrain : le lien satellite ne supporte pas un flux d’inférence continu, et il tombe. Un SOC qui ne fonctionne que lorsque la liaison est nominale n’est pas un SOC.

Conclusion : l’inférence est locale. Ce n’est pas de l’idéologie, c’est la seule architecture qui tienne sur ce terrain.

3.2 — Installer et vérifier

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b          # ou qwen2.5:7b, ou gemma2:9b
ollama list

Vérifiez que l’inférence répond et mesurez-la — vous en aurez besoin à l’étape 4 :

time ollama run llama3.1:8b "Réponds uniquement par OK."

À noter dans votre rendu : modèle retenu, taille, RAM de la machine, latence de cette première réponse. C’est votre point de comparaison.

---

4. Étape 2 — Approche A : le LLM qui lit (RAG)

C’est l’architecture décrite par le blog Wazuh. Le principe tient en une phrase : on découpe les archives Wazuh en morceaux, on les transforme en vecteurs, et on donne au LLM les morceaux les plus proches de la question posée.

4.1 — Activer les archives

/var/ossec/etc/ossec.conf

<logall_json>yes</logall_json>

systemctl restart wazuh-manager
ls -lh /var/ossec/logs/archives/archives.json

4.2 — Monter la chaîne

python3 -m venv ~/hunt-rag && source ~/hunt-rag/bin/activate
pip install langchain langchain-community faiss-cpu sentence-transformers fastapi uvicorn

Le script de référence charge les sept derniers jours d’archives, construit un index FAISS, et expose un chat en WebSocket sur le port 8000. Adaptez la fenêtre à votre volume : l’indexation initiale peut prendre de longues minutes, voire des heures sur un gros corpus.

4.3 — Ce que vous devez observer

Posez trois fois exactement la même question — par exemple « Y a-t-il eu des tentatives de brute-force SSH ? » — et consignez les trois réponses.

Ce que vous testez	Ce que vous devez constater
Reproductibilité	Les trois réponses diffèrent. Parfois sur le fond.
Traçabilité	Le modèle affirme. Il ne cite pas systématiquement l’événement source.
Fraîcheur	L’index est figé à l’heure de sa construction. Une attaque de la minute passée est invisible.
Coût	Chronométrez l’indexation. Rapportez-la au volume d’une vraie base sur une saison.

Le mode d’échec à identifier vous-même

Provoquez une hallucination et capturez-la. Demandez au modèle des détails qui ne sont pas dans les logs — l’identité derrière une IP, la motivation d’un attaquant, un événement sur une plage horaire vide. Un LLM en RAG comble volontiers les trous.

Cette capture est un livrable. Un outil de sécurité qui affirme avec aplomb quelque chose de faux est plus dangereux qu’un outil absent : il déplace la confiance au mauvais endroit.

---

5. Étape 3 — Approche B : le LLM qui interroge (MCP)

Changement de paradigme. Ici le modèle ne lit pas les logs. Il dispose d’un catalogue d’outils et décide lesquels appeler ; c’est le serveur qui interroge Wazuh et renvoie des données réelles.

Le projet : gensecaihq/Wazuh-MCP-Server — MIT, 54 outils répartis en neuf familles.

Famille	Outils	Nature
Alertes	5	lecture
Agents	6	lecture
Vulnérabilités	3	lecture
Analyse de sécurité	5	lecture
Conformité (PCI-DSS, HIPAA, RGPD, ISO 27001)	6	lecture
Système	10	lecture
Réponse active	9	modifie l’état
Vérification	5	contrôle post-action
Annulation	5	modifie l’état

Quatorze outils changent l’état du système et exigent le scope wazuh:write. Les quarante autres se contentent de wazuh:read. Retenez ce chiffre, on y revient à l’étape 6.

5.1 — Déployer

git clone https://github.com/gensecaihq/Wazuh-MCP-Server.git
cd Wazuh-MCP-Server
cp .env.example .env

# .env — commencez en lecture seule. Sans exception.
WAZUH_HOST=<ip-manager>
WAZUH_USER=<compte-lecture-seule>
WAZUH_PASS=<mot-de-passe>

WAZUH_INDEXER_HOST=<ip-indexer>
WAZUH_INDEXER_USER=<user>
WAZUH_INDEXER_PASS=<pass>

docker compose up -d
curl -s http://localhost:3000/health

Le serveur écoute sur 0.0.0.0:3000 et expose /mcp (Streamable HTTP, recommandé), /sse (hérité) et /health (sans authentification).

Deux pièges de configuration, tout de suite

Le serveur parle HTTP en clair. Le TLS se termine en reverse proxy — jamais dans le conteneur. Sur un réseau de base, un MCP non chiffré, c’est votre API Wazuh en libre-service.

En mode production, AUTH_SECRET_KEY est obligatoire et le serveur refuse de démarrer sans. Un mode authless existe : il vous limite à la lecture. Si vous êtes tenté de le laisser en place « le temps du TP », écrivez pourquoi dans votre rendu — et relisez-vous.

5.2 — Brancher un client

Le serveur accepte tout client MCP. Pour rester 100 % local, mcphost avec Ollama :

mcphost -m ollama:llama3.1:8b --config ~/.mcphost.json

{
  "mcpServers": {
    "wazuh": { "type": "streamable", "url": "http://localhost:3000/mcp" }
  }
}

Open WebUI (0.6.31+) fonctionne aussi et donne une interface plus confortable pour la démonstration.

5.3 — La vérification qui compte

Posez la même question qu’à l’étape 4.3, et cette fois regardez les appels d’outils, pas seulement la réponse.

docker compose logs -f | grep -i "tool"

Vous devez pouvoir reconstituer la chaîne : question → outil appelé → paramètres → données renvoyées → conclusion. C’est ça, la différence. Le modèle reste faillible dans son interprétation, mais les faits, eux, viennent de Wazuh.

---

6. Étape 4 — Cinq chasses

Cinq questions, à mener avec l’approche MCP. Pour chacune, remplissez une ligne du journal de chasse.

#	Chasse	Ce que vous cherchez
1	Force brute	Authentifications en échec anormalement groupées — source, cible, fenêtre
2	Surface exposée	Ports ouverts et processus actifs sur les agents : quelque chose écoute-t-il qui ne le devrait pas ?
3	Dette de vulnérabilités	CVE critiques par agent — laquelle exploiteriez-vous en premier ?
4	Horaires	Activité en dehors des plages de travail de la base. Une base australe a des rythmes très réguliers.
5	Libre	Votre propre intuition, issue des Actes 1 et 2. Justifiez-la.

Gabarit du journal de chasse — une ligne par chasse :

#	Question posée	Outils appelés	Données obtenues	Verdict	Preuve
1	« … »	wazuh_search_alerts, …	ex. 47 échecs, 1 IP, 4 min	Confirmé / Bénin / Indéterminé	ID d’alerte ou requête rejouable

La règle qui sépare une chasse d’une conversation

Aucun verdict sans preuve rejouable. Si vous ne pouvez pas donner l’ID d’alerte ou la requête qui permet à un collègue de retrouver le même résultat sans le LLM, vous n’avez pas chassé — vous avez discuté. Une ligne sans preuve vaut zéro, même si la conclusion est juste.

---

7. Étape 5 — Le faux positif austral

Voilà où ce terrain devient intéressant, et où un SOC générique se trompe.

Une base australe produit en permanence des signaux qui ressemblent à une attaque sans en être une :

• une station météo automatique qui reprend son émission après une tempête et rejoue son tampon d’un coup — soudain pic de trafic sortant ;
• un capteur sismique qui redémarre en boucle sur une alimentation instable — échecs d’authentification répétés ;
• un raid vers Concordia qui bascule les liaisons — connexions depuis des adresses inhabituelles ;
• une campagne scientifique de nuit — activité aux heures creuses.

Le travail

1. Choisissez un de ces motifs et retrouvez-le dans vos données.
2. Posez la question au LLM sans le prévenir du contexte scientifique.
3. Consignez son verdict.
4. Reposez la question en donnant le contexte dans votre requête.
5. Comparez.

Question	Verdict du LLM	Justification donnée
Sans contexte
Avec contexte

Ce que vous devez en conclure

Un LLM sans contexte métier classera l’anomalie scientifique comme une attaque. C’est le faux positif le plus coûteux d’un SOC : il use l’analyste, et à force, il fait ignorer la vraie alerte quand elle arrive.

Puis retournez le problème, parce que c’est là qu’est le vrai danger :

La question à laquelle il faut répondre par écrit

Un attaquant qui connaît vos rythmes scientifiques peut déguiser son exfiltration en rejeu de tampon météo. Votre IA, bien contextualisée, la classera « bénigne » avec assurance.

Comment détecte-t-on une attaque qui imite le bruit de fond légitime ? Un paragraphe. C’est la question la plus difficile de tout le module SIEM, et elle n’a pas de réponse propre — on attend un raisonnement, pas une recette.

---

8. Étape 6 — Le doigt sur la détente

Le serveur MCP expose neuf outils de réponse active : bloquer une IP, isoler un hôte, tuer un processus, mettre un fichier en quarantaine. Plus cinq outils d’annulation. Tous derrière wazuh:write.

Jusqu’ici vous étiez en lecture seule. La question est maintenant frontale : accordez-vous wazuh:write à un LLM ?

8.1 — Les quatre niveaux

Niveau	Ce que l’IA fait	Ce que l’humain fait	Risque principal
N0	Rien — lecture seule	Tout	Aucun. Lenteur.
N1	Propose une action rédigée	Exécute	Biais d’automatisation : on valide sans lire
N2	Exécute, réversible et auditée	Contrôle a posteriori	Blocage erroné pendant N minutes
N3	Exécute tout, y compris l’irréversible	Découvre le lendemain	Auto-déni de service

8.2 — Votre matrice

Pour chacune des neuf actives, tranchez et justifiez en une phrase.

Action	Niveau retenu	Justification	Réversible ?
Bloquer une IP			oui — 5 outils d’annulation
Isoler un hôte
Tuer un processus
Mettre un fichier en quarantaine
(compléter les autres)

8.3 — L’incident de refus

Livrable obligatoire. Décrivez une situation, sur votre base, où l’exécution automatique d’une réponse par l’IA aurait aggravé l’incident. Puis dites quel garde-fou l’aurait empêchée.

Une piste, à ne pas recopier telle quelle : à Crozet, isoler « l’hôte compromis » peut couper la seule passerelle SATCOM de la base. L’IA a raison sur la menace et vous laisse aveugle et muet pendant huit heures, à 2 810 km, sans personne pour rebrancher un câble.

Le principe à retenir

Le serveur applique un fail-closed par défaut : sans scope wazuh:write explicite, aucune action d’état n’est possible. Ce défaut est bien choisi. Votre travail d’ingénieur n’est pas de le contourner — c’est de décider, action par action, ce qui mérite d’en sortir.

---

9. Livrables & validation

Livrables

1. Ollama opérationnel : modèle, taille, RAM, latence mesurée.
2. Approche A montée : capture du chat RAG + les trois réponses à la même question.
3. Une hallucination capturée et commentée.
4. Serveur MCP opérationnel : /health en 200 + capture des outils disponibles.
5. Journal de chasse : les 5 lignes complètes, chaque verdict avec sa preuve rejouable.
6. Tableau comparatif RAG vs MCP sur les 4 critères, avec des chiffres mesurés, pas des impressions.
7. Analyse du faux positif austral : les deux verdicts + le paragraphe sur l’attaque camouflée.
8. Matrice de scopes : les 9 actives, niveau et justification.
9. Incident de refus documenté avec son garde-fou.
10. (Bonus) Une règle Sigma qui détecte l’usage abusif de l’API Wazuh elle-même — parce que votre serveur MCP est désormais une cible.

Grille de validation

Critère	Pondération
Ollama local opérationnel et mesuré	10 %
Approche A montée + variabilité démontrée	10 %
Hallucination capturée et analysée	10 %
Serveur MCP opérationnel en lecture seule	10 %
Journal de chasse — 5 lignes avec preuves rejouables	20 %
Comparatif RAG vs MCP chiffré	15 %
Faux positif austral + attaque camouflée	15 %
Matrice de scopes + incident de refus	10 %
(Bonus) Sigma sur l’abus de l’API Wazuh	+10 % bonus

Format de rendu : PDF nom-prenom-promo.pdf sur Moodle.

---

10. Annexe enseignant — corrigé

Attendus par étape

Étape 2 (RAG). Les trois réponses à la même question doivent différer — si l’étudiant rapporte trois réponses identiques, il a probablement figé la température à 0 sans le dire, ou il n’a posé la question qu’une fois. Faire refaire.

Étape 3 (MCP). Le critère discriminant est la trace d’appel d’outil. Un étudiant qui rend une belle réponse sans la chaîne question → outil → données n’a pas compris la différence entre les deux approches, qui est tout l’objet du TP.

Étape 4 (chasses). Le point de bascule est la colonne Preuve. Beaucoup rendront des verdicts plausibles sans ID d’alerte. Pénaliser fermement : c’est exactement l’erreur qu’on veut désapprendre.

Étape 5 (faux positif). Sans contexte, le LLM classe presque toujours en attaque. Le paragraphe sur l’attaque camouflée est le passage le plus révélateur du niveau réel : on accepte « détection sur la forme du trafic plutôt que sur le volume », « corrélation avec le calendrier scientifique déclaré », « baseline par capteur ». On refuse « il suffit d’entraîner mieux le modèle ».

Étape 6 (scopes). Une matrice qui accorde N2 ou N3 à isoler un hôte sans mentionner le risque de coupure SATCOM montre que le contexte du terrain n’a pas été intégré. C’est la faute type.

Erreurs courantes à pénaliser

• Ollama pointé sur une API cloud → -20 %. L’étape 1 dit exactement pourquoi ; c’est le contraire du TP.
• .env avec un compte Wazuh admin au lieu d’un compte lecture seule → -15 %.
• Mode authless laissé actif sans justification écrite → -10 %.
• Journal de chasse sans preuve rejouable → -20 % (le cœur du livrable).
• Comparatif RAG/MCP sans un seul chiffre → -15 %.
• Aucun incident de refus, ou un incident recopié de l’énoncé → -10 %.

Notes logistiques

Prévoir une instance Ollama partagée (16 Go RAM minimum, GPU appréciable) : la majorité des VM SAE ne tiendra pas un 8B en plus de la stack Wazuh. Modèle conseillé côté instructeur : un 9B à 12B quantifié, qui donne des synthèses nettement plus sûres qu’un 3B tout en restant hébergeable.

Vérifier la version de Wazuh avant la séance : hors de la plage 4.8.0–4.14.4, le serveur MCP refuse de démarrer et la séance est perdue.

---

Références

• Wazuh — Leveraging artificial intelligence for threat hunting in Wazuh — l’approche RAG (FastAPI, LangChain, FAISS, Ollama)
• gensecaihq/Wazuh-MCP-Server — le serveur MCP, 54 outils, MIT
• Model Context Protocol — spécification
• Ollama — modèles et déploiement local
• Wazuh — API REST
• Wazuh — Active response
• OWASP Top 10 for Large Language Model Applications