📋 Playbook Development
Un playbook (ou runbook) est une procedure standardisee qui guide les analystes a travers les etapes d'une reponse a un type d'incident specifique.
Pourquoi c'est important : À 2h du matin face à un ransomware, sans runbook chacun improvise : l'un éteint, l'autre attend. Avec un playbook PB-RANSOM testé, le Tier 1 sait isoler sans éteindre, préserver les logs et escalader en 15 minutes. C'est la différence entre un incident contenu et une propagation à tout le domaine.
L'analogie qui aide : Comme la check-list des pilotes avant décollage : même expérimentés, ils la suivent case par case. Le playbook évite l'oubli fatal sous stress.
Structure d'un Playbook
# Playbook: [Nom du Type d'Incident]
Version: 1.0
Auteur: [Nom]
Date: [Date]
Derniere revision: [Date]
## En-tete
- **ID Playbook**: PB-XXX
- **Type d'incident**: [Description]
- **Severite**: [P1/P2/P3/P4]
- **Declencheurs**: [Alertes qui activent ce playbook]
- **Equipe responsable**: [Tier 1/2/3]
## Etapes de reponse
1. [ ] Verification initiale
2. [ ] Containment
3. [ ] Investigation
4. [ ] Eradication
5. [ ] Recuperation
6. [ ] Post-incident
## Automatisations
- [ ] Isolation reseau (API FW)
- [ ] Desactivation compte (API AD)
- [ ] Notification email
## Contacts
- SOC Manager: [Contact]
- CSIRT: [Contact]
- DPO: [Contact]
Exemple : Playbook Ransomware
- Verification : Confirmer l'alerte EDR. Verifier les processus suspects. Sauvegarder les logs.
- Containment : Isoler l'hote du reseau via EDR ou FW. Ne pas eteindre la machine (preuves en memoire).
- Investigation : Identifier le vecteur d'entree. Rechercher le lateral movement. Collecter les IOCs.
- Eradication : Supprimer les artefacts malveillants. Restaurer depuis un backup propre.
- Recuperation : Remettre en production. Surveiller les comportements anormaux.
- Post-incident : Post-mortem. Mise a jour des regles. Formation de l'equipe.
Démonstration pas à pas : Alerte EDR « rançongiciel suspect sur SRV-FICHIERS ». Étape 1 : vérification, confirmation du processus et sauvegarde des logs. Étape 2 : confinement, isolation réseau via EDR sans extinction. Étape 3 : investigation, vecteur d'entrée et mouvements latéraux identifiés. Étape 4 : éradication et restauration depuis backup sain. Livrable : ticket coché étape par étape avec IOC et heures.
Best practice : Chaque playbook doit etre teste regulierement via des exercises de simulation (tabletop exercises) pour garantir son efficacite.
Categories de Playbooks
- Reponse a incident : Ransomware, phishing, brute force, C2, exfiltration
- Investigation : Enrichissement d'IOC, analyse de malware, forensic
- Compliance : Audit, reporting regulier, revue des acces
- Operational : Provisioning, deprovisioning, rotation de cles
Pièges classiques : Un playbook de 40 pages que personne ne lit, ou jamais testé en tabletop et inapplicable le jour J. Autre faute : oublier les contacts DPO et CSIRT, puis chercher un numéro en pleine crise.
À vous de jouer : Ta première action face à un ransomware confirmé sur un poste ?
Voir la réponse
Isoler l'hôte du réseau via EDR ou pare-feu sans l'éteindre, sauvegarder les logs, ouvrir le ticket et escalader. Tu préserves la mémoire pour le forensique tout en stoppant la propagation.
☁ SIEM - Microsoft Sentinel
Microsoft Sentinel est un SIEM cloud-native et une solution SOAR integrees dans Azure. Il utilise KQL (Kusto Query Language) pour le requetage.
Pourquoi c'est important : Quand la direction signale des connexions impossibles sur Microsoft 365, Sentinel avec ses connecteurs natifs et le KQL te permet de confirmer en minutes si c'est une attaque par mot de passe pulvérisé. Sans cette maîtrise, tu passes des heures à exporter des logs à la main pendant que l'attaquant persiste.
L'analogie qui aide : Comme un moteur de recherche pour tes logs : les connecteurs amènent les livres (données), Log Analytics est la bibliothèque, le KQL est le bibliothécaire qui retrouve la phrase exacte.
Architecture
Sources ──▶ Data Connectors ──▶ Log Analytics ──▶ Sentinel ──▶ Workbooks
(M365, (API, Agent, (Kusto) (Detections, (Dashboards)
Azure, Syslog, Analytics
3rd party) CEF) Rules, SOAR)
KQL - Exemples de Requetes
// Detecter les echecs de connexion multiples
SigninLogs
| where ResultType != 0
| summarize FailedCount = count() by UserPrincipalName, IPAddress
| where FailedCount > 10
| order by FailedCount desc
// Rechercher un processus specifique
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("mimikatz.exe", "psexec.exe", "nc.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
// Correlation d'evenements
SecurityAlert
| join kind=leftouter SecurityIncident on IncidentNumber
| where Severity in ("High", "Critical")
| project AlertName, Severity, EntityFriendlyName, IncidentNumber
Analytics Rules
- Scheduled Rules : Requetes KQL executes a intervalle regulier
- Near-Real-Time (NRT) : Detection en quasi-temps reel (<1 min)
- Fusion : Detection avancee ML pour les attaques complexes
- Microsoft Security : Integration des alertes Defender
- Threat Intelligence : Matching avec les IOCs Threat Intel
Démonstration pas à pas : Suspicion de brute force sur Entra ID. Étape 1 : requête SigninLogs filtrée sur ResultType différent de 0. Étape 2 : agrégation par utilisateur et IP avec seuil supérieur à 10. Étape 3 : tri décroissant et création d'une Scheduled Rule. Étape 4 : le SOAR crée l'incident et force la réinitialisation. Livrable : règle KQL versionnée et incident traçable.
Attention : Les regles NRT ne supportent pas les jointures et les fonctions avancees. Utilisez-les pour des detections simples et rapides uniquement.
Pièges classiques : Écrire une règle NRT avec jointure qui échoue silencieusement, ou une requête sans filtre temporel qui scanne 90 jours et fait exploser les coûts Log Analytics. En entretien, précise toujours index, période et seuil.
À vous de jouer : Pourquoi ta règle NRT avec jointure ne se déclenche jamais ?
Voir la réponse
Parce que les règles NRT ne supportent pas les jointures ni les fonctions avancées. Il faut simplifier en détection rapide sans jointure, ou basculer sur une Scheduled Rule pour la corrélation.
📦 SIEM - Elastic Security
Elastic Security (ELK Stack) est une solution open source composee de Elasticsearch, Logstash et Kibana. Il utilise le KQL et le Lucene pour le requetage.
Pourquoi c'est important : Pour une PME sans budget Splunk, Elastic permet de centraliser Syslog et événements Windows et de détecter un mimikatz en quelques requêtes. Sans pipeline Filebeat vers Elasticsearch bien réglé, tes logs arrivent en retard ou non normalisés, et la chasse au mouvement latéral devient impossible.
L'analogie qui aide : Comme une chaîne de tri postal : Filebeat collecte les lettres, Logstash les trie et les tamponne, Elasticsearch les archive, Kibana permet de retrouver n'importe quel courrier en secondes.
Stack Technique
Sources ──▶ Filebeat/Logstash ──▶ Elasticsearch ──▶ Kibana
(Syslog, (Ingestion, (Indexation, (Visualisation,
Windows Normalisation, Recherche, Detection,
Events) Enrichissement) Stockage) Dashboards)
Exemples de Requetes Kibana
// Detection de brute force
event.kind: "alert" AND event.category: "authentication" AND event.outcome: "failure"
| stats count by source.ip, user.name
| where count > 20
// Recherche de processus suspects
process.name: ("mimikatz.exe" OR "procdump.exe" OR "psexec.exe")
AND NOT user.name: "SYSTEM"
| stats count by process.name, host.name, user.name
// Detection de lateral movement
event.action: "logon-success" AND
source.ip: 10.0.1.15 AND
destination.ip: (10.0.2.0/24 OR 10.0.3.0/24)
| stats unique_count(destination.port) as ports by source.ip, host.name
Detection Rules Elastic
- Custom Rules : Regles KQL/ESPL personnalisees
- Prebuilt Rules : Regles community et Elastic (MITRE ATT&CK mapped)
- Machine Learning Jobs : Detection d'anomalies via ML
- Threshold Alerts : Alertes basees sur des seuils
Démonstration pas à pas : Alerte « procdump.exe hors compte SYSTEM ». Étape 1 : recherche du process.name dans Kibana sur 24 heures. Étape 2 : exclusion du bruit légitime et statistiques par hôte et utilisateur. Étape 3 : création d'une Threshold Rule mappée MITRE ATT&CK. Étape 4 : vérification du déclenchement et ajustement du seuil. Livrable : règle testée avec faux positifs mesurés.
Pièges classiques : Activer toutes les Prebuilt Rules sans tuning : des centaines d'alertes inexploitables. Ou écrire une requête Lucene trop large sans champ précis, qui sature le cluster Elasticsearch.
À vous de jouer : Ta règle Elastic génère 200 alertes par jour sur un outil d'administration légitime. Que fais-tu ?
Voir la réponse
Tu ajoutes une exception précise (par exemple exclusion du compte ou chemin légitime), tu relèves le seuil après analyse, et tu documentes. Tu ne désactives jamais la règle brutalement sans alternative.
📈 SIEM - Splunk Enterprise Security
Splunk ES est le SIEM de reference pour les grandes organisations. Il utilise SPL (Search Processing Language).
Pourquoi c'est important : En grande entreprise avec 50 000 événements par seconde, seul Splunk ES avec index précis et Risk-Based Alerting permet de faire émerger le vrai incident parmi le bruit. Un analyste qui ne maîtrise pas le SPL ni les Notable Events passe à côté d'une exfiltration lente étalée sur trois semaines.
L'analogie qui aide : Comme un sismographe : les index sont les capteurs, le SPL est l'échelle de mesure, les Notable Events sont les secousses qui méritent l'évacuation. Sans calibrage, tout tremblement devient une alerte.
SPL - Exemples de Requetes
// Detecter les echecs de connexion multiples
index=authentication action=failure
| stats count as failures by src_ip, user
| where failures > 15
| sort -failures
// Rechercher des commandes suspectes
index=windows sourcetype=WinEventLog:Security EventCode=4688
| search Process_Name IN ("mimikatz.exe", "psexec.exe", "cmd.exe")
| table _time, ComputerName, User, Process_Name, Process_Command_Line
| sort -_time
// Analyse temporelle des alertes
index=security_alerts
| timechart span=1h count by severity
| rename count as "Nombre d'alertes"
Fonctionnalites Splunk ES
- Notable Events : Gestion des alertes prioritaires
- Risk-Based Alerting : Score de risque cumule par entite
- Adaptive Response : Actions automatisees (SOAR integre)
- Correlation Searches : Regles de detection avancees
- MITRE ATT&CK Mapping : Visualisation des TTPs detectes
Démonstration pas à pas : Soupçon d'exécution suspecte sur Windows. Étape 1 : requête SPL ciblée sur index=windows et EventCode 4688 avec fenêtre temporelle courte. Étape 2 : filtre sur mimikatz et psexec, projection en table triée par temps. Étape 3 : timechart horaire par sévérité pour visualiser le pic. Étape 4 : remontée en Notable Event avec score de risque. Livrable : corrélation SPL documentée et mappée ATT&CK.
Astuce : Commencez toujours vos requetes Splunk avec un index et un time range precis pour optimiser les performances.
Pièges classiques : Lancer une recherche sur all-time sans index : tu bloques le search head et tu attends 20 minutes. Autre erreur : confondre Correlation Search et simple saved search, puis rater le Risk-Based Alerting qui fait la vraie valeur de Splunk ES.
À vous de jouer : Ta requête SPL met 15 minutes à tourner. Que corriges-tu en premier ?
Voir la réponse
Tu ajoutes un index précis et une fenêtre temporelle courte, tu filtres le plus tôt possible avant les stats, et tu limites les champs avec table. L'ordre compte : filtrer d'abord, calculer ensuite.
⚡ Integration SOAR
Le SOAR (Security Orchestration, Automation and Response) permet d'automatiser les procedures de reponse et d'integrer les outils SOC entre eux.
Pourquoi c'est important : Avec 80 alertes de phishing par jour, traiter à la main épuise le Tier 1 et le MTTR explose. Un playbook SOAR qui enrichit, bloque et crée le ticket en 2 minutes rend l'équipe disponible pour les vrais incidents. Sans garde-fous, c'est aussi ce qui peut bloquer un domaine légitime à grande échelle.
L'analogie qui aide : Comme une ligne d'assemblage avec contrôle qualité : les robots font le tri répétitif (enrichissement, blocage basse criticité), l'humain valide les pièces sensibles avant expédition (isolation, suppression de compte).
Principes du SOAR
- Orchestration : Connecter tous les outils SOC via des API
- Automatisation : Executer des actions repetitives sans intervention humaine
- Response : Automatiser la reponse aux alertes de basse/moyenne severite
Exemples d'Automatisations
// Microsoft Sentinel Playbook (Logic App)
// Declencheur : Alerte de phishing detectee
1. Recevoir l'alerte (Azure Sentinel trigger)
2. Extraire les IOCs (URL, domaine, IP)
3. Verifier les IOCs contre Threat Intel (VirusTotal, AbuseIPDB)
4. Si malveillant :
a. Bloquer le domaine sur le proxy (API Zscaler)
b. Quarantaine de l'email (API Exchange)
c. Creer un ticket Jira (P2)
d. Envoyer notification Slack a l'equipe SOC
5. Si bénin :
a. Fermer l'alerte comme faux positif
b. Mettre a jour la whitelist
Connecteurs SOAR populaires
- API REST : Integration universelle
- Azure Logic Apps : 400+ connecteurs natifs
- Cortex XSOAR : 700+ integrations
- Webhooks : Slack, Teams, PagerDuty
Démonstration pas à pas : Alerte phishing reçue dans Sentinel. Étape 1 : déclencheur Logic App, extraction des IOC (URL, domaine, IP). Étape 2 : enrichissement automatique via VirusTotal et AbuseIPDB. Étape 3 : si malveillant, blocage proxy, quarantaine Exchange, ticket Jira P2 et message Slack. Étape 4 : si bénin, fermeture en faux positif et mise à jour de la liste blanche. Livrable : incident enrichi et traçable sans action manuelle répétitive.
Mise en garde : L'automatisation sans supervision peut causer des problemes. Toujours prevoir des gardes-fou : validation humaine pour les actions critiques (suppression de comptes, isolation reseau).
Pièges classiques : Automatiser l'isolation réseau sans approbation et couper un serveur de production en pleine journée. Ou chaîner 5 API sans gestion d'erreur : quand VirusTotal ne répond pas, tout le playbook échoue silencieusement.
À vous de jouer : Automatises-tu la désactivation d'un compte direction sur simple alerte ?
Voir la réponse
Non sans validation humaine. Tu automatises l'enrichissement et la préparation, mais la désactivation exige une approbation du Team Lead. Vitesse oui, aveuglément non.
📈 Metriques & KPI
Les KPIs permettent de mesurer l'efficacite du SOC et d'identifier les axes d'amelioration.
Pourquoi c'est important : En comité de direction, on ne te demande pas combien d'alertes tu as vues, mais ton MTTD et ton MTTR. Si ton MTTR dépasse 4 heures ou tes faux positifs 15 pour cent, tu justifies un tuning ou un recrutement. Sans KPI, le SOC subit sans prouver sa valeur.
L'analogie qui aide : Comme le tableau de bord d'une voiture : MTTD la vitesse de détection du danger, MTTR le temps de freinage, faux positifs les fausses alertes du radar. Conduire sans compteurs, c'est foncer à l'aveugle.
KPIs Essentiels
| KPI |
Definition |
Cible |
| MTTD |
Mean Time to Detect - Temps moyen de detection |
< 10 minutes |
| MTTR |
Mean Time to Respond - Temps moyen de reponse |
< 1 heure |
| MTTC |
Mean Time to Contain - Temps moyen de containment |
< 4 heures |
| Taux faux positifs |
Pourcentage d'alertes non pertinentes |
< 15% |
| Alertes traitees/jour |
Volume d'alertes analyses par analyste |
50-100 |
| Couverture MITRE |
Pourcentage de TTPs couverts par des regles |
> 70% |
| Playbook compliance |
Taux de suivie des playbooks |
> 90% |
Tableaux de bord recommandes
- Dashboard Operations : Volume d'alertes, queue de travail, temps de reponse
- Dashboard Threat : Types d'attaques, tendances, IOCs top
- Dashboard Compliance : Couverture regles, audits, incidents
- Dashboard Performance : MTTD, MTTR, productivite analystes
Démonstration pas à pas : Revue mensuelle SOC. Étape 1 : extraction MTTD 8 minutes, MTTR 55 minutes, faux positifs 12 pour cent. Étape 2 : comparaison aux cibles (10 minutes, 1 heure, 15 pour cent). Étape 3 : identification du point faible, couverture MITRE à 60 pour cent. Étape 4 : plan d'action, 5 nouvelles règles et tuning. Livrable : dashboard opérations et plan d'amélioration présenté au CISO.
Pièges classiques : Se vanter de 100 alertes traitées par jour sans regarder le MTTR, ou viser 0 pour cent de faux positifs en désactivant tout et en ratant les vrais positifs. Un bon KPI se lit en faisceau, jamais seul.
À vous de jouer : MTTD à 5 minutes mais MTTR à 6 heures. Où est le problème ?
Voir la réponse
La détection est bonne, la réponse est trop lente. Il faut revoir les playbooks, l'escalade et l'automatisation du confinement. Détecter vite sans contenir vite ne sert à rien.