Incident Response Access Depends on the Compromised Identity Plane

Les outils et les ressources nécessaires pour répondre à un incident dépendent tous du même plan d’identité que l’incident peut avoir compromis : annuaire, fédération infonuagique, VPN, authentification multifacteur, postes administratifs, documentation, coffre de mots de passe et canaux de communication.

En exploitation normale, cette centralisation paraît propre et efficace. Quand l’intégrité de l’identité devient incertaine, elle transforme un seul problème en perte simultanée d’accès et de confiance. L’équipe doit alors utiliser des comptes qu’elle soupçonne, depuis des appareils qu’elle ne peut pas valider, pour atteindre des consoles qui doivent servir à reprendre le contrôle.

La réponse ralentit précisément lorsque chaque minute compte. Révoquer des sessions, isoler des machines ou recueillir des preuves peut devenir impossible sans réactiver des accès potentiellement compromis.

L’attaquant peut aussi observer les gestes de l’équipe, intercepter les nouveaux secrets, supprimer les accès des défenseurs ou se faire passer pour eux. Même la documentation du plan de réponse peut être inaccessible si elle vit uniquement dans l’environnement touché.

Ce pattern crée un paradoxe : pour reprendre confiance dans le système, il faut d’abord utiliser le système auquel on ne fait plus confiance.

• Tracer le parcours nécessaire pour accéder aux consoles d’identité, de sécurité, de réseau, de sauvegarde et d’infrastructure lors d’une compromission complète de l’annuaire.
• Demander où résident le plan de réponse, les coordonnées d’urgence, les procédures de récupération et les secrets d’administration.
• Vérifier si les comptes d’urgence, les facteurs d’authentification, les appareils et les canaux de communication sont réellement indépendants du plan principal.
• Tester un scénario simple : « L’annuaire et les postes administratifs sont non fiables. Pouvez-vous encore atteindre chaque console critique? »
• Si la réponse contient « on réactiverait probablement… », « on demanderait au même administrateur… » ou « le document est dans… », la dépendance existe probablement.

• Maintenir des identités d’urgence distinctes, fortement protégées et limitées aux consoles critiques.
• Conserver les procédures, contacts et informations minimales de récupération hors du plan de confiance principal, avec accès contrôlé et vérifié.
• Préparer des appareils administratifs propres ou une méthode documentée pour en établir rapidement.
• Éviter qu’un même fournisseur d’identité, appareil ou facteur soit l’unique chemin vers tous les outils de réponse.
• Tester au moins annuellement une perte simulée du plan d’identité, pas seulement la validité des mots de passe d’urgence.

• Présumer que les identités et appareils dépendant du plan compromis ne sont pas fiables jusqu’à validation.
• Établir un canal de coordination hors bande et un petit noyau d’identités propres.
• Accéder aux consoles critiques depuis des appareils connus comme sains; créer des accès temporaires directement auprès des plateformes lorsque c’est possible.
• Révoquer ou surveiller les anciennes sessions seulement après avoir sécurisé un chemin de retour fiable, afin de ne pas enfermer aussi les défenseurs dehors.
• Journaliser chaque nouvel accès créé, sa portée, son utilisateur et son retrait prévu.