Un seul format pour passer de l’alerte à une décision explicite, sans perdre les preuves.
À utiliser pendant l’investigation et lors du handover vers CSIRT, IT ou l’astreinte.
Une escalade SOC échoue souvent pour une raison simple : on remédie trop tôt, et on perd les éléments qui permettaient de comprendre.
Cette fiche vous force à transmettre 3 choses, dans un ordre stable : les faits (preuves), une hypothèse courte, puis la prochaine action avec son impact.
Le mécanisme est volontairement minimal : figer la chronologie, définir le périmètre, comparer des options de confinement, décider.
Point de repère : NIST SP 800-61 Rev. 3 recommande de préserver les faits nécessaires, définir le périmètre, choisir une action réversible et documenter l’impact opérationnel (source : https://csrc.nist.gov/pubs/sp/800/61/r3/final).
##Ce que votre escalade doit contenir (sinon, elle repart en questions)
- -Une chronologie figée (horodatages, sources, trous de logs)
- -Les preuves disponibles et leur emplacement (sans les altérer)
- -Le périmètre : actifs, comptes, dépendances touchés ou suspectés
- -Une hypothèse de travail + ce qui la confirme / l’infirme
- -Trois options : contenir maintenant, surveiller sous contrôle, ou différer avec justification
- -Une prochaine action unique, réversible si possible, avec un propriétaire et une heure
- -L’impact opérationnel attendu (même si c’est une estimation prudente)
##Chemin opérationnel (alerte → escalade prête à envoyer)
##Worksheet : escalade SOC en 7 champs (à remplir dans cet ordre)
Groupe 1 : 1) Chronologie (à figer)
- ->Heure de détection et heure de début estimée (si connue)
- ->Source(s) : SIEM, EDR, firewall, proxy, IAM, email, etc.
- ->Événements clés (3 à 10 lignes) + les trous de logs constatés
- ->Ce qui a déjà été fait (même « rien ») et par qui
Groupe 2 : 2) Preuves à collecter / préserver (avant remédiation)
- ->Figer la chronologie et les sources disponibles (ce qui existe maintenant)
- ->Identifier actifs, comptes et dépendances touchés (ou corrélés)
- ->Comparer options de confinement et conséquences (ce qui change la décision)
- ->Noter où sont stockées les preuves (lien, index, hôte, dossier, ticket)
Groupe 3 : 3) Périmètre (ce qui est touché vs suspecté)
- ->Actifs : hôtes, serveurs, applications, segments, SaaS concernés
- ->Comptes : humains, services, privilèges, tokens / sessions à risque
- ->Dépendances : AD/IAM, VPN, bastion, messagerie, CI/CD, sauvegardes
- ->Éléments explicitement hors périmètre (si justifié)
Groupe 4 : 4) Hypothèse (une phrase + tests)
- ->Hypothèse de travail (simple, falsifiable)
- ->Deux observations qui la confirment (ou la rendent plausible)
- ->Deux observations attendues si elle est fausse
- ->Prochain pivot d’investigation (source et filtre à utiliser)
Groupe 5 : 5) Décision et prochaine action (explicite)
- ->Choix : contenir maintenant / surveiller sous contrôle / différer
- ->Prochaine action unique et réversible si possible (verbe + cible)
- ->Propriétaire (nom/équipe) + heure limite + canal de suivi
- ->Impact opérationnel attendu (et comment le mesurer rapidement)
##Carte de contrôle : de l’alerte à la décision sans casser les preuves
Une vue « garde-fous » pour séparer collecte de preuves et remédiation, et rendre la décision traçable.
- ├─Créer un fil unique (ticket) et y centraliser horodatages et sources
- ├─Lister ce qui est disponible maintenant vs ce qui risque de disparaître
- └─Identifier tout changement en cours (patch, reboot, rotation de clés)
- ├─Isoler la collecte de preuves des actions de remédiation
- ├─Documenter l’emplacement exact des éléments (index, hôte, chemin)
- └─Tracer qui a accès et qui a manipulé quoi (pour éviter les doutes)
- ├─Lister actifs, comptes, dépendances touchés ou corrélés
- ├─Marquer les inconnues (ex : « logs VPN manquants ») et leur owner
- └─Définir une frontière de périmètre utilisable pour agir (même provisoire)
- ├─Contenir maintenant si le risque immédiat dépasse le coût opérationnel
- ├─Surveiller sous contrôle si vous pouvez limiter et mesurer le risque
- ├─Différer seulement avec justification, propriétaire, et prochaine heure de revue
- └─Documenter l’impact attendu et ce qui rend la décision réversible (si possible)
##Questions rapides (pour trancher sans débat)
Quelle observation permet de décider : contenir, surveiller, ou différer ?
Cherchez une observation qui change l’action : propagation active, privilèges élevés, exfiltration probable, ou au contraire un signal isolé et contrôlable. Si aucune observation ne change l’action, l’escalade doit demander une collecte ciblée (une seule).
Que veut dire « action réversible » dans ce contexte ?
Une action qui limite le risque sans détruire l’état utile à l’investigation. Exemple de logique : bloquer un compte ou un flux de manière contrôlée, plutôt que supprimer des fichiers ou réinstaller sans capture préalable.
Comment « figer la chronologie » quand tout bouge ?
Vous ne figez pas le monde. Vous figez votre récit : sources, horodatages, ce qui manque, et ce qui peut disparaître. Puis vous notez chaque changement (qui, quoi, quand) dans le ticket.
Que faut-il absolument écrire dans la prochaine action ?
Un verbe, une cible, un propriétaire, une heure, et un résultat attendu vérifiable. Sans ça, l’escalade est un échange d’opinions.
Quel est le piège le plus courant pendant l’escalade ?
Lancer une remédiation destructrice avant d’avoir collecté le minimum de preuves. Si quelqu’un pousse pour « nettoyer tout de suite », proposez : collecte minimale, puis action réversible, puis revue à heure fixe. Et notez tout changement dans le ticket.
Référence utilisée pour cadrer la méthode
Source officielle citée pour le principe : préserver les faits, cadrer le périmètre, choisir une action réversible et documenter l’impact.