Présentation du MTCR : l’indicateur manquant pour Cyber Recovery

Le MTCR mesure le temps nécessaire pour restaurer les systèmes et les données de manière fiable — c’est-à-dire sans logiciels malveillants, sans altération des données ni traces persistantes   après une cyberattaque. 

Les indicateurs RTO et RPO mesurent la durée et la perte de données. L’indicateur MTCR mesure le niveau de confiance. Une Recovery rapide n’a aucun sens si les menaces persistent. 

Cela implique de vérifier les sauvegardes,à rechercherles menaces cachées et de valider les charges de travail restaurées — ce qui est bien plus complexe qu’un simple basculement. 

Les pirates corrompent de plus en plus souvent les sauvegardes et effacent leurs traces, ce qui fait de l’identification des données saines l’étape la plus longue du processus de Recovery. 

Cela fournit aux dirigeants un indicateur concret de la qualité de la Recovery, leur permettant ainsi d’investir et de se préparer de manière plus éclairée. 

Veuillez regarder la vidéoicipour accéder à la transcription horodatée

Bienvenue à notre discussion sur une nouvelle façon d’envisager la cyber-résilience : le « Mean Time to Clean »
« Recovery » (MTCR).

Je suis accompagné de deux experts à l’origine de ce concept de MTCR : Darren Thomson, directeur technique sur le terrain chez
Commvault, qui travaille en étroite collaboration avec des organisations de tous les secteurs sur les stratégies de résilience et

stratégies, et Duncan Bradley, responsable du pôle Sécurité et résilience pour le Royaume-Uni et l’Irlande chez Kyndryl
. Ils sont à l’origine d’une réflexion novatrice et de pointe sur le MTCR. Et

Depuis des années, les entreprises évaluent le succès de leur plan de Recovery en fonction de la rapidité avec laquelle les systèmes peuvent être
restaurés.

Nous utilisons des acronymes tels que RTO et RPO : RTO (objectif de temps de reprise) et RPO (objectif de point
(de reprise).

Mais dans le contexte actuel des menaces, nous savons que la rapidité à elle seule n’est pas synonyme de sécurité et ne garantit pas
et non la réussite de la « Recovery ».

Si les données que vous restaurez ne sont pas valides et fiables, vous risquez de transformer votre Recovery en
une nouvelle attaque.

Bonjour.

Je m’appelle Danielle Sheer, directrice de la confiance chez Commvault.

Je consacre une grande partie de mon temps à aider les conseils d’administration et les dirigeants à comprendre que le risque cyber est
indissociable du risque lié à l’activité.

Je suis ravie d’animer la discussion d’aujourd’hui et d’expliquer pourquoi ce nouveau concept, le MTCR,
Ce n’est pas simplement un indicateur technique de plus, mais bien la norme d’entreprise qui a désormais sa place dans la

salle du conseil d’administration.

C’est parti.

Oui, merci Danielle.

Et merci pour cette excellente introduction.

En cette année 2025, au Royaume-Uni en particulier, mais aussi partout dans le monde,
notamment en Europe, nous avons assisté à une série d’attaques ciblées contre le secteur de la vente au détail.

Et nous avons pu constater de nos propres yeux à quel point il a été difficile pour ces commerçants de rester en contact
avec leurs clients et, surtout, de remettre leurs systèmes sur pied.

Cette année, j’ai été personnellement impliqué dans une attaque bien particulière qui a débuté vers la mi-avril
2025.

Et juste pour vous donner une petite idée du calendrier suivi par cette entreprise
pour se remettre sur pied.

Au mois d’avril, il s’est essentiellement agi d’un incident lié à un rançongiciel.

Et pendant cette période, l’entreprise a fait un excellent travail pour, sinon mettre fin à cette
incident, ou du moins l’isoler et en endiguer la propagation.

Au cours du mois de mai, elle s’est attachée à confirmer la nature et l’ampleur de l’attaque, ce que
C’est ce qu’on appelle son « rayon d’action ».

Et elle a commencé à s’exprimer à ce sujet.

Puis, de mai jusqu’au début du mois d’août, s’est déroulée la Recovery effective des systèmes.

En d’autres termes, cela a pris près de trois mois, jusqu’au mois d’août, puis il
Il n’y a eu qu’une reprise progressive, une sorte d’approche par étapes pour remettre les systèmes en service.

Alors pourquoi tout ce temps, vous savez, trois mois, pour remettre cette entreprise sur les rails ?
ligne ?

Eh bien, une grande partie de ce temps a été consacrée à la recherche de données fiables, de données « propres ».

Des systèmes fiables sur lesquels l’entreprise pouvait compter pour renouer le contact avec ses
des clients et de générer à nouveau des revenus en tant que détaillant.

Et c’est justement cette période de trois mois qui illustre ce dont nous voulons parler
ici.

L’entreprise doit commencer à poser un autre type de questions au service
l’informatique afin d’en arriver à un stade où l’on puisse non seulement miser sur la rapidité avec laquelle

restaurer les systèmes,

mais aussi des promesses concernant la qualité de ces systèmes, c’est-à-dire leur propreté
.

Sinon, je crains que nous continuions à constater qu’il faut généralement deux, trois,
voire parfois quatre ou cinq mois pour remettre les systèmes en service.

Vous savez, d’accord, c’est fascinant.

Vous nous avez donné matière à réflexion.

Duncan, permettez-moi maintenant de revenir au début.

Pourriez-vous nous donner la définition du MTCR ?

Expliquez-nous les cinq piliers et pourquoi c’est la bonne approche pour nous, dans ce
dans ce contexte, ce paysage semé d’embûches, pour évaluer le succès de Recovery.

Oui, bien sûr, Danielle.

Je pense que c’est vraiment important.

Nous avons imaginé le concept de « Mean Time to Recovery » (temps moyen de retour à la normale) afin d’en faire un indicateur
un métier compréhensible pour l’entreprise.

Il s’agit du temps nécessaire pour que les systèmes soient à nouveau opérationnels, comme le disait Darren.

Avec des données fiables, des systèmes opérationnels et prêts à reprendre la production.

La plupart des organisations se sont vraiment concentrées sur la disponibilité de leurs systèmes en ligne
sans comprendre que ces cyberattaques détruisent les données et les plateformes

qui sous-tendent ces opérations.

Ainsi, en cas d’incident nécessitant une reprise après une cyberattaque, il s’agit davantage de tout remettre en état
depuis le premier jour jusqu’au point de Recovery,

environnement sain.

Cela prend souvent plusieurs jours, comme l’expliquait Darren dans son exemple sur le commerce de détail.

Il faut ensuite reconstruire tous vos services essentiels.

Il faut ensuite remettre vos plateformes en ligne, puis y restaurer les données
saines.

Et très souvent, avec les types d’attaques que nous observons, les données sont corrompues depuis
des jours, voire des semaines, avant l’attaque.

Vous devez donc vérifier vos sauvegardes et réintégrer ces données valides dans l’environnement de production.

Ce MTCR (Mean Time to Clean Recovery, temps moyen de Recovery après nettoyage) est censé être un indicateur métier permettant de déterminer :

« Combien de temps pouvez-vous être indisponible ? »

Combien de temps seriez-vous hors service aujourd’hui si cet incident venait à se produire ?

Ce paramètre sert ensuite à inciter les services informatiques et de contrôle de la continuité à réduire ce délai
de Recovery.

En quoi le MTCR diffère-t-il des indicateurs traditionnels ?

On dirait qu’il regroupe en quelque sorte plusieurs indicateurs traditionnels en un seul indicateur plus global.

Eh bien, je pense que c’est là qu’interviennent les objectifs de délai de reprise.

Combien de temps faut-il pour remettre ce système en service ?

Cela ne tient pas compte du type de données présentes sur cette plateforme.

Vous savez, on utilise généralement la disponibilité comme critère.

Combien de temps faut-il pour basculer du centre de données A vers le centre de données B en cas de
Une attaque traditionnelle contre l’infrastructure ?

La récupération des données est une opération bien plus complexe.

Il ne s’agit pas simplement de récupérer un ensemble de données.

Il s’agit de remettre la plateforme en ligne.

Donc, si l’on pense aux services d’identité, il faut que l’identité fonctionne avant que quiconque puisse
accéder aux données.

Le simple fait de mesurer le temps nécessaire à la restauration d’une base de données

ne signifie pas pour autant que ce processus métier sera à nouveau opérationnel.

Et ce système est vraiment conçu pour regrouper les différents piliers de ces systèmes que vous
vous devez le remettre en service pour que le processus métier puisse fonctionner.

Et Danielle, si je peux me permettre, je pense que cela renvoie à un problème plus général.

Il est donc très facile de, euh, adopter une approche purement technique dans cette conversation.

Et en effet, cela constitue à bien des égards un moyen d’évaluer l’organisation technique.

Mais je pense que cela renvoie à un problème d’organisation.

Ce que nous constatons sans cesse, c’est que l’un des problèmes culturels liés à la remise
au service des systèmes, et l’une des raisons pour lesquelles cela prend tant de temps dans de nombreux cas, comme cela a été le cas dans mon

Par exemple, cela signifie qu’en réalité, nous avons affaire à deux équipes qui doivent assumer une
part de responsabilité.

Il y a bien sûr l’équipe chargée de l’infrastructure traditionnelle, dont les membres sont chargés
de la tâche de Backup and Recovery ; ils ont clairement un rôle à jouer, mais ils ne sont plus les seuls.

Il y a également l’équipe de sécurité.

Une équipe capable de vous indiquer, grâce à une analyse forensic par exemple, où se trouve la sauvegarde intacte, où se trouvent les
données intactes, dans quel état sont les systèmes infectés : voilà ce qu’est une équipe de sécurité.

Ainsi, lorsque ces équipes ne collaborent pas sur Recovery, ou qu’elles parlent des langues différentes
, ou qu’elles évaluent leurs performances selon des critères divergents, un problème commence à se poser

Et cela commence par la culture d’entreprise.

Une façon d’aborder cela consiste à prendre le RPO et le RPO (objectif de temps de récupération),

Combien de temps cela va-t-il me prendre pour récupérer mes données ?

L’objectif de point de reprise (RPO) : quelle quantité de données suis-je susceptible d’utiliser ?

Et on associe cela à la criminalistique, une discipline liée à la sécurité.

On obtient alors le MTCR.

Le « C » est donc essentiel.

La qualité de ces données est vraiment, vraiment cruciale.

Et le point de départ, dont nous discuterons sans aucun doute, consiste à laisser l’entreprise poser
cette question.

« Combien de temps nous faut-il pour remettre nos systèmes en état ? »

Et ce que nous constatons chaque jour, c’est que cette question n’est pas si difficile à poser, mais qu’il
Il est très difficile d’y répondre, en particulier lorsqu’il existe un fossé culturel entre

les équipes chargées de la sécurité et des infrastructures.

Je pense sincèrement que c’est là que réside tout le génie du MTCR : on prend un certain nombre de concepts très
techniques sur lesquelles les équipes informatiques et de sécurité s’évaluent, et vous les transformez en

un sujet dont on peut discuter avec les PDG et les conseils d’administration.

Pour reprendre votre exemple, Darren, celui d’un commerçant qui, à Noël, a été victime d’une cyberattaque
, comment utiliseriez-vous le MTCR si vous deviez vous présenter devant un conseil d’administration pour

Expliquer ce qui s’est passé et comment se déroule le… euh… processus de Recovery ?

Eh bien, je vais commencer à répondre, puis je laisserai la parole à Duncan pour qu’il
termine, car une partie de ce document, dont Duncan était en grande partie responsable, concerne justement

le regroupement

des éléments qui s’associent pour former un service.

Mais je commencerai par dire qu’il y a quelques discussions qui doivent avoir lieu et qui, très
souvent, ne le sont pas.

L’une d’entre elles porte sur l’appétit pour le risque.

Alors, qui sommes-nous en tant qu’entreprise ?

De quel type d’entreprise s’agit-il ?

Un détaillant présente généralement une propension au risque faible à moyenne, quelque
se situer dans cette fourchette.

Mais cela doit être défini afin que, par la suite, à mesure que nous commençons à, euh, comprendre les
face aux risques qui nous entourent, nous puissions décider de ce qui est acceptable et de ce qui

devrait être pris en charge par notre assurance, par exemple, et ce qui doit absolument être
intégré.

Voilà donc le premier point à aborder.

La deuxième discussion porte ensuite sur la question suivante : quelle est la « société minimale viable » dans ce contexte ?

Il est tout à fait irréaliste de supposer qu’une organisation, quel que soit son budget, sera
capable de tout remettre en ordre rapidement.

Alors, qu’est-ce qui compte vraiment dans cette activité ?

C’est une discussion très, très approfondie et intéressante à avoir avec la plupart des entreprises.

La plupart des entreprises ne peuvent pas imaginer un monde sans informatique.

Elles ont donc beaucoup de mal à analyser en détail leurs processus métier et à se demander si 
à quoi cela ressemblerait-il si l’on revenait au papier ?

Mais cette réflexion est en quelque sorte indispensable.

Et cela nous amène à ce que l’on appelle un MVC, c’est-à-dire une entreprise minimalement viable.

C’est-à-dire : quels éléments sont indispensables à cette époque, ou quelle que soit la période que nous
choisissons.

Quels sont les éléments sans lesquels cette entreprise ne pourrait pas fonctionner du tout, sans lesquels nous ne serions pas opérationnels ?

Et c’est une discussion très, très importante.

Vous pouvez ensuite commencer à appliquer le concept du MTCR à l’entreprise minimale viable.

Je vais maintenant donner la parole à Duncan, qui pourra nous expliquer en quoi consiste un service.

Comment aborder cette question dans le cadre des services ?

Merci, Darren.

Et encore une fois, sans chercher à compliquer les choses ni à trop les approfondir.

Le MTCR sert à mesurer le temps moyen de Recovery d’un processus métier,

un service métier essentiel qui, à son tour, contribue à la viabilité minimale globale de l’entreprise.

Il y aura donc plusieurs MTCR différents selon les processus métier.

Je discutais justement aujourd’hui avec une entreprise du secteur des biens de grande consommation, un brasseur, et
Ils m’expliquaient que s’ils perdaient l’équivalent de quatre jours de données, ils devaient littéralement jeter

quatre jours de bière à l’égout, car nous ne pouvons pas prouver qu’elle est propre à la consommation et
ne peuvent donc pas la vendre.

Ce concept consiste donc à analyser en détail ces processus métier, puis à utiliser ce
Le MTCR comme langage métier commun pour pouvoir ensuite dire : « Bon, dans mon processus, j’ai besoin

puis : « Oh, ce processus repose sur plusieurs types d’applications. »

Elles reposent toutes sur des services fondamentaux, tels que l’identité ou la possibilité pour les
aux clients de se connecter à la plateforme.

Vous disposez ensuite de vos systèmes backend, qu’ils soient dans le cloud ou sur site, de vos hyperviseurs,
de vos solutions cloud critiques.

Vos systèmes frontaux qui exécutent les applications proprement dites, puis vos systèmes
Accès utilisateur : comment les utilisateurs accèdent-ils réellement à cette solution ? Est-ce via des PDA, des terminaux de point de vente ?

, etc. ?

Tous ces éléments doivent être disponibles pour que ce service métier puisse fonctionner.

Le MTCR est conçu pour que le chef d’entreprise en soit responsable.

La première étape de ce parcours consiste à réaliser une analyse comparative.

Quel est leur MTCR actuel ?

Combien de temps cela leur prendrait-il actuellement, même s’ils parvenaient à récupérer des données intactes ?

Car ce qui est choquant à l’heure actuelle, c’est que la plupart des organisations ne disposent pas
ne disposent pas de la technologie nécessaire pour protéger leurs sauvegardes et pouvoir les consulter

leurs sauvegardes pour en extraire des données valides, ce qui constitue le véritable problème métier que nous sommes là
à résoudre.

C’est très intéressant.

Vous avez demandé : quel est le MTCR actuel ?

Le MTCR n’est donc pas une mesure effectuée a posteriori pour évaluer l’efficacité de notre récupération.

Le MTCR est mesuré à intervalles réguliers tout au long de l’attaque.

Et c’est probablement parce que

Si l’on se précipite pour effectuer une Recovery, on risque en réalité de causer davantage de dégâts.

Pourriez-vous nous en dire un peu plus à ce sujet ?

Oui, je peux tout à fait aborder ce sujet.

Mais avant cela, tu as soulevé un point vraiment intéressant,
qui, je pense, mérite d’être approfondi.

Le MTCR n’est donc pas seulement un indicateur que l’on mesure tout au long de la phase de Recovery après une attaque.

C’est quelque chose qu’il faudrait évaluer avant même que la violation ne se produise.

C’est ce que j’appelle en quelque sorte « avant le coup ».

Lorsque nous présentons ce concept aux conseils d’administration, nous voyons cette idée faire son chemin
au sein de toute l’organisation.

Et la question se pose : qu’est-ce que le MTCR, par exemple, pour notre entreprise minimalement viable ?

On obtient alors des réponses qu’on ne souhaite pas entendre, comme le fait de ne pas savoir ce qu’est une entreprise minimalement viable
.

Ou bien, même si nous le savons, en réalité, notre MTCR est probablement de quatre mois à l’heure actuelle.

Nous ne voulons pas entendre ces réponses, mais nous devons les entendre pour pouvoir nous concentrer
sur l’amélioration.

Et c’est donc un point vraiment, vraiment important, je pense.

Et Darren, pour aller plus loin, je pense qu’il est essentiel pour l’entreprise de comprendre quel
Il est important de définir son MTCR dès aujourd’hui, car cela permet ensuite d’orienter correctement son processus de gestion des risques.

Et ce n’est pas toujours une solution technologique qui permettra de réduire ce MTCR.

Très souvent, si l’entreprise sait qu’elle court le risque de se retrouver sans système
pendentif « critique »

Pendant un certain temps, elle peut mettre en place un plan de continuité d’activité alternatif,
revenir au papier… Tu sais, c’est peut-être le pire des cas, Darren, mais, tu sais, pour l’instant,

les entreprises ne comprennent pas les risques qu’elles couvrent.

Et ce MTCR est censé permettre au conseil d’administration de s’adresser au RSSI et à ses équipes
et de se demander : « Combien de temps, de manière réaliste, allons-nous rester à l’arrêt aujourd’hui ? »

Et ensuite, si ce chiffre est acceptable… J’ai mené plusieurs études de ce type
et les durées sont souvent…

souvent 28, 35 ou 42 jours.

L’entreprise est alors complètement horrifiée à l’idée de se retrouver sans services informatiques pendant une telle
durée.

Mais elle n’a jamais imposé ces exigences aux services du DSI ou du RSSI en leur disant : « Nous avons besoin d’une
« Pour assurer le fonctionnement minimal de l’entreprise, ces actifs doivent être remis en service dans les 24 heures. »

Comment concevoir ces processus métier pour qu’ils puissent être rétablis dans les 24 heures ?

Cela doit faire partie des exigences fonctionnelles ou non fonctionnelles de l’entreprise pour pouvoir dire : « Voici
nos exigences.

« Services informatiques, RSSI, pouvez-vous m’aider à les respecter ? »

Et pour revenir au point que j’ai soulevé tout à l’heure, d’ailleurs, euh… il est vraiment important de
comprendre que, d’une certaine manière, cette question ne peut même pas être posée à l’une ou l’autre de ces

les équipes.

La seule façon d’obtenir une réponse qui ait du sens, même si
Ce n’est pas celle que vous souhaitez, mais il s’agit d’avoir d’un côté l’équipe chargée de l’infrastructure et de l’autre l’équipe chargée de la sécurité.

soient présentes dans la même pièce pour y répondre.

Car aucune de ces deux équipes ne peut répondre seule à cette question.

Et cela, encore une fois, d’un point de vue culturel, est extrêmement important avant même d’aborder
la technologie.

D’un point de vue culturel, ce que nous essayons de faire ici avec ce concept, c’est d’encourager un
un comportement qui n’existe pas aujourd’hui.

C’est exact.

Vous essayez de faire tomber les barrières.

Ainsi, chaque service, qu’il s’agisse de l’équipe informatique, de l’équipe chargée de l’infrastructure ou de celle des opérations de sécurité (SecOps), se dit : « Ma
« Chaque élément fonctionne bien », mais tous ces éléments doivent fonctionner ensemble.

C’est pourquoi le MTCR les rassemble et les amène à réfléchir à cette question

concept de risque dans l’environnement, car chacun a un rôle à jouer à cet égard.

Et puis je pense que c’est vraiment une expérience transformatrice dans la mesure où cela permet à chacun de ces
aux responsables la capacité d’expliquer à un PDG ou à un conseil d’administration ce que…

ce qu’ils vivent réellement en matière de reprise et de risques opérationnels, n’est-ce pas ?

Tout à fait, c’est génial.

Alors, quel est le rapport avec les exigences de base ?

Ce n’est pas si simple, mais il s’agit d’exigences de conformité telles que DORA et NIST 2.

Comment le MTCR s’inscrit-il dans ce cadre, le cas échéant ?

Bon, je vais commencer si ça te va, Duncan.

Voici donc ma première réflexion à ce sujet : tu sais, Danielle, toi et moi, nous avons tous les deux parcouru
Nous avons examiné ces articles de la DORA à maintes reprises et discuté de leur conformité.

L’une des tendances que l’on commence à observer dans le domaine de la conformité, qu’il s’agisse
que ce soit dans la norme DORA, la norme NIST 2 ou d’autres réglementations internationales, il s’agit d’une part de la mention de la

la résilience et ce qu’elle signifie par opposition à la sécurité, puis les tests.

Avez-vous un plan ?

Avez-vous testé le plan de Recovery ?

Eh bien, je pense que cela renvoie directement à ce qui devrait constituer le critère d’évaluation du plan.

Je crains un peu que bon nombre des réglementations que je constate, même les plus récentes
et celles qui sont en pleine évolution continuent de s’appuyer sur des concepts tels que la reprise après sinistre.

Elles ne précisent toujours pas très clairement ce qui doit être testé.

J’ai même vu quelques références au RPO-RTO.

Et donc, dans une certaine mesure, vous savez, ce concept est important dans la mesure où les gens
commencent à se mettre en conformité et s’orientent vers ce type de conformité qui repose fortement sur la résilience

.

En ce qui concerne ce que nous allons mesurer ici ?

Car si nous nous contentons de mesurer les anciens indicateurs de reprise après sinistre, nous n’irons
pas très loin, en fait.

Ce qui va se passer, c’est que nous serons attaqués, nous passerons à notre plan de reprise après sinistre, nous le mettrons en œuvre,
Et, surprise, surprise, nous ne retrouverons pas notre sauvegarde intacte, et il nous faudra 30, 40, 50, 60

jours pour nous remettre sur pied.

Nous devons donc changer de mentalité.

Et en matière de conformité, cela a été très rafraîchissant de constater que certaines des nouvelles politiques et certains des nouveaux calendriers de mise en conformité

évoquaient la résilience, la reprise et les tests, mais nous devons veiller à les aborder
de la bonne manière, en utilisant les cadres et les contextes appropriés.

Oui, je suis tout à fait d’accord, Darren.

Réfléchis : si tu examines bon nombre des exigences de la directive DORA et ce que fait la Banque centrale européenne
Comme il l’a mentionné à propos des tests de résistance, la plupart des organisations se sont mises en situation de…

échouer, car il est stipulé qu’il faut prouver que l’on est capable de se rétablir dans les limites de sa tolérance aux impacts
métier.

Et la plupart des organisations s’appuient sur cette tolérance vis-à-vis des répercussions sur l’activité

sur des indicateurs de disponibilité ou sur l’ancien plan de reprise après sinistre qui stipule qu’il est possible de basculer du centre de données A vers
le centre de données B en quatre heures.

On ne peut pas remettre en état de fonctionnement une banque ou une institution financière dans son ensemble en quatre heures, c’est
impossible.

Je pense donc — et cela met en évidence la nécessité de ce nouveau vocabulaire du MTCR —
qu’elles doivent réexaminer cette tolérance opérationnelle, cette tolérance à l’impact métier, afin de

la redéfinir en se demandant : « Si je perds mon système central, par exemple mon grand livre,

Comment puis-je continuer à fonctionner ?

Eh bien, je n’arrive pas à m’en sortir.

Je dois donc mettre en place des plans d’urgence pour déterminer comment je peux recourir à des sous-processus afin de pouvoir
puis revenir en arrière une fois que votre grand livre sera de nouveau en ligne, pour reprendre l’exemple financier.

Mais vous avez évoqué les tests : la plupart des organisations, lorsque je leur ai posé la question « À quand remonte votre dernier test de CR ? »
», renvoient à leur plan de reprise après sinistre (DR) traditionnel.

Elles ne font pas référence à leur plan de reprise après sinistre informatique, car la plupart des organisations n’ont pas encore

ni entièrement conçu ni mis en œuvre un plan de reprise après un cyberincident.

Et il va sans dire que ce MTCR doit figurer parmi les indicateurs clés de ce plan de Recovery
après un sinistre informatique.

Vous avez défini les scénarios contre lesquels vous allez vous protéger et à partir desquels vous allez vous remettre.

Et vous disposez ensuite d’une mesure MTCR pour ces différents types d’attaques.

Il est vraiment là pour essayer, comme je le disais, de combler ce fossé entre l’entreprise, l’informatique et le RSSI.

Tu sais, Darren, tu disais qu’il s’agissait de changer la culture d’entreprise, et Duncan, tu venais…
de mentionner justement tant de…

Les contrats entre, euh, les organisations prévoient un délai de reprise, et cela n’a aucun sens.

Cela ne concerne donc pas seulement les équipes techniques, mais aussi les équipes de direction
les responsables de la gestion des risques d’entreprise et les juristes chargés de la rédaction des contrats : ils doivent comprendre que le RTO et le RPO ne suffisent pas, mais que

La nouvelle norme, c’est une reprise sans faille.

Et tout le monde doit comprendre quel doit être le résultat final, et non pas les étapes
intermédiaires qui

peuvent s’avérer sans importance, n’est-ce pas ?

Oui, je pense que c’est un très bon argument.

Et je m’y attends tout à fait, à mesure que nous progressons dans ce projet et que nous organisons des ateliers sur
la prise de risque souhaitée, dans toutes les entreprises viables et au sein du MTCR, afin que nous

nous découvrirons que, vous savez, peut-être bien plus de personnes que celles qui, traditionnellement, auraient été
Les entreprises associées à Recovery doivent s’y intéresser et avoir leur mot à dire lors de ces

ateliers.

Précisément pour les raisons que tu as évoquées, Danielle.

Je m’adresse donc aux dirigeants qui nous écoutent :

Je vous encourage tous à consulter le rapport dans son intégralité.

Il s’intitule « Redéfinir la cyber-Recovery : présentation du « Mean Time to Clean Recovery » ».

Et j’ai une dernière question pour Duncan et Darren : vous avez abordé de
de nombreux sujets aujourd’hui.

Vous avez ancré votre propos dans une application concrète pour une entreprise réelle, ce qui est tout à fait pertinent.

À l’intention des dirigeants qui nous écoutent : par où commencer ?

Par où commencer dès maintenant ?

Nous avons lu le rapport et souhaitons mettre en œuvre ce concept dans nos entreprises, dans nos
activités.

Comment s’y prendre ?

Eh bien, en ce qui me concerne, en tant que dirigeant non technique, j’encouragerais l’organisation d’une réunion
entre la personne chargée de la mise en place de l’infrastructure au sein de l’entreprise, généralement un directeur des systèmes d’information,

et la personne chargée de la cybersécurité au sein de l’entreprise, généralement le RSSI (si ce n’est pas le cas),
… organiser une réunion avec ces deux personnes, ces deux dirigeants, et leur poser la question suivante : comment

rapidement, si nous devions subir une attaque catastrophique par ransomware — prenons l’exemple du ransomware

À titre d’exemple, car ce phénomène est très répandu et nous sommes tous concernés par les ransomwares.

Donc, en cas de catastrophe liée à un rançongiciel, en combien de temps pourriez-vous rétablir ensemble le
fonctionnement de l’entreprise et m’assurer que les données que je m’apprête à utiliser pour gérer l’

entreprise sont intactes ?

Je vous garantis que cette réunion en entraînera cinq autres, car la
La réponse n’est pas simple.

Cela nécessitera une collaboration entre ces équipes.

Cela nécessitera également un changement de mentalité.

Et je pense que je dirais à peu près la même chose, à ceci près que j’élargirais probablement le cercle
des participants afin d’y inclure des personnes telles que le directeur des risques et le responsable des achats.

Car, pour la plupart des organisations, qu’il s’agisse d’un contrat SaaS ou
Les contrats d’externalisation ne font généralement aucune mention de la question de la Recovery après sinistre informatique.

Quand puis-je récupérer des données intactes lors de Recovery ?

En effet, dans la plupart de ces types de contrats, c’est le client qui est responsable de
ces données.

Ces fournisseurs d’infrastructure et ces fournisseurs de SaaS sont responsables de l’infrastructure
qui assure ce service.

C’est donc à eux qu’il revient de se charger de récupérer leurs données intactes
.

Mais ils doivent ensuite les transmettre assez rapidement à leurs dirigeants pour essayer
de bien comprendre en quoi consiste notre MVC, car les organisations, comme vous l’avez dit tout à l’heure,

Darren, ils ne peuvent tout simplement pas se permettre de restaurer l’intégralité de leurs systèmes d’entreprise
en très peu de temps, et n’en seront jamais capables.

La clé réside ici dans la hiérarchisation des priorités, et seule l’entreprise peut juger de ce qui est le plus important
pour elle en cas de cybercatastrophe.

Darren, directeur technique chez Commvault, et Duncan, responsable du pôle Sécurité et résilience chez Kyndryl.

Merci beaucoup.

Prochaines étapes : j’espère que vous allez faire connaître ce concept du MTCR et aider les dirigeants
un sujet à approfondir lors d’ateliers.

Et je suis convaincu que nous commencerons à voir ce concept se généraliser à l’échelle mondiale à mesure que nous contribuerons à
nos entreprises à définir leur propre modèle MVC.

Merci beaucoup de nous avoir consacré un peu de votre temps aujourd’hui.

Merci, Danielle.