TP 2 — Alerting & Notification Discord

Acte 2 · SIEM Avancé Grafana Alerting · Discord · rejeu d'incident

---

Légende — les trois machines du TP

Placeholder	Machine	Ce qui tourne dessus
IP_APPS	Applications	PostgreSQL, NextCloud, Adminer — le SI observé
IP_VM1	Supervision	Grafana, Prometheus, Loki, Alertmanager
IP_VM2	SOC	Grafana de détection, règles Sigma, alerting
IP_VM3	Audit	Outillage offensif et de conformité

Relevez vos adresses avec hostname -I sur chaque VM. Les noms réels des machines sont dans Infrastructure — les énoncés n’en dépendent pas.

---

1. Objectif & contexte

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

Une détection ne sert à rien si personne ne la voit. On ferme la boucle : règle Sigma → requête LogQL → alerte Grafana → notification Discord — sur la même stack Grafana, sans composant externe.

🔴 Au fil de l’enquête

La règle existe (TP 1) mais elle dort. Le jour J, aucune alerte n’a jamais tonné — personne n’avait fermé la boucle. Ici vous la fermez : vous déclenchez l’attaque depuis votre poste, et vous regardez la notification tomber dans Discord. C’est la seconde qui aurait réveillé l’astreinte ce jour-là.

Objectifs pédagogiques

• Comprendre la chaîne règle ⇒ alert rule ⇒ notification policy ⇒ contact point.
• Provisionner une alerte par YAML (alerting-as-code) — pas par clics dans l’UI.
• Configurer des notification policies par sévérité (Discord channel routing).
• Déclencher l’attaque en rejouant l’incident (regen-logs.sh) et voir la notification tomber.
• Tuner les faux positifs contre le bruit de fond du log-streamer.

Architecture du TP2

graph LR
 subgraph "Détection-as-Code (TP1)"
 RULE[/règle.yml<br/>Sigma/]
 end

 subgraph "Compilation"
 SIGMA[sigma convert<br/>-f grafana_alerting]
 end

 subgraph "Grafana Alerting"
 PROV[/provisioning/<br/>alert-rules.yml/]
 AR[Alert Rule]
 NP[Notification Policy<br/>severity routing]
 CP[Contact Point<br/>Discord webhook]
 end

 subgraph "Sortie"
 DISCORD([Discord<br/>#soc-critical<br/>#soc-info])
 end

 RULE --> SIGMA
 SIGMA --> PROV
 PROV --> AR
 AR -->|severity label| NP
 NP --> CP
 CP --> DISCORD

 classDef code fill:#99ff99,stroke:#333,stroke-width:2px
 classDef alert fill:#ffccff,stroke:#333,stroke-width:2px
 classDef out fill:#ffcc99,stroke:#333,stroke-width:2px

 class RULE,SIGMA,PROV code
 class AR,NP,CP alert
 class DISCORD out

---

2. Prérequis

TP1 validé

Vous arrivez avec un repo taaf-detections contenant au moins :

• rules/initial_access/vpn-auth-external-ip.yml
• rules/collection/falco-classified-vault-read.yml
• rules/exfiltration/falco-pgdump-genetic-samples.yml
• scripts/compile.sh

Discord — créer un webhook

1. Discord → votre serveur de TP → Paramètres du salon → Intégrations → Créer un webhook.
2. Nommez-le TAAF-SOC-bot, choisissez le salon #soc-critical (créez-le si besoin).
3. Copiez l’URL du webhook : https://discord.com/api/webhooks/<id>/<token>.

Vérifiez :

curl -X POST -H "Content-Type: application/json" \
  -d '{"content":"Hello from TAAF SOC 👋"}' \
  "$DISCORD_WEBHOOK_CRITICAL"

→ Un message doit apparaître dans #soc-critical.

Créez aussi #soc-info (avec son propre webhook → $DISCORD_WEBHOOK_INFO).

Outils d’attaque

• Le générateur du scénario (dépôt data, joué par regen-logs.sh en Acte 0 Phase 4) — c’est lui qui réinjecte la kill chain datée maintenant, sur laquelle vos alertes se déclenchent.

Bonus — trafic live

Pour aller plus loin, générer du vrai trafic suspect (DNS exfil, beaconing) avec un outil comme flightsim est possible, mais hors tronc commun : la SAE se valide sur le rejeu de l’incident, pas sur du trafic fabriqué à la main.

---

3. Étape 1 — Webhook Discord + Contact Point Grafana

3.1 — Créer le contact point dans Grafana

Ouvrez Grafana (http://IP_VM1:3000) → Alerting → Contact points → + Add contact point.

Champ	Valeur
Name	discord-soc-critical
Integration	Discord
Webhook URL	<votre webhook critical>
Use Discord username	TAAF-SOC-bot
Avatar URL	(laissez vide ou mettez un logo TAAF)
Message Content	{{ template "discord.taaf.message" . }}
Use template for message	✅ (on créera le template en 3.3)

Test : bouton Test → vous devez voir un message arriver dans #soc-critical.

Recommencez pour discord-soc-info (webhook info).

3.2 — Provisionner par YAML (recommandé pour la traçabilité)

Plutôt que de cliquer, déposez dans le repo monitoring le fichier grafana/provisioning/alerting/contact-points.yml :

apiVersion: 1
contactPoints:
  - orgId: 1
    name: discord-soc-critical
    receivers:
      - uid: discord_critical
        type: discord
        settings:
          url: ${DISCORD_WEBHOOK_CRITICAL}
          use_discord_username: true
          username: TAAF-SOC-bot
          message: |
            {{ template "discord.taaf.message" . }}
  - orgId: 1
    name: discord-soc-info
    receivers:
      - uid: discord_info
        type: discord
        settings:
          url: ${DISCORD_WEBHOOK_INFO}
          username: TAAF-SOC-bot
          message: |
            {{ template "discord.taaf.message" . }}

Et dans .env du compose Grafana :

DISCORD_WEBHOOK_CRITICAL=https://discord.com/api/webhooks/.../...
DISCORD_WEBHOOK_INFO=https://discord.com/api/webhooks/.../...

docker compose restart grafana

3.3 — Template Discord lisible

Dans Grafana → Alerting → Contact points → Notification templates → + Add template :

{{ define "discord.taaf.message" }}
🚨 **{{ .CommonLabels.alertname }}** — {{ .CommonLabels.severity | toUpper }}

{{ range .Alerts }}
**État :** {{ .Status }}
**Règle :** `{{ .Labels.rulename }}` (ATT&CK : {{ .Labels.attack_id }})
**Source :** {{ .Labels.job }}
**Détails :** {{ .Annotations.summary }}
**Lien :** [Explore]({{ .GeneratorURL }})
{{ end }}
{{ end }}

---

4. Étape 2 — Compiler Sigma → Alerte Grafana

Reprenez le repo taaf-detections du TP1.

4.1 — Conversion avec le format grafana_alerting

cd ~/taaf-detections
source ~/sigma-venv/bin/activate

sigma convert \
  -t loki \
  -f grafana_alerting \
  -p loki_grafana \
  rules/initial_access/vpn-auth-external-ip.yml \
  > build/alerts/vpn-auth-external-ip.yml

Sortie attendue (extrait) :

apiVersion: 1
groups:
  - orgId: 1
    name: taaf-detections
    folder: SOC-TAAF
    interval: 1m
    rules:
      - uid: vpn-auth-external-ip
        title: VPN Authentication from External IP (TAAF)
        condition: A
        data:
          - refId: A
            datasourceUid: loki
            model:
              expr: |
                {job="auth"} |= `WARNING` |= `external IP`
        noDataState: OK
        execErrState: Error
        for: 1m
        labels:
          severity: high
          attack_id: T1078
          attack_id_secondary: T1133
        annotations:
          summary: "Auth VPN externe pour utilisateur TAAF"
          description: "Auth VPN réussie depuis IP non-interne, non-partenaire."

4.2 — Étendre scripts/compile.sh

#!/usr/bin/env bash
set -euo pipefail
OUT_LOGQL="build/logql"
OUT_ALERTS="build/alerts"
mkdir -p "$OUT_LOGQL" "$OUT_ALERTS"

find rules -name "*.yml" -type f | while read -r rule; do
  name=$(basename "$rule" .yml)
  echo "[+] $rule"
  sigma convert -t loki -p loki_grafana "$rule" > "$OUT_LOGQL/$name.logql"
  sigma convert -t loki -f grafana_alerting -p loki_grafana "$rule" > "$OUT_ALERTS/$name.yml"
done
echo "[✓] $(ls "$OUT_LOGQL" | wc -l) LogQL · $(ls "$OUT_ALERTS" | wc -l) alertes Grafana"

./scripts/compile.sh

---

5. Étape 3 — Provisionner l’alerte par YAML

5.1 — Déposer les alertes dans le provisioning Grafana

Copiez build/alerts/*.yml dans le volume monté par Grafana :

# Depuis le repo monitoring
mkdir -p grafana/provisioning/alerting/rules
cp ~/taaf-detections/build/alerts/*.yml grafana/provisioning/alerting/rules/

# Redémarrer Grafana pour charger
docker compose restart grafana
docker compose logs -f grafana | grep -i alert

Vérification : Grafana → Alerting → Alert rules → dossier SOC-TAAF → 3 règles visibles.

5.2 — Tester sans attendre l’attaque

Dans l’UI de l’alerte → Preview → exécute la query et montre les résultats actuels. Si vos logs du jour J sont peuplés, la query doit retourner ≥ 1 ligne → l’alerte passera en Pending puis Firing après for: 1m.

---

6. Étape 4 — Notification policies par sévérité

6.1 — Créer la policy

Grafana → Alerting → Notification policies → Default policy → + New nested policy :

Champ	Valeur
Matching labels	severity = critical
Contact point	discord-soc-critical
Group by	alertname, attack_id
Group wait	15s
Group interval	1m
Repeat interval	4h

Recommencez :

| severity = high | discord-soc-critical | | severity = medium | discord-soc-info | | severity = low | discord-soc-info |

6.2 — Provisionner par YAML

grafana/provisioning/alerting/notification-policies.yml :

apiVersion: 1
policies:
  - orgId: 1
    receiver: discord-soc-info     # default
    group_by: [alertname]
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 12h
    routes:
      - receiver: discord-soc-critical
        matchers:
          - severity =~ "critical|high"
        group_by: [alertname, attack_id]
        group_wait: 15s
        group_interval: 1m
        repeat_interval: 4h
      - receiver: discord-soc-info
        matchers:
          - severity =~ "medium|low"

docker compose restart grafana

6.3 — La leçon « fatigue d’alerte »

Mauvaise pratique	Symptôme
Tout en severity: critical	L’astreinte se déconnecte au bout d’1 semaine
Pas de group_by	50 alertes pour 1 incident — analyste noyé
repeat_interval: 1m	Spam Discord, on désactive le webhook
Pas de silences pour la maintenance	Faux positifs pendant les déploiements

→ Documentez votre politique d’alerting dans le README.md du repo taaf-detections.

---

7. Étape 5 — Déclencher l’attaque (R3)

Le déclencheur, c’est le rejeu. Vous ne fabriquez pas de faux événements à la main : le générateur réinjecte la kill chain complète datée à l’instant présent. Vos règles, évaluées sur la fenêtre récente, tombent alors pour de vrai.

Sur la VM apps (où vivent Alloy et le générateur) :

cd ~/monitoring
./regen-logs.sh 2026-A          # réinjecte l'incident (auth, windows, falco, zeek, nextcloud…) daté maintenant

Puis, dans les ~2 minutes (intervalle d’évaluation Grafana), les alertes correspondantes passent Firing et tombent dans Discord :

Signal rejoué	Règle qui tombe	LogQL de l’alerte
Auth VPN externe (T1078)	vpn-auth-external-ip	{job="auth"} |= "WARNING" |= "external IP"
Accès coffre (T1213)	falco-classified-vault-read	{job="falco"} | json | rule="Read sensitive file untrusted" |= "CLASSIFIED-VAULT-X"
pg_dump exfil (T1041)	falco-pgdump-genetic-samples	{job="falco"} |= "pg_dump"

Bonus optionnel, non requis

Le rejeu réinjecte aussi une sortie C2 (T1071, 185.220.101.42) visible dans job="zeek", log="conn". Elle n’est pas couverte par une règle du tronc TP1-3 — ce n’est pas un livrable noté de la SAE. Si vous voulez aller plus loin, c’est une piste d’exploration bonus, pas une règle fournie ou attendue.

📸 Capture #1 : Grafana → Alert state Firing. 📸 Capture #2 : message Discord avec le template rendu (severity=critical, mention du signal).

Si vous avez fait la Conception d’architecture

Le beaconing suppose une sortie vers Internet depuis la zone données. Votre matrice de flux du TP1 l’aurait-elle laissé passer ? C’est exactement le point d’orgue du fil rouge.

---

8. Étape 6 — Tuner les faux positifs (R4)

8.1 — Le bruit de fond bénin est déjà là (log-streamer)

Vous n’avez pas à fabriquer le bruit : le service log-streamer de la Phase 4 (profil scenario) réinjecte en continu de l’activité bénigne fraîche dans les cinq catégories (auth, réseau, satcom, système, falco). C’est sur ce bruit que vos règles doivent rester silencieuses — sinon elles crient au loup.

# Sur la VM apps — vérifier que le streamer tourne
docker compose -f docker-compose-apps.yml ps log-streamer

Laissez-le tourner pendant que vous observez vos alertes.

Bonus — plus de bruit

Simuler de l’activité utilisateur riche (browsing, mails) avec GHOSTS est possible en bonus, mais hors tronc commun : le log-streamer suffit à mesurer les faux positifs.

8.2 — Observer les faux positifs

Vérifiez #soc-info : combien d’alertes medium/low sont tombées sans qu’il y ait eu d’attaque ?

8.3 — Tuner

Ajoutez des filter_* dans les règles Sigma. Exemple — la règle pg_dump ne doit pas s’affoler sur un dump de maintenance planifié : on exclut la fenêtre de sauvegarde légitime (le job tourne la nuit, jamais depuis un shell interactif) :

detection:
  keywords:
    - 'pg_dump'
  filter_maintenance:
    output|contains: 'cron'          # le backup planifié passe par cron, pas par 'sh -c'
  condition: keywords and not filter_maintenance

Recompilez (./scripts/compile.sh), redéployez (docker compose restart grafana), laissez tourner le bruit de fond (le log-streamer de la Phase 4) — comparez le nombre de FP avant/après.

8.4 — Tableau de tuning (livrable)

Règle	FP avant tuning	Cause FP	Filtre ajouté	FP après tuning
falco-pgdump-genetic-samples	8 / heure	dump de maintenance planifié	filter_maintenance_window	0
vpn-auth-external-ip	0	—	—	0
falco-classified-vault-read	2 / heure	Backup nightly	vault_authorized_users += backup-cron	0

---

9. Souveraineté — Discord en prod ?

Discord est un SaaS US

Discord = pratique et engageant pour le lab, mais en production des alertes de sécurité ne devraient pas transiter par un cloud tiers :

• NIS 2 (Art. 21 §2.c) : la confidentialité des incidents fait partie de la gestion des risques.
• IGI 1337 : les flux d’alerte d’un SI étatique doivent rester sous contrôle souverain.
• RGPD : un utilisateur compromis = un nom dans une alerte = donnée personnelle.

En production réelle, vous remplaceriez Discord par : Mattermost auto-hébergé, Element/Matrix, Signal API, ou un CSIRT/CERT dédié (le CERT-FR pour les ministères).

À mentionner dans votre rapport : un paragraphe de ~10 lignes sur le pourquoi du choix Discord (pédagogique) et le plan de migration vers un canal souverain pour la prod.

---

10. Livrables & validation

Livrables (à pousser sur GitLab)

1. Repo taaf-detections enrichi :
   • build/alerts/*.yml (3 alertes Grafana compilées)
   • scripts/compile.sh étendu (LogQL + alerts)
   • README.md avec la politique d’alerting (sévérités, groupings, repeat intervals)
2. Repo monitoring enrichi :
   • grafana/provisioning/alerting/contact-points.yml
   • grafana/provisioning/alerting/notification-policies.yml
   • grafana/provisioning/alerting/rules/*.yml (3 fichiers copiés du build)
   • grafana/templates/discord.taaf.tmpl (notification template)
3. 3 captures :
   • Grafana Alert state Firing
   • Message Discord #soc-critical (template rendu)
   • Tableau Notification policies
4. Tableau de tuning FP (markdown ou PDF) — § 8.4

Grille de validation

Critère	Pondération
Webhook Discord configuré et testé (test message reçu)	10 %
Contact points provisionnés par YAML (pas par clics)	15 %
Compilation Sigma → grafana_alerting fonctionnelle (3 alertes)	20 %
Notification policies par sévérité (≥ 2 routes)	15 %
Au moins une attaque déclenchée fait tomber une notification Discord	20 %
Tableau de tuning FP rempli avec valeurs réelles	10 %
Paragraphe souveraineté + plan de migration	10 %

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

---

11. Annexe enseignant — corrigé

Notification policy YAML — version corrigée

(Voir § 6.2 — vérifier qu’elle est strictement identique chez l’étudiant.)

Évaluation des erreurs courantes

• Webhook hardcodé dans contact-points.yml (sans ${DISCORD_WEBHOOK_CRITICAL}) → push d’un secret sur Git. -15 %.
• Pas de group_by → la promo a découvert l’effet en TP : 30+ notifications pour 1 attaque. -10 %.
• for: à 0s → l’alerte tombe puis se résout aussitôt (oscillation). Doit être ≥ 1 min. -5 %.
• Sévérité non cohérente avec la règle Sigma (level: critical dans Sigma mais severity: medium dans le label Grafana) → -5 %.

Pont vers le TP3

À la fin du TP2, l’étudiant a 3 alertes provisionnées qui tombent quand l’attaque est rejouée. Au TP3, on va mesurer la couverture ATT&CK de ces règles (S2AN → Navigator) et construire une corrélation multi-étapes (phishing → puis → escalade → puis → exfil) pour reconstruire la kill chain, pas juste voir des alertes éparses.

---

Références

• Grafana Alerting documentation
• Grafana provisioning — Alerting
• flightsim
• GHOSTS
• Sigma backend grafana_alerting
• Discord webhooks documentation