Expert - SOC Operations Avancées

Corrélation SIEM Avancée

01 Règles de corrélation complexes 55 min ▸
Au-delà des règles simples, la corrélation avancée combine :

Pourquoi c'est important : Une alerte isolée n'est que du bruit : une tentative SSH, c'est le quotidien d'Internet. Mais une tentative suivie d'un succès dans les 5 minutes puis de commandes suspectes, c'est une compromission. La corrélation temporelle, spatiale, statistique et multi-sources transforme des signaux faibles en détection fiable. Sans elle, le SOC noie l'analyste ; avec elle, il le guide. C'est le cœur du niveau expert.

L'analogie qui aide : Pensez à un puzzle : une pièce isolée ne montre rien, mais dix pièces assemblées révèlent l'image. Ou à l'orchestre : une note seule n'est pas une mélodie, c'est leur enchaînement qui fait la musique. La corrélation, c'est l'assemblage : chaque événement est une pièce, l'alerte corrélée est l'image.
- Corrélation temporelle : Événements A puis B dans un intervalle de temps
- Corrélation spatiale : Même source sur multiples capteurs
- Corrélation statistique : Détection d'anomalies par déviation
- Corrélation multi-sources : Firewall + Auth + Proxy = Incident
Exemple de corrélation avancée :
- Événement A : Tentative SSH depuis IP externe
- Événement B : Connexion réussie < 5 min après
- Événement C : Commandes shell suspectes
- Résultat : Alerte "Compromission SSH possible"
Démonstration pas à pas : Règle « compromission SSH possible ».
1. Contexte : trois événements à chaîner — tentative depuis une IP externe, succès peu après, commandes shell suspectes.
2. Enrichissement : fenêtre temporelle courte, jointure sur les champs normalisés (utilisateur, IP source, hôte).
3. Classification : la séquence complète déclenche une alerte de sévérité haute avec les trois preuves.
4. Action : rejeu sur l'historique pour calibrer, activation, surveillance des faux positifs. La recette : chaîner, borner dans le temps, joindre sur des champs propres, tester avant d'activer.

Pièges classiques : Fenêtre temporelle trop large (faux positifs en cascade) ou trop courte (vrais positifs manqués) ; corréler sur des champs non normalisés (les jointures ratent) ; règles qui se déclenchent en cascade (tempête d'alertes) ; activer sans rejeu sur l'historique.

À vous de jouer : Votre règle « 5 échecs puis 1 succès » génère du bruit à cause des comptes de service légitimes. Que faites-vous : vous la supprimez ?
Voir la réponse
Non, on l'affine : exclusion des comptes de service connus (allowlist documentée), fenêtre resserrée, et idéalement troisième signal exigé (commande suspecte après le succès). Supprimer la règle, c'est perdre la détection ; la tuner, c'est la rendre viable. Si votre plan contient exclusion, resserrage et test, il est bon.
02 Use Cases SOC avancés 50 min ▸
Use cases critiques pour un SOC mature :

Pourquoi c'est important : Les use cases sont les détections pilotées par le risque : mouvements latéraux, escalade de privilèges, exfiltration, stuffing, tunneling DNS, beaconing, Living-off-the-Land. Chaque use case couvre une TTP réelle d'attaquant, pas un scénario imaginaire. Un SOC mature se mesure à sa bibliothèque de use cases — et à leur taux de vrais positifs.

L'analogie qui aide : Pensez aux vaccins : on vaccine contre les maladies qui circulent vraiment, pas contre des virus imaginaires, et on adapte le cocktail au pays. Les use cases, c'est le carnet de vaccination du SOC : les bonnes protections contre les vraies menaces du moment.
- Lateral Movement : Détection de mouvements latéraux (PsExec, WMI, RDP)
- Privilege Escalation : Ajout de privilèges, abus de tokens
- Data Exfiltration : Transferts anormaux vers l'extérieur
- Credential Stuffing : Tentatives massives avec many accounts
- DNS Tunneling : Longueur anormale de sous-domaines
- Beaconing : Communication C2 régulière
- Living-off-the-Land : Abus d'outils légitimes (PowerShell, WMI)
Démonstration pas à pas : Use case « mouvement latéral via PsExec ».
1. Contexte : création de service suspect (7045) plus ouverture de session réseau (4624 type 3) sur le même hôte.
2. Enrichissement : même créneau, binaire PsExec identifié, compte inhabituel pour de l'administration.
3. Classification : TTP de mouvement latéral avérée.
4. Action : règle activée après mesure du bruit admin légitime et test sur historique. Chaque use case suit ce chemin : TTP, signaux, bruit légitime mesuré, règle testée.

Pièges classiques : Empiler 200 use cases sans tuning (noyade garantie) ; déployer un use case sans sa source de logs (détection aveugle) ; ne jamais mesurer l'efficacité (use cases morts depuis des mois) ; copier des use cases génériques sans les adapter à son environnement.

À vous de jouer : On vous demande un use case « DNS tunneling » mais aucun log DNS n'est collecté. Déployez-vous quand même ?
Voir la réponse
Non : sans données, la règle ne détectera jamais rien et donnera un faux sentiment de sécurité. D'abord combler le gap de couverture (collecter les logs DNS), ensuite déployer et tester. Si vous avez priorisé la collecte avant la règle, votre ordre est juste.
03 Détection d'anomalies avec UEBA 45 min ▸
UEBA (User and Entity Behavior Analytics) utilise le machine learning :

Pourquoi c'est important : Les règles classiques ratent les activités « légitimes mais anormales » : un compte compromis utilisé normalement, un insider qui exfiltre avec ses propres accès. L'UEBA profile le comportement normal de chaque entité par machine learning, détecte les déviations et produit un score de risque dynamique. C'est le filet pour ce que les signatures ne voient pas — et un sujet d'entretien expert.

L'analogie qui aide : Pensez au vigile d'un immeuble qui connaît tous les habitués : il repère instantanément le comportement inhabituel sans aucune consigne écrite — la personne qui vient à 3h du matin avec des cartons. Ou à votre banque qui bloque la carte utilisée à l'étranger : elle connaît vos habitudes et s'étonne des écarts. L'UEBA, c'est ce vigile algorithmique.
- Profilage du comportement normal de chaque utilisateur
- Détection de déviations par rapport au baseline
- Score de risque dynamique par entité
- Détection des compromissions de comptes
- Analyse de shower : vers qui l'utilisateur envoie des données ?
Démonstration pas à pas : La comptable et ses 10 Go.
1. Contexte : baseline connue — bureau, 9h-18h, petits volumes.
2. Enrichissement : trois déviations simultanées — connexion à 3h, depuis un pays étranger, 10 Go vers un cloud personnel.
3. Classification : score de risque élevé — une orientation d'enquête, pas une preuve.
4. Action : vérification humaine par un analyste, jamais de sanction automatique. La doctrine : le score propose, l'humain dispose.

Pièges classiques : Entraîner la baseline sur une période déjà compromise (on apprend le mal comme normal) ; subir un déluge d'alertes au démarrage (seuils non calibrés) ; traiter le score comme une preuve (sanction automatique) ; ignorer le cadre légal et la vie privée dans la surveillance des utilisateurs.

À vous de jouer : Un nouvel employé est flaggé chaque jour pendant deux semaines. Pourquoi, et que faites-vous ?
Voir la réponse
Le modèle n'a pas de baseline pour lui : sans période d'apprentissage, tout est déviation. On laisse la baseline se constituer, on ajuste les seuils pour les nouveaux arrivants, et on vérifie humainement en attendant. Si vous avez diagnostiqué l'apprentissage plutôt que la malveillance, votre lecture UEBA est bonne.
04 Analyse de beacons C2 50 min ▸
Le beaconing est le signe d'un CNC actif :

Pourquoi c'est important : Le beaconing — ces requêtes périodiques vers un serveur de commande — est la preuve qu'un attaquant est présent et actif dans le système. Savoir le détecter (intervalles réguliers, jitter d'évasion, analyse statistique avec RITA ou notebooks) distingue l'analyste avancé : c'est traquer le dialogue avec l'attaquant, pas seulement ses outils.

L'analogie qui aide : Pensez au phare qui clignote dans la nuit : régulier, discret, destiné à guider quelqu'un. Ou au prisonnier qui tape au mur à intervalles réguliers pour parler à la cellule voisine. Le beacon C2, c'est ce clignotement : le malware signale « je suis vivant » à son maître.
- Intervalle régulier : Requêtes DNS/HTTP périodiques
- Jitter : Légère variation de timing pour évasion
- Détection : Analyse statistique des intervals
- Outils : RITA (Real Intelligence Threat Analytics), Jupyter notebooks
Démonstration pas à pas : Logs proxy d'un poste suspect.
1. Contexte : domaine jeune, jamais vu dans l'entreprise.
2. Enrichissement : connexions toutes les 60 secondes avec léger jitter, analyse statistique des intervalles (RITA), user-agent inhabituel.
3. Classification : beaconing probable — C2 actif.
4. Action : isolation, blocage du domaine, recherche d'autres postes avec le même rythme. La méthode : mesurer les intervalles, juger la régularité, corroborer, étendre.

Pièges classiques : Confondre beacon et polling légitime (antivirus, mises à jour : la baseline du normal d'abord) ; utiliser une statistique naïve face à un jitter élevé ; analyser sans connaître le trafic normal de l'entreprise ; conclure sur un seul indicateur.

À vous de jouer : Connexions toutes les 60 secondes vers un domaine : beacon malveillant ou simple mise à jour logicielle ? Comment tranchez-vous ?
Voir la réponse
Par faisceau d'indices : âge et réputation du domaine, entropie du nom, user-agent, régularité stricte contre fenêtres de mise à jour, autres postes affectés, processus source côté EDR. Un seul signal ne tranche jamais. Si votre méthode croise au moins trois indices, elle est solide.

Playbook Development

05 Conception de playbooks 50 min ▸
Comment créer un playbook efficace :

Pourquoi c'est important : Un playbook bien conçu standardise la réponse : même qualité à 15h qu'à 3h du matin, formation des nouveaux facilitée, audit possible. Format, déclencheur précis, étapes avec outils et temps, escalade, communication : chaque rubrique a sa raison. Concevoir des playbooks, c'est industrialiser l'excellence du SOC — compétence clé du niveau expert.

L'analogie qui aide : Pensez au plan d'architecte : chaque corps de métier sait quoi faire, quand, avec quels matériaux, et qui appeler en cas de problème. Ou à la partition d'orchestre : chacun joue sa partie, ensemble cela fait la symphonie. Le playbook, c'est la partition de l'incident.
- Format : Workflow structuré avec étapes numérotées
- Déclencheur : Type d'alerte spécifique (ex: "Malware Detected")
- Étapes : Actions précises, outils requis, temps estimé
- Escalade : Conditions et contacts
- Communication : Templates pour chaque scénario
Démonstration pas à pas : Canevas « malware détecté ».
1. Contexte et déclencheur : alerte EDR précise, périmètre défini.
2. Enrichissement : étapes numérotées — vérifier le blocage effectif, chercher la propagation latérale, isoler si besoin — chacune avec outils et temps estimé.
3. Classification : critères d'escalade écrits et contacts nommés.
4. Action : templates de communication, SLA, puis test en exercice tabletop avant mise en service. Un playbook se teste avant de servir.

Pièges classiques : Playbook générique copié-collé (inapplicable à votre entreprise) ; sans propriétaire ni maintenance (périmé en six mois) ; jamais testé (la première utilisation est en incident réel) ; sans critères de sortie (on ne sait jamais quand clôturer).

À vous de jouer : Un playbook commence par « analyser la situation » sans dire qui, avec quoi, ni en combien de temps. Quel est son défaut ?
Voir la réponse
Il n'est pas actionnable : pas de RACI, pas d'outils, pas de SLA. Un playbook doit être exécutable par un analyste de garde à 3h du matin sans appeler personne pour comprendre. Si votre critique exige le qui, le quoi et le combien de temps, elle est juste.
06 Automatisation avec SOAR 55 min ▸
SOAR (Security Orchestration, Automation and Response) :

Pourquoi c'est important : Le SOAR divise le MTTR en automatisant le répétitif : orchestration multi-outils via API, enrichissement automatique des IOC, blocage des cas simples, création de tickets. L'analyste se concentre sur la valeur — l'investigation et la décision. Mais l'automatisation est une arme à double tranchant : progressive et supervisée, ou dangereuse. D'où la règle d'or de la leçon.

L'analogie qui aide : Pensez à la chaîne de montage : les robots font le répétitif vite et sans fatigue, les humains supervisent et gèrent les exceptions. Ou au pilote automatique : il tient le cap, mais le pilote reste aux commandes et peut reprendre la main. Le SOAR, c'est le pilote automatique du SOC.
- Orchestration : Intégration multi-outils via API
- Automatisation : Réponse automatique aux alertes de basse sévérité
- Playbooks automatisés : Enrichissement IOC, blocage IP, création ticket
- Outils : Cortex XSOAR, Splunk SOAR, Shuffle (open source)
Démonstration pas à pas : Alerte phishing traitée en 2 minutes.
1. Contexte : e-mail suspect signalé.
2. Enrichissement automatique : réputation des IOC, verdict sandbox.
3. Classification automatique : score et proposition d'action.
4. Action graduée : blocage si score élevé, ticket créé, analyste notifié pour contrôle. La progressivité de la leçon : d'abord enrichir, puis filtrer, et enfin contenir — uniquement les cas simples et bien définis.

💡 Règle d'or

L'automatisation doit être progressive. Commencez par l'enrichissement, puis le filtrage, et enfin les actions de containment pour les cas simples et bien définis.

Pièges classiques : Tout automatiser d'un coup (le containment automatique transforme une erreur en panne) ; intégrer des API sans monitoring (le workflow casse en silence) ; automatiser un processus pourri (on industrialise le chaos) ; supprimer l'humain de la boucle (plus personne pour arrêter la machine).

À vous de jouer : Un blocage automatique d'IP a isolé le serveur de paie en pleine journée. Quelle leçon en tirez-vous ?
Voir la réponse
Gradualisme et garde-fous : allowlist des actifs critiques, mode « proposer » avant « bloquer », périmètre limité au démarrage, humain dans la boucle. L'automatisation sans garde-fou transforme une erreur de détection en incident de production. Si votre réponse cite allowlist et progressivité, elle est complète.
07 Exemple : Playbook Phishing Avancé 45 min ▸
Playbook complet pour un phishing avancé (spear phishing) :

Pourquoi c'est important : Le spear phishing — ciblé, personnalisé, soigné — est la porte d'entrée des attaquants avancés, et sa réponse ne s'improvise pas : neuf étapes, de la vérification de la réputation à la notification, en passant par la chasse aux autres destinataires et la vérification des clics. Ce playbook est le plus exécuté des SOC : le connaître par cœur, c'est être opérationnel.

L'analogie qui aide : Pensez au déminage : procédure stricte, gestes dans l'ordre, aucun improvisé — chaque écart peut tout faire sauter. Le playbook phishing avancé, c'est la procédure de déminage du SOC : on suit les neuf étapes, sans en sauter.
- 1. Vérifier reputation source (IP, domaine, enveloppe)
- 2. Analyser attachment (sandbox, VirusTotal)
- 3. Extraire IOCs (URL, hash, IPs contacted)
- 4. Rechercher dans SIEM : emails similaires envoyés
- 5. Identifier les utilisateurs exposés
- 6. Containment : Supprimer emails + bloquer IOCs
- 7. Vérifier clics : Proxy logs, EDR logs
- 8. Si clic confirmé : Isolation endpoint, reset MDP
- 9. Notification interne + documentation
Démonstration pas à pas : Spear phishing contre un dirigeant, en récit.
1. Contexte : e-mail ciblé, expéditeur usurpé, prétexte crédible.
2. Enrichissement : réputation source, pièce jointe en sandbox et sur VirusTotal, extraction des IOC.
3. Classification : spear avéré, haute sévérité.
4. Action : recherche des e-mails similaires, identification des exposés, suppression et blocage, vérification des clics (proxy, EDR), isolation et réinitialisation si clic, notification, documentation. Chaque étape de la leçon devient un geste, dans l'ordre.

Pièges classiques : Analyser la pièce jointe sur son propre poste (l'analyste s'infecte) ; prévenir les utilisateurs avant de mesurer l'étendue (l'attaquant est alerté, les preuves bougent) ; oublier les règles de boîte mail (la persistance par transfert survit au nettoyage) ; négliger les clics depuis mobile (hors proxy d'entreprise).

À vous de jouer : Après un spear phishing, vous découvrez une règle de transfert automatique vers l'externe sur la boîte du dirigeant. Qu'en déduisez-vous ?
Voir la réponse
Une persistance probable post-compromission : l'attaquant siphonne les e-mails en continu. On traite une compromission avérée — réinitialisation, révocation des sessions, audit des messages transférés, recherche d'autres accès. Si vous avez lu « règle de transfert égale persistance », votre lecture est excellente.
08 Exemple : Playbook Ransomware 50 min ▸
Réponse à une infection ransomware active :

Pourquoi c'est important : Face à un ransomware actif, les minutes comptent et certaines erreurs sont irréversibles : sauvegardes chiffrées, mémoire volatile perdue, rançon payée sans cadre. Ce playbook — containment immédiat, identification, vérification de propagation, préservation des logs, évaluation, notifications, recovery, post-mortem — doit être connu avant le jour J. On ne lit pas la procédure pendant l'incendie.

L'analogie qui aide : Pensez à l'incendie : couper le gaz (isoler), évacuer (protéger), ne pas rouvrir la porte (pas de retour en arrière), ne pas négocier seul avec le feu (management et juridique décident). Les pompiers n'improvisent pas : ils appliquent. Le playbook ransomware, c'est la procédure feu du SOC.
- 1. Containment IMMÉDIAT : Isolation réseau machine(s) infectée(s)
- 2. Identifier le variant ransomware (chaîne de ransom)
- 3. Vérifier propagation : scanners réseau, EDR
- 4. Sauvegarder les logs pour investigation
- 5. Arrêter le chiffrement si possible (kill process)
- 6. Évaluer l'étendue des dégâts
- 7. Notification management + équipe juridique
- 8. Plan de recovery depuis backups
- 9. Post-mortem complet
Démonstration pas à pas : Les dix premières minutes, minute par minute.
1. Minutes 0 à 2, contexte et containment : isoler via l'EDR, stopper la propagation.
2. Minutes 2 à 5, enrichissement : identifier le variant, mesurer l'étendue avec scanners et EDR.
3. Minutes 5 à 7, préservation : sauvegarder logs et dump mémoire avant toute extinction.
4. Minutes 7 à 10, escalade et suite : management, juridique, puis recovery depuis backups sains et post-mortem. Et les deux interdits de la leçon : jamais de rançon sans accord du management et du juridique, jamais d'extinction sans préservation de la mémoire.

❌ Ne JAMAIS faire

Ne jamais payer la rançon sans accord du management et de la direction juridique. Ne jamais éteindre la machine infectée sans préserver les logs en mémoire.

Pièges classiques : Payer la rançon sans cadre (financement du crime, aucune garantie, cadre légal) ; éteindre sans dump mémoire (preuves et clés volatiles perdues) ; brancher les backups sur le réseau infecté (sauvegardes chiffrées à leur tour) ; négocier seul ; restaurer sans avoir fermé la porte d'entrée.

À vous de jouer : Les sauvegardes, restées connectées au réseau, ont été chiffrées avec le reste. Quelle faute, et quelle parade ?
Voir la réponse
La faute : des backups dans la même zone de risque que la production (en ligne, accessibles). La parade : règle du 3-2-1, copies hors ligne ou immuables, et tests de restauration réguliers. Si votre réponse cite le hors-ligne et l'immuable, elle est juste.

Métriques & KPI SOC

09 KPI essentiels du SOC 40 min ▸
Les KPI les plus importants à suivre :

Pourquoi c'est important : On ne pilote que ce que l'on mesure : MTTD, MTTR, MTTC, taux de faux positifs, volume d'alertes, utilisation des analystes, couverture des sources — ces KPI disent si le SOC détecte vite, répond bien et voit large. Ils justifient aussi les budgets auprès de la direction. Un futur manager qui ne parle pas KPI ne sera pas écouté.

L'analogie qui aide : Pensez au tableau de bord d'une voiture : vitesse, carburant, voyants — on ne pilote pas à l'aveugle ni au bruit du moteur. Ou aux constantes d'un patient : pouls, tension, température. Les KPI, ce sont les constantes du SOC : ils disent s'il est en bonne santé.
- MTTD (Mean Time to Detect) : Temps moyen de détection d'un incident
- MTTR (Mean Time to Respond) : Temps moyen de réponse
- MTTC (Mean Time to Contain) : Temps moyen de containment
- False Positive Rate : Pourcentage de faux positifs
- Alert Volume : Nombre d'alertes par jour/semaine
- Analyst Utilization Rate : Capacité utilisée de l'équipe
- Coverage : % de log sources intégrées au SIEM
Démonstration pas à pas : Lecture d'un mois d'activité.
1. Contexte : MTTD 12 minutes, MTTR 40 minutes, MTTC 1h10, faux positifs 35 %, couverture 60 % des sources.
2. Enrichissement : détection correcte mais lente, FP trop élevés, angle mort de 40 % des sources.
3. Classification : SOC qui voit mal et qui fatigue ses analystes.
4. Action : tuning des règles, nouveaux use cases, plan de raccordement des sources. Un KPI sans lecture ni plan d'action ne sert à rien.

Pièges classiques : Les vanity metrics (alertes clôturées : gonflables à volonté) ; optimiser le MTTR en clôturant vite (tricher avec le thermomètre) ; comparer des SOC différents (contextes incomparables) ; publier des KPI sans cible ni plan d'action.

À vous de jouer : MTTD de 2 minutes mais MTTR de 3 jours. Votre diagnostic ?
Voir la réponse
Détection excellente, réponse bloquée : le goulot est en aval — sous-effectif, escalade grippée, processus lourd ou astreinte absente. Il faut renforcer l'aval (L2, astreinte, playbooks), pas la détection. Si vous avez situé le goulot après la détection, votre diagnostic est juste.
10 Dashboards et reporting 45 min ▸
Tableaux de bord essentiels :

Pourquoi c'est important : Le bon graphe à la bonne personne : l'analyste a besoin de la file temps réel, le manager des tendances, la direction des risques et de la conformité. Un dashboard opérationnel, un stratégique, un de conformité, un de couverture MITRE — quatre vues, quatre usages. Sans reporting adapté, le SOC travaille bien mais personne ne le sait (ni ne le finance).

L'analogie qui aide : Pensez au cockpit de l'avion contre l'écran du passager : mêmes données de vol, deux présentations — technique et temps réel pour le pilote, trajet simplifié pour le passager. Le dashboard SOC, c'est pareil : la vue dépend du siège.
- Dashboard Opérationnel : Alertes en cours, workload par analyste
- Dashboard Stratégique : Tendances, évolution des métriques
- Dashboard Conformité : Couverture des logs, comply aux normes
- Tableau de bord MITRE : Couverture par technique ATT&CK
Démonstration pas à pas : Mêmes données, trois vues.
1. Contexte : un mois d'alertes, d'incidents et de métriques.
2. Enrichissement : vue analyste (file temps réel, charge par analyste), vue manager (tendances MTTD/MTTR, faux positifs), vue direction (risques, couverture, conformité).
3. Classification : chaque vue répond à sa question — que faire, où investir, sommes-nous couverts.
4. Action : on ne construit une vue que pour une décision. La règle : une vue, un public, une décision.

Pièges classiques : Le dashboard spaghetti (40 graphiques, pour personne) ; des chiffres faux mais beaux (requêtes jamais validées) ; le dashboard décoratif que personne ne consulte ; du temps réel partout (coûteux et inutile en stratégique).

À vous de jouer : Un dashboard de 40 graphiques que personne n'ouvre. Diagnostic et remède ?
Voir la réponse
Pas de question métier derrière les graphiques : on repart des décisions (qui décide quoi ?) et on construit une vue par rôle, cinq à sept indicateurs maximum, sur des données validées. Si votre remède propose moins d'indicateurs mais utiles, il est bon.
11 Amélioration continue du SOC 40 min ▸
Le cycle PDCA (Plan-Do-Check-Act) appliqué au SOC :

Pourquoi c'est important : Les attaquants évoluent ; un SOC qui n'apprend pas régresse. Le cycle PDCA (Plan-Do-Check-Act) appliqué au SOC — revues mensuelles, lessons learned, exercices tabletop et red/blue team, veille IOC et ATT&CK, formation continue — transforme chaque incident en progrès. L'amélioration continue, c'est l'écart entre un SOC vivant et un SOC en routine.

L'analogie qui aide : Pensez au sportif qui revoit ses matchs : débrief à froid, correction des gestes, entraînement ciblé, puis nouveau match. Ou au jardinier : on taille les règles qui dépassent, on plante de nouvelles détections, on arrache les mauvaises herbes. Le SOC s'entretient comme un jardin.
- Revue mensuelle : Analyse des alertes, tuning des règles
- Lessons Learned : Après chaque incident majeur
- Exercices : Tabletop exercises, red team / blue team
- Veille : Mise à jour des IOCs, nouvelles techniques ATT&CK
- Formation : Certification continue, CTF internes
Démonstration pas à pas : Lessons learned d'un phishing réel.
1. Contexte : clic, deux heures de latence de détection.
2. Enrichissement : trois actions décidées — règle de filtrage tunée, logs manquants raccordés, sensibilisation ciblée — chacune avec responsable et date.
3. Classification : boucle à fermer.
4. Action et vérification : un mois après, attaque rejouée et détectée en 5 minutes. Sans la vérification, les lessons learned ne sont que des vœux : pas de boucle fermée, pas de progrès.

Pièges classiques : Le post-mortem punitif (après ça, plus personne ne parle) ; les actions sans propriétaire ni date (vœux pieux) ; les exercices annoncés et truqués (théâtre) ; la veille sans intégration (on lit, on n'applique jamais).

À vous de jouer : Même incident, même cause, trois mois après. Où est l'échec ?
Voir la réponse
Dans la boucle non fermée : lessons écrites mais actions non suivies — pas de propriétaire, pas d'échéance, pas de vérification. L'échec est organisationnel, pas technique. Si vous avez pointé le suivi plutôt que l'outil, votre lecture est mature.

Threat Hunting

12 Introduction au Threat Hunting 45 min ▸
Le Threat Hunting est une approche proactive de détection :

Pourquoi c'est important : Le threat hunting part d'un principe sain : les défenses automatiques ont raté quelque chose, cherchons-le avant l'attaquant. Hypothèses fondées sur la TI et MITRE, données SIEM/EDR/réseau, techniques par IOC, TTP et anomalies, boucle hypothèse-collecte-analyse-découverte-amélioration : c'est la posture proactive qui distingue le L3. Le hunting trouve aujourd'hui ce que les règles détecteront demain.

L'analogie qui aide : Pensez au garde-chasse : aucune alarme ne sonne en forêt, il lit les indices — empreintes, branches brisées, restes de feu — et remonte la piste. Ou au contrôle fiscal ciblé : on ne contrôle pas au hasard, on va où les signaux sentent. Le hunter ne subit pas les alertes : il va chercher.
- Hypothèses : Basées sur TI, MITRE, ou observations
- Data : Logs SIEM, EDR, network traffic
- Techniques : Recherche par IOCs, TTPs, anomalies
- Outils : SIEM (SPL/KQL), Jupyter, RITA, Sigma rules
- Boucle : Hypothèse → Collecte → Analyse → Découverte → Amélioration
Démonstration pas à pas : Hypothèse « PsExec abusé pour mouvement latéral ».
1. Contexte et données : logs SIEM et EDR sur 30 jours.
2. Enrichissement : créations de services croisées avec les ouvertures de session, usages administrateurs connus exclus.
3. Classification : deux hôtes suspects hors processus admin — découverte.
4. Action et amélioration : nouvelle règle de détection et IOC diffusés. La boucle vertueuse : hypothèse, collecte, analyse, découverte, amélioration. Et le principe de la leçon : on cherche ce que les outils automatiques ne détectent pas.

🎯 Principe fondamental

Le threat hunting part du principe que les défenses existantes ont échoué. On cherche ce que les outils automatiques ne détectent pas.

Pièges classiques : Chasser sans hypothèse (pêche au hasard) ; chasser sans accès aux données (le gap rend la chasse impossible) ; ne jamais convertir la découverte en détection (la chasse ne sert qu'une fois) ; lancer des requêtes lourdes en production (impact sur le SIEM).

À vous de jouer : Quelle est la différence entre le triage d'alerte et le threat hunting ?
Voir la réponse
Le triage est réactif : l'alerte existe, on la qualifie. Le hunting est proactif : aucune alerte, on cherche ce que l'automatique rate, guidé par des hypothèses. Si votre réponse oppose réactif et proactif, elle est juste.
13 Hypothèses de chasse 40 min ▸
Comment formuler des hypothèses de chasse efficaces :

Pourquoi c'est important : Une bonne hypothèse fait une bonne chasse : testable, bornée, falsifiable. Les quatre familles — TTP, IOC, comportementale, données — couvrent tous les points de départ, du bulletin TI au gap de collecte. Formuler des hypothèses précises, c'est passer du « on va regarder les logs » au « on va vérifier ceci, ainsi, et conclure cela ». C'est l'acte fondateur du hunter.

L'analogie qui aide : Pensez à l'enquêteur et ses pistes : chaque piste est vérifiable — un alibi se contrôle, une empreinte se compare. On ne suit pas une « impression », on teste une piste. L'hypothèse de chasse, c'est la piste de l'enquêteur : si on ne peut pas la tester, ce n'en est pas une.
- TTP-based : "Un attaquant utilise PowerShell pour la persistence"
- IOC-based : "Une campagne cible notre secteur avec ces domaines C2"
- Behavior-based : "Un utilisateur accède à des ressources inhabituelles"
- Data-based : "Nous avons un gap dans la collecte de logs réseau"
Démonstration pas à pas : Un bulletin TI devient deux chasses.
1. Contexte : campagne documentée avec TTP connues.
2. Enrichissement : hypothèse TTP (« l'acteur utilise BITSAdmin pour télécharger ») testée sur les créations de processus, et hypothèse comportementale (« comptes de service actifs la nuit ») testée sur les ouvertures de session.
3. Classification : chasses bornées à 30 jours, critères de conclusion écrits d'avance.
4. Action : résultats documentés, positifs ou négatifs — une hypothèse infirmée est aussi un résultat. La règle : testable, bornée, falsifiable.

Pièges classiques : Les hypothèses intestables (« les APT nous visent ») ; trop larges (tout le SIEM pendant un an) ; le biais de confirmation (ne chercher que ce qui confirme) ; les hypothèses sans données disponibles (impossibles à tester).

À vous de jouer : Formulez une hypothèse TTP-based testable sur l'outil BITSAdmin.
Voir la réponse
Exemple valide : « un attaquant utilise BITSAdmin pour télécharger un payload : on cherchera les exécutions de bitsadmin.exe avec transfert vers l'externe sur 30 jours, en excluant les usages administrateurs connus ». Testable, bornée, avec exclusions. Si la vôtre ressemble à cela, elle est validée.
14 Techniques de chasse avancées 55 min ▸
Techniques concrètes de threat hunting :

Pourquoi c'est important : Le hunter a sa boîte à outils : analytics DNS (domaines jeunes, DGA, entropie), détection de beaconing, usages Living-off-the-Land (PowerShell, WMI, Certutil), insider (volumes anormaux), mouvements latéraux (authentifications horizontales). Chaque technique a ses signaux et ses faux positifs connus. Les maîtriser, c'est pouvoir chasser sur tout le spectre.

L'analogie qui aide : Pensez au pistage : en forêt on lit les empreintes, en montagne les éboulis, au bord de l'eau les traces de passage — chaque milieu a ses indices. Le hunter lit le DNS comme le garde lit la boue : chaque source a ses traces.
- DNS Analytics : Requêtes DNS vers new domains, DGA, longueur anormale
- Beaconing Detection : Analyse de régularité dans les connexions sortantes
- Living-off-the-Land : Usage anormal de PowerShell, WMI, Certutil
- Insider Threat : Volume anormal de données transférées
- Lateral Movement : Corrélation des authentifications horizontales
Démonstration pas à pas : Chasse DNS au DGA.
1. Contexte et hypothèse : un générateur de domaines actif sur le parc.
2. Enrichissement : logs DNS sur 30 jours, filtres sur domaines jeunes, entropie élevée et rafales de NXDOMAIN.
3. Classification : un domaine suspect contacté par trois postes.
4. Action : règle de détection créée, domaine bloqué, postes investigués. Même patron pour chaque technique : hypothèse, données, filtres, vérification, conversion en détection.

Pièges classiques : Confondre DGA et CDN légitimes (faux positifs : prévoir l'allowlist) ; prendre un usage admin légitime pour du Living-off-the-Land malveillant (la baseline d'abord) ; lancer des requêtes lourdes en production ; chasser l'insider sans cadre légal et RH.

À vous de jouer : PowerShell avec option encodée s'exécute sur 50 postes en même temps : attaque ou administration ? Votre démarche ?
Voir la réponse
On vérifie d'abord : déploiement ou GPO légitime ? Même commande partout à la même heure évoque un outil d'administration (type SCCM). Commandes variées ou C2 derrière : incident. On ne conclut jamais sur le seul binaire : le contexte tranche. Si vous avez vérifié le déploiement avant de sonner l'alerte, votre démarche est mature.
15 Sigma Rules & Detection Engineering 50 min ▸
Sigma est le format open source de règles de détection :

Pourquoi c'est important : Sigma est l'espéranto des détections : un format ouvert, portable (Splunk, ELK, QRadar), partageable et versionnable. Écrire des règles Sigma — title, logsource, detection, condition — puis les convertir avec Sigma CLI, c'est faire du detection engineering moderne : reproductible, testé, collaboratif. Compétence rare, très demandée en entretien expert.

L'analogie qui aide : Pensez à la recette universelle : mêmes ingrédients et mêmes étapes, adaptables à chaque cuisine du monde. Sigma, c'est la recette de détection que chaque SIEM sait cuisiner dans sa langue.
- Portable : Convertible en Splunk, ELK, QRadar, etc.
- Structure : title, status, logsource, detection, condition
- Detection Engineering : Créer des règles de détection reproductibles
- Sigma CLI : Conversion automatique vers différentes cibles
Exemple de Sigma rule :
- title: Suspicious PowerShell Download
- logsource: category: process_creation
- detection: selection: Image|endswith: '\powershell.exe' Selection|contains: 'Invoke-WebRequest'
- condition: selection
Démonstration pas à pas : Lecture de la règle d'exemple, ligne par ligne.
1. Contexte (title) : l'intention — téléchargement suspect via PowerShell.
2. Enrichissement (logsource) : les données requises — créations de processus.
3. Classification (detection et condition) : Image se terminant par powershell.exe ET contenant Invoke-WebRequest.
4. Action : conversion vers la syntaxe cible (Sigma CLI), test sur historique, puis mise en production. La discipline : écrire, convertir, tester, déployer.

Pièges classiques : Déclarer une logsource sans disposer des données (règle aveugle) ; écrire une condition AND/OR fausse (silence total ou déluge) ; déployer sans test sur historique ; croire la conversion automatique magique (toujours vérifier la requête cible).

À vous de jouer : Écrivez l'intention (en français structuré) d'une règle « clé USB suivie de PowerShell suspect » : title, logsource, detection, condition.
Voir la réponse
Title : usage suspect de PowerShell après insertion USB. Logsource : créations de processus et journaux USB. Detection : séquence sur un même hôte et une fenêtre courte — insertion USB puis powershell avec commande encodée ou téléchargement. Condition : la séquence est vraie. Si votre intention enchaîne ces quatre rubriques, c'est une vraie règle Sigma en gestation.

SOC Operations Avancées

Corrélation SIEM Avancée

Playbook Development

💡 Règle d'or

❌ Ne JAMAIS faire

Métriques & KPI SOC

Threat Hunting

🎯 Principe fondamental