Les éditeurs de logiciels accordent-ils autant d'importance à la sécurité que vous ?

Une version de cet article a été publiée dans Security Magazine. Il a été mis à jour et syndiqué ici.

‍

Pour les professionnels de la sécurité, le 13 décembre a une signification particulière. Est-ce le jour où nous avons enfin éradiqué les injections SQL pour de bon ? Bien sûr que non. S'agit-il de la « Journée internationale de reconnaissance des travailleurs de la sécurité » ? Non plus. C'est le jour où FireEye et Mandiant ont publié leur rapport choc sur une campagne d'intrusion mondiale jusqu'alors inconnue, qui allait devenir célèbre sous le nom de SolarWinds. Le rapport détaillait une attaque en cours, presque incroyable, où du code malveillant était dissimulé au cœur des mises à jour du populaire logiciel de gestion Orion de SolarWinds.

Plus de 18 000 clients de SolarWinds avaient déjà téléchargé la mise à jour corrompue. Beaucoup l'ont fait automatiquement, comme ils le faisaient pour des centaines d'autres mises à jour logicielles au sein de leurs organisations et réseaux. Les attaquants ont été extrêmement sélectifs dans leurs cibles une fois l'accès obtenu via la faille SolarWinds. De nombreuses grandes entreprises, ainsi que des agences gouvernementales, ont vu leurs données volées et leurs réseaux compromis. Ce fut l'une des plus grandes et probablement la plus coûteuse des failles de tous les temps, d'autant plus que, dans le cas des agences gouvernementales, l'ampleur réelle des dégâts n'a jamais été rendue publique.

Et tout cela est arrivé parce que les entreprises ont fait confiance aux fournisseurs de leur chaîne d'approvisionnement logicielle sans vérifier ni auditer correctement leurs activités.

Le virage massif vers la sécurité de la chaîne d'approvisionnement

Une fois l'alerte donnée, les entreprises, les organisations et les agences gouvernementales ont réagi rapidement. La faille SolarWinds a été stoppée, bien sûr, mais l'attaque a également mis en lumière les dangers d'une chaîne d'approvisionnement logicielle non réglementée et non surveillée. Bien que l'incident SolarWinds ait été rapidement résolu une fois découvert, les implications concernant l'utilisation de la chaîne d'approvisionnement comme vecteur d'attaque persistent. Si cette attaque a eu un mérite, c'est bien celui d'avoir mis en lumière un aspect critique, mais négligé, de la cybersécurité.

L'une des réponses les plus médiatisées à l'attaque SolarWinds a été le décret présidentiel (Executive Order) de Joe Biden sur l'amélioration de la cybersécurité nationale. Ce décret est l'une des directives de cybersécurité les plus complètes jamais émises aux États-Unis. Il exige une meilleure cybersécurité au sein des agences et pour ceux qui traitent avec le gouvernement, préconise des protections avancées comme le réseau « zero-trust » et souligne la nécessité de sécuriser la chaîne d'approvisionnement logicielle.

Bien que ce décret soit spécifique au gouvernement, d'autres groupes ont également commencé à souligner l'importance de la sécurité de la chaîne d'approvisionnement pour prévenir une nouvelle attaque de type SolarWinds. Par exemple, Palo Alto a récemment publié son rapport sur les menaces cloud Unit 42 intitulé « Sécuriser la chaîne d'approvisionnement logicielle pour sécuriser le cloud ». Le rapport indique qu'aucun déploiement cloud n'est totalement sûr sans une sécurisation de la chaîne d'approvisionnement logicielle. La Cloud Native Computing Foundation partage cet avis et a publié un livre blanc détaillant les meilleures pratiques critiques en matière de chaîne d'approvisionnement logicielle à suivre à la suite de SolarWinds.

Il est indéniable que ces deux dernières années ont transformé les normes de cybersécurité. Bien que cela ne soit pas obligatoire, toutes les organisations devraient se fixer pour objectif de suivre cette voie et d'examiner les pratiques de sécurité de leurs fournisseurs comme si elles faisaient partie intégrante de leur propre programme de sécurité interne. Des initiatives comme le nouveau plan stratégique de la CISA prouvent que considérer la sécurité comme une responsabilité partagée devient une nouvelle norme pour tous les créateurs de logiciels, en particulier ceux impliqués dans les infrastructures critiques ou la chaîne d'approvisionnement logicielle.

Que peuvent faire les organisations pour améliorer leurs chaînes d'approvisionnement logicielles ?

Face à cette situation, de nombreux fournisseurs se demandent à juste titre ce qu'ils peuvent faire pour protéger leurs propres chaînes d'approvisionnement. Que peut faire une organisation pour s'assurer que ses fournisseurs accordent autant d'importance à la cybersécurité qu'elle-même ?

Le décret souligne spécifiquement l'impact des développeurs de logiciels et la nécessité pour eux de posséder des compétences en sécurité vérifiées et une réelle sensibilisation. C'est un domaine souvent oublié dans une industrie obsédée par les outils, plutôt que par une défense axée sur l'humain et des compétences clés en sécurité.

Il est devenu évident que toute approche globale de la cybersécurité doit désormais inclure une évaluation détaillée des risques liés aux tiers, couvrant les contrôles de sécurité techniques en place ainsi qu'une évaluation de la manière dont les partenaires perçoivent la gouvernance, les risques et la conformité au sein de leur propre organisation.

Toutes les évaluations de tiers doivent inclure des garanties et des plans détaillés sur la manière dont les acteurs de votre chaîne d'approvisionnement logicielle prévoient de publier des mises à jour sécurisées avec des signatures de certificats vérifiées, et sur la façon dont ils aideront à gérer les identités de tous leurs logiciels et appareils. Elles doivent également démontrer une voie claire pour les mises à niveau et les mises à jour cryptographiques de leurs produits.

Et maintenant que les développeurs sont enfin considérés comme un élément critique de la sécurité de la chaîne d'approvisionnement logicielle, toute évaluation devrait également inclure un rapport détaillant comment ils encouragent le codage sécurisé et l'amélioration continue au sein de leur communauté de développement, et idéalement, une évaluation comparative de leurs compétences et de leur formation actuelle. Nous savons que l'accent mis sur la montée en compétences des développeurs s'améliore, mais 48 % des développeurs ont admis avoir sciemment livré du code vulnérable.

Des facteurs tels que les contraintes de temps et la réalité que la sécurité n'est tout simplement pas une priorité absolue (ni une mesure de succès) dans leur monde, contribuent à un environnement où les vulnérabilités au niveau du code ne sont pas traitées aussi tôt qu'elles le devraient. Si nous voulons les empêcher d'infecter la chaîne d'approvisionnement logicielle, chaque organisation doit s'engager dans un programme de sécurité plus convivial pour les développeurs.

Prochaines étapes ?

Les évaluations des risques sont essentielles car, si vous utilisez un logiciel provenant d'un fournisseur ayant des problèmes de sécurité, vous les hériterez dans votre propre écosystème et en subirez les conséquences. Cependant, les organisations doivent également réaliser qu'il est possible que leurs fournisseurs soient en réalité plus sécurisés et peut-être même meilleurs pour soutenir leurs communautés de développeurs.

Vous pouvez utiliser une évaluation des risques par des tiers comme un moyen secondaire d'évaluer votre propre sécurité. Si un fournisseur gère mieux certains aspects de la sécurité que vous ne le faites en interne, vous pouvez adopter ses méthodes pour améliorer votre propre organisation.

Enfin, la prochaine grande étape pour réellement améliorer la chaîne d'approvisionnement logicielle consiste à mettre en œuvre des certifications de codage sécurisé pour les développeurs. Avoir un bon plan en place est une première étape, mais vérifier qu'il est réellement suivi et qu'il contribue à produire du code sécurisé est également une nécessité.

Tant que la formation des développeurs au codage sécurisé ne sera pas la norme, nous aurons toujours un temps de retard pour combler les failles avant que les cybercriminels ne les exploitent. Il n'est toutefois jamais trop tard pour agir efficacement avec le bon accompagnement. Découvrez comment vos développeurs peuvent acquérir des compétences en sécurité pertinentes et à fort impact grâce à l'apprentissage agile dès maintenant.