On est en pleine attaque, on n'a pas de plan écrit. On commence par quoi, là, maintenant ?

Une seule chose : arrêtez l'hémorragie avant de réfléchir au reste. Le réflexe utile, c'est de désigner tout de suite une personne qui décide (souvent vous), et une seule, pour éviter que cinq mains fassent cinq choses contradictoires sur les mêmes machines. Notez l'heure de chaque action sur un bout de papier ou un message horodaté : vous croyez que vous vous en souviendrez, vous ne vous en souviendrez pas, et cette chronologie vaudra de l'or pour l'analyse comme pour l'assureur. Le reste s'organise après ces deux gestes.

Faut-il prévenir les salariés, les clients, voire la presse ?

Pas dans la première heure, et pas tous en même temps. En interne, dites le minimum vrai et utile (« on a un incident de sécurité, ne touchez pas à vos postes, attendez les consignes ») : un mail alarmiste envoyé à tout le monde déclenche des initiatives malheureuses, quelqu'un va vouloir « vérifier » en se reconnectant. Vers l'extérieur, la communication se prépare avec la direction et, si vous en avez un, un conseil juridique, parce que certaines formulations vous engagent. Le silence total est rarement une bonne idée non plus, surtout si des clients sont concernés, mais ça se décide à froid, pas sous le coup de la panique.

Mes sauvegardes sont sur un NAS connecté au réseau. C'est un problème ?

Oui, et c'est même un des scénarios qui finit le plus mal. Un rançongiciel un peu sérieux cherche activement les partages réseau et les volumes de sauvegarde montés : si votre NAS est accessible depuis les machines compromises, il sera chiffré avec le reste, et vous découvrirez votre seule bouée déjà percée. La règle qui vous épargne ça : au moins une copie hors ligne ou hors d'atteinte (déconnectée, immuable, ou sur un compte séparé que les machines de production ne peuvent pas toucher). À vérifier avant l'incident, parce que le jour J il est trop tard pour s'en apercevoir.

Le CERT-FR ou l'ANSSI, ça sert à quoi pour une petite structure, concrètement ?

Le CERT-FR publie des alertes et des fiches de remédiation par famille de menace, accessibles à tout le monde : pendant un incident, retrouver le mode opératoire d'un rançongiciel connu vous fait gagner des heures de tâtonnement. L'ANSSI, elle, n'intervient pas en direct chez une TPE lambda (ce n'est pas son rôle), mais elle outille l'écosystème et qualifie les prestataires de réponse à incident, ce qui vous aide à choisir un intervenant sérieux plutôt que le premier numéro trouvé en panique. Pour une petite structure, le réflexe gagnant reste souvent un prestataire qualifié plus les ressources publiques en appui, pas l'État qui débarque.

Que faire dans les premières heures d'un incident

Un client m’appelle un samedi matin. Rançongiciel sur son parc, repéré la veille au soir, et son équipe avait déjà « pris les devants » : tout éteint, machines débranchées de la prise, et restauration lancée dans la nuit sur les serveurs jugés sains. À mon arrivée, deux d’entre eux étaient de nouveau chiffrés. Ils avaient effacé en mémoire la moitié des traces dont j’avais besoin, et rouvert la porte par laquelle l’attaquant était entré. Tout ça avec les meilleures intentions du monde. C’est exactement ce que les premières heures peuvent coûter quand on agit dans le désordre.

Parce que ces premières heures décident de la suite. Ce que vous faites pendant ce créneau, et surtout ce que vous évitez de faire, sépare le redémarrage dans la journée du chantier de trois semaines. Voici l’ordre qui compte.

Dans les premières heures d’un incident, l’ordre des gestes décide de tout : isolez la menace du réseau sans couper l’alimentation, préservez les preuves, mesurez l’étendue, puis restaurez seulement depuis une sauvegarde sûre, et ne gérez pas ça seul.

Isoler sans détruire

Stoppez la propagation. C’est le seul objectif de la première minute : débranchez du réseau les machines touchées pour que l’attaque cesse de s’étendre, en laissant les systèmes dans l’état où vous les avez trouvés. Couper le courant d’un coup, c’est tentant quand l’adrénaline monte. Mauvais réflexe presque à tous les coups, parce que vous effacez ce qui vit en mémoire, et il arrive même que l’extinction brutale déclenche un mécanisme qui aggrave les dégâts. Donc : on isole du réseau, on ne touche pas à l’alimentation, sauf raison sérieuse.

Préserver les preuves

Avant de réparer quoi que ce soit, figez la scène. Journaux, état des systèmes, traces de l’origine : ces éléments racontent comment l’attaquant est entré, et sans eux vous réparez à l’aveugle. J’insiste là-dessus parce que l’instinct pousse exactement à l’inverse. On veut nettoyer, vite, faire disparaître le problème. Or balayer la scène trop tôt, c’est se condamner à ne jamais savoir par où c’est passé, et donc à recommencer.

Évaluer l’étendue

Quelles données, quels serveurs, jusqu’où est-il allé ? Y a-t-il eu exfiltration ? Cette dernière question est loin d’être un détail : si des données personnelles sont sorties, vous basculez dans des obligations de notification, et l’horloge tourne dès l’instant où vous le constatez. On mesure l’ampleur réelle avant d’agir. Un poste isolé qui a chopé un malware, ce n’est pas du tout le même chantier qu’un parc entièrement chiffré, et confondre les deux vous fait soit paniquer pour rien, soit sous-estimer un désastre.

Restaurer, mais une fois qu’on a compris

C’est le geste qui coûte le plus cher quand il est mal placé, et l’histoire du début le montre assez bien. Restaurer dans la foulée, par réflexe, sans savoir par où ça s’est joué, ça revient à remettre les clés sous le paillasson : la faille est toujours là, ouverte, et la réinfection tombe parfois en moins d’une heure. Vous restaurez après avoir colmaté la voie d’accès, depuis une sauvegarde antérieure à la compromission et dont vous avez la certitude qu’elle est saine. Cette certitude-là, elle se prépare bien avant l’incident, pas le jour où le téléphone sonne.

Ne pas rester seul

Un incident sérieux géré en solo, sous pression, à une heure du matin, ça tourne mal neuf fois sur dix. Mobilisez les bonnes personnes selon ce qui est touché : technique, direction, prestataires. Respectez les obligations de notification (NIS2 impose des délais courts aux entités concernées). Et tenez la communication, parce qu’un message envoyé sous le coup de la panique fait parfois plus de dégâts que l’attaque elle-même.

Tout ce qui précède s’improvise très mal. Un plan de réponse écrit à froid (j’y consacre un autre article) transforme la nuit d’incident en exécution de gestes décidés au calme. En vingt-cinq ans, personne ne m’a jamais dit avoir regretté d’avoir préparé ce plan.

Une réserve, quand même, pour rester honnête. Cet ordre des gestes suppose que vous gardez assez de sang-froid pour le suivre, et que vous avez une marge de manœuvre : du temps, des sauvegardes propres, quelqu’un à appeler. Sur un parc déjà chiffré à 90 %, sans sauvegarde hors ligne et avec une activité à l’arrêt qui saigne de l’argent chaque heure, la théorie cède vite à l’arbitrage. Aucune méthode ne remplace ce qui se joue avant : la préparation, et les sauvegardes que vous avez réellement testées. Le reste, c’est de la limitation de casse.

Si vous lisez ces lignes en pleine attaque : débranchez le réseau sans éteindre, ne restaurez rien dans la précipitation, et appelez de l’aide maintenant.