En bref : La relance après rançongiciel est ce qui distingue une interruption gérée d’une crise, bien plus que la prévention seule. Elle repose sur des sauvegardes hors de portée de l’attaque, hors ligne ou immuables, sur un plan écrit accessible même quand les systèmes sont chiffrés, et sur un test récent qui confirme que la restauration fonctionne réellement.
Dans cet article
Qu’est-ce qui distingue une interruption gérée d’une crise ?
La différence ne tient presque jamais à la sophistication de l’attaque. Elle tient à ce que l’entreprise avait préparé avant que l’attaque n’arrive.
Deux entreprises touchées par le même rançongiciel, le même jour, peuvent vivre deux histoires complètement différentes. La première restaure ses systèmes critiques en quelques jours, informe ses clients, documente l’incident, repart. La seconde négocie pendant des semaines, perd des données qu’elle ne retrouvera jamais, et paie le prix d’une confiance entamée bien après que les systèmes soient revenus en ligne.
La plupart des dirigeants investissent dans la prévention parce qu’elle se voit : un pare-feu, un antivirus, une formation annuelle. La capacité de relance, elle, ne se voit pas tant qu’on n’en a pas besoin. C’est justement pour ça qu’elle reste souvent la dernière ligne du budget, alors qu’elle devrait être la première question posée par la direction.
Pourquoi la prévention ne suffit-elle pas ?
La prévention ne suffit pas parce qu’elle réduit la probabilité qu’un rançongiciel réussisse, elle ne la ramène jamais à zéro. Plusieurs mesures y contribuent :
- Pare-feu et filtrage du trafic réseau
- Filtrage des courriels entrants
- Formation régulière du personnel
- Gestion stricte des accès et des identifiants
Un clic sur un lien piégé, une vulnérabilité non corrigée dans un logiciel tiers, des identifiants d’un fournisseur compromis ailleurs, et le rançongiciel est à l’intérieur.
C’est le message central du Guide sur les rançongiciels du Centre canadien pour la cybersécurité : la prévention est nécessaire, elle n’est pas suffisante à elle seule. La prévention réduit la probabilité d’un incident. La relance après rançongiciel réduit ses conséquences. Seule la seconde borne le pire scénario, celui où l’entreprise ne repart tout simplement pas.
C’est une obligation de moyens, pas une obligation de résultat. Quiconque vous promet une protection totale contre le rançongiciel vous dit quelque chose sur sa rigueur, pas sur votre sécurité réelle.
Le facteur humain reste au cœur de la plupart des cas : un courriel bien imité, un appel qui se fait passer pour le service informatique, une pièce jointe ouverte un vendredi après-midi. Former le personnel réduit le risque, ça ne l’élimine pas. La question à se poser n’est donc pas seulement « comment empêcher l’entrée du rançongiciel ? », mais aussi « le jour où il entre quand même, qu’est-ce qui nous protège ? ».
Qu’est-ce qu’une sauvegarde hors ligne ou immuable ?
Une sauvegarde hors ligne ou immuable est une copie que le rançongiciel ne peut pas atteindre, parce qu’elle est déconnectée du réseau ou verrouillée contre toute modification. Un rançongiciel moderne ne se contente pas de chiffrer les postes de travail et les serveurs. Il cherche activement les sauvegardes accessibles depuis le réseau, avec les mêmes identifiants compromis, pour les chiffrer ou les supprimer avant même que la rançon soit exigée. Une sauvegarde connectée en tout temps au réseau de production n’est pas une protection contre le rançongiciel, c’est une cible de plus.
Deux approches échappent à ce risque.
Une sauvegarde hors ligne, ou en air gap, est physiquement ou logiquement déconnectée du réseau de production en dehors de sa fenêtre de copie. Le rançongiciel ne peut pas atteindre ce qu’il ne peut pas voir.
Une sauvegarde immuable est écrite une fois, puis verrouillée : personne, pas même un administrateur dont les identifiants seraient compromis, ne peut la modifier ou la supprimer avant l’échéance de rétention fixée à l’avance.
Le tableau suivant compare l’exposition de ces trois profils de sauvegarde au rançongiciel :
| Type de sauvegarde | Accessible depuis le réseau de production | Vulnérable si le réseau est compromis |
|---|---|---|
| Sauvegarde en ligne standard | Oui, en tout temps | Oui, avec les mêmes identifiants que le reste du réseau |
| Sauvegarde hors ligne | Non, sauf pendant la fenêtre de copie | Non, une fois la copie déconnectée |
| Sauvegarde immuable | Oui, mais en lecture seule pendant la rétention | Non, même avec des identifiants administrateur compromis |
Nous détaillons les principes qui sous-tendent ces choix dans La règle 3-2-1 : pourquoi vos sauvegardes ne suffisent pas. La règle n’a pas été pensée seulement pour le rançongiciel, elle vise toute perte de données. Mais son exigence d’une copie hors site et déconnectée est exactement ce qui la rend efficace contre lui.
Les deux approches ne s’excluent pas. Une organisation prudente combine souvent une sauvegarde immuable, pratique pour une restauration rapide sans manipulation physique, et une copie réellement hors ligne, conservée hors des mêmes fournisseurs et des mêmes identifiants que le reste de l’environnement. Le bon dosage dépend de la taille de l’organisation et de la sensibilité des données, pas d’une recette unique.
Sans l’une des deux, la relance après rançongiciel reste hypothétique, peu importe la qualité du reste du plan.
Pourquoi le plan de reprise après rançongiciel doit-il rester hors des systèmes ?
Un plan de reprise hébergé sur les mêmes systèmes qu’il doit aider à restaurer devient inaccessible pile au moment où il sert le plus. Le jour où vos systèmes sont chiffrés, votre intranet est chiffré aussi. Votre outil de gestion des incidents, votre liste de contacts, votre procédure pas à pas, souvent hébergés sur les mêmes serveurs que tout le reste, deviennent inaccessibles au moment précis où vous en avez le plus besoin.
Un plan de relance qui n’existe que dans les systèmes qu’il est censé aider à restaurer n’est pas un plan, c’est une intention. La version qui compte est celle imprimée, ou conservée sur un support totalement indépendant du réseau. Elle doit répondre à ces questions sans aucun accès aux systèmes :
- Qui appeler en premier
- Dans quel ordre restaurer les systèmes
- Quelles sont les coordonnées de l’assureur
- Quelles sont les coordonnées du conseiller juridique
- Quelles sont les coordonnées de la firme externe, s’il y en a une
Ce plan s’appuie sur deux repères que votre direction doit connaître avant l’incident, pas pendant : le temps maximal pendant lequel l’entreprise peut rester hors service (RTO), et la quantité de données qu’elle accepte de perdre entre deux sauvegardes (RPO). Nous les détaillons dans RTO, RPO : les deux chiffres que votre direction doit connaître. Sans ces deux chiffres fixés à l’avance, chaque décision pendant la crise se négocie dans l’urgence, sans repère.
Un bon plan tient sur quelques pages, pas dans un classeur de cent pages que personne n’a lu. Sous le choc d’un incident réel, une procédure trop détaillée ne se suit pas : ce sont les premières actions, claires et dans l’ordre, qui font la différence entre une équipe qui agit et une équipe qui panique.
Payer la rançon garantit-il de récupérer ses données ?
Non, sans garantie d’aucune sorte. Rien n’oblige un attaquant à fournir une clé de déchiffrement fonctionnelle après paiement, et rien ne garantit que cette clé restaure l’intégralité des données touchées.
Payer ne restaure pas non plus la confiance dans les systèmes concernés. Un environnement où un attaquant a circulé, parfois pendant des semaines avant même de déclencher le chiffrement, doit être examiné et souvent reconstruit, peu importe la décision prise sur la rançon. La question du paiement se pose au cas par cas, avec l’assureur et le conseiller juridique de l’entreprise : ce n’est pas une décision à prendre seul, ni une décision qui referme le dossier.
Si des renseignements personnels sont touchés, la Loi 25 impose ses propres obligations de déclaration à la Commission d’accès à l’information, indépendamment de la décision de payer ou non.
La police d’assurance cyberrisque de l’entreprise, si elle en a une, encadre souvent la décision aussi : plusieurs polices exigent d’aviser l’assureur avant tout paiement, sans quoi la couverture peut être remise en question. C’est une raison de plus pour que cette décision passe par un canal établi d’avance, pas par un seul dirigeant sous pression au moment de l’incident.
Comment tester votre relance après rançongiciel ?
La question que la direction devrait se poser n’est pas « sommes-nous protégés ? ». C’est : si tout était chiffré ce matin, en combien de temps et avec quelles pertes l’entreprise repartirait-elle ? La seule réponse honnête à cette question vient d’un test récent, pas d’une conviction.
Trois vérifications concrètes, dans l’ordre.
- Confirmez lesquelles de vos sauvegardes sont réellement hors ligne ou immuables aujourd’hui, pas telles qu’elles étaient conçues à l’origine. Les configurations dérivent avec le temps, souvent sans que personne ne le remarque.
- Sortez votre plan de relance des systèmes qu’il décrit et vérifiez qu’il est lisible sans accès au réseau, avec des coordonnées à jour.
- Planifiez une restauration réelle, pas un exercice sur papier. Une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une protection. C’est aussi le principe central de la norme ISO 22301:2019 sur la gestion de la continuité d’activité : un plan non testé reste une hypothèse documentée, pas une capacité démontrée.
Un test crédible ne se limite pas à l’équipe technique. La direction doit y participer, au moins une fois, pour voir de ses propres yeux combien de temps prend réellement une restauration et quelles décisions elle devrait prendre pendant que ça se passe. Un test entièrement délégué reste un test partiel : il valide la technique, pas la capacité de l’organisation entière à traverser la crise.
Le pilier sur les sauvegardes, le plan de relance et les tests reprend l’ensemble de la démarche, de la première sauvegarde jusqu’au test complet.
Vérifier votre relance après rançongiciel avant l’incident, c’est comme vérifier un extincteur avant le feu, pas pendant. Un audit TI indépendant confirme où en est réellement votre organisation, sans complaisance et sans rien vous vendre au passage : ni logiciel de sauvegarde, ni service infonuagique, ni assurance. Les faits tels qu’ils sont, pour que la décision reste la vôtre.
Pour aller plus loin avec Factero :
- test de restauration de vos sauvegardes
- accompagnement cyberassurance pour votre police cyberrisque
- audit TI indépendant pour valider votre relance
Foire aux questions
Faut-il déclarer un rançongiciel à la Commission d’accès à l’information ?
Oui, si des renseignements personnels sont touchés et que l’incident présente un risque de préjudice sérieux pour les personnes concernées. L’entreprise doit alors aviser la Commission d’accès à l’information et informer directement les personnes touchées, peu importe la décision prise sur le paiement d’une rançon. Cette obligation découle de la Loi 25 et s’applique sans égard à la taille de l’entreprise.
À quelle fréquence faut-il tester ses sauvegardes ?
Il n’y a pas de fréquence légale unique. Le Centre canadien pour la cybersécurité recommande d’établir un calendrier de tests réguliers pour les processus de sauvegarde, avec un rythme mensuel donné en exemple. Une restauration complète, avec la direction impliquée, mérite d’être planifiée au moins une fois par année. Ce qui compte, c’est la régularité réelle, pas la fréquence affichée sur papier.
Combien de temps faut-il pour se remettre d’un rançongiciel ?
Ça varie trop d’une organisation à l’autre pour donner un chiffre universel, et une moyenne sectorielle serait trompeuse. La seule réponse fiable vient d’un test récent de restauration, mesuré contre le délai maximal d’interruption que l’entreprise s’est fixé (RTO) et la quantité de données qu’elle accepte de perdre (RPO). Sans ces repères fixés à l’avance, le délai réel se découvre en pleine crise, au pire moment pour le faire.
L’assurance cyberrisque couvre-t-elle le paiement d’une rançon ?
Ça dépend entièrement de la police en vigueur, il n’y a pas de réponse uniforme. Plusieurs polices d’assurance cyberrisque couvrent une partie du paiement, mais exigent d’aviser l’assureur avant toute transaction, sous peine de voir la couverture remise en question. La décision de payer ou non devrait donc passer par l’assureur et le conseiller juridique de l’entreprise, jamais par un seul dirigeant agissant seul sous pression.
