Moins de deux heures plus tard, les systèmes concernés sont isolés, notre plan de gestion de crise est activé et les investigations forensiques ont déjà commencé. Si l'attaque elle-même n'a duré que peu de temps, la gestion de ses conséquences nous mobilisera pendant près de trois semaines.

La principale bonne nouvelle était que nos systèmes de production destinés aux clients ont continué de fonctionner pendant toute la durée de l'incident. À l'issue de l'analyse forensique, aucun élément n'indiquait que les données de nos clients, notre code source ou nos bases de données de production avaient été affectés. Notre entreprise a néanmoins traversé près de trois semaines de gestion de crise, durant lesquelles nous avons dû faire face simultanément à des défis techniques, organisationnels et juridiques.

Aujourd'hui, nous avons choisi de partager publiquement cette expérience. Non pas pour présenter une réussite sans faille, mais pour revenir avec transparence sur une attaque qui nous a rappelé que même les entreprises disposant de solides compétences en cybersécurité peuvent présenter des vulnérabilités et commettre des erreurs.

L'essentiel n'est donc pas d'être à l'abri de toute erreur, mais d'être préparé lorsqu'un incident survient. Une bonne préparation permet de limiter la propagation d'une attaque, d'en réduire les dommages et d'aider une entreprise à maintenir ses activités en période de crise. Il est tout aussi important d'analyser ensuite l'incident avec honnêteté et de tirer les enseignements de cette expérience.

Les 120 premières minutes

Alors que les attaquants tentent encore de faire pression sur nos collaborateurs par téléphone, nos premières mesures d'urgence sont déjà engagées. Toutes les personnes concernées sont réunies lors d'une visioconférence, notre plan de réponse aux incidents est activé et les responsabilités sont réparties entre les investigations forensiques, la restauration technique, les questions juridiques et la communication.

Parallèlement, nos équipes techniques commencent à arrêter de manière contrôlée certaines parties de l'infrastructure et à déconnecter systématiquement du réseau les systèmes touchés. Une première analyse forensique est lancée tandis que les mesures nécessaires pour contenir l'attaque sont coordonnées en parallèle.

Dans une telle situation, il reste très peu de temps pour de longues discussions sur la répartition des responsabilités. Il faut rapidement déterminer quels systèmes doivent être arrêtés, qui documente les mesures techniques prises et qui se charge d'informer les collaborateurs, les clients et les interlocuteurs externes. Dans le même temps, les éventuelles obligations de déclaration et d'information doivent être examinées, et la collaboration avec des spécialistes en analyse forensique et en droit doit être organisée.

En temps normal, bon nombre de ces questions paraissent évidentes, jusqu'au moment où il faut y répondre sous une pression considérable. Le fait que les rôles et les responsabilités aient déjà été globalement définis chez nous n'a pas empêché l'attaque, mais a permis d'éviter qu'une crise organisationnelle vienne s'ajouter à l'incident technique.

Lundi : les services clients fonctionnent, mais les activités internes sont perturbées

Le soulagement le plus important apparaît dès le lundi suivant : nos systèmes de production destinés aux clients continuent de fonctionner normalement. Nos plateformes SaaS restent disponibles et, selon les informations dont nous disposons alors, rien n'indique que l'environnement de production ait été compromis.

Cette continuité des services clients n'est pas le fruit du hasard, mais le résultat d'une architecture de sécurité conçue dans ce but. Nos systèmes de production et nos systèmes administratifs sont strictement séparés. En interne, nous appelons cette approche notre « principe du sous-marin » : à l'image de compartiments étanches, des séparations techniques doivent empêcher qu'un incident de sécurité survenant dans une zone ne se propage librement au reste de l'infrastructure.

Cette séparation s'est révélée particulièrement précieuse pendant l'attaque. Malgré cela, les répercussions sur notre fonctionnement interne ont été considérables. Les systèmes administratifs n'étaient que partiellement disponibles, plusieurs processus internes ont dû être réorganisés provisoirement et les investigations techniques, les évaluations juridiques ainsi que la communication avec les clients et les collaborateurs se déroulaient simultanément.

Cet incident nous a clairement montré qu'une cyberattaque peut perturber une grande partie de l'entreprise, même lorsque les services destinés aux clients restent opérationnels. La disponibilité des systèmes de production ne signifie pas nécessairement que le reste de l'activité peut se poursuivre sans difficulté.

La prévention reste notre objectif. Mais lorsque la prévention échoue, c'est la résilience qui fait la différence. Une architecture de sécurité bien pensée ne doit donc pas seulement chercher à empêcher les attaques, mais également à en limiter les conséquences aussi efficacement que possible lorsqu'un incident survient.

La question la plus difficile : à quels systèmes pouvons-nous encore faire confiance ?

Dans certaines circonstances, un système touché peut être restauré relativement rapidement à partir d'une sauvegarde existante. La question bien plus complexe est de savoir si ce système peut ensuite être considéré comme suffisamment sûr pour être remis en service.

Pendant la phase de restauration, nous avons donc dû déterminer non seulement quels systèmes et quelles données avaient été affectés, mais aussi si des comptes utilisateurs avaient été compromis, si de nouveaux accès avaient été créés ou si des autorisations avaient été modifiées à notre insu. Ce n'est qu'après avoir suffisamment clarifié ces points qu'il devient possible de décider de manière responsable quels systèmes peuvent être reconnectés au réseau et remis en exploitation.

Il s'agit précisément de l'une des difficultés les plus souvent sous-estimées après une cyberattaque. Réussir à restaurer les données ne signifie pas automatiquement que le niveau de sécurité initial de l'infrastructure a été rétabli. Cela nécessite une vérification technique approfondie et, dans certains cas, une reconstruction complète des systèmes concernés.

Le point d'entrée était un périphérique réseau discret

Notre analyse forensique a révélé qu'une vulnérabilité présente dans un équipement réseau périphérique avait servi de premier point d'entrée aux attaquants. À partir de cet appareil, ils ont réussi à progresser dans l'environnement administratif et à obtenir des privilèges supplémentaires.

Cette découverte a été particulièrement importante pour nous, car elle a mis en évidence l'étendue réelle de la surface d'attaque d'une entreprise. Lorsqu'il s'agit de sécuriser une infrastructure informatique, l'attention se porte souvent sur les serveurs, les postes de travail et les pare-feu. On oublie facilement que des équipements réseau moins visibles disposent eux aussi de logiciels, de comptes utilisateurs et d'accès au réseau.

Si ces appareils ne sont pas régulièrement mis à jour, correctement segmentés et surveillés de manière rigoureuse, ils peuvent devenir le point de départ d'un incident de sécurité bien plus important. Notre expérience a ainsi confirmé qu'une architecture de sécurité complète doit également prendre en compte les composants qui semblent, à première vue, peu importants.

Exfiltration de données administratives, tandis que les systèmes clients restent opérationnels

Au cours de l'attaque, des données ont été exfiltrées de notre environnement administratif. Il s'agissait notamment de données internes de l'entreprise et de données relatives aux collaborateurs. L'incident a donc eu des conséquences réelles, même si nos systèmes de production destinés aux clients sont restés disponibles.

À l'issue des investigations forensiques, aucun élément n'a indiqué que l'environnement de production ou les données des clients avaient été compromis. Cette distinction était essentielle, tant pour notre évaluation interne que pour notre communication externe.

Vu de l'extérieur, une cyberattaque se résume souvent à une affirmation simplifiée : une entreprise a été piratée. En réalité, les conséquences techniques et commerciales peuvent être extrêmement différentes. Il existe une différence majeure entre un incident touchant des systèmes administratifs et une attaque au cours de laquelle des cybercriminels parviennent à accéder aux environnements de production des clients.

Nous avons donc décidé d'informer rapidement nos clients et nos collaborateurs, en privilégiant une communication transparente. Nous avons expliqué quelles zones étaient touchées selon les informations disponibles à chaque étape, quels systèmes ne présentaient aucun indice de compromission et quelles mesures avaient déjà été engagées pour contenir l'attaque et en analyser les conséquences.

Cette transparence n'a pas toujours été facile à assumer, mais elle était nécessaire. Plutôt que de laisser les incertitudes s'amplifier faute d'informations suffisantes, nous souhaitions fournir des éléments factuels et compréhensibles permettant à nos clients et collaborateurs d'évaluer la situation.

Pourquoi la restauration a pris près de trois semaines

Nos sauvegardes ont fonctionné et les données concernées étaient stockées sous forme chiffrée, avec une séparation à la fois logique et physique des systèmes affectés. La restauration des données en elle-même ne constituait donc pas notre principal défi.

La tâche la plus exigeante consistait à assainir en profondeur l'infrastructure touchée et à garantir que les systèmes pourraient ensuite être exploités à nouveau dans des conditions de sécurité suffisantes. Pour cela, les systèmes concernés ont été reconstruits ou restaurés à partir de sauvegardes vérifiées, puis soumis à des mesures supplémentaires de renforcement de la sécurité avant leur remise en service.

En parallèle, nous avons contrôlé les structures critiques d'authentification et de gestion des accès, dont certaines ont dû être reconstruites. Par mesure de précaution, tous les mots de passe ont également été renouvelés afin de réduire les risques liés à d'éventuels identifiants compromis.

Ce renouvellement généralisé des mots de passe s'est transformé en un défi organisationnel souvent sous-estimé dans le quotidien des entreprises. Pour remplacer de manière fiable tous les identifiants nécessaires après une attaque, une organisation doit savoir quels comptes existent, qui en est responsable et de quels systèmes ils dépendent.

Les comptes administrateurs oubliés ou les comptes de service peuvent notamment compliquer inutilement une telle opération d'assainissement. En l'absence d'une vue d'ensemble complète de ces accès, la charge de travail augmente, tout comme le risque que certaines autorisations compromises passent inaperçues.

Cette période de restauration de près de trois semaines nous a montré que des sauvegardes fonctionnelles constituent une condition indispensable à la continuité des activités, mais qu'elles ne garantissent pas, à elles seules, un retour rapide et sécurisé à la normale.

Six décisions qui ont permis de limiter les dommages

Avec le recul, six décisions et mesures préparées en amont ont joué un rôle particulièrement important pour nous aider à contenir les conséquences de l'attaque et à rétablir progressivement nos activités.

1. Une segmentation rigoureuse

La séparation stricte des systèmes administratifs et des environnements de production a limité la propagation de l'attaque et empêché ses conséquences de s'étendre librement à l'ensemble de notre infrastructure. L'enquête forensique n'a révélé aucun indice de compromission de nos systèmes de production destinés aux clients.

2. Des sauvegardes séparées et fiables

Nos sauvegardes étaient chiffrées, séparées logiquement et physiquement des systèmes touchés, et leur restauration était effectivement possible. Nous disposions ainsi d'une base fiable pour reconstruire notre infrastructure sans dépendre d'un éventuel paiement de rançon.

3. Des responsabilités clairement définies

Grâce à une répartition des responsabilités établie à l'avance, la restauration technique, les investigations forensiques, les évaluations relatives à la protection des données et la communication ont pu être coordonnées simultanément. Cette préparation nous a fait gagner un temps précieux et a réduit le risque que des décisions importantes soient négligées pendant les premières heures critiques.

4. Une communication proactive

Plutôt que d'attendre la fin de toutes les investigations, nous avons informé rapidement nos clients et nos collaborateurs des conséquences connues de l'incident. Nous avons veillé à communiquer uniquement des résultats vérifiés et à distinguer clairement les informations confirmées des questions encore ouvertes.

5. La capacité de rétablir les systèmes sans payer de rançon

Nos sauvegardes intactes et la séparation stricte de l'environnement de production nous ont permis de poursuivre la restauration de manière autonome, sans verser de rançon aux attaquants. Le facteur déterminant a été notre capacité à nous appuyer sur des mesures techniques et organisationnelles déjà en place.

6. Le soutien de spécialistes externes

Nous avons fait appel à des spécialistes externes et à des conseillers en protection des données pour accompagner l'analyse forensique et l'évaluation juridique de l'incident. Leur expérience nous a aidés à examiner l'attaque de manière structurée et à prendre des décisions importantes sur des bases solides. Une crise en cours n'est pas le moment idéal pour découvrir les procédures essentielles en procédant par essais et erreurs.

Ce que nous avions sous-estimé et ce que nous faisons différemment aujourd'hui

L'attaque nous a permis de constater non seulement quelles mesures de sécurité avaient été efficaces, mais aussi quelles faiblesses subsistaient. Nous avions notamment sous-estimé l'importance de la protection des équipements réseau périphériques et de la surveillance des environnements administratifs.

Nous avons depuis pris des mesures concrètes pour remédier à ces lacunes. À la suite de l'incident, nous avons renforcé la rigueur avec laquelle nous contrôlons la segmentation de notre infrastructure, les autorisations existantes, les niveaux de mise à jour et nos processus de surveillance. Nous utilisons désormais également des technologies assistées par l'intelligence artificielle afin d'améliorer davantage nos capacités de détection et de surveillance.

Toutefois, ces améliorations ne constituent pas un projet ponctuel qui pourrait un jour être considéré comme définitivement terminé. Les infrastructures informatiques évoluent constamment, de nouvelles vulnérabilités apparaissent et les attaquants adaptent continuellement leurs méthodes. Les concepts de sécurité doivent donc être régulièrement réévalués et adaptés aux nouvelles exigences.

Cet incident nous a surtout confirmé qu'il est impossible d'éliminer totalement les vulnérabilités et les erreurs humaines. Il est donc d'autant plus important de mettre en place, avant qu'un incident ne survienne, les bases techniques et organisationnelles nécessaires pour contenir une attaque et en gérer les conséquences.

Ces bases reposent notamment sur une architecture de sécurité soigneusement conçue, des responsabilités clairement définies, des mécanismes de protection efficaces et une volonté de remettre régulièrement en question les processus existants. Il est tout aussi essentiel d'analyser ouvertement les incidents après leur résolution et d'intégrer systématiquement les enseignements tirés dans la stratégie de sécurité à long terme de l'entreprise.

La préparation fait la différence avant même qu'un incident ne survienne

Une cyberattaque ne prend pas automatiquement fin lorsqu'un serveur compromis a été arrêté ou qu'une sauvegarde a été restaurée avec succès. La gestion de l'incident n'est véritablement achevée que lorsque les systèmes concernés fonctionnent à nouveau de manière fiable et sûre, que les accès critiques ont été contrôlés et sécurisés, et que les collaborateurs comme les clients ont reçu des réponses claires et fiables à leurs questions.

Notre expérience a démontré que la cybersécurité va bien au-delà de la simple protection technique des systèmes. Elle concerne tout autant la continuité des activités, les responsabilités organisationnelles, la transparence de la communication et la capacité des dirigeants à prendre des décisions éclairées sous une pression considérable.

Chaque entreprise devrait donc se poser une question essentielle : seriez-vous aujourd'hui capable d'isoler rapidement une partie de votre infrastructure informatique, de la restaurer à partir de sauvegardes sûres et de maintenir vos activités essentielles, sans devoir d'abord déterminer qui prend les décisions et quelles mesures doivent être engagées ?

Nous avons dû répondre à cette question dans des conditions réelles et avons pu mesurer directement toute la valeur d'une préparation rigoureuse.

Je souhaite à chaque entreprise de trouver sa réponse avant d'être confrontée à cette question sous une véritable pression.