Les risques de la chaîne d'approvisionnement vous dépriment ? Restez calme et soyez stratégique !

L'industrie de la sécurité perd collectivement la tête lorsque de nouvelles vulnérabilités sont découvertes dans les logiciels. OpenSSL ne fait pas exception, et deux nouvelles vulnérabilités ont submergé les flux d'actualités fin octobre et début novembre 2022. La découverte et la divulgation ne sont que le début de ce cycle de vulnérabilité sans fin. Les organisations concernées sont confrontées à des mesures correctives, ce qui est particulièrement douloureux pour ceux qui sont en première ligne du service informatique. Les responsables de la sécurité doivent maintenir une stratégie de cybersécurité efficace pour aider à filtrer une partie du bruit sur les nouvelles vulnérabilités, reconnaître les impacts sur les chaînes d'approvisionnement et sécuriser leurs actifs en conséquence.

Les attaques de la chaîne d'approvisionnement ne vont pas disparaître

En environ un an, nous avons subi de graves vulnérabilités dans les composants, notamment log4j, Cadre de printempset OpenSSL. L'exploitation des vulnérabilités plus anciennes ne cesse également jamais des implémentations mal configurées ou qui utilisent des dépendances vulnérables connues. En novembre 2022, le public a pris connaissance d'un campagne d'attaque contre le pouvoir exécutif civil fédéral (FCEB), attribuable à une menace iranienne parrainée par l'État. Cette entité fédérale américaine exécutait une infrastructure VMware Horizon qui contenait la vulnérabilité Log4Shell, qui servait de vecteur d'attaque initial. FCEB a été touché par une chaîne d'attaque complexe qui comprenait un mouvement latéral, une compromission des informations d'identification, une compromission du système, une persistance du réseau, un contournement de la protection des terminaux et un cryptojacking.

Les organisations peuvent demander "pourquoi consommer OSS du tout?" après des incidents de sécurité provenant de packages vulnérables comme OpenSSL ou Log4j. Les attaques de la chaîne d'approvisionnement continuent d'augmenter, car la réutilisation des composants est « bonne affaire » pour les partenaires et les fournisseurs. Nous concevons des systèmes en réaffectant le code existant plutôt qu'en construisant à partir de zéro. Il s'agit de réduire les efforts d'ingénierie, d'évoluer sur le plan opérationnel et de livrer rapidement. Les logiciels open source (OSS) sont généralement considérés comme dignes de confiance en raison de l'examen public dont ils font l'objet. Cependant, les logiciels sont en constante évolution et des problèmes surviennent à cause d'erreurs de codage ou de dépendances liées. De nouveaux problèmes sont également découverts grâce à l'évolution des techniques de test et d'exploitation.

S'attaquer aux vulnérabilités de la chaîne d'approvisionnement

Les organisations ont besoin d'outils et de processus appropriés pour sécuriser les conceptions modernes. Les approches traditionnelles telles que la gestion des vulnérabilités ou les évaluations ponctuelles ne suffisent pas à elles seules. Les réglementations peuvent encore autoriser ces approches, ce qui perpétue le fossé entre « sécurisé » et « conforme ». La plupart des organisations aspirent à atteindre un certain niveau de maturité DevOps. « Continu » et « automatisé » sont des traits communs des pratiques DevOps. Les processus de sécurité ne doivent pas différer. Les responsables de la sécurité doivent rester concentrés tout au long des phases de construction, de livraison et d'exécution dans le cadre de leur stratégie de sécurité :

• Scanner en continu en CI/CD : Visez à sécuriser les pipelines de construction (c'est-à-dire, shift-left) mais reconnaissez que vous ne pourrez pas analyser tout le code et le code imbriqué. Le succès des approches de décalage vers la gauche est limité par l'efficacité du scanner, la corrélation de la sortie du scanner, l'automatisation des décisions de publication et l'achèvement du scanner dans les fenêtres de publication. L'outillage devrait aider à hiérarchiser les risques de découvertes. Tous les résultats ne sont pas exploitables et les vulnérabilités peuvent ne pas être exploitables dans votre architecture.

• Scanner en continu pendant la livraison : La compromission des composants et la dérive de l'environnement se produisent. Les applications, l'infrastructure et les charges de travail doivent être analysées lors de leur livraison au cas où quelque chose serait compromis dans la chaîne d'approvisionnement numérique lorsqu'elles proviennent de registres ou de référentiels et qu'elles sont amorcées.

• Scanner en continu pendant l'exécution : La sécurité d'exécution est le point de départ de nombreux programmes de sécurité, et la surveillance de la sécurité sous-tend la plupart des efforts de cybersécurité. Cependant, vous avez besoin de mécanismes capables de collecter et de corréler la télémétrie dans tous les types d'environnements, y compris les environnements cloud, de conteneurs et Kubernetes. Les informations recueillies lors de l'exécution doivent être répercutées sur les étapes de construction et de livraison précédentes. Interactions identité et service

• Hiérarchisez les vulnérabilités exposées lors de l'exécution : Toutes les organisations ont du mal à disposer de suffisamment de temps et de ressources pour tout analyser et tout réparer. La hiérarchisation basée sur les risques est fondamentale pour le travail du programme de sécurité. L'exposition à Internet n'est qu'un facteur parmi d'autres. Un autre est la gravité de la vulnérabilité, et les organisations se concentrent souvent sur les problèmes de gravité élevée et critique, car ils sont réputés avoir le plus d'impact. Cette approche peut encore gaspiller des cycles d'équipes d'ingénierie et de sécurité, car elles peuvent rechercher des vulnérabilités qui ne sont jamais chargées au moment de l'exécution et qui ne sont pas exploitables. Utilisez l'intelligence d'exécution pour vérifier quels packages sont réellement chargés dans les applications et l'infrastructure en cours d'exécution afin de connaître le risque de sécurité réel pour votre organisation.

Nous avons créé conseils spécifiques au produit pour guider les clients à travers la récente folie OpenSSL.

La dernière vulnérabilité OpenSSL et Log4Shell nous rappellent la nécessité d'une préparation à la cybersécurité et d'une stratégie de sécurité efficace. Nous devons nous rappeler que les identifiants CVE ne sont que les problèmes connus des logiciels ou du matériel publics. De nombreuses vulnérabilités ne sont pas signalées, en particulier les faiblesses du code local ou les mauvaises configurations environnementales. Votre stratégie de cybersécurité doit tenir compte de la technologie distribuée et diversifiée des conceptions modernes. Vous avez besoin d'un programme de gestion des vulnérabilités modernisé qui utilise des informations d'exécution pour hiérarchiser les travaux de correction pour les équipes d'ingénierie. Vous avez également besoin de capacités de détection des menaces et de réponse qui corrèlent les signaux entre les environnements pour éviter les surprises.

À propos de l’auteur

Michael Isbitski, directeur de la stratégie de cybersécurité chez Sysdig, a effectué des recherches et des conseils sur la cybersécurité pendant plus de cinq ans. Il connaît la sécurité du cloud, la sécurité des conteneurs, la sécurité Kubernetes, la sécurité des API, les tests de sécurité, la sécurité mobile, la protection des applications et la livraison continue sécurisée. Il a guidé d'innombrables organisations dans le monde entier dans leurs initiatives de sécurité et dans le soutien de leurs activités.

Avant son expérience de recherche et de conseil, Mike a appris de nombreuses leçons difficiles sur les lignes de front de l'informatique avec plus de 20 ans d'expérience de praticien et de leadership axés sur la sécurité des applications, la gestion des vulnérabilités, l'architecture d'entreprise et l'ingénierie des systèmes.