Quand la prévention ne suffit plus : les nouveaux calculs de la cyber-Recovery

Points clés à retenir

• Frontier AI réduit les délais de correction des vulnérabilités ; la prévention à elle seule ne suffit plus à garantir la sécurité.
• La question que se posent désormais les conseils d’administration, les autorités de régulation et les assureurs n’est plus « Disposons-nous de sauvegardes ? », mais « Pouvons-nous prouver que nous sommes en mesure de rétablir le fonctionnement sans heurts ? ».
• Une sauvegarde n’est pas une restauration : une copie vous indique que les données existent, mais ne vous permet pas de savoir si elles sont intactes ou si elles peuvent être restaurées.
• Le temps moyen de retour à la normale (MTCR) doit devenir un indicateur suivi en permanence au niveau du conseil d’administration, et non une simple estimation théorique.
• Un environnement de récupération isolé – hors réseau, immuable, renforcé et doté d’identités isolées – constitue la norme de base, et non une fonctionnalité avancée.
• La définition de ce qui est considéré comme « propre » ne cessera d’évoluer à mesure que les modèles d’IA deviendront de plus en plus capables de détecter des failles que les humains ne peuvent pas anticiper.

J’ai passé une grande partie de ma carrière à gérer des systèmes de production. Je connais de l’intérieur les environnements de sauvegarde, ceux auxquels les clients font réellement confiance. Je sais que les plans de reprise ne révèlent leurs faiblesses que lorsque quelque chose a déjà mal tourné. Cette expérience change la façon dont on envisage la cyber-résilience.

Vus de loin, Backup and Recovery semblent gérables. Protéger les données, stocker des copies, documenter le guide d’intervention, tester quand on le peut, restaurer quand on en a besoin. Mais quiconque a géré ces environnements à grande échelle connaît la dure réalité : c’est lors de Recovery que les hypothèses sont mises à l’épreuve. Et à l’heure actuelle, trop d’organisations fonctionnent sur la base d’hypothèses qui ne sont plus d’actualité. Pendant des années, la sécurité a fonctionné selon un schéma bien connu : identifier la faille, la corriger, renforcer la sécurité de l’environnement, surveiller l’activité. Ce modèle reste d’actualité. Mais la marge de manœuvre sur laquelle il repose est en train de s’effriter.

L’IA de pointe a révolutionné la rapidité de détection des vulnérabilités, d’enchaînement des voies d’attaque et de génération d’exploits. Des modèles tels que Claude Mythos et GPT-5.5-Cyber ont déjà donné un aperçu de ce à quoi cela ressemble, même si, jusqu’à présent, ces tests contrôlés en accès anticipé s’appuyaient encore sur l’expertise humaine et présentaient des taux de faux positifs significatifs ; la tendance est toutefois indéniable. À mesure que l’accès se généralise, ces mêmes capacités tombent entre les mains des attaquants.

En l’espace d’un seul mois, Palo Alto Networks a révélé 26 CVE, correspondant à 75 problèmes sous-jacents, après avoir adopté des modèles d’IA de pointe pour l’analyse de code, alors que son volume habituel est inférieur à cinq CVE par mois. Les chercheurs avertissent également que la détection assistée par l’IA réduit considérablement les délais de correction, certains exploits apparaissant désormais quelques minutes seulement après leur divulgation. Lorsque la fenêtre de correction disparaît, les calculs de correction ne tiennent plus la route. La prévention ne peut pas à elle seule garantir la « Readiness ».

La prévention reste importante, mais elle ne définit plus la « Readiness ». Les clients auxquels je m’adresse ne se demandent pas s’ils ont besoin de contrôles supplémentaires. Ils savent déjà que c’est le cas. Ils se demandent si leur entreprise peut se rétablir sans encombre lorsque ces contrôles échouent, lorsque les attaquants agissent plus vite que les cycles de correction, ou lorsque la compromission est présente depuis plus longtemps que quiconque ne l’avait réalisé.

C’est désormais cette question que posent les conseils d’administration, les autorités de régulation et les assureurs. Ils ne se contentent plus de demander « Disposons-nous de systèmes de secours ? », mais s’intéressent désormais à un aspect plus crucial : « Pouvons-nous prouver que nous sommes capables de rétablir le fonctionnement sans heurts ? » Cette démonstration commence par une distinction que la plupart des organisations ont encore du mal à faire : les sauvegardes ne sont pas synonymes de restauration.

Une sauvegarde vous indique qu’une copie existe. Elle ne vous permet pas de savoir si les données sont correctes, si les dépendances des applications sont intactes, si les services d’identité peuvent être restaurés en toute sécurité, ni si la séquence de restauration correspond toujours à l’environnement actuel. J’ai examiné des plans qui semblaient complets jusqu’à ce que quelqu’un tente de les mettre en œuvre. Le guide d’intervention était bien là, mais obsolète. La restauration a fonctionné, mais a pris trois fois plus de temps que prévu. Le système a redémarré, mais les applications en aval n’ont pas pu se connecter. Rien de tout cela n’est inhabituel. C’est exactement ce que les tests en conditions réelles sont censés mettre en évidence. Le problème, c’est que la plupart des organisations ne découvrent ces lacunes qu’au moment d’un incident réel. L’indicateur qui importe le plus lorsqu’un problème survient est la rapidité avec laquelle on peut revenir à un état dont on sait qu’il est correct. C’est pourquoi le « Mean Time to Recovery » (MTCR) doit devenir un indicateur suivi au niveau du conseil d’administration : non pas une estimation théorique figurant dans un plan, mais un délai mesuré et validé.

Une cible mouvante : ce qui est sécurisé aujourd’hui ne le sera peut-être plus demain

Avec les modèles d’IA de Frontier, la réponse honnête est la suivante : vous ne pouvez pas garantir que toutes les vulnérabilités seront détectées et corrigées à temps. Les pirates qui exploitent ces mêmes modèles découvrent et enchaînent les exploits à un rythme qu’aucun programme de correction ne peut raisonnablement suivre. Ce n’est pas un échec de votre équipe de sécurité. C’est la nouvelle réalité du paysage des menaces.

Ce que vous pouvez contrôler, c’est votre capacité à vous remettre d’un incident. Cela implique un environnement de Recovery isolé : des sauvegardes coupées d’Internet, inaccessibles depuis le réseau de production et protégées contre les mouvements latéraux caractéristiques d’une intrusion sophistiquée. Cela implique l’immuabilité et un verrouillage de conformité, afin qu’aucun identifiant, aussi privilégié soit-il, ne puisse raccourcir la durée de conservation ou supprimer des données en dehors d’un processus autorisé. Et cela signifie la mise en œuvre des ResOps : il ne s’agit pas seulement de sauvegarder les données, mais de tester en continu Recovery, d’automatiser la validation de l’intégrité et de mesurer votre MTCR – le délai validé pour revenir à un état connu comme étant correct.

Mais voici l’aspect dont la plupart des organisations ne tiennent pas encore compte : ce qui est considéré comme « propre » n’est pas une ligne fixe. À mesure que les modèles d’IA gagnent en capacité, ils détecteront de plus en plus de vulnérabilités que l’esprit humain ne peut tout simplement pas anticiper, de nouvelles voies d’attaque, des implants dormants, des corruptions subtiles intégrées bien avant leur détection. Un point de restauration considéré comme « propre » selon les normes actuelles peut receler des compromissions que l’analyse forensic assistée par l’IA de demain mettra au jour. Cela signifie que votre définition de la « propreté » doit évoluer en permanence. Le MTCR n’est pas un chiffre que l’on fixe une fois pour toutes. C’est une discipline à entretenir, qui consiste à redéfinir ce que signifie « propre », à mettre à jour vos critères de validation et à considérer la résilience comme une norme évolutive plutôt que comme une certification que l’on obtient une seule fois.

Alors, quel est un bon MTCR ? D’après ce que j’ai pu constater dans la pratique, l’objectif pour l’ensemble de votre « entreprise minimale viable » – l’ensemble le plus restreint de systèmes vous permettant de poursuivre vos activités, que je définis précisément ci-dessous – devrait être inférieur à six heures. Six heures, c’est un objectif réalisable avec la bonne architecture : un IRE prêt à fonctionner, une séquence de Recovery pré-validée et des runbooks qui sont exécutables plutôt que simplement lisibles. Si votre MTCR actuel se mesure en jours, l’écart provient presque toujours de l’un de ces trois éléments.

Quatre étapes pour rester résilient à l’ère de l’IA de pointe

Le point de départ consiste à accepter que la prévention à elle seule ne suffit pas. À partir de là, le travail devient plus concret. Voici les points sur lesquels je conseille aux organisations de se concentrer.

1. Évaluez vos risques réels en matière de reprise d’activité.

La plupart des évaluations des risques liés à la reprise posent les mauvaises questions. « Existe-t-il des sauvegardes ? » n’est pas la même chose que « Pouvons-nous effectuer une reprise sans problème ? ». Les questions les plus difficiles sont les suivantes : les systèmes critiques peuvent-ils être restaurés sans réintroduire la menace ? Les environnements de reprise sont-ils isolés des systèmes de production compromis ? Les plans de reprise sont-ils adaptés aux dépendances actuelles – et non à l’architecture d’il y a deux ans ?

Dans un environnement où les vulnérabilités évoluent rapidement, c’est l’écart entre « nous avons des sauvegardes » et « nous pouvons rétablir le fonctionnement » qui fait mal aux organisations. C’est par une évaluation honnête de cet écart, avant qu’un incident ne vienne forcer la main, que doit commencer la planification de la résilience. Cette évaluation doit inclure une analyse d’impact sur l’activité : quels systèmes ont un délai de reprise de l’ordre de quelques minutes, lesquels de quelques heures, et lesquels peuvent attendre une journée ? Sans cette hiérarchisation, tous les systèmes semblent aussi urgents les uns que les autres lors d’un incident, et rien n’est restauré assez rapidement.

2. Veiller à ce que la récupération isolée et l’« air gap » constituent la norme, et non l’exception.

Si vous considérez encore les copies « air-gapped » et immuables comme une fonctionnalité avancée plutôt que comme une exigence standard, cette hypothèse n’est plus valable. Lorsque les délais d’exploitation se réduisent à quelques minutes, vous avez besoin de solutions de secours structurellement séparées des plans d’identité, du réseau et de la gestion de l’environnement de production : elles doivent être isolées logiquement ou physiquement, immuables et ne présenter aucun chemin actif vers l’environnement de production qu’un attaquant pourrait emprunter.

L’objectif n’est pas seulement de se protéger contre la menace actuelle, mais aussi de disposer d’options de restauration efficaces lorsqu’une vulnérabilité que vous n’avez pas encore corrigée sera exploitée. Cela arrive déjà. Préparez-vous-y. L’isolation n’est efficace que si l’infrastructure qui l’entoure est renforcée. Cela implique une infrastructure de sauvegarde reposant sur des systèmes d’exploitation renforcés, et non sur des images génériques, et idéalement sur des serveurs physiques capables de résister à une attaque au niveau de la couche d’hyperviseur. Cela implique que les clés de chiffrement soient stockées en dehors de la plateforme de sauvegarde, dans un coffre-fort externe avec un accès « juste à temps » et sans dépendance vis-à-vis de l’Active Directory de production. Cela implique également de traiter votre domaine de sauvegarde comme une frontière d’identité distincte : aucune confiance accordée à l’Active Directory de production, une authentification multifactorielle (MFA) obligatoire et une autorisation multi-personne pour les opérations destructives. Rien de tout cela n’a d’exotique ; il s’agit de la base indispensable pour que votre environnement puisse se restaurer dans un espace non compromis.

Tout aussi importante est la question de savoir à partir de quoi vous effectuez la Recovery. Les données du secteur relatives à la réponse aux incidents indiquent systématiquement que la durée médiane de persistance d’une intrusion se compte en semaines, et non en jours. Cela signifie que vos copies de Recovery doivent remonter suffisamment loin dans le temps pour trouver un point véritablement sain, et pas seulement la sauvegarde d’hier. Les systèmes critiques justifient la mise en place de plusieurs copies géographiquement séparées, dont au moins une copie immuable et une autre entièrement hors ligne. La politique de conservation n’est pas une décision liée aux coûts de stockage. C’est une décision de sécurité.

3. Identifiez les systèmes dont l’entreprise ne peut se passer, et veillez à les remettre en service en priorité.

La plupart des organisations définissent leur plan de reprise après sinistre au moment même où un incident se produit. C’est pourquoi les premières 24 à 48 heures ne sont pas consacrées à la restauration des systèmes, mais à déterminer ce qui est essentiel. Les entreprises savent qu’elles doivent rétablir le fonctionnement de leurs plateformes d’identité, de leurs systèmes de facturation, de leurs bases de données opérationnelles et de leur infrastructure de base. Ce qu’elles n’ont souvent pas encore défini, c’est l’ordre de restauration, les dépendances entre ces systèmes, ainsi que les applications en aval qui ne peuvent fonctionner tant que certains services n’ont pas été rétablis.

La situation se complique à mesure que l’IA s’intègre aux opérations métier. Les pipelines de données, les référentiels de modèles, les bases de données vectorielles, les workflows basés sur des agents : tous ces éléments constituent désormais des dépendances opérationnelles, et non plus seulement une infrastructure technique. Si votre séquence de reprise ne les prend pas en compte, vos estimations du temps de reprise sont probablement erronées. Définir ce que signifie fonctionner en tant qu’« entreprise minimalement viable » (l’ensemble minimal de systèmes nécessaires au maintien de l’activité) et construire Recovery autour de cette définition n’est pas un exercice théorique. C’est la réponse concrète à la question que toute équipe de direction se posera lors d’un incident : « Que faut-il rétablir en priorité ? »

D’après mon expérience auprès de clients confrontés à des incidents réels, les 12 premières heures répondent à cette question, que vous l’ayez prévu ou non : ce qui est rétabli pendant ce laps de temps devient par défaut votre MVC. Les organisations qui s’en sortent le plus rapidement ont pris leurs décisions à l’avance : elles savaient exactement quels systèmes devaient être rétablis dans les 12 heures et avaient vérifié qu’elles en étaient capables. Si votre MVC ne tient pas dans un délai de 12 heures, ce n’est pas votre MVC, c’est une liste de vœux pieux. Le travail consiste à réduire progressivement l’ensemble jusqu’à ce que ce qui reste puisse réellement être restauré dans ce délai, puis à le tester jusqu’à ce que vous puissiez le prouver.

4. Automatisez la résilience et effectuez des tests en continu, sans vous limiter à un calendrier préétabli.

Un plan de reprise qui se limite à un document et qui fait l’objet d’une révision annuelle ne constitue pas une capacité de reprise. Il s’agit d’une hypothèse qui n’a jamais été mise à l’épreuve dans la réalité. Le problème des tests basés sur un calendrier réside dans le fait qu’ils ne tiennent pas compte de ce qui se passe entre deux cycles. Les environnements évoluent constamment : nouvelles charges de travail, dépendances mises à jour, infrastructure qui s’est éloignée de ce que décrit le guide d’exploitation. Au moment où le test annuel est effectué, il valide un instantané d’un environnement qui n’existe plus. Dans un contexte de menaces où l’exploitation peut intervenir quelques minutes seulement après la divulgation, ce décalage est inacceptable. L’analyse des menaces, l’identification de points de restauration spécifiques, la restauration tenant compte des dépendances et l’orchestration de la reprise doivent toutes être automatisées et fonctionner en continu. Non pas parce que l’automatisation est une bonne pratique, mais parce que l’alternative manuelle ne peut pas suivre le rythme effréné auquel les choses évoluent aujourd’hui. Les tests continus dépendent également d’une détection continue. Vous ne pouvez pas sélectionner un point de restauration sain si vous ne savez pas quand la compromission a commencé. C’est pourquoi la détection des menaces, l’analyse des anomalies dans les données de sauvegarde et l’analyse des points de restauration doivent se nourrir mutuellement : la détection vous indique quelles copies sont antérieures à l’intrusion, et cette détermination définit le point à partir duquel vous effectuez réellement la restauration. Sans ce lien, vous effectuez une restauration à une date que vous espérez intacte plutôt qu’à une date que vous avez vérifiée, et dans un environnement de menaces Frontier AI, l’espoir n’est pas une stratégie de restauration.

Les problèmes mis en évidence par les tests continus diffèrent de ceux détectés lors des tests annuels. Les tests périodiques ont tendance à confirmer que le plan fonctionne dans des conditions contrôlées. Les tests continus permettent quant à eux de repérer la dépendance qui a changé le mois dernier, la séquence de reprise qui échoue lorsqu’une charge de travail spécifique est ajoutée, ou encore le service d’identité dont la restauration prend deux fois plus de temps que prévu. Ce sont ces failles qui comptent lors d’un événement réel, et la seule façon de les détecter avant qu’un incident ne se produise est de procéder à des tests en permanence.

Les tests doivent également être effectués dans le bon environnement. Un test de reprise exécuté sur l’infrastructure de production ne vous indique pas si vous êtes en mesure de procéder à une reprise lorsque la production est compromise. Les tests en « salle blanche » – qui consistent à valider la restauration dans un environnement totalement isolé, sans aucune connectivité avec la production – vous permettent de confirmer que vos copies de sauvegarde sont réellement utilisables en cas d’incident. Cela inclut la reprise des services d’identité, de la gestion des clés externes et des applications de niveau 0 en isolation, à l’aide de comptes d’urgence dédiés qui n’appartiennent pas à votre annuaire habituel.

Ce qui rend les tests quotidiens réalisables, c’est la « validation de restauration » (validate restore), un type de restauration qui simule le processus complet de restauration pour chaque ressource critique sans affecter l’environnement de production. Votre plateforme de sauvegarde prend-elle en charge cette fonctionnalité de manière native ? Si elle n’est pas capable d’exécuter quotidiennement un test de restaurabilité automatisé et sans interruption sur l’ensemble de votre infrastructure MVC, vous ne savez pas réellement si vos sauvegardes fonctionnent. Dans Commvault, cette fonctionnalité effectue des restaurations sur vos groupes de ressources critiques, avec des rapports automatisés sur l’état de restauration de chaque système protégé.

Il en va de même pour vos guides d’intervention. Un guide d’intervention stocké dans un document Word ou un PDF est un manuel de référence, pas un outil opérationnel : il part du principe que quelqu’un dispose du temps, de la lucidité et de l’accès nécessaires pour le lire en situation de crise. Les véritables guides d’intervention sont des scripts numériques qui exécutent la séquence de Recovery et valident chaque étape, en s’assurant que l’application fonctionne réellement avant de passer à l’étape suivante : non pas « le service a démarré », mais « l’application a répondu correctement à une transaction synthétique ». Les « Commvault Cleanroom Runbooks » sont conçus à cet effet : il s’agit de workflows exécutables qui pilotent une reprise de bout en bout dans un environnement isolé, sans qu’un intervenant humain ait à interpréter un document à chaque étape.

Un dernier point rarement pris en compte dans les plans de Recovery avant qu’il ne soit trop tard : lors d’un incident grave, votre infrastructure de communication d’entreprise peut elle-même être compromise ou indisponible. Les services de messagerie électronique, Teams et Slack fonctionnent sur la même infrastructure que celle ciblée par les attaquants. Déterminez à l’avance quels canaux hors bande votre équipe utilisera pour se coordonner, et assurez-vous que ces canaux sont testés parallèlement à vos procédures techniques de Recovery. Découvrez les propos de Bill O’Connell, directeur de la sécurité chez Commvault, sur les quatre étapes essentielles pour assurer la résilience à l’ère de l’IA.

La résilience est une discipline opérationnelle, pas un projet

Les organisations qui résisteront aux menaces de pointe accélérées par l’IA sont celles qui considèrent la résilience comme une discipline opérationnelle : un MTCR mesuré, une validation continue et une capacité de reprise dont elles ont prouvé l’efficacité, et non pas simplement supposée. Le problème n’est pas que les attaques gagnent en rapidité. C’est que la capacité de reprise n’a pas suivi le rythme, et tant que ce ne sera pas le cas, le calcul ne tiendra pas la route.

FAQ

Q : Qu’est-ce que le « Mean Time to Clean Recovery » (MTCR) et pourquoi est-ce important ?
R : Le MTCR mesure la rapidité avec laquelle une organisation peut revenir à un état vérifié et reconnu comme correct après une cyberattaque — il ne s’agit pas seulement de restaurer les données, mais de confirmer qu’elles sont saines et que les dépendances des applications sont intactes. Il devrait s’agir d’un indicateur suivi au niveau du conseil d’administration, avec un délai mesuré et validé, et non d’une estimation théorique enfouie dans un plan de Recovery. L’objectif pour un MVC bien conçu – couvrant tous les systèmes d’identité, les applications critiques et la Readiness de l’environnement isolé – est inférieur à six heures.

Q : Qu’est-ce qu’un environnement de Recovery isolé et en quoi diffère-t-il d’une sauvegarde standard ?
R : Un environnement de Recovery isolé est une copie immuable et entièrement isolée (air-gapped) des données critiques, structurellement séparée des réseaux de production, des systèmes d’identité et des plans de gestion. Une sauvegarde standard vous indique qu’une copie existe. Un environnement de reprise isolé (IRE) vous garantit que cette copie est protégée contre la même attaque que celle qui a touché votre environnement de production.

Q : Comment savoir si nous sommes réellement en mesure de nous rétablir aujourd’hui ?
R : La seule réponse honnête provient des tests, et non de la documentation. Si vous ne pouvez pas mettre en avant une Recovery récente et validée de votre « entreprise minimale viable » – idéalement un test automatisé quotidien –, alors vous ne le savez pas, vous ne faites que supposer. Une réponse défendable devant le conseil d’administration est un MTCR mesuré, étayé par une validation continue, et non un plan de reprise qui semble complet sur le papier.

Q : Qu’attendent désormais les régulateurs et les assureurs cyber ?
R : La question n’est plus « Avez-vous des sauvegardes ? », mais « Pouvez-vous prouver que vous êtes en mesure de vous rétablir sans incident, et en combien de temps ? » Les régulateurs attendent de plus en plus une capacité de reprise démontrable et une résilience testée ; les assureurs fixent de plus en plus le prix de la couverture – et règlent les sinistres – en fonction de preuves de sauvegardes isolées et immuables, ainsi que de délais de reprise validés. Un MTCR mesuré et une cadence de tests documentée deviennent des conditions indispensables pour les deux. Rajiv Kottomtharayil est directeur produit chez Commvault.