📌
Journée 100% Splunk — VM SOC uniquement

Toutes les actions du Jour 4 se font dans l'interface web Splunk (http://[IP_SOC]:8000) ou en ligne de commande sur la VM SOC. La VM cible peut rester démarrée pour générer du trafic en arrière-plan, mais aucune configuration ne lui est nécessaire.

🎯 Objectifs pédagogiques

  • Définir et mesurer des KPIs de sécurité pertinents
  • Construire des dashboards Splunk avec panels SPL
  • Configurer des alertes déclenchées par des seuils SPL
  • Mettre en place une notification email sur alerte
  • Générer un rapport périodique automatisé (PDF/CSV)
  • Comprendre la prise de décision basée sur les données

⚠️ Prérequis — État des Jours 1 à 3

  • Splunk accessible sur http://[IP_SOC]:8000
  • Index security contenant des données réelles
  • Sourcetypes présents : linux_secure, suricata, fail2ban, wazuh
  • Les rapports du Jour 2 (TP2_Attaques_SSH_Timeline) et Jour 3 (TP3_Detection_360) sauvegardés

📦 Livrables fin de journée

  • Dashboard "SOC_Vue_Operationnelle" avec 4 panels minimum
  • Alerte "Brute Force SSH Detecte" configurée et testée
  • Alerte "Suricata Scan Detecte" configurée
  • Rapport planifié hebdomadaire généré en PDF ou CSV
  • Screenshot de chaque livrable
  • Snapshot "Jour4_OK"

⚠️ Points d'attention

  • Les alertes email nécessitent un serveur SMTP — voir la section de configuration SMTP dédiée au début du TP 2
  • Splunk Free Licence limite les alertes — vérifier avec Settings → Licensing
  • Ne pas confondre "Alert" (déclenché par une condition SPL) et "Report" (planifié périodiquement)
  • Tester les alertes avec des données réelles — générer du trafic depuis la VM cible si besoin

📊 KPIs de sécurité — Les métriques clés du SOC

MTTD
Mean Time To Detect — délai moyen entre une attaque et sa première détection
index=security | timechart...
Volume d'alertes / h
Nombre d'alertes générées par heure — indicateur de charge de l'analyste L1
| stats count by date_hour
Taux de ban Fail2ban
IPs bannies / tentatives détectées — efficacité de la première ligne de défense
sourcetype=fail2ban "Ban"
Top IPs suspectes
IPs sources générant le plus d'alertes Suricata ou SSH — radar des scanners
| stats count by src_ip
Alertes Wazuh critiques
Alertes de niveau ≥ 7 — modifications FIM, escalades de privilèges
sourcetype=wazuh level>=7
Couverture réseau
Nombre de hosts supervisés vs hosts actifs sur le réseau NAT
| stats dc(host)

🗓️ Planning de la journée

HoraireActivitéVM(s)Durée
09h00 – 09h30Cours — KPIs dans un SI, importance des métriques pour la prise de décision30 min
09h30 – 10h00Cours — Niveaux d'alertes (P1/P2/P3), processus d'escalade, rôles L1/L2/L330 min
10h00 – 10h15Pause15 min
10h15 – 13h00TP 1 — Construction des dashboards de sécuritéSOC2h45
13h00 – 14h00Pause déjeuner1h
14h00 – 16h00TP 2 — Mise en place des alertes de sécuritéSOC2h
16h00 – 17h30TP 3 — Génération de rapports automatisésSOC1h30
17h30 – 18h00Validation + débrief + snapshot30 min
A

Générer des données fraîches pour les dashboards Les deux VMs

⏱ ~15 min
1

Alimenter les index avec du trafic réel avant de construire VM Cible

Les dashboards sont plus parlants avec des données récentes. Générer quelques événements de test depuis la VM cible.

Terminal — générer du trafic de testVM CIBLE
# Tentatives SSH échouées (alimente linux_secure et fail2ban)
for i in {1..8}; do
  ssh -o ConnectTimeout=2 -o StrictHostKeyChecking=no \
    scantest@192.168.91.10 2>/dev/null || true
  sleep 1
done

# Trafic Apache (alimente access_combined)
for i in {1..15}; do curl -s http://localhost > /dev/null; done
curl -s http://localhost/.env > /dev/null
curl -s http://localhost/admin > /dev/null
curl -s http://localhost/wp-login.php > /dev/null

# Scan Nmap vers la VM SOC (alimente suricata)
nmap -sS -p 1-500 192.168.91.10
💡
Attendre 2 à 3 minutes

Les Forwarders ont un délai d'envoi de quelques secondes à 1 minute. Vérifier dans Splunk : index=security | head 5 — le champ _time des derniers événements doit être récent.

B

Créer le dashboard principal VM SOC

⏱ ~30 min
2

Créer un nouveau dashboard vide VM SOC

Dashboards Create New Dashboard
Interface Splunk — Création du dashboardVM SOC
Dashboard Title : SOC_Vue_Operationnelle
Dashboard ID    : soc_vue_operationnelle  (auto-rempli)
Description     : Vue temps réel — Alertes Suricata, SSH, Fail2ban, Wazuh
Shared in App   : Search (ou All Apps)

→ Create Dashboard (Classic Dashboards)
📌
Classic vs Studio

Choisir Classic Dashboards — c'est le mode standard basé sur XML et SPL, plus stable et plus pédagogique. Dashboard Studio (nouveau) utilise un éditeur visuel mais est moins stable sur les versions récentes.

C

Ajouter les panels SPL un par un

⏱ ~90 min
3

Panel 1 — Volume d'alertes par outil (Line Chart) VM SOC

Ce panel montre l'évolution temporelle du nombre d'alertes par outil de détection. C'est la vue principale d'un analyste L1 en début de journée.

Edit Dashboard Add Panel New Line Chart
SPL — Panel 1 : Timeline des alertes par outil
index=security
  (sourcetype=suricata event_type=alert)
  OR (sourcetype=linux_secure "Failed password")
  OR (sourcetype=fail2ban "Ban")
  OR (sourcetype=wazuh)
| eval outil=case(
    sourcetype=="suricata",    "Suricata",
    sourcetype=="linux_secure","SSH Echecs",
    sourcetype=="fail2ban",    "Fail2ban",
    sourcetype=="wazuh",       "Wazuh")
| timechart span=15m count by outil

# Title: "Alertes par outil — 24h"
# Time range: Last 24 hours
4

Panel 2 — Top 10 IPs suspectes (Bar Chart) VM SOC

Identifie les IPs sources qui génèrent le plus d'alertes réseau — les "top scanners" visibles depuis Suricata.

SPL — Panel 2 : Top IPs sources Suricata
index=security sourcetype=suricata event_type=alert
| spath output=src_ip path=src_ip
| spath output=signature path=alert.signature
| where isnotnull(src_ip) AND src_ip!="127.0.0.1"
| stats count as nb_alertes by src_ip
| sort -nb_alertes
| head 10

# Title: "Top 10 IPs suspectes (Suricata)"
# Visualization: Bar Chart (nb_alertes en Y, src_ip en X)
5

Panel 3 — Alertes Wazuh critiques (Table) VM SOC

Liste les alertes Wazuh de niveau ≥ 7 (critiques) avec leur agent source et leur description. C'est la table de triage de l'analyste L1.

SPL — Panel 3 : Alertes Wazuh critiques
index=security sourcetype=wazuh
| spath output=level path=rule.level
| spath output=description path=rule.description
| spath output=agent path=agent.name
| where level >= 7
| eval criticite=case(level>=12,"CRITIQUE",level>=9,"HAUTE",level>=7,"MOYENNE")
| table _time, criticite, level, agent, description
| sort -level, -_time

# Title: "Alertes Wazuh — Niveau ≥ 7"
# Visualization: Table
# Time range: Last 24 hours
6

Panel 4 — Bannissements Fail2ban (Single Value + Sparkline) VM SOC

Affiche le nombre total d'IPs bannies aujourd'hui avec une mini-courbe d'évolution. C'est un KPI de synthèse idéal pour un écran de supervision.

SPL — Panel 4 : Compteur de bannissements
index=security sourcetype=fail2ban "Ban"
| rex "NOTICE \[(?<jail>\w+)\] Ban (?<banned_ip>\d+\.\d+\.\d+\.\d+)"
| where isnotnull(banned_ip)
| stats count as total_bans, dc(banned_ip) as ips_distinctes

# Title: "IPs bannies — Aujourd'hui"
# Visualization: Single Value
# Time range: Today
7

Panel 5 (bonus) — Répartition par sourcetype (Pie Chart) VM SOC

SPL — Panel 5 : Répartition des événements
index=security
| stats count by sourcetype
| sort -count

# Title: "Répartition des événements par source"
# Visualization: Pie Chart
# Time range: Last 7 days
Sauvegarder le dashboard

Cliquer sur Save en haut à droite. Le dashboard est maintenant accessible depuis Dashboards → SOC_Vue_Operationnelle. Il se rafraîchit automatiquement selon la plage de temps sélectionnée.

D

Configurer le rafraîchissement automatique

⏱ ~15 min
8

Ajouter un auto-refresh pour la supervision en temps réel VM SOC

En mode supervision, le dashboard doit se mettre à jour automatiquement. Cela se configure dans le XML du dashboard.

Edit Dashboard Edit Source (XML)
XML Dashboard — Ajouter refreshVM SOC
<!-- Trouver la balise <dashboard> en haut du XML et modifier ainsi -->
<dashboard version="1.1" theme="dark" refresh="60">

<!-- refresh="60" = rafraîchissement automatique toutes les 60 secondes -->
<!-- ⚠️ Ne pas ajouter refreshType="delay" — non reconnu par Splunk Enterprise 9.x -->
⚠️
Erreur courante — attribut refreshType inconnu

L'attribut refreshType="delay" n'est pas reconnu par toutes les versions de Splunk Enterprise et génère l'erreur "Unknown attribute refreshType for node dashboard". Il faut utiliser uniquement refresh="60" — c'est suffisant pour le rafraîchissement automatique.

📌
Anatomie d'une alerte Splunk

Recherche SPL → exécutée périodiquement (ex: toutes les 5 min) → si condition remplie (ex: count > 5) → action déclenchée (email, log, webhook) → throttle pour éviter le spam (ex: 1 fois par heure max par IP source)

📧

Configuration du serveur SMTP (email) VM SOC

⏱ ~10 min
0

Configurer Splunk pour envoyer des emails VM SOC

Sans SMTP configuré, l'action email dans les alertes et rapports est grisée. Cette étape est facultative pour le TP mais requise en production. Si vous n'avez pas de serveur SMTP disponible, passez directement à la Section A — les alertes fonctionnent sans email.

Paramètres Paramètres du serveur Paramètres de messagerie
Champs à renseigner dans SplunkVM SOC
Serveur de messagerie (SMTP) : [hôte SMTP de votre fournisseur]
Port                         : 587  (TLS/STARTTLS) ou 465 (SSL)
Sécurité de connexion        : TLS
Nom d'utilisateur            : [votre identifiant email]
Mot de passe                 : [mot de passe ou token d'application]
Adresse d'envoi              : [votre adresse email]
FournisseurServeur SMTPPortAuthentification
Gmailsmtp.gmail.com587Mot de passe d'application (pas le mot de passe habituel)
Microsoft 365smtp.office365.com587Identifiant + mot de passe du compte
Outlook.comsmtp-mail.outlook.com587Identifiant + mot de passe du compte
SMTP entrepriseDemander à l'administrateur25 ou 587Selon config interne (relay autorisé ou auth)
Serveur locallocalhost ou 127.0.0.125Souvent sans auth (relay local)
⚠️
Gmail et Microsoft 365 — mot de passe d'application requis

Ces fournisseurs bloquent les connexions SMTP avec le mot de passe de compte normal si l'authentification multifacteur est activée. Il faut générer un mot de passe d'application (ou token d'application) dans les paramètres de sécurité du compte.
Pour Gmail : myaccount.google.com → Sécurité → Mots de passe des applications
Pour M365 : portal.azure.com → Entra ID → Authentification → Mots de passe d'application

Tester la configuration SMTP depuis SplunkVM SOC
# Dans Splunk : Paramètres → Paramètres du serveur → Paramètres de messagerie
# → Remplir les champs → cliquer "Envoyer un e-mail de test"
# → Vérifier la réception dans votre boîte mail

# Test alternatif depuis la ligne de commande de la VM SOC :
curl -s --ssl-reqd \
  --mail-from "expediteur@domaine.com" \
  --mail-rcpt "destinataire@domaine.com" \
  --url "smtps://[VOTRE_SERVEUR_SMTP]:587" \
  --user "identifiant@domaine.com:MOT_DE_PASSE" \
  -T /dev/null \
  && echo "SMTP OK" || echo "SMTP ERREUR"
Pas de SMTP ? — pas de problème pour le TP

Les alertes s'enregistrent dans Activité → Alertes déclenchées et les rapports sont consultables dans Splunk, même sans email. L'email est une fonctionnalité additionnelle de notification — elle ne conditionne pas le fonctionnement du SOC.

A

Alerte 1 — Brute Force SSH Détecté VM SOC

⏱ ~40 min
1

Créer l'alerte Brute Force SSH VM SOC

Cette alerte se déclenche dès qu'une IP source génère plus de 5 tentatives SSH échouées en 5 minutes — seuil bas pour le TP, à ajuster en production selon le contexte.

Search & Reporting Exécuter la recherche ci-dessous Save As Alert
SPL — Recherche de base de l'alerte
index=security sourcetype=linux_secure "Failed password"
| rex "from (?<src_ip>\d+\.\d+\.\d+\.\d+)"
| where isnotnull(src_ip)
| stats count as nb_echecs by src_ip
| where nb_echecs >= 5
Configuration de l'alerte dans SplunkVM SOC
Alert name    : Brute Force SSH Detecte
Description   : Une IP a généré 5+ tentatives SSH échouées en 5 minutes
Alert type    : Scheduled
Schedule      : Run every 5 minutes   (Cron : */5 * * * *)
Time range    : Last 5 minutes

Trigger condition : Number of Results > 0
                    (la recherche retourne des lignes seulement si nb_echecs >= 5)

Déclencher    : "Pour chaque résultat" (pas "Une fois")
               → Ce choix fait apparaître le champ de throttle par valeur

Throttle      : ✅ Supprimer les déclenchements pendant  60  minutes
                Supprimer les résultats contenant la valeur de champ : src_ip
                (Dans l'interface Splunk FR : "Supprimer les résultats contenant la valeur de champ")
                (évite le spam — 1 alerte max par IP par heure)
💡
Pourquoi "Number of Results > 0" ?

La requête SPL filtre elle-même avec where nb_echecs >= 5. Si elle retourne 0 lignes, aucune IP ne dépasse le seuil — pas d'alerte. Si elle retourne 1+ lignes, au moins une IP est suspecte — alerte déclenchée. C'est plus flexible que le seuil natif Splunk car on contrôle tout en SPL.

2

Configurer l'action de l'alerte — Log & email VM SOC

Chaque alerte peut déclencher plusieurs actions simultanément. L'action log est obligatoire (Splunk refuse de sauvegarder sans elle), l'email est optionnel.

Actions de l'alerte — section "+ Ajouter des actions"VM SOC
# Action OBLIGATOIRE — Splunk refuse de sauvegarder sans au moins une action
Ajouter aux alertes déclenchées
  → Mode: Pour chaque résultat   (= Per-Result)
  → Gravité: Élevée              (= High — brute force SSH = menace sérieuse)

# Action OPTIONNELLE — nécessite SMTP configuré (voir section dédiée ci-dessous)
Envoyer un e-mail
  → À: votre@email.com
  → Objet: [SOC ALERTE] Brute Force SSH détecté — $result.src_ip$
  → Message: IP $result.src_ip$ a effectué $result.nb_echecs$ tentatives SSH
📌
Splunk oblige à avoir au moins une action

Si vous cliquez Enregistrer sans avoir ajouté d'action, Splunk affiche "Activer au moins une action". L'action minimale est Ajouter aux alertes déclenchées — elle enregistre dans Activité → Alertes déclenchées sans email. Suffisant pour valider le TP.

3

Tester l'alerte en conditions réelles Les deux VMs

Terminal — générer les tentatives SSHVM CIBLE
# Générer 8 tentatives SSH échouées (dépasse le seuil de 5)
for i in {1..8}; do
  ssh -o ConnectTimeout=2 -o StrictHostKeyChecking=no \
    alertetest@192.168.91.10 2>/dev/null || true
  sleep 0.5
done
echo "8 tentatives envoyées — attendre 5 min max pour l'alerte"
Interface Splunk — vérifier le déclenchementVM SOC
Activity → Triggered Alerts
# → Doit afficher "Brute Force SSH Detecte" avec l'heure du déclenchement

# Ou forcer l'exécution immédiate :
# Alerts → "Brute Force SSH Detecte" → Run Now (icône ▶)
Résultat attendu

L'alerte apparaît dans Activity → Triggered Alerts avec le statut "Fired". Si email configuré, un mail est reçu avec l'IP source et le nombre de tentatives.

B

Alerte 2 — Scan Réseau Détecté (Suricata) VM SOC

⏱ ~30 min
4

Créer l'alerte Scan Réseau VM SOC

SPL — Alerte scan réseau Suricata
index=security sourcetype=suricata event_type=alert
| spath output=signature path=alert.signature
| spath output=src_ip path=src_ip
| where match(signature, "SCAN|scan|nmap|Nmap")
| stats count as nb_alertes, values(signature) as signatures by src_ip
| where nb_alertes >= 3
Configuration SplunkVM SOC
Alert name    : Scan Reseau Detecte
Schedule      : Every 5 minutes — Last 5 minutes
Trigger       : Number of Results > 0
Throttle      : 30 minutes, group by : src_ip
Action        : Add to Triggered Alerts (severity: Medium)
C

Alerte 3 — Alerte Wazuh Critique VM SOC

⏱ ~20 min
5

Créer l'alerte sur alertes Wazuh niveau élevé VM SOC

SPL — Alerte Wazuh critique
index=security sourcetype=wazuh
| spath output=level path=rule.level
| spath output=description path=rule.description
| spath output=agent path=agent.name
| where level >= 9
| table _time, agent, level, description
Configuration SplunkVM SOC
Alert name    : Wazuh Alerte Critique
Schedule      : Every 5 minutes — Last 5 minutes
Trigger       : Number of Results > 0
Throttle      : 60 minutes, group by : agent
Action        : Add to Triggered Alerts (severity: Critical)
💡
Tableau de bord des alertes déclenchées

Toutes les alertes déclenchées sont visibles dans Activity → Triggered Alerts. C'est l'équivalent d'une file d'incidents pour l'analyste L1 — chaque entrée représente un événement à qualifier et traiter.

D

Organisation des niveaux d'alertes et prise de décision

⏱ ~15 min
6

Matrice de priorité des alertes SOC — réflexion collective

En SOC réel, chaque alerte est qualifiée selon deux axes : probabilité que ce soit une vraie attaque et impact potentiel sur le SI.

PrioritéAlerteSplunk SeverityDélai de réponse attenduAction L1
P1 — CritiqueWazuh niveau ≥ 12 / rootkitCritical< 15 minIsolation immédiate + escalade L2
P2 — HauteBrute force SSH réussi / FIM fichier critiqueHigh< 1hVérification + blocage IP + ticket
P3 — MoyenneScan réseau / Fail2ban ban / SSH échouéMedium< 4hLog + surveillance renforcée
P4 — BasseTrafic Apache 404 / alertes Suricata informativesLowRapport quotidienAgrégation dans rapport périodique
💬
Question de réflexion

Avec les 3 alertes configurées aujourd'hui, quelle priorité (P1/P2/P3/P4) assigneriez-vous à chacune ? Un scan Nmap de votre VM SOC par votre propre VM cible est-il une vraie menace dans ce contexte ? Que se passerait-il si le scan venait d'une IP externe inconnue ?

📌
Alerte vs Rapport — la différence fondamentale

Alerte : réactive — se déclenche quand une condition anormale est détectée. Destinée aux analystes L1 pour action immédiate.
Rapport : proactif — s'exécute périodiquement quel que soit l'état du SI. Destiné au management et RSSI pour vision stratégique.

A

Construire le rapport hebdomadaire SOC VM SOC

⏱ ~45 min
1

Rapport 1 — Synthèse hebdomadaire des incidents VM SOC

Ce rapport agrège tous les événements de sécurité de la semaine écoulée, ventilés par outil et par criticité. Il est envoyé chaque lundi matin au RSSI.

SPL — Rapport synthèse hebdomadaire
index=security earliest=-7d latest=now
| eval outil=case(
    sourcetype=="suricata" AND event_type="alert", "Suricata (NIDS)",
    sourcetype=="linux_secure" AND match(_raw,"Failed password"), "SSH Echecs",
    sourcetype=="fail2ban" AND match(_raw,"Ban"), "Fail2ban Bans",
    sourcetype=="wazuh", "Wazuh (HIDS)",
    true(), "Autre")
| where outil!="Autre"
| stats
    count as total_evenements,
    dc(host) as nb_hotes_impliques
    by outil
| sort -total_evenements
| addcoltotals total_evenements label="TOTAL"
Save As Report Rapport_SOC_Hebdomadaire
2

Rapport 2 — Top menaces de la semaine VM SOC

SPL — Top IPs et signatures Suricata 7 jours
index=security sourcetype=suricata event_type=alert earliest=-7d
| spath output=src_ip path=src_ip
| spath output=signature path=alert.signature
| spath output=severity path=alert.severity
| stats
    count as nb_alertes,
    dc(signature) as signatures_distinctes
    by src_ip
| sort -nb_alertes
| head 10
| rename src_ip as "IP Source",
         nb_alertes as "Nb Alertes",
         signatures_distinctes as "Signatures distinctes"
Save As Report Rapport_Top_Menaces_Semaine
B

Planifier et exporter les rapports VM SOC

⏱ ~30 min
3

Configurer la planification et l'export PDF VM SOC

Reports Rapport_SOC_Hebdomadaire Edit Schedule
Configuration de la planificationVM SOC
Schedule Report : ✅ Schedule Report

Run on cron schedule : 0 8 * * 1
# → Chaque lundi à 08h00
# Décomposition : 0=minute 8=heure *=jour *=mois 1=lundi

Time Range : Last 7 days

# Remplir les champs de la planification :
Planifier le rapport : ✅ Planifier le rapport

Cron schedule : 0 8 * * 1
# → Chaque lundi à 08h00

Plage de temps : 7 derniers jours

# Section "Envoyer un e-mail" (si SMTP configuré) :
À       : rssi@entreprise.com, soc-team@entreprise.com
Objet   : [SOC] Rapport hebdomadaire de sécurité
Inclure :
  ✅ Joindre PDF          (= Format PDF — la case à cocher, pas un menu séparé)
  ✅ Lier à Rapport
  ✅ Lien vers les résultats

→ Enregistrer
⚠️
Il n'y a pas de menu "Format : PDF" — c'est une case à cocher

Dans Splunk, le format PDF s'active en cochant Joindre PDF dans la section "Inclure" — il n'y a pas de champ "Format" séparé. Si vous cherchez un menu "Format", vous ne le trouverez pas.

💡
Tester le rapport sans attendre lundi

L'icône "Envoyer" sur le rapport n'apparaît que si SMTP est configuré. Sans SMTP, utiliser Ouvrir dans la recherche pour vérifier que la requête retourne des données — c'est la validation suffisante pour le TP. L'envoi email sera automatique à la prochaine exécution planifiée une fois SMTP configuré.

4

Exporter un rapport en PDF manuellement VM SOC

Pour générer un PDF immédiatement sans attendre la planification, Splunk propose un export direct depuis la recherche ou depuis le rapport.

Reports Rapport_SOC_Hebdomadaire Open in Search Export (⬇) Export as PDF
Livrable attendu

Un fichier PDF nommé Rapport_SOC_Hebdomadaire.pdf contenant le tableau de synthèse avec les colonnes Outil / Nb Événements / Nb Hôtes impliqués. Ce PDF est le livrable que vous présenteriez au RSSI.

C

Rapport CSV pour analyse dans Excel VM SOC

⏱ ~15 min
5

Exporter les données brutes en CSV VM SOC

Le CSV est utile pour une analyse complémentaire dans Excel ou pour alimenter un outil de reporting externe (PowerBI, Tableau). On exporte les 7 derniers jours d'alertes triées.

SPL — Export CSV complet des alertes 7 jours
index=security earliest=-7d latest=now
| eval
    date=strftime(_time,"%Y-%m-%d %H:%M"),
    outil=case(
        sourcetype=="suricata","Suricata",
        sourcetype=="linux_secure","SSH",
        sourcetype=="fail2ban","Fail2ban",
        sourcetype=="wazuh","Wazuh",
        true(),"Autre")
| table date, outil, sourcetype, host, _raw
| rename
    date as "Date/Heure",
    outil as "Outil",
    sourcetype as "Type",
    host as "Hôte",
    _raw as "Événement brut"
| sort -"Date/Heure"
Export (⬇) Export as CSV Filename: alertes_soc_7jours.csv
💡
Automatiser l'export CSV via API Splunk

En production, les exports CSV périodiques peuvent être automatisés via l'API REST Splunk : curl -k -u admin:pass "https://localhost:8089/services/search/jobs/export?search=index%3Dsecurity&output_mode=csv" > rapport.csv. Cette approche est utilisée pour alimenter des pipelines de données externes.

📸
Screenshots obligatoires avant le snapshot

Faire les screenshots avant d'éteindre les VMs — une fois éteintes, les dashboards et alertes restent mais les données récentes ne seront plus visibles de la même façon.

📊 TP 1 — Dashboards
🚨 TP 2 — Alertes
📄 TP 3 — Rapports
💬 Questions de réflexion — Débrief collectif
1

Avec le dashboard construit aujourd'hui, combien de temps faudrait-il à un analyste L1 pour détecter une attaque brute force en cours ?

Avec le Panel 1 (timeline 15 min) et l'alerte SSH configurée à 5 min, la détection théorique est de 5 à 20 minutes selon le timing. Sans alerte et sans dashboard, l'analyste devrait lancer une recherche manuellement — détection en heures voire jours. C'est l'impact direct du travail d'aujourd'hui : passer d'une détection réactive (après coup) à une détection proactive (en cours).

2

Le rapport hebdomadaire envoyé au RSSI contient des données sensibles (IPs internes, types d'attaques). Quelles précautions prendre ?

1. Chiffrer le PDF ou le lien de téléchargement. 2. Restreindre la liste de destinataires aux seules personnes habilitées. 3. Anonymiser les IPs dans la version destinée aux parties externes. 4. Conserver les rapports dans un espace de stockage avec contrôle d'accès et durée de rétention définie (RGPD). 5. Ne jamais envoyer via email non chiffré en dehors du périmètre de l'entreprise.

3

Demain, Jour 5 : le projet intégrateur. Quelles faiblesses reste-t-il dans votre SOC actuel ?

1. Pas de corrélation automatisée entre les outils (un ban Fail2ban + un scan Suricata de la même IP n'est pas encore traité comme un seul incident). 2. Trafic chiffré non analysé (HTTPS, DNS sur TLS). 3. Pas de VM Windows encore surveillée (Wazuh agent). 4. Pas de réponse automatique (isolation d'un hôte, blocage IP au firewall). 5. Le taux de couverture réel du SI n'est pas encore mesuré. Ce sont les axes d'amélioration du Jour 5.

🎉
Jour 4