Cesin – Et si on osait la sécurité logicielle ?

Alain Bouillé, Délégué Général du CESIN

“On n’agit pas, par crainte d’impacts économiques ou pire, par manque de courage.”

L’année 2021 ne nous aura pas épargnés de cyber-attaques plus ou moins ciblées avec les ravages que l’on sait pour les entreprises et les collectivités, d’actes plus sophistiqués souvent téléguidés par des états, la cyber-guerre est à nos portes nous dit-on. A cela s’ajoutent aussi des faits de cyber espionnage de plus en plus répandus, rendus sans aucun doute beaucoup plus simples par l’usage massif du cloud, avec ce qu’il comporte encore de mauvaises pratiques, par manque d’expertise, entraînant une surexposition des données sensibles des entreprises utilisatrices.

Continuer à sécuriser le périmétrique, tenter de sécuriser les usages du cloud, officiels ou non, blinder la sécurité des Endpoints, forcer le MFA, gérer les multiples alertes collectées par les services de SOC externalisés ou non, gérer des crises à répétition, tenter de recourir à la cyber-assurance quand les assureurs ne mettent pas les barres trop haut, tel est l’infernal agenda du RSSI 2021 les conduisant pour certains à des situations de surmenage voire de burn-out. Le CESIN publie en cette fin d’année une étude éloquente en la matière.

Mais si on prenait le temps de s’interroger sur la cause principale de ce marasme ? Pour qu’une attaque réussisse, il faut une conjonction de plusieurs phénomènes mais l’exploitation de vulnérabilités logicielles ou matérielles reste bel et bien, le plus souvent, le point de départ de tous ces maux. Or, les chiffres le montrent, on est dans une courbe inflationniste en matière de vulnérabilités. Si à grand renfort de briques de sécurité empilées depuis des années et de stricts processus de gestion, on a réussi tant bien que mal à gérer les vulnérabilités dites d’infrastructure, la situation concernant la qualité des codes produits et celle de l’intégrité des solutions logicielles s’aggrave de jour en jour, cette dernière donnant lieu à des attaques dites « de la supply chain ». Ce phénomène trouve ses origines dans de multiples causes mais force est de constater que le RSSI est désormais obligé de faire des choix dans la gestion de ses rustines car il ne peut plus boucher tous les trous de la grande piscine gonflable des données de l’entreprise …

Des facteurs aggravants

D’aucuns affirment que ça n’est pas la sécurité logicielle qui se dégrade mais le fait que les hackers éthiques ou non fouillent de plus en plus dans les logiciels pour y trouver la porte d’entrée idéale pour y pénétrer et extraire des données ou pour y insérer un code malveillant. Quoi qu’il en soit, plusieurs facteurs aggravants sont survenus au cours de ces dernières années :

• Tout d’abord, le recours massif au cloud et particulièrement celui du mode SAaS implique que tout le monde utilise à un instant T les mêmes solutions sans pour autant avoir la main sur leur sécurisation en cas de publication de failles importantes dont le traitement reste à la main de l’éditeur.
• Dans la kyrielle des petites solutions SaaS, beaucoup sont développées à la va-vite, mal sécurisées, et utilisées par les entreprises, y compris les plus grandes, à la marge du SI traditionnel pour tout ce qui n’est pas « core business ». Or c’est souvent-là que l’on retrouve nombre de données sensibles, souvent à caractère personnel, dont la fuite et la divulgation peuvent avoir des conséquences dramatiques pour l’entreprise.
• L’apparition du DEVOPS avec le fameux argument de l’agilité n’a pas arrangé les choses. Mais où est l’agilité quand ces développements sont confiés à des prestataires, des développeurs indépendants, voire des étudiants, qui ont souvent peu de conscience et de connaissance en matière de sécurité des développements et qu’il faut à la fin remettre une couche de sécurité avant la mise en prod ? On a bien entendu très vite inventé le DevSecOps avec notamment ses outils d’audit de code, on a généralisé les tests d’intrusions automatisés ou non, et développé le bug bounty … mais pourquoi ne pas former tout ce petit monde à développer du code sécurisé dès le départ comme on le faisait pour les développements traditionnels ? Et finalement a-t-on vraiment calculé le ROI de ces développements dont la durée de vie est souvent assez courte ?
• Enfin on ne peut pas ne pas évoquer ici les grands éditeurs dont le nombre de vulnérabilités de leur suite logicielle fait quasiment partie de leur marque de fabrique depuis plusieurs décennies maintenant. L’industrie de la gestion des patchs, en termes de produits, mais surtout d’opérations, engloutit des sommes d’argent faramineuses si l’on additionne les budgets et les ETP que toutes les entreprises y consacrent. Que de projets de sécurisation préventive pourraient être menés à la place !

L’épisode Solarwinds, suivi de quelques autres, ont, semble-t-il, éveillé quelques consciences (mais pour combien de temps ?) et on ne compte plus les rapports, les groupes de travail à des niveaux plus ou moins élevés de l’échelle politique pour proposer des pistes pour, sinon régler ce problème (on n’atteindra jamais une sécurité à 100% du logiciel), du moins en endiguer l’inflation.

Ce qui est désarmant dans cet épisode Solarwinds et ses quelques répliques, c’est le caractère quasiment fataliste de son traitement. Que peut faire le RSSI même le mieux armé, si une société spécialisée telle que Fireye a certes détecté l’attaque mais plusieurs mois après son déclenchement et si des géants comme Microsoft n’ont rien détecté du tout ?  

Partant du principe que nulle forteresse n’est imprenable, on ne peut pas s’empêcher d’envisager un Patch Tuesday porteur de ce type de maux par exemple. Et là nous serons bien dans une situation de pandémie numérique mais pas nécessairement celle que l’on envisageait.

Alors que faire ?

Si on se hasarde à une comparaison avec le monde automobile, outre les cents ans du code de la route qui vient d’être célébré, si on désosse une voiture et que l’on met de côté tout ce qui concourt à la sécurité du conducteur et des passagers, on doit arriver à environ 70 % des composants de la voiture qui contribuent à la sécurité de ses usagers. Si on fait la même chose avec un logiciel, il y a fort à parier que la part du logiciel consacrée à la sécurité sera très décevante. Pourquoi une telle disparité ? Tout simplement parce que depuis l’apparition des premiers véhicules au début du siècle dernier, on s’est très vite rendu compte que l’on avait mis en service de formidables machines à tuer et que depuis, on n’a pas cessé de progresser en matière de fiabilité des véhicules. Il semblerait que le cahier des charges de la sécurité logicielle des voitures autonomes soit tellement exigeant qu’il en paraisse inatteignable pour les constructeurs. La justification de ces niveaux de réglementation semble bien entendu indiscutable.

Mais alors pourquoi observe-t-on une telle médiocrité dans la sécurité logicielle au sens large ? Parce que jusqu’à une période récente l’absence de sécurité logicielle n’a pas fait beaucoup de morts ! Alors faudra-t-il attendre des victimes en grand nombre après un piratage d’une usine de distribution d’eau ou plus simplement un dérèglement des feux de signalisation dans une ville justement « connectée » ou encore un phénomène de pandémie numérique tel que décrit plus haut ?

On sait ce qu’il faut faire pour sécuriser le code ou pour empêcher que des intrus ne le détournent, mais un peu comme pour le réchauffement climatique, on n’agit pas, par crainte d’impacts économiques ou pire, par manque de courage.

On n’a jamais autant parlé de souveraineté numérique qu’en ce moment mais selon l’adage « faites ce que je dis, pas ce que je fais », force est de constater que l’exemple ne vient pas encore d’en haut si l’on ne retient que de récentes décisions étatiques en matière de choix de solutions américaines plutôt qu’européennes.