SIEM — Détection des menaces (SOC Grafana-natif)

Acte 2 Tronc commun · les deux publics Avancé Sigma · LogQL · Falco · Zeek

Acte 2 — Sentinelle

La DSI voit, désormais. Mais voir ne suffit pas : des connexions anormales rôdent autour des liaisons satellite. Constater un incident, c’est déjà trop tard — il faut le détecter avant.

Vous transformez la supervision en sentinelle. Pas en déployant un produit à part : en posant une lentille sécurité sur la stack d’observabilité de l’Acte 1. Un SIEM, ici, c’est ce que vous faites de vos logs — des règles de détection, de la corrélation, de l’alerting.

→ Le parcours complet : la progression et les deux parcours · le threat model (quel TP traite quelle menace).

D’où vous arrivez — et où cet acte vous mène

Vous venez de l’Acte 1 : l’infrastructure est visible. Elle n’est pas encore vigilante.

• Vous avez bâti la base (ingénieurs) — c’est ici que votre parcours se referme. L’attaquant se déplace dans les zones que vous avez découpées au TP1 et se heurte — ou non — aux règles que vous avez écrites. Les encarts [FULL] de cet acte vous renvoient à votre propre conception : ta segmentation l’a-t-elle ralenti ? ton default-deny a-t-il tenu ?
• Vous tenez la base (BUT) — cet acte ne juge personne. Il sert à établir ce qui s’est réellement passé sur une architecture que vous n’avez pas dessinée et dont vous répondez quand même. Le concepteur peut expliquer ses intentions ; vous n’avez que les traces. Vous continuez ensuite vers l’Acte 3.

Le principe : SOC Grafana-natif

Une seule collecte (Alloy), un seul stockage (Loki), un seul langage (LogQL), une seule vitre (Grafana) — les mêmes que l’Acte 1 et l’Acte 3. La couche SIEM s’ajoute par-dessus :

• Détection-as-code — règles Sigma (standard, mappées MITRE ATT&CK) compilées en LogQL (pySigma-backend-loki). Vous écrivez une détection, vous ne cliquez pas dans une UI propriétaire.
• Alerting — Grafana Alerting (Alertmanager intégré) → Discord, avec notification policies par sévérité.
• Sources ingérées — Falco (runtime), Zeek (ssl/conn/arp), Windows/AD, auth VPN, NextCloud audit, télémétrie SATCOM, PostgreSQL → Loki (via Alloy).
• Couverture — tagging ATT&CK + visualisation (S2AN → Navigator).

Zeek est ingéré, sa détection active vient à l’Acte 3

Zeek est collecté dans Loki dès l’Acte 2 (job="zeek", log=ssl|conn|arp), mais écrire des règles de détection dessus n’est pas au tronc commun de cette SAE. Cette exploitation active de Zeek est traitée à l’Acte 3.

🇫🇷 Cadre réglementaire

Ce module répond à l’axe « supervision et réponse à incidents » de la feuille de route de sécurité numérique de l’État (logique CSIRT / CERT-FR). Voir le Cadre réglementaire.

Golden-box

Le cœur tient en ~3-4 Go (Loki/Grafana/Falco) — il tourne sur la golden-box. Pas de JVM OpenSearch dans le tronc commun.

Ce que vous allez détecter

L’attaque rejouée à la date du jour (J) (cf threat model). L’Acte 2 prend en charge ses temps « actifs », tous détectables sur les sources ingérées : auth VPN externe (auth), escalade AD svc_backup→Domain Admins (windows), accès coffre (nextcloud+falco), pg_dump runtime (falco), sortie C2 corrélée (falco+zeek), repli DNS tunneling (falco) et downgrade SATCOM (zeek+sat_telemetry).

Travaux Pratiques

Ordre	TP	Ce que vous y faites
Prérequis	SSO AD ↔ NextCloud	Faire de l’AD le hub d’identité (#8)
1	Détection Sigma → LogQL	Écrire des règles, les compiler en LogQL
2	Alerting & Discord	Déclencher l’attaque, faire tomber l’alerte
3	Couverture & Corrélation	MITRE coverage + corrélation (et ses limites)
Bonus	Wazuh — SIEM clé-en-main	Comparer un SIEM monté vs celui que vous avez bâti
Bonus	Intégration Windows	Sources AD / Windows
Bonus	Threat hunting IA	Chasser en langage naturel (Ollama + MCP Wazuh)

Livrables & évaluation

Voir le CONSIGNES-SAE-SIEM pour les livrables et la grille.

---