Cyberattaques de la chaîne d'approvisionnement logiciel : 3 principaux enseignements
2021 est une année à part dans l'actualité des attaques ciblant la chaîne d'approvisionnement logiciel. Les organisations doivent tirer trois grands enseignements afin d'assurer leur sécurité.
Repérer les risques
Développer, gérer et maintenir une chaîne de développement logiciel s’apparente à tout ce qui dépend d’une chaîne : il est essentiel de comprendre et d’avoir une visibilité totale sur chacun de ses maillons. Prenons l’exemple simple d’une équipe de sauveteurs : elle doit connaître les compétences précises de chacun de ses membres, savoir d’où provient l’équipement de premier secours, quelles sont les langues parlées par chacun et, enfin, maîtriser l’environnement d’intervention. Ne pas avoir ces informations revient à fonctionner à l’aveugle, sans avoir connaissance des risques éventuels encourus. Les entreprises doivent adopter la même approche lorsqu’elles cherchent à protéger leur chaîne d’approvisionnement logiciel, en s’assurant que chacun de ses maillons est sûr.
De nouvelles vulnérabilités critiques seront mises au jour au niveau de cette chaîne, c’est inévitable, particulièrement étant donné le nombre croissant de librairies et frameworks open source déployés au sein des organisations à travers le monde.
Pour garantir leur sécurité, les entreprises doivent donc absolument disposer d’un inventaire précis des composants open source qu’elles utilisent. Nul ne peut se permettre de faire une confiance aveugle à la provenance et à la sécurité de ses composants logiciels. Les attaques Log4Shell, Spring4Shell et SolarWinds ont été une source d’enseignements précieux : il faut examiner à la loupe les logiciels utilisés au sein d’une organisation. Cela suppose ainsi de connaître leur lieu et mode de développement, comment ils sont utilisés au sein de l’entreprise, de sorte que si une vulnérabilité est détectée, celle-ci pourra être corrigée rapidement et, ainsi, les dégâts éventuels seront limités.
Éviter d’ajouter à la complexité
Le deuxième prérequis est de se prémunir des risques évidents, surtout lors du développement de frameworks ou de librairies. Là encore, il est tout aussi important d’opter pour une approche simplifiée afin de ne pas introduire de nouvelle faille sans le savoir.
Mieux vaut s’attacher à en faire moins, mais mieux, que d’introduire un grand nombre de nouvelles fonctionnalités en s’y prenant mal. Dans le cas de la faille du logiciel de journalisation Log4J, toutes les conditions étaient réunies pour en faire un produit populaire, sans que personne ne se doute qu’il était si vulnérable. A l’évidence, plus les fonctionnalités sont nombreuses et plus les chances sont grandes qu’elles renferment une vulnérabilité critique. A l’heure de sélectionner les nouvelles fonctionnalités dont vous souhaiteriez doter vos nouveaux produits et services, demandez-vous si vous en avez vraiment besoin ; mieux vaut retenir celles jugées véritablement essentielles. Les entreprises ont sans doute besoin de développer rapidement de nouveaux produits, mais elles doivent absolument prendre le temps de réfléchir aux fonctionnalités vraiment nécessaires en se demandant ce qui motive cette idée. Tout ce qui relèvera du bonus est en effet susceptible de laisser la porte ouverte à des vulnérabilités.
Miser sur la simplification
Les organisations doivent avoir conscience des problématiques transversales lors des phases de conception et de développement de leurs applications. Qu’il s’agisse des fichiers journaux (logs), des métriques, des communications chiffrées ou de la mise en cache, il est important de se demander si ces soucis permanents doivent être réglés au sein de l’application ou s’il ne serait pas possible, plutôt, de les externaliser.
Prenons un exemple : avec le logging, de nombreux frameworks peuvent envoyer des journaux vers différentes cibles, y compris vers des fichiers contenant des sorties de commande stdout et des services d’alerte ; cette tâche incombant alors à votre application. Or il existe une meilleure approche, plus sécurisée, à privilégier. Il vaut mieux faire en sorte que votre application envoie les logs vers des fichiers contenant les sorties de commande stdout puis d’utiliser un service de collecte de logs, afin de diriger ces logs vers les destinations finales souhaitées. En externalisant ces éléments, les développeurs auront moins de portions de code et de configurations à prendre en charge, ce qui réduira d’autant les risques d’introduction de vulnérabilités.
Les contrecoups
Les incidents Log4Shell et Spring4Shell auront au moins permis aux organisations de prendre conscience du besoin impérieux de sécuriser en amont leurs environnements. Une tâche qui sera néanmoins de plus en plus difficile, étant donné le rythme effréné de l’innovation qui engendre une forte croissance des parcs d’identités machine à gérer.
Superviser et gérer ces identités machine tout en veillant à ce que la totalité des composants logiciels et le développement des applications demeure simple, ne sera pas chose facile. Aujourd’hui, les organisations ne disposent pas des compétences et des ressources nécessaires. Pour relever ce défi, elles peuvent se doter d’outils d’automatisation et de sécurisation qui permettront de limiter au maximum la présence de vulnérabilités pour ne pas alimenter des vagues d’attaques similaires à celles qui a ciblé Log4j.