Log4Shell, la sécurité informatique est-elle une option ?

Le week-end dernier fut quelque peu agité pour le monde de l’IT avec la publication d’une faille dans la bibliothèque Log4j découverte le 24 novembre dernier et corrigée le 6 décembre. Je ne reviendrai pas dessus, de très nombreux articles ont expliqué la problématique et sa portée, et la page Wikipedia à son sujet est une bonne base d’information. Cet événement me donne surtout envie d’exprimer mon ressenti vis à vis d’un sentiment d’indifférence envers la sécurité informatique dans les entreprises.

J’ai découvert l’info comme beaucoup de monde à travers mes différentes lectures d’actualités et rapidement je me suis inquiété vis à vis de outils basés sur Java que nous utilisons au boulot pour connaître notre plan d’action. Notamment Jenkins car nous l’utilisons comme orchestrateur de toute notre intégration continue. L’équipe sécurité de Jenkins a cependant confirmé que la bibliothèque n’est pas utilisée dans le code de base de ce dernier, mais alerte concernant ses plugins tiers.

En arrivant lundi au boulot, dépilage usuel de mails, et je constate une chose : silence radio. Voilà quelque chose qui m’inquiète, étant architecte au sein d’une équipe au coeur de la chaîne de delivery logicielle de mon client, je ne cache pas ma surprise de ne voir passer aucune communication de la DSI. Après m’être auto-saisi du sujet, j’apprends ensuite qu’il y a bien eu des actions d’audit réalisées durant le week end pour traiter les éléments les plus critiques, mais la redescente managériale n’a pas vraiment été réactive. De mon côté, je décide donc d’aller sonder nos différents prestataires développant des logiciels pour le client, mais aussi nos éditeurs de logiciels, et enfin de notre boîte à outils interne.

Après avoir faire le tour du propriétaire, mais aussi au travers de divers autres sujets traités ces deux derniers jours, je constate amèrement que la sécurité informatique est toujours considérée comme une option.

Une réunion au sujet d’une livraison de nouveaux environnements applicatifs, j’entends encore le prestataire de l’infogérence demander “comment envoyer les mots de passe ? par mail ? … Bon sang ! Comment est-il possible en 2021, à l’heure où les ransomware, keyloggers, phishings et autres saletés sont légion, d’entendre ça ?!

Plus tard, des nouvelles de la part de l’éditeur d’un progiciel utilisé par le client, “audit en cours, on revient vers vous”. Je ne peux m’empêcher d’être étonné qu’un éditeur logiciel ait besoin de réaliser un audit pour ça, maîtrise-t-il son ensemble applicatif ?

Prise de contact avec le directeur de projet et un dev d’une des sociétés de service développant certains outils du client. Bonne nouvelle, ils n’utilisent pas de version vulnérable de Log4j… Pour cause, ils sont encore sur la version 1.x qui n’est plus supportée depuis 2015. Sérieusement ?

Récemment nous traitons aussi différents irritants relatifs au déploiement souvent hasardeux d’une application et je découvre aussi avec horreur que toute la stack logicielle est obsolète et datée. Et cela ne semblait choquer personne au sein des équipes projets.

D’autres équipes projets n’arrêtent pas de bloquer, invoquant plannings serrés et autres “enjeux business” pour maintenir en vie des plateformes applicatives de test qui utilisent des versions d’OS et logiciels obsolètes… Pire encore, toutes les productions ont été basculées vers des socles parfaitement à jour et maintenus. Quelle est la valeur ajoutée de tester une application sur un système obsolète différent de sa production ? Pourquoi un changement aussi simple et maîtrisé (l’industrialisation du déploiement est quasi totale…) provoque-t-il autant de passion ?

Des discussions relatives à la transformation d’une application assez ancienne vers un modèle plus moderne à base de microservices et de containérisation… L’équipe projet refuse de payer les changements de code ou de couche logicielle car “n’y “voit pas l’intérêt”. Fiabiliser un produit n’a aucun intérêt ? Réduire ses coûts de maintenance non plus ? Réduire les temps de déploiement de nouvelle fonctionnalité est sans intérêt ? Comment peut-on encore avoir une vision aussi étriquée d’un système d’information ?

Il y a un meme Internet qui circule régulièrement au regard des trop fréquentes actualités relatives à la cybersécurité.

Et derrière on oublie aussi la conséquence.

C’est triste à dire, mais il a trop souvent tendance à se vérifier.

Je n’ai pas la prétention d’être un expert en sécurité informatique, ce n’est pas mon métier, mais elle est une des composantes de mon activité. J’essaye de toujours l’avoir en tête dans mes activités et roadmap, en particulier lorsqu’il s’agit d’intégrer une nouvelle application au SI et donc de lui faire hériter de tous les acquis de l’expérience des autres. Tout en essayant de gagner des niveaux de sécurisation sur l’existant que ce soit au travers de projets dédiés ou bien d’opportunités.

Ce n’est pas pour rien d’ailleurs qu’on parle beaucoup plus de culture DevSecOps que DevOps. La démarche initialement proposée par DevOps a beaucoup aidé à fluidifier la chaîne de valeur (pour peu qu’elle ait été comprise), mais inclure la sécurité by design et de manière automatique reste quelque chose qui manque.

En fait, si je voulais résumer l’un des gros soucis que je constate dans l’IT, c’est qu’il y a deux composantes essentielles qui sont les plus oubliées : la sécurité et la qualité, sacrifiées sur l’autel des deadlines et des budgets taillés à la truelle. Alors qu’un projet logiciel qui inclut ces deux éléments de base, c’est un projet qui a plus de chances de succès qu’un projet construit selon des idées à court terme.

Il me reste quelques éléments dans mon sac que je n’ai pas encore vidé sur le sujet, mais cet article est déjà assez long comme ça. J’aborderai dans un prochain les travers de l’extrême inverse sur la sécurité, et aussi dans un autre billet quelques exemples sur l’absence de qualité dans l’IT.

N’hésitez-pas à me contacter par les différents moyens proposés sur ce site si vous souhaitez partager vos expériences sur le sujet !