La plupart des gens œuvrant en TI ont entendu parler de la faille de sécurité du logiciel log4j de Apache. C’est une faille qui permet a une personne malveillante de prendre le contrôle à distance d’un serveur. Une faille critique à laquelle il fallait remédier de toute urgence, à la mi-décembre 2021. Ça parait simple mais la situation était très complexe. Premièrement, la plupart des versions courantes de log4j avaient la faille (versions 2.0-beta9 à 2.14.1). Alors que la faille a été découverte le 24 novembre 2021 par un chercheur en cybersécurité chez Alibaba, il a fallu attendre jusqu’au début décembre avant d’avoir une version 2.15.0 réparée. Entretemps, notre “ami” chercheur qui a eu la générosité d’alerter Apache, a aussi publié le code permettant d’exploiter la faille.
Quelques jours plus tard, les mécanismes de protection ayant été implantés dans cette version 2.15.0 ont été contournés par les cybercriminels, et cela a donné lieu à la version corrective 2.16.0 *** copier/coller *** copier/coller *** copier/coller *** pour finalement arriver à la version 2.17.1.
Mais pourquoi cette faille a-t-elle fait couler autant d’encre? Parce qu’elle est critique, elle est facile à exploiter, le code pour l’exploiter est disponible, elle s’exploite à distance… et quoi encore? Ah oui, log4j est utilisé partout, partout, partout. Cette faille a eu un impact énorme dans le monde entier. Des organisations, et pas les plus petites, se sont retrouvées incapable de servir leur clients. Le gouvernement du Québec a du mettre plus de 4000 sites web gouvernementaux hors ligne de façon préventive pendant plusieurs jours. Et de tels scénarios se sont répétés un peu partout.
Comment cette faille a-t-elle pu mettre hors-service autant d’organisations? Comment log4j se retrouve-t-il au cœur des affaires menées par l’ensemble de la planète?
Les premiers touchés sont les éditeurs de logiciels qui utilisent log4j. Leurs produits sont soudainement devenus la cause d’incidents de sécurité partout dans le monde. Ces éditeurs de logiciel ont donc du travailler 24 heures sur 24 pour fournir des remédiations à leur clients. Ces clients eux, ont du non seulement patcher les serveurs (oui, les systèmes d’exploitation, les plateformes de virtualisations, les bases de données, etc. ont aussi été touchées), mais aussi contacter chaque fournisseur pour obtenir les remédiations de chacun d’eux et les déployer. Ça a été un cauchemar et les congés de fin d’année de beaucoup de gens ont été gâchés. Et après, les organisations ont réalisé qu’ils avaient oublié certains systèmes: le serveur pour les caméras de sécurité, l’application SaaS de gestion de trésorerie, etc. Janvier aussi fût donc le théâtre d’activités intensives pour régler le problème log4j.
Enfin, tout ça est maintenant derrière nous. Ou non?
Log4j est une composante logicielle parmi des dizaines de milliers d’autres qui sont peut-être présentes dans les environnements informatiques. Qui sait quelle autre composante logicielle va vous affecter dans le futur? Aura-t-on un autre log4j cette année? Le mois prochain? Comment s’appelleront ces variants?
Dans le domaine de l’ingénierie, il existe la notion de nomenclature de produit (Bill Of Materials (BOM) et Software Bill Of Materials (SBOM), en anglais). Ces nomenclatures listent, de façon hiérarchisée, la liste de toute les pièces, composantes, matériaux, etc. qui composent un produit physique, et donc par analogie les liste des composantes open source, librairies, etc. qui composent un logiciel. Les États-Unis considèrent rendre la production des BOMs pour tous les produits manufacturés aux USA. C’est une excellente idée.
Comme CISO/RSI/DSI, pourquoi attendre une loi? Exigez d’ores et déjà des BOMs de tous vos fournisseurs. À la prochaine faille affectant une composante logicielle, vous saurez déjà quels produits, quelles applications, quelles plateformes, et donc quels processus d’affaire sont aeffectés. Et vous pourrez gérer la situation bien plus proactivement.
Vous êtes éditeur de logiciels? Sachez que des outils comme Grype et Syft peuvent vous aider à produire ces BOMs.
Posons-nous aussi la question suivante: l’open source est en général maintenu par la bonne volonté de quelques personnes bénévoles. Quelle est la pertinence de la présence de l’open source dans des processus d’affaire critiques*? Des contrats de support existent pour certaines composantes open source et ces contrats ont des niveaux de service bien définis. C’est certainement quelque chose à considérer.
* Posons-nous encore une question : Y a-t-il une différence entre open source et logiciel marchand ? Pas forcément, une fois les failles découvertes, les correctifs sont développés soit par le collectif libre soit par le vendeur.
Certains vendeurs excellent à fournir ces correctifs, d’autres non. Certains collectifs sont bons et d’autres moins. Le code des applications est fait par des humains, et l’humain est presque toujours le maillon faible en cybersécurité. Ne vous demandez pas si le logiciel que vous utilisez aura des vulnérabilités, mais demandez-vous plutôt quand. Et déployez des mécanismes pour vous protéger en cas de vulnérabilité applicative.
