Lacunes des playbooks d'incident

Le guide de réponse aux incidents d’un éditeur de logiciels pour la distribution consacré aux rançongiciels comptait trente-deux pages : il couvrait de manière exhaustive les phases de l’incident, les arbres de décision pour l’escalade, les modèles de communication et les procédures de rétablissement. Le guide avait été élaboré par l’équipe de sécurité avec la contribution des équipes d’exploitation, juridique et de communication, et il était revu chaque année. Lorsqu’un rançongiciel a été détecté un samedi à 2 h du matin, l’analyste d’astreinte a activé le guide et commencé à en exécuter les étapes. Les étapes un à trois étaient autonomes : elles décrivaient des actions que l’analyste pouvait mener directement. L’étape quatre, isoler les systèmes touchés, renvoyait à « la procédure d’isolement par segmentation réseau de l’annexe C ». L’annexe C était un document d’exploitation distinct, tenu par l’équipe d’ingénierie réseau dans son wiki interne. L’analyste d’astreinte n’avait pas accès au wiki de l’équipe réseau. L’analyste a appelé l’ingénieur réseau d’astreinte. Celui-ci devait accéder au wiki à distance. Le certificat de son client VPN avait expiré trois jours plus tôt. L’isolement réseau a été effectué trente-huit minutes après que le guide eut renvoyé l’analyste à l’étape quatre. Le rançongiciel avait continué à chiffrer pendant trente-huit minutes, le temps de retrouver la procédure. Le guide était exhaustif, revu et exact. Il renvoyait à une procédure qui n’était pas accessible aux personnes chargées de l’exécuter dans les circonstances créées par l’incident.

Que sont réellement les lacunes des guides de réponse aux incidents ?

Les lacunes des guides de réponse aux incidents sont les insuffisances des procédures de réponse propres à chaque scénario qui empêchent une exécution efficace dans des conditions d’incident réelles : lacunes d’exhaustivité, d’accessibilité, d’exactitude et de précision opérationnelle qui provoquent des retards, des erreurs ou des échecs lorsque les intervenants tentent d’exécuter le guide pendant un incident actif. Ces lacunes ne sont pas toujours visibles lors de l’examen documentaire : un guide bien rédigé qui renvoie à des procédures externes, contient des coordonnées obsolètes, décrit des actions exigeant des accès indisponibles pendant les incidents ou suppose des outils non déployés dans l’environnement touché peut sembler complet à l’examen tout en échouant à l’exécution.

Le problème de la dépendance aux renvois externes est la lacune des guides de réponse la plus critique sur le plan opérationnel. Les guides qui renvoient à des procédures, documents ou systèmes externes (« voir l’annexe C », « suivre la procédure de segmentation réseau », « consulter l’inventaire des actifs ») créent des dépendances à l’égard de ressources qui peuvent être inaccessibles pendant un incident, en particulier en dehors des heures ouvrées. Un guide n’est pas plus complet que sa dépendance externe la moins accessible. Une étape qui ne peut pas être exécutée parce que la procédure référencée est indisponible bloque toute la séquence du guide à cette étape.

Le problème des coordonnées obsolètes est la lacune secondaire. Les playbooks qui contiennent des coordonnées (contacts d’escalade, lignes d’urgence des fournisseurs, adresses de notification réglementaire) doivent être mis à jour régulièrement à mesure que le personnel change, que les rôles évoluent et que les coordonnées sont modifiées. La revue annuelle peut mettre à jour le texte du playbook mais omettre des coordonnées précises intégrées dans des modèles ou des annexes. Un appel d’escalade qui aboutit à un numéro hors service ou à un employé parti retarde l’escalade précisément au moment où la rapidité compte le plus.

Le problème des hypothèses sur les outils et les accès crée une troisième catégorie de lacunes des guides de réponse. Les guides élaborés par des ingénieurs sécurité qui disposent d’un accès complet aux outils peuvent décrire des actions exigeant un accès à des outils, des identifiants ou des autorisations système précis dont l’intervenant d’astreinte ne dispose pas, qu’il soit junior, situé ailleurs ou qu’il utilise un appareil personnel. Une action qui exige un accès console à un système précis, une authentification auprès d’un outil précis ou un identifiant précis conservé dans un coffre-fort exigeant sa propre chaîne d’authentification crée un obstacle à l’exécution que le processus d’élaboration du guide n’avait pas anticipé.

• Renvois à des procédures externes : l’annexe C dans le wiki inaccessible d’une autre équipe
• Coordonnées obsolètes : changements de personnel qui rendent les contacts d’escalade invalides
• Hypothèses sur les outils et les accès : actions du playbook nécessitant des identifiants ou des accès dont l’intervenant d’astreinte ne dispose pas
• Défaillances du VPN et des outils d’accès : certificat expiré ou infrastructure d’accès indisponible pendant les incidents
• Revue annuelle confirmant l’actualité du guide sans tester son exécutabilité dans des conditions d’incident

Pourquoi c’est important

Les lacunes des playbooks d’incident comptent pour la TPRM, car la qualité de la réponse d’un fournisseur à une violation touchant les données des clients dépend de l’efficacité avec laquelle ses playbooks s’exécutent dans les conditions réelles d’un incident, qui peuvent être 2 h du matin un samedi, avec un analyste d’astreinte sur son appareil personnel, sans accès au wiki de l’équipe réseau. Un playbook bien revu qui ne peut être exécuté sans outils, accès ou documents externes indisponibles pendant les incidents n’est pas un playbook fonctionnel pour ces incidents.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à assimiler l’exhaustivité d’un guide de réponse à son opérabilité. Un guide exhaustif qui renvoie à des procédures externes indisponibles est complet sur le papier et incomplet à l’exécution. Les tests d’opérabilité, qui consistent à dérouler le guide dans des conditions d’incident simulé, révèlent les lacunes que l’examen documentaire ne peut pas révéler.

• Exhaustivité du guide de réponse assimilée à son opérabilité
• Accessibilité des références à des procédures externes non validée
• Coordonnées non testées : aucun appel passé pour confirmer que les contacts sont à jour
• Hypothèses sur les outils et les accès non validées : accès des intervenants aux systèmes requis non confirmé
• Aucun test d’opérabilité : aucun déroulement du guide dans des conditions d’incident simulé

À quoi ressemblent les bonnes pratiques

Les programmes de playbooks matures réalisent des tests d’opérabilité annuels, en déroulant les playbooks critiques dans des conditions d’incident simulées, avec les intervenants qui les exécuteraient réellement et les accès dont ils disposeraient lors d’un véritable incident, et corrigent les lacunes révélées par ces tests avant que des incidents ne les rendent nécessaires.

• Test annuel d’opérabilité : déroulé du playbook par les intervenants d’astreinte, avec l’accès disponible en situation d’incident
• Références externes intégrées : les procédures critiques figurent dans le playbook, pas seulement par renvoi
• Coordonnées testées : appels d’escalade effectués pour confirmer que les contacts sont à jour et joignables
• Accès aux outils validé : accès de l’intervenant d’astreinte à tous les outils requis confirmé
• Lacunes des guides de réponse suivies et corrigées : constats des tests d’opérabilité intégrés à un carnet de mesures correctives

Outils

Gestion des guides de réponse : Confluence, outils dédiés aux guides IR, PagerDuty Runbooks

Les plateformes dédiées à la gestion des procédures opérationnelles et des guides de réponse fournissent des procédures autonomes et exécutables qui ne nécessitent pas d’accès à des documents externes ni à des wikis. Pour les praticiens de la TPRM, demander si les guides de réponse aux incidents critiques sont autonomes, avec toutes les procédures référencées intégrées plutôt que liées, ou s’ils dépendent de documents externes constitue une question précise sur l’opérabilité.

Enjeux de gouvernance

Le défi de gouvernance de l’opérabilité des guides de réponse est la charge de maintenance. Les guides autonomes qui intègrent toutes les procédures auxquelles ils renvoient sont plus difficiles à tenir à jour que les guides modulaires comportant des renvois externes : lorsqu’une procédure change, un guide autonome doit être mis à jour partout où la procédure est intégrée. La solution de gouvernance consiste à identifier les étapes du chemin critique de chaque guide, celles où un retard a les conséquences les plus graves, et à faire en sorte que ces étapes soient entièrement autonomes, les étapes moins critiques pouvant renvoyer à des documents externes.

• Tester l’opérabilité du playbook chaque année : intervenants d’astreinte, avec l’accès disponible en situation d’incident
• Intégrer les procédures du chemin critique : les étapes dont le retard aurait les conséquences les plus graves doivent être autonomes
• Tester tous les contacts d’escalade : appels effectivement passés, sans présumer qu’ils sont à jour
• Valider l’accès des intervenants aux outils, en particulier en dehors des heures ouvrées et depuis un appareil personnel
• Suivre les lacunes d’opérabilité dans un carnet de mesures correctives, avec responsables et échéances

Si vous êtes une petite équipe

Choisissez votre guide de réponse le plus critique (celui consacré aux rançongiciels est généralement le bon choix) et déroulez-le un vendredi à 14 h, en guise de vérification d’opérabilité de trente minutes. Pour chaque étape qui renvoie à un document situé dans un autre système, vérifiez que l’analyste d’astreinte a accès à ce système et peut récupérer le document en moins de deux minutes. Pour chaque contact d’escalade du guide, vérifiez que le contact est à jour en l’appelant. Pour chaque outil requis par le guide, vérifiez que l’analyste d’astreinte y a accès et dispose des identifiants. Cette vérification de trente minutes le vendredi révélera les lacunes avant l’incident du samedi à 2 h du matin qui en dépendra.

• Dérouler le guide de réponse aux rançongiciels en guise de vérification d’opérabilité de trente minutes le vendredi
• Confirmer l’accès à chaque procédure externe référencée
• Appeler chaque contact d’escalade pour confirmer qu’il est à jour
• Confirmer l’accès de l’analyste d’astreinte aux outils

Ce qu’il faut exiger

Demandez directement :

« Pour votre guide de réponse aux rançongiciels, avez-vous réalisé au cours des douze derniers mois un test d’opérabilité au cours duquel les intervenants d’astreinte ont déroulé le guide avec les accès et les outils dont ils disposeraient réellement lors d’un incident à 2 h du matin, et quelles lacunes ont été identifiées et résolues ? »

Preuves attendues

• Date et méthode du test d’opérabilité
• Lacunes identifiées lors des tests d’opérabilité
• Correction des lacunes identifiées
• Conception des procédures : autonomes ou par renvoi externe

Un fournisseur qui confirme disposer de playbooks complets contre les rançongiciels doit être interrogé sur le test d’opérabilité. L’exhaustivité est l’indicateur de qualité du document. L’opérabilité est l’indicateur de qualité de l’exécution. Le scénario du samedi à 2 h du matin est le test qui révèle la différence.

Comment le prouver

• Registres des tests d’opérabilité
• Registres d’identification et de correction des lacunes
• Registres des tests des coordonnées
• Registres de validation des accès aux outils

À retenir

Étape quatre : isoler selon l’annexe C. Annexe C : wiki de l’équipe réseau. Wiki : nécessite le VPN. Certificat VPN : expiré depuis trois jours. Trente-huit minutes plus tard : isolement exécuté. Quarante minutes de chiffrement pendant une étape que le playbook décrivait correctement mais qui ne pouvait pas être exécutée. Le playbook était complet. Le test d’opérabilité qui aurait révélé la dépendance au certificat VPN n’a pas été réalisé. Le test d’opérabilité est la vérification annuelle de trente minutes, un vendredi, qui pose la question : l’analyste d’astreinte peut-il exécuter cette étape à 2 h du matin un samedi avec les accès dont il dispose réellement ? La revue annuelle confirme que le playbook est à jour. Le test d’opérabilité confirme qu’il peut être exécuté.