La faille logicielle Log4j devrait semer le chaos sur Internet pendant des mois, voire des années. La mise à jour des correctifs est devenue une véritable course à l'armement pour les entreprises et les administrations publiques. La réussite dépendra de la visibilité du réseau, de la rapidité d'application des correctifs et des processus de travail.
Log4j est un utilitaire de journalisation. Il est utilisé par la quasi-totalité des services cloud et des réseaux d'entreprise à travers le monde pour accéder aux serveurs. Il s'agit simplement de la dernière faille en date dans la chaîne d'approvisionnement logicielle (à l'instar de celle qui a été mise au jour lors de l'attaque massive contre SolarWinds) qui vient aujourd'hui perturber nos vies numériques.
Mais la vérité concernant ces vulnérabilités de la chaîne d'approvisionnement est la suivante : elles peuvent — et doivent — être contrôlées avant qu'elles ne causent des dommages.
[À lire également : Qu'est-ce que la norme Log4j et comment protéger votre organisation ?]
Nick Selby, ancien responsable de la sécurité chez Paxos, une société spécialisée dans les services de blockchain, ne souhaite pas prendre de risques inutiles en matière de sécurité de la chaîne d'approvisionnement des logiciels . C'est pourquoi il s'inquiète de la manière dont de nombreuses organisations se protègent aujourd'hui.
« Nous essayons de sécuriser les environnements modernes à peu près de la même manière qu’il y a 20 ans, ce qui alimente une incompréhension totale de la surface d’attaque », met en garde Selby. « C’est un aspect que le secteur doit changer – et rapidement », ajoute-t-il.
Ce malentendu s'explique en grande partie par un manque de visibilité sur les risques de sécurité liés aux logiciels tiers, aux services logiciels dans le cloud et aux logiciels libres. « Les risques liés aux tiers, qu’ils proviennent de la chaîne d’approvisionnement ou de vulnérabilités au sein des composants logiciels tiers, continuent de constituer un facteur majeur dans les violations de données d’origine externe », a averti Sandy Carielli, analyste principale chez Forrester Research, lors du récent forum « Security & Risk Forum 2021 » organisé par l’ . « Les organisations comptent probablement plus de tiers que jamais au sein de leur écosystème », a-t-elle ajouté.
Les attaques visant les chaînes d'approvisionnement logicielles d' ont connu une forte augmentation pendant la pandémie. L'été dernier encore, l'outil d'Atlassian dédié à la gestion de projets agiles et au suivi des bogues logiciels présentait une faille d'attaque « en un clic » qui permettait à un pirate informatique de s'introduire dans le système de planification agile ou dans le dépôt de code de l'entreprise, ce qui lui donnait la possibilité d'injecter des exploits dans le code source d'un utilisateur qui ne se doutait de rien.
Comme l’a déclaré Chris Condo, analyste en sécurité chez Forrester, lors du forum sur la sécurité et les risques organisé par cette société : « Vous ne vous rendriez même pas compte que quelqu’un s’est connecté et a modifié votre logiciel. » « Voilà le genre de problèmes qui se produisent quotidiennement. »
Selon l'Agence de l'Union européenne chargée de la cybersécurité (ENISA), les attaques visant la chaîne d'approvisionnement (dont toutes ne sont pas rendues publiques) auraient quadruplé entre 2021 et 2020. L’ENISA souligne que dans 66 % de ces attaques, les pirates ont d’abord ciblé le code source du fournisseur afin de poursuivre leurs attaques jusqu’à la cible finale.
Les pirates se tournant de plus en plus vers les attaques de type « chaîne d’approvisionnement », les organisations doivent comprendre comment mieux se protéger. Considérez cela comme la première étape de toute gestion des vulnérabilités fondée sur les risques.
Adaptez vos tactiques pour faire face à des attaques en constante évolution
Les attaques visant la chaîne d'approvisionnement se multiplient, car elles permettent de toucher de grandes entreprises qui n'ont pas modifié, depuis des décennies, leur approche en matière de gestion des risques liés aux technologies d'entreprise et aux tiers. « Les entreprises n’ont pas su s’adapter à la manière dont les entreprises modernes achètent, développent et gèrent leurs technologies », explique Selby, coanimateur du podcast « Tech Debt Burndown » de l’ , qui a récemment quitté Paxos pour rejoindre Trail of Bits, un cabinet de recherche et de conseil en cybersécurité. « Nous continuons à mener des vérifications préalables pour le compte de tiers à partir de feuilles de calcul établies dans le ’90s par des comptables. »
«Les organisations comptent probablement plus de tiers que jamais au sein de leur écosystème. »
Ces stratégies ont porté leurs fruits à une époque où le principal risque de sécurité lié aux failles de sécurité impliquant des tiers résidait dans la divulgation de données confidentielles ou l'interruption des services. Mais ils ne s'en sortent pas très bien face aux risques liés à des acteurs tiers qui visent à mener une attaque directe destinée à paralyser ou à bloquer votre organisation à l'aide d'un rançongiciel. Une stratégie de gestion des vulnérabilités fondée sur les risques doit en tenir compte.
Voici comment fonctionnent les attaques par la chaîne d'approvisionnement. Plutôt que de cibler directement les organisations, les cybercriminels et les pirates informatiques agissant pour le compte d'États s'attaquent aux éditeurs de logiciels et aux prestataires de services logiciels. Ils injectent du code malveillant dans des logiciels qui sont ensuite utilisés par d'autres organisations. Ces pirates ciblent spécifiquement les pipelines de développement logiciel vulnérables et les configurations cloud non sécurisées, ou exploitent les processus de mise à jour logicielle.
À la suite du piratage dévastateur de SolarWinds, les autorités fédérales se sont efforcées d’aider les agences et les organisations du secteur privé à mieux gérer les risques liés à la chaîne d’approvisionnement en s logicielles. Dans le cadre de l’initiative « mai 2021 », le président Biden a publié un décret présidentiel intitulé « » (Amélioration de la cybersécurité nationale), qui impose aux fournisseurs de logiciels du gouvernement fédéral de joindre une liste des composants logiciels (SBOM) pour l’ensemble des éléments composant leurs produits.
Une SBOM s'apparente à une liste des composants et des dépendances d'une application ou d'un progiciel, qu'il s'agisse de code propriétaire ou open source.
« Ce décret prévoit des mesures sans précédent », a déclaré Alla Valente, analyste de recherche senior chez Forrester, devant l'auditoire du forum sur la sécurité et les risques organisé par l'entreprise. Bien qu'il ne s'agisse ni d'une solution miracle ni d'un substitut aux bonnes pratiques de cybersécurité , ce décret a permis d'accélérer les efforts en matière de sécurité de la chaîne d'approvisionnement.
Allan Friedman partage cet avis. M. Friedman, défenseur de la SBOM au sein de l’Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA), a déclaré lors d’une récente table ronde organisée par SecurityWeek et réunissant des responsables de la sécurité des systèmes d’information (CISO) sur le thème de la transparence en matière de sécurité de la chaîne d’approvisionnement « » : « L’une des choses qui me tient particulièrement à cœur est l’amélioration de l’analyse et de la surveillance de la chaîne d’approvisionnement. »
Aménager un ralentisseur
L'évaluation des fournisseurs tiers de services cloud et de logiciels commence par une analyse de leur niveau de maturité en matière de sécurité. Avant de s'engager avec un éditeur de logiciels, M. Selby commence par effectuer un test simple et direct destiné à éliminer ceux dont les programmes de sécurité ne sont pas encore au point.
« Chez Paxos, nous utilisions un questionnaire de 10 questions comme évaluation préliminaire, et celui-ci revêt une importance capitale. » « Nous avons mis cela en place comme une mesure de ralentissement, et non comme notre évaluation finale en matière de sécurité ou de conformité », précise-t-il.
«Si [votre responsable de la sécurité est] le vice-président de l'ingénierie, alors vous n'avez pas de programme de sécurité. »Nick Selby, ancien directeur de la sécurité informatique chez Paxos
Parmi les questions préliminaires, on trouve notamment : « Disposez-vous de politiques et de procédures de sécurité consignées par écrit et imprimées ? » Puis-je les voir ? Parlez-moi de votre programme d'entraînement. Disposez-vous d'un cadre désigné dont la seule responsabilité est la sécurité de l'information ?
« Si c’est le cas, et qu’il s’agit du vice-président chargé de l’ingénierie », déclare Selby, « alors vous n’avez pas de programme de sécurité. » « Je veux entendre : “Oui, j’ai un responsable de la sécurité, un responsable de la sécurité des systèmes d’information, un directeur de la sécurité des systèmes d’information” — quelqu’un qui soit pleinement responsable et qui doive rendre des comptes quant à la mise en œuvre de la sécurité. »
Un élément essentiel de toute évaluation de la sécurité d'un logiciel de type « » devrait également inclure des revues de code effectuées par des tiers. M. Selby conseille aux organisations qui envisagent d'adopter un logiciel de gestion de la chaîne logistique de s'attacher à bien comprendre le processus de développement logiciel du fournisseur ainsi que les pratiques de codage sécurisé de son équipe d'ingénieurs. « Suivez-vous une formation au codage sécurisé, et en quoi consiste-t-elle ? » demande Selby. « Parlez-nous de votre programme d'entraînement. »
Le fait de passer avec succès un contrôle de sécurité ne signifie pas pour autant que le prestataire remportera le marché. Mais cela signifie tout de même qu'ils ont franchi la première étape, la plus élémentaire et la plus cruciale, des tests. « Nous savons au moins que nous pouvons être sûrs qu’ils répondront à nos exigences en matière de conformité, de sécurité et de respect de la législation », déclare Selby.
« Et c’est exactement ce que, selon moi, les organisations devraient faire : impliquer les services de sécurité dès le début des processus d’intégration des nouveaux fournisseurs. » « Malheureusement, les entreprises n’intègrent toujours pas la sécurité avant la toute dernière étape. »
L'open source est gratuit, mais il n'est pas sans risque
Pour garantir une sécurité adéquate de la chaîne d'approvisionnement, il est également nécessaire d'identifier et de comprendre quels sont les services logiciels et les logiciels, tant sur site que dans le cloud, qui sont exécutés dans l'environnement réseau. « C'est un défi plus complexe qu'il n'y paraît à première vue », explique Selby.
L'utilisation de composants open source rend la tâche encore plus difficile. « Lorsque les organisations utilisent l’open source pour créer des applications, ou l’intègrent dans des logiciels disponibles dans le commerce – qui contiennent eux-mêmes jusqu’à 90 % de code open source –, elles introduisent dans leur environnement un niveau effrayant de risques liés aux tiers », a déclaré M. Valente lors du forum sur la sécurité et les risques.
«Les logiciels disponibles dans le commerce contiennent jusqu’à 90 % de code open source, ce qui entraîne un niveau inquiétant de risques liés aux tiers. »
La gestion des risques liés aux logiciels libres exige des équipes de sécurité qu'elles examinent minutieusement le code de ces logiciels. Cela ne signifie pas qu’il suffit de vérifier la présence de vulnérabilités connues et de considérer que tout va bien si tous les correctifs sont à jour.
« La plupart du temps, c’est ce qui se passe » lors d’un bilan au sein d’une équipe de sécurité, explique Selby. « Ils vérifient s’il existe des CVE [vulnérabilités et expositions courantes] pour le projet open source, et s’il n’y a pas de vulnérabilités critiques, ils le jugeront acceptable. » « C'est complètement fou. »
Les équipes de sécurité doivent au contraire examiner l'ensemble des composants et des dépendances logicielles au sein d'un projet open source, et comprendre comment les différents composants ont été évalués et testés pour détecter d'éventuelles failles de sécurité.
« L’open source signifie que le code source est accessible afin que vous puissiez l’utiliser, l’évaluer et l’améliorer », explique Selby. « L’open source ne signifie pas “à prendre ou à laisser”. »
La sécurité de la chaîne d'approvisionnement logicielle en pratique
Alors que le décret présidentiel de M. Biden impose de nouvelles exigences aux agences fédérales afin d’améliorer leurs programmes de sécurité — telles que la mise en œuvre d’une architecture « zero trust » ( ), l’amélioration des stratégies de sécurité dans le cloud ( ) ( ) et la mise en place de SBOM —, l’Institut national des normes et des technologies (NIST) s’emploie à concrétiser ces outils.
“Stop using the same spreadsheets that procurement weasels have used since the ’90s.”Nick Selby
Lors d'un récent atelier, le NIST a examiné les mises à jour apportées à sa publication spéciale intitulée « » (SP 800-218). Publié en septembre 2021, ce document présente en détail un ensemble de pratiques fondamentales de développement logiciel sécurisé de haut niveau que les organisations peuvent intégrer dans leurs cycles de vie de développement logiciel. Les directives définitives relatives à l'utilisation des SBOM seront publiées sur le site février 2022.
Par ailleurs, l'Administration nationale des télécommunications et de l'information (NTIA) a récemment défini les éléments minimaux requis dans les SBOM. Ces informations doivent notamment inclure le nom de l'éditeur du logiciel, les données relatives à la version du logiciel, les identifiants uniques permettant d'identifier les composants logiciels, un répertoire des dépendances entre les composants, ainsi qu'une trace indiquant qui a créé la SBOM et à quelle date. La NTIA a reconnu trois normes ouvertes pour le partage d'informations relatives aux SBOM : SPDX, CycloneDX et SWID.
Selon les analystes, ces trois normes présentent chacune des différences. Alors que le SWID est conçu pour assurer le suivi des licences logicielles et des droits commerciaux, le SPDX couvre les licences, les composants logiciels, les informations de sécurité et d'autres métadonnées. Par ailleurs, la norme CycloneDX est axée sur la sécurité des logiciels.
« »« CycloneDX est spécialement conçu pour répondre à toute une série de cas d'utilisation en matière de cybersécurité qui vont bien au-delà des critères minimaux requis publiés par la NTIA », a déclaré Steve Springett lors de la récente table ronde des RSSI organisée par SecurityWeek. M. Springett est président du groupe de travail « CycloneDX SBOM Standard » de l'Open Web Application Security Project (OWASP), une communauté en ligne qui publie gratuitement des articles, des méthodologies, de la documentation, des outils et des technologies consacrés à la sécurité des applications web.
[À lire également : Votre agence est-elle prête à faire face à la fin de vie d'un logiciel ?]
À mesure que les normes continuent d'évoluer, les organisations qui souhaitent améliorer l'efficacité de leur développement logiciel sécurisé devront se contenter des moyens dont elles disposent. Ces processus ne sont pas faciles à mettre en place, et les outils destinés à vous y aider évoluent sans cesse.
Il n'en reste pas moins essentiel que les organisations commencent à sécuriser leur chaîne d'approvisionnement logicielle. « Les entreprises devraient réfléchir à la manière de tirer parti de leurs logiciels existants, qu’il s’agisse d’une plateforme GRC ou d’une plateforme de gestion des risques liés aux tiers », a déclaré M. Valente à l’auditoire du forum.
Si la sécurité de la chaîne d'approvisionnement logicielle commence par un examen minutieux des processus de sécurité et du cycle de vie du développement logiciel sécurisé, les cybercriminels et les États-nations continueront de lancer des attaques contre les fournisseurs de services, puis de s'en servir comme tremplins pour s'en prendre aux clients. Les clients qui ont mis en place les meilleures pratiques générales en matière de sécurité seront mieux à même d'assurer la sécurité au sein de leur organisation.
Cela implique de bien connaître les logiciels utilisés au sein de votre organisation et de veiller à ce qu’ils soient correctement mis à jour et protégés par des correctifs, de mettre en place une gestion de configuration efficace, ainsi que de disposer de capacités performantes en matière de surveillance et de gestion des incidents .
Quant à Selby, il affirme que l'une des mesures les plus importantes que les organisations puissent prendre dès à présent est d'abandonner au plus vite les anciennes méthodes de gestion des risques liés aux logiciels tiers et à la chaîne d'approvisionnement.
“Stop using the same spreadsheets that procurement weasels have used since the ’90s,” he says. « Il est temps de reformuler ces questions afin de mettre l’accent sur la manière dont ces organisations gèrent les risques pour leur environnement. »
