Après une attaque par ransomware, la première urgence consiste généralement à remettre les systèmes en fonctionnement. Les équipes recherchent une sauvegarde disponible, choisissent une date antérieure à l'incident et lancent la restauration.
Cette démarche est nécessaire. Elle ne répond pourtant pas à la question la plus difficile : les données restaurées sont-elles réellement dignes de confiance ?
L'attaque commence souvent avant le chiffrement
Le chiffrement visible des fichiers marque rarement le début de l'incident. Un attaquant peut être présent depuis plusieurs jours, parfois plusieurs semaines. Pendant cette période, il peut créer des comptes, modifier des droits, déposer des outils, altérer des configurations ou préparer des mécanismes de persistance.
La dernière sauvegarde réalisée avant le déclenchement du ransomware peut donc contenir un environnement déjà compromis.
Restaurer cette sauvegarde permettrait de retrouver des fichiers lisibles, mais aussi de réintroduire les conditions ayant rendu l'attaque possible.
La sauvegarde répond à une première question : quelles données pouvons-nous récupérer ? La reprise de confiance en pose une autre : quel état devons-nous choisir, et pourquoi pouvons-nous lui faire confiance ?
Trois dates qui ne coïncident pas nécessairement
Après un incident, trois points temporels doivent être distingués :
- le dernier état disponible
- le dernier état techniquement intact
- le dernier état dont la confiance peut être raisonnablement établie
Le plus récent n'est pas nécessairement le plus sûr.
Une version peut présenter une empreinte parfaitement cohérente tout en contenant une modification malveillante. L'intégrité cryptographique démontre que cette version n'a pas été altérée depuis son enregistrement. Elle ne démontre pas que son contenu était sain au moment où il a été enregistré.
La sélection d'un point de restauration doit donc prendre en compte davantage que la date et l'état des fichiers.
Reconstruire le contexte de chaque état
Pour évaluer un état ancien, une organisation doit pouvoir retrouver les informations qui l'entouraient au moment considéré :
- la version exacte des données
- les identités et les droits actifs
- les comptes récemment créés ou modifiés
- les politiques de sécurité applicables
- les événements observés par les outils de protection
- les traitements ayant modifié les données
- les dépendances avec d'autres fichiers ou systèmes
- les validations humaines et les décisions prises
Ces éléments sont généralement répartis entre le stockage, les sauvegardes, l'annuaire, le SIEM, les applications métiers et différents journaux techniques. Chacun conserve une partie de l'histoire, mais aucun ne permet nécessairement de la reconstruire dans son ensemble à une date précise.
C'est cette continuité qui manque souvent au moment où elle devient indispensable.
Sélectionner avant de restaurer
La sélection d'un état candidat et l'exécution de sa restauration sont deux opérations différentes.
La première relève de l'investigation et de la gouvernance. Elle consiste à comparer plusieurs états, à examiner leur contexte et à qualifier les éléments de preuve disponibles.
La seconde relève des outils de sauvegarde, de réplication et de reprise d'activité. Elle remet effectivement les données et les systèmes en service.
Confondre ces deux étapes revient à demander à la sauvegarde de prendre une décision qu'elle n'a pas été conçue pour prendre.
Une sauvegarde sait restaurer des octets. Elle ne sait pas toujours expliquer si les droits associés étaient légitimes, si la politique appliquée était encore valide ou si une modification provenait d'un utilisateur autorisé, d'un traitement normal ou d'un attaquant.
Donner une mémoire aux données
KARL Core a été conçu pour préserver l'identité, les versions et le contexte gouverné des données dans le temps. Il relie chaque état aux événements, aux acteurs, aux politiques et aux éléments de preuve effectivement capturés.
Cette mémoire temporelle ne remplace ni la sauvegarde, ni le stockage S3, ni les outils de cybersécurité. Elle leur apporte une continuité commune.
Lorsqu'un incident survient, l'objectif n'est pas que KARL déclare automatiquement qu'une version est saine. Une telle conclusion resterait impossible si certains événements n'ont jamais été observés ou conservés.
KARL aide plutôt l'organisation à sélectionner un état candidat, à documenter les raisons de ce choix et à exposer les éventuelles lacunes. La conclusion reste bornée au périmètre gouverné et aux preuves réellement disponibles.
Revenir au bon moment, pour les bonnes raisons
Une stratégie de résilience ne devrait donc pas seulement mesurer la vitesse de restauration. Elle devrait également mesurer la capacité à répondre à des questions plus exigeantes :
- Pourquoi cette version a-t-elle été retenue ?
- Quels événements la précèdent ?
- Qui pouvait la modifier ?
- Quelles règles étaient applicables ?
- Quels indices permettent de la considérer comme plus fiable que les versions suivantes ?
Une organisation n'est véritablement revenue à la normale que lorsqu'elle peut exploiter ses données sans reconstruire, en même temps, les conditions de l'incident.
Le magazine suédois Aktuell Säkerhet revient sur cette question à la suite de la présentation de StratoFoundry lors de l'IT Press Tour de Ljubljana : après un ransomware, quelle version des données peut-on réellement considérer comme fiable ?
