Protéger la supply chain : qu’avons-nous appris depuis l’incident de SolarWinds en 2020 ?

Quels sont les enjeux en termes de sécurité posés par la supply chain ?

Alors que la supply chain des logiciels devient de plus en plus sophistiquée, nous constatons une adoption généralisée de l’automatisation du développement des logiciels, mais aussi d’outils et de référentiels basés sur le cloud pour aider à rationaliser les opérations. Toutefois, ces nouvelles solutions élargissent considérablement la surface d’attaque exploitable par les cybercriminels, en particulier du point de vue de l’identité. La digitalisation croissante dans les environnements décentralisés entraine plus d’identités humaines et non-humaines habilitées, susceptibles d’être exploitées par des hackers. En complément, le codage avec des composants open-source, et les tests automatisés pour les déploiements basés sur le cloud, créent plus de vulnérabilités pour la supply chain des logiciels, dont les cybercriminels peuvent tirer parti.

Comment les incidents liés à la sécurité de la supply chain se produisent-ils ? Et pourquoi ?

Ces attaques sont loin d’être nouvelles. En effet, les cybercriminels ciblent depuis longtemps des fournisseurs tiers dans les supply chains numériques et physiques, qu’il s’agisse de prestataires de logiciels et de technologies, d’avocats et de consultants, ou d’entreprises manufacturières et logistiques. Un exemple notable de ce type d’incident est le piratage de SolarWinds en 2020, sans précédent à bien des égards, et il y en a malheureusement eu de nombreux autres depuis. En fin de compte, les parties tierces comprises dans la chaîne d’approvisionnement constituent une entrée potentielle vers les réseaux des partenaires commerciaux. En testant leurs défenses, un cybercriminel peut y trouver une voie d’accès.

Cela dit, les attaques contre la supply chain des logiciels sont devenues plus fréquentes avec l’avènement des pipelines CI/CD ; en d’autres termes, chaque fois qu’un individu peut lire et contribuer au code, il y a un risque de porte dérobée. En effet, il est désormais courant que les hackers compromettent certains certificats afin d’y modifier le code source et de contourner les dispositifs de contrôle. Ainsi, dès 2016, celui du client BitTorrent Transmission a été dissimulé sur GitHub. Et en 2017, l’application de nettoyage populaire CCleaner a été tristement célèbre du fait d’un certificat de signature de code compromis ; ces deux cas étant des signes révélateurs que les chaînes d’approvisionnement en logiciels sont devenues un terrain de jeu pour les cybercriminels.

Quels sont les enseignements tirés suite aux multiples incidents sur la supply chain, en particulier celui visant SolarWinds ?

Il est facile pour les entreprises de penser qu’elles perdent du terrain face aux attaquants, étant donné que le nombre de brèches visibles ne cesse d’augmenter. Mais en réalité, c’est dès maintenant qu’elles devraient prendre les mesures de sécurité nécessaires pour protéger leurs institutions. Même si elles ne peuvent pas altérer le passé, elles ont un impact sur l’avenir, donnant lieu à deux perspectives distinctes.

Tout d’abord, il est de plus en plus reconnu que la responsabilité de protéger la supply chain n’incombe plus uniquement le vendeur, le fournisseur ou le client. Il s’agit désormais d’une charge partagée qui ne relève plus seulement des processus de certification standard des prestataires, comme c’était le cas avant 2019 lorsque l’attaque contre SolarWinds a commencé.

On comprend également que la posture de sécurité des développeurs doit être renforcée, en particulier dans trois domaines : la gestion des identités et des accès, la protection de leur environnement de travail et celles des pratiques de codage, qui doivent être plus strictes.

Quelles ont été les mesures déployées pour améliorer la sécurité en conséquence ?

Bon nombre d’organisations ont cherché à suivre plus étroitement aux conseils émanant d’agences, telles que l’Agence de cybersécurité de l’Union européenne (ENISA), qui ont été rapidement actualisés suite à d’autres incidents très médiatisés. Dans certains cas, ces nouvelles recommandations ont également été étendues aux fournisseurs cherchant à renforcer leurs pratiques existantes, grâce à des cadres tels que le Supply-chain Levels for Software Artifacts (SLSA) et le Cloud Native Computing Foundation (CNCF).

Nous constatons également un niveau de contrôle plus approfondi autour des fonctions du développeur, où les améliorations se répartissent en plusieurs domaines. Cela inclut désormais des vérifications courantes, telles que l’authentification multifactorielle (MFA) adaptative, qui sont plus sensibles aux exigences opérationnelles des équipes de développement, n’ont pas d’impact sur les workloads et n’entraînent pas de fatigue. Aussi, les organisations procèdent à un examen plus complet des pratiques en matière de codage et de pipeline, et augmentent les évaluations mutuelles du code.

En ce qui concerne la programmation, l’accent est désormais mis sur certains procédés telles que l’analyse des vulnérabilités des codes en open-source, ou l’évaluation et la suppression des secrets codés en dur, car les équipes de sécurité cherchent à intégrer des contrôles proactifs pour tester la validité et le niveau de sécurité des produits qui circulent dans le pipeline.

Que reste-t-il à faire pour s’assurer de la sécurité de la supply chain ?

Si SolarWinds nous a appris quelque chose, c’est que les équipes de sécurité doivent à tout prix identifier et éliminer les vulnérabilités dans tous les environnements de développement qui expose l’ensemble de l’organisation. Cette protection nécessite également une approche collaborative, car les développeurs peuvent ne pas reconnaître toutes les failles potentielles susceptibles d’avoir un impact sur l’entreprise et, de la même manière, les équipes informatiques et de sécurité peuvent être moins familiarisées avec les outils et les processus dédiés.

Il est donc indispensable d’impliquer la sûreté, avec anticipation, dès le début du cycle de développement. Il faut en effet intégrer proactivement les équipes de sécurité, ainsi que les développeurs, au stade de planification, plutôt que d’attendre juste avant que le code ne soit mis en ligne.

Quelles mesures complémentaires les organisations peuvent-elles prendre pour sécuriser la supply chain et mieux appréhender les cybermenaces ?

Chaque entreprise est différente, mais pour protéger la supply chain, elles respectent généralement les mêmes bonnes pratiques en matière de cybersécurité. Lorsqu’il s’agit de travailler avec des vendeurs et des fournisseurs tiers par exemple, il faut évaluer à la fois les prestataires directs et indirects, ainsi que les systèmes connectés non traditionnels et les appareils IoT, car ils disposent tous de logiciels susceptibles d’introduire un risque de cybersécurité.

Il est également primordial de traiter tout nouveau fournisseur avec prudence, tout en le hiérarchisant en fonction du risque, et en le classant selon la priorité de la mission ou l’impact sur l’organisation. À partir de là, les organisations doivent identifier et définir les principaux domaines de menace, fournir aux parties tierces des plans d’action catégorisés par risque et basés sur toutes les informations compilées, et faire en sorte que le respect de ces stratégies soit obligatoire.

Comment la menace va-t-elle évoluer ?

Les cybercriminels qui ciblent les supply chains ont beaucoup en commun avec les développeurs qui ajoutent une « intelligence humaine » à ces mêmes environnements : ils sont toujours en train d’apprendre, de s’adapter et d’exploiter les technologies et les compétences les plus récentes pour atteindre leurs objectifs.

Il est donc probable que nous verrons les hackers redoubler d’efforts pour déjouer les contrôles en matière de sécurité et d’authentification, et qu’ils utiliseront des méthodes automatisées, pour cibler les bibliothèques open-source, les dépôts de code publics et les utilisateurs humains, qui conservent un accès puissant à l’administration des pipelines/supply chains.