Les vulnérabilités, talon d’Achille de la transformation numérique

Même si elle mobilise de nombreuses équipes informatiques dans le monde, la révélation il y a quelques jours de la vulnérabilité Apache Log4j, est probablement passée inaperçue des dirigeants comme du grand public. Cette vulnérabilité provient d’un défaut de sécurité sur un module logiciel très utilisé par les développeurs. La criticité de cette vulnérabilité réside dans la très large utilisation de ce module ainsi que dans la facilité de son exploitation pour mener des attaques informatiques. Elle a conduit à arrêter préventivement des applications, à mettre en place dans l’urgence des dispositifs de protection complémentaires et à implémenter des correctifs.

Au-delà de ce cas particulier, l’année 2021 a connu la publication officielle de plus de 18.000 vulnérabilités, soit une multiplication par trois en cinq ans, et même par dix sur les vingt dernières années. Ce chiffre est en outre largement sous-estimé car ne comptabilisant que les logiciels « industrialisés », soit environ la moitié du parc logiciel mondial, le reste étant constitué de logiciels spécifiques dits « à façon » faisant l’objet d’une moindre attention de la part des chercheurs en vulnérabilités.

Alors même que nous confions de plus en plus de nos vies au digital, les vulnérabilités, et le flot de cyber attaques qui en découle, sont devenues le talon d’Achille de cette transformation numérique. Une réaction vigoureuse de l’écosystème numérique est requise sous peine de compromettre la confiance placée en lui et d’hypothéquer ainsi son avenir.

Comment en est-on arrivés là, comment expliquer cette fragilité endémique ?

A l’origine c’est la qualité générale de production, des composants mais surtout des logiciels, qui est en cause. La complexité des applications, le plus souvent constituées de différents modules dont certains libres de droit (open source), la pression compétitive incitant à la mise rapide sur le marché, le défaut de formation des développeurs et la non-application de processus et de contrôle des développements sont assurément les causes primaires. Trop souvent, l’agilité du développement s’est construite au détriment de sa qualité et partant de sa sécurité. Cette crise démontre également, si cela était nécessaire, que les logiciels open source bien que résultant d’une démarche de transparence ne sont pas exempts de défaut de sécurité.

De plus, le partage de responsabilité entre l’éditeur et l’utilisateur est par trop déséquilibré pour que la situation s’améliore. En effet, si la publication du correctif est bien du ressort de l’éditeur, les dommages causés par les attaques exploitant cette vulnérabilité, les mesures de protection complémentaires temporaires, ainsi que le travail de mise en place du correctif, qui peut s’avérer complexe car engendrant des régressions et des dysfonctionnements, reste à la charge du client final.

Enfin, cette situation est alimentée par le développement d’un business, officiel ou plus opaque, de recherche de vulnérabilités. Certaines entreprises ou groupes se sont ainsi spécialisés dans la découverte et la revente de vulnérabilités, soit à l’éditeur pour renforcer sa sécurité, ce qui est vertueux, soit à des groupes d’attaquants, privés comme gouvernementaux. Une nouvelle vulnérabilité critique peut être négociée jusqu’à plusieurs millions de dollars.

Cette situation n’est pas tenable dans la durée, notamment en prévision du déploiement massif d’objets connectés interférant avec nos vies.

Si l‘éradication complète des vulnérabilités est souhaitable mais reste utopique à moyen terme, il est crucial de s’employer à en réduire le volume et la criticité.

Quatre mesures graduelles et complémentaires devraient pouvoir y contribuer.

En premier lieu, il s’agirait de renforcer la formation des développeurs à la sécurité en les incitant à utiliser des méthodes robustes et des outils de contrôle performants.

Il s’agirait également, comme cela se fait dans de nombreux secteurs, de valoriser davantage les solutions les plus sécurisées et d’obtenir ainsi le consentement à payer des entreprises et administrations en impliquant les directions générales dans ces choix. Les grands acteurs économiques et étatiques ont à cet égard un devoir d’exemplarité.

La question de la responsabilité des éditeurs sur les conséquences des vulnérabilités des logiciels qu’ils publient mérite également d’être posée et rééquilibrée en faveur de l’utilisateur et de l’intégrateur.

Enfin, en ultime recours, l’imposition réglementaire d’une démarche de certification et de normalisation du développement logiciel mériterait d’être envisagée, notamment à l’occasion de la future directive européenne NIS2. Même si ce type d’approche est difficile et présente certaines limites (coût, délais, suivi de version…) elle devrait pouvoir engendrer une spirale vertueuse pour bâtir une chaîne cohérente de sécurité : donner des gages, réclamer des garanties.

Ces mesures ne peuvent être initiées et portées exclusivement par le secteur privé et ne peuvent non-plus être limitées à l’échelle d’un pays sous peine d’être victime d’un biais concurrentiel. Avec le RGPD l’Europe a montré la voie, une démarche similaire sur le sujet des vulnérabilités trouverait assurément sa place dans l’agenda de la future présidence française de l’UE.