Pre-Incident Planning: 5 Things to Document in an Incident Response Plan
Parce que le moment venu, vous n’aurez pas le temps de chercher ces informations.
La plupart des guides de préparation en cybersécurité informatique se concentrent sur ce qu’il faut faire une fois qu’une attaque a commencé. Isoler les appareils infectés. Contacter votre équipe de réponse aux incidents. Informer le service juridique. Ce sont d’excellents conseils, mais ils ne sont utiles que si vous savez déjà qui appeler, où sont stockées vos sauvegardes et quels systèmes sont indispensables à la survie de l’entreprise.
Le problème, c’est que les premières heures d’un incident de ransomware sont chaotiques. Des décisions qui devraient prendre quelques minutes prennent beaucoup plus de temps lorsque les informations nécessaires sont éparpillées dans des fils d’e-mails, dans la mémoire institutionnelle ou dans des systèmes qui peuvent désormais être inaccessibles. Ce n’est pas une défaillance technologique. C’est une défaillance de la documentation — et elle est entièrement évitable.
Ce qui suit n’est pas un plan de réponse aux incidents. Il s’agit de quelque chose de plus ciblé et immédiatement applicable : cinq catégories essentielles d’informations que votre équipe doit documenter et rendre accessibles avant qu’un incident ne survienne. Établir cette liste ne prendra pas longtemps. Ne pas l’avoir à disposition le moment venu vous coûtera bien plus de temps que vous n’en aurez économisé.
Lorsqu’un incident de sécurité survient, le premier réflexe est généralement de décrocher le téléphone. Le problème, c’est que de nombreuses équipes ne savent pas toujours qui elles doivent appeler.
Votre documentation d’escalade doit inclure les coordonnées de votre équipe de réponse aux incidents, des contacts principaux et de votre partenaire DFIR. Elle doit également préciser le processus d’engagement, les coordonnées de votre conseil juridique (ayant une expertise en protection des données), ainsi que le contact sinistres de votre assureur cyber, accompagné de votre numéro de police.
La documentation d’escalade doit contenir les contacts clés et les informations de police nécessaires en cas d’incident. Plus précisément, elle doit inclure :
Équipe de réponse aux incidents et responsables
Coordonnées de votre équipe interne de réponse aux incidents et de ses responsables
Partenaire DFIR
Coordonnées de votre partenaire en investigation numérique et réponse aux incidents (DFIR), y compris son processus d’engagement.
Conseil juridique
Coordonnées de votre conseil juridique externe, en veillant à ce qu’il dispose d’une expertise en protection des données.
Assurance cyber
Le contact pour les déclarations de sinistre de votre assureur cyber et votre numéro de police.
C’est souvent ce dernier point qui est négligé. Les polices de cyberassurance incluent généralement des délais de notification précis, et ne pas les respecter peut compliquer votre demande d’indemnisation au moment même où vous pouvez le moins vous permettre des complications. Connaître votre contact pour les sinistres ainsi que votre numéro de police avant qu’un incident ne survienne est indispensable.
Dernier point concernant l’assurance cyber : conservez votre police en lieu sûr et séparément de vos systèmes principaux. Des acteurs malveillants ayant passé du temps dans votre réseau avant de lancer le chiffrement peuvent avoir accès aux documents qui y sont stockés. Les informations relatives à votre police ne doivent pas être accessibles.
Quand tout s’accélère, vous ne voulez pas perdre de temps à chercher un numéro de téléphone.
Les acteurs malveillants ciblent les sauvegardes en premier. Ce n’est pas une supposition. C’est un schéma récurrent que DriveSavers a observé dans de nombreux incidents de ransomware. Avant de chiffrer les systèmes de production, les attaquants identifient et compromettent souvent l’infrastructure de sauvegarde afin d’éliminer la voie de récupération la plus directe pour la victime. Au moment où le chiffrement est lancé, les sauvegardes peuvent déjà avoir disparu.
Cela doit orienter votre réflexion sur la documentation des sauvegardes. Il ne suffit pas de savoir que des sauvegardes existent. Votre équipe doit être en mesure d’évaluer rapidement l’intégrité des sauvegardes en situation d’incident, ce qui implique que l’architecture soit suffisamment documentée pour permettre cette évaluation avant que quiconque ne soit sous pression.
Documentez l’emplacement des sauvegardes (sur site, hors site et dans le cloud), la manière dont les tâches de sauvegarde s’exécutent et selon quel calendrier, ainsi que les procédures de restauration étape par étape.
Considérez que vos sauvegardes peuvent être compromises tant que vous n’avez pas pu vérifier le contraire.
En cas d’incident de sécurité, vous ne pourrez pas tout restaurer en même temps. Les décisions concernant les priorités de restauration seront prises rapidement, sous pression, par des personnes qui auront peut-être très peu dormi. Ces décisions sont nettement plus efficaces lorsqu’elles sont prises à l’avance, sans pression.
Votre liste des données critiques doit identifier les systèmes sans lesquels l’entreprise ne peut pas fonctionner, les ensembles de données nécessaires aux opérations quotidiennes, ainsi qu’un ordre de priorité clair pour la restauration : indispensables versus secondaires.
Soyez honnête quant à ce dont l’entreprise dépend réellement par rapport à ce qui est simplement important. Cette lucidité est beaucoup plus difficile à trouver au cœur d’un incident actif. Donnez la priorité aux ensembles de données indispensables à restaurer avant de vous concentrer sur les éléments secondaires. Tout ne peut pas être rétabli en premier, et le savoir à l’avance constitue un avantage opérationnel majeur.
En cas d’incident de sécurité, la reprise ne consiste pas seulement à restaurer des données — il s’agit de restaurer les bonnes données en priorité.
En cas d’incident de sécurité, la reprise ne consiste pas seulement à restaurer des données — il s’agit de restaurer les bonnes données en priorité.
Dans la plupart des environnements d’une taille significative, l’infrastructure de sauvegarde s’étend sur plusieurs sites. La documentation relative aux responsabilités doit préciser qui est responsable de chaque environnement de sauvegarde, les identifiants d’accès aux sauvegardes, aux instantanés et aux réplicas, ainsi que l’emplacement des systèmes secondaires et des copies existantes.
Tenez compte du fait que les mêmes données existent souvent sous plusieurs formes : une sauvegarde principale, un instantané, une réplique, une copie archivée sur bande ou dans un environnement cloud secondaire. Lorsque les sauvegardes principales ont été compromises, savoir où chercher ailleurs peut faire une différence significative.
Une cartographie complète des responsabilités constitue, en pratique, une cartographie de votre surface de reprise. Plus elle est exhaustive avant un incident, plus vous disposerez d’options pendant celui-ci.
Les mêmes données existent souvent sous plusieurs formes. Savoir où chercher élargit les options de reprise.
La réussite de la reprise opérationnelle après une cyberattaque dépend en grande partie des fournisseurs qui assurent les produits et services soutenant votre infrastructure. Il est donc essentiel de documenter leurs circuits d’escalade et leurs canaux de support avant qu’un incident ne survienne.
La liste des contacts fournisseurs doit inclure les prestataires nécessaires au rétablissement des opérations essentielles, leurs canaux de support et circuits d’escalade, ainsi qu’un partenaire en récupération de données pour les situations où les sauvegardes et les outils de déchiffrement ont échoué.
Ce troisième point est celui que la plupart des organisations omettent complètement. L’échec des sauvegardes et l’échec des outils de déchiffrement ne sont pas des cas marginaux rares. Ce sont des issues réalistes d’une cyberattaque bien exécutée. Avoir un partenaire professionnel en récupération de données identifié et documenté avant un incident signifie que vous n’évaluez pas des prestataires au pire moment de l’année pour votre organisation. Cela signifie également que votre équipe de réponse à incident dispose d’une voie de récupération parallèle à poursuivre, plutôt que d’attendre un point de résolution unique.
Documenter ces relations à l’avance garantit que, lorsque la reprise commence, votre équipe exécute un plan — et ne cherche pas à en improviser un.


