Quand quelque chose tourne mal, on restaure.
Quand des données sont perdues, on les récupère.
Quand les systèmes tombent en panne, on revient en arrière.
Les sauvegardes sont essentielles.
Mais après un cyberincident, elles répondent à la mauvaise question.
La vraie question n’est pas « Pouvons-nous restaurer les données ? »
C’est plutôt :
« Pouvons-nous prouver que les données sont toujours exactes ? »
Restaurer n’est pas vérifier
Après un incident, les organisations s’empressent de remettre les systèmes en ligne.
Les sauvegardes font leur travail : les fichiers réapparaissent, les bases de données sont restaurées, les services reprennent.
Mais il manque un élément critique.
Une sauvegarde peut vous dire :
• quelles données existaient à un moment donné,
• quelle version a été restaurée,
• quand la restauration a eu lieu.
Elle ne peut pas vous dire :
• si les données étaient déjà compromises avant la sauvegarde,
• si des enregistrements ont été modifiés à votre insu,
• si l’information est suffisamment fiable pour servir de preuve.
La restauration vous apporte la continuité.
La vérification vous apporte la crédibilité.
L’hypothèse dangereuse derrière les sauvegardes
La plupart des organisations fonctionnent selon une hypothèse implicite :
« Si cela vient d’une sauvegarde, c’est forcément correct. »
Après un incident, cette hypothèse devient un risque.
Les attaquants ne suppriment pas toujours les données.
Ils les modifient. Subtilement. Sélectivement. Discrètement.
Un seul champ modifié.
Un horodatage changé.
Une clause altérée dans un document.
Les sauvegardes conservent fidèlement tout cela - y compris la compromission.
D’un point de vue technique, tout semble en ordre. D’un point de vue juridique, réglementaire ou d’audit, tout est discutable.
Les auditeurs ne demandent pas des sauvegardes. Ils demandent des preuves.
Lorsque les auditeurs, les régulateurs ou les équipes juridiques interviennent, la réussite de la restauration ne les intéresse pas.
Ils posent d’autres questions :
• Comment savez-vous que cet enregistrement n’a pas été modifié ?
• Pouvez-vous prouver que ce document existait sous cette forme exacte à ce moment-là ?
• Quelle preuve avez-vous que ces données sont authentiques ?
« Parce que nous l’avons restauré à partir d’une sauvegarde » n’est pas une réponse. C’est une hypothèse - et les hypothèses ne résistent pas à l’examen.
Sans preuve vérifiable :
• les audits ralentissent ou échouent,
• les rapports de conformité sont contestés,
• les positions juridiques s’affaiblissent,
• les décisions sont retardées.
Le problème n’est pas le stockage. C’est la confiance.
La plupart des stratégies de sécurité reposent sur la protection du stockage :
• chiffrer la base de données,
• durcir les accès,
• répliquer les données,
• les sauvegarder.
Tout est nécessaire. Rien n’est suffisant.
La confiance ne vient pas de l’endroit où les données sont stockées.
Elle vient de la possibilité de vérifier leur intégrité de manière indépendante.
Après un incident, la confiance doit se mériter - elle ne se présume pas.
Et une confiance qui repose uniquement sur des systèmes internes est fragile, surtout lorsque ces systèmes viennent d’être compromis.
La preuve doit exister hors du rayon d’impact
Si la seule preuve dont vous disposez se trouve dans les systèmes mêmes qui ont été attaqués, vous n’avez pas de preuve - vous avez de l’incertitude.
Une véritable preuve possède trois propriétés :
• Immuable : elle ne peut pas être modifiée rétroactivement
• Horodatée : elle prouve à quel moment quelque chose existait
• Indépendante : elle subsiste même si les systèmes internes tombent en panne
Sans ces propriétés, les données sont peut-être récupérables - mais elles ne sont pas défendables.
Les sauvegardes sont nécessaires. Elles ne suffisent pas.
Ce n’est pas un argument contre les sauvegardes.
C’est un argument contre le fait de s’y fier pour quelque chose qu’elles n’ont jamais été conçues pour faire.
Les sauvegardes relèvent de la disponibilité.
La preuve relève de l’intégrité.
La continuité sans crédibilité est fragile.
Et dans les environnements réglementés aux enjeux élevés, la fragilité est un risque que les organisations ne peuvent pas se permettre.
Dans le prochain article, nous verrons ce que signifie réellement prouver l’intégrité des données dès la conception - et pourquoi la vérification doit commencer dès la création, et non après un incident.
Car après une violation de sécurité, la question n’est plus de savoir si vous avez récupéré les données - mais si quelqu’un peut s’y fier.