En bref : Un audit après une cyberattaque vérifie que l’attaquant n’a plus accès à vos systèmes, que la preuve numérique nécessaire aux recours est préservée et que votre capacité de relance a été testée, pas seulement affirmée. Le fournisseur TI qui gérait les systèmes touchés ne peut pas certifier objectivement la fin de l’incident : il évaluerait son propre travail.
Vous avez vécu l’incident. Vous avez peut-être payé une rançon, restauré des systèmes, envoyé un courriel rassurant à vos clients. Votre fournisseur TI, celui qui gérait les systèmes touchés, vous dit maintenant que tout est réglé. La question que vous n’osez pas poser tout haut : comment le savoir vraiment ?
Dans cet article
Le pirate est-il encore dans nos systèmes après une cyberattaque ?
Un rançongiciel ou une intrusion ne se limite presque jamais au chiffrement de fichiers. Pendant qu’il était dans vos systèmes, l’attaquant a eu le temps de créer des comptes, d’ouvrir des accès distants, de modifier des règles de pare-feu. Ce sont les doubles de clés que le cambrioleur a pu faire pendant qu’il était chez vous, avant de repartir par la porte que tout le monde a fini par verrouiller.
Restaurer les systèmes à partir d’une sauvegarde ne garantit rien si cette sauvegarde contient déjà une des portes dérobées de l’attaquant, ou si un compte créé durant l’intrusion existe encore, inaperçu, dans votre annuaire. Un audit après une cyberattaque vérifie spécifiquement la persistance que l’attaquant a pu laisser derrière lui :
- Comptes créés ou modifiés durant la fenêtre d’intrusion
- Tâches planifiées ajoutées aux systèmes
- Règles de transfert de courriel configurées à l’insu de l’utilisateur
- Clés d’accès ou jetons ajoutés à vos environnements infonuagiques
Le Centre canadien pour la cybersécurité insiste, dans ses recommandations de rétablissement après un rançongiciel, sur la nécessité de déterminer la cause profonde de l’intrusion et de documenter les preuves avant de considérer un incident clos.
Un système qui fonctionne de nouveau normalement n’est pas un système démontré propre. Ce sont deux affirmations différentes, et seule la seconde compte.
Le moment où vous confirmez la fin de l’incident a aussi une conséquence pratique. Écraser des systèmes ou réinstaller des postes avant qu’une image judiciaire n’ait été prise détruit la preuve dont vous pourriez avoir besoin plus tard. Nous y revenons plus loin, parce que c’est rarement la priorité de l’équipe qui veut simplement revenir en ligne.
L’audit s’appuie sur les journaux de connexion, l’historique des comptes administrateurs et, quand l’organisation en dispose, les alertes de l’outil de détection et réponse aux points d’accès (EDR, pour endpoint detection and response). Sans ces traces, une partie de la vérification devient une question de confiance plutôt qu’une démonstration.
Notre fournisseur TI dit que c’est réglé : pourquoi vérifier quand même ?
Parce que ce même fournisseur a géré les systèmes pendant qu’ils étaient compromis. Lui confier un audit après une cyberattaque revient à lui demander d’évaluer son propre travail. Ce n’est pas une question de compétence ni de mauvaise foi, c’est une question de position.
Personne n’est un bon juge de sa propre copie.
Dans la grande majorité des dossiers que nous voyons passer, c’est exactement le même MSP (fournisseur de services gérés, de l’anglais managed service provider) qui gérait l’infrastructure avant l’incident, qui a géré la réponse, et qui déclare ensuite la crise terminée. Juge et partie, du début à la fin.
Il y a une raison concrète de ne pas se contenter de cette parole. Une partie des organisations qui subissent un rançongiciel ou paient une rançon voient l’incident se reproduire dans les mois qui suivent, souvent parce que la faille d’origine ou une porte dérobée oubliée n’a jamais été réellement fermée. Une déclaration de victoire prématurée coûte plus cher qu’une vérification.
Un audit indépendant n’a rien à protéger dans ce dossier. Il n’a pas facturé la réponse à l’incident, il ne facture pas la remédiation, et il n’a aucun intérêt à ce que le rapport dise que tout est beau plutôt que ce qu’il trouve réellement. C’est la différence entre une opinion et une vérification.
Un audit post-incident, comme tout audit, reste une obligation de moyens. Personne ne peut vous garantir d’avance ce qu’il va trouver, ni que le résultat sera rassurant. C’est justement pour ça qu’il a de la valeur : un résultat garanti à l’avance n’est pas un résultat, c’est une formalité.
C’est aussi une question de structure, pas seulement d’intention. Un cabinet qui vend en même temps la réponse à l’incident et la confirmation qu’elle a fonctionné a un intérêt financier dans sa propre conclusion. Un cabinet qui n’a jamais touché à vos systèmes n’a rien à gagner à dire que tout va bien, ni rien à gagner à dire le contraire : il rapporte ce qu’il trouve.
Que vérifie un audit après une cyberattaque, concrètement ?
Un audit après une cyberattaque vérifie six éléments concrets : les accès créés durant l’intrusion, la persistance technique laissée par l’attaquant, l’intégrité des sauvegardes restaurées, la préservation de la preuve numérique, la conformité à la Loi 25 et l’existence d’un test de restauration documenté.
Le NIST (National Institute of Standards and Technology, l’organisme américain de normalisation technique dont le guide SP 800-61 sert de référence dans le domaine) organise la réponse aux incidents autour de plusieurs fonctions, dont détecter, répondre et rétablir. Un audit post-incident se concentre sur les deux dernières, celles où votre fournisseur affirme avoir terminé.
<table> <thead> <tr><th>Élément vérifié</th><th>Ce que ça confirme</th></tr> </thead> <tbody> <tr><td>Comptes et accès créés durant l’intrusion</td><td>Qu’aucun accès résiduel ne subsiste, sous un autre nom</td></tr> <tr><td>Persistance technique (tâches planifiées, règles de pare-feu, clés d’accès)</td><td>Que l’attaquant n’a pas laissé de porte dérobée</td></tr> <tr><td>Intégrité des sauvegardes restaurées</td><td>Que vous ne restaurez pas une copie déjà compromise</td></tr> <tr><td>Préservation de la preuve numérique</td><td>Que vous conservez ce dont un assureur ou un tribunal pourrait avoir besoin</td></tr> <tr><td>Déclaration et registre Loi 25</td><td>Que vos obligations envers la CAI sont bel et bien remplies</td></tr> <tr><td>Test de restauration documenté</td><td>Que votre plan de relance fonctionne, pas seulement sur papier</td></tr> </tbody> </table>
Chaque ligne de ce tableau correspond à une question que quelqu’un finira par poser : un assureur, un client, parfois un tribunal. Mieux vaut y avoir répondu avant qu’on vous la pose.
Que demanderont l’assureur, les clients et peut-être un tribunal ?
Un incident de sécurité qui touche des renseignements personnels déclenche des obligations qui survivent à la « résolution » technique. Si le risque est sérieux, la Loi 25 (la loi québécoise sur la protection des renseignements personnels) exige une déclaration à la Commission d’accès à l’information du Québec, la CAI. Le registre des incidents, lui, doit consigner tout incident de confidentialité touchant des renseignements personnels, sérieux ou non. Remettre les systèmes en ligne ne referme pas ce dossier.
Votre assureur en cybersécurité, s’il doit indemniser une partie des coûts, voudra voir comment l’incident a été confiné et confirmé, pas seulement entendre que c’est réglé. Vos clients les plus exigeants, en particulier s’ils sont eux-mêmes soumis à des obligations de diligence envers leurs propres clients, poseront la même question sous une autre forme : sur quoi repose votre affirmation que c’est terminé ?
Si l’incident donne lieu à une réclamation, une poursuite ou un litige avec un fournisseur, la preuve numérique devient déterminante. Une image judiciaire des systèmes prise avant leur remise en service, une chronologie documentée, des journaux conservés plutôt qu’écrasés : ce sont ces éléments qui permettent, des mois plus tard, de reconstituer ce qui s’est passé. Les reconstituer après coup, une fois les systèmes réinstallés, est souvent impossible.
C’est un terrain où la manière dont la preuve a été traitée peut compter autant que l’incident lui-même, devant un tribunal ou un assureur qui pose des questions serrées.
La chronologie compte aussi pour vous. Un dossier qui montre clairement quand l’intrusion a commencé, quand elle a été détectée, quand elle a été confinée et quand la vérification indépendante a eu lieu se défend beaucoup mieux, devant qui que ce soit, qu’un dossier où tout se résume à « le fournisseur nous a dit que c’était fait ».
Comment transformer l’incident en plan de relance testé ?
La vraie leçon d’un incident n’est pas la liste des correctifs appliqués la semaine suivante. C’est un plan de relance qui a été testé, pas seulement rédigé. Notre guide complet sur les sauvegardes, le plan de relance et les tests détaille ce que ça veut dire concrètement, du choix des sauvegardes jusqu’à la fréquence des exercices.
Une sauvegarde qui existe n’est pas une garantie. Une sauvegarde non testée n’est pas une sauvegarde : c’est vrai avant un incident, et ça reste vrai après. L’audit post-incident est le moment logique pour exiger, une fois pour toutes, un test de restauration documenté, celui qui démontre que la capacité de relance existe réellement plutôt que sur une diapositive de présentation.
Nous l’écrivons ailleurs et ça reste vrai ici : face à un rançongiciel, la vraie défense est votre capacité de relance, pas la promesse qu’il ne se reproduira jamais. Un audit post-incident bien fait débouche sur un plan concret, pas sur un rapport qu’on range dans un tiroir. Trois éléments distinguent un plan de relance qui tient d’un plan qui reste sur papier :
- Un propriétaire nommé, responsable du plan et de sa mise à jour
- Un délai fixé pour chaque étape critique de restauration
- Un test de restauration documenté, répété à intervalle régulier, pas exécuté une seule fois après l’incident
Vous avez le droit de vouloir dormir tranquille, pas seulement de vous faire dire que tout est beau. Un audit TI indépendant mené par un cabinet qui n’a rien géré dans l’incident, qui ne vend pas de remédiation et qui ne touche aucune commission sur ce qu’il recommande ensuite, confirme la fin de l’incident sans avoir d’intérêt dans la réponse. C’est le seul type d’audit dont le résultat n’est pas à vendre.
Pour aller plus loin avec Factero :
- reprise après incident vérifiée par un tiers
- test de restauration de vos sauvegardes
- témoin expert TI en cas de litige
Foire aux questions
Notre assureur peut-il exiger ce type d’audit ?
Oui, et c’est de plus en plus fréquent. Une police en cybersécurité peut conditionner l’indemnisation à la preuve que l’incident est réellement terminé, pas seulement déclaré réglé par le fournisseur qui a géré la réponse. Certains assureurs exigent même un rapport d’un tiers indépendant avant de clore le dossier. Vérifiez les conditions de votre police avant de considérer l’affaire close.
Combien de temps a-t-on pour déclarer un incident à la CAI après une cyberattaque ?
La Loi 25 n’impose pas de nombre de jours précis. Elle exige que l’entreprise « s’empresse » d’aviser par écrit la Commission d’accès à l’information dès qu’un incident présente un risque de préjudice sérieux (sensibilité des renseignements, conséquences appréhendées, probabilité d’utilisation préjudiciable). Le registre des incidents, lui, se conserve un minimum de cinq ans, même si l’incident n’est pas jugé sérieux. L’audit post-incident ne remplace pas cette déclaration : il peut en documenter une partie.
Qui paie l’audit post-incident, est-ce couvert par l’assurance cyber ?
Ça dépend de votre police, pas automatiquement. Une partie des polices de cyberassurance couvre les frais de vérification post-incident, surtout quand l’assureur conditionne une partie de l’indemnisation à une confirmation indépendante que l’incident est clos. D’autres ne couvrent que la réponse à l’incident elle-même, pas la vérification qui vient après. Vérifiez ce point avec votre courtier avant de commander l’audit.
Quand peut-on dire qu’on est vraiment revenu à la normale après une cyberattaque ?
Pas quand les systèmes refonctionnent : c’est un signe technique, pas une confirmation. Le retour à la normale, au sens où un assureur, un client ou un tribunal l’entendrait, suppose un test de restauration documenté, une vérification que l’attaquant n’a plus d’accès et une confirmation par une partie qui n’a pas géré la réponse à l’incident. Sans ces trois éléments, vous avez repris vos activités, pas confirmé la fin de l’incident.
« Post-breach audit » : est-ce différent d’un audit post-incident ?
Non, c’est le même exercice sous son nom anglais courant. Certaines organisations, en particulier celles qui font affaire avec des assureurs ou des partenaires hors Québec, utilisent l’expression anglaise dans leurs échanges. Le contenu de la vérification reste le même.
