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

Une version de cet article a été publiée dans Magazine de sécurité. Il a été mis à jour et diffusé ici.

‍

Pour les professionnels de la sécurité, le 13 décembre a quelque chose de spécial. Est-ce le jour où nous aurons enfin éradiqué l'injection SQL, pour toujours ? Bien sûr que non. C'est peut-être la « Journée internationale de reconnaissance des agents de sécurité » ? Non non plus. C'est le jour où FireEye et Mandiant ont publié leur rapport choquant sur un inconnu campagne d'intrusion mondiale qui deviendrait connu sous le nom de SolarWinds. Le rapport détaille une attaque en cours et presque incroyable au cours de laquelle un code malveillant a été dissimulé au plus profond des mises à jour logicielles 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. Nombre d'entre eux l'ont fait automatiquement, comme ils l'ont fait pour des centaines d'autres mises à jour logicielles au sein de leur organisation et de leurs réseaux. Les attaquants ont choisi d'attaquer de manière très sélective une fois autorisés à y accéder 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. C'était l'un des plus grands et probablement des violation la plus coûteuse de tous les temps, d'autant plus que, dans le cas des agences gouvernementales, l'ampleur des dégâts n'a jamais été rendue publique.

Et tout cela s'est produit parce que les utilisateurs faisaient confiance aux fournisseurs de leur chaîne d'approvisionnement logicielle sans vérifier ou valider correctement leurs activités.

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

Une fois l'alarme déclenchée, les entreprises, les organisations et les agences gouvernementales n'ont pas tardé à réagir. La faille SolarWinds a bien sûr été stoppée, mais l'attaque a également révélé 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 la manière dont la chaîne d'approvisionnement a été utilisée comme vecteur d'attaque se font toujours sentir. Si cette attaque n'a rien donné de positif, elle a au moins 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 de SolarWinds a été celle du président Biden Décret exécutif sur l'amélioration de la cybersécurité du pays. Cette ordonnance est l'une des directives de cybersécurité les plus complètes jamais publiées aux États-Unis. Elle exige une meilleure cybersécurité des agences et de ceux qui font affaire avec le gouvernement, préconise des protections avancées telles que les réseaux Zero Trust et souligne la nécessité de sécuriser la chaîne d'approvisionnement logicielle.

Bien que l'EO 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 empêcher une autre attaque de type Solarwinds. Par exemple, Palo Alto a récemment publié son Rapport sur les menaces liées au cloud de l'unité 42 intitulé « Sécurisez la chaîne d'approvisionnement logicielle pour sécuriser le cloud ». Le rapport indique qu'aucun déploiement dans le cloud n'est totalement sûr sans la sécurité de la chaîne d'approvisionnement logicielle. Et la Cloud Native Computing Foundation est d'accord en publiant un livre blanc détaillant les meilleures pratiques critiques de la chaîne d'approvisionnement logicielle qui doivent être suivies à la suite de SolarWinds.

On peut dire que les deux dernières années ont été marquées par une transformation des normes de cybersécurité. Bien que cela ne soit pas obligatoire, toutes les organisations devraient avoir pour objectif de suivre cet exemple et d'examiner les pratiques de sécurité des fournisseurs comme si elles faisaient partie de leur propre programme de sécurité interne. Des initiatives comme la nouvelle de la CISA Plan stratégique apporte une preuve supplémentaire que l'approche de la sécurité comme une responsabilité partagée fait partie intégrante d'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 ?

La situation amène de nombreux fournisseurs à se demander à 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 se soucient autant qu'eux de la cybersécurité ?

L'EO décrit spécifiquement l'impact des développeurs de logiciels et la nécessité pour eux de compétences de sécurité vérifiées et la sensibilisation, domaine qui tend à être oublié dans un secteur obsédé par les outils, au lieu de se concentrer sur une défense dirigée par les personnes grâce à des compétences clés en matière de sécurité.

De nos jours, il est devenu évident que toute approche globale de la cybersécurité doit absolument inclure une évaluation détaillée des risques par des tiers, couvrant les contrôles de sécurité techniques en place et une évaluation de la façon dont les partenaires perçoivent la gouvernance, les risques et la conformité au sein de leurs propres organisations.

Toutes les évaluations par des 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 manière dont ils aideront à gérer l'identité de tous leurs logiciels et appareils. Il doit également indiquer une voie claire pour les mises à niveau cryptographiques et les mises à jour de leurs produits.

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 logicielle, toute évaluation 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éveloppement, et idéalement, une analyse comparative de leurs compétences et de leur formation actuelle. Nous savons que l'accent mis sur le renforcement des compétences des développeurs est en train de s'améliorer, 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 de succès) dans leur monde contribuent à créer un environnement dans lequel 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 l'organisation doit s'engager à mettre en place un programme de sécurité plus convivial pour les développeurs.

Prochaines étapes ?

Les évaluations des risques sont essentielles car, si vous utilisez le logiciel d'un fournisseur présentant des problèmes de sécurité, vous en hériterez dans votre écosystème et vous en subirez les conséquences. Cependant, les entreprises doivent également se rendre compte qu'il est possible que leurs fournisseurs soient réellement plus sûrs et puissent même mieux soutenir leurs communautés de développeurs.

Vous pouvez utiliser une évaluation des risques par un tiers comme moyen secondaire d'évaluer votre propre sécurité. Si un fournisseur gère certains aspects 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 étape importante pour réellement améliorer la chaîne d'approvisionnement logicielle consiste à mettre en œuvre des certifications de codage sécurisées 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 de contribuer à la production d'un code sécurisé.

Jusqu'à ce que l'implication des développeurs dans le codage sécurisé devienne la norme, nous serons toujours en retard lorsqu'il s'agit de fermer les opportunités avant que les acteurs de la menace ne puissent s'y intéresser. Cependant, il n'est jamais trop tard pour avoir un impact positif avec le soutien approprié. Découvrez comment vos développeurs peuvent perfectionner des compétences de sécurité pertinentes et à fort impact grâce à la puissance de l'apprentissage agile maintenant.