Rançongiciels : la sauvegarde qui tient

Quand un rançongiciel frappe, la seule question qui compte dans les premières heures est : est-ce que la sauvegarde tient ? Nous avons vu les deux réponses. Les organisations qui ont pu dire oui n'avaient pas plus de budget que les autres. Elles avaient trois choses : une copie que l'attaquant ne pouvait pas atteindre, une copie qu'il ne pouvait pas modifier, et la preuve, datée, que la restauration fonctionnait.

Ce que disent les guides officiels

Le Centre canadien pour la cybersécurité, dans sa fiche ITSAP.00.099 sur les rançongiciels, est direct : « Assurez-vous que vos copies de sauvegarde sont chiffrées et stockées hors ligne sans connexion à Internet ou à des réseaux locaux. » Il explique pourquoi : les auteurs de menace infectent les sauvegardes reliées aux systèmes de production pour rendre la reprise impossible, et il faut créer de nombreuses barrières de sécurité entre la production et les sauvegardes. Il demande de tester le processus de sauvegarde, condition d'une reprise rapide et efficace, et d'analyser les fichiers de sauvegarde avant la restauration pour s'assurer qu'ils sont exempts de maliciel. Il déconseille de payer la rançon, qui ne garantit rien.

Sa fiche ITSAP.40.002 sur les sauvegardes ajoute la règle 3-2-1 : trois copies de l'information (l'original et deux sauvegardes), sur deux types de supports, dont une copie conservée hors site. Elle définit les sauvegardes hors ligne (« à froid ») comme des copies qui restent déconnectées des systèmes de l'organisation et ne sont branchées que lorsqu'on en a besoin, et demande de tester la reprise de façon routinière.

Le guide #StopRansomware de la CISA, mis à jour en septembre 2023 avec le MS-ISAC, la NSA et le FBI, dit la même chose en une phrase : « Maintenez des sauvegardes hors ligne et chiffrées des données critiques, et testez régulièrement la disponibilité et l'intégrité des sauvegardes dans un scénario de reprise après sinistre. » Il précise que de nombreuses variantes de rançongiciel cherchent et suppriment ou chiffrent les sauvegardes accessibles. Il recommande de conserver des images de référence des systèmes (système d'exploitation et applications préconfigurés) pour reconstruire vite, et, pour les environnements infonuagiques, des solutions de stockage immuable, en notant qu'elles demandent une configuration soignée.

Pourquoi ça compte

Trois leçons reviennent dans nos interventions. Aucune ne demande une technologie nouvelle.

La sauvegarde en ligne est la première cible. Dans les cas où la sauvegarde a cédé, le scénario est toujours le même : le serveur de sauvegarde était joint au domaine, l'attaquant a obtenu un compte d'administrateur, et il a supprimé les copies avant de lancer le chiffrement. La console de sauvegarde accessible avec les identifiants de production est une porte, pas une protection.

Immuable veut dire que personne, pas même vous, ne peut supprimer. Les organisations qui ont tenu avaient activé le verrouillage des copies pour une durée fixe, sur un dépôt dont le compte d'écriture n'avait pas le droit de suppression. Là où l'immuabilité était « activée » mais désactivable par le même administrateur, elle n'a servi à rien.

Une restauration jamais testée est une hypothèse. Nous avons vu des copies intactes qui n'ont pas pu être restaurées dans un délai utile : clé de chiffrement perdue avec le serveur, dépendances manquantes, ordre de reconstruction inconnu. Le test complet, chronométré, sur un système représentatif, est ce qui sépare la sauvegarde qui existe de la sauvegarde qui tient.

Ce que nous en pensons chez Sentrix

Dans l'ordre où nous le faisons avec les organisations que nous accompagnons :

1. Isoler la sauvegarde de l'identité de production : dépôt hors domaine, comptes distincts, MFA résistante à l'hameçonnage sur la console, aucun droit de suppression pour le compte qui écrit.
2. Rendre une copie immuable avec une durée de rétention verrouillée, et vérifier que la désactivation exige une procédure séparée, pas un clic d'administrateur.
3. Garder une copie hors ligne, déconnectée sauf pendant l'écriture, conformément aux fiches du Centre canadien pour la cybersécurité, et une copie hors site selon la règle 3-2-1.
4. Tester une restauration complète à date fixe, chronométrée, avec les images de référence recommandées par la CISA, et conserver le rapport comme preuve : c'est ce que demandent ISO 27001 (contrôle 8.13) et SOC 2 (disponibilité).
5. Prévoir l'analyse des copies avant restauration dans le plan de reprise, et savoir à quelle date remonter si l'intrusion est ancienne.
6. Mettre la sauvegarde dans le scénario d'exercice de réponse aux incidents : la question « quelle copie restaure-t-on et qui a la clé » doit avoir une réponse avant l'incident.

Notre service de réponse aux incidents commence toujours par cette vérification, parce qu'elle décide de tout le reste.

La prochaine étape

Faites l'exercice cette semaine : avec les identifiants de votre administrateur principal, essayez de supprimer votre sauvegarde la plus récente. Si vous y arrivez, un attaquant y arrivera aussi. Si vous n'y arrivez pas, restaurez un système complet et regardez l'horloge.