Alain Bouillé (CESIN) : « le risque est de faire plus de conformité que de cybersécurité »

En tant que délégué général du CESIN (Club des Experts de la Sécurité de l’Information et du Numérique), qui représente la communauté des RSSI en France, vous avez exprimé des attentes en matière de réglementation. Pourquoi ?

Alain Bouillé : La réglementation est à la fois une bénédiction et une malédiction pour les RSSI.

Il existe une forte tendance, qui s’amplifie ces dernières années, à sur-réglementer dans certains secteurs particuliers. Certains RSSI me disent : « je n’ai plus un rôle de CISO mais je fais de la sécurité ‘check-the-box’, de la réponse à des questionnaires de conformité au lieu de me préoccuper des véritables risques pesant sur mon organisation. » Or, si la sécurité-conformité est une tendance majeure, c’est très dangereux à la fois pour la cybersécurité réelle des organisations et pour la profession de RSSI. D’une certaine manière, trop de réglementation peut tuer la cybersécurité des entreprises.

Trop de réglementation tue la cybersécurité des entreprises.

C’est d’autant plus gênant que certaines réglementations se chevauchent ou se contredisent. En particulier, les entreprises transnationales se retrouvent parfois avec des règles différentes et contradictoires dans leurs différents pays d’implantation.

D’un autre côté, la réglementation est aussi une excellente chose. Par exemple, le Cyber-relisience Act est un très bon exemple. Contrairement au RGPD ou aux règles sectorielles que j’évoquais à l’instant, il ne va pas concerner les entreprises utilisatrices de technologies mais les fournisseurs, ce alors que nous faisons face à une croissance exponentielle des vulnérabilités. Auparavant, il suffisait d’appliquer le Patch Tuesday et quelques autres patchs puis on était tranquille. Ce qui était dans un datacenter n’était pas exposé. Aujourd’hui, tout est connecté, le SaaS est généralisé et les programmes propres sont souvent hébergés en IaaS/PaaS. La moindre vulnérabilité a donc forcément un impact sur la sécurité du SI et des données de l’entreprise.

Parfois, la faille peut même passer sous le radar. Je vais prendre un exemple qui peut sembler, au premier abord, anecdotique. Une entreprise prend un abonnement auprès d’une compagnie de taxis. Avec cet abonnement vient un SaaS pour réserver des taxis où sont inclus les données de noms, prénoms, adresses mail, adresses personnelles, peut-être cartes bancaires… de tous les cadres de l’entreprise. Toutes ces données sont donc externalisées dans un SI, celui de l’opérateur de taxis. Si l’opérateur se fait pirater, toutes ces données (y compris les mails et mots de passe habituels) sont en danger. Du coup, elles constituent une fuite majeure de données et peuvent servir à réaliser une attaque par rebond (si un couple mail / mot de passe d’utilisateur à pouvoir présent dans la fuite peut être utilisé par ailleurs…).

En dehors de certaines rares exceptions (armée, aviation…), il y a zéro exigence sur la qualité des logiciels. C’est pour cela que le Cyber-resilience Act nous intéresse. Il pourrait introduire une règle qui obligerait les fournisseurs de logiciels à ne plus faire n’importe quoi en matière de sécurité, même si le 100 % sûr n’est évidemment pas possible.

Quelles difficultés particulières voyez-vous, en informatique au sens large, du point de vue de la responsabilité des fournisseurs ?

C’est très simple et tout à fait unique. Quand j’achète une voiture, si je constate un défaut, je ramène la voiture en concession et c’est au constructeur de réparer. Si un défaut est dans la conception ou général, le constructeur doit procéder à une campagne de rappels.

En matière de logiciels, c’est l’inverse. Le client doit réparer à ses risques et périls. L’éditeur envoie un patch et advienne que pourra. Or, quand on patche, on doit procéder à des tests de non-régression. Il n’est pas si rare qu’un éditeur doive s’y reprendre à quatre ou cinq fois avant de fournir un patch valide et efficace.

En gros, pour reprendre l’image de la voiture, l’éditeur nous envoie la clé de 12 et à chacun de se débrouiller. Si la réparation n’est pas faite, c’est l’entreprise qui doit assumer le risque. De plus, il n’existe aucun recours contre l’éditeur du logiciel.

Du coup, quelles obligations vous souhaitez voir dans la future réglementation ?

Il faut une responsabilité juridique de l’éditeur si son logiciel met en danger l’entreprise.

D’abord, c’est la finalité recherchée, il faut une obligation de qualité du code d’un point de vue sécurité. En deuxième lieu, il faut une responsabilité juridique de l’éditeur si son logiciel met en danger l’entreprise, quelques puissent être les clauses contractuelles imposées par l’éditeur.

Quel est votre avis sur les réglementation européennes plus ou moins récentes ?

Plusieurs règles impactent directement les RSSI. Sous NIS 1, des pans entiers de l’économie sont passés sous le radar mais sont rattrapés par la patrouille avec NIS 2 (l’alimentaire par exemple). Mais on risque d’être dans la situation de sur-réglementation que j’évoquais au début de notre entretien.

Si on excepte ce risque de sur-réglementation, avez-vous eu des déceptions sur ce sujet dans le passé ?

Le RGPD a été le bienvenu pour faire face aux errances constatées chez de grands acteurs transnationaux. Mais on a utilisé un marteau-pilon pour tuer une mouche. Au final, les acteurs comme Facebook, Twitter, etc. ont été conformes assez vite. Et, même si on connaissait les principe en France depuis 1978, beaucoup d’autres entreprises ont eu énormément de difficultés à se mettre en règle.

Et puis, nous aurions aimé, dans la foulée du RGPD, une loi sur les données non-personnelles (secrets de fabrique, informations sensibles non personnelles…). Il y a des travaux sur le sujet mais nous avons l’impression, avec le seul RGPD, de marcher sur une seule jambe. Finalement, on fait de la conformité RGPD et, pour le reste, on compte sur la conscience professionnelle des RSSI qui doivent quémander des budgets et des moyens pour sécuriser les « autres » données sensibles.