Aller au contenu
SITECH

Chiffrés un vendredi soir : combien de temps pour rouvrir lundi ?

Cybersécurité

Chronomètre et chaîne de sauvegarde illustrant la mesure du délai réel de remise en service après un rançongiciel.

Dans son évaluation 2026, Interpol relève que les pertes financières liées aux menaces cyber signalées en Afrique ont progressé de 152 % en une seule année, et classe les rançongiciels et l'extorsion numérique parmi les principales menaces du continent, aux côtés de la compromission de messagerie professionnelle. La même année, une enquête de l'Internal Audit Foundation place les incidents cyber en tête des risques cités par 62 % des professionnels africains interrogés.

Et ce n'est plus lointain : la presse spécialisée africaine a rapporté que BGFIBank, premier groupe bancaire d'Afrique centrale, aurait été visé par le groupe criminel BianLian. Le secteur financier est une cible de choix — valeur des données, dépendance aux systèmes, capacité à payer.

Nous n’allons pas vous vendre un produit dans cet article. Nous allons vous proposer un exercice.

La seule question qui compte

Pas « sommes-nous protégés » — personne ne peut y répondre honnêtement par oui. La question utile est : si tout est chiffré vendredi à 19 h, à quelle heure lundi les équipes retravaillent-elles ? Ce chiffre existe déjà dans votre organisation. Il est simplement inconnu, parce qu'il n'a jamais été mesuré.

L'exercice des quatre-vingt-dix minutes

Bloquez une matinée, réunissez l'administrateur système, le responsable métier de l'application choisie et un chronomètre. Choisissez un serveur qui compte vraiment — pas le serveur de test. Et restaurez-le, réellement, dans un environnement isolé.

Notez ces six chiffres, à la minute près :

  1. Le temps de retrouver la sauvegarde. Combien de minutes entre « on démarre » et « on a identifié le bon point de restauration ». Chez beaucoup, c'est déjà là que ça coince.
  2. L'ancienneté réelle du point restauré. Votre contrat dit peut-être « sauvegarde quotidienne ». La dernière sauvegarde réussie date de quand, exactement ?
  3. La durée de la restauration elle-même, du lancement au démarrage du système.
  4. Le temps jusqu'au service utilisable : base repartie, application accessible, connexion d'un utilisateur test réussie. C'est le seul délai qui intéresse la direction générale.
  5. Le nombre d'interventions humaines nécessaires, et surtout : combien exigeaient une personne précise. Si la réponse est « seul untel sait faire », vous avez trouvé votre risque principal.
  6. Ce qui manquait. Un mot de passe dans un coffre inaccessible, une clé de licence, un plan d'adressage, un numéro de support. Notez-les : cette liste vaut plus que le reste de l'exercice.

Multipliez ensuite le résultat par le nombre de serveurs à relever dans un scénario réel. C'est votre vrai délai de reprise. Comparez-le à celui que vous aviez annoncé.

Ce que l'exercice révèle presque toujours

  • Les sauvegardes tournent, mais personne ne lit les rapports d'échec. Une tâche en erreur depuis onze semaines est un classique.
  • Les sauvegardes sont accessibles depuis le domaine. Or un rançongiciel qui obtient les droits d'administration du domaine chiffre d'abord ce qu'il trouve — les sauvegardes comprises. D'où la règle 3-2-1-1-0 : trois copies, deux supports, une hors site, une immuable ou déconnectée, zéro erreur de vérification.
  • La procédure existe, mais elle décrit une version antérieure du système.
  • La détection n'a rien signalé parce que les alertes partent sur une boîte que personne ne relève.

Ce qu'on met en place ensuite, dans cet ordre

L'ordre compte, parce qu'un budget de sécurité se dépense mal quand il commence par l'outil le plus visible.

  1. Une copie immuable ou hors ligne, vérifiée automatiquement. Sans elle, tout le reste est décoratif. Nos déploiements s'appuient selon les cas sur Veeam, Veritas NetBackup ou ExaGrid.
  2. La surveillance des postes et des serveurs — EDR ou XDR selon la taille, avec une alerte qui arrive à quelqu'un qui la lit. CrowdStrike, SentinelOne, Sophos et Fortinet couvrent ce besoin.
  3. La supervision de la sauvegarde elle-même dans votre outil de suivi, au même titre qu'un disque plein. PRTG, ManageEngine ou SolarWinds font remonter l'échec de tâche comme un incident, pas comme un courriel de plus.
  4. L'exercice, refait tous les six mois, avec une personne différente aux commandes à chaque fois.

Un mot sur ce qu'il ne faut pas faire

Ne payez pas sans avoir mesuré vos alternatives : payer ne garantit ni la clé, ni l'absence de publication des données. Ne redémarrez pas les serveurs avant d'avoir prélevé les traces, sous peine de perdre ce qui permettrait de comprendre l'entrée. Et prévenez tôt : la déclaration aux autorités et l'information des clients concernés se préparent avant l'incident, pas pendant.

Nous animons cet exercice de restauration chez nos clients, en une demi-journée, sur un serveur qu'ils choisissent. Le livrable tient en une page : vos six chiffres, et la liste de ce qui manquait.

Sources

Partager cet article