Les éditeurs de logiciels se soucient-ils autant que vous de la sécurité ?

Une version de cet article a été publiée dans Security Magazine. Elle a été mise à jour et publiée ici.

‍

Pour les professionnels de la sécurité, le 13 décembre a quelque chose de particulier. Est-ce le jour où nous avons enfin éradiqué l'injection SQL pour toujours ? Bien sûr que non. Peut-être s'agit-il de la "Journée internationale d'appréciation des travailleurs de la sécurité" ? Non, pas du tout. C'est le jour où FireEye et Mandiant ont publié leur rapport choquant sur une campagne d'intrusion mondiale inconnue jusqu'alors, qui allait être connue sous le nom de SolarWinds. Le rapport décrit une attaque permanente et presque incroyable dans laquelle un code malveillant est dissimulé au cœur des mises à jour du célèbre logiciel de gestion Orion de SolarWind.

Plus de 18 000 clients de SolarWinds avaient déjà téléchargé la mise à jour corrompue. Beaucoup d'entre eux l'ont fait automatiquement, comme ils l'ont fait pour des centaines d'autres mises à jour de logiciels au sein de leurs organisations et de leurs réseaux. Les attaquants ont été très sélectifs dans le choix de leurs attaques une fois qu'ils ont eu accès à la brèche de SolarWinds. De nombreuses grandes entreprises, ainsi que des agences gouvernementales, ont vu leurs données volées et leurs réseaux compromis. Il s'agit de l'une des failles les plus importantes et probablement la plus coûteuse de tous les temps, d'autant plus que dans le cas des agences gouvernementales, l'étendue des dégâts n'a jamais été rendue publique.

Tout cela s'est produit parce que les gens ont fait confiance aux fournisseurs de leur chaîne d'approvisionnement en logiciels sans vérifier ou contrôler correctement leurs activités.

Le passage massif à la sécurité de la chaîne d'approvisionnement

Une fois la sonnette d'alarme tirée, les entreprises, les organisations et les agences gouvernementales n'ont pas tardé à réagir. La faille de SolarWinds a bien sûr été stoppée, mais l'attaque a également mis en lumière les dangers d'une chaîne d'approvisionnement en logiciels non réglementée et non surveillée. Si l'incident de SolarWinds a été rapidement résolu une fois découvert, les implications concernant la manière dont la chaîne d'approvisionnement a été utilisée comme vecteur d'attaque sont toujours en cours. Si l'attaque n'a rien apporté de bon, elle a au moins permis de mettre en lumière un aspect essentiel, mais négligé, de la cybersécurité.

L'une des réponses les plus médiatisées à l'attaque de SolarWinds a été le décret du président Biden sur l'amélioration de la cybersécurité de la nation. Ce décret est l'une des directives les plus complètes jamais publiées aux États-Unis en matière de cybersécurité. Il exige une meilleure cybersécurité dans les agences et pour ceux qui travaillent avec le gouvernement, préconise des protections avancées telles que le réseau de confiance zéro et souligne la nécessité de sécuriser la chaîne d'approvisionnement des logiciels.

Bien que le 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 autre attaque du type de celle de SolarWinds. Par exemple, Palo Alto a récemment publié son Unit 42 Cloud Threat Report intitulé "Secure the Software Supply Chain to Secure the Cloud" (Sécuriser la chaîne d'approvisionnement des logiciels pour sécuriser le nuage). Ce rapport indique qu'aucun déploiement en nuage n'est totalement sûr sans la sécurité de la chaîne d'approvisionnement des logiciels. La Cloud Native Computing Foundation partage cet avis et a publié un livre blanc détaillant les meilleures pratiques de la chaîne d'approvisionnement des logiciels qui doivent être suivies à la suite de l'affaire SolarWinds.

On peut dire sans risque de se tromper que les normes de cybersécurité ont été transformées au cours des deux dernières années et, bien que cela ne soit pas obligatoire, toutes les organisations devraient avoir pour objectif de suivre le mouvement et d'examiner minutieusement les pratiques de sécurité des fournisseurs comme si elles faisaient partie de leur propre programme de sécurité interne. Des initiatives telles que le nouveau plan stratégique de la CISA prouvent une fois de plus que l'approche de la sécurité en tant que responsabilité partagée fait partie d'une nouvelle norme pour tous les créateurs de logiciels, en particulier ceux qui sont impliqués dans les infrastructures critiques ou la chaîne d'approvisionnement en logiciels.

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

De nombreux fournisseurs se demandent, à juste titre, ce qu'ils peuvent faire pour protéger leur propre chaîne d'approvisionnement. Que peut faire une organisation pour s'assurer que ses fournisseurs se soucient autant qu'elle de la cybersécurité ? 

Le décret souligne spécifiquement l'impact des développeurs de logiciels et la nécessité pour eux de disposer de compétences et d'une sensibilisation vérifiées en matière de sécurité, un domaine qui tend à être oublié dans un secteur obsédé par les outils, plutôt que de mettre l'accent sur une défense dirigée par les personnes grâce à des compétences clés en matière de sécurité.

assessment Il est devenu évident que, de nos jours, toute approche globale de la cybersécurité doit absolument inclure une analyse détaillée des risques pour les tiers assessment, couvrant les contrôles de sécurité techniques en place et une analyse de la façon dont les partenaires envisagent 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 en logiciels prévoient de publier des mises à jour de programmes sécurisées avec des signatures de certificats vérifiées, et sur la manière dont ils aideront à gérer les identités de tous leurs logiciels et appareils. Ils doivent également démontrer qu'ils disposent d'un chemin clair pour les mises à niveau cryptographiques et les mises à jour de leurs produits.

Et maintenant que les développeurs sont enfin considérés comme un élément essentiel de la sécurité de la chaîne d'approvisionnement des logiciels, tout site assessment devrait également inclure un rapport détaillant la manière dont ils encouragent le codage sécurisé et l'amélioration continue au sein de leur communauté de développeurs, et idéalement, l'évaluation comparative de leurs compétences et de leur formation actuelle. Nous savons que l'accent mis sur le perfectionnement des développeurs s'améliore, mais 48 % des développeurs ont admis avoir sciemment envoyé du code vulnérable.

Des facteurs tels que les contraintes de temps et le fait que la sécurité n'est tout simplement pas une priorité absolue (ni une mesure du 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 devraient l'être. Si nous voulons les empêcher d'infecter la chaîne d'approvisionnement en logiciels, chaque organisation doit s'engager à mettre en place un programme de sécurité plus convivial pour les développeurs. 

Prochaines étapes ?

L'évaluation des risques est essentielle car, si vous utilisez le logiciel d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et en subirez les conséquences. Toutefois, les organisations doivent également se rendre compte qu'il est possible que leurs fournisseurs soient en fait plus sûrs et qu'ils soient même plus à même de soutenir leurs communautés de développeurs. 

Vous pouvez utiliser le site assessment comme deuxième moyen d'évaluer votre propre sécurité. Si un fournisseur gère un aspect de la sécurité mieux 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 améliorer réellement la chaîne d'approvisionnement en logiciels consiste à mettre en place des certifications de codage sécurisé pour les développeurs. La mise en place d'un bon plan est la première étape, mais il est également nécessaire de vérifier qu'il est réellement suivi et qu'il contribue à produire un code sécurisé. 

Tant que nous n'aurons pas atteint un point où l'habilitation des développeurs à coder de manière sécurisée sera la norme, nous serons toujours en retard pour fermer les fenêtres d'opportunité avant que les acteurs de la menace ne puissent s'infiltrer. Cependant, il n'est jamais trop tard pour avoir un impact positif avec le soutien adéquat. Découvrez dès maintenant comment vos développeurs peuvent perfectionner des compétences pertinentes et à fort impact en matière de sécurité grâce à la puissance de l'apprentissage agile.