Testez la restauration de vos sauvegardes avant le ransomware

Avant que le ransomware ne mette vos sauvegardes à l'épreuve, faites trois vérifications vous-même : quelqu'un peut-il les supprimer, un compte administrateur volé peut-il les atteindre, et combien de temps prend une vraie restauration par rapport à ce que l'entreprise peut tolérer ?

Le guide du NCSC sur la réduction des risques liés aux malwares et aux ransomwares est sans détour. Des sauvegardes à jour sont le moyen le plus efficace de se remettre d'une attaque par ransomware, les ransomwares les prennent activement pour cible afin d'augmenter les chances de paiement, et des attaquants ont détruit les fichiers copiés ou perturbé la reprise avant de lancer l'attaque. Testez donc vos sauvegardes comme le ferait un attaquant.

Test 1 : essayer de supprimer votre propre sauvegarde

Les exemples ci-dessous utilisent Amazon S3 Object Lock. Si vous êtes sur une autre solution, cherchez le verrouillage d'immutabilité ou de rétention équivalent dans votre produit de sauvegarde. Vérifiez qu'il est activé, quelle est la durée de rétention, et qui peut la raccourcir ou la supprimer. Tentez ensuite une suppression définitive en tant qu'utilisateur ordinaire, en tant que votre administrateur de sauvegarde le plus privilégié, et avec un compte qu'un attaquant pourrait vraisemblablement prendre en main. Notez qui y parvient.

Pour S3, travaillez dans un bucket de test. Object Lock ne fonctionne que dans les buckets où S3 Versioning est activé : vérifiez-le d'abord. Utilisez le mode governance, qu'AWS présente comme un moyen de tester les paramètres de rétention avant de définir une période de rétention en mode compliance.

N'appliquez jamais le mode compliance dans le bucket de test. En mode compliance, le mode de rétention ne peut pas être modifié et la période ne peut pas être raccourcie, et le seul moyen de supprimer plus tôt un objet verrouillé en compliance est de supprimer le compte AWS associé.

Effectuez ces tentatives via la console, puis via l'API ou la CLI, et comparez :

La deuxième ligne n'est pas un échec : la version verrouillée subsiste, car les périodes de rétention n'empêchent pas la création de nouvelles versions ni de marqueurs de suppression. La troisième ligne est celle qui inquiète. La console S3 inclut par défaut l'en-tête x-amz-bypass-governance-retention:true, si bien que toute personne détenant cette permission peut effacer des objets verrouillés en mode governance en quelques clics.

Envoyez ensuite la même suppression définitive avec cet utilisateur, via l'API ou la CLI, sans l'en-tête. AWS l'exige pour toute requête qui outrepasse le mode governance : vous devriez donc obtenir Access Denied. Si la suppression réussit, vérifiez le mode de rétention du bucket et les paramètres de verrouillage de la version de l'objet.

Auditer ensuite qui peut défaire le verrou

Listez tous les principals dont les politiques autorisent s3:BypassGovernanceRetention, y compris les rôles, les groupes et les politiques inline. Faites de même pour s3:PutObjectLegalHold : un legal hold n'a pas de date d'expiration, et tout utilisateur disposant de cette permission peut librement poser et retirer des holds.

Retirez ces deux permissions aux comptes qu'un attaquant pourrait vraisemblablement prendre en main. Pour les données que vous ne pouvez pas perdre, envisagez le mode compliance avec une période de rétention choisie délibérément.

Test 2 : essayer d'atteindre la sauvegarde avec les mauvais identifiants

Un stockage immuable ne sert à rien si l'attaquant contrôle la console qui le gère. Essayez de vous connecter à la console de sauvegarde et au stockage avec un administrateur de domaine, un compte backup operator et un utilisateur IAM cloud, puis vérifiez si chacun peut supprimer des données ou modifier les paramètres de rétention.

Le guide du NCSC recommande ces protections pour les comptes de sauvegarde :

• des Privileged Access Workstations et des pare-feux matériels qui appliquent une liste d'autorisation d'adresses IP ;
• le MFA, avec une méthode MFA qui n'est pas installée sur l'appareil utilisé pour administrer les sauvegardes ;
• le Privileged Access Management, afin que les administrateurs n'accèdent pas directement aux systèmes de sauvegarde à forte valeur.

Les disques de sauvegarde et les clés USB ne doivent pas rester connectés en permanence à votre réseau, et les produits de sauvegarde doivent être patchés. Avec un service cloud, vérifiez que les versions précédentes sont protégées contre une suppression immédiate et que vous pouvez restaurer vers elles, car les services se synchronisent souvent juste après que vos fichiers ont été remplacés par des copies chiffrées.

Test 3 : restaurer quelque chose, chronomètre en main

Choisissez un système dont l'entreprise sentirait l'absence en moins d'une journée et restaurez-le depuis la sauvegarde vers un environnement propre et isolé, afin qu'une infection restaurée ne puisse pas atteindre les systèmes en production. Notez le temps écoulé, qui a fait quoi, et chaque moment où quelqu'un a dû chercher un mot de passe, une clé de licence ou un document stocké sur les serveurs que vous restaurez.

Si la restauration échoue en cours de route, consignez l'étape, le temps écoulé, la cause et la correction, puis reprenez à partir de cette étape et journalisez séparément le temps restant. Gardez des étapes identiques d'une exécution à l'autre pour que les résultats soient comparables.

Avant la reprise, ne connectez les sauvegardes qu'à des appareils connus et sains, et analysez-les à la recherche de malwares avant de restaurer les fichiers. Le ransomware a pu se répliquer dans les sauvegardes avant d'être découvert : un point de restauration d'apparence saine ne l'est peut-être pas.

Comparez votre temps mesuré avec ce que l'entreprise dit pouvoir tolérer. Obtenez ce chiffre auprès du propriétaire du système avant le test, pour ne pas ajuster l'objectif au résultat. Une récupération complète après un ransomware, si elle est possible, peut prendre plusieurs semaines : considérez donc le chiffre obtenu pour un seul système comme un plancher.

Sur le papier, déterminez ce qui se passe si les systèmes sur site et les serveurs de sauvegarde cloud sont tous deux inutilisables et que vous devez reconstruire à partir de sauvegardes hors ligne, et comment vous maintiendriez les services métier critiques. Vérifiez que les playbooks, les check-lists et les coordonnées existent quelque part où vous pouvez les consulter sans vos systèmes informatiques. Notre service de réponse à incident couvre ce type d'exercice si vous souhaitez un regard extérieur.

Par où commencer

1. Choisissez un système critique pour l'activité et demandez à son propriétaire combien de temps il peut rester indisponible. Notez d'abord ce chiffre.
2. Créez un bucket S3 de test avec versioning et Object Lock en mode governance, jamais compliance. Tentez une suppression définitive et une suppression simple, et consignez les réponses.
3. Répétez la suppression définitive avec un utilisateur détenant s3:BypassGovernanceRetention, depuis la console puis depuis l'API ou la CLI sans l'en-tête de contournement. Listez ensuite tous les détenteurs de cette permission et de s3:PutObjectLegalHold, et retirez-la à ceux qui n'en ont pas besoin.
4. Essayez de vous connecter à la console de sauvegarde avec un administrateur de domaine, un backup operator et un utilisateur IAM cloud. Là où une connexion a fonctionné, prévoyez le MFA sur un appareil distinct et une liste d'autorisation d'adresses IP. Vérifiez qu'une copie hors ligne existe, qu'elle n'est pas connectée en permanence et qu'une restauration a déjà été faite à partir d'elle.
5. Restaurez le système choisi dans un environnement isolé à partir d'une sauvegarde analysée, en chronométrant chaque étape, et comparez le résultat avec le chiffre de l'étape 1.
6. Corrigez l'écart le plus important, puis relancez les tests chaque fois que l'architecture de sauvegarde change.