Avec autant d'équipes de sécurité et de développeurs faisant des post mortem sur le fiasco de la vulnérabilité de sécurité Log4j qui s'est déroulé fin 2021, à peine 10 jours avant Noël, la question principale est :comment éviter ce type de douleur à l'avenir ? La réponse, malheureusement, est... c'est compliqué.
Couverture de sécurité à lire absolument
Selon de nouvelles données de (ISC)2, la plus grande association à but non lucratif au monde de professionnels certifiés de la cybersécurité, près de la moitié (48 %) des équipes de cybersécurité ont renoncé aux vacances et aux week-ends pour aider à la remédiation, et 52 % des équipes ont passé "des semaines ou plus ” corrigeant Log4j. Pas exactement comment les développeurs déjà surchargés voulaient passer les vacances.
En revanche, la douleur de cette expérience a déclenché une refonte majeure de la sécurité de la chaîne d'approvisionnement logicielle de la part des développeurs et des équipes de sécurité.
Corriger les vulnérabilités sans casser le code hérité
L'un des aspects les plus gênants de Log4j n'était pas la vulnérabilité elle-même, mais la profondeur de l'intégration de la technologie dans le code hérité. Après tout, Java est l'une des plates-formes les plus populaires au monde, et Log4j est un système de journalisation Java incroyablement populaire dont la sortie initiale remonte à 2001. Ainsi, Log4J touche non seulement une tonne de systèmes de production, mais aussi beaucoup d'héritage code.
"Personne ne veut toucher au code hérité", a déclaré Sergei Egorov, PDG d'AtomicJar, la nouvelle startup à l'origine du framework de test d'intégration open source, Testcontainers. "Vous n'avez pas seulement besoin de corriger une vulnérabilité de sécurité, vous devez savoir que vous avez corrigé la vulnérabilité sans casser votre système. Lorsque vous avez une vulnérabilité avec une bibliothèque de journalisation très populaire comme Log4j, vous parlez de dépendances à un code hérité qui manque généralement de tests, et où parfois les développeurs qui ont écrit le code et compris comment cela fonctionne ne travaillent même pas dans l'entreprise. plus."
Selon Egorov, Log4j est souvent une dépendance transitive d'autres bibliothèques qui doivent être mises à jour. Contrairement aux plates-formes qui fournissent des binaires statiques, avec les systèmes Java, la liaison du code se produit au moment de l'exécution, il n'y a donc aucun moyen d'avoir une certitude à 100 % que l'application se comportera correctement jusqu'à ce que vous l'exécutiez réellement et testiez la liaison en temps réel entre les dépendances et compilations.
Egorov a déclaré que Log4j a accéléré l'intérêt pour la plate-forme Testcontainers déjà populaire, comme moyen de tester ces interactions avant le déploiement en production. Il voit des développeurs qui ont été piqués par Log4j créer maintenant des tests d'intégration entre les systèmes et les dépendances externes, afin que la prochaine fois qu'une vulnérabilité de sécurité arrive, les développeurs puissent tester que leurs correctifs n'arrêteront pas les systèmes de production une fois déployés. Testcontainers est en train de devenir une association populaire avec Snyk, car les développeurs peuvent recevoir des demandes d'extraction pour des demandes de sécurité automatisées, et les tests d'intégration leur donnent la confiance qu'ils peuvent les fusionner sans rien casser.
Qu'est-ce qui est pire… la vulnérabilité ou la perturbation des utilisateurs ?
L'arrivée de la vulnérabilité de sécurité Log4j et son timing terrible pendant la haute saison des fêtes ont créé un choix pervers pour les équipes de développeurs :déployer des correctifs maintenant et risquer de mettre hors service les systèmes pendant les cycles de pointe du commerce électronique des fêtes, ou repousser le déploiement des correctifs à des intervalles moins risqués sur le plan commercial. ?
C'est une décision impossible à prendre si vous n'avez pas le bon contexte.
"Log4j a fait paniquer de nombreuses équipes d'ingénieurs car elles n'avaient aucun moyen de prédire comment sa réparation affecterait leurs utilisateurs", a déclaré Marcin Kurc, PDG de la startup de fiabilité logicielle Nobl9, dont les clients comprennent de grands détaillants en ligne. « Il y a une analyse coûts-avantages qui doit avoir lieu sur toute remédiation de sécurité. Vous devez déterminer le bon intervalle pour déployer le correctif, ce qui nécessite une compréhension complète du risque en termes de nombre d'utilisateurs qu'il pourrait affecter, et le niveau acceptable de non-fiabilité que vous pouvez accepter."
L'entreprise de Kurc défend un mouvement appelé objectifs de niveau de service (SLO) qui est né dans les pratiques d'ingénierie de fiabilité des sites de Google et que Nobl9 a commercialisé dans une plate-forme.
Les SLO permettent aux développeurs de modéliser le temps de disponibilité et les taux de réussite des interactions logicielles et de définir des seuils pour les résultats des utilisateurs, par exemple, quel pourcentage de paniers d'achat sont exécutés correctement. Les entreprises qui modélisent les SLO, dit Kurc, peuvent avoir une vraie conversation sur le risque de patcher ou de ne pas patcher.
De telles solutions, cependant, viennent après le fait ou, plutôt, après que le logiciel open source a été écrit. Mais que faisons-nous pour le rendre intrinsèquement plus sûr ?
Un problème plus large :à qui appartient la sécurité pour l'open source ?
Personne ne va arrêter d'utiliser l'open source. Il serait absurde de créer une solution de journalisation à partir de zéro, plutôt que de recourir à des outils comme Log4j. Les développeurs écrivent moins de logique et intègrent plus de frameworks, de bibliothèques et d'API ces jours-ci, et cela ne changera pas.
Comme Filippo Valsorda de Google l'a écrit dans un message viral, nombre de ces mainteneurs open source "entrent dans l'une des deux catégories suivantes :bénévoles ou employés de grandes entreprises. Parfois les deux. Aucun des deux modèles n'est sain."
Log4j a mis en lumière le fait qu'une grande partie de la chaîne d'approvisionnement logicielle moderne repose sur des projets open source avec une poignée de responsables, voire un seul responsable, qui a souvent créé la technologie en tant que projet parallèle. (Et soyons clairs :des données récentes suggèrent que la grande majorité de tous les logiciels open source sont écrits par moins de 10 personnes.)
"Les applications modernes sont construites à partir de nombreux composants, dont beaucoup ne sont pas développés en interne mais sont plutôt assemblés à l'aide de solutions" prêtes à l'emploi "", selon John France, CISO chez (ISC)2. "Une grande partie de la qualification et de l'identification des problèmes consiste à savoir quels composants et bibliothèques sont utilisés par votre logiciel et à conserver une nomenclature logicielle (SBOM)."
Mais selon un praticien de la sécurité anonyme dans le sondage de remédiation Log4 de (ISC) 2, "Les développeurs en général ont été très laxistes quant au suivi de ce qu'ils utilisent dans leur logiciel. Lorsqu'un événement comme celui-ci nous oblige à identifier si une bibliothèque ou un composant est utilisé par notre code, ce manque de traçabilité devient un problème majeur. Il transforme un simple exercice de vérification des inventaires et des SBOM en un processus de numérisation complexe, avec de nombreuses possibilités de faux positifs et de faux négatifs. Si jamais nous avions besoin d'un réveil, nous en avons eu un gros avec Log4j. »
Google et d'autres poids lourds se lancent dans ce défi de vulnérabilité de sécurité open source, et le temps nous dira si un investissement plus approfondi et une collaboration avec les fournisseurs peuvent aider à réduire la fréquence et la douleur des incidents comme Log4j. Mais en attendant, les développeurs élaborent des stratégies pour éviter de terribles surprises en matière de sécurité lors de la prochaine saison des fêtes.
Divulgation :je travaille pour MongoDB, mais ces opinions n'engagent que moi.
Lien source