La récente violation de GitHub Inc., qui a permis aux attaquants d'accéder à environ 4 000 référentiels de code internes de la plateforme, illustre les menaces croissantes émanant d'acteurs malveillants qui enfouissent les logiciels malveillants dans des bibliothèques de logiciels open source.
Les chaînes d’approvisionnement sont des cibles convoitées pour les cyberattaques, et les menaces ont été récemment amplifiées par la rapidité avec laquelle elles peuvent être introduites. Les auteurs de ces actes sont traditionnellement gênés par la nécessité de se concentrer sur une poignée de cibles à la fois. Ils exploitent désormais l’IA pour atteindre un large éventail de cibles dans de nombreuses organisations, individus et appareils à la fois.
L’IA a contribué à la croissance de ces attaques en permettant le « codage dynamique », permettant aux utilisateurs techniquement compétents de télécharger et d’installer des packages à partir du cloud. Les gens ont tendance à faire implicitement confiance aux packages qui existent depuis un certain temps. Mais sans une surveillance suffisante, ils peuvent perdre la capacité de détecter les compromissions, ce qui donne aux attaquants plus de temps pour frapper.
Ces défis ne sont pas insurmontables. Les dirigeants peuvent faire face à ces nouvelles menaces en se concentrant sur quatre principes :
Restreindre les téléchargements. Autoriser les téléchargements sans entrave de tous les packages souhaités par les utilisateurs limite la responsabilité en cas de problème. Les organisations doivent examiner les packages de deux manières. Premièrement, ils doivent créer et appliquer des politiques strictes autour desquelles les packages open source sont autorisés et garantir que tous les logiciels installés sont soumis à des examens internes. Deuxièmement, ils ont besoin de contrôles techniques pour détecter le code malveillant au moment de l’installation, moment où la plupart des activités malveillantes sont initiées. Cela peut être plus difficile qu’il n’y paraît. Souvent, le code malveillant n'est pas signalé car rien sur le comportement du package n'est apparent au moment de l'installation.
Les responsables de la sécurité doivent s’assurer que les éléments politiques et techniques sont en place. Des politiques strictes sans contrôles techniques tout aussi stricts empêchent les organisations de mener une analyse comportementale au moment de l'installation. Des contrôles techniques stricts associés à des politiques faibles peuvent entraîner une telle surcharge de packages dans les organisations qu'il devient presque impossible de déterminer ce qui est réellement malveillant.
Implémentez le verrouillage des fichiers et l’épinglage de version. Lors de l’introduction de nouveaux packages dans l’organisation, les responsables de la sécurité doivent s’assurer qu’ils sont épinglés sur une version spécifique. Cela permet d’éviter le scénario courant dans lequel une nouvelle version d’un code approuvé existant est introduite inaperçue dans l’entreprise. Le verrouillage des fichiers et l'épinglage de version garantissent que l'organisation utilise la version approuvée de tout progiciel. Il offre également l’avantage supplémentaire d’acheter des jours ou des semaines supplémentaires pour évaluer les dommages potentiels posés par la dernière version d’un package particulier.
Comprendre les outils de développement autorisés au sein de l'organisation. Les organisations accordent souvent trop de liberté aux développeurs pour contourner la gouvernance et la surveillance. Ils font preuve de diligence en matière de protection des ordinateurs de l'utilisateur moyen, mais sont plus souples en ce qui concerne les postes de travail des développeurs.
Exiger davantage de structure autour des outils de développement se traduit par une sécurité améliorée, mais avec certains compromis en termes de vitesse. Une solution consiste à désigner un ensemble d’extensions approuvées dont l’utilisation a été vérifiée par les développeurs. Les développeurs qui souhaitent utiliser de nouvelles extensions peuvent les soumettre à un processus d'examen de sécurité.
La confiance doit être gagnée. Historiquement, les attaques contre les bibliothèques open source s'appuyaient sur l'ingénierie sociale pour convaincre les utilisateurs de télécharger un package malveillant. Désormais, les attaquants utilisent un ensemble initial d’informations d’identification compromises pour transmettre des packages aux utilisateurs. Au lieu de menaces provenant de packages non fiables, elles proviennent de sources apparemment fiables et vérifiées.
Même l'application de la signature de code dans toute l'organisation ne garantit pas que celui qui soumet du code est bien celui qu'il prétend être. Les clés de signature de code peuvent également être volées, la signature et la compromission se produisant dans le pipeline de build lui-même. Les dirigeants doivent être plus diligents que jamais pour garantir la sécurité du code.
La cybersécurité a longtemps été caractérisée par un cycle dans lequel les améliorations des outils défensifs incitent les attaquants à se tourner vers de nouveaux vecteurs de menace. La différence aujourd’hui est que la sophistication des attaques augmente considérablement. Ce n’est pas le moment pour les responsables de la sécurité de l’information de baisser la garde.
Casey Erikson est directeur des tests d'intrusion chez NR Labs LLC. Il a écrit cet article pour SiliconANGLE.
