🔴 Niveau Expert — Opérations Avancées
30+ leçons sur KQL avancé, automatisation, workbooks, threat hunting et attaques persistantes avancées (APT).
Module 1 : KQL Avancé
1.1 Fonctions personnalisées
KQL permet de créer des fonctions réutilisables pour simplifier les requêtes complexes.
Pourquoi c'est important : Quand cinq analystes réécrivent chaque jour le même filtre « connexions échouées des 24 h », vous perdez du temps et multipliez les erreurs. Une fonction stockée (FailedSignins) écrit la logique une fois, la teste une fois, et toute l'équipe la réutilise — y compris dans les règles analytics. C'est la différence entre un SOC artisanal et un SOC industrialisé.
L'analogie qui aide : Imaginez les recettes d'un restaurant : au lieu de réexpliquer chaque matin comment faire la vinaigrette, le chef l'écrit une fois sur une fiche, et tous les cuisiniers suivent la fiche. La fonction KQL est cette fiche recette : paramètres en entrée (ici le nombre d'heures), résultat standardisé en sortie.
// Créer une fonction pour les connexions échouées
.create-or-alter function
with (docstring = "Filtre les connexions échouées Azure AD")
FailedSignins(hours:int) {
SigninLogs
| where TimeGenerated > ago(hours)
| where ResultType != 0
}
// Utilisation de la fonction
FailedSignins(24)
| summarize count() by UserPrincipalName, ResultDescription
| order by count_ desc
Démonstration pas à pas : Suivez l'exemple : .create-or-alter function crée ou met à jour la fonction avec sa documentation (docstring) ; FailedSignins(hours:int) déclare un paramètre typé — hours doit être un entier ; le corps filtre SigninLogs sur TimeGenerated supérieur à ago(hours) et ResultType différent de 0. Utilisation : FailedSignins(24) retourne les échecs des dernières 24 h, que vous enchaînez avec summarize et order by. Changez 24 en 168 et vous avez la semaine, sans réécrire le filtre. Le paramètre rend la logique réutilisable.
Pièges classiques : les fonctions sont stockées dans le workspace — elles ne voyagent pas d'un workspace à l'autre, pensez à les redéployer ; un paramètre typé (int) rejette une valeur d'un autre type — FailedSignins passé avec une chaîne échoue ; et .create-or-alter exige des droits d'écriture sur le schéma — un rôle lecteur seul ne peut pas créer de fonction, ce qui tombe en question d'examen sur les RBAC.
À vous de jouer : Question de contrôle : votre règle analytics utilise FailedSignins(24) mais vous la copiez dans un autre workspace. Que se passe-t-il ?
Voir la réponse
La règle échoue : la fonction n'existe que dans le workspace d'origine. Il faut recréer FailedSignins dans le nouveau workspace (ou exporter puis rejouer le .create-or-alter) avant que la règle puisse s'exécuter.
1.2 Opérateurs avancés
make-series — Création de séries temporelles pour la visualisation
serialize — Ajoute un index de ligne pour les fonctions de fenêtrage
row_window() — Fonctions de fenêtrage sur les lignes adjacentes
partition — Partitionnement des données par clé
parse / parse_where — Extraction de patterns avec des expressions régulières
mv-expand — Expansion de tableaux multi-valués en lignes individuelles
mv-apply — Application d'opérations sur des tableaux multi-valués
bag_keys — Extraction des clés d'un objet JSON dynamique
externaldata — Chargement de données depuis des sources externes (CSV, APIs)
Pourquoi c'est important : Les opérateurs de base répondent à « que s'est-il passé ? », les avancés à « quelle est la tendance ? » et « que contiennent ces champs JSON ? ». make-series révèle une attaque lente sur 30 jours, mv-expand démonte les tableaux d'AuditLogs, parse extrait des motifs des chaînes brutes. Sans eux, vous êtes aveugle aux attaques étalées et aux données semi-structurées — exactement le terrain des attaquants avancés.
L'analogie qui aide : Imaginez un astronomie amateur : les opérateurs de base sont les jumelles (on voit les étoiles brillantes, les événements évidents), les opérateurs avancés sont le télescope avec suivi motorisé (make-series suit une courbe sur 30 nuits, mv-expand sépare les étoiles doubles, parse lit les spectres). Même ciel, tout autre niveau de détail.
// make-series : Tendance des connexions échouées par jour
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType != 0
| make-series FailedCount = count() default=0 on TimeGenerated from ago(30d) to now() step 1d by UserPrincipalName
| render timechart
// mv-expand + parse : Analyser les membres de groupe
AuditLogs
| where OperationName == "Add member to group"
| extend Members = TargetResources
| mv-expand Members
| extend MemberName = tostring(Members.displayName)
| project TimeGenerated, GroupName = TargetResources[0].displayName, MemberName, InitiatedBy = InitiatedBy.user.userPrincipalName
Démonstration pas à pas : Déroulez make-series : SigninLogs sur 30 jours, échecs uniquement ; make-series FailedCount = count() default=0 on TimeGenerated from ago(30d) to now() step 1d by UserPrincipalName — pour chaque utilisateur, on construit une série d'une valeur par jour (default=0 comble les jours vides, sinon les trous faussent les courbes) ; render timechart. Lecture : une ligne plate à 2-3 échecs par jour qui saute à 150 le 12 du mois, c'est une force brute datée au jour près. Puis mv-expand : AuditLogs, ajout de membre, on étend TargetResources en lignes, on extrait displayName — un ajout groupé illisible devient une ligne par membre, auditable.
Pièges classiques : make-series exige from, to et step explicites — sans bornes, la série est tronquée ; mv-expand multiplie les lignes (un tableau de 50 membres donne 50 lignes) — combinez-le avec un filtre strict avant, sinon explosion du volume ; parse échoue silencieusement si le motif ne correspond pas — préférez parse_where quand les lignes hétérogènes coexistent.
À vous de jouer : Question de contrôle : pourquoi écrire default=0 dans make-series, et que se passe-t-il sans ?
Voir la réponse
Sans default=0, les jours sans événement sont absents de la série au lieu de valoir zéro : la courbe montre des trous qui faussent les moyennes et cassent les détections d'anomalie. default=0 garantit une série continue, indispensable pour comparer les jours entre eux.
1.3 Windowing Functions
// Détection d'anomalies basées sur la tendance
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4625
| serialize
| extend RowNumber = row_number()
| extend MovingAvg = row_window_mean(FailedCount, 7, 0)
| where FailedCount > MovingAvg * 3 // Plus de 3x la moyenne
| project TimeGenerated, Computer, FailedCount, MovingAvg
Pourquoi c'est important : Compter ne suffit plus quand l'attaquant se fond dans le bruit : 50 échecs par jour, c'est normal pour un grand service, mais 50 échecs quand la moyenne mobile est de 5, c'est une attaque. Les fonctions de fenêtrage (serialize, row_number, row_window_mean) comparent chaque valeur à son historique glissant au lieu d'un seuil fixe. C'est le passage du seuil statique (qui hurle ou dort) à la détection adaptative.
L'analogie qui aide : Imaginez un cardiologue : il ne dit pas « au-delà de 100 battements, c'est anormal » — il compare votre rythme actuel à votre moyenne des derniers jours pendant l'effort. row_window_mean est cette moyenne personnelle : elle sait que 90 est normal pour un sportif au repos mais alarmant pour un patient habitué à 60.
Démonstration pas à pas : Déroulez l'exemple : SecurityEvent sur 30 jours, EventID 4625 ; serialize ordonne les lignes (obligatoire avant toute fonction de fenêtre) ; row_number numérote ; row_window_mean(FailedCount, 7, 0) calcule pour chaque ligne la moyenne des 7 lignes précédentes jusqu'à la courante ; where FailedCount supérieur à MovingAvg multiplié par 3 ne garde que les pics à plus de 3 fois la moyenne. Exemple chiffré : moyenne mobile de 12 échecs par jour, pic à 410 le mardi — la requête ne retourne que le mardi. Vous avez transformé 30 jours de bruit en une ligne d'alerte.
💡 Utilisez les fonctions
Les fonctions KQL sont stockées dans le workspace et réutilisables. Créez des fonctions pour les patterns de requêtes fréquents (filtrage de temps, formatage, corrélation).
Pièges classiques : oublier serialize avant row_window_mean donne des résultats faux ou une erreur — l'ordre des lignes doit être explicite ; le multiplicateur x3 est un choix de sensibilité : trop bas, des faux positifs ; trop haut, des attaques manquées — calibrez sur votre historique ; et ces fonctions travaillent sur l'ordre des lignes retournées, pas sur le temps : sans tri temporel préalable, la « moyenne glissante » ne glisse sur rien de sensé.
À vous de jouer : Question de contrôle : vous supprimez serialize de la requête. Que devient la moyenne mobile ?
Voir la réponse
Elle devient invalide : les fonctions de fenêtrage exigent un ordre de lignes explicite, et sans serialize l'ordre n'est pas garanti. La moyenne serait calculée sur des lignes dans un ordre quelconque — le pic détecté ne correspondrait à aucune réalité temporelle.
Module 2 : Règles d'Automation et Playbooks
2.1 Règles d'automation Sentinel
Les règles d'automation déclenchent automatiquement des actions lorsque des alertes ou incidents sont créés.
Pourquoi c'est important : Une alerte critique à 3h du matin qui attend 6 heures qu'un analyste l'assigne, c'est une attaque qui progresse librement. Les règles d'automation (assignation, statut, commentaire, lancement de playbook) exécutent en secondes les gestes réflexes : router au bon analyste, monter la sévérité, déclencher la réponse. L'automatisation ne remplace pas l'analyste — elle lui rend ses premières minutes.
L'analogie qui aide : Imaginez le standard d'un hôpital : quand un appel « arrêt cardiaque » arrive, le standard ne réfléchit pas — il bippe l'équipe de réanimation, ouvre le dossier et prévient le bloc. La règle d'automation est ce standard : condition en entrée (sévérité, tactique, produit), actions réflexes en sortie, sans attendre qu'un humain décroche.
- Automation Rules — Déclenchées par des conditions (sévérité, tactic, produit)
- Actions disponibles — Assignation, changement de statut, ajout de commentaires, exécution de playbook
- Ordre d'exécution — Les règles s'exécutent dans l'ordre de priorité (1 = première)
Démonstration pas à pas : Construisez une règle : déclencheur — incident créé avec sévérité Critical et tactique Credential Access ; actions — assigner à l'analyste d'astreinte, passer le statut à Active, ajouter le commentaire « Procédure vol d'identifiants : révoquer les sessions », exécuter le playbook d'isolation ; ordre de priorité 1 pour qu'elle passe avant les règles de tri général. Testez avec un incident simulé : vérifiez l'assignation, le commentaire et le déclenchement du playbook dans le journal d'activité. Une règle non testée est une règle qui échouera à 3h du matin.
Pièges classiques : l'ordre d'exécution compte — une règle générale qui ferme des incidents en faux positifs placée avant votre règle critique l'empêchera de se déclencher ; automation rule (réflexe sur alerte existante) contre analytics rule (création d'alerte) — l'examen les oppose systématiquement ; et une règle sans condition de fin (boucle playbook qui rouvre l'incident) crée des boucles infinies — bornez toujours les redéclenchements.
À vous de jouer : Question de contrôle : votre règle critique ne se déclenche jamais alors que des incidents Critical arrivent. Où regardez-vous en premier ?
Voir la réponse
L'ordre des règles : une règle antérieure (priorité plus basse en numéro) modifie ou ferme probablement ces incidents avant que votre règle ne les voie. Les règles s'exécutent dans l'ordre de priorité — placez les règles critiques en premier et vérifiez les journaux d'exécution.
2.2 Playbooks Logic App
Un playbook est une Azure Logic App qui s'exécute en réponse à un déclencheur Sentinel :
Pourquoi c'est important : Un playbook transforme une procédure écrite (isoler, notifier, créer un ticket) en exécution automatique en moins d'une minute, à toute heure, sans erreur de copier-coller. Déclencheur Sentinel, connecteurs (Teams, ServiceNow, Azure AD, Defender) et actions : c'est le bras armé du SOAR. Un SOC sans playbooks répond en heures ; avec, en minutes.
L'analogie qui aide : Imaginez une chaîne de montage : le déclencheur est le capteur qui détecte une pièce défectueuse (l'incident), chaque station ajoute une opération (isoler le poste, prévenir l'équipe, ouvrir un ticket), et le produit fini sort sans intervention humaine. Le playbook est cette chaîne : une fois réglée, elle tourne seule.
- Déclencheur — Incident ou alerte créé dans Sentinel
- Connecteurs — Microsoft Teams, ServiceNow, Jira, Azure AD, etc.
- Actions — Envoyer une notification, isoler un poste, bloquer un IP, créer un ticket
Démonstration pas à pas : Déroulez le scénario type : 1) déclencheur — incident de sévérité Critical créé ; 2) lecture — le playbook récupère les entités (le poste PC-042) ; 3) action Defender — appel Isolate Machine via le connecteur ; 4) action Teams — message au canal SOC avec le résumé ; 5) action Sentinel — commentaire « poste isolé à 14h03 » dans l'incident. Chaque étape journalise son succès ou son échec : en cas d'échec (droits insuffisants), le playbook le signale au lieu de se taire. La règle d'or : toute action automatique laisse une trace écrite.
Pièges classiques : le déclencheur incident n'apporte que les métadonnées — il faut une action « récupérer les entités » pour agir dessus ; multiplier les connecteurs multiplie les points de panne et les secrets à gérer — préférez le Managed Identity aux clés stockées ; et un playbook qui agit (isoler, bloquer) doit avoir un chemin d'approbation ou des conditions strictes — l'automatisation aveugle confine un jour le poste du directeur en pleine présentation.
À vous de jouer : Question de contrôle : votre playbook doit isoler un poste mais ne connaît que le titre de l'incident. Que manque-t-il ?
Voir la réponse
Les entités : le déclencheur ne fournit que les métadonnées de l'incident. Il faut ajouter une action de lecture des entités (ou des alertes) pour obtenir l'identifiant du poste (DeviceId) avant d'appeler l'isolation. Sans entité, l'action n'a pas de cible.
2.3 Exemple de Playbook
// Playbook : Isoler un poste de travail suite à une alerte critique
// 1. Déclencheur : Incident avec sévérité "Critical"
// 2. Récupérer les endpoints affectés
// 3. Appeler l'API Defender for Endpoint : Isolate Machine
// 4. Envoyer une notification Teams au SOC
// 5. Ajouter un commentaire dans l'incident
Pourquoi c'est important : Cet exemple est le patron que vous copierez pour 80 % de vos automatisations : déclencheur sur incident critique, récupération des endpoints, isolation via Defender, notification Teams, commentaire de traçabilité. Le maîtriser par coeur, c'est pouvoir construire un playbook de réponse en vingt minutes le jour d'un ransomware — quand chaque minute compte.
L'analogie qui aide : Imaginez une recette de cuisine en cinq lignes : 1) quand la sonnette retentit (déclencheur), 2) regardez par le judas qui est là (récupérer les endpoints), 3) verrouillez la porte si c'est un intrus (isoler), 4) appelez la police (notifier Teams), 5) notez l'heure dans le carnet (commentaire). Simple, ordonné, vérifiable — c'est exactement le plan de l'exemple.
Démonstration pas à pas : Jouez le scénario minute par minute : 14h00, incident Critical « Ransomware behavior » créé ; 14h00 et 20 secondes, le playbook démarre et lit les entités : PC-042 et PC-043 ; 14h01, appel API Isolate Machine sur les deux postes — le chiffrement ne peut plus se propager au réseau ; 14h01 et 30 secondes, message Teams au canal SOC avec les deux noms de poste et le lien vers l'incident ; 14h02, commentaire automatique dans l'incident. Bilan : propagation stoppée en 2 minutes, sans attendre l'analyste d'astreinte. Mesurez toujours ce délai : c'est votre preuve de valeur.
💡 Permissions des playbooks
Les playbooks nécessitent un Managed Identity avec les rôles appropriés (ex: Microsoft Sentinel Automation Responder). Ne jamais utiliser de comptes individuels pour l'automatisation.
Pièges classiques : isoler sans notifier laisse le SOC aveugle — la notification n'est pas décorative ; isoler tous les endpoints d'un incident sans vérifier peut couper des serveurs critiques — filtrez (postes de travail oui, serveurs à valider) ; et l'isolation Defender garde une connexion de gestion — « isolé » ne veut pas dire « éteint », l'investigation à distance reste possible, ce qui est voulu.
À vous de jouer : Question de contrôle : le playbook a isolé deux postes mais personne n'a été prévenu. Quelle étape manque et quel risque ?
Voir la réponse
La notification (Teams ou ticket) et le commentaire de traçabilité. Risque : les utilisateurs appellent le support qui ne comprend rien, l'analyste découvre l'isolation par hasard, et l'incident n'est pas suivi. Une réponse automatique sans communication est une réponse à moitié faite.
2.4 Headers HTTP personnalisés
// Exemple de connector custom dans un playbook
// POST https://api.service-now.com/api/now/table/incident
// Headers:
// Content-Type: application/json
// Authorization: Basic {{secrets('ServiceNowToken')}}
// Body: {
// "short_description": "{{incident.title}}",
// "severity": "{{incident.severity}}",
// "assignment_group": "SOC"
// }
Pourquoi c'est important : Les connecteurs Logic App ne couvrent pas tout : votre ITSM maison, votre firewall spécifique ou ServiceNow exigent parfois des appels HTTP sur mesure. Savoir construire un POST avec Content-Type, Authorization et un corps JSON dynamique (titre, sévérité de l'incident) vous rend autonome face à n'importe quelle API — compétence décisive quand l'examen ou la production sort des sentiers battus.
L'analogie qui aide : Imaginez que vous envoyez une lettre recommandée : l'en-tête Content-Type est la mention « contient des documents » (le format), Authorization est votre pièce d'identité au guichet (la preuve du droit d'envoyer), et le corps JSON est la lettre elle-même avec des champs à trous (titre, sévérité) remplis à chaque envoi. Même rituel à chaque fois, contenu adapté.
Démonstration pas à pas : Déroulez l'exemple ServiceNow : méthode POST vers l'URL de la table incident ; en-tête Content-Type application/json — le serveur sait qu'il reçoit du JSON ; en-tête Authorization Basic avec le secret (référencé via secrets(), jamais en dur) ; corps avec short_description rempli par le titre de l'incident, severity par sa sévérité, assignment_group fixé à SOC. Testez avec un incident factice, vérifiez le ticket créé et son contenu, puis seulement branchez le playbook sur du réel. Un appel testé une fois fonctionne cent fois.
Pièges classiques : un secret en dur dans le playbook est visible par tous les lecteurs — utilisez toujours le coffre (Key Vault ou secrets()) ; Basic contre Bearer : vérifiez le schéma exigé par l'API, un 401 vient presque toujours de là ; et le corps doit être du JSON valide — une virgule en trop et tout l'appel échoue silencieusement côté ticket (vérifiez le code retour HTTP, exigez un 201).
À vous de jouer : Question de contrôle : votre appel ServiceNow retourne 401. Vous vérifiez en premier le corps JSON ou l'en-tête Authorization ?
Voir la réponse
L'en-tête Authorization : 401 signifie « non authentifié », donc le problème est l'identifiant (schéma Basic/Bearer, secret expiré ou mal référencé), pas le contenu. Le corps JSON ne se vérifie qu'après un 200/201 ou face à une erreur 400 (requête mal formée).
Module 3 : Workbooks et Visualisation
3.1 Workbooks Sentinel
Les workbooks sont des tableaux de bord interactifs basés sur KQL pour visualiser les données de sécurité.
Pourquoi c'est important : Un SOC qui ne montre rien ne prouve rien : les workbooks transforment vos requêtes KQL en tableaux de bord que la direction comprend (courbes, tuiles, cartes). Textes, requêtes, métriques, parties HTML et paramètres : ces cinq briques construisent le reporting de sécurité — revues hebdomadaires, suivi du Secure Score, pilotage des incidents. Sans visualisation, vos données restent un secret d'initiés.
L'analogie qui aide : Imaginez le tableau de bord d'une voiture : la requête KQL est le moteur (ça tourne en dessous), les tuiles sont les voyants (alertes critiques : 3), les graphiques sont les compteurs (vitesse des incidents sur 7 jours), et les paramètres sont les boutons (choisir la période). Le conducteur (votre directeur) ne veut pas voir le moteur — il veut les voyants.
- Text — En-têtes et descriptions
- Query — Résultats KQL en tableau ou graphique
- Metrics — Graphiques de métriques Azure Monitor
- Parts — Éléments HTML personnalisés (Donut, Tiles, etc.)
- Parameters — Filtres interactifs (time range, dropdowns)
Démonstration pas à pas : Construisez un workbook en cinq gestes : 1) un bloc Text avec le titre et la question métier (« incidents critiques des 7 derniers jours ? ») ; 2) un bloc Query avec votre KQL qui compte par sévérité ; 3) un affichage en tuiles pour les chiffres clés et en barres pour la répartition ; 4) un paramètre Time range pour laisser le lecteur changer la période ; 5) sauvegarde dans le workspace partagé du SOC. Règle : un workbook répond à une question précise — celui qui affiche tout ne sert à rien.
Pièges classiques : un workbook interroge en direct à chaque affichage — une requête lourde sur 90 jours rend le tableau inutilisable, bornez les périodes ; les paramètres (time range, listes) doivent être branchés dans les requêtes ({Timerange:start}) sinon le filtre est décoratif ; et un workbook personnel n'est visible que par vous — publiez dans le groupe partagé pour le SOC.
À vous de jouer : Question de contrôle : votre workbook met 3 minutes à s'afficher. Quelle est la cause la plus probable et le correctif ?
Voir la réponse
Une requête trop gourmande (période trop longue, pas de filtre, summarize sur des millions de lignes). Correctif : réduire la période par défaut, filtrer tôt (where en premier), agréger moins large, et tester la requête dans Log Analytics pour mesurer son coût avant de l'embarquer.
3.2 Types de visualisations
- Bar chart — Distribution par catégorie
- Pie chart — Proportions
- Time chart — Évolution temporelle
- Line chart — Tendances
- Area chart — Aires empilées
- Scatter chart — Corrélations
- Table — Données tabulaires
- Tile — Cartes résumées
Pourquoi c'est important : Choisir le bon graphique, c'est choisir de faire comprendre : des barres pour comparer des catégories, un timechart pour une tendance, un donut pour des proportions, une table pour le détail, une tuile pour l'alerte chiffrée. Un mauvais choix (un camembert à 40 parts, une courbe pour des catégories) rend l'information illisible — et un reporting illisible ne déclenche aucune décision.
L'analogie qui aide : Imaginez une boîte à outils de mécanicien : le marteau (bar chart) enfonce les comparaisons, la clé dynamométrique (time chart) mesure les évolutions, le tournevis de précision (table) règle les détails, et le gros voyant rouge (tile) signale l'urgence. On ne visse pas avec un marteau : chaque visualisation a son usage.
// Exemple de requête pour un workbook de menace
SecurityAlert
| where TimeGenerated > ago(7d)
| summarize Count = count() by ProductName, AlertSeverity
| order by Count desc
| render barchart with (
title="Alertes par produit et sévérité (7j)",
xtitle="Nombre d'alertes",
ytitle="Produit"
)
Démonstration pas à pas : Appliquez à l'exemple : SecurityAlert sur 7 jours, comptage par produit et sévérité, tri décroissant, render barchart avec titres d'axes. Lecture : la barre « M365 Defender / High » domine — votre menace principale de la semaine vient des endpoints ; la barre « Azure Security Center / Critical » courte mais rouge exige un clic pour le détail en table. La méthode : vue agrégée en graphique pour décider, table détaillée en dessous pour agir. Les deux niveaux cohabitent dans le même workbook.
Pièges classiques : render est toujours le dernier opérateur — tout ce qui suit est ignoré ou provoque une erreur ; trop de séries sur un timechart (20 courbes) le rend illisible — agrégez ou filtrez le top 5 ; et les titres d'axes (xtitle, ytitle) ne sont pas décoratifs : un graphique sans unités se lit de travers en comité.
À vous de jouer : Question de contrôle : vous devez montrer l'évolution quotidienne des échecs de connexion sur 30 jours. Quelle visualisation et pourquoi pas un camembert ?
Voir la réponse
Un timechart (courbe temporelle) : il montre l'évolution et les pics jour par jour. Un camembert (pie chart) montre des proportions à un instant — avec 30 jours de données il serait illisible et masquerait la dynamique, qui est exactement l'information recherchée.
3.3 Paramètres de workbook
// Paramètre time range dans un workbook
// 1. Ajouter un paramètre "Timerange" de type "Time range"
// 2. Utiliser {Timerange:start} et {Timerange:end} dans les requêtes
SecurityEvent
| where TimeGenerated between ({Timerange:start} .. {Timerange:end})
| summarize count() by EventID
| order by count_ desc
Pourquoi c'est important : Un workbook en dur (période figée, périmètre figé) meurt en une semaine : chaque lecteur veut sa période, son service, sa sévérité. Les paramètres (time range, listes déroulantes) rendent le tableau interactif — un seul workbook sert alors toute l'entreprise. C'est la différence entre un rapport jetable et un outil de pilotage.
L'analogie qui aide : Imaginez un distributeur de boissons : sans boutons (paramètres), il ne sert qu'un café fixe ; avec boutons (période, périmètre, sévérité), chacun compose sa boisson. Les paramètres sont les boutons du workbook : même machine, consommation personnalisée.
Démonstration pas à pas : Branchez un paramètre pas à pas : 1) ajoutez un paramètre Timerange de type Time range avec une valeur par défaut (7 derniers jours) ; 2) dans la requête, remplacez ago(7d) par between ({Timerange:start} .. {Timerange:end}) ; 3) testez en changeant la période dans le menu — les graphiques doivent se recalculer ; 4) ajoutez une liste déroulante de sévérités branchée de la même façon. Vérifiez toujours qu'un changement de paramètre change réellement les chiffres : un paramètre débranché est un bouton factice qui détruit la confiance.
💡 Templates de workbook
Commencez avec les workbooks fournis par Microsoft (identité, endpoint, cloud, réseau) et personnalisez-les. Ils couvrent déjà les cas d'usage principaux du SC-200.
Pièges classiques : la syntaxe {Timerange:start} est sensible à la casse et aux accolades — une faute et la requête échoue ; un paramètre sans valeur par défaut bloque l'affichage initial du workbook ; et chaque paramètre ajoute une exécution de requête — accumulez trop de paramètres croisés et le workbook devient lent.
À vous de jouer : Question de contrôle : vous changez la période du workbook mais les chiffres ne bougent pas. Diagnostic ?
Voir la réponse
Le paramètre n'est pas branché dans les requêtes : elles utilisent encore une période en dur (ago(7d)). Il faut remplacer les bornes fixes par {Timerange:start} et {Timerange:end} dans chaque requête du workbook, puis retester.
Module 4 : Threat Hunting
4.1 Méthodologie du Threat Hunting
La chasse aux menaces est une approche proactive pour détecter les compromissions non identifiées par les détections automatiques.
Pourquoi c'est important : Les détections automatiques ne voient que le connu ; le hunting traque l'inconnu — l'attaquant discret qui passe sous les radars depuis trois mois. La méthode en cinq temps (hypothèse, données, requête, analyse, amélioration) transforme une intuition (« on serait vulnérable au living-off-the-land ») en finding prouvé puis en règle automatique. Sans méthode, le hunting n'est que du clic au hasard.
L'analogie qui aide : Imaginez un chercheur en médecine : il formule une hypothèse (ce virus résiste à cet antibiotique), choisit ses échantillons (les données), fait l'expérience (la requête), lit les résultats (l'analyse) et publie un traitement (la règle de détection). Le hunter est ce chercheur : même rigueur, même cycle, ennemis différents.
- Hypothèse — Formuler une hypothèse basée sur les tactiques MITRE ou les IoC
- Données — Identifier les tables KQL nécessaires pour tester l'hypothèse
- Requête — Écrire des requêtes KQL pour explorer les données
- Analyse — Évaluer les résultats et valider/infirmer l'hypothèse
- Amélioration — Créer des détections automatiques basées sur les findings
Démonstration pas à pas : Menez une chasse complète : 1) hypothèse — « un attaquant utilise mshta.exe depuis Temp pour exécuter du code » (technique MITRE T1218) ; 2) données — DeviceProcessEvents des 30 derniers jours ; 3) requête — filtre sur mshta dans les dossiers Temp, comptage par poste ; 4) analyse — 2 postes sur 500 exécutent mshta depuis Temp, dont un avec une ligne de commande contenant une URL externe : finding confirmé ; 5) amélioration — création d'une règle analytics sur ce motif. Une chasse qui ne finit pas en règle (ou en documentation) est une chasse perdue.
Pièges classiques : chasser sans hypothèse (explorer au hasard) brûle des heures pour aucun finding — partez toujours d'une technique MITRE ou d'un IoC ; chasser sur une période trop courte rate les attaques lentes — 30 jours minimum pour les comportements furtifs ; et ne jamais convertir un finding en détection condamne le SOC à redécouvrir la même attaque à chaque chasse.
À vous de jouer : Question de contrôle : après 2 heures d'exploration libre dans les logs sans hypothèse, vous n'avez rien trouvé. Quelle erreur méthodologique ?
Voir la réponse
L'absence d'hypothèse de départ : le hunting part d'une supposition testable (technique MITRE, IoC, scénario) qui guide le choix des tables et des requêtes. Explorer sans hypothèse, c'est chercher une aiguille sans savoir à quoi elle ressemble — ni même s'il y a une botte de foin.
4.2 Techniques de Threat Hunting
- Analyse des IoC — Chercher des indicateurs de compromission (IP, hash, domaines)
- Analyse comportementale — Détecter les déviations par rapport à la normale
- Analyse de pile d'exécution — Explorer les processus enfants et les chaînes d'exécution
- Analyse de cohérence — Vérifier la correspondance entre les événements de sécurité
- Analyse temporelle — Identifier les pics ou patterns inhabituels
Pourquoi c'est important : Les cinq techniques (IoC, comportementale, pile d'exécution, cohérence, temporelle) sont vos cinq angles d'attaque : un IoC trouve le connu, l'analyse comportementale trouve l'anormal, la pile d'exécution remonte au parent, la cohérence croise les sources, la temporelle repère les pics. Un bon hunter en combine toujours au moins deux — un IoC seul se contourne, un comportement seul fait des faux positifs.
L'analogie qui aide : Imaginez un douanier : il contrôle les passeports (IoC — les interdits connus), observe les comportements (le voyageur nerveux — l'anormal), fouille les bagages (la pile d'exécution — d'où vient ce processus ?), recoupe les déclarations (cohérence entre sources) et note les heures de passage (pics temporels). Cinq contrôles, un seul objectif : le passager qui cache quelque chose.
Démonstration pas à pas : Combinez deux techniques sur un cas : 1) temporelle — un pic de connexions RDP la nuit sur un serveur ; 2) comportementale — le compte utilisé ne fait jamais de RDP d'habitude ; 3) IoC — l'IP source figure dans un flux de threat intelligence ; 4) pile d'exécution — le processus parent est un service web compromis. Chaque technique seule est un indice faible ; les quatre ensemble sont une preuve. La règle : un finding solide croise au moins deux techniques indépendantes.
Pièges classiques : les IoC vieillissent vite (une IP malveillante est réattribuée en quelques semaines) — vérifiez la fraîcheur du flux ; l'analyse comportementale exige une baseline (sans « normal » connu, pas d'anormal détectable) ; et la pile d'exécution se falsifie (spoofing du processus parent) — corroborez toujours avec une seconde source.
À vous de jouer : Question de contrôle : un IoC signale une IP malveillante vue il y a 8 mois. Vous bloquez et concluez l'incident ?
Voir la réponse
Non : un IoC de 8 mois est probablement périmé (réattribution d'IP, infrastructure démantelée). Vérifiez sa fraîcheur, corroborez avec une analyse comportementale (activité anormale actuelle vers cette IP ?) et ne concluez que sur des preuves récentes croisées.
4.3 Requêtes de Threat Hunting avancées
// Hunt : Processus exécutés depuis des répertoires inhabituels
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FolderPath has_any ("\\Temp\\", "\\AppData\\Local\\Temp\\", "\\Public\\", "\\Downloads\\")
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe", "wscript.exe", "cscript.exe")
| summarize count() by DeviceName, AccountName, FileName, FolderPath
| order by count_ desc
Pourquoi c'est important : Ces trois requêtes sont des armes prêtes à l'emploi contre les classiques du SOC : exécutables lancés depuis Temp, vol d'identifiants via LSASS, RDP anormal. Les comprendre ligne par ligne vous permet de les adapter à votre environnement au lieu de les copier aveuglément — et l'examen SC-200 mesure exactement cette lecture fine (que filtre cette ligne ? pourquoi ce seuil ?).
L'analogie qui aide : Imaginez trois pièges à souris réglés différemment : le premier se déclenche sur l'endroit (les exécutables dans Temp — sale tronçon), le second sur l'appât (toucher à lsass, le garde-manger des mots de passe), le troisième sur l'habitude (une porte RDP qui s'ouvre alors qu'elle ne s'ouvre jamais). Trois pièges, trois logiques — à vous de choisir le bon.
// Hunt : Détecter le credential dumping (LSASS)
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_all ("lsass", "procdump") or
(FileName == "procdump.exe" and ProcessCommandLine has "lsass") or
(FileName == "rundll32.exe" and ProcessCommandLine has "comsvcs")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
// Hunt : Connexions RDP anormales
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort == 3389
| summarize ConnectionCount = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, RemoteIP
| where ConnectionCount > 5
| join kind=leftanti (
DeviceNetworkEvents
| where RemotePort == 3389
| where Timestamp > ago(30d)
| summarize count() by DeviceName, RemoteIP
| where count_ > 20
) on DeviceName, RemoteIP
Démonstration pas à pas : Déroulez la chasse RDP, la plus subtile : DeviceNetworkEvents sur 7 jours, port 3389 ; comptage par couple poste-IP avec premier et dernier contact ; seuil à plus de 5 connexions ; puis join kind=leftanti avec l'historique 30 jours des couples fréquents (plus de 20 connexions) — leftanti ne garde que les lignes de gauche SANS correspondance à droite, c'est-à-dire les couples nouveaux ou rares. Résultat : 200 connexions RDP se réduisent à 2 couples inhabituels, dont un serveur qui n'avait jamais fait de RDP. leftanti est l'opérateur star du hunting : il soustrait le connu pour révéler l'inconnu.
⚠️ Threat Hunting vs Detection
Le threat hunting est proactif (recherche de menaces non détectées), tandis que la détection est réactive (alertes basées sur des règles). Les findings du hunting doivent être convertis en règles de détection automatiques.
Pièges classiques : has_any sur les chemins exige les bons motifs — un attaquant qui utilise C:\Windows\Temp contourne un filtre limité à AppData ; la chasse LSASS par nom d'outil (procdump) rate les variantes — chassez le comportement (accès à lsass) autant que l'outil ; et les seuils (5, 20, 50) se calibrent sur votre environnement — un seuil copié d'un blog inonde ou aveugle.
À vous de jouer : Question de contrôle : que fait kind=leftanti dans la chasse RDP, en une phrase ?
Voir la réponse
Il soustrait le connu : il ne garde que les couples poste-IP récents qui n'ont PAS de correspondance dans l'historique des couples habituels. C'est un filtre « nouveauté » — ne reste que l'inhabituel, le périmètre à investiguer.
Module 5 : Attaques Persistantes Avancées (APT)
5.1 Caractéristiques des APT
- Sponsorisé par un État — Ressources importantes, patience, objectifs géopolitiques
- Persistence — Maintien de l'accès pendant des mois voire des années
- Opérational Security — Minimisation des traces, chiffrement,Living off the Land
- Supply Chain — Compromission de fournisseurs ou de logiciels tiers
- Zero-day — Exploitation de vulnérabilités non corrigées
Pourquoi c'est important : Les APT ne sont pas des cybercriminels pressés : parrainés par des États, patients pendant des mois, experts en discrétion (living off the land, chiffrement) et friands de zero-day et de supply chain. Les confondre avec de la délinquance classique fait sous-dimensionner la réponse : face à une APT, on ne « nettoie pas un poste », on mène une enquête d'envergure avec hypothèse de persistance multiple.
L'analogie qui aide : Imaginez la différence entre un cambrioleur (il force une porte, vole la télé, repart en 10 minutes) et un espion en mission longue (il se fait embaucher comme jardinier, copie les clés pendant six mois, photographie les documents chaque nuit sans rien déranger). Le premier veut un butin rapide, le second un accès durable et invisible. L'APT est cet espion.
Démonstration pas à pas : Reconnaissez une APT à ses traces : 1) durée — des connexions C2 régulières de quelques Ko chaque nuit depuis 8 mois (pas un pic, une marée basse continue) ; 2) discrétion — aucun malware connu, uniquement PowerShell et WMI légitimes (living off the land) ; 3) patience — trois mois entre l'accès initial et la première exfiltration ; 4) ciblage — seuls les postes de la R et D et leurs partages sont touchés. Face à ce profil, la réponse n'est pas le formatage du poste mais le plan de sortie coordonné (couper tous les accès simultanément, sinon l'attaquant se réinstalle par sa seconde porte).
Pièges classiques : attribuer trop vite à une APT (tout incident grave n'est pas étatique — 95 % sont de la criminalité financière) ; croire que l'antivirus suffit (les APT utilisent des zero-day et des outils légitimes, invisibles aux signatures) ; et sous-estimer la supply chain (le vecteur peut être un logiciel tiers compromis, pas votre périmètre direct) — l'examen adore ce vecteur.
À vous de jouer : Question de contrôle : un poste est infecté par un ransomware connu qui réclame 500 euros. APT ou criminalité classique ? Pourquoi ?
Voir la réponse
Criminalité classique : appât du gain immédiat, outil connu, pas de discrétion ni de persistance longue. Une APT chercherait un accès durable et furtif vers des données stratégiques, pas un chiffrement bruyant avec demande de rançon.
5.2 Kill Chain des APT
- Initial Access — Spear phishing, watering hole, supply chain, zero-day
- Foothold — Backdoor, webshell, persistence registry
- C2 Setup — Communication chiffrée avec le serveur de commandement
- Lateral Movement — Pass-the-Hash, Kerberoasting, RDP
- Privilege Escalation — DCSync, Golden Ticket, Token Manipulation
- Data Collection — Exfiltration binaire lente, chiffrement, stéganographie
- Exfiltration — DNS tunneling, HTTPS, cloud storage
Pourquoi c'est important : La kill chain en sept étapes (accès, ancrage, C2, mouvement latéral, escalade, collecte, exfiltration) est votre carte de la bataille : savoir où en est l'attaquant dit ce qu'il fera ensuite et où le couper. Couper le C2 avant l'exfiltration sauve les données ; confiner après l'exfiltration ne sauve que l'honneur. L'examen teste cette lecture : « à quelle étape sommes-nous ? que faire ? ».
L'analogie qui aide : Imaginez un siège de château fort : les éclaireurs repèrent (accès initial), une poterne est achetée (ancrage), les pigeons voyageurs partent (C2), les espions circulent dans les couloirs (mouvement latéral), ils volent les clés du donjon (escalade), emballent les archives (collecte) et les sortent par le souterrain (exfiltration). Chaque étape franchie rend la suivante plus grave — et arrêter les pigeons tôt sauve le trésor.
Démonstration pas à pas : Placez des indices réels sur la chaîne : email de spear phishing cliqué — étape 1 ; webshell déposé sur le serveur web — étape 2 ; beacons HTTPS réguliers vers un domaine jeune — étape 3 ; Pass-the-Hash vers trois serveurs — étape 4 ; DCSync détecté — étape 5 ; accès massif aux partages R et D — étape 6 ; transfert de 40 Go vers un cloud personnel — étape 7. Décision : si vous êtes à l'étape 3 (C2), coupez le réseau de façon coordonnée avant l'étape 7. La kill chain transforme des alertes en plan d'action ordonné.
Pièges classiques : les étapes ne sont pas toujours séquentielles (un attaquant peut exfiltrer avant d'avoir fini l'escalade) — la chaîne est un guide, pas un dogme ; confondre collecte (rassembler en interne) et exfiltration (sortir) fausse l'évaluation des dégâts ; et le C2 chiffré en HTTPS ressemble à du trafic normal — sans inspection TLS ou analyse comportementale, l'étape 3 est invisible.
À vous de jouer : Question de contrôle : vous détectez des beacons C2 réguliers mais aucune exfiltration. À quelle étape êtes-vous et quelle est la priorité ?
Voir la réponse
Étape 3 (C2 installé, contrôle établi, pas encore d'exfiltration). Priorité : couper les accès de façon coordonnée AVANT l'exfiltration — identifier toutes les portes (comptes, postes, persistance) et les fermer simultanément, sinon l'attaquant bascule sur son accès de secours.
5.3 Détection des APT avec Sentinel
// Hunt APT : Détecter le DCSync (credential theft)
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4662 // Accès aux objets AD
| where Properties has_all ("DS-Replication-Get-Changes", "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2")
| project TimeGenerated, Account = AccountUsed, TargetServer = Computer, Properties
Pourquoi c'est important : Ces trois chasses (DCSync via l'EventID 4662, DNS tunneling par longueur et volume, persistance via les tâches 4698) ciblent les gestes que les APT ne peuvent pas éviter : voler les identifiants, communiquer furtivement, survivre au redémarrage. Les connaître, c'est avoir des filets là où les APT passent obligatoirement — même avec des outils légitimes et du chiffrement.
L'analogie qui aide : Imaginez trois capteurs dans une maison : le premier écoute qui demande le double des clés (DCSync — réplication d'annuaire), le second mesure les lettres postées (DNS : des centaines de lettres épaisses vers l'étranger, c'est du tunneling), le troisième vérifie qui a posé un paillasson piégé devant la porte (tâche planifiée — persistance). L'espion le plus discret doit bien dupliquer des clés, écrire à sa centrale et garder un pied dans la place.
// Hunt APT : Détecter le DNS Tunneling
DnsEvents
| where TimeGenerated > ago(7d)
| extend QueryLength = strlen(ConcatQueryName)
| where QueryLength > 50
| summarize SuspiciousQueries = count(), UniqueDomains = dcount(ConcatQueryName) by ClientIP, bin(TimeGenerated, 1h)
| where SuspiciousQueries > 100 or UniqueDomains > 50
| order by SuspiciousQueries desc
// Hunt APT : Persistence via Scheduled Tasks
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4698 // Tâche planifiée créée
| where TaskName !startswith "Microsoft"
| project TimeGenerated, Account = Account, TaskName, TaskContent
| order by TimeGenerated desc
Démonstration pas à pas : Déroulez la chasse DCSync : SecurityEvent sur 30 jours, EventID 4662 (accès aux objets AD) ; filtre sur les droits de réplication (DS-Replication-Get-Changes et le GUID du service) dans Properties ; project du compte et du serveur. Seuls les vrais contrôleurs de domaine répliquent : tout autre compte avec ces droits est un attaquant qui aspire l'annuaire. Puis DNS tunneling : requêtes de plus de 50 caractères, plus de 100 requêtes ou 50 domaines par heure et par poste — un poste normal ne fait jamais ça, un tunnel oui. Deux requêtes, deux gestes incontournables des APT.
💡 Intelligence Threat
Intégrez des threat intelligence feeds dans Sentinel (STIX/TAXII) pour enrichir vos détections avec des IoC connus des APT. Utilisez les indicators dans Analytics Rules pour matcher automatiquement les IoC.
Pièges classiques : l'EventID 4662 est très bruyant sans le filtre sur les GUID de réplication — la précision est dans le détail du filtre ; le DNS tunneling se confond avec les antivirus cloud ou les CDN verbeux — whitelistez vos services légitimes avant de chasser ; et la tâche 4698 exclut les tâches Microsoft par préfixe — un attaquant qui nomme sa tâche « MicrosoftUpdate » contourne ce filtre, chassez aussi les tâches aux chemins suspects.
À vous de jouer : Question de contrôle : un compte de sauvegarde légitime déclenche votre chasse DCSync. Faux positif ou vraie alerte ? Comment tranchez-vous ?
Voir la réponse
Probablement un faux positif à valider : les comptes de sauvegarde peuvent avoir des droits de réplication. Tranchez en vérifiant que le compte est bien le compte officiel, que le serveur cible est un vrai DC, et que l'activité suit le planning de sauvegarde — sinon, traitez comme un DCSync hostile et réagissez.
Module 6 : Réponse Avancée et Recovery
6.1 Réponse aux incidents critiques
- Confinement réseau — Blocage des IPs/sources dans le NSG ou le pare-feu via playbook
- Confinement endpoint — Isolation du poste via l'API Defender for Endpoint
- Désactivation de compte — Blocage du compte Azure AD compromis via playbook
- Purge d'email — Suppression des emails malveillants via Defender for Office 365
Pourquoi c'est important : Face à un incident critique, quatre gestes comptent et s'apprennent avant le jour J : confinement réseau (NSG/pare-feu via playbook), confinement endpoint (isolation Defender), désactivation du compte (Azure AD via playbook), purge des emails (Defender for Office 365). Les connaître avec leurs outils, c'est passer de la panique au réflexe — et l'examen vérifie que vous savez quel outil pour quel geste.
L'analogie qui aide : Imaginez un incendie dans un immeuble : on coupe le gaz (réseau — confinement NSG), on confine le feu dans l'appartement (endpoint — isolation du poste), on bloque l'ascenseur aux intrus (compte — désactivation), et on évacue les voisins exposés (emails — purge des boîtes infectées). Quatre gestes simultanés, quatre outils — aucune improvisation.
Démonstration pas à pas : Jouez un ransomware à 15h00 : 15h01, playbook — isolation des 3 postes via Defender for Endpoint (la propagation réseau s'arrête) ; 15h02, playbook — révocation des sessions et blocage du compte compromis dans Azure AD (l'attaquant perd son accès) ; 15h03, règle NSG — blocage de l'IP C2 au pare-feu (le chiffrement ne reçoit plus d'ordres) ; 15h05, purge — suppression des emails piégés restants dans les boîtes via Defender for Office 365 (plus de nouvelle victime). Quatre gestes, cinq minutes, un seul coordinateur. Répétez ce scénario en exercice : le jour J, on exécute, on ne découvre pas.
Pièges classiques : isoler un serveur critique sans validation coupe la production — distinguez postes (automatique) et serveurs (validation humaine) ; désactiver un compte sans révoquer ses sessions laisse l'attaquant connecté avec ses tokens existants — faites les deux ; et la purge email ne couvre que les boîtes connectées — les PST locaux et les transferts échappent, vérifiez.
À vous de jouer : Question de contrôle : vous désactivez le compte compromis mais l'attaquant reste actif sur le poste. Qu'avez-vous oublié ?
Voir la réponse
De révoquer les sessions et tokens existants (et d'isoler le poste). Désactiver le compte bloque les futures connexions, mais les sessions déjà ouvertes et les tokens valides restent utilisables. La procédure complète est : isoler le poste, désactiver le compte ET révoquer ses sessions.
6.2 Forensics et Evidence Collection
- Collecte de préuves — Snapshot des VM, collecte de mémoire, dumps disque
- Chaîne de possession — Documentation complète de la manipulation des preuves
- Analyse forensique — Extraction d'IOC, timeline reconstruction, attribution
Pourquoi c'est important : Répondre sans preuves, c'est accuser sans dossier : snapshots VM, images mémoire et dumps disque collectés proprement permettent l'analyse (timeline, IOC, attribution) et tiennent devant un tribunal. La chaîne de possession (qui a manipulé quoi, quand) fait la valeur juridique des preuves — sans elle, vos découvertes techniques sont inutilisables en procédure.
L'analogie qui aide : Imaginez une scène de crime : on photographie avant de toucher (snapshot), on met les indices en sachets scellés et numérotés (images forensiques hachées), on note chaque personne qui touche un sachet (chaîne de possession), et le labo analyse ensuite (timeline, attribution). Le SOC qui éteint le serveur avant le snapshot est le policier qui passe la serpillière sur les empreintes.
Démonstration pas à pas : Collectez dans l'ordre : 1) snapshot de la VM compromise AVANT toute action (fiançailles avec l'état actuel) ; 2) dump mémoire si le poste est allumé (les clés, process et connexions s'y trouvent et meurent à l'extinction) ; 3) copie des disques avec empreinte cryptographique (SHA-256 notée au procès-verbal) ; 4) journalisation de chaque manipulation (qui, quoi, quand, pourquoi) ; 5) analyse sur COPIE, jamais sur l'original. Puis reconstruisez la timeline : premier accès, escalade, exfiltration — chaque fait horodaté devient une ligne du rapport.
Pièges classiques : éteindre avant de collecter détruit la mémoire (processus, clés, connexions) — snapshot et dump d'abord, extinction ensuite ; analyser l'original au lieu d'une copie casse la chaîne de possession ; et collecter sans base légale (CSE, RGPD, accord hiérarchique) expose l'entreprise — le forensique se fait avec un cadre, pas en solo.
À vous de jouer : Question de contrôle : l'analyste éteint le serveur compromis « pour stopper l'attaque » avant toute collecte. Quelle erreur et quelle perte ?
Voir la réponse
Il a détruit la mémoire vive : processus en cours, clés de chiffrement, connexions réseau, fichiers déchiffrés — autant de preuves volatiles perdues à jamais. Le réflexe correct : snapshot et dump mémoire d'abord (la propagation se coupe au réseau, pas en éteignant), extinction ensuite.
6.3 Post-Incident
- Retour d'expérience — Analyse root cause, leçons apprises
- Amélioration des détections — Création de nouvelles règles analytics
- Mise à jour des playbooks — Automatisation de la réponse basée sur les findings
- Reporting — Documentation pour les audits et la conformité
Pourquoi c'est important : Un incident sans retour d'expérience est un incident qui se répétera : root cause, leçons apprises, nouvelles règles analytics, playbooks mis à jour, reporting d'audit. Le post-incident transforme une crise subie en capital de défense — c'est ce cycle qui distingue un SOC mature d'une équipe qui éteint des feux en boucle.
L'analogie qui aide : Imaginez un club d'aviation après un incident : on ne se contente pas de réparer l'avion — on analyse la boîte noire (root cause), on publie le rapport pour tous les pilotes (leçons), on modifie les check-lists (règles et playbooks) et on rend compte à l'autorité (reporting). Le prochain vol est plus sûr grâce au précédent. Votre SOC doit fonctionner comme ce club.
Démonstration pas à pas : Menez un post-incident en quatre livrables : 1) compte-rendu factuel — timeline de l'attaque minute par minute, périmètre, dégâts ; 2) root cause — phishing non filtré plus absence de MFA : deux causes, deux responsables (technique et gouvernance) ; 3) actions — règle analytics sur le domaine C2, playbook d'isolation étendu aux serveurs, campagne MFA forcée sous 30 jours avec pilote nommé ; 4) reporting — synthèse pour la direction (risque, coût, mesures) et dossier pour l'audit. Vérifiez à 90 jours : chaque action est-elle faite ? Un plan non suivi est un voeu pieux.
💡 Opérations de sécurité matures
Un SOC mature combine : détection automatique (règles analytics), threat hunting proactif, automatisation (playbooks) et amélioration continue basée sur les retours d'expérience.
Pièges classiques : chercher un coupable au lieu d'une cause — le post-mortem sans blâme obtient la vérité, l'autre obtient le silence ; écrire des actions sans pilote ni délai — elles ne se feront jamais ; et oublier de mettre à jour les détections — le même incident reviendra et le second rapport fera mal. Retenez : pas de responsable nommé, pas d'action.
À vous de jouer : Question de contrôle : votre rapport post-incident liste 5 actions sans responsable ni échéance. Que va-t-il se passer dans 90 jours ?
Voir la réponse
Rien : sans pilote nommé ni délai, aucune action ne sera suivie ni réalisée, et le même incident pourra se reproduire à l'identique. Un plan d'action n'existe que s'il est assigné, daté et revu — prévoyez systématiquement responsable, échéance et point de contrôle.