Ransomware : s’y retrouver dans le processus de remédiation
Si des systèmes sont bloqués par un rançongiciel, à quoi convient-il de donner la priorité ? Ce plan aide à éviter des problèmes supplémentaires avant de lancer la remédiation.
Si vos défenses et vos sauvegardes échouent malgré tous vos efforts, la remédiation peut prendre différentes directions afin de ramener votre organisation à des conditions opérationnelles normales.
Les rançongiciels constituent déjà en eux-mêmes une plaie douloureuse. Alors mieux vaut ne pas se précipiter pour remonter systèmes et traitements affectés au risque de causer des problèmes additionnels. Dans une telle situation, le premier point à l’ordre du jour est d’établir un inventaire précis de ce qui fonctionne encore et de ce qui a besoin de réparations. Cela doit être fait rapidement, mais méticuleusement.
La direction voudra savoir ce qui doit être fait, mais il n’est pas possible de produire un rapport avant d’avoir bien compris la situation. Pour commencer, il faut penser à l’annuaire Active Directory, aux serveurs de fichiers, aux sauvegardes, à l’infrastructure réseau, à la messagerie électronique et aux systèmes de communication, ainsi qu’aux serveurs de production.
Faire le point sur la situation
La liste des machines virtuelles et des systèmes affectés ne sera pas exhaustive. Il faut commencer par ceux qui sont prioritaires, et les serveurs de production ne le sont pas dans ce cas. Si l’annuaire Active Directory est hors service, il y a fort à parier que la plupart des serveurs de production – et l’essentiel de l’infrastructure IT – ne fonctionneront pas correctement même si aucun impact direct n’a été observé.
Ensuite, il convient de vérifier l’état des sauvegardes. Trop de gens ont supprimé des machines virtuelles chiffrées pour découvrir ensuite que le maliciel avait anéanti les systèmes de sauvegarde… Des erreurs se produisent lorsque l’on se précipite.
Si les sauvegardes sont intactes, à jour et opérationnelles, il existe un moyen relativement facile de restaurer des serveurs. Mais le processus de restauration doit être testé avant tout chose. Plutôt que de supprimer les machines affectées, essayez de les relocaliser vers des systèmes de stockage secondaires, voire même un stockage externe ou les ressources locales d’un hôte. L’objectif est de supprimer les machines virtuelles chiffrées pour se donner de l’espace de travail, puis de tenter les restaurations et le redémarrage des machines virtuelles avant de supprimer leur équivalent chiffré.
Le temps de faire des choix difficiles
Si l’attaque a corrompu les systèmes de sauvegarde ou si l’effort de restauration a échoué, alors quelqu’un plus haut dans la hiérarchie devra prendre certaines décisions. Cela risque d’entraîner quelques conversations difficiles, en partie parce que la responsabilité des sauvegardes – et de leur fiabilité – reposait sur vous. Cela veut dire qu’il soit possible de rejeter sur la DSI la faute de l’impossibilité de les exploiter – le maliciel peut y être pour quelque chose, de même que les financements accordés. Ce sera une conversation à poursuivre plus tard. Mais à ce stade, il est temps de prendre une décision : payer la rançon, reconstruire les systèmes ou faire un rapport.
Cette dernière option nécessite la participation de la direction et de l’équipe juridique de l’entreprise. Si vous travaillez pour une entité régulée, vous avez peut-être des directives précises à suivre. Quoi qui soit dit, ce ne sera pas bien accueilli. Il faut être honnête avec ses clients, mais également être attentif et limiter l’étendue des informations communiquées publiquement.
Mais votre organisation n’a peut-être même pas été la cible véritablement visée, en particulier si elle a été touchée par une ancienne variante d’un ransomware. Si c’est le cas, il est possible qu’il existe un outil de déchiffrement. Pas d’illusion toutefois : c’est une hypothèse peu probable, mais qui vaut la peine d’être vérifiée avant de reconstruire à partir de zéro.
La plupart des organisations cèdent, sinon le modèle économique des ransomwares s’effondrerait.
Bien qu’amère, payer la rançon est aussi une option. Il convient de considérer combien il en coûtera pour reconstruire et récupérer, par rapport au paiement de la rançon. Ce n’est pas un choix facile à faire parce que le paiement n’offre aucune garantie. La plupart des entreprises qui paient la rançon ne le reconnaissent généralement pas, ni même qu’elles ont été attaquées. Je soupçonne que la plupart des organisations cèdent, sinon le modèle économique des ransomwares s’effondrerait.
Le défi de la reconstruction est l’effort à fournir. Relativement peu d’entreprises disposent de personnes qui comprennent parfaitement comment chaque aspect de leur environnement IT fonctionne. De nombreuses infrastructures informatiques sont le produit d’expertises internes combinées à des consultants externes.
Ceux qui installent des systèmes emportent souvent ces connaissances avec eux lorsqu’ils partent. Leurs remplaçants apprennent comment maintenir ces systèmes en production, mais c’est très différent de les installer ou de les reconstruire à partir de zéro. La réparation d’une infrastructure Active Directory est un défi, mais la reconstruire avec des milliers d’utilisateurs et de groupes avec des permissions issues de la documentation – disponible et complète, avec un peu de chance – est presque impossible à moins d’avoir beaucoup de temps et d’expertise.
Se remettre d’une attaque de rançongiciel n’est pas une tâche facile, car toutes les situations comportent leurs spécificités.
Une compromission par ransomware n’est pas quelque chose que le département informatique doit ou peut gérer seul.
Si les défenses et la récupération des sauvegardes échouent, l’effort de reconstruction ne sera ni facile ni bon marché. Et il y a de fortes chances que vos clients découvrent ce qui se passe pendant ce processus de récupération. Pas question, dès lors, de faire l’impasse sur un plan de communication et un point de contact unique pour des raisons de cohérence.
Une compromission par ransomware n’est pas quelque chose que le département informatique doit ou peut gérer seul : les décisions jalonnant la reprise impliqueront plusieurs intervenants et des coûts réels. D’où l’importance de planifier méticuleusement à l’avance pour éviter de se précipiter dans de mauvais choix sur lesquels il serait impossible de revenir.
Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)
