Projet Jour 5 — SOC Intégrateur

🚨

Snapshot obligatoire avant de commencer

Faire un snapshot "Jour5_Depart" sur toutes les VMs avant tout. En cas de problème grave (VM corrompue, disque plein, services cassés), vous pourrez revenir à l'état initial. Sans snapshot, aucun retour en arrière possible.

📋 Description du projet

—

Contexte : vous êtes l'équipe SOC d'une entreprise

Votre entreprise vient de déployer un SI composé d'un serveur Linux (VM cible) et d'une infrastructure réseau NAT VMware. La direction vous demande de mettre en place un SOC opérationnel, de le valider face à des attaques réelles et de présenter le bilan de sécurité.

Votre rôle est double : défenseur (vous construisez et opérez le SOC) et attaquant (vous simulez les menaces pour valider la détection). Cette dualité est la réalité quotidienne d'un ingénieur SOC.

🗺️ Les 5 phases du projet

Phase 1 · 09h00 – 10h30

Vérification & consolidation de l'infrastructure SOC

Vérifier que tous les services des Jours 1 à 4 fonctionnent. Corriger les services en panne. S'assurer que les alertes et dashboards sont opérationnels. C'est votre état "avant attaque".

Phase 2 · 10h30 – 12h00

Configuration de la corrélation d'événements complexes

Construire une règle SPL de corrélation multi-outils (Suricata + SSH + Wazuh) et une nouvelle alerte de haut niveau. Mesurer le taux de couverture "avant attaque".

Phase 3 · 13h00 – 15h30

Lancement des attaques de validation (VM Kali)

Simuler 6 types d'attaques depuis la VM Kali. Vérifier que chaque attaque est détectée et enregistrée dans Splunk. Mesurer le taux de couverture "après attaque".

Phase 4 · 15h30 – 16h30

Rapport écrit de synthèse

Rédiger le rapport de mise en place avec captures d'écran, métriques, analyse du taux de couverture et recommandations. Document à remettre à l'enseignant.

Phase 5 · 16h30 – 18h00

Soutenance orale (10 min par binôme)

Présentation des résultats, démonstration live optionnelle, questions de l'enseignant. Chaque membre du binôme présente une partie.

🏗️ Architecture cible du projet

VM	Rôle	IP NAT	Services actifs	Statut requis
VM SOC	Serveur central de détection	`192.168.91.10`	Splunk :8000, Elasticsearch :9200, Logstash :5514, Suricata, Wazuh Manager :1514	✅ Requis
VM Linux Cible	Hôte surveillé — cible des attaques	`192.168.91.20`	SSH :22, Apache :80, Splunk UF :9997, rsyslog, Fail2ban, Wazuh Agent	✅ Requis
VM Kali	Simulateur d'attaques	`192.168.91.40`	Nmap, Hydra, Nikto, curl	⚠️ Phase 3 seulement

📦 Livrables à remettre

Rapport écrit (PDF)

Document PDF de 10 à 20 pages, remis avant la soutenance. Structure détaillée dans l'onglet Livrables & Questionnaire.

Soutenance orale (10 min)

Présentation des résultats + Q&A. Slides recommandées mais non obligatoires. Démonstration live fortement appréciée.

Screenshots des alertes déclenchées

Une capture par attaque lancée, montrant l'alerte dans Splunk (Activité → Alertes déclenchées) ou dans le dashboard.

Tableau de couverture

Tableau avant/après avec le taux de couverture calculé pour chaque vecteur d'attaque testé. Template disponible dans l'onglet Rapport.

Vérification systématique de tous les services Toutes les VMs

⏱ ~45 min

Checklist de démarrage — VM SOC VM SOC

Script de vérification globaleVM SOC

# ── ESPACE DISQUE (critique — vérifier en premier) ──
df -h /
# → Doit avoir au moins 2 Go libres. Si plein : sudo truncate -s 0 /var/log/suricata/eve.json

# ── SPLUNK ENTERPRISE ──
sudo /opt/splunk/bin/splunk status
ss -tlnp | grep 8000
# → "splunkd is running" + port 8000 en écoute

# ── ELASTICSEARCH ──
curl -s http://localhost:9200 | python3 -m json.tool | grep tagline
# → "You Know, for Search"

# ── LOGSTASH ──
sudo systemctl status logstash --no-pager | head -5
# → "active (running)"

# ── SURICATA ──
sudo systemctl status suricata --no-pager | head -5
sudo tail -3 /var/log/suricata/fast.log 2>/dev/null || echo "fast.log vide — OK si aucun trafic"

# ── WAZUH MANAGER ──
sudo /var/ossec/bin/agent_control -l
# → Doit afficher au moins 1 agent "Active"

# ── SPLUNK UF (sur VM SOC) ──
sudo /opt/splunkforwarder/bin/splunk status

Checklist de démarrage — VM Cible VM Cible

Script de vérification globaleVM CIBLE

# ── SSH ──
sudo systemctl status ssh --no-pager | head -3

# ── APACHE ──
sudo systemctl status apache2 --no-pager | head -3
curl -s http://localhost | grep -i "apache\|html\|It works" | head -2

# ── RSYSLOG → SOC ──
logger -p auth.warning "TEST_J5_$(date +%H%M%S)"
sleep 3
curl -s "http://192.168.91.10:9200/syslog-*/_search?q=TEST_J5&pretty" \
  | python3 -m json.tool | grep '"message"' | head -2
# → Doit retourner le message de test

# ── SPLUNK UF ──
sudo /opt/splunkforwarder/bin/splunk status

# ── FAIL2BAN ──
sudo fail2ban-client status
sudo fail2ban-client status sshd

# ── WAZUH AGENT ──
sudo /var/ossec/bin/wazuh-control status | grep "is running"

Vérification des données dans Splunk VM SOC

Depuis l'interface web Splunk, s'assurer que toutes les sources de données sont actives et récentes.

SPL — Vérification des sourcetypes présents

# Vérifier que toutes les sources remontent dans l'index security
index=security earliest=-1h
| stats count, max(_time) as derniere_donnee by sourcetype
| eval age_minutes=round((now()-derniere_donnee)/60,0)
| table sourcetype, count, age_minutes
| sort age_minutes

# Résultat attendu :
# sourcetype         count  age_minutes
# linux_secure       XXX    < 60
# suricata           XXX    < 60
# wazuh              XXX    < 60
# fail2ban           XXX    < 60
# wazuh              XXX    < 60   (inclut les logs Apache)

⚠️

Un sourcetype absent ou trop ancien ?

Si un sourcetype n'apparaît pas ou a une ancienneté > 60 min, le service correspondant est probablement en panne. Se référer aux TPs des jours précédents pour le redémarrer. Ne pas avancer à la Phase 2 tant que tous les sourcetypes ne sont pas actifs.

Mesure de l'état "avant attaque" VM SOC

⏱ ~30 min

Mesurer le taux de couverture initial VM SOC

Le taux de couverture mesure la proportion des vecteurs d'attaque qui sont détectés par le SOC. C'est la métrique principale de votre rapport.

SPL — État initial : volume par outil

# Volume d'événements par outil sur les dernières 24h
index=security earliest=-24h
| eval outil=case(
    sourcetype=="suricata" AND event_type="alert", "Suricata NIDS",
    sourcetype=="linux_secure" AND match(_raw,"Failed password"), "SSH Brute Force",
    sourcetype=="fail2ban" AND match(_raw,"Ban"), "Fail2ban Bans",
    sourcetype=="wazuh", "Wazuh HIDS",
    sourcetype=="access_combined", "Apache Web",
    true(), "Autre")
| where outil!="Autre"
| stats count by outil
| sort -count

📌

Copier ces chiffres dans votre rapport — section "État avant attaque"

Ces valeurs de référence serviront à comparer avec les chiffres "après attaque" et à calculer l'augmentation de détection générée par les attaques simulées. C'est le cœur de votre analyse.

Règle de corrélation multi-outils VM SOC

⏱ ~45 min

Construire la requête de corrélation Suricata + SSH + Fail2ban

Cette requête reconstitue la chronologie d'une attaque brute-force complète : scan réseau détecté par Suricata → tentatives SSH détectées dans linux_secure → bannissement Fail2ban. Trois outils, un seul incident.

SPL — Corrélation attaque brute-force complète

index=security earliest=-1h
  (sourcetype=suricata event_type=alert)
  OR (sourcetype=linux_secure "Failed password")
  OR (sourcetype=fail2ban "Ban")
| eval phase=case(
    sourcetype=="suricata",    "1_Reconnaissance",
    sourcetype=="linux_secure","2_BruteForce",
    sourcetype=="fail2ban",    "3_Detection_Ban")
| eval src=coalesce(
    spath(_raw,"src_ip"),
    replace(_raw,".*from (\d+\.\d+\.\d+\.\d+).*","\1"),
    replace(_raw,".*Ban (\d+\.\d+\.\d+\.\d+).*","\1"))
| where isnotnull(src) AND src!="127.0.0.1"
| stats
    count as evenements,
    min(_time) as premier_evt,
    max(_time) as dernier_evt,
    values(phase) as phases_detectees
    by src
| eval duree_min=round((dernier_evt-premier_evt)/60,1)
| eval attaque_complete=if(mvcount(phases_detectees)>=2,"OUI","PARTIELLE")
| table src, evenements, phases_detectees, duree_min, attaque_complete
| sort -evenements

💡

Interpréter les résultats

Une IP avec attaque_complete=OUI et 3 phases détectées = l'attaque entière est visible dans le SOC. Une IP avec attaque_complete=PARTIELLE et 1 seule phase = le SOC a une détection partielle sur cet attaquant. Le rapport devra analyser ces cas.

Alerte de corrélation — Attaque multi-étapes détectée

Créer une alerte Splunk basée sur la requête de corrélation. Elle se déclenche quand une IP traverse au moins 2 phases de la kill chain.

SPL — Base de l'alerte de corrélation

index=security earliest=-10m
  (sourcetype=suricata event_type=alert)
  OR (sourcetype=linux_secure "Failed password")
  OR (sourcetype=fail2ban "Ban")
| eval src=coalesce(
    spath(_raw,"src_ip"),
    replace(_raw,".*from (\d+\.\d+\.\d+\.\d+).*","\1"),
    replace(_raw,".*Ban (\d+\.\d+\.\d+\.\d+).*","\1"))
| where isnotnull(src) AND src!="127.0.0.1"
| stats dc(sourcetype) as nb_outils by src
| where nb_outils >= 2

Configuration Splunk

Nom       : Attaque Multi-Etapes Detectee
Schedule  : Every 10 minutes — Last 10 minutes
Trigger   : Number of Results > 0
Throttle  : 30 minutes, champ : src
Action    : Ajouter aux alertes déclenchées (Gravité : Critique)
            + Email si SMTP configuré

Dashboard de corrélation VM SOC

⏱ ~30 min

Ajouter un panel "Kill Chain" au dashboard SOC

Ajouter un nouveau panel au dashboard SOC_Vue_Operationnelle du Jour 4, visualisant la progression des attaques par phase.

SPL — Panel Kill Chain progression

index=security earliest=-24h
  (sourcetype=suricata event_type=alert)
  OR (sourcetype=linux_secure "Failed password")
  OR (sourcetype=fail2ban "Ban")
| eval phase=case(
    sourcetype=="suricata",    "1 - Scan réseau",
    sourcetype=="linux_secure","2 - Tentatives SSH",
    sourcetype=="fail2ban",    "3 - Ban Fail2ban")
| stats count by phase
| sort phase

# Visualization : Bar Chart — "Progression Kill Chain (24h)"

🚨

Périmètre strictement limité au lab VMware

Ces attaques sont autorisées uniquement entre les VMs du réseau NAT VMware (192.168.91.0/24) qui vous appartiennent. Toute attaque hors de ce périmètre est illégale. Vérifier l'IP de la cible avant chaque commande.

Préparation de la VM Kali VM Kali

⏱ ~15 min

Vérifier la connectivité depuis Kali VM Kali

Terminal KaliVM KALI

# Vérifier l'IP Kali (doit être sur 192.168.91.x)
ip a | grep "192.168.91"

# Tester la connectivité vers les cibles
ping -c2 192.168.91.10  # VM SOC
ping -c2 192.168.91.20  # VM Cible Linux

# Vérifier les outils disponibles
which nmap && echo "nmap OK" || echo "nmap manquant — sudo apt install -y nmap"
which hydra && echo "hydra OK" || echo "hydra manquant — sudo apt install -y hydra"
which nikto && echo "nikto OK" || echo "nikto manquant — sudo apt install -y nikto"
which curl && echo "curl OK"

Les 4 scénarios d'attaque

⏱ ~90 min

Attaque 1 — Reconnaissance par scan de ports VM Kali

Simulation de la phase de reconnaissance d'un attaquant — identifier les ports ouverts et les services exposés. Devrait être détecté par Suricata.

Nmap — Scan SYN + détection de versionVM KALI

# Scan SYN rapide — déclenche la règle local.rules Suricata
nmap -sS -p 1-1000 192.168.91.20

# Scan avec détection de services — génère plus d'alertes
nmap -sV -p 22,80,443 192.168.91.20

# Vérification immédiate sur VM SOC :
# sudo tail -10 /var/log/suricata/fast.log

✅

Détection attendue dans Splunk

index=security sourcetype=suricata event_type=alert → signature SCAN nmap SYN scan detected + ET SCAN Possible Nmap User-Agent Observed avec src_ip = 192.168.91.40

Attaque 2 — Brute Force SSH avec Hydra VM Kali

Simulation d'une attaque par force brute sur le service SSH. Devrait déclencher des alertes dans linux_secure (tentatives) et Fail2ban (bannissement).

Hydra — Brute force SSHVM KALI

# Prérequis IMPORTANT — vérifier la config Fail2ban sur la VM cible
# Le fichier /etc/fail2ban/jail.local doit contenir :
#   [sshd]
#   enabled  = true
#   port     = ssh
#   logpath  = /var/log/auth.log
#   backend  = auto
#   maxretry = 3
#   ignoreip = 127.0.0.1 ::1 192.168.91.10   ← VM SOC en whitelist, pas le /24 !
# Après modification : sudo systemctl restart fail2ban

# Créer un mini-dictionnaire de mots de passe de test
cat << 'EOF' > /tmp/passwords_test.txt
password
123456
admin
root
toor
pass123
letmein
EOF

# Lancer le brute force SSH (utilisateur "dis" sur la VM cible)
# -t 1 = 1 thread séquentiel (important : Fail2ban détecte mieux les tentatives séquentielles)
# -w 3 = attendre 3 secondes entre chaque tentative
hydra -l dis -P /tmp/passwords_test.txt \
  -t 1 -w 3 -s 22 \
  ssh://192.168.91.20

# → Fail2ban bannira l'IP Kali après 3 échecs (maxretry=3)
# → Vérifier avec : sudo fail2ban-client status sshd (depuis VM cible)
# → Si "Ignore ... by ip" dans /var/log/fail2ban.log → l'IP est en whitelist, vérifier ignoreip

✅

Détection attendue dans Splunk

index=security sourcetype=linux_secure "Failed password" src_ip=192.168.91.40 + index=security sourcetype=fail2ban "Ban" 192.168.91.40 → l'alerte "Brute Force SSH Detecte" du Jour 4 doit se déclencher.

Attaque 3 — Scan de vulnérabilités web avec Nikto VM Kali

Nikto teste le serveur web à la recherche de fichiers sensibles, configurations dangereuses et CVEs connues. Les logs Apache sont collectés par Wazuh (qui surveille /var/log/apache2/access.log) et remontent dans Splunk en sourcetype=wazuh.

Nikto — Scan webVM KALI

# Scan Nikto sur le serveur Apache de la VM cible
nikto -h http://192.168.91.20 -maxtime 120

# Alternative manuelle si Nikto absent — simuler des requêtes suspectes
for path in /.env /admin /wp-login.php /phpmyadmin /.git/config \
            /etc/passwd /backup.sql /config.php; do
  curl -s -o /dev/null -w "%{http_code} $path\n" \
    http://192.168.91.20$path
done

✅

Détection attendue dans Splunk

index=security sourcetype=wazuh "192.168.91.130" location="/var/log/apache2/access.log" → des milliers de requêtes HTTP générées par Nikto remontent via Wazuh. La requête sourcetype=access_combined ne fonctionnera pas — les logs Apache passent par Wazuh dans cette architecture.

Attaque 4 — Modification de fichier sensible (FIM Wazuh) VM Cible

Pour cette attaque, on simule un attaquant qui a déjà obtenu un accès et modifie un fichier sensible. On l'exécute depuis la VM cible directement (simulation post-exploitation). Devrait déclencher Wazuh FIM.

Terminal — Simulation modification post-exploitationVM CIBLE

# Créer un faux fichier "backdoor" dans /etc (surveillé par Wazuh FIM)
sudo bash -c 'cat > /etc/soc_test_backdoor' << 'ENDOFFILE'
# Fichier de test SOC - simulation backdoor
ENDOFFILE

# Attendre 60-90 secondes que le scan FIM de Wazuh tourne
# Puis vérifier sur la VM SOC :
# sudo tail -50 /var/ossec/logs/alerts/alerts.log | grep -i "554\|added\|backdoor"

# Modifier le fichier (déclenche règle 553 - fichier modifié)
sudo echo "attacker_was_here" | sudo tee -a /etc/soc_test_backdoor

# Nettoyage après validation
# sudo rm /etc/soc_test_backdoor

✅

Détection attendue dans Splunk

index=security sourcetype=wazuh → règle 554 (fichier ajouté) puis 553 (fichier modifié) avec agent.name=vm-client. Si non visible, vérifier que la fréquence FIM est bien à 60s dans /var/ossec/etc/ossec.conf.

Attaque 5 — Énumération de services et bannières VM Kali

Un attaquant collecte les bannières des services pour identifier les versions logicielles et chercher des CVEs associées. Cette phase suit généralement le scan de ports.

💡

Indice — approche boîte noire

Vous cherchez à identifier les versions exactes des services SSH et HTTP exposés sur la VM cible. Quel outil Nmap permet de faire de la détection de version ? Quel outil dédié permet de récupérer la bannière HTTP et les headers de sécurité manquants ?

Indices de commandes — à compléterVM KALI

# Détection de version des services (flag Nmap à trouver)
nmap -________ -p 22,80 192.168.91.20

# Récupérer les headers HTTP et identifier les informations exposées
curl -________ http://192.168.91.20

# Vérifier si le serveur Apache expose sa version dans les headers
curl -s -I http://192.168.91.20 | grep -i "server\|x-powered"

✅

Détection attendue dans Splunk

index=security sourcetype=suricata event_type=alert → ET SCAN Possible Nmap User-Agent Observed pour la détection de version Nmap. index=security sourcetype=wazuh location="/var/log/apache2/access.log" → requêtes HEAD/GET depuis 192.168.91.130.

📌

À documenter dans le rapport client

Les informations exposées (version Apache, version SSH, OS fingerprint) permettent à un attaquant de cibler des CVEs spécifiques. C'est un risque de divulgation d'information — à inclure dans la fiche de remédiation avec la recommandation de masquer les bannières.

Attaque 6 — Tentatives d'accès à des ressources sensibles VM Kali

Simulation d'un attaquant qui tente d'accéder à des fichiers de configuration ou des interfaces d'administration courantes sur le serveur web. Génère du trafic caractéristique dans les logs Apache.

💡

Indice — approche boîte noire

Vous voulez tester si des chemins sensibles sont accessibles sur le serveur web : fichiers .env, .git, interfaces d'administration (/phpmyadmin, /admin), fichiers de backup. Quel outil permet de faire du "directory bruteforcing" ? Ou comment le faire manuellement avec curl ?

Approche manuelle — requêtes vers chemins sensiblesVM KALI

# Tester l'accès à des fichiers et répertoires sensibles courants
for path in /.env /.git/config /admin /phpmyadmin /backup.sql \
            /wp-login.php /config.php /.htaccess /server-status \
            /etc/passwd /proc/self/environ; do
  code=$(curl -s -o /dev/null -w "%{http_code}" http://192.168.91.20$path)
  echo "$code $path"
done

# Tester avec un User-Agent suspect (simuler un scanner automatique)
curl -s -A "sqlmap/1.0" http://192.168.91.20/
curl -s -A "Havij" http://192.168.91.20/

✅

Détection attendue dans Splunk

index=security sourcetype=wazuh location="/var/log/apache2/access.log" "192.168.91.130" → rafale de requêtes 404 depuis Kali. Les User-Agents suspects (sqlmap, Havij) peuvent déclencher des règles Suricata ET/open : index=security sourcetype=suricata event_type=alert.

Mesure du taux de couverture VM SOC

⏱ ~30 min

Calculer et documenter le taux de couverture final

Remplir ce tableau dans votre rapport. Pour chaque attaque, indiquer si elle a été détectée, par quel outil, et dans quel délai.

Attaque simulée	Outil attendu	Détecté ?	Délai	Alerte déclenchée ?
Scan Nmap SYN (depuis Kali)	Suricata	À remplir	À mesurer	Scan Reseau Detecte
Brute Force SSH Hydra (depuis Kali)	linux_secure + Fail2ban	À remplir	À mesurer	Brute Force SSH Detecte
Scan web Nikto (depuis Kali)	Wazuh (via Apache log)	À remplir	À mesurer	Aucune alerte spécifique — visible dans index=security sourcetype=wazuh
Modification FIM /etc (VM cible)	Wazuh	À remplir	À mesurer	Wazuh Alerte Critique
Énumération de services (Nmap -sV)	Suricata + Wazuh (Apache)	À remplir	À mesurer	ET SCAN Nmap User-Agent
Accès ressources sensibles (curl / dirbusting)	Wazuh (Apache) + Suricata	À remplir	À mesurer	Aucune alerte spécifique — visible dans Wazuh

SPL — Vérification globale post-attaquesVM SOC

# Vue consolidée de toutes les détections liées aux attaques Kali
# Adapter l'IP selon votre VM Kali : ip a | grep "192.168.91" depuis la VM Kali
index=security earliest=-2h
| eval src=coalesce(
    spath(_raw,"src_ip"),
    replace(_raw,".*from (\d+\.\d+\.\d+\.\d+).*","\1"),
    replace(_raw,".*clientip.*?(\d+\.\d+\.\d+\.\d+).*","\1"))
| where src="192.168.91.40" OR sourcetype="wazuh"
| stats count by sourcetype, src
| sort -count

# Taux de couverture = nb_attaques_detectees / nb_attaques_lancees × 100
# Objectif : 6/6 = 100% de couverture sur les vecteurs testés

🎭

Scénario client — Contexte de la mission

—

Briefing client — PME "LogiTrans SARL"

Votre client : LogiTrans SARL, PME de 45 employés dans la logistique. Aucune politique de sécurité formelle, pas de SOC, des serveurs Linux exposés en interne. Après une tentative d'intrusion détectée par hasard par un administrateur, ils vous mandatent pour :

Mettre en place une infrastructure de détection (fait aux Jours 1 à 4)
Simuler des attaques réalistes pour valider la détection
Rédiger un rapport de sécurité professionnel à destination de la direction
Proposer un plan de remédiation priorisé

⚠️

Approche "boîte noire" pour les attaques

Le TP ne vous dit pas quel outil utiliser ni comment — c'est à vous de choisir la bonne approche pour chaque scénario, comme un vrai pentest. Des indices sont fournis si vous bloquez, mais l'objectif est de trouver par vous-mêmes. Documenter chaque choix dans votre rapport.

📦

Les 4 livrables à remettre

Rapport client PDF

Document professionnel remis à la direction de LogiTrans. Rédigé comme si vous étiez un cabinet de conseil en cybersécurité. Structure imposée — voir Section A.

Format : PDF · 10-20 pages · Logos + mise en page soignée

Journal d'incidents

Rempli en temps réel pendant la Phase 3. Pour chaque attaque : horodatage, outil utilisé, gravité, impact estimé, première alerte Splunk. Document séparé du rapport.

Format : tableau PDF ou Google Sheets · à remplir pendant les attaques

Questionnaire d'évaluation

20 questions couvrant l'intégralité du cours — questions ouvertes, techniques, commandes à compléter, requêtes SPL à écrire et expliquer. Section B.

Format : réponses écrites dans le document fourni

Fiche de remédiation

Pour chaque vecteur d'attaque testé : actions correctives concrètes, priorité (P1/P2/P3), effort estimé, impact attendu. À destination du DSI de LogiTrans.

Format : tableau structuré inclus dans le rapport client ou document séparé

L1 — Structure du rapport client

—

Consignes de rédaction

📌

Ton et posture du rapport

Le rapport est rédigé à destination de la direction de LogiTrans — pas de jargon technique pur, vulgariser sans simplifier à l'excès. Chaque constat doit être accompagné d'une recommandation concrète. Les captures d'écran Splunk sont des preuves — les légender précisément.

Page de garde & résumé exécutif

1-2 pages

Nom du cabinet (votre binôme), date, nom du client (LogiTrans SARL), classification (CONFIDENTIEL)
Résumé exécutif en 10 lignes max : ce qui a été fait, ce qui a été trouvé, le niveau de risque global (Rouge/Orange/Vert), les 3 recommandations prioritaires
Tableau de synthèse : nb d'attaques simulées / nb détectées / taux de couverture global

Périmètre & architecture auditée

1-2 pages

Schéma de l'architecture des VMs avec les flux de données (qui envoie quoi où)
Inventaire des services surveillés et des outils déployés
Ce qui est dans le périmètre et ce qui en est exclu (ex: trafic HTTPS, Windows non supervisé)

Résultats des tests d'intrusion

4-6 pages

Pour chaque scénario d'attaque : description vulgarisée, capture Splunk de la détection, délai de détection mesuré, gravité CVSS estimée
Ce qu'un attaquant réel aurait pu faire ensuite (impact potentiel)
Ce que le SOC a vu vs ce qu'il n'a pas vu (angles morts identifiés)

Taux de couverture avant / après

1-2 pages

Tableau comparatif : situation avant déploiement du SOC (0% de détection) vs après
Graphique ou représentation visuelle du taux de couverture par vecteur
Analyse : quels vecteurs restent non couverts et pourquoi

Fiche de remédiation (L4)

2-3 pages

Tableau avec : Vecteur d'attaque · Risque · Action corrective · Priorité · Effort · Responsable recommandé
Minimum 1 action par attaque simulée + recommandations organisationnelles (processus, formation)
Roadmap suggérée : actions à 1 mois / 3 mois / 6 mois

Conformité & aspects légaux

1 page

RGPD : les logs collectés contiennent-ils des données personnelles (IPs, noms d'utilisateurs) ? Durée de rétention recommandée, base légale (intérêt légitime), obligation de notification CNIL en cas de violation
Durée de rétention des logs : recommandation légale France = 1 an minimum pour les logs de sécurité (LPM, directive NIS2)
Accès aux logs : qui peut consulter les logs ? Traçabilité des accès aux données de supervision
NIS2 : LogiTrans est-elle concernée ? (PME secteur logistique — à analyser)

L2 — Journal d'incidents

—

À remplir en temps réel pendant la Phase 3

Ce document est rempli au fil des attaques — une ligne par événement détecté. Il sert à reconstituer la chronologie de l'incident et à démontrer la réactivité du SOC.

Heure	Attaque simulée	Outil attaquant	Premier outil de détection	Délai détection	Gravité	Alerte Splunk déclenchée ?	Impact estimé si réel
__:__	Scan ports	À compléter	À compléter	__ sec	Faible	Oui / Non	Cartographie réseau exposée
__:__	Brute force SSH	À compléter	À compléter	__ sec	Élevée	Oui / Non	Accès root potentiel
__:__	Scan web	À compléter	À compléter	__ sec	Moyenne	Oui / Non	Exposition de fichiers sensibles
__:__	Modification FIM	À compléter	À compléter	__ sec	Critique	Oui / Non	Persistance attaquant
__:__	Énumération services	À compléter	À compléter	__ sec	Faible	Oui / Non	Versions logicielles exposées → CVEs ciblables
__:__	Accès ressources sensibles	À compléter	À compléter	__ sec	Moyenne	Oui / Non	Fichiers config / backup exposés

💡

Comment mesurer le délai de détection

Noter l'heure exacte de lancement de l'attaque. Puis dans Splunk, rechercher le premier événement lié à cette attaque et noter son _time. La différence est votre délai de détection — c'est votre MTTD (Mean Time To Detect) pour ce vecteur.

L3 — Questionnaire d'évaluation (20 questions)

—

Partie 1 — Architecture & Concepts (Questions 1 à 6)

Question ouverte

Expliquez en 5 à 10 lignes la différence entre un NIDS et un HIDS. Dans votre lab, quel outil joue chaque rôle ? Donnez un exemple concret d'attaque que l'un détecterait mais pas l'autre.

Question ouverte

Décrivez le flux complet d'un log depuis sa génération sur la VM cible jusqu'à son affichage dans Splunk. Citez chaque composant traversé et son rôle.

Question technique — Compléter la commande

Vous venez d'allumer la VM SOC. Complétez les commandes pour vérifier que tous les services sont opérationnels :


            sudo ________ status splunk

            curl -s http://localhost:________ | python3 -m json.tool | grep tagline

            sudo systemctl status ________

            sudo /var/ossec/bin/________ -l

Question ouverte

Pourquoi a-t-on utilisé le réseau NAT VMware (192.168.91.0/24) plutôt qu'un réseau bridgé pour ce lab ? Quelles seraient les implications sécurité si les VMs avaient été directement sur le réseau de l'école ?

Question technique — Compléter la commande

La VM cible n'envoie plus ses logs à Splunk depuis 30 minutes. Dans quel ordre vérifiez-vous les composants ? Complétez :


            # Étape 1 — vérifier que rsyslog tourne

            sudo systemctl status ________


            # Étape 2 — vérifier la connectivité vers le port Logstash

            nc -zv ________ 5514


            # Étape 3 — vérifier que le Splunk UF envoie bien

            sudo /opt/______/bin/splunk status

Question ouverte

Dans votre architecture, Fail2ban est configuré avec ignoreip = 127.0.0.1 ::1 192.168.91.10. Expliquez pourquoi on a retiré le 192.168.91.0/24 initial. Qu'est-ce qui se serait passé si on l'avait gardé pendant les tests d'intrusion ?

—

Partie 2 — Détection & Analyse SPL (Questions 7 à 13)

Question SPL — Écrire et expliquer

Écrivez une requête SPL qui affiche le top 5 des IPs sources ayant généré le plus d'alertes Suricata sur les dernières 24 heures, avec le nombre d'alertes et les signatures distinctes déclenchées. Expliquez chaque opérateur utilisé.

Question SPL — Analyser et corriger

La requête suivante est censée compter les bannissements Fail2ban par jour sur 7 jours, mais elle retourne 0 résultat. Identifiez et corrigez l'erreur :


            index=security sourcetype=fail2ban earliest=-7d

            | rex "BAN (?<ip>\d+\.\d+\.\d+\.\d+)"

            | timechart span=1d count by ip

Question SPL — Écrire et expliquer

Écrivez une requête SPL qui détecte les tentatives de connexion SSH réussies (pas les échecs) et affiche l'utilisateur, l'IP source et l'heure. Pourquoi ce type de détection est-il important dans un SOC ?

Question ouverte

Vous observez dans Splunk une rafale de 5 000 alertes Suricata en 2 minutes avec la signature "SCAN nmap SYN scan detected". Décrivez votre processus de triage : quelles questions posez-vous ? Quelles actions prenez-vous ? Quelle priorité assignez-vous ?

Question technique — Compléter la règle Suricata

Complétez cette règle Suricata pour détecter toute tentative de connexion sur le port 3306 (MySQL) depuis l'extérieur, avec un seuil de 3 tentatives en 10 secondes :


            alert ________ any any -> $HOME_NET ________ (

              msg:"________";

              flags:S;

              threshold:type threshold, track by_src, count ________, seconds ________;

              sid:9000002; rev:1;)

Question SPL — Écrire et expliquer

Écrivez la requête SPL de l'alerte "Attaque Multi-Etapes Detectee" que vous avez configurée au Jour 5. Expliquez pourquoi on utilise dc(sourcetype) >= 2 plutôt que count > 10 pour détecter une attaque multi-étapes.

Question ouverte

Quelle est la différence entre une alerte Splunk et un rapport planifié ? Donnez un exemple concret de quand utiliser l'un plutôt que l'autre dans le contexte de LogiTrans.

—

Partie 3 — Sécurité opérationnelle & Réflexion (Questions 14 à 20)

Question ouverte

Votre SOC génère en moyenne 500 alertes par jour. Proposez une stratégie concrète pour qu'un analyste L1 puisse traiter efficacement cette charge sans passer à côté d'une vraie menace. Mentionnez au moins 3 mécanismes techniques ou organisationnels.

Question technique — Compléter la commande

Un administrateur vous signale que Wazuh ne détecte plus les modifications de fichiers sur la VM cible. Complétez les commandes de diagnostic :


            # Vérifier l'état de l'agent sur la VM cible

            sudo /var/ossec/bin/________ status


            # Vérifier la fréquence du scan FIM

            grep "________" /var/ossec/etc/ossec.conf


            # Vérifier que /etc est bien dans les répertoires surveillés

            grep -A2 "________" /var/ossec/etc/ossec.conf | head -10


            # Forcer un scan FIM immédiat depuis le Manager

            sudo /var/ossec/bin/agent_control ________ -u 001

Question ouverte — RGPD & Légal

Les logs SSH collectés dans votre SOC contiennent les noms d'utilisateurs et adresses IP des employés de LogiTrans. Au regard du RGPD, quelles obligations s'appliquent à LogiTrans pour ces données ? Quelle durée de rétention recommandez-vous et pourquoi ?

Question ouverte

Hydra a été bloqué par Fail2ban après 3 tentatives SSH échouées. Un attaquant réel contournerait-il facilement ce mécanisme ? Décrivez deux techniques d'attaque que Fail2ban ne détecterait pas dans votre configuration actuelle.

Question SPL — Écrire et expliquer

LogiTrans vous demande un rapport mensuel automatique montrant l'évolution du nombre d'incidents par semaine sur le dernier mois, ventilé par outil de détection. Écrivez la requête SPL et expliquez comment planifier ce rapport dans Splunk.

Question ouverte

Votre taux de couverture est de X% sur les vecteurs testés. Est-ce que ce chiffre est représentatif de la sécurité réelle de LogiTrans ? Identifiez au moins 3 vecteurs d'attaque que votre SOC ne couvre pas et expliquez comment les couvrir.

Question ouverte — Synthèse

En tant que consultant SOC, quelle est votre recommandation principale à la direction de LogiTrans ? Justifiez votre réponse en vous appuyant sur les résultats concrets obtenus pendant le projet. Proposez une roadmap de sécurité sur 6 mois avec des jalons mesurables.

L4 — Fiche de remédiation

—

Actions correctives par vecteur d'attaque

À compléter pour chaque attaque simulée. Les colonnes "Action corrective" et "Effort" sont à rédiger par le binôme.

Vecteur	Risque	Action corrective recommandée	Priorité	Effort	Délai
Scan de ports (Nmap)	Moyen	À compléter — piste : firewall, port knocking, fail2ban sur scan...	P3	À estimer	1 mois
Brute Force SSH	Élevé	À compléter — piste : clés SSH, désactiver auth par mot de passe, port non standard...	P1	À estimer	1 semaine
Scan web (Nikto)	Moyen	À compléter — piste : WAF, headers sécurité, retirer pages admin exposées...	P2	À estimer	1 mois
Modification FIM /etc	Critique	À compléter — piste : moindre privilège, sudo logging, alertes FIM temps réel...	P1	À estimer	Immédiat
Organisationnel	Moyen	À compléter — processus d'escalade, astreinte, formation équipe...	P2	À estimer	3 mois

🔧 Mise en œuvre technique

40 points

Qualité du déploiement et de la configuration de l'infrastructure SOC.

Infrastructure complète et fonctionnelle (tous les services actifs) — 10 pts
Données remontant correctement dans Splunk (tous les sourcetypes) — 10 pts
Alertes configurées et déclenchables — 10 pts
Dashboard SOC opérationnel et lisible — 10 pts

⚔️ Validation par les attaques

25 points

Chaque attaque simulée et détectée avec preuve (screenshot).

Attaque 1 détectée — Scan Nmap → Suricata — 5 pts
Attaque 2 détectée — Brute Force SSH → Fail2ban — 5 pts
Attaque 3 détectée — Scan web Nikto → Wazuh (sourcetype=wazuh) — 5 pts
Attaque 4 détectée — FIM → Wazuh — 5 pts
Alerte de corrélation multi-outils déclenchée — 5 pts

📄 Rapport écrit

20 points

Qualité et pertinence du rapport de synthèse.

Structure claire et complète (toutes les sections) — 5 pts
Analyse du taux de couverture avant/après — 8 pts
Réflexion sur les alertes, la visualisation, les limites — 4 pts
Recommandations pertinentes et réalistes — 3 pts

🎤 Soutenance orale

15 points

Clarté de la présentation et maîtrise technique démontrée.

Clarté et structure de la présentation — 5 pts
Démonstration technique convaincante — 5 pts
Réponses aux questions de l'enseignant — 5 pts

📌

Total : 100 points — les deux membres du binôme sont évalués conjointement

L'évaluation porte sur le travail collectif, pas individuel. Chaque membre doit néanmoins être capable de répondre à des questions techniques sur l'ensemble du projet lors de la soutenance.

✅ Checklist finale avant de remettre

✓
Snapshot "Jour5_Depart" réalisé en début de journée
✓
Tous les services vérifient OK dans Splunk (index=security | stats count by sourcetype)
✓
Alerte de corrélation "Attaque Multi-Etapes Detectee" configurée et activée
✓
Attaque 1 (Nmap) lancée et détectée — screenshot Splunk réalisé
✓
Attaque 2 (Hydra SSH) lancée et détectée — screenshot Splunk réalisé
✓
Attaque 3 (Nikto web) lancée et détectée — screenshot Splunk réalisé
✓
Attaque 4 (FIM Wazuh) lancée et détectée — screenshot Splunk réalisé
✓
Tableau de couverture avant/après rempli avec les vrais chiffres
✓
Rapport PDF finalisé (10-20 pages, toutes les sections présentes)
✓
Rapport remis à l'enseignant avant la soutenance
✓
Démonstration live préparée et testée (nmap → Splunk, 60s max)
✓
Snapshot "Jour5_Final" réalisé sur toutes les VMs

🏁

Félicitations — vous avez déployé un SOC complet !

En 5 jours vous avez mis en place une stack de détection professionnelle : centralisation rsyslog/Logstash/Elasticsearch, SIEM Splunk, NIDS Suricata, HIDS Wazuh, prévention Fail2ban, dashboards KPI, alertes automatiques et rapports périodiques. C'est exactement ce qu'on attend d'un ingénieur SOC en entreprise.

Projet Intégrateur — Architecture SOC Complète

📋 Description du projet

Contexte : vous êtes l'équipe SOC d'une entreprise

🗺️ Les 5 phases du projet

🏗️ Architecture cible du projet

📦 Livrables à remettre

Rapport écrit (PDF)

Soutenance orale (10 min)

Screenshots des alertes déclenchées

Tableau de couverture

Vérification & Consolidation de l'Infrastructure

Vérification systématique de tous les services Toutes les VMs

Checklist de démarrage — VM SOC VM SOC

Checklist de démarrage — VM Cible VM Cible

Vérification des données dans Splunk VM SOC

Mesure de l'état "avant attaque" VM SOC

Mesurer le taux de couverture initial VM SOC

Corrélation d'Événements Complexes

Règle de corrélation multi-outils VM SOC

Construire la requête de corrélation Suricata + SSH + Fail2ban

Alerte de corrélation — Attaque multi-étapes détectée

Dashboard de corrélation VM SOC

Ajouter un panel "Kill Chain" au dashboard SOC

Validation par Attaques Simulées

Préparation de la VM Kali VM Kali

Vérifier la connectivité depuis Kali VM Kali

Les 4 scénarios d'attaque

Attaque 1 — Reconnaissance par scan de ports VM Kali

Attaque 2 — Brute Force SSH avec Hydra VM Kali

Attaque 3 — Scan de vulnérabilités web avec Nikto VM Kali

Attaque 4 — Modification de fichier sensible (FIM Wazuh) VM Cible

Attaque 5 — Énumération de services et bannières VM Kali

Attaque 6 — Tentatives d'accès à des ressources sensibles VM Kali

Mesure du taux de couverture VM SOC

Calculer et documenter le taux de couverture final

Étude de Cas & Livrables Clients

Scénario client — Contexte de la mission

Briefing client — PME "LogiTrans SARL"

Les 4 livrables à remettre

Rapport client PDF

Journal d'incidents

Questionnaire d'évaluation

Fiche de remédiation

L1 — Structure du rapport client

Consignes de rédaction

L2 — Journal d'incidents

À remplir en temps réel pendant la Phase 3

L3 — Questionnaire d'évaluation (20 questions)

Partie 1 — Architecture & Concepts (Questions 1 à 6)

Partie 2 — Détection & Analyse SPL (Questions 7 à 13)

Partie 3 — Sécurité opérationnelle & Réflexion (Questions 14 à 20)

L4 — Fiche de remédiation

Actions correctives par vecteur d'attaque

Grille d'Évaluation