Stratégie

Incidents cyber : les entreprises demandent aux RSSI de garder le silence

---

Une étude montre que 69 % des RSSI ont été sommés par leur employeur de garder le silence sur les incidents cyber. Soit 27 points de plus qu'il y a deux ans. Malgré un environnement réglementaire qui, lui, réclame un signalement toujours plus rapide des attaques.

PublicitéLes RSSI sont soumis à une pression croissante pour garder le silence sur les incidents de sécurité que connait leur organisation, car les préoccupations liées à la réputation de celle-ci priment souvent sur le respect de la conformité réglementaire. Selon une récente enquête de l'éditeur Bitdefender, plus des deux tiers (69 %) des RSSI ont été sommés de maintenir la confidentialité sur ces incidents. Ces chiffres sont en nette hausse : il y a deux ans, seuls 42 % des RSSI disaient avoir à faire face à ce type d'injonction.

Martin Zugec, directeur des solutions techniques chez Bitdefender, explique que l'évolution des méthodes des cybercriminels pourrait avoir une influence directe sur la chape de plomb entourant certaines violations de données. « Les attaques traditionnelles par rançongiciel, qui chiffraient les données et imposaient leur divulgation publique, sont en baisse, souligne-t-il. Les attaquants se concentrent de plus en plus sur le vol de données sans interruption de service, rendant les violations moins visibles aux yeux des clients ou du public.»

Même lorsque le chiffrement est utilisé, il est souvent limité à l'infrastructure back-end. Par exemple, une attaque récente du groupe RedCurl a spécifiquement ciblé les hyperviseurs, évitant les systèmes susceptibles d'impacter les utilisateurs finaux. « Cette approche minimise les retombées publiques et ouvre la voie à des négociations de gré à gré, ce qui accroît la pression exercée sur les RSSI en matière de divulgation », dit Martin Zugec.

Malgré la pression réglementaire

Or, les RSSI ont également une pression réglementaire, notamment issue des règles de protection des données, telles que le RGPD, et des réglementations des marchés financiers, qui exige, elle, la divulgation rapide des incidents cyber. D'autres réglementations, telles que la législation européenne sur la cybersécurité et la résilience (Cyber Security and Resilience Act), DORA et NIS2, renforcent cette surveillance réglementaire.

Les RSSI sont contraints de minimiser ou d'éviter de signaler les problèmes de conformité, malgré le risque de responsabilité personnelle qu'ils encourent en cas de non-signalement des incidents de sécurité. Bryan Marlatt, directeur régional du cabinet de conseil en cybersécurité CyXcel et ancien RSSI, expliqué avoir quitté son ancien employeur après qu'on lui ait demandé de minimiser un incident de sécurité. « Chez cet employeur, le DSI m'avait demandé de ne pas partager les risques avec le comité d'audit et de sur-valoriser les capacités de sécurité sur le formulaire 10K de la SEC (le gendarme des bourses aux Etats-Unis, NDLR), raconte Bryan Marlatt. Cela fait suite à l'ordre que j'ai reçu de ne pas divulguer les détails d'une compromission de messagerie professionnelle survenue récemment. » L'ancien RSSI précise « le DSI était à un an avant de la retraite et ne voulait pas faire de vagues, comme il le prétendait.»

Publicité« L'intégrité est plus importante pour moi que n'importe quelle somme d'argent. C'est pourquoi, lorsqu'on m'a demandé de ne pas divulguer les détails d'un incident et d'enjoliver les mérites des dispositifs de sécurité, j'ai démissionné », tranche Bryan Marlatt.

« Intense pression » pour garder le silence

Deux autres anciens RSSI ont fait état de pressions afin qu'ils gardent le silence sur des suspicions d'incidents de sécurité. Tous deux ont souhaité garder l'anonymat en raison d'accords de confidentialité de fin de contrat conclus avec leurs précédents employeurs. « Lorsque je travaillais dans une entreprise européenne du Fortune Global 500, j'ai été témoin de ce phénomène à plusieurs reprises, explique l'un d'eux. La pression était particulièrement intense avant les assemblées générales des actionnaires ou la publication des rapports financiers trimestriels. »

Le même indique : « chaque incident devait d'abord être transmis au DSI, qui le signalait à son équipe de direction ou au conseil d'administration - généralement au directeur financier - indépendamment de l'urgence ou des délais réglementaires. La justification était toujours la même : "Il ne s'agit pas nécessairement d'un incident de cybersécurité." La décision finale de divulgation était systématiquement prise sans intervention du RSSI. »

Cet ancien RSSI donne quelques exemples qu'il a personnellement rencontrés :

- Vol de données dans le développement automobile : environ 500 Go de données techniques et personnelles sensibles ont été volés par un initié, puis vendus sur le dark web. Cause première : mauvaise configuration de la gestion des identités et des accès (IAM). Non divulguée, car il s'agissait « de données volées, et non d'un piratage ».
- Abus de droits de super-administrateur par un responsable de la sécurité : un cadre supérieur dans la cyber a abusé de ses droits d'administrateur pour intimider ses subordonnés et accéder aux comptes de membres du conseil d'administration et d'autres personnes clefs de l'entreprise. Le centre des opérations de sécurité l'a détecté. Il a été qualifié de « mauvaise configuration » et non de cyberattaque.
- Piratage d'une entité à l'étranger : des pirates ont détourné environ 50 millions d'euros de paiements de fournisseurs SAP via une faille de sécurité, bien aidés par l'absence d'authentification multifacteur. Non divulgué, car cela « ne tombait pas sous le coup des lois de l'UE ».
- Identifiants administrateur volés : CrowdStrike a signalé un compte super-administrateur toujours actif. Les logs étaient manquants. Les Red Team et Blue Team ont recommandé la réinitialisation de l'IAM. Un conseil ignoré, car « aucun préjudice direct n'a été détecté ».
- Scandale de corruption impliquant le RSSI : un fournisseur du Big Five a soudoyé le RSSI du groupe au niveau global et deux de ses subordonnés directs en leur accordant des vacances et d'autres avantages coûteux pour obtenir des contrats internationaux. Les preuves ont été ignorées. Le RSSI a été discrètement remplacé, non sans une importante indemnité de départ, et l'équipe a été priée de ne pas en parler.

Un deuxième ancien RSSI nous a fait part d'un incident au cours duquel son employeur a été informé d'une suspicion de violation de données impliquant des informations privées : des adresses e-mail et des noms. Après avoir déterminé que la source du problème ne provenait pas de son organisation, mais du développeur d'un site web tiers, le RSSI s'est vu demander de ne pas signaler le problème, même si des données clients étaient concernées, car ce n'était « pas son problème » et l'entreprise souhaitait préserver sa relation commerciale avec le site web tiers.

Pris au piège

Ces situations illustrent la position inconfortable dans laquelle se trouvent souvent les RSSI : légalement responsables de la sécurité, mais contraints de faire fi des normes lorsque la divulgation des incidents entre des conflits avec les intérêts de leur organisation. « L'entreprise ne comprend pas vraiment ce que cela implique pour les personnes qui se soucient vraiment du sujet », explique notre première source, ajoutant que, face à des situations de ce type, elle a obtempéré aux demandes de silence. « Il n'existe aucune véritable protection, financière ou réputationnelle, pour les lanceurs d'alerte, qu'il s'agisse d'un RSSI ou de tout autre responsable de la sécurité qui dénoncerait une situation de cette nature », constate notre source.

Témoigner peut mettre fin à une carrière.

« Dans mon cas, je suis sûr d'avoir été signalé, reprend notre source. Lors d'un entretien d'évaluation, on m'a expliqué que si je voulais atteindre le sommet de l'organisation, je devais me conformer davantage aux exigences de l'entreprise et moins à celles de mon équipe. Cette conversation a été l'une des principales raisons de mon départ. »

Bryan Marlatt de CyXcel ajoute que les dirigeants d'entreprise tentent souvent de dissimuler la survenue d'un incident, même s'il est susceptible d'avoir un impact sur leurs clients ou partenaires commerciaux. « En tant que consultant, j'ai entendu parler de nombreux RSSI à qui l'on demandait de ne pas divulguer les détails d'un incident, ou de ne pas révéler qu'il s'était produit, indique-t-il. Avec la multiplication des rançongiciels et la nécessité de faire appel à des prestataires externes pour l'investigation numérique, la réponse aux incidents ou la déclaration de sinistres, il devient beaucoup plus difficile de dissimuler des incidents importants. »

Le silence n'est pas d'or

Caroline Morgan, associée chez CM Law, reconnait que, au sein des entreprises, la pression pour garder le silence est réelle, tout en avertissant que les régulateurs non seulement attendent, mais exigent la divulgation des incidents de sécurité. « Juridiquement, en gardant le silence, une entreprise ne fait probablement qu'aggraver ses problèmes, au lieu de les éviter, dit-elle. Le prix à payer peut être dévastateur, car il ne s'agit plus seulement de violation, mais aussi de dissimulation. »

« Les régulateurs peuvent utiliser cette propension à garder le silence pour démontrer une tendance à la non-conformité et imposer des sanctions importantes, avertit la juriste. L'atteinte à l'image de marque, la perte de confiance des clients et, pire encore, des poursuites judiciaires peuvent également en résulter. »

Et Caroline Morgan poursuit : « si un responsable de la sécurité informatique ou un autre responsable tente de dissimuler des incidents et est découvert, cela signifie souvent la fin de sa carrière et un risque de poursuites personnelles, une amende des régulateurs ou, pire encore, des poursuites pénales. » Ce risque est loin d'être théorique. Joe Sullivan, ancien directeur de la sécurité d'Uber, a été reconnu coupable d'avoir dissimulé une faille de sécurité en 2016 et condamné à une peine de probation.

Un cadre préétabli pour la réponse aux incidents

Car le signalement rapide des incidents est le fondement des lois sur la protection des données. « Les entreprises peuvent réduire considérablement leur exposition [aux risques] en reconnaissant que la pression interne exercée pour ne pas signaler les incidents constitue une menace et en mettant en place des solutions pour la minimiser avant qu'une faille ne se produise, conseille Caroline Morgan. Et elles peuvent minimiser la pression interne en s'assurant de disposer d'un plan de réponse aux incidents solide, dont le cadre favorise la transparence, incluant des formations sur la gestion éthique des incidents et un pouvoir décisionnel séparé des fonctions commerciales ».

Article rédigé par

John Leyden, CSO (adapté par Reynald Fléchaux)

Partager cet article