Acte 0 · Phases 4-5 — Peupler le scénario & valider

Acte 0 · Mise en place Phases 4-5 — Scénario & validation

Phase 4 — Peupler le scénario

Les services tournent mais sont vides. On y charge d’abord les données de base du SI — biodiversité en base, documents NextCloud — que l’Acte 1 Monitoring va superviser (4.1, 4.2). Puis, pour le seul module SIEM (Acte 2), les logs de l’incident rejoués à la date du jour (J) par le générateur (data/taaf_log_generator, date-rolling) : la kill chain que le SIEM détectera (4.3). Chaque seed est un script joué délibérément et expliqué, jamais caché dans le provisioning. Les données existent déjà dans le dépôt data ; on ne fait que les charger.

Le dépôt data est déjà cloné à côté de monitoring (Phase 3). Tout ce qui suit se joue dans la VM apps (c’est là que vivent PostgreSQL, NextCloud et Alloy), sous le compte taaf-engineer.

4.1 — Base de données (genetic_samples)

Source : data/Base Port-aux-Français/MDV_Biodiversity_Data.sql (tables endemic_species, genetic_samples — dont KER-2024-002, CLASSIFIED).

docker exec -i postgres-af psql -U taaf_admin -d base_af \
  < ~/"data/Base Port-aux-Français/MDV_Biodiversity_Data.sql"

Checkpoint :

docker exec -it postgres-af psql -U taaf_admin -d base_af \
  -c "SELECT sample_id FROM genetic_samples WHERE sample_id='KER-2024-002';"
# → 1 ligne. La cible du vol existe.

4.2 — Documents NextCloud

Source : data/NextCloud/ (Biologie-Marine, Document-Technique, Administratif [docs Julie Moreau], Sismologie…) → le coffre que l’attaquant exfiltre.

# Copier les dossiers dans l'espace de l'admin NextCloud
docker cp ~/data/NextCloud/. nextcloud-alfred-faure:/var/www/html/data/admin.cloud.af/files/
# Re-scanner pour que NextCloud indexe les fichiers
docker exec -u www-data nextcloud-alfred-faure php occ files:scan admin.cloud.af

Checkpoint : les dossiers apparaissent dans l’UI (http://IP_APPS:8081), dont Administratif/.

4.3 — Logs de l’incident

Étape réservée au module SIEM (Acte 2)

Cette étape rejoue la kill chain : elle ne sert qu’au module SIEM, où vous la détecterez. L’Acte 1 Monitoring n’en a pas besoin — il supervise les métriques et les logs de fonctionnement des apps (Nextcloud, PostgreSQL), qui coulent déjà via Alloy. Vous pouvez sauter 4.3 jusqu’au début de l’Acte 2.

Elle s’appuie sur _scenario/entities.yaml — le corrigé du scénario, donc non versionné (spoile la détection) et fourni par l’enseignant au démarrage du module SIEM.

Source : data/taaf_log_generator (générateur TAAF-Rolling, piloté par _scenario/entities.yaml) → produit toutes les sources de la kill chain, datées du jour (date-rolling) : phishing .eml, Windows LotL, auth VPN/AD, accès DB (SQL), Falco, Zeek (ssl/conn/arp), télémétrie SATCOM.

cd ~/monitoring
./regen-logs.sh 2026-A

Ce script joue, dans l’ordre : le générateur (conteneur log-generator, qui lit ../data/taaf_log_generator et _scenario/entities.yaml), la réinitialisation de Loki (état propre, aucun doublon), la ré-ingestion par Alloy, puis le bruit de fond bénin continu (log-streamer) — sans lui, l’incident serait le seul trafic, et trop facile à voir. Lisez le script (cat regen-logs.sh) : il fait quatre choses, vous devez savoir lesquelles.

Sous le capot

Le générateur est un package Python (data/taaf_log_generator, make help pour les cibles). regen-logs.sh l’exécute dans un conteneur pour que personne n’ait à installer Python dans la VM.

Checkpoint : dans Grafana → Explore (datasource Loki), les logs du scénario sont interrogeables :

{log="ssl"} |= "x25519" != "X25519MLKEM768"

Variante par promo

SEED=2026-A produit un jeu cohérent mais propre à la promo (évite le copier-coller des réponses entre étudiants). La date change toute seule (jour courant) : impossible de réutiliser le corrigé d’une session sur l’autre.

Phase 5 — Validation « suis-je prêt ? »

Checklist finale avant l’Acte 1 :

• vagrant status → VMs apps et monitoring running
• PostgreSQL base_af répond, genetic_samples peuplée (KER-2024-002 présent)
• NextCloud répond (:8081), documents data/NextCloud/ visibles
• Grafana / Prometheus / Loki répondent (checkpoints Phase 3)
• Les logs de fonctionnement des apps (Nextcloud, PostgreSQL) remontent dans Loki via Alloy
• (Module SIEM uniquement — Acte 2, pas requis pour l’Acte 1) Logs de l’incident datés du jour visibles dans Loki après regen-logs.sh

Active Directory n’est pas requis ici : il est monté plus tard, dans le TP d’intégration Windows (Acte 2).

→ ✅ tout coché = feu vert pour l’Acte 1 — Monitoring.

Pourquoi cette discipline

Un environnement validé phase par phase = vous savez exactement ce qui tourne et pourquoi. C’est la base d’un bon analyste : on ne supervise/détecte bien que ce qu’on a soi-même compris.