La sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde
Les groupes de rançongiciels visent d'abord les sauvegardes, précisément parce qu'une restauration qui fonctionne leur retire tout levier. La plupart des organisations découvrent leur temps de reprise pendant l'incident.
One stopwatch, nothing else
A single mechanical stopwatch on a seamless bone-white surface, viewed slightly from above. Vast empty space around it. Nothing else in frame.
2400×1350 · WebP · <350KB
Toutes les organisations que nous avons accompagnées lors d'un incident rançongiciel avaient des sauvegardes. Ce n'est pas ça, le facteur différenciant. Le facteur, c'est de savoir si quelqu'un avait déjà restauré depuis ces sauvegardes sous pression, avec la personne qui le fait d'habitude indisponible, pendant que le contrôleur de domaine était lui aussi chiffré.
Les attaquants visent les sauvegardes délibérément
Les opérateurs de rançongiciels modernes ne sont pas des opportunistes qui chiffrent par hasard un partage de fichiers. Ils passent d'abord des jours dans le réseau, et l'un de leurs premiers objectifs est votre infrastructure de sauvegarde — parce qu'un client qui peut restaurer ne paie pas. Ils suppriment les snapshots, corrompent les dépôts, et si votre serveur de sauvegarde est joint au domaine avec un compte de service administrateur du domaine, ils le font avec vos propres identifiants.
Si un attaquant disposant des droits d'administrateur de domaine peut supprimer vos sauvegardes, vous n'avez pas de sauvegardes. Vous avez des copies.
3-2-1-1-0, et la partie que tout le monde saute
- 3 copies des données
- 2 types de supports différents
- 1 copie hors site
- 1 copie immuable ou déconnectée — un stockage à verrouillage d'objets qu'un attaquant, même avec le contrôle total, ne peut supprimer
- 0 erreur à la vérification de restauration
Le zéro final est celui qu'on laisse tomber, parce que c'est le seul qui demande un effort continu plutôt qu'un achat. Tout ce qui précède relève de l'architecture. Ce dernier chiffre relève de l'habitude.
À quoi ressemble un vrai test de restauration
Pas un travail de sauvegarde qui a signalé un succès. Une vraie restauration, vers une infrastructure isolée, d'un système qui compte, chronométrée, menée par quelqu'un qui n'est pas celui qui l'a construite. Vous testez trois choses à la fois : que les données sont intactes, que le runbook est exact, et qu'un membre ordinaire de votre équipe peut le suivre.
Faites-le avec le runbook imprimé. Pendant un vrai incident, votre wiki peut être chiffré, votre SSO indisponible, et votre gestionnaire de mots de passe faire partie des systèmes que vous essayez de restaurer.
Les chiffres que vous devriez pouvoir énoncer
Pour chaque niveau de système : combien de données vous pouvez vous permettre de perdre (RPO), combien de temps vous pouvez rester indisponible (RTO) et — séparément — le temps de reprise que vous avez réellement mesuré. L'écart entre les deux derniers est votre exposition réelle, et c'est le seul chiffre de cet article qui mérite d'être présenté à votre conseil.
La plupart des organisations que nous évaluons constatent un écart d'un facteur trois ou plus. Non parce que la technologie est mauvaise, mais parce que personne n'avait compté les heures nécessaires pour restaurer Active Directory avant les serveurs applicatifs, ni remarqué que la copie hors site se restaure via un lien qui met onze heures à transférer un téraoctet.