Fiche SOC pour figer les preuves, cadrer le périmètre, puis décider : contenir, surveiller, ou différer
Objectif : éviter le “cleanup” trop tôt. Sortie attendue : une décision explicite, traçable, et des preuves conservées.
##Le problème à résoudre (sans perdre les faits)
Après une alerte et une première remédiation, la vraie question n’est pas “qu’est-ce qu’on a corrigé”, mais “qu’est-ce qui prouve que le mécanisme d’accès n’existe plus”.
Si vous remédiez trop tôt, vous effacez les artefacts qui permettent de comprendre le chemin d’accès, le périmètre, et le risque de retour.
Selon NIST SP 800-61 Rev. 3 (https://csrc.nist.gov/pubs/sp/800/61/r3/final), l’idée est de préserver les faits nécessaires, définir le périmètre, choisir une action réversible, et documenter l’impact opérationnel.
##À vérifier avant de “corriger plus”
- -Les sources de temps sont cohérentes (horodatages, fuseaux, dérive).
- -Vous avez une chronologie minimale, même incomplète, mais figée et exportée.
- -Le périmètre est explicite : actifs, comptes, et dépendances concernés (même provisoire).
- -Les actions déjà faites (scripts, suppression, reset) sont listées avec qui/quand/pourquoi.
- -Vous savez ce qui est réversible et ce qui est destructif (et donc à différer).
- -Une décision est nommée avec un propriétaire : contenir maintenant, surveiller sous contrôle, ou différer avec justification.
##Mécanisme unique : les 3 pivots, dans l’ordre
##Feuille de travail : preuves minimales à collecter (et à figer)
Groupe 1 : Chronologie (ce qui s’est passé, dans quel ordre)
- ->Figer la chronologie et les sources disponibles
- ->Lister les événements pivots : première alerte, premiers accès, premières actions humaines
- ->Noter les trous connus : périodes sans logs, hôtes non télémétrés, comptes non audités
Groupe 2 : Périmètre (où et avec quoi l’accès a été possible)
- ->Identifier actifs comptes et dépendances touchés
- ->Cartographier les relations utiles : compte → machine → service → données
- ->Distinguer “touché”, “suspect”, “non évalué” (et marquer ce qui manque)
Groupe 3 : Confinement / restauration (ce qui change l’état du système)
- ->Comparer options de confinement et conséquences
- ->Conserver la trace des actions : commande, outil, compte opérateur, fenêtre horaire
- ->Noter l’effet attendu : ce que l’action empêche, et ce qu’elle ne couvre pas
##Vue opérationnelle : du signal à la décision (et aux critères de sortie)
Lecture rapide pour piloter l’équipe : entrées minimales, décision explicite, sorties attendues, et garde-fous.
- ├─Alerte initiale + horodatage + source
- ├─Actifs/comptes cités par le signal (même partiel)
- └─Actions déjà réalisées (cleanup, blocage, reset, patch)
- ├─Contenir immédiatement si l’accès reste plausible ou si le périmètre est incertain
- ├─Surveiller sous contrôle si vous avez des critères clairs + une durée + un responsable
- └─Différer seulement avec justification écrite + propriétaire + condition de re-déclenchement
- ├─Une chronologie figée + exportée + référencée dans le ticket
- ├─Un périmètre daté (même provisoire) et une liste “non évalué” assumée
- └─Une action réversible choisie (ou un différé justifié) + impact opérationnel documenté
- ├─Ne pas lancer une remédiation destructrice avant d’avoir capturé les éléments nécessaires
- ├─Ne pas confondre “plus d’alerte” avec “mécanisme d’accès supprimé”
- └─Ne pas élargir le périmètre sans marquer ce qui est hypothèse vs observation
##Questions courtes qui débloquent la décision
Quelle observation me permet de décider : contenir, surveiller, ou différer ?
Décidez à partir de ce que vous pouvez soutenir par des faits figés (chronologie + périmètre) et par l’impact acceptable. Si le périmètre reste flou, privilégiez une action réversible et traçable.
Qu’est-ce qu’une action “réversible” dans ce contexte ?
Une action qui réduit le risque tout de suite sans détruire les preuves et sans vous enfermer. Exemple de logique : isoler, limiter, bloquer temporairement, plutôt que supprimer ou réinstaller sans capture préalable.
Que documenter pour que “plus tard” ce soit prouvable ?
Le pourquoi (hypothèse/risque), le quoi (périmètre daté), le comment (actions exactes), et le résultat attendu (critères de sortie). Si un point manque, marquez-le comme manquant plutôt que de le combler.
À quel moment je peux dire “le mécanisme d’accès a disparu” ?
Quand vous avez une chaîne logique : (1) périmètre explicite, (2) mécanisme probable adressé par une action documentée, (3) critères de sortie définis, (4) surveillance ou contrôles alignés sur ce mécanisme. Si l’un manque, formulez-le comme un risque résiduel.