Recovery Begins Before Persistence Is Eliminated

La pression de reprendre les opérations déclenche la restauration avant que l’accès initial, les mécanismes de persistance et l’étendue de la compromission aient été suffisamment compris et traités.

Les sauvegardes sont disponibles, les dirigeants veulent redémarrer et les systèmes visibles ont été nettoyés. Cette combinaison donne une impression de progrès. Pourtant, des identités compromises, des sessions actives, des clés, des tâches planifiées, des appareils oubliés, des accès distants ou des modifications infonuagiques peuvent encore permettre le retour de l’attaquant.

La reprise reconnecte des systèmes propres à un environnement qui ne l’est peut-être pas. Elle offre de nouvelles cibles, restaure parfois des configurations vulnérables et révèle à l’attaquant que l’organisation est en train de reconstruire.

Le résultat peut être une seconde compromission, une seconde exfiltration ou un nouveau chiffrement, souvent plus coûteux que le premier parce que les sauvegardes, les équipes et la confiance des décideurs ont déjà été entamées.

« L’EDR ne voit plus rien » n’est pas un critère d’autorisation de reprise. C’est une observation parmi plusieurs.

• Demander quelle preuve objective doit exister avant qu’un système puisse être restauré ou reconnecté.
• Vérifier si les critères couvrent l’accès initial, la persistance, les identités, les sessions, le réseau, les consoles d’administration et les actifs inconnus.
• Examiner qui possède l’autorité de reprise et si cette personne reçoit un état clair des risques résiduels.
• Chercher dans les plans une séparation réelle entre confinement, éradication et reprise.
• Vérifier si la pression opérationnelle peut contourner les critères sans acceptation formelle du risque.

• Définir des critères de sortie pour le confinement et l’éradication avant les critères techniques de restauration.
• Exiger une autorisation conjointe des responsables opérationnels et de la réponse à incident pour reconnecter les services critiques.
• Préparer des vagues de reprise : identité et administration, services de base, applications prioritaires, puis reste de l’environnement.
• Prévoir un environnement de restauration isolé où les systèmes peuvent être validés avant reconnexion.
• Documenter les dépendances, les contrôles de surveillance renforcée et un mécanisme de retour arrière.
• Tester le plan avec un scénario où la première restauration doit être suspendue à cause d’un nouvel indicateur.

• Suspendre les restaurations non essentielles tant que les principaux chemins de retour n’ont pas été évalués.
• Établir des critères écrits, même simples, pour chaque vague : secrets renouvelés, persistance recherchée, sources de journaux actives, actifs critiques validés et approbation obtenue.
• Restaurer dans un segment isolé, avec surveillance renforcée et communications strictement nécessaires.
• Faire la rotation des identités et secrets depuis une infrastructure saine avant de les réutiliser.
• Si la reprise doit commencer malgré une incertitude, faire accepter et consigner explicitement le risque résiduel; surveiller comme si une réintrusion était attendue.