Skip to content

Atelier

Protocole Phoenix : renaître de ses cendres après une cyberattaque

Lorsqu’une cyberattaque frappe, la reprise peut sembler insurmontable. Dans cette session du SHIFT 2025, Commvault présente le protocole Phoenix, un cadre éprouvé permettant de sortir plus fort d’une attaque. Fondé sur une Recovery rigoureuse, l’isolation et la Readiness, le protocole Phoenix montre comment les organisations peuvent transformer une crise en résilience. 

Video thumbnail

Points clés à retenir

  • Recovery après sinistre est une opportunité de reconstruction. Recovery après un incident
    cybernétique ne se limite pas à la restauration des systèmes : c’est l’occasion de se reconstruire de manière plus solide et plus intelligente. 
  • Quatre piliers définissent le protocole Phoenix :
    Commvault AirGap, un environnement de reprise isolé, un plan de Recovery après sinistre informatique et des tests de chaos. 
  • La préparation prévient les défaillances. Une Recovery
    non rodée entraîne des erreurs, un manque de coordination et des interruptions prolongées. 
  • L’informatique fantôme augmente les risques : des actions de restauration
    non coordonnées en cas de crise peuvent réintroduire des logiciels malveillants et prolonger les temps d’arrêt. 
  • Cyber Recovery ≠ Reprise après sinistre : la reprise après sinistre
    traditionnelle échoue lors de cyberattaques, car les attaquants persistent et réinfectent les systèmes. 
  • Les tests de chaos renforcent la confiance :
    s’entraîner en situation de stress contribue à renforcer les équipes et à améliorer les résultats lorsque de véritables attaques se produisent. 

À propos de cette vidéo

Se remettre d’une cyberattaque est un défi, mais cela représente également une opportunité unique pour les organisations de se reconstruire avec une plus grande résilience. Cette discussion SHIFT 2025 présente le « Phoenix Protocol » – le cadre stratégique de Commvault conçu pour aider les entreprises à se relever plus fortes après une perturbation grâce à quatre piliers essentiels : Commvault AirGap, un environnement de reprise isolé, un plan de cyber-reprise et des tests de chaos continus.  

Pourquoi la cyber-Recovery est-elle différente ? Les
cyberattaques sont délibérées et adaptatives. Contrairement aux catastrophes naturelles, les attaquants tentent activement de réintégrer les systèmes, ce qui rend dangereuses les restaurations effectuées à la hâte ou non vérifiées. 

L’un des principaux problèmes réside dans le manque de préparation à la cyber-récupération à l’échelle du secteur. De nombreuses organisations ne planifient ni ne s’entraînent aux processus de récupération avant qu’une crise ne survienne, ce qui entraîne confusion, actions désorganisées et décisions informatiques parallèles. Ces efforts non coordonnés – tels que des restaurations de systèmes bien intentionnées – peuvent réintroduire par inadvertance des logiciels malveillants et prolonger les temps d’arrêt.  

Présentation du protocole Phoenix
Le protocole Phoenix est le cadre structuré de reprise après attaque de Commvault, conçu pour aider les organisations à sortir renforcées de la crise grâce à quatre piliers essentiels : Commvault AirGap, un environnement de reprise isolé, un plan de reprise après cyberattaque et des tests de chaos continus. 

Le coût d’un manque de préparation De
nombreuses organisations reportent la planification de la Recovery jusqu’à ce qu’un incident se produise. Cela entraîne de la confusion, des décisions prises en vase clos et des actions bien intentionnées qui aggravent les dégâts. 

Methodical Recovery, Focused on Security
The Phoenix Protocol emphasizes confinement, verification, and coordination, prioritizing safety over speed to enable clean recovery. 

La pratique renforce la résilience Les tests de
chaos dans des conditions réalistes mettent en évidence les faiblesses, valident les hypothèses et préparent les équipes à effectuer la reprise en toute confiance. 

Capacité

Commvault AirGap

Solution de stockage dans le cloud avec isolation physique (air-gap) permettant de réduire les risques et de protéger les sauvegardes critiques.

Découvrez Commvault AirGap À propos de Commvault AirGap
Capacité

Backup & Recovery

Backup and Recovery complète des charges de travail sur site, dans le cloud et en périphérie.

Découvrez Backup and Recovery À propos de Backup and Recovery
Capacité

Cleanroom

Environnements de Recovery isolés permettant une Recovery propre et validée. 

En savoir plus sur Cleanroom Recovery À propos de Cleanroom Recovery

Questions fréquemment posées

En quoi la reprise après une cyberattaque diffère-t-elle de la reprise après sinistre classique ?

Les incidents de cybersécurité impliquent des adversaires actifs et des infections cachées. Recovery doit être prudente et vérifiée pour éviter toute réinfection. 

Qu’est-ce que le protocole Phoenix ?

Il s’agit du cadre de reprise après attaque de Commvault, qui s’appuie sur Commvault AirGap, la reprise isolée, un plan de reprise après cyberattaque et des tests de chaos. 

Pourquoi les entreprises ont-elles du mal à mettre en œuvre la Recovery après cyberattaque ?

Beaucoup ne planifient ni ne s’entraînent à Recovery. Les équipes non préparées prennent souvent des mesures fragmentées qui propagent l’infection et retardent la restauration. 

Quel rôle jouent les tests de chaos ?

Les tests de chaos simulent les pressions réelles, aidant ainsi les équipes à valider leurs processus et à améliorer leur coordination avant qu’un incident ne se produise réellement. 

Comment Commvault AirGap et l’isolation améliorent-ils la Recovery ?

Ils contribuent à prévenir toute altération et permettent d’analyser et de restaurer en toute sécurité des systèmes sains sans risque de réinfection. 

Transcription

Voir la Transcription

Veuillez visionner la vidéo ici pour obtenir une transcription horodatée


Bienvenue à l’épisode du podcast SHIFT d’aujourd’hui, intitulé « Le protocole Phoenix : comment renaître de ses cendres
après une cyberattaque ». 

Je m’appelle Chris Dirado et je suis aujourd’hui accompagné de Michael Stempf. 

Michael, merci de vous joindre à moi aujourd’hui, j’ai vraiment hâte de discuter avec vous. 

Merci Chris. 

Lorsqu’une cyberattaque frappe, Recovery peut sembler insurmontable, mais c’est aussi l’occasion de se reconstruire
en devenant plus fort. 

Au cours de cette conversation, nous allons explorer le « Phoenix Protocol » et voir comment les quatre piliers de
Commvault peuvent vous aider à renaître de vos cendres. 

AirGap Protect, un environnement de Recovery isolé, un plan de Recovery après cyberattaque et, surtout
, des tests de résistance au chaos. 

Ensemble, nous verrons comment les organisations peuvent transformer cette crise en une
opportunité de renouveau et comment sortir vainqueurs d’une attaque. 

Alors, Michael, quelles sont les erreurs les plus courantes commises par les entreprises lors de la reprise
après une cyberattaque ? 

C’est une question piège. 

Le problème le plus courant que les gens rencontrent lors de la Recovery, c’est qu’ils ne la planifient pas avant que la
Recovery ne soit nécessaire. 

Il faut être préparé, n’est-ce pas ? 

On appelle souvent cet événement majeur un « bang », et les gens se concentrent sur ce qui se passe juste après
qu’il s’est produit. 

Mais si vous n’avez pas planifié, si vous ne vous êtes pas entraîné, si vous n’avez pas développé cette résistance mentale
en simulant le scénario encore et encore et en travaillant avec vos équipes, 

pour créer une expérience de cohésion d’équipe autour de cela, vous ne serez pas prêt. 

Après coup, ce que nous avons souvent observé, c’est que les gens essaient sincèrement de faire de leur mieux. 

Vous aurez un administrateur Windows qui veut simplement aider et remettre ses serveurs en
service ; il va donc agir un peu en solo, se lancer dans l’informatique parallèle et mettre en place ses propres 

systèmes. 

Et nous avons constaté à maintes reprises que, lorsqu’ils agissent ainsi, ils ne font que
réinfecter une nouvelle zone qui n’avait pas encore été touchée par l’attaquant, 

et il faut alors s’y attaquer à nouveau. 

On perpétue donc le problème en essayant de faire du bon travail. 

Et sans cette mise en pratique, sans ces tests dans le chaos dont vous parliez,
ils ne comprendront pas le véritable niveau de complexité et de sophistication dont font preuve ces 

malfaiteurs nous opposent. 

Et tu soulèves là un très bon point concernant les gens qui essaient simplement d’aider, mais
parfois… 

vous savez, elles vont un peu trop vite en besogne, n’est-ce pas ? 

En lançant des procédures de Recovery avant même d’être réellement prêts à le faire. 

Et je sais, d’après mon expérience et la vôtre aussi, que nous avons déjà été confrontés à de nombreux scénarios de Recovery
de ce type. 

Parfois, on travaille 60, 70, voire 80 heures par semaine. 

Le pire moment pour entreprendre quelque chose qui risque de ne pas aboutir, c’est quand on est déjà
à bout de souffle et qu’on tourne à plein régime, n’est-ce pas ? 

Donc, pour ma prochaine question, je voudrais parler de certaines idées fausses qui… 

vous savez, celles qui nous font croire que nous sommes à l’abri, mais en réalité, ce ne sont que
des idées reçues et elles ne nous aident pas vraiment au final. 

Pourriez-vous me donner quelques exemples de ces idées fausses ? 

Oui, je pense que la première et la plus importante, c’est que tout le monde dispose d’un plan de reprise après sinistre. 

Ils en ont depuis des années. 

Ils les ont testés pendant des années. 

Et les cyberattaques ne sont qu’une catastrophe de plus, du moins c’est ce qu’ils croient. 

Le problème, c’est que la reprise après sinistre repose entièrement sur la rapidité et l’efficacité. 

Exactement. 

Qu’il s’agisse d’une catastrophe naturelle, 

une tornade, un ouragan, peu importe de quoi il s’agit. 

Et il n’y a aucune intention malveillante. 

Et quand on passe au domaine cybernétique, la rapidité et l’intensité signifient tout simplement que l’on va réinfecter
l’environnement. 

Il faut y aller doucement, il faut être méthodique, il faut tenir compte de cette malveillance,
de la présence d’un acteur malveillant. 

Et donc, utiliser un plan spécialement conçu pour vous permettre de reprendre vos activités le
plus vite possible ne fera que causer des problèmes. 

Il faut donc ralentir, prendre le temps de respirer. 

Il faut disposer d’un plan de reprise après incident cybernétique, qui repose peut-être en grande partie sur les principes de la
reprise après sinistre, mais dont l’objectif ultime est de revenir à un état propre, et non de 

reprendre le plus vite possible. 

C’est donc vraiment l’élément principal. 

Mais il y a tellement d’autres éléments qui vont de pair avec cela. 

Vous savez, avant tout, j’ai vu à peu près tout ce qu’il est possible de détruire lors d’une
cyberattaque. 

Et l’un des facteurs qui précèdent ce genre de situation est que tout le monde a 

tout est aujourd’hui relié à un système de gestion des identités, comme Active Directory. 

D’après les dernières statistiques, Active Directory est présent dans 98 % des entreprises et est la cible de
92 % de toutes les cyberattaques. 

C’est évident, n’est-ce pas ? 

Une fois que l’on est dans Active Directory, on peut aller n’importe où. 

C’est la clé du royaume. 

C’est pourquoi je recommande toujours de mettre en place votre dernière ligne de défense, c’est-à-dire de sortir
votre système de protection des données d’Active Directory, 

car c’est l’une des tactiques courantes des cybercriminels : ils savent que si votre système de protection
des données résiste à l’attaque, il y a de fortes chances que vous ne payiez pas. 

C’est comme ça qu’on évite de payer. 

Tout à fait. 

L’une des choses que nous conseillons, c’est de retirer votre système de protection des données d’Active Directory, de le rendre
autonome, de le séparer et de l’isoler autant que possible. 

Ainsi, même si une grande partie de votre entreprise est détruite, ce système continuera de fonctionner. 

Petite remarque : Michael a soulevé un 

remarque à ce sujet concernant un plan de reprise après cyberattaque. 

Au cours de certaines des sessions que j’ai animées, j’ai constaté que beaucoup de gens n’avaient pas de plan de Recovery
après sinistre informatique. 

Eh bien, chez Commvault, nous avons ce qu’il vous faut. 

Si vous vous rendez sur notre plateforme de Readiness et que vous recherchez un plan de Recovery après incident cybernétique, vous pouvez télécharger
notre modèle et l’adapter à vos besoins. 

Et comme l’a dit Michael, certains éléments figureront déjà dans votre plan de reprise après sinistre. 

N’hésitez pas à reprendre ces éléments, d’accord ? 

Copiez-collez. 

Mais c’est vraiment le fait de disposer d’un plan de Recovery après sinistre informatique qui vous aidera à vous en sortir si vous vous retrouvez
dans l’une de ces situations. 

Michael, en quoi les attentes en matière de Recovery ont-elles évolué, passant du simple rétablissement des données à la reprise de
l’activité ? 

Bonne question. 

Vous savez, la plupart des gens prévoient des restaurations de type « un Z » ou « deux Z ». 

J’ai quelques fichiers ici. 

J’ai un serveur ici. 

Et on peut prévoir ça, n’est-ce pas ? 

C’est très mathématique, n’est-ce pas ? 

Pour une reprise après sinistre (DR). 

J’ai un étage. 

J’ai un serveur. 

J’ai un bâtiment. 

Je dois savoir quelle quantité de données il y a, quelle bande passante j’ai vers le prochain 

site, géographiquement dispersé, et je peux simuler des scénarios toute la journée à ce sujet. 

Le problème avec un incident cybernétique, c’est que j’en ignore l’ampleur, n’est-ce pas ? 

Combien de serveurs ont été touchés au sein de cette organisation ? 

Combien de sites ont été touchés ? 

J’ai eu un client qui a été touché. 

Il disposait de 99 sites à travers le monde, et le cybercriminel a détruit ces 99 sites partout dans le monde. 

Ainsi, toutes les copies de données qu’ils possédaient, où qu’elles se trouvent, ont été complètement détruites. 

Analyser la situation, concevoir un plan, le tester et s’entraîner à le mettre en œuvre font vraiment partie des
choses les plus importantes ici ; vous devez donc vous assurer de l’aborder différemment 

que vous l’envisagiez différemment, car les conséquences seront toujours différentes. 

Et vous soulevez là un point vraiment important. 

Il existe trois types distincts d’opérations de Recovery que nous planifions correctement : 

La reprise opérationnelle, la reprise après sinistre et la reprise après une cyberattaque. 

Pourriez-vous nous en dire un peu plus sur chacune d’entre elles, en quoi elles diffèrent et en
quoi 

empêche réellement les clients de se remettre d’un incident cybernétique ? 

Bien sûr. 

La reprise Recovery, c’est le cas classique : j’ai supprimé un fichier, vous disposez d’une copie locale à partir de laquelle
vous pouvez le restaurer, c’est ultra-rapide, facile à faire, automatisé dans la plupart des cas, il suffit simplement d’ 

et… 

J’allais dire qu’ici, chez Commvault, nous avons tous la possibilité d’effectuer nos propres restaurations sur
nos ordinateurs portables. 

Je suis sûr que dans la plupart des entreprises, c’est simple, n’est-ce pas ? 

C’est une procédure simple. 

Tout à fait. 

Recovery après sinistre, en cas de catastrophes naturelles, 

et c’est très sophistiqué. 

Nous le faisons depuis plus de 30 ans, en effectuant des tests trimestriels dans la plupart des sites. 

En fait, on l’a tellement fait que les gens sont devenus négligents en matière de reprise après sinistre. 

Ils ne font plus vraiment de tests. 

Ce qu’ils font généralement maintenant, c’est basculer leur centre de données d’un site à l’autre
tous les six mois et dire : « Tiens, on est en production. » 

C’est un bon test. 

Mais pour ce dernier point, celui lié à la cybersécurité, certaines mesures spécifiques sont nécessaires. 

Premièrement, et je pense que c’est le plus important, il faut une troisième copie des données. 

Une troisième copie des données hébergée sur l’infrastructure d’un tiers, car, vous savez, les
pirates auront accès à Active Directory, ils auront tout votre environnement, 

ils disposeront de tous vos identifiants cloud. 

Donc, se contenter de cette deuxième copie de données, que l’on disperserait
normalement géographiquement, ne constitue pas une protection suffisante. 

Vous devez donc vous assurer qu’elle se trouve derrière l’infrastructure d’un tiers, qu’elle est
immuable et indélébile. 

La fonction « indélébile » impose une gouvernance pour garantir que 

personne, pas même avec des identifiants privilégiés qu’il aurait pu obtenir depuis Active Directory, ne puisse modifier
ou supprimer ces données. 

Ce sont ces données qui nous sauveront la mise en cas d’attaque. 

Nous savons qu’elles seront bien là le moment venu, car elles ne peuvent pas être supprimées, comme vous l’avez dit, elles
ne peuvent pas être modifiées et elles doivent répondre à des exigences strictes. 

Et pour qu’un acteur malveillant puisse s’en emparer, il ne suffirait pas qu’il pirate votre
organisation, il devrait également pirater la nôtre, n’est-ce pas ? 

Il s’agit donc en réalité d’une attaque à deux volets qu’il lui faudrait mener à bien. 

Donc, avec ça… 

nous savons que nous pouvons disposer d’une copie sûre et sécurisée de nos données. 

Où devrions-nous restaurer ces données en cas de cyberattaque ? 

C’est le point auquel personne ne pense jamais, n’est-ce pas ? 

Environ 17 % de toutes les attaques sont des attaques destructrices, où les pirates s’introduisent dans le micrologiciel et
le BIOS des serveurs, et il est alors impossible de les restaurer. 

Mais cela fait partie du plan de tout le monde. 

Je vais revenir exactement à la source du problème. 

Et aujourd’hui, même si ces 17 % représentent un chiffre relativement faible, la plupart des RSSI 

comme on ne sait pas s’il s’agissait d’une attaque destructrice, se disent : « Je dois partir du principe que c’en est
une. » 

Ainsi, la plupart des entreprises ne disposent pas d’un plan prévoyant 50 serveurs prêts à l’emploi sur leur quai.
 

C’est pourquoi, dans le contexte actuel, il est indispensable de disposer d’un environnement de Recovery isolé. 

D’une part, c’est un endroit sûr où je peux effectuer la reprise, et d’autre part, c’est un environnement que je peux mettre
en production et dont je sais que le pirate n’y a pas accès. 

C’est donc l’un de ces domaines clés dont vous parliez tout à l’heure : 

un environnement de reprise isolé – que nous appelons « salle blanche » – est essentiel à la cyber-résilience
. 

Bien sûr, nous disposons désormais d’un bon système : nous savons que nous avons des copies de nos données, en sécurité, et nous disposons désormais
d’un emplacement où nous pouvons stocker ces données ; et comme vous l’avez souligné plus tôt, nous pouvons nettoyer 

et purger ces données avant de les transférer en production. 

Et l’une des fonctionnalités de Commvault qui, selon moi, n’est pas suffisamment mise en avant, c’est notre
portabilité « any-to-any », n’est-ce pas ? 

Car comme vous l’avez dit, vous pouvez être victime d’une attaque destructrice sur site ; dans ce cas, vous devez changer de
stratégie, n’est-ce pas ? 

Il faut… 

vous devez aller ailleurs. Combien de temps faut-il pour obtenir du nouveau matériel ? 

Six semaines peut-être ? 

Vous ne pouvez pas rester inactif pendant six semaines sans serveurs de production. 

Vous pouvez transférer vos charges de travail vers le fournisseur de cloud de votre choix ou vers un autre hyperviseur, ce qui
vous offre une réelle flexibilité pour vous remettre d’une de ces attaques. 

C’est en fait l’un des principaux atouts de
Commvault par rapport à ses concurrents, dont on ne parle jamais vraiment : le fait que nous proposons depuis des années des solutions « any-to-any ». 

Donc, si vous souhaitez… 

disposer d’un environnement VMware sur site, puis de le transférer vers un environnement AWS EC2, tout
se fait de manière entièrement automatique. 

Cela se fait lors de la restauration, je n’ai à m’en soucier en aucune manière. 

Et la gamme des différentes possibilités de migration « de n’importe quelle plateforme vers
n’importe quelle autre » que nous proposons est absolument incroyable et surpasse de loin celle de n’importe quel autre acteur du secteur. 

Oui, nous offrons vraiment à nos clients toutes les options dont ils pourraient rêver, n’est-ce pas, en la
matière ? 

Tout à fait. 

Très bien, changeons de sujet. 

Quels sont les défis que vous rencontrez le plus souvent en ce moment avec ces cyberattaques ? 

Le principal problème, c’est le manque de préparation. 

On traite ça comme une catastrophe. 

Quand on parle de reprise après sinistre et de Recovery, on dispose
généralement d’un administrateur chargé des sauvegardes, n’est-ce pas ? 

Et cette personne, dans ce cas-là, 

je les appelle toujours ainsi, est considérée comme une sorte de dieu, n’est-ce pas ? 

Mais quand on en arrive à la phase de Recovery après sinistre, c’est plutôt : « Ne vous approchez pas de cette personne,
restez à l’écart, contentez-vous de lui apporter à manger et à boire de temps en temps, et laissez-la faire, 

car elle a élaboré le plan depuis une éternité. 

Et tout reposait sur ses épaules. 

Le problème, c’est que cette personne n’a pratiquement aucune responsabilité en cas de cyberattaque. 

Elle ne peut pas se contenter de commencer à restaurer les données, car cela déclencherait une phase de réinfection. 

Il faut collaborer avec vos équipes de sécurité, vos équipes informatiques, vos services juridiques, vos équipes de communication ;
toutes ces personnes doivent travailler ensemble, alors qu’elles ne l’ont jamais fait auparavant. 

Et j’aime toujours plaisanter en disant que la dernière fois que votre équipe de sécurité et votre équipe
informatique se sont retrouvées, c’était probablement lorsqu’elles se sont affrontées lors d’un match de baseball organisé dans le cadre d’un 

Événement. 

Elles sont toujours adversaires, jamais dans la même équipe. 

Mais en cas de cyberincident, si je suis la personne de secours, je… 

je n’ai pas l’autorité nécessaire pour procéder à une Recovery tant qu’un membre de l’équipe de sécurité ne m’a pas donné l’ordre de
le faire. 

Et les responsables de la sécurité ne peuvent pas faire ce qu’ils doivent faire tant qu’un membre de l’équipe informatique ne les y oblige
pas. 

C’est donc cette idée de freins et contrepoids, un concept totalement étranger à toute procédure de Recovery de données
avant les incidents de cybersécurité. 

Oui, et tu sais, ce qui me fait sourire, c’est que… pense à la dernière fois où tu as eu
affaire à un administrateur de sauvegarde, d’accord ? 

C’était probablement du genre : « Tiens, j’ai perdu un e-mail ou une feuille de calcul », et qu’ont-ils fait ? 

Il l’a restauré en quelques minutes, n’est-ce pas ? 

Or, comme vous le soulignez, il ne peut plus le faire. 

Ils ne peuvent pas faire ça parce qu’on ne sait pas ce qui a été corrompu. 

Vous ne savez pas s’ils ont touché une douzaine de serveurs, s’ils ont touché l’ensemble du parc ESX, et vous
ne pouvez pas vous contenter de commencer à restaurer des données, car cela vous ramènerait tout simplement à la case départ. 

Il faut vraiment que ce soit un travail d’équipe, n’est-ce pas ? 

Tout le monde doit finalement se rassembler, travailler ensemble, mettre la main à la pâte pour remettre l’organisation
sur pied. 

Tout à fait d’accord. 

Quelles sont donc les principales leçons que les organisations ont tirées après avoir subi une
cyberattaque ? 

Les leçons tirées varient. 

Elles sont très variées. 

Je pense que le plus important, et cela apparaît généralement après la deuxième attaque (il
est très courant de subir jusqu’à quatre attaques par an environ), c’est qu’il est impossible de vraiment prévoir ce genre d’événement. 

Vous ne pourrez pas mettre en place des scénarios qui se dérouleront exactement comme vous
l’imaginez lorsque cet incident informatique se produira. 

Il y a tellement de variables différentes. 

Voici le problème : en matière de Recovery, il est très facile de se préparer à une tornade. 

Une tornade va probablement détruire un bâtiment. 

Une inondation peut détruire… 

peut-être les niveaux inférieurs d’un bâtiment, mais c’est prévisible, ça peut faire l’objet de simulations, je peux intervenir et m’en occuper
. 

En matière de cybersécurité, les moyens d’attaque sont extrêmement variés. 

Tant de façons différentes de s’introduire, tant de façons de détruire des informations. 

D’ailleurs, de nos jours, il ne s’agit même plus tant que ça des ransomwares, n’est-ce pas ? 

On assiste à des attaques simplement parce que quelqu’un veut éliminer un concurrent, ou qu’un
gouvernement veut en éliminer un autre. 

Il s’agit là d’une pure intention malveillante, sans autre but que de détruire
son ennemi. 

C’est difficile à anticiper. 

C’est vrai. 

Et donc, ce qu’il nous faut, c’est vraiment intégrer cette théorie du chaos dans nos tests. 

Une chose que j’aime toujours faire lorsque je participe à ces tests, c’est qu’ils
ont toujours une liste prédéfinie des cibles à attaquer, n’est-ce pas ? 

Ils savent toujours exactement de quels serveurs il s’agit, et ce qui est appréciable, c’est qu’ils font toujours participer à nos réunions toutes les personnes
responsables de ces serveurs. 

Tout à fait. 

Et l’une des choses que j’aime toujours faire, c’est d’écrire les noms des serveurs au dos
de cartes à jouer, 

puis je lance ces cartes contre le mur et celles qui atterrissent face visible sont celles
qui viennent d’être touchées. 

C’est donc un excellent moyen d’introduire cette méthodologie du chaos ici pour pouvoir tester. 

Et une fois que vous avez effectué des tests selon tant de scénarios chaotiques différents, je ne dirais pas que vous êtes
prêts à faire face à cette attaque, mais vous avez une idée et une compréhension de l’impact 

et comment vous pourrez mieux vous en remettre. 

Ouais, et tu connais ton point de basculement, pas vrai ? 

Hé, si je sais que si X se produit, je vais pivoter vers Y, c’est ça ? 

Si je sais que si je fais Y et que ça ne marche pas, je vais passer à Z. 

Et je pense qu’on ne peut pas être prêt pour tous ces scénarios, mais plus on est
préparé à en affronter quand ça arrive vraiment, plus c’est une question de mémoire musculaire, n’est-ce pas ? 

Du genre : « Tiens, je sais qu’on va y arriver parce que je m’y suis préparé, j’ai
anticipé toutes ces situations. » 

Je sais qu’il y a quelques années, le FBI disait : « Si vous êtes victime d’une cyberattaque,
vous devez suivre cette série de procédures. » 

Et puis, un an plus tard, ils ont changé ça pour dire : 

« lorsque vous êtes victime d’une cyberattaque, vous devez faire ceci ». 

Et cette année, ils disent : « Vu le nombre de fois où vous allez être victime d’une cyberattaque
, vous devez être prêts, vous devez vous y préparer. » 

Pouvez-vous nous en dire un peu plus sur ce à quoi ressemble cette préparation dans ce contexte ? 

Oui, c’est fréquent, et je pense donc que la première chose à faire pour se préparer, c’est de changer
d’état d’esprit. 

Et ce changement de mentalité ne porte pas sur le « si », le « quand » ou la « fréquence », mais consiste plutôt à
partir du principe que j’ai déjà été victime d’une intrusion. 

Vous savez, on aime bien plaisanter en disant qu’il existe deux types d’entreprises dans ce monde. 

Celles qui savent qu’elles ont été piratées et celles qui ne le savent pas. 

Et même si ce n’est pas tout à fait vrai, soyons honnêtes : l’année dernière aux États-Unis, seules 60 % des entreprises ont
subi une intrusion, n’est-ce pas ? 

Vous aviez donc une chance, 40 % de chances, de ne pas avoir été piratées, mais ça ne concernait qu’une seule
année. 

Oui, vous avez eu de la chance. 

Mais si vous adoptez l’état d’esprit selon lequel vous partez du principe qu’une violation a eu lieu, 

lorsque j’irai travailler demain, je prendrai des décisions différentes. 

Je vais voir les choses différemment, je vais les analyser différemment, et j’espère pouvoir
lancer ce processus de cohésion d’équipe en faisant intervenir les services informatiques et juridiques, et 

aborder des sujets dont je n’aurais normalement pas discuté avec eux. 

C’est drôle, vous avez dit que 60 % des organisations avaient été victimes d’une violation de données. 

Voici le problème : j’ai lu une statistique l’autre jour selon laquelle une cyberattaque se produira toutes
les 14 secondes en 2025. 

Ce chiffre me semble complètement fou. 

Un autre chiffre vraiment stupéfiant est que la cybercriminalité devrait atteindre 10 500
milliards de dollars cette année. 

Donc, même si cela ne concerne que 60 % des entreprises aux États-Unis, on n’atteint
pas 10 000 milliards de dollars sans cibler tout le monde, n’est-ce pas ? 

Ce n’est pas comme si elles ne visaient que le 1 % des grandes entreprises, n’est-ce pas ? 

Ils ciblent tout le monde. 

Pour mettre les choses en perspective : 10 000 milliards de dollars, si on considère ce chiffre du point de vue du PIB des
pays du monde entier, cela correspondrait au troisième plus grand pays du monde. 

C’est incroyable. 

La cybercriminalité, le troisième plus grand pays du monde. 

C’est incroyable. 

Bon, je pense qu’il est temps de changer de sujet, n’est-ce pas ? 

Nous avons donc beaucoup parlé des aspects négatifs, des nombreuses difficultés. 

Voyons maintenant comment réduire ce délai de 24 jours. 

Voyons ce que les clients peuvent faire non seulement pour se remettre de ces attaques, mais aussi pour y répondre
et peut-être même en sortir renforcés. 

C’est ce que nous appelons nos quatre piliers. 

C’est très important. 

Tout d’abord, vous devez disposer d’une copie tertiaire de vos données hébergée sur l’infrastructure d’un tiers
. 

Vous disposez ainsi d’une copie propre, immuable et indélébile. 

Il faut disposer d’un emplacement où la restaurer, c’est-à-dire un environnement de Recovery isolé. 

Nous appelons le nôtre « salle blanche ». 

Cela vous permet, euh, d’effectuer des tests, ce qui est primordial. 

Nous ne parviendrons pas à réduire ce délai de 24 jours, même en appliquant ces méthodes, si nous ne réalisons pas de
tests. 

Il faut donc disposer d’un lieu dédié aux tests, car on ne peut pas interrompre la production. 

On peut également y effectuer des analyses forensiques. 

Souvent, par exemple, vous n’êtes même pas victime d’une attaque, mais vous mettez en place un nouvel
outil de cybersécurité et vous souhaitez le tester au sein de votre organisation. 

Vous ne voulez pas simplement lâcher un logiciel malveillant dans votre environnement pour voir comment il le détecte. 

Et vous ne souhaitez pas non plus vous retrouver dans un environnement stérile qui ne ressemble en rien
à votre environnement de production. 

Grâce à Commvault Cleanroom, je peux donc restaurer mon environnement dans un emplacement sécurisé, 

et j’y lancer un logiciel malveillant pour observer comment cette solution de cybersécurité réagit. 

D’un autre côté, si vous êtes victime d’une attaque – comme cela m’est arrivé une fois, où il ne s’agissait pas d’une
attaque destructrice –, une fois le feu vert obtenu, nous pouvions procéder à la restauration des données, mais le gouvernement des 

est intervenu en déclarant : « Vous ne pouvez pas procéder à la restauration pour le moment. » 

Nous n’avions jamais vu cet acteur malveillant ni ce type d’attaque. 

Ils ont donc souhaité mener leur propre analyse médico-légale. 

Rapidement, quel était leur SLA dans ce cas-là ? 

Ouais, ils ont complètement dépassé le… 

Oui, bien sûr, n’est-ce pas ? 

Il n’y a pas de SLA quand c’est le gouvernement qui s’en charge. 

Non, pas du tout. 

Ça nous a pris deux semaines. 

Deux semaines pour que le gouvernement mène ses recherches. 

Ça aurait donc été génial si j’avais eu Commvault Cleanroom et que j’avais pu restaurer
ces machines dans cet environnement en disant : « Tenez, prenez tout le temps qu’il vous faut. 

Allez-y, faites vos évaluations, réglez vos problèmes. 

Nous, on va se remettre au travail. 

Ouais, génial. 

Vraiment génial. 

Du coup, j’ai de bonnes données. 

J’ai un espace propre où je peux transférer ces données. 

La prochaine étape, et la plus importante, c’est le plan de Recovery après sinistre informatique, dont on a déjà parlé, ce qui
est super. 

Tout y sera détaillé, mais il y a certains éléments qui doivent figurer dans ce plan de Recovery après sinistre informatique
et qui sont, par nature, très difficiles à obtenir. 

Il s’agit donc de recenser l’ensemble de vos applications. 

Si je ne restaure que quelques fichiers à partir d’un serveur de fichiers, cela m’importe peu. 

Si je remets en service, disons, Epic pour un environnement de soins de santé, et qu’il comporte 32
serveurs différents qui interagissent tous entre eux, alors 

je dois tous les remettre en service. 

Je dois les remettre tous en état de fonctionnement de manière cohérente. 

Et j’espère que vous avez effectué un audit pour le déterminer, afin d’établir la cartographie de vos applications. 

Il existe des outils pour vous aider à le faire, mais pour être honnête, c’est un processus très difficile
. 

Oui, comment savoir que 32 serveurs alimentent une seule machine, n’est-ce pas ? 

Et la plupart des gens se disent : « Eh bien, on le sait parce qu’on va remettre en service nos serveurs de niveau 1
. » 

Eh bien, le problème, c’est qu’un serveur de niveau 1 ne fonctionne que si vous disposez d’un ensemble de serveurs de niveaux 3
et 4 qui lui fournissent effectivement les données 

dont il a besoin. 

Et donc, la seule façon d’y parvenir, c’est grâce à cette quatrième étape, qui consiste à tester en conditions de chaos. 

Je dois entrer dans la salle blanche. 

Je dois m’assurer que je procède bien aux Recoverys, les randomiser, voir ce qui se passe, voir ce qui fonctionne
et ce qui ne fonctionne pas après cette randomisation. 

D’accord, peut-être que seules 32 machines ont été touchées, mais je vais devoir en remettre 142
en service à cause de toutes les dépendances existantes. 

Ce sont vraiment ces quatre éléments : la barrière physique, la salle blanche ou l’environnement de Recovery
isolé, 

un plan de reprise après sinistre informatique, puis tester tout cela, car un plan de reprise après sinistre informatique n’est qu’un
bout de papier tant qu’on ne l’a pas mis à l’épreuve. 

Tout à fait, c’est vrai. 

Ce n’est qu’un document tant qu’on ne l’a pas mis à l’épreuve. 

Et parmi les tests que je recommanderais, il y a ceux que les clients devraient réaliser eux-mêmes : des exercices sur
table, par exemple, se réunir dans une salle de réunion pour discuter de ce qui se passerait si nous étions victimes d’un rançongiciel, et déterminer 

allons-nous faire en premier, en deuxième et en troisième lieu ? 

À quel moment allons-nous même déclencher notre plan de Recovery après sinistre informatique ? 

Mais j’irais même un peu plus loin, vous voyez ? 

Il faut en fait procéder à un exercice pratique de Recovery après incident cybernétique. 

Tout à fait. 

Tiens, j’ai cet outil qui s’appelle AirGap Protect, j’ai cet autre qui s’appelle Cleanroom, alors
mettons-les à l’épreuve : c’est à l’usage qu’on voit si ça marche, n’est-ce pas ? 

Assurons-nous de pouvoir restaurer ces charges de travail à partir de cette copie tertiaire des données vers ce
Cleanroom, car c’est ça le véritable test, n’est-ce pas ? 

Je peux remettre mon entreprise sur pied. 

Ce qui m’amène à ma question suivante : comment les entreprises déterminent-elles ce qu’elles
vont mettre en place en deuxième et troisième phases ? 

J’ai souvent entendu parler de ce terme, la « viabilité minimale ». 

Je suppose que cela varie d’une organisation à l’autre. 

Comment cela s’inscrit-il dans ces quatre piliers ? 

C’est différent pour chaque organisation, n’est-ce pas, selon le secteur d’activité dans lequel on
évolue. 

Et la seule façon de le savoir, c’est de faire des tests. 

Sans cela, on ne peut pas le savoir. 

Très souvent, les gens pensent savoir ce qui doit aller où et comment. 

Et sans ces tests, que nous avons menés pendant des années dans le cadre de la reprise après sinistre, nous disposons donc du
processus. 

Nous ne l’avons tout simplement pas appliqué. 

Je veux dire, voilà ce qui est fou. 

Depuis des années, 30 ans, nous effectuons des tests trimestriels pour la reprise après sinistre et les plans de reprise après sinistre
, et pourtant moins de 1 % de toutes les entreprises ayant jamais existé ont déclaré un 

sinistre et, comme nous l’avons dit plus tôt, 60 % de toutes les entreprises américaines ont subi une violation de données l’année
dernière, et personne ne teste les procédures pour y faire face. 

Personne ne teste cela parce que c’est complexe, n’est-ce pas ? 

Il faut un doctorat pour comprendre la différence entre la reprise après sinistre informatique et la reprise après sinistre classique, ce que tout le monde peut
faire de nos jours. 

Bien sûr. 

Oui, et c’est un peu comme si on se disait : « Mais comment savoir ce que je teste exactement lors d’un incident de cyber-Recovery
? », n’est-ce pas ? 

Et je pense que, vous savez, nos clients ici chez Commvault ont vraiment de la chance. 

Nous venons de lancer ce nouveau service, le service Guardian, car, vous savez, nous comprenons bien que cela
ne se fait pas du jour au lendemain, n’est-ce pas ? 

Si on voulait être cyber-résilients dès demain, on le serait, mais ce n’est tout simplement pas si simple,
n’est-ce pas ? 

C’est un parcours. 

Cela prend du temps. 

Dans de nombreux cas, vous aurez le plus souvent besoin d’aide. 

Et je pense que ce nouveau service a pour objectif d’aider véritablement les clients 

franchir cette nouvelle étape dans leur parcours vers la cyber-résilience. 

De plus, grâce à notre plateforme « readi verse », comme beaucoup de gens ne savent pas comment mener correctement un
exercice sur table, nous proposons désormais deux parcours, l’un destiné aux dirigeants et l’autre aux techniciens, pour un 

simulation sur table portant sur des incidents cybernétiques. 

Mais comme vous l’avez dit, ce n’est que la première étape. 

Il faut maintenant passer à la pratique. 

Dans l’armée, on appelle cela la boucle OODA : Observer, S’orienter, Décider et Agir. 

Il s’agit d’un processus répétitif 

en testant constamment quelque chose, en l’évaluant, en le modifiant, puis en le testant à nouveau. 

De cette façon, on est mieux préparé lorsque quelque chose se produit réellement. 

Eh bien, vous avez traversé tant de cycles de tests, de changements et de façons de faire
que cela devient presque un test de plus pour vous. 

Bien sûr. 

Et c’est comme ça qu’on se relève vraiment, n’est-ce pas ? 

Donc, avec ces quatre piliers : la protection par isolation physique, la salle blanche, votre plan de Recovery après incident cybernétique,
et enfin les tests en conditions de chaos, c’est ça ? 

Et nous… 

nous nous alignons parfaitement sur ces principes, comme vous l’avez dit. 

Nous disposons de copies sûres et sécurisées de nos données. 

Nous avons l’emplacement où nos données seront restaurées. 

D’ailleurs, si vous avez besoin d’un plan de Recovery après sinistre informatique, n’hésitez pas à le télécharger sur Readiverse, comme je
l’ai mentionné, et à l’adapter à vos besoins. 

Et enfin, si vous avez besoin d’aide en cours de route, nous sommes là
pour vous avec le service Guardian. 

Michael, merci de nous avoir accordé un peu de votre temps aujourd’hui. 

C’était vraiment très instructif. 

Merci, Chris. 

Et voilà qui conclut notre conversation sur le protocole Phoenix et sur la manière dont les quatre
piliers de la cyber-résilience de Commvault aident réellement les clients à renaître de leurs cendres après une 

.