Risques et contrôles de la chaîne logistique logicielle - 2025

1. Introduction: Bonjour. Bonjour, tout le monde. Bienvenue dans mon nouveau cours, qui porte sur la sécurité de la chaîne d'approvisionnement et la master class. m'appelle Pamurg Law et je vais être professeur pendant toute la durée de ce cours, qui porte, bien entendu , sur la sécurité de la chaîne d'approvisionnement logicielle Maintenant, le but de ce cours est très, très simple. Je souhaite vous expliquer les principes fondamentaux de la sécurité de la chaîne d'approvisionnement logicielle, les approfondir au niveau avancé, et vous obtiendrez une compréhension très complète de la chaîne d'approvisionnement logicielle. Quels sont ses composants, quelles sont les parties prenantes et les différents types de risques et de problèmes de sécurité susceptibles compromettre l'intégrité et la sécurité de vos logiciels. Vous allez donc comprendre tous les risques qui existent, et je vais vous donner les connaissances dont vous avez besoin pour mettre en œuvre un programme de sécurité de la chaîne d'approvisionnement approprié. Et très, très important. J'ai parlé d'un programme de sécurité. Je ne voulais pas dire que je n'ai pas parlé de produit de sécurité car c'est malheureusement souvent une source de confusion pour les gens. Ils pensent que la sécurité de la chaîne d'approvisionnement logicielle consiste à implémenter un logiciel ou à obtenir une certification, ce qui est loin d'être le cas. sécurité de la chaîne d'approvisionnement logicielle La sécurité de la chaîne d'approvisionnement logicielle est, comme on peut le dire, un créneau complet dans le domaine de la cybersécurité, dont vous devez comprendre différents risques et comment les atténuer. Nous allons examiner quelques études de cas également menées dans le secteur, comment elles se sont produites et comment vous pouvez utiliser leur compréhension pour vous protéger davantage contre vous protéger les mêmes problèmes que ceux qui existent déjà. Maintenant, qui suis-je ? Je m'appelle Kamchal et je suis un leader professionnel de la cybersécurité plusieurs fois primé leader professionnel de la cybersécurité plusieurs fois primé J'ai écrit : « D'accord, je vais me qualifier de leader Je travaille dans un secteur de la cybersécurité depuis plus de 21 ans . J'ai été conférencier, instructeur. Je suis également coach de carrière. J'aide les gens à se lancer dans la cybersécurité. J'ai une chaîne YouTube intitulée Cloud Security guy sur laquelle je parle de sécurité du cloud et d'IA. Je suis également un auteur à succès et un créateur de cours, comme je l'ai mentionné Donc, juste pour vous donner l'assurance que je sais un peu de quoi je parle, voici quelques-uns de mes livres qui sont écrits sur la gouvernance de l'IA et la cybersécurité. J'ai de nombreux cours sur cette plateforme. Sur ce sujet. J' ai également écrit des livres sur Zero Trust et Comtea, certifications en cybersécurité, ainsi que sur de nombreux autres sujets J'y suis sur Substack. J'y ai une newsletter gratuite. Je suis également présent sur LinkedIn. cloud, comme ma chaîne YouTube Le cloud, comme ma chaîne YouTube, s' appelle Cloud Security guy, et je suis là sur Twitter, alors n'hésitez pas à me contacter sur ce site. Je suis toujours heureuse d'avoir des nouvelles des personnes qui ont suivi mes cours. Maintenant, faisons un pas en avant, en arrière, désolé. Parlons de la chaîne d'approvisionnement lorsque nous parlons de la chaîne d'approvisionnement. Vous ne le savez peut-être pas, mais la chaîne d'approvisionnement est essentielle à nos vies. Et qu'est-ce qu'une chaîne d'approvisionnement ? Il s'agit d'un réseau d' individus et d'entreprises qui participent à la création d'un produit et à sa livraison au client, n'est-ce pas ? Et lorsque vous achetez quelque chose, vous savez, par exemple sur Internet ou sur un produit, et la plupart des gens ne le savent pas. En général, le trajet entre l'idée originale et le moment de la livraison est très long . Et il y a beaucoup de personnes impliquées, de l' entrepôt à l'entreprise, du transport jusqu' à ce que vous l'obteniez, n'est-ce pas ? Et nombreux sont ceux que vous appelez «   parties prenantes » qui y sont impliqués. Et ce que vous ne réalisez pas, c'est qu' il existe de très nombreuses opportunités, notamment que quelque chose se produise au fur et à mesure que le produit suit cette voie, les marchandises qui se déplacent, n'est-ce pas ? Ce sont tous des problèmes. Les problèmes de sécurité sont présents à n'importe quel point de la chaîne d'approvisionnement. Et la plupart des gens ne le savent pas, mais la sécurité de la chaîne d'approvisionnement fait partie de notre existence. Pendant des milliers et des milliers d'années, par exemple lorsque les épices étaient transportées d'est en ouest ou lorsque les navires transportaient des marchandises entre les continents, n'est-ce pas ? Ou lorsque les troupes militaires transportent de la nourriture et des armes pendant les guerres, toutes les situations, les gens sont préparés aux attaques et défendent leurs approvisionnements. Ainsi, l'article pourrait atteindre la destination prévue. Et il en va de même pour les logiciels. Alors imaginez construire une voiture. Hein ? Vous ne fabriqueriez pas les pièces à partir de zéro, n'est-ce pas ? Au lieu de cela, vous vous procureriez les différents composants, les pneus, le moteur, les composants électroniques auprès de différents fournisseurs dans une usine, puis vous les assembleriez. Et c'est pareil. Le même principe s'applique également aux logiciels. Et c'est là qu'intervient la chaîne d'approvisionnement logicielle. Il fait référence à la séquence des processus impliqués dans le développement, le déploiement et maintenance des applications logicielles, essentiellement tout ce qui est nécessaire pour créer un logiciel, du déploiement du code source à la production, n'est-ce pas ? Dans les environnements actuels, il est très rare que les entreprises créent des logiciels entièrement à partir de zéro. Au lieu de cela, ils s' appuient sur une gamme de composants de base, tels que les bibliothèques open source, les outils de développement, les déploiements basés sur le cloud, vous savez Et chacun de ces composants fait partie d' une longue chaîne d'approvisionnement depuis infrastructure informatique jusqu'au code source, n'est-ce pas ? Et la chaîne d'approvisionnement logicielle fait référence à la séquence des processus impliqués dans l'obtention de ce logiciel. Il peut donc s'agir du code source, des bibliothèques tierces impliquées, des systèmes de construction et d'empaquetage, des canaux de distribution , des infrastructures de déploiement , tout cela provient d'ici. Voici donc à quoi cela ressemble aux différents niveaux, n'est-ce pas ? Par exemple, les développeurs s'appuieront sur de nombreux composants externes lorsqu'ils développeront des logiciels lorsqu'ils rédigeront nombreux composants externes lorsqu'ils développeront le logiciel. Il peut s'agir d'une bibliothèque open source, d'une tierce partie, d'une API ou d'un service cloud. Ils l'utilisent dans leur environnement, puis l'envoient à un système de bits, qui crée comme un artefact logiciel et est envoyé dans un référentiel, puis il est déployé Ne vous inquiétez pas si vous ne connaissez pas ces termes. Nous allons approfondir chacun de ces aspects, les logiciels J'essaie simplement de vous faire comprendre que les logiciels sont généralement développés par plusieurs personnes qui peuvent faire partie de plusieurs organisations différentes. Et au fil du temps, des milliers de personnes peuvent avoir contribué à un logiciel en particulier. Vous devez donc vous assurer de bien comprendre. D'où peuvent intervenir les problèmes de sécurité, n'est-ce pas ? Et c'est là qu'intervient la sécurité de la chaîne d' approvisionnement logicielle . s'agit de garantir l' intégrité, la sécurité et la fiabilité des composants et des processus impliqués dans le développement, distribution et la maintenance des logiciels. Vous devez vous assurer que votre logiciel n'est pas altéré compromis à aucun moment de son cycle de vie Et la chaîne d'approvisionnement, ce n' est pas seulement le code, mais aussi les bibliothèques, outils et services tiers. Cela dépend de l' infrastructure. La sécurité de la chaîne d'approvisionnement logicielle englobe donc tout. sécurité de la chaîne d'approvisionnement logicielle La sécurité de la chaîne d'approvisionnement logicielle n'est pas une certification que l'on obtient. Ce n'est pas un produit que vous achetez. Il englobe tous ces processus. OK ? Et pourquoi est-ce si important ? Eh bien, tout simplement, cela peut être un énorme angle mort. Hein ? La plupart des entreprises se concentrent sur la sécurisation de leurs propres environnements, leur propre code, proposent des formations et s'assurent que tout est sécurisé Et ils ont complètement oublié les bibliothèques tierces, les composants tiers qui s'y trouvent. Et les attaquants ne sont pas stupides. Ils en sont également conscients. Pourquoi voudraient-ils attaquer de front alors qu'ils savent que l' entreprise se protège elle-même, alors qu'ils peuvent simplement se faufiler biais d'un composant tiers, d'une bibliothèque tierce autre sorte de porte dérobée dont l' entreprise n'est pas consciente Et malheureusement, comme moi, il y a un manque de sensibilisation et de contrôle à ce sujet. La plupart des entreprises pensent qu'elles achèteront un produit et que leur chaîne d'approvisionnement est sécurisée, ou qu'elles établiront une liste de contrôle, vérifieront leur fournisseur, et maintenant nous sommes sécurisés ou elles factureront le MFA Toutes ces choses sont importantes. D'ailleurs, je ne dis pas que ces choses ne sont pas importantes, mais la sécurité de la chaîne d'approvisionnement logicielle est bien plus que cela. Et il y a un manque général de sensibilisation, c'est pourquoi j'ai créé ce cours ici. Et pourquoi devriez-vous vous en soucier ? Je veux dire, je ne saurais trop insister sur ce point alors qu'il y a quelques années, gains solaires étaient compromis, n'est-ce pas ? Il a permis de sensibiliser le public à la sécurité de la chaîne d'approvisionnement logicielle. Et je vais parler en détail victoires solaires, mais en résumé, ont commencé en octobre 2019 et n'ont pas été détectées jusqu'en décembre 2020. Et à ce moment-là, 18 000 clients étaient en danger, d'accord ? Microsoft a confirmé que tant d' entreprises avaient été rémunérées, y compris les gouvernements américains, n'est-ce pas ? Et Solar gagne, ils ont dû se contenter, je crois, d'un procès de 26 000 000$ avec ses investisseurs en raison toutes les pertes financières qui Et cela n'incluait pas les millions dépensés par Solar Winds et ses clients, ni la réponse aux incidents, enquêtes sur les menaces, temps d'arrêt, les mesures correctives, les pertes de revenus Vous pouvez donc comprendre à quel point cette attaque était puissante et, de même, Log for J, si vous savez, si vous avez travaillé dans le domaine de la cybersécurité en décembre 2021, je suis sûr que vous savez combien de vacances de personnes ont je suis sûr que vous savez combien de vacances de personnes compromises à cause de ce célèbre labrary, il a été compromis, il était présent dans des millions et des millions d'environnements, et tous ont dû prendre des risques pour s'assurer qu'ils n' étaient pas vulnérables. La sécurité de la chaîne d'approvisionnement logicielle n'est donc pas une blague. Cela peut entraîner des cyberattaques dévastatrices si vous ne le sécurisez pas correctement. Alors, à qui s'adresse ce cours ? Ce cours s'adresse, bien entendu, aux professionnels de la cybersécurité qui souhaitent bien comprendre J'ai utilisé toutes mes connaissances en matière sécurité de la chaîne d'approvisionnement logicielle pour les intégrer dans ce cours. Il s'adresse également aux développeurs qui souhaitent comprendre le contexte plus large du code, sa sécurité. Ces professionnels, si vous souhaitez affiner vos connaissances en matière de risques et inclure également les risques de la chaîne d'approvisionnement de Suffa Et bien entendu, les responsables de la sécurité tels que les directeurs informatiques, directeurs techniques, les directeurs de la sécurité de l'information , ainsi que tous ceux qui souhaitent comprendre la sécurité de la chaîne d'approvisionnement logicielle, sont heureux de vous accueillir dans comprendre la sécurité de la chaîne d'approvisionnement logicielle, ce Et comment utiliser ce cours, s'il vous plaît, vous devez comprendre et mettre en œuvre les stratégies que je vais décrire et adapter votre chaîne d'approvisionnement logicielle à ces pratiques Ne vous contentez pas de suivre ce cours pour ensuite l'oublier. Veuillez appliquer les connaissances dont je parle. En sachant que vous n'êtes pas appliqué, vous allez l'oublier, puis créer un programme de sécurité de la chaîne d'approvisionnement logicielle approprié . Ce sera votre projet pour ce cours. Je veux que vous dirigiez, que vous utilisiez les concepts que je vous enseigne , que vous les appliquiez au sein de votre entreprise et que vous fassiez une lacune. C'est ce que nous abordons. Maintenant, en ce qui concerne les logiciels, nous sommes sur le point de commencer. N'oubliez pas que les logiciels sont partout. Des milliards de lignes de code source sont présentes partout, et une seule vulnérabilité logicielle peut empêcher entreprises entières de faire des affaires et causer des milliards de dollars de dégâts Plus que jamais, vous devez comprendre la chaîne d'approvisionnement logicielle et la sécurité. J'espère donc que cela vous donnera une bonne compréhension et cela vous a motivé à vraiment en apprendre davantage sur ce sujet. Commençons. J'espère que vous êtes aussi enthousiaste que moi, et je vous verrai à la prochaine leçon. Merci beaucoup. 2. Comprendre la chaîne d'approvisionnement: Bonjour, tout le monde. Bienvenue dans cette leçon dans laquelle nous allons comprendre la chaîne d'approvisionnement logicielle. Avant de commencer à la sécuriser, vous devez comprendre le fonctionnement de la chaîne d'approvisionnement logicielle dans le monde d'aujourd'hui, puis nous allons passer à la partie risques. D'accord ? C'est donc ce parlez dans cette leçon, dont vous parlez dans cette leçon, à savoir la chaîne d'approvisionnement logicielle, les concepts clés que vous devez garder à l'esprit et les différents types d' environnements existants. Et c'est comme un cours de qui servira de base à l'ensemble du cours Donc, si vous ne connaissez pas ce qu'est la chaîne d'approvisionnement logicielle, assurez-vous de suivre cette leçon, et vous ne croirez pas le nombre de professionnels de la sécurité que j'ai vus commettre cette erreur. Ce qu'ils font, c'est qu'ils prennent immédiatement le risque sans avoir au préalable compris ou apprécié ce qu'est la chaîne d'approvisionnement logicielle, quels sont les différents environnements et comment ils fonctionnent. Nous avons donc déjà parlé cette définition, revue très rapide. chaîne d'approvisionnement logicielle, comme nous en avons parlé, la séquence des processus impliqués dans le déploiement, développement et la maintenance des applications logicielles. En gros, tout ce dont vous avez besoin pour créer un artefact logiciel, du développement du code source au déploiement en production, fait partie de la chaîne d'approvisionnement logicielle Nous avons parlé plus tôt du fait qu'il est très rare que les entreprises créent un fichier à partir de zéro. Ils s'appuient sur des éléments de base tels que les bibliothèques open source, les outils de développement et les services SAS. se réunissent tous pour créer ce progiciel, n'est-ce pas ? Et dans chacun d'entre eux, il existe un risque potentiel de sécurité. Alors, à quoi ressemble un environnement de développement logiciel typique de nos jours ? Un environnement logiciel, désolé. Voilà donc à quoi ça ressemble. Nous allons procéder étape par étape. Et avant que vous ne me sautiez dessus et que vous ne commenciez à crier que mon environnement n'est pas le même, je sais que chaque environnement est différent , mais c'est le plus courant, comme les attributs qui seront présents dans pratiquement tous les environnements existants Commençons donc par l' environnement de développement. C'est là que la magie opère, non ? Les développeurs utilisent cet environnement pour écrire et tester du code. Ils créent de nouvelles fonctionnalités et expérimentent des idées. C'est comme leur espace de travail, non ? Leur permettre d'écrire du code et de donner vie à leurs visions. Et l'environnement de développement est généralement équipé de divers outils et frameworks, qui ne sont pas présents sur les autres machines professionnelles. C'est donc comme un environnement spécial. Ils ont généralement plus de privilèges. Alors, que font-ils ? Ils utilisent leur environnement de développement intégré, leurs postes de travail, dotés de leur logiciel de codage Pour écrire du code, qui est envoyé vers un dépôt de code. Un dépôt de code peut être similaire un serveur partagé qui contient le code À partir de là, la plate-forme de construction prend son code et l' intègre pour en faire un artefact Désormais, les développeurs utilisent peut-être des dépendances dans leur code ou, lors de sa création, il peut en extraire des dépendances. Les dépendances sont, comme je l'ai dit, ces éléments de base, n'est-ce pas ? Vous n'allez pas tout écrire à partir de zéro, n'est-ce pas ? Si vous écrivez du code Python, vous utiliserez différentes bibliothèques. de développement utilisera donc toutes ces dépendances La plateforme de développement utilisera donc toutes ces dépendances pour créer son logiciel, et c'est ainsi que fonctionne l'environnement de développement . J'écris donc du code. Il entre dans un dépôt de code, où l'environnement de construction qu'il génère compile ce Il extrait toutes les dépendances requises. Cela peut se trouver dans l'environnement, il peut s'agir d'un rapport public stocké sur Internet. Mais voici à quoi ressemble généralement un environnement de développement. Ensuite, ce qui vient, vient l' environnement de test. Donc, une fois le code écrit, il est temps d'évaluer sa robustesse et ses fonctionnalités, n'est-ce pas ? L'environnement de test ressemble à un lieu contrôlé où vous effectuez différents types de tests, tels que les tests unitaires, les tests d'intégration, les tests de système , l'assurance qualité. Vous évaluez méticuleusement ce code, n'est-ce pas ? Par rapport à des cas de test prédéfinis pour déterminer s'il existe des problèmes. Désormais, cela peut être complètement automatisé dans de nombreux environnements. Ils ont DevOps et DFSyCovs. Il se peut donc que vous ayez des tests complètement automatisés. Ou vous avez peut-être une personne assise là qui fait les tests, et vous ne croirez pas que cela se produit toujours. Vous avez de nombreuses équipes d'assurance qualité et de test qui exécutent ces tests automatisés, mais il y a une personne qui s' occupe de cela. Il existe donc différentes manières de le faire. Mais généralement, vous disposez d'un environnement de test et d'un environnement UAT dans lesquels le code est testé pour s'assurer qu'il est exempt de robots D'accord ? Que se passera-t-il ensuite ? Ensuite, vous avez ce on appelle un environnement de pré-production ou de mise en scène. Cela ressemble donc à un écart entre les phases de test et de production. Il s'agit généralement d'une réplique de l'environnement de production. Cela permet aux équipes de valider si le logiciel est comportemental. Cela fonctionne correctement dans des conditions réelles, n'est-ce pas ? Comme je l'ai dit, c'est très proche de l'environnement de production. Cela leur permet donc de le tester et d'examiner différentes manières dont le logiciel fonctionnera réellement, vous savez ? Parce que l'environnement de test UAT est similaire à un environnement de test. Il ne représente pas le monde réel. Donc, l'environnement de préproduction et de préparation est très, très proche de la façon dont fonctionnera l'environnement de production Et pour beaucoup de gens, ils utilisent préproduction et la mise en scène de Il existe de subtiles différences. Mais en général, dans l'ensemble, ils utilisent de manière assez interchangeable, honnêtement parlant, selon ce que j'ai vu Et quels sont les avantages de l' utilisation de ces environnements ? Comme je l'ai dit, des tests de charge, des tests de performance, des tests de résistance, ce que vous ne pouvez pas faire dans les environnements UAT, n'est-ce Et ils vous offrent plusieurs avantages, car ils vous indiqueront comment le client regardera le logiciel, s'il détecte des erreurs de performance, et vous ralentissez avant le logiciel n'atteigne le client final. Il vous permet d'affiner les performances en identifiant les d'étranglement qui pourraient s'y trouver, et cela vous donne un bon moyen de déterminer si les performances de l'utilisateur, la satisfaction des utilisateurs, comment elles seront présentes, car vous avez maintenant et cela vous donne un bon moyen de déterminer si les performances de l'utilisateur, la satisfaction des utilisateurs, comment elles seront présentes, car vous avez maintenant une très bonne idée de la façon dont le client regardera ce logiciel, et c'est l' avantage d'ajouter la pré-production et la mise en scène. Comme je l'ai dit, c'est très, très proche de l'environnement de production Vous pouvez donc avoir des données réelles ici, données de production réelles y étant stockées. Enfin, il y a l'environnement de production. s'agit donc de la destination ultime pour votre logiciel Il s'agit d'un environnement réel dans lequel les utilisateurs finaux interagiront avec votre application ou votre système. Le logiciel est déployé ici, et il doit être méticuleusement testé et affiné dans les environnements précédents pour garantir aux clients une expérience fluide Maintenant, je n'ai jamais entendu parler d'un logiciel qui ne présente aucun bogue dans cet environnement de production, quel que soit le nombre de tests que vous effectuez. Mais en suivant les étapes, cela vous donne une très bonne idée et vous donne la possibilité de supprimer les bogues qui pourraient s'y trouver. Voici donc à quoi ressemblera un environnement logiciel typique . Comme je l'ai dit, avant que vous ne deveniez fou et m' accusiez de passer à côté de domaines critiques. Comme je l'ai dit, je sais que chaque environnement est différent, mais c'est celui qui s'en rapproche le plus. Ce sont généralement les manières les plus courantes structurer les environnements de développement logiciel. J'espère donc que tu as une bonne idée. Nous allons maintenant passer en revue quelques concepts existants, à savoir revue quelques concepts existants, à les Dev SecOps, les pipelines CICD, les artefacts, les dépôts d' artefacts, les référentiels de packages et l'infrastructure sous forme de COD dépôts d' artefacts, les référentiels de packages et l'infrastructure sous forme et Cela vous est peut-être familier, mais je l'ai délibérément mis ici à titre de rappel, car tous ces domaines entreront en jeu lorsque nous évoquerons les risques liés à la sécurité de la chaîne d'approvisionnement logicielle risques liés à la sécurité de la chaîne Je l'ai donc présenté comme une révision. Si vous pensez être très bon dans tous ces concepts, n'hésitez pas à sauter cette leçon. Mais je vous recommande de le prendre comme une révision rapide, donc je vous verrai dans la prochaine leçon. 3. Risques de chaîne d'approvisionnement - 1: Bonjour, tout le monde. Bienvenue. Bienvenue à la prochaine leçon. Et c'est là que nous commençons vraiment à entrer dans le vif du sujet, c' est-à-dire que nous allons maintenant parler du risque de sécurité, n'est-ce pas ? La chaîne d'approvisionnement logicielle, les risques de sécurité. Dans la leçon précédente, je vous explique comment les environnements de développement logiciel sont généralement configurés, n'est-ce pas ? J'essaie tout simplement de décrire l'environnement de développement logiciel le plus courant , son fonctionnement, les différents concepts et la manière dont les logiciels les traversent. Maintenant, dans cette leçon, nous allons parler des risques de sécurité, c'est-à-dire des risques de sécurité dans la chaîne d'approvisionnement des canapés, de la manière dont ils se produisent, et nous allons analyser les incidents réels. Certains des plus populaires, comme les événements solaires, Cord Cov Au moment où j'ai terminé ce cours, il probable une autre attaque de la chaîne d'approvisionnement se soit produite. Mais je vais aborder ceux qui couvrent différents scénarios. Et qui peut vous montrer l'impact réel. Ce n'est donc pas simplement théorique que je vous dis que ces choses peuvent se produire. Je vais vous montrer comment cela s'est produit, quel en a été l'impact et ce que vous pouvez faire pour réellement vous protéger, est-à-dire empêcher que ces choses ne se produisent. Donc, si vous vous souvenez, c'est le schéma que nous avons examiné auparavant, n'est-ce pas ? Nous avions l' environnement de développement avec l'identifiant, qui envoyait le code vers le dépôt, la plateforme Bull se lançait , intégrait toutes les dépendances et le blanc, et elle le transmettait à l'environnement de test, puis à la préparation à la production Cela peut être entièrement manuel ou il peut s'agir d'un pipeline CICD, blanc, diffusant votre code Des différents environnements jusqu'à ce qu'il soit transféré à l'environnement de production, et c'est ce dont nous avons parlé. Réfléchissons donc maintenant aux risques à un niveau élevé. Commençons maintenant par le développeur. Aujourd'hui, dans la plupart des environnements, les développeurs , que vous appelez développeurs, disposent généralement de privilèges assez puissants. Ils ont la capacité de gérer leurs propres environnements de développement, car ils ont besoin cette flexibilité pour créer de nouvelles applications et de nouveaux produits. D'après mon expérience, ils peuvent parfois créer des machines virtuelles telles que, vous savez, des systèmes d'exploitation à deux bateaux, Linux et Windows. Et ces environnements sont souvent parfois invisibles pour les services informatiques. C'est pourquoi ils les appellent Shadow IT, non ? Et les développeurs pensent qu'ils ont besoin de cette flexibilité, n'est-ce pas ? Ils doivent être capables de lancer une machine virtuelle, installer des applications et de gérer leur environnement. Ils ne veulent pas que leurs ordinateurs portables ou de bureau soient verrouillés, et ils veulent avoir accès à leurs systèmes par des administrateurs ou des utilisateurs expérimentés , car si vous arrêtez cette fonctionnalité, ils ne seront pas en mesure de résoudre les problèmes liés à la création d'environnements, ou ils devront passer par des dizaines d' approbations pour modifier Si vous avez déjà travaillé dans le domaine de la cybersécurité, je suis sûr que vous avez dû le voir, n'est-ce pas ? Nous commençons donc par le fait que c'est la première chose à laquelle vous devez penser aux privilèges très puissants dont disposent les développeurs et à quoi cela aboutira, nous verrons. Ensuite, bien sûr, vient en code sécurisé. Et nous allons voir si le code qu'ils écrivent n'est pas sécurisé ? Ils le placeront dans un dépôt de code , puis il se propagera dans tous les environnements, et ce code présente de graves failles de sécurité Et si vous êtes un fournisseur de services, comme Solar Winds, ce code peu sûr se propagera partout, Des milliers et des milliers de personnes parce que vous ne l'avez pas vérifié vous-même, n'est-ce pas ? Et le code est poussé comme ce que vous appelez un dépôt de code, n'est-ce pas Maintenant, le dépôt de code, vous pouvez également avoir plusieurs compromis ici, Le référentiel source, le référentiel de code, peut-être l' interface d'administration, ne sont pas sécurisés. Et l'attaquant peut utiliser l'interface d'administration ou compromettre le serveur sous-jacent pour attaquer directement le code source et y accéder, puis il commence à modifier le code. Ou ils peuvent y placer un logiciel malveillant qui se propage partout. Pensez donc au dépôt de code qui s'y trouve. Bien entendu, vous disposez de la plate-forme intégrée, étroitement intégrée à vos dépôts d' artefacts et à vos référentiels de packages Et souvent, ils commencent à créer des objets et à les propager dans vos environnements, n'est-ce pas Ainsi, l'attaquant peut attaquer les entrées de cette plate-forme de compilation, comme la version à utiliser, et rediriger vers un code malveillant, que la plate-forme de génération propage avec elle que la plate-forme de génération propage avec Et nous le verrons lors de l'attaque des vents solaires. Ils peuvent donc attaquer n'importe quelle partie de la plate-forme construite, y compris ses services ou l'infrastructure sous-jacente, et ils peuvent modifier la façon dont elle est facturée, n'est-ce pas ? Et cela peut mener à bien. Ils peuvent compromettre le dépôt d' artefacts comme le package dont nous avons parlé, et ils peuvent télécharger ou publier artefacts modifiés parce que vous n'avez pas sécurisé l'interface d'administration Enfin, les dépendances, si vous regardez tout en haut c'est l'une des choses les plus courantes. Malheureusement, les gens pensent que c'est la seule chose qui concerne chaîne d'approvisionnement logicielle, mais que vos dépendances, parce que vous utilisez diverses bibliothèques commerciales et open source tierces, existent, et c'est ainsi que la plupart des environnements sont configurés, n'est-ce pas ? Donc, ce qui va se passer, c'est que vous aurez plusieurs et si un attaquant compromet cette bibliothèque Ils essaient d'introduire un comportement malveillant en compromettant cette bibliothèque, et cette dépendance va se propager dans tout votre code Votre code, nous avons un composant non sécurisé, comme nous avons parlé de Log for J, n'est-ce pas ? Elle se propagera dans votre environnement, et plus tard, lorsqu'une vulnérabilité sera découverte, l' attaquant pourra s' en servir pour s'intégrer à votre environnement Il s'agit donc simplement de l' environnement des développeurs, n'est-ce pas ? Passons ensuite aux autres environnements tels que l' environnement de test UAT. Lorsque vous effectuez les tests, les entreprises ne prennent parfois même pas peine de faire des tests de sécurité Ils ne savent pas si le code est sécurisé. Que le COO introduise vulnérabilités ou non, quelque chose d'indépendant Ils ne comptent que sur le développeur. Vous ne croirez pas à quel point c'est encore courant, malheureusement. Ces tests de sécurité ne sont donc pas là. Beaucoup d'entreprises que j'ai vues font des tests de sécurité, mais rien ne se passe ensuite. Ils font donc un test de sécurité, et ils sont d'accord, ils viennent de publier un rapport. Voici les failles de sécurité. Personne ne regarde ces vulnérabilités, n'est-ce pas ? Donc, le test de sécurité, vous ne le faites pas uniquement pour le plaisir de tester la sécurité, n'est-ce pas ? Vous effectuez des tests de sécurité afin de corriger les vulnérabilités. C'est donc un autre problème. Les tests de sécurité n'existent pas. Ensuite, bien sûr, vous passez à l'environnement de pré-fierté et à l' environnement de mise en scène. Et nous avons dit qu'il s'agissait d'une réplique de la production. Ce n'est pas aussi sûr que la production. C'est une réplique. Quelqu'un pourrait donc être en mesure de le compromettre et d' accéder aux données parce que vous avez des données sur les clients. Peut-être que vous ne les avez pas masquées ou anonymisées, afin que les gens puissent accéder à ces données et les compromettre Et enfin, bien sûr, l'environnement de production. L'environnement de production n'a pas été abordé dans le cadre de ce cours car, entendu, il s'agit de cybersécurité traditionnelle. Vous aurez des correctifs et toutes ces autres choses. Mais cela peut aussi être compromis, non ? Parce que je veux que vous y pensiez d' de vue d'ensemble. Ce sont toutes les attaques qui peuvent se produire, n'est-ce pas ? Enfin, bien sûr, si vous regardez les flèches qui relient ces environnements, celui-ci, le pipeline CICD si vous utilisez, si vous utilisez un pipeline CSED , nous avons expliqué comment l'intégration continue le testera rapidement, diffusera le code et effectuera les tests, puis le déploiement continu ou elle transmettra le code dans l'autre environnements, non ? Et si quelqu'un est capable de compromettre le pipeline du CICD ? Ce pipeline a accès à tous les environnements, n'est-ce pas ? Ils peuvent donc réellement contrôler le code qui est envoyé, type de tests en cours C'est une autre chose que vous devez garder à l'esprit. C'est une autre chose très, très dangereuse qui peut arriver. Voici donc la situation dans son ensemble. est le genre d'attaques auxquelles je veux que vous pensiez lorsque vous pensez à la sécurité de la chaîne d'approvisionnement, n'est-ce pas ? Et est-ce mon opinion ? Vous êtes peut-être en train de réfléchir, et ce n'est que votre opinion subjective. Donc non, je l'ai basé sur une référence du secteur. C'est donc de la salsa. On dit que c'est de la salsa, ce que j'aime bien, mais c' est le niveau de la chaîne d'approvisionnement pour les artefacts logiciels Il s'agit d'une référence dans le secteur. Je mettrai le lien dans ce cours. Il s'agit donc d'un cadre de sécurité. C'est comme une liste de bonnes pratiques pour éviter que la sécurité de votre chaîne d'approvisionnement logicielle ne soit compromise, n'est-ce pas ? Et il est généralement utilisé dans l'ensemble de l'industrie. C'est une très, très bonne entreprise indépendante, indépendante de la technologie ou du fournisseur. Et c'est comme un ensemble de directives. Vous pouvez les adopter lentement et ils sont établis par consensus au sein de l'industrie. Et ils sont mis en place. Donc, tous ceux qui créent des logiciels les utilisent, n'est-ce pas ? Toute personne qui produit, consomme ou fournit des logiciels tels que des plateformes de création ou autre peut être utilisée pour renforcer peut être utilisée pour confiance dans sécurité de votre chaîne d'approvisionnement logicielle. C'est comme une collaboration intersectorielle. Nous en reparlerons plus tard. Mais il s'agit d'un système totalement indépendant des fournisseurs Ce que vous appelez un cadre de sécurisation de votre logiciel est un plan. Il vous donne un vocabulaire commun pour parler de la sécurité de la chaîne d'approvisionnement logicielle. C'est donc sur cela que j'ai construit ce schéma. C'est donc ce que nous voulons montrer. Et il s'agit d'une référence dans le secteur. Je vais donc y mettre le lien. Vous pouvez voir, donc il n'y a pas que moi, vous pensez que je ne parle que de mon propre avis. Cela est basé sur une référence du secteur dont j'ai parlé, et je recommanderais certainement d'y jeter un coup d'œil plus tard, lorsque nous élaborerons un programme de sécurité de la chaîne d'approvisionnement logicielle un programme de sécurité de la chaîne d'approvisionnement logicielle, d'accord ? Nous allons donc maintenant parler du principal risque de sécurité. Je ne vais pas en parler dans cette leçon, car je vous ai déjà donné quelques points à aborder. Nous allons continuer dans la prochaine leçon. Mais nous allons parler du principal risque de sécurité. Tous les risques dont nous avons parlé dans le diagramme, nous allons examiner en profondeur chacun d' entre eux et réfléchir à façon dont cela fonctionne et aux implications de ces attaques. Il est essentiel de les comprendre, car sinon vous ne pourrez pas sécuriser quelque chose si vous ne comprenez pas comment cela se passe, n'est-ce pas ? Nous allons donc maintenant examiner en profondeur chacun de ces risques, et je vais vous montrer l'impact de ces événements. OK, merci beaucoup. Je te verrai dans la prochaine leçon. 4. Risques de chaîne d'approvisionnement - 2: Bonjour, tout le monde. Bienvenue dans cette leçon. Nous allons maintenant parler des principaux risques de sécurité dont nous avons parlé dans le schéma. Et nous allons marcher un par un, afin que vous ayez une meilleure idée de ces risques de sécurité. Et plus tard, lorsque nous commencerons à les sécuriser, vous aurez une bien meilleure idée. Nous allons également voir quelques études de cas sur les vents solaires et sur manière dont ces risques peuvent réellement se produire et faire de véritables compromis Je vais y aller étape par étape pour vous donner une meilleure idée de ces attaques. Commençons donc par le numéro un qui est un code non sécurisé Maintenant, le code non sécurisé ne l'est pas. Je veux dire, honnêtement, c'est quelque chose qui existe dans l'industrie depuis des décennies, et il y a maintenant une grande prise de conscience Je veux dire, comparé aux autres attaques, je dirais que le code non sécurisé n' est pas si grave Je sais que la plupart des entreprises ont commencé à prendre des mesures, mais c'est le point de départ. Parmi tous les risques liés à la sécurité de la chaîne d'approvisionnement logicielle Honnêtement, comme je l'ai dit, à la racine de tous les maux, qu'il s'agisse d'un tiers ou d'un tiers, vous devez vous assurer que votre code est sécurisé. Et l'erreur que commettent de nombreuses entreprises, qu'elles sécurisent leur propre code, c'est qu'elles sécurisent leur propre code, mais elles ne tiennent pas compte des tiers, et il faut traiter tous les codes de la même manière. Vous devez vous assurer que vous avez l'assurance que ce code a été sécurisé. Et vous vous demandez peut-être comment puis-je sécuriser un code tiers ? Je n'y ai pas accès ? Eh bien, il existe des moyens de s'y prendre. Vous pouvez demander au vendeur. Vous pouvez évaluer les processus de gestion des risques liés aux fournisseurs, n'est-ce pas ? Il existe donc des moyens de le vérifier, et nous allons l'examiner plus en détail. Où nous parlons de la création du programme de gestion des risques de sécurité des fournisseurs. Mais un code non sécurisé signifie que si vous ne sécurisez pas votre code, tous les autres contrôles n'auront aucune importance, car c' est là que se situeront la plupart de vos risques de sécurité Ce ne sont donc que des exemples. J'avais l'habitude de les examiner, et si vous vous y connaissez un peu en codage, cela ressemble à une attaque par injection où vous ne nettoyez pas le code, vous acceptez simplement du code dans votre environnement, et pratiquement tout le monde peut simplement contourner ce code pour accéder à vos bases de données sous-jacentes, à votre système d'exploitation sous-jacent C'est ce qu'on appelle une attaque par injection. Et vous n'allez pas le croire, même en 2024, je vois des gens continuer à commettre cette erreur. C'est donc incroyable. Je m'intéressais à la programmation en 2002. Cela fait donc presque 22 ans maintenant, et ce problème est toujours là J'ai trouvé très amusant que cette erreur soit toujours présente malgré tous les progrès que nous avons réalisés. C'est autre chose. Cela ressemble à un attentat à la bombe ZIP au cas où vous ne le connaîtriez pas, c' est comme une archive dont vous ne validez pas un fichier ZIP ou un fichier d'archive, vous l'extrayez simplement sans effectuer de validation vous l'extrayez simplement sans effectuer Vous pouvez donc effectivement provoquer un déni de service à l'attaquant. Vous pouvez épuiser l' espace ou la mémoire du système cible lorsque vous essayez de l'extraire, n'est-ce pas ? Et honnêtement, le format ZIP est le plus couramment utilisé, mais vous pouvez à peu près l'utiliser. C'est comme compresser un gros fichier composé d'un seul caractère, n'est-ce pas ? Et vous pouvez créer un fichier d'un Mo qui sera décompressé en un seul Go Et cela va en fait gâcher le système d'exploitation parce que vous n'effectuez aucune validation. Il s'agit donc d'une autre attaque , due à votre code non sécurisé Et je veux dire, tout le monde le sait. C'est la chose la plus ancienne et la plus courante, savoir les secrets codés en dur. Comme si les gens étaient paresseux. Ils ne veulent pas effectuer de validation sécurisée et personne ne regarde le code. Ils ont donc introduit les secrets codés en dur, et ceux-ci sont transférés dans un référentiel de code public. supposant que vous utilisez un moissonneur de code public, quelqu'un y accède et boum, il a accès à votre environnement parce que vous avez saisi le nom d'utilisateur et le mot de passe dans un moissonneur de code Je connais tellement d'entreprises ont des politiques de mots de passe très strictes, mais elles ne tiennent pas compte du code. qui est là, et donc ils ne scannent même pas leur code. Cela peut donc entraîner la saisie d' identifiants utilisateur, de mots de passe clés d' accès codés en dur dans un code et insérés dans le rapport de code. Toute personne ayant accès à ce code peut désormais contourner et compromettre votre environnement. C'est donc juste pour vous montrer à quel point ces attaques sont dangereuses. C'était donc comme un code non sécurisé. Passons au suivant, qui concerne les composants tiers non sécurisés Et c'est là que l'accent est le plus mis lorsque les gens parlent de sécurité de la chaîne d'approvisionnement, c'est-à-dire de dépendances vulnérables ou malveillantes avec des tiers. Vous savez, nous en avons parlé plus tôt : les logiciels modernes reposent sur des bibliothèques tierces ou adios Et si ces dépendances contiennent des vulnérabilités ou du code malveillant , elles peuvent introduire des risques dans l'ensemble de votre environnement, n'est-ce pas ? Et les logiciels tiers, pensez aux logiciels tiers, ne sont que des logiciels propriétaires écrits par quelqu'un d'autre. Donc, tout comme le Cloud n'est qu'un serveur géré par quelqu'un d'autre. Les dépendances logicielles tierces, vous pouvez y penser. Ce sont vos dépendances, mais elles ont été écrites par quelqu'un d'autre. Tous les risques que nous avons évoqués au sujet de l'encodage sont également répercutés ici. Et ces vulnérabilités peuvent s'introduire dans votre environnement. Si l'attaquant parvient à le compromettre. Cette dépendance, cette dépendance, sera désormais utilisée pour compromettre votre environnement, n'est-ce pas ? Et il peut s'agir de vulnérabilités connues. Ce n'est donc pas comme si elle était masquée car cette vulnérabilité est connue depuis longtemps, mais vous n'êtes pas en mesure de la corriger car elle endommagerait votre application ou parce que le fournisseur n'a pas publié de correctif. Il faut donc y réfléchir. OK, que dois-je faire maintenant ? Ou bien, cela peut être un jour nul, comme le Lock initial pour J. Vous vous souvenez de Log for J, n'est-ce pas ? Cela peut prendre zéro jour. Personne n'était au courant. Soudainement, cela arrive, et il n'y a pas de solution. Et rapidement, les attaquants peuvent commencer à le manipuler, à essayer de compromettre les environnements avec lui Et c'est comme si vulnérabilités immédiates pouvaient rester inactives dans une base de code pendant des mois, des années, voire des décennies. Et quand ils sont enfin découverts et annoncés dans le monde entier, ils se bousculent J'aimerais savoir s' ils utilisent ce logiciel ou non, d'accord, pour savoir s'ils utilisent cette dépendance et comment se protéger contre toute exploitation. Les attaquants se bousculent également. D'ailleurs, ils essaient de déterminer qui utilise ce logiciel vulnérable, et ils essaient de créer des exploits pour en tirer parti et compromettre l'environnement. Donc c'est comme une course effrénée pour que les gens le découvrent, non ? Et c'est à ça que ça ressemble habituellement. Vous avez donc un attaquant qui compromet cet environnement. Ils compromettent un laboratoire tiers et ce laboratoire tiers s'immisce dans tous les domaines Cela se propage à des milliers et des milliers d'entreprises, n'est-ce pas, comme Lock for et prenons l'exemple des victoires solaires Quelqu'un a compromis l'environnement des vents solaires et le code que nous avons ensuite utilisé pour faire passer dans l'environnement. Voici donc un autre exemple de la façon dont cela s'est produit. Et c'est généralement ainsi que fonctionnent les composants tiers peu sécurisés , n'est-ce pas ? Il faut y réfléchir sous cet angle. Il s'agissait donc du codage de premier niveau et des dépendances tierces. Je vais diviser cette leçon en plusieurs parties parce que je veux que vous absorbiez ce nous avons parlé avant de passer à la suivante. Dans le prochain article, je vais parler de la compromission du code dans lequel vous le stockez. N'oubliez pas que lorsque le développeur avait l' habitude de publier du code, celui-ci était dirigé vers un dépôt de code Parlons donc du dépôt de code et de ce qui peut arriver. Merci, je vous verrai dans la prochaine leçon. 5. Risques de chaîne d'approvisionnement - 3: Bonjour, tout le monde. Bienvenue. Bienvenue dans cette leçon. Nous allons maintenant parler de la compromission du dépôt de code Comme vous pouvez le constater, si vous vous souvenez du schéma, nous progressons lentement dans la chaîne d'approvisionnement logicielle. Et nous avons déjà parlé des dépôts de code. De base, considérez-le comme une bibliothèque centralisée ou un référentiel centralisé dans lequel vos développeurs peuvent collaborer sur le code, n'est-ce pas ? J'écris donc du code et je le place dans un rapport de code. Un autre développeur écrit également du code. Ils insistent pour que le même rapport soit publié. Et le code, vous avez entendu parler de Github Wide. Il s'assure donc que tout le code est synchronisé. Et que peut-il arriver, les attaquants peuvent accéder à ce dépôt, n'est-ce pas ? Peut-être que le logiciel n' est pas sécurisé, ou peut-être qu'ils compromettent l'utilisateur. Ils lui ont envoyé un lien malveillant, et il a fait comme s'il avait saisi son nom d'utilisateur et son mot de passe, et ils avaient réussi à les obtenir. Ils peuvent désormais manipuler le code source à la base. Ou même beaucoup de gens ne le savent pas. Le dépôt lui-même peut être utilisé pour lancer des attaques contre les clients Et parfois, les gens n'en sont pas conscients. Il y a donc la sécurité du dépôt lui-même, en s'assurant que le dépôt n'est pas compromis, et le dépôt lui-même peut être utilisé comme vecteur d' Et prenons un exemple. Donc, juste au cas où vous ne le sauriez pas, je pense que cela s'est produit en 2020, avec le malware Octopus Scanner Ce sont donc en fait des attaquants. Ce qu'ils ont fait, c'est qu'ils disposaient d'un ensemble de référentiels hébergés sur Github, et ils étaient involontairement le mot clé Involontairement, ils étaient utilisés pour diffuser des logiciels malveillants. En fait, l' équipe de sécurité de Github a fait des recherches et a découvert que ces dépôts n'avaient pas été sécurisés et qu'ils étaient utilisés pour diffuser des malwares à tous les niveaux, Et les propriétaires des maisons de repos n'en étaient absolument pas conscients. Ils commettaient comme du code malveillant dans les référentiels. Quand ils extraient le code, ils extrayaient en fait des logiciels malveillants, et ils fournissent un niveau élevé. Comment appelez-vous ? Ce qu'il fait bien, en gros, c'est qu'il a compromis le dépôt lui-même. Et vous pouvez imaginer à quel point c'est dangereux, non ? Parce que pourquoi ? Parce que le malware est introduit dans le poste de travail du développeur. À partir de là, il est intégré au build, et vous permettez à ce malware de se déplacer dans votre environnement. Et comme les principales personnes compromises sont les développeurs, et si vous vous souvenez de ce dont nous avons parlé, les développeurs ont traditionnellement plus d'accès que les gens ordinaires, n'est-ce pas ? Ils ont des privilèges élevés, utilisateurs expérimentés. Cela leur permettra donc potentiellement d' accéder aux environnements de production. Vous pourriez potentiellement accéder à la base de données, mots de passe et à d'autres actifs essentiels, n'est-ce pas ? Il existe un énorme potentiel d'escalade de l'accès pour l'attaquant procédant à une augmentation de privilèges, ce qui est l'un des principaux objectifs de la plupart des compromissions de données. Lorsque l'attaquant pénètre dans un environnement, la première chose qu'il souhaite faire est devenir administrateur, n'est-ce pas ? Et c'est juste pour vous montrer ce qui peut arriver. Les gens pensent que, oh, le dépôt de code pourrait devenir public. C'est la pire chose qui puisse arriver. Non, si vous n'avez pas sécurisé votre dépôt de code, le rapport de code lui-même peut compromis et être utilisé pour diffuser des logiciels malveillants. Et nous parlerons de tous les contrôles de sécurité plus tard. Tout d'abord, je veux que vous compreniez les risques. Et cela est étroitement lié à l'environnement des développeurs. Nous en avons déjà parlé, non ? C'est un développeur auquel ils ont besoin d'un accès parce qu'ils veulent pouvoir le faire, ils veulent des bacs à sable Ils veulent avoir la possibilité de faire tourner une machine virtuelle, installer des applications, au moins un accès élevé. Ils ne veulent pas de ce PC d'entreprise sur lequel ils ne peuvent rien faire car ils ont besoin de pouvoir exécuter du code. Ils ont donc des outils électriques, ils ont des identifiants avec des plugins. Ces plugins peuvent être compromis, non ? Il faut donc penser à toutes ces choses. Et, bien sûr, PreProdeEnvironments. L'environnement de pré-production contiendra les données des clients. Ainsi, si un malware est présent, il compromet la machine du développeur et, lentement, il est poussé vers l'environnement, l'attaquant pourra atteindre un environnement où le malware pourra lui dire : «   Écoutez, j'ai accès aux données des clients maintenant Vous serez en mesure d' exfiltrer ces données. C'est ainsi que vous pouvez voir à quel point plusieurs éléments se rejoignent le PC du développeur n'est pas sécurisé, l'analyse des sources est compromise, votre environnement de préproduit contient des données production totalement ouvertes Tous ces éléments sont combinés pour réellement compromettre votre environnement. C'était donc davantage du point de vue du développeur. Parlons maintenant des attaques pendant la phase de construction. Nous avons déjà parlé d'un serveur de build, n'est-ce pas ? C'est un élément essentiel du CICD, car automatise essentiellement le processus de compilation du code, exécution de tests et de préparation des applications pour C'est comme si le serveur de build faisait tout, n'est-ce pas ? Et les attaques pendant la phase de construction sont très dangereuses, car si un attaquant parvient à obtenir accès ou un contrôle non autorisé sur le serveur de compilation, il peut réellement provoquer des ravages dans votre environnement Pourquoi ? Parce que les plateformes créées sont généralement intégrées à vos dépôts d'artefacts, où se trouve votre code ou à vos dépôts de packages, pourquoi ? Et ils peuvent modifier votre build. Ils peuvent donc réellement attaquer ces plateformes de facturation. Ils ont beaucoup de paramètres, non ? Ils peuvent donc réellement le changer. Ils peuvent l'utiliser pour se diriger vers un endroit compromis. Ils peuvent également utiliser la plateforme de facturation elle-même pour diffuser leur propre code malveillant, comme celui qui s'est produit avec les vents solaires, dont nous parlerons bientôt. Ou ils peuvent réellement l'utiliser pour compromettre les artefacts, n'est-ce pas ? La plate-forme construite est donc un élément très, très critique de votre environnement. Et l'un des meilleurs exemples de ce qui se passe est celui des victoires solaires. Après cette leçon, nous aborderons quelques leçons plus tard, nous allons faire une étude de cas sur ce qui se passe lorsqu'une plateforme construite est compromise. L'impact du meilleur exemple en est celui des victoires solaires. L'autre facteur étroitement lié à cela est la compromission du pipeline du CICD Nous avons parlé du pipeline du CICD. Pourquoi ? Cela envoie automatiquement le code, le déploie, le teste Et ces pipelines sont des cibles très, très attrayantes pour les attaquants. Pourquoi ? Parce qu'ils offrent un accès direct à l'environnement de production logicielle système utilisateur et aux données. Donc je veux dire, comment cela peut-il être compromis ? Il existe plusieurs moyens. Il se peut que vos informations d'identification ne soient pas sécurisées. Vous n'avez peut-être pas correctement configuré les contrôles d'accès. Vous avez peut-être des outils vulnérables qui sont compromis, n'est-ce pas ? Et n'oubliez pas que CSCDPipeline est le processus automatisé utilisé pour intégrer, tester et Et celles-ci peuvent entraîner de graves failles de sécurité. Et cela peut également amener d' autres clients à faire des compromis, ce dont nous allons parler dans une étude de cas intitulée Cod COV Je vais vous montrer ce qui se passe. En fait, si le pipeline du CICD est compromis, cela aura un impact Ce sont donc les deux. L'un d'eux est le serveur de build, nous allons faire une étude de cas et celle-ci. Nous allons faire une étude Kas. Je vais vous montrer brièvement ce qui se passe lorsque le serveur de build ou le pipeline CICD sont compromis. Mais maintenant, je veux que vous réfléchissiez à l'impact que cela peut avoir. Cela couvre donc cette section particulière. Nous allons maintenant parler du dépôt de colis, mais comme je l'ai dit, je ne veux pas vous submerger ou vous submerger de trop d'informations Dans la prochaine leçon, nous allons parler du package wept et des attaques spécifiques qui peuvent le cibler, ainsi que de certaines attaques uniques telles que les attaques de dépendance ou de confusion Comment se produisent-ils et quel est l'impact de ces attaques ? Merci beaucoup, je vous verrai bientôt. 6. Risques de chaîne d'approvisionnement - 4: Bonjour, tout le monde. Bienvenue Bienvenue dans cette leçon. Et maintenant, nous allons nous concentrer sur le package rest. Si vous vous souvenez de votre logiciel intégré dans un package, n'est-ce pas ? Tout le code et toutes ses dépendances regroupés dans un package que vous pouvez déployer dans les environnements du client, dans vos environnements de production. Désormais, le dépôt des packages est l'endroit où ces packages sont conservés, et le rapport du package lui-même peut être compromis. Alors peut-être que vous n'avez pas sécurisé le dépôt de packages, n'est-ce pas ? Nous lui avons donné un accès libre. Vous l'avez donc mal configuré. Peut-être que vous êtes connecté à Internet ou que vous avez autorisé l'accès anonyme. Vous utilisez des mots de passe par défaut et vous accordez des privilèges de téléchargement à des utilisateurs susceptibles de faire l'objet d'abus. Et ce qui peut arriver, c'est qu'un attaquant peut accéder à ce dépôt de paquets et l'empoisonner dépôt du package est donc violé ou manipulé par des acteurs malveillants tels que Widen Cela peut donc affecter l'intégrité et la sécurité de l'ensemble de la chaîne d'approvisionnement, n'est-ce pas, la chaîne d'approvisionnement logicielle, car ils peuvent envoyer des packages malveillants, n'est-ce pas ? N'oubliez pas qu'il s'agit d'un endroit centralisé où les progiciels sont stockés. Alors, que peut-il se passer ? Les gens peuvent diffuser des logiciels malveillants. Ainsi, l'injection de logiciels malveillants, le code malveillant peuvent être ajoutés aux packages du référentiel. Ainsi, lorsque les utilisateurs le téléchargent et intègrent ces packages compromis, le malware fait partie de application ou, euh, le vol d'informations d'identification, n'est-ce pas ? Les attaquants peuvent peut-être voler informations d'identification des packages, puis les utiliser pour introduire d'autres codes non autorisés dans le pipeline. Vous pouvez même faire remplacer des packages légitimes. Vous avez donc un nom de package. Vous pouvez le remplacer par votre propre package malveillant, et en aval, il sera transmis à des milliers et des milliers de personnes. Enfin, les attaques de confusion liées à la dépendance. Il s'agit d'un type d'attaque spécial cadre duquel les attaquants publient des packages, dont les noms sont similaires à ceux packages privés internes utilisés par l'entreprise. Et s' il s'agit d'un package public dont le numéro de version est supérieur, les gestionnaires de packages peuvent récupérer au lieu du package interne, et je vais vous montrer comment cela se passe C'est une attaque tout à fait unique, mais extrêmement dangereuse. Mais c'est exactement ce que je voulais te montrer. Et ce n'est pas une blague. Je veux dire, le dépôt de packages, juste pour vous donner un exemple. Il s'agit d'un dépôt de packages qui a été compromis l'année dernière. L'attaquant a réussi à accéder, je crois, à quatre comptes inactifs, et il a piraté plus d'une douzaine de packages avec plus de 500 millions d' installations, n'est-ce pas ? Et en gros, ils ont remplacé, je crois la description du package par leur propre message, et cela a été autorisé à compromettre, gros, à modifier les packages, et cela a été diffusé de plus en plus. Ainsi, les développeurs qui téléchargeraient les packages recevraient le package malveillant. Et juste pour vous montrer à quel point c'est dangereux, les gens, si vous n' utilisez pas quelque chose comme l' authentification multifactorielle, si vous utilisez simplement des mots de passe partagés, et c'est ainsi que cela s'est passé Et, vous savez, cela ne fait que vous montrer à quel point il est dangereux que des utilisateurs, qui sont complètement ouverts, qui n'ont pas de contrôle d'accès, puissent acquérir des logiciels malveillants. Les gens pensent aux malwares. Ils pensent à quelque chose qui arrive sur Internet ou par courrier électronique, n'est-ce pas ? Ils ne se rendent pas compte que votre chaîne d'approvisionnement logicielle, c'est-à-dire vos packages, vos plateformes conçues qui peuvent également être utilisées pour introduire du code malveillant dans votre environnement et dans celui de vos clients, peut entraîner un énorme problème de réputation pour votre entreprise Souvenez-vous donc de toutes ces choses, s'il vous plaît. Et maintenant, ce dont je voulais parler tout à l'heure, confusion liée à la dépendance, si vous vous en souvenez. Il s'agit donc d'un type d'attaque spécial. Ils exploitent la façon dont les gestionnaires de packages téléchargent et installent les packages. Ainsi, un attaquant publie un package malveillant dans un dépôt de packages public portant le même nom qu'un package populaire, qui est utilisé en interne Et ce qui se passe, c'est que lorsque vous demandez ce package, si vous n'êtes pas configuré pour votre dépôt de packages, il va d' abord accéder à Internet et vérifier s'il existe un numéro de version supérieur Donc, en supposant que vous utilisez version 1 dans votre dépôt privé, l'attaquant va mettre le même nom et il va mettre la version deux Donc, le dépôt de packages, si vous ne l'avez pas configuré correctement, téléchargera ce package malveillant C'est pourquoi cela s'appelle la confusion des dépendances, n'est-ce pas ? Nous exploitons la façon dont ces choses fonctionnent. N'oubliez pas que nous avons des dépôts publics et des dépôts privés, n'est-ce pas ? Désolée Les dépôts privés sont donc hébergés en interne, mais vous pouvez avoir un gestionnaire de paquets public, comme un gestionnaire de paquets de nœuds et tout ça, n'est-ce pas ? Ainsi, les pirates informatiques peuvent rapidement découvrir quels sont les packages les plus courants et les plus populaires, et ils peuvent rapidement envoyer de nombreux packages, des packages malveillants portant le même nom. Et cela est très, très dangereux car si vous ne l'avez pas configuré correctement, attaquants peuvent créer un package malveillant portant le même nom qu' un package légitime et télécharger sur ces dépôts de packages populaires. Ainsi, lorsqu'un développeur demande une dépendance légitime, le gestionnaire de packages va récupérer ce package malveillant Et c'est un excellent moyen de diffuser des logiciels malveillants. Donc c'est à ça que ça va ressembler, non ? Vous avez un dépôt de packages public. L'agresseur s'y rend. Il dit : « D'accord, ce sont les packages les plus courants. Je vais publier le mien avec le même nom, mais je vais mettre un numéro de version supérieur à celui actuel. Version trois, version quatre, version cinq, non ? Et que se passe-t-il ? Le développeur s'y rend donc. Il dit, je veux que le package XYZ soit ajouté au registre privé. Ils n'ont pas configuré ce registre privé pour n'utiliser que les registres privés. Donc, par défaut, le comportement sera d'abord dirigé vers le dépôt public Il va dire et il va récupérer le mauvais package Il ne va pas récupérer le fichier interne. Il va dire : «   Hé, j'ai la première version sur Internet, il y a la version deux. Donc, ça va donner comment appelle-t-on le dernier en date. Mais celui-ci était malicieux. C'est l'agresseur qui l'a poussée. Donc, en cas de succès, une confusion et une attaque liées à la dépendance peuvent avoir de graves conséquences Il peut infecter tous les clients qui installent le package malveillant, peuvent ensuite être ciblés parce qu'ils ont été compromis par un logiciel malveillant ou un rançongiciel possible en veillant à ce que les développeurs examinent et vérifient leurs packages et maintiennent leurs dépendances à jour mais avec les dépendances privées, Il s'agit donc d'un type d'attaque tout à fait unique que beaucoup de gens ne connaissent pas. Et c'est très dangereux dans sa façon de fonctionner. résume donc ce que vous appelez le risque lié à la sécurité de la chaîne d'approvisionnement Dans la prochaine leçon, je vais parler d'une étude de cas. N'oubliez pas que nous avons parlé de la compromission de la plate-forme de construction et du pipeline CICD Nous allons parler des veines solaires et de celles à code CV. Mais dans cette leçon, qui était assez longue, nous avons parlé des types de logiciels, des risques liés à la chaîne d'approvisionnement, des différents points d'entrée des attaques et de l'impact que cela peut avoir. ce qui concerne l'impact, je vais vous donner plus de contexte en examinant les attaques réelles qui se sont produites et les conséquences très dangereuses qui en ont les conséquences très dangereuses découlé. Je vous remercie donc beaucoup. Prends le temps de recommencer cette leçon si tu en as besoin. Pour que vous ayez de bonnes bases, je vous verrai dans la prochaine leçon. 7. SolarWinds: Bonjour, tout le monde. Bienvenue. Bienvenue dans cette leçon, qui traite de la compréhension de l'attaque des vents en solo. Je suis sûr que vous avez entendu parler de l'attaque de la chaîne d'approvisionnement liée aux vents solaires. Il s'agit de l'une des attaques les plus dévastatrices qui se soient produites, au moins 21 ans après que je travaille dans le domaine de la cybersécurité, compte tenu de l'impact et du nombre d' entreprises compromises. Solar Wins est de loin l'une des plus grandes cyberattaques jamais survenues. Il est fort possible que vous suiviez ce cours, principalement à cause de la cyberattaque du vent solaire, je vais être honnête, oui. C'est pourquoi je voulais parler des vents solaires. On ne peut pas parler de sécurité de la chaîne d'approvisionnement sans parler de la cyberattaque liée au vent solaire et des études de cas, et, vous savez, prendre du recul et examiner certains de ces problèmes aidera vraiment à contextualiser les risques de sécurité de la chaîne d'approvisionnement dont je parlais, car vous pouvez alors les examiner du point de vue d'un incident réel qui s'est produit et juste pour avoir une meilleure idée de la dangerosité de ces choses, non ? Alors allons-y. Ainsi, lorsque nous parlons de victoires solaires, il s'agit, comme je l'ai dit, de l'une des attaques de chaîne d'approvisionnement les plus dévastatrices de tous les temps. C'est comme si tous les grands incidents de cybersécurité étaient reconnus, tous les grands incidents de cybersécurité étaient reconnus, et cela montre vraiment vulnérabilités présentes au sein la chaîne d'approvisionnement des canapés et leurs conséquences, telles que leur impact. Les vents solaires ont eu un impact mondial. Il est répandu dans les gouvernements et les organisations du monde entier, simplement en raison de la banalisation du logiciel d'énergie solaire, n'est-ce pas ? Et c'est vraiment tant d'OSC, des milliers et des milliers d'entreprises, qui ont réévalué la sécurité de leur chaîne d'approvisionnement et leur confiance dans les fournisseurs tiers dans tous les secteurs Et si vous ne le savez pas, Solar gagne. C'est une société de logiciels de gestion de réseau largement utilisée, qui a été la cible attaque très sophistiquée contre la chaîne d'approvisionnement. En gros, les attaquants ont réussi à s'infiltrer dans le processus de développement et de distribution du logiciel Solar Wind , et ils ont réussi à insérer du code malveillant dans ses mises à jour logicielles Il ne s'agissait donc pas simplement d'une attaque directe contre les éoliennes, mais d'une attaque indirecte contre des milliers et des milliers d' entreprises. En qui ils ont confiance. La mise à jour malveillante, déguisée jour logicielle légitime de Solar Win, a été distribuée à a été distribuée à des milliers de clients de Solar Win, et elle s'est infiltrée sournoisement dans les réseaux de tant de clients de Solar Win Et cela nous rappelle à quel point il est important de sécuriser la chaîne d'approvisionnement logicielle et à quel point vous devez réellement continuer à évaluer effectuer ces évaluations des risques. Voilà donc ce qui semblait correct. Comme je vous l'ai dit, Solar remporte des offres telles que gestion et de surveillance des performances des identifiants système de gestion et de surveillance des performances des identifiants appelé Orion, et il est utilisé par des clients du monde entier Et Orion a généralement accès aux journaux et aux données de performance du système des clients Et c'est probablement pour cela que les attaquants l'ont ciblée, car c' est pourquoi elle été victime de l'attaque de la chaîne d'approvisionnement. Ils ont donc utilisé logiciels malveillants personnalisés conçus pour le cycle de construction des vents solaires. Et ils ont pu remplacer les fichiers. Certaines personnes parlent de quelques millisecondes, et elles ont réussi à remplacer les fichiers par leurs propres mises à jour Et il y a eu une attaque très, très sophistiquée , comme ils l'ont fait, non ? Il s'appelait le malway Sunspot, et il permettait aux pirates informatiques de essentiellement surveiller L'environnement de développement des vents solaires. Et chaque fois qu'ils payaient leurs factures, ils les remplaçaient par leur propre mise à jour malveillante. Donc, en gros, c'était une porte dérobée. Et cette porte dérobée, lorsque les mises à jour étaient diffusées sous forme de mise à jour malveillante, ils avaient désormais accès à des milliers et des milliers de clients parce qu'ils pouvaient se faufiler auprès d'autres clients en insérant leur propre mise à jour malveillante dans la mise à jour de Solar Wins Solar Wins les a donc aidés à distribuer ce malware, non ? Et vous pouvez comprendre pourquoi Slewns était une cible si prometteuse pour ce type d'attaque de la chaîne d'approvisionnement, n'est-ce pas Pourquoi seraient-ils comme ça ? Eh bien, parce que honnêtement, comme je l'ai dit, de nombreuses entreprises multinationales et agences gouvernementales utilisent le logiciel Oon. Tout ce dont les pirates avaient besoin était d'installer cette mise à jour malveillante, et Solewns la distribuerait, n'est-ce pas ? Et parce que les entreprises leur font confiance , elles les installeraient Donc c'était vraiment beau dans la façon dont il n'était pas beau à cause des dégâts, mais vraiment beau dans la façon dont il a été conçu. Vous pouviez voir à quel point ces gars étaient intelligents , non ? Et que s'est-il passé ensuite ? Une société de sécurité, je crois que c'était Frey. Ils ont détecté ce malware qui se propageait aux clients et ont pu identifier le package de mise à jour Sunburst Ils ont identifié dans K que ce package Solvins avait été compromis, n'est-ce pas ? Et une fois détecté, ils ont immédiatement publié cette mise à jour, et plusieurs clients ont pu détecter le même comportement chez leur enami Ils ont donc réalisé à quel point le spread était mauvais, non ? Il avait infecté des milliers et des milliers de clients grâce à eux. Et Solns a publié correctifs rapides pour éliminer cette porte dérobée Mais, vous savez, je pense qu' environ 18 000 clients de Solar Vines ont appliqué la mise à jour Sunburst, qui a ensuite permis aux attaquants d' accéder à distance aux données de leurs clients Et, vous savez, je crois que le ministère américain de la Santé, le Trésor et l'État étaient tous infectés, de grands noms, vous savez, comme les grandes entreprises technologiques, tous étaient affectés par le malware. Tout cela tient au fait que la façon dont ils ont réussi à le diffuser a révélé l'angle mort lié à la confiance dans les mises à jour logicielles, et cela a vraiment incité non seulement les centrales solaires, mais aussi d'autres entreprises à se pencher sur le processus de reconstruction Si vous êtes une entreprise qui distribue des logiciels à d'autres entreprises, n'est-ce pas ? Et vous publiez automatiquement des mises à jour. Vous devez vraiment réfléchir à ce qui se passerait s'il y avait un malware dedans ? Comment m'assurer que cela ne m'arrive pas ? Et c'est là tout l'intérêt de cette étude de cas. Et c'est ce qui s'est passé par la suite. Beaucoup d' entreprises ont donc examiné leurs factures de logiciels, exemple, comment puis-je m'assurer que personne ne se faufile C'est là que le concept de versions reproductibles a commencé à apparaître, dont nous parlerons prochainement Mais je voulais juste vous montrer l'impact. Nous avons eu, par exemple, un gouvernement Biden , qui a publié un décret et amélioré la cybersécurité du pays. Vous pouvez voir la date du 12 mai 2021 et ils avaient une exigence spécifique sécurité de la chaîne d'approvisionnement logicielle. Ils ont dit avoir mentionné le fait que ce type de logiciel n'est pas transparent. Nous ne savons pas si des logiciels malveillants arrivent, et nous devons vraiment mettre en place des contrôles pour nous assurer que la sécurité de la chaîne d'approvisionnement logicielle est sécurisée, n'est-ce pas ? Et ce qui a le plus choqué, c'est la décision de Landmark, la Securities and Exchange Commission, SEC, a accusé le CSO des victoires solaires de fraude et défaillances du contrôle interne liées aux pratiques de cybersécurité de l'entreprise Ils ont dit qu'ils avaient acheté des frais parce que vous aviez mal indiqué dans quelle mesure Solar Wins était sûr Ils les ont donc achetés. Ils ont déclaré qu'il avait induit les investisseurs en erreur quant aux pratiques de cybersécurité de l'entreprise Il n'avait pas révélé les risques et le contrôle inadéquat. Donc, en gros, il avait surestimé leur niveau et il n'avait pas divulgué tous les risques Et cela a représenté un changement significatif dans la façon dont les gens perçoivent la cybersécurité. Maintenant, les OSC se rendent compte qu' elles sont réellement passibles, vous savez, non seulement d'amendes, mais aussi de peines d'emprisonnement Et va évaluer les organisations de la société civile ont vraiment dû prendre du recul. C'est pourquoi la sécurité de la chaîne d'approvisionnement logicielle est devenue si importante de nos jours. Et j'espère pouvoir vous faire comprendre quel point l'énergie solaire est importante. Maintenant, comment se protéger ? C'est une question de 1 000 000$, non ? Comment vous assurer que votre entreprise ne sera pas la prochaine gagnante, par exemple, dans le secteur de l'énergie solaire ? Malheureusement, de nombreuses bonnes pratiques classiques en matière de sécurité ne peuvent pas contrer ce type d'attaque. Par exemple, que disent les gens qui n'ont installé que des versions signées, vous savez, des mises à jour logicielles signées numériquement provenant de Solar Wins ? n'ont installé que des versions signées, vous savez, mises à jour logicielles signées numériquement provenant de Solar Wins Cela n'aidera pas car le logiciel est un signe. Cela vient de l'entreprise légitime. Ce n'est pas comme si un attaquant l'introduisait en douce. Cela vient d'une entreprise de confiance, non ? Mettez à jour votre logiciel la dernière version, comme le diront les gens, n'est-ce pas ? Parce que c' est le logiciel mis à jour qui était malveillant. Et cela faisait partie du processus de construction valide. C'est donc là le problème a commencé à se poser. Vous ne pouvez même pas dire de revoir le code source parce qu'il compromettait le processus de construction, n'est-ce pas ? L'une des principales choses que vous pouvez faire est donc, outre vos bonnes pratiques de sécurité, telles surveillance et le renforcement, n'est-ce pas, assurer que vous disposez de contrôles qui surveillent le comportement, les entreprises doivent vraiment renforcer leur processus de création contre ce type d'attaques, Et ils doivent s'assurer que l'environnement de construction ne peut pas être compromis. Ils ont veillé à ce que nous en parlions davantage lorsque nous parlerons de la sécurisation de la chaîne d'approvisionnement logicielle. Mais l'environnement de construction doit être sécurisé. Vous devez vous assurer que les utilisateurs ne peuvent pas simplement compromettre l'environnement et insérer leurs propres mises à jour malveillantes, et vous devez faire preuve de surveillance. Et les deux choses les plus importantes que vous puissiez faire sont vérifier les versions reproductibles et les nomenclatures logicielles Je vais entrer dans les détails de leurs nomenclatures logicielles , mais la contre-mesure la plus efficace que vous puissiez avoir est appelée une version reproductible, c'est-à-dire une version qui produit toujours les mêmes résultats afin que les résultats de construction puissent être vérifiés Donc, en gros, version reproductible vérifiée est endroit où une personne indépendante peut produire une version à partir du code source et vérifier que les résultats de la construction proviennent du même code source que vous revendiquez Presque, je dirais que 99 % des logiciels actuels ne sont pas comme ça. Mais dans le cas des vents solaires, que se serait-il passé ? Par exemple, comment se produirait une construction reproductible vérifiée ? Rien qu'à partir du nom que vous pouvez voir, vous pouvez le vérifier et le reproduire. Donc, si vous avez accès à la fois au code source et au build. À quoi servent les factures reproductibles vérifiées ? Ils vous offrent essentiellement une contre-mesure très, très puissante contre les attaques telles que les attaques solaires où les binaires ne correspondent pas au code source Pourquoi ? Parce qu'un attaquant a inséré du code malveillant dans un binaire, n'est-ce pas ? Parce que dans le cas des veines solaires, elles attaquent le binaire, pas le code source. L'un des avantages des builds reproductibles est donc que lorsque ces deux versions se produisent, vous pouvez les créer indépendamment, et les deux produiront le même artefact petit à petit Et cela vous donnera l'assurance qu' aucun logiciel malveillant n'y a été injecté. Et c'est là toute la motivation de ce concept. Et si Solar Wins avait mis en place des factures reproductibles, il aurait fallu générer un bon binaire à partir de la source et le comparer au binaire distribué Et ça ne correspondrait pas, non ? Cet écart aurait donc été introduit par l'insertion du code malveillant, et il aurait été détecté car lors de la distribution du binaire, il ne correspondrait pas à la version reproductible vérifiée Et cela aurait pu alerter les développeurs de la présence de modifications non autorisées indiquant que le processus de construction a été compromis. Il y a quelque chose de plus ajouté au binaire, qui n' existait pas auparavant. Est-ce que c'est infaillible, à 100 % ? Absolument pas. Parce que souvenez-vous, les attaquants étaient déjà dans l' environnement, n'est-ce pas ? Vous avez donc également besoin d'autres contrôles de sécurité. Mais ce type de version vérifiée et reproductible vous donne un contrôle très, très fort contre elle Je vais également mettre le lien vers l' ensemble du site Web qui prétend ce type de contrôle Mais n'oubliez pas que si vous distribuez des mises à jour à des milliers de clients et que vous avez besoin de ce type de vérification, la ceinture reproductible vérifiée constitue un contrôle très, très strict à cet égard J'espère donc que cela vous a été utile. Nous avons pris du recul et nous avons examiné attentivement l'attaque des vents solaires. Maintenant, allons-nous examiner une autre attaque et voir comment elle s'est produite  ? Il s'agissait d'un type d'attaque différent de celui des vents solaires. Mais juste pour vous donner plus de contexte sur la façon dont ces attaques se produisent, merci, et je vous verrai dans la prochaine leçon. 8. Codecov: C'est plutôt Bonjour, tout le monde. Bienvenue dans cette leçon. Et maintenant, nous poursuivons le précédent où nous avons examiné les vents solaires. Nous allons maintenant passer à une autre récente, Dov Attack Maintenant, les vents solaires, si vous vous en souvenez, compromettent le processus de construction, n'est-ce pas ? Les attaquants ont réussi à compromettre le processus de création et à injecter des logiciels malveillants. Avec celui-ci, il s'agit davantage du pipeline du CICD. Si vous ne connaissez pas Codkov, j'espère que je prononcerai le nom s' ils ne s'énervent pas Mais oui, c'est un outil de couverture de code. Qu'est-ce que cela signifie ? En gros, pour vérifier quelle partie de votre application est testée, vous savez ? Par exemple, lorsque vous créez des applications modernes lorsque nous utilisons le CICE, nous utilisons des tests automatisés, n'est-ce pas ? Nous en avons déjà parlé. Et nous voulons nous assurer que chaque ligne de code a été testée correctement, ainsi que chaque FOG, ce qui nécessite un framework de test mature. C'est là qu'intervient Cod Cov, qui peut vous aider à savoir quelles lignes de code ne sont pas couvertes dans votre environnement CI Et c'est ainsi qu'ils font des compromis : ils compromettent celui-ci, ce qui leur a permis de compromettre également d'autres environnements. Maintenant, si vous vous souvenez du vent solaire, Solar Wins était plus ciblé et était destiné à l'espionnage contre les agences gouvernementales et les grandes entreprises, n'est-ce pas ? Avait un motif géopolitique clair, comme une attaque d'un État-nation. Il s'agit plutôt d'une faille de sécurité généralisée qui a touché un large éventail d' entreprises sans discrimination Ils se fichaient de savoir qui était compromis. Et ils se concentraient sur le vol d'informations dans les environnements de développement de Soffe Oh, c'est ce dont nous parlons maintenant. L'attaque Code Cv, elle a été découverte en avril 2021, si je me souviens bien. Oui, c'était comme une immense plage sécurisée. Comme je l'ai dit, il s'agit d'un outil de couverture de code très populaire utilisé par les développeurs de logiciels pour évaluer l'efficacité de leurs tests. Et il s'intègre à divers systèmes de contrôle des vierges. Il génère des rapports pour vous indiquer dans quelle mesure les tests logiciels couvrent votre base de code, n'est-ce pas ? Donc, en gros, les attaquants ont obtenu un accès non autorisé aux systèmes Code CoF Comment ils ont exploité notre vulnérabilité. Je pense que dans leur création d'image Docker, nous n'avons pas besoin de connaître les spécificités de Docker et de tout Mais en gros, ils ont modifié le script de téléchargement de Bash. Je vais voir les détails à ce sujet. Ce qui leur a permis de le faire leur a permis d'exporter secrètement des informations sensibles provenant des clients de Cod C, n'est-ce pas ? À partir de là, en particulier à partir des environnements CI, des environnements d'intégration continue. Et quelles sont ces informations, informations d'identification, ID utilisateur, mots passe, clés de connexion et autres données qu' ils pourraient utiliser pour accorder un accès supplémentaire et non autorisé. Il est passé inaperçu pendant plusieurs mois, je crois, du 31 janvier 2021 à avril 2021. Et tous ceux qui ont téléchargé le script de téléchargement Bash compromis ont en fait dévoilé leurs informations sans le savoir Je pense que cela a touché environ 29 000 clients, grands noms du secteur, vous savez ? Et encore une fois, comme d'habitude, tout le monde a pris conscience des attaques contre la chaîne d'approvisionnement. Désolé, et tout le monde a pris conscience des attaques contre la chaîne d'approvisionnement, et ils ont soudainement réalisé quel point ces choses étaient critiques. Kotov a informé les utilisateurs concernés ont révoqué et délivré les clés et tout le reste, et ils ont accepté de faire auditer leur environnement Mais si vous y jetez un œil, c'est à cela que cela ressemblait en gros, non ? Concentrons-nous donc sur l'environnement CI, si vous vous souvenez de l'environnement CI, savoir un environnement d'intégration continue. Nous pouvons faire beaucoup d'automatisation puissante ici pour tester notre application, n'est-ce pas ? Et vous comptez également sur beaucoup de facteurs extérieurs, n'est-ce pas ? Bases de données, systèmes de paiement, infrastructure cloud. Lorsque vous effectuez les tests, tous ces composants doivent être accessibles depuis le pipeline afin qu'ils puissent créer et tester l'application. Donc, en gros, votre pipeline CI doit avoir accès à quels secrets et informations d'identification pour qu'ils puissent y accéder. Et en général, j'espère que si vous créez un environnement CI, vous devez utiliser une infrastructure intermédiaire , et non un octet de production, mais d'après ma propre expérience, il est très courant d'utiliser des informations d'identification de production parce que les utilisateurs veulent s'assurer qu'ils font les tests correctement et que les tests couvrent autant que possible. Malheureusement, cette information peut souvent se produire. Il est donc très probable que l'environnement CI ait accès à des informations très sensibles. Donc en attaquant Kotkov et c'est ce qu'ils ont fait, non ? Ils ont infecté le malware, ils ont compromis l'outil de test. Ils ont accès à toutes les informations d'identification. Dans l'environnement CI pour tous les clients de Cdf. Et en gros, si vous vous souvenez, ils ont compromis un script Bash, qui n'est qu'un ensemble d'instructions ce que vous écririez si vous aviez déjà utilisé un terminal ou Bash, mais écrites de manière programmative Ils ont ajouté une seule ligne de code, qui devait envoyer toutes leurs variables d' environnement du CI au serveur distant de l' attaquant. Vous comprenez qu'ils exfiltrent ces données en silence Et maintenant, vous pouvez comprendre s'ils ont environ 23 000 clients, tous ceux qui utilisaient la version compromise de Cod Cov entre le 31 janvier et le 1er avril auraient été concernés Et les grandes entreprises ont été touchées, et elles ont en fait publié essentiellement des documents leurs clients à leurs clients comment se remettre de cette attaque. Et ce qu'ils font, qu'ont-ils fait après l'avoir compromis Ils ne les ont donc pas attaqués directement. Ils auraient pu mener plusieurs attaques à partir de là, non ? Mais ce qu'ils ont fait, c'est qu'ils ont en fait compromis les dépôts du code source parce qu'ils avaient obtenu les informations d'identification, n'est-ce pas ? La source. Et ils ont ensuite pu accéder à leurs dépôts de code source. Et ils ont pu le trouver parce que ces dépôts pouvaient avoir en fait des informations de production. Vous pouvez donc voir comment cette attaque se déroule en cascade, n'est-ce pas ? Tout d'abord, ils ont compromis Kotkov. Ils ont obtenu les informations d'identification des dépôts de code source des clients. Ils ont compromis ces dépôts. Ils ont eu accès à la production. Et ils s'étaient même réveillés et avaient même remarqué des activités suspectes provenant d'autres centres de repos privés. Ils étaient clonés pour des utilisateurs non autorisés, et cela montre à quel point c'était simple, n'est-ce pas ? KotkVu compromis : utilisez des informations d'identification Git volées, accédez à des dépôts privés en utilisant ces informations d'identification volées, puis vous pouvez commencer à les scanner à la recherche Juste pour vous montrer à quel point cette attaque était simple et comment ils ont pu compromettre tant de clients qui l'utilisaient. Encore une fois, comme je l'ai mentionné, cela a eu un impact mondial. Un grand nombre de clients changeaient leurs secrets, leurs dépôts de code source et les attaquants pouvaient accéder à des dépôts non autorisés, et ils contenaient malheureusement le code source et les informations internes Encore une fois, vous avez maintenant une meilleure idée de ce qui peut être fait. Bien entendu, c'est différent des vents solaires, ont compromis l'environnement du bâtiment. Mais là encore, il faut renforcer la sécurité de l'environnement. Je ne saurais trop insister, vous devez vous assurer que votre environnement est sécurisé Gardez vos dépôts de code source propres. N' y mettez pas d'informations d'identification dans votre sommeil. Si quelqu'un est capable de les compromettre, il peut s'en servir comme point de départ dans votre environnement, n'est-ce pas ? Intégrez la filtration des données et le contrôle des fuites. Comment savoir si quelqu'un divulgue silencieusement des données à grande échelle Vous pouvez même renforcer vos dépôts de code source grâce à l'authentification multifactorielle et à la liste blanche d'adresses IP Donc, si vous savez que les demandes ne proviennent que d'une zone particulière, vous pouvez réellement imposer des restrictions IP, n'est-ce pas ? Ainsi, même s'ils ont les informations d'identification, ils ne pourront pas y accéder. de la sécurité des pipelines CICD, en veillant à ce qu'ils n'aient que l'accès nécessaire Vous ne voulez pas leur donner des informations d'administration pour l' ensemble de l'environnement, n'est-ce pas ? Et bien sûr, en évitant les informations d'identification codées en dur. Il s'agissait donc, encore une fois, d' une autre étude clé, un autre environnement qui avait été compromis à la suite d'une attaque de la chaîne d'approvisionnement, et j'espère que vous avez vu une situation différente maintenant. J'ai délibérément choisi celui-ci parce qu'il est différent de la façon dont les systèmes solaires ont été compromis. Vous avez maintenant une bonne idée, et j'espère que vous avez préparé le terrain pour comprendre comment nous pouvons nous y prendre pour la sécuriser. Vous avez une bonne idée des risques, et dans le contexte d'attaques réelles, vous voyez comment ces risques se matérialisent Nous pouvons donc maintenant passer à la leçon suivante, qui porte sur la sécurisation effective de la chaîne d'approvisionnement logicielle. Nous pouvons maintenant passer à l'aspect positif, qui consiste à sécuriser et à atténuer ces risques Merci beaucoup, je vous verrai dans la prochaine leçon. 9. Crowdstrike: Bonjour, tout le monde. Bienvenue. Bienvenue dans cette nouvelle leçon que je viens de mettre en ligne concernant la panne de CrowdStrike Donc, sauf si je veux dire, si vous n'utilisez pas l'informatique ou si vous n'utilisez aucun système, vous avez sûrement entendu parler de la panne de CrowdStrike, survenue cette année en 2024 Cloud Strike est une entreprise de solutions de sécurité très, très populaire. Je veux dire, ils proposent leurs produits exclusivement aux entreprises et aux grandes organisations. Ils sont très, très connus dans le monde de la cybersécurité. Malheureusement, ils deviennent comme un nom familier. Maintenant, tout le monde les connaît à cause de cet incident. En gros, même s'il ne s'agit pas d'un incident de cybersécurité au sens où personne ne l'a compromis , mais cela a eu un impact énorme sur la chaîne d'approvisionnement. Et c'est très important. Je ne pourrais pas parler de la chaîne d'approvisionnement logicielle ou risques liés à la sécurité de la chaîne d'approvisionnement sans évoquer Cloud Strike. Maintenant, si vous ne connaissez pas CoudStrike, ils ont essentiellement un composant appelé le faucon CrowdStrike. C'est comme un capteur. Elle utilise l'IA pour protéger les environnements des clients, vous savez, en identifiant les dernières menaces et en les protégeant contre celles-ci. En bref, en 2024, ils ont introduit une nouvelle mise à jour, c'est vrai, que ils ont introduit une nouvelle mise à jour, c'est vrai, le nouveau capteur n' était pas en mesure de gérer et il est tombé en panne Et étant donné la proximité du capteur CrowdStrike rapport au système d'exploitation Windows, cela a provoqué le crash de tous les systèmes et une panne mondiale massive qui a touché presque tous les secteurs du Des millions et des millions de terminaux ont été touchés, n'est-ce pas ? Et cela a été considéré comme la plus grande perturbation de l'identification de tous les temps ou comme l'une des plus importantes, je pense que c'est simplement à cause de la nature et de la façon dont cela s'est produit. Je vous ai déjà parlé de Rodseg, une entreprise de solutions de sécurité très, très populaire Des millions d'entreprises l'ont utilisé , et c'est une bonne entreprise. Malheureusement, le nom a été un peu traîné dans la boue à cause de cet incident Mais il ne fait aucun doute que c'est une très bonne entreprise, une entreprise de sécurité très, très mature. Mais malheureusement, la mise à jour logicielle défectueuse. J'ai mené à cet écran bleu de la mort. C'est comme une boucle sur les machines Windows qui les fait planter à plusieurs reprises. Et malgré les foules qui ont déployé le correctif, l'impact a été énorme dans le monde entier. Et comme je l'ai dit, littéralement, les aéroports , les ports, prenons un exemple, quel genre de choses se produisent. Les aéroports ont été touchés. Si vous étiez en voyage à un moment donné, vous avez toute ma sympathie. Vous verrez des images montrant, vous savez, à tous les niveaux, des aéroports bloqués, des milliers de vols retardés, des ports d' expédition touchés, des supermarchés, des hôpitaux, je vis au Royaume-Uni, et le NHS a envoyé une déclaration disant qu'il n'est pas en et le NHS a envoyé mesure de servir les clients à l'heure actuelle patients à cause de l' impact des sociétés d'identification, des bureaux gouvernementaux, etc. sur. Je veux dire, à travers le monde, des fermetures majeures, des retards se produisaient, des milliers de vols étaient comme un obstacle Et en gros, cela montre la nature interconnectée de la chaîne d'approvisionnement logicielle. Et même si c'est étonnant, cela ne ressemble pas à une attaque. C'était juste une erreur, mais cela a montré l'impact qui peut se produire, et ce n'est qu'un exemple. Je veux dire, je suis sûr que tu l' aurais vu, non ? Mais cela montre simplement à quel point les dépendances à travers le monde sont dangereuses à l'égard de ce type de logiciel, n'est-ce pas ? Donc, comme je l'ai dit, le monde entier, les hôpitaux , les entreprises australiennes ont dit avoir une facture de dommages d'environ 1 milliard de dollars, n'est-ce pas ? Et les banques, les médias, le NHS. L'impact à travers le monde a donc été incroyable. Mais il est très, très important de séparer les faits de l'hyperbole Et je n'aime pas la façon dont c'est souvent formulé Et comment les gens ont commencé à dire qu'il s'agissait d'une cyberattaque. Cela a eu un impact cybernétique sur la disponibilité, bien entendu, et cela ne ressemblait pas à une attaque commise par un criminel. Et ils ont publié un rapport sur les causes profondes, que vous pouvez consulter. Et ils ont mentionné comment cela s'est passé. En gros, le censeur. C'était comme s'attendre, je crois, environ 20 champs de saisie, mais la dernière mise à jour contenait 21 champs de saisie, et l'inadéquation du nombre est à l' origine d'un crash mondial Et comme l'interprète attendait 20 valeurs, et lorsqu'il a commencé à accéder à la 21e, il a produit une annonce de mémoire hors limites Tu sais, ces choses-là. Et comme il est étroitement intégré au code Windows, lorsqu'il est tombé en panne, il a fait tomber en panne l' ensemble du système d'exploitation, et l'écran bleu clignotait dans le monde entier, dans les supermarchés, les aéroports, partout où vous pouvez penser, il clignotait en gros comme si étroitement intégré au code Windows, lorsqu'il est tombé en panne, il a fait tomber en panne l' ensemble du système d'exploitation, et l'écran bleu clignotait dans le monde entier, dans les supermarchés, aéroports, partout où vous pouvez penser, cela se résumait à un manque de tests appropriés pour les mises à jour des Cela a contourné leurs nouveaux processus. Les tests n'ont pas été un obstacle. Et beaucoup de gens ont commencé à dire que cela pouvait désormais être exploité. Je vous recommande de lire les articles de blog de CrowdStrike dans lesquels ils ont réfuté les affirmations concernant le capteur de sécurité Falcon's Même s'il s'agissait d'un crash de mémoire hors limites, il a été déterminé qu'il n'était pas exploitable lors d'une précédente escalade ou d'une exécution de code à distance Et ils ont fourni une analyse détaillée des causes profondes selon laquelle même ce bogue n' autorisait aucune exécution de programme, et ils ont mentionné les autres contrôles dont ils disposaient, tels que l' épinglage des certificats, la validation des sommes de contrôle, le contrôle d' accès et la détection anti-falsification, n' Et ils ont indiqué que je vais lier le rapport ici, le blog ici, et je vous recommande vivement de le lire, car si vous voulez analyser ces situations, assurez-vous de l'analyser correctement et de ne pas y des choses qui n'existaient pas à l'époque. Et CoudStak a affirmé son engagement en faveur de la sécurité, et ils ont indiqué que leur programme Bug Bounty avait également été amélioré son engagement en faveur de la sécurité, et ils ont indiqué que leur programme Bug Bounty avait également été amélioré . Mais les leçons à tirer de cet incident sont très, très importantes. Donc, pour être très clair, attaquant, même s'il ne s' agissait pas d'une attaque, mais les attaquants tireront les leçons de cet incident. Ils ont vu à quel point l'impact de cette attaque a été dommageable . Vous pouvez donc imaginer que les attaquants se sont intéressés à cette attaque et qu'ils réfléchiront à la manière dont ils pourraient encore un impact plus important la prochaine fois et en tirer un peu d'argent. Si vous êtes un fournisseur de solutions. C'est comme CrowdStrike, vous fournissez un agent, un logiciel à l'entreprise C'est une bonne chose d' examiner vos processus de test. Pensez à ce type de résilience. Que se passe-t-il si votre terminal se trouve très près du noyau Windows et qu' il se passe quelque chose, n'est-ce pas ? Effectuez une phase de déploiement. N'adoptez pas une approche du Big Bang. Je n'arrive pas à croire que je doive dire ça, mais c'est juste. Il n'est pas nécessaire de procéder à un déploiement à grande échelle, le faire par étapes et faire réaliser des audits indépendants de l'ensemble de votre processus. CrowdStrike, je pense qu'ils font appel à deux entreprises distinctes pour effectuer une évaluation complète de leurs pratiques de développement logiciel, les tests étant simplement destinés à s'assurer qu'ils n'ont aucun angle mort. Et du point de vue du client, si vous utilisez un logiciel tel que RoudStrik Tout d'abord, je recommanderais de supprimer dépendance excessive Si vous avez un fournisseur qui fait tout et qu' il arrive quelque chose à ce fournisseur, vous allez avoir de gros problèmes, n'est-ce pas ? Réfléchissez à ce scénario et ajoutez-le à votre manuel de reprise après sinistre Mais je dois être très clair. Très peu de gens peuvent prévoir ce genre de scénario. C'était comme un incident avec Black Swan, non ? Comme quelque chose qui se produit une fois tous les deux ou trois décennies. Mais je vous recommande de penser à des choses comme les sauvegardes dans le cloud ou le fait d'avoir un bureau virtuel, qui est une image complètement distincte de vos bureaux habituels, n'est-ce pas ? Donc, si quelque chose se produit, s'il y a un cas majeur, vous serez en mesure revenir sur le poste de travail Cloud. Et c'est quelque chose qui est complètement coupé de votre réseau habituel Il n'a pas les mêmes agents. Il a différents agents. Cela peut coûter plus cher, mais dans un tel incident, vous serez en mesure de créer une image complètement séparée sur laquelle votre personnel pourra reprendre au moins des activités limitées, car de nombreuses entreprises ont été complètement coupées. Les serveurs étaient en panne, mais même les ordinateurs de bureau ordinaires sont en panne parce que Cloud Stoke fonctionnait partout, Pensez donc à avoir une autre image sur laquelle vous pouvez déployer et que vous pouvez lancer, qui est distincte de vos images normales et qui ne sera pas affectée par les mêmes problèmes. C'est donc ce dont je voulais parler à tout le monde, juste pour vous montrer, car CrowdSTK était comme un énorme incident Cela continue de se dérouler. Beaucoup de nouvelles vont être publiées. Mais pensez à ces incidents, en particulier lorsque vous songez à sécuriser la chaîne d'applications de votre logiciel. Merci beaucoup Je te verrai à la prochaine leçon. 10. Sécuriser la chaîne d'approvisionnement - 1: Bonjour, tout le monde. Bienvenue. Bienvenue dans cette leçon, qui fait partie d'une leçon en plusieurs parties, qui portera sur la sécurisation de la chaîne d'approvisionnement logicielle. Maintenant, j'espère que vous avez une bonne idée de ce qu'est la chaîne d'approvisionnement logicielle. Vous avez une bonne idée des risques qui peuvent survenir. Vous avez vu de véritables attaques et façon dont elles ont été compromises, n'est-ce pas ? Nous allons donc maintenant examiner la mise en œuvre de contrôles au sein de la chaîne d'approvisionnement logicielle. Nous allons examiner contrôles et les pratiques de sécurité, certaines des erreurs les plus courantes commises par les utilisateurs au début de leur chaîne d'approvisionnement logicielle ou de leur parcours en matière de sécurité. Ensuite, nous allons également examiner certaines normes et certains cadres, vous pouvez utiliser pour en tirer le meilleur parti. Lorsque vous élaborez un programme de sécurité de la chaîne d'approvisionnement, vous n'avez pas besoin de le créer à partir de zéro . Vous pouvez tirer parti de ce que vous avez déjà. Donc, si vous jetez un œil, c'est ce dont nous avons discuté plus tôt. Tu te souviens ? C'était l'environnement qui présentait les risques liés à un environnement de développement, qui pouvait être compromis. Vous avez un code non sécurisé, la plate-forme de construction est compromise, le dépôt du code source, les dépendances, vous ne pourriez pas tester la sécurité du Vous avez été victime d'une violation de données dans l'environnement de préproduction, et même votre environnement de production peut être compromis C'est donc là qu' intervient la sécurité de la chaîne d'approvisionnement logicielle pour protéger tous ces risques, n'est-ce pas ? Et si vous vous souvenez quand nous avons commencé le cours, avons parlé de la sécurité de la chaîne d'approvisionnement logicielle, n'est-ce pas ? Il s'agit essentiellement de garantir l'intégrité, la sécurité, la disponibilité et la fiabilité de tous les composants et processus concernés. Dans le cadre du développement, de la distribution et de la maintenance de logiciels. Vous voulez vous assurer que personne n' altère votre logiciel, que personne ne le modifie Et c'est très, très important lorsque nous parlons de chaîne d'approvisionnement, nous ne parlons pas seulement du code source direct, n'est-ce pas ? Nous parlons également de bibliothèques, d' outils et de services tiers , ainsi que de l' infrastructure, car je constate souvent ce n'est pas votre infrastructure qui fait des compromis. Ce sont les vendeurs ou les fournisseurs. Alors, comment vous assurer que votre programme de sécurité de la chaîne d'approvisionnement couvre tout ? C'est donc ce que vous devez garder à l'esprit. Et quelles sont malheureusement les erreurs les plus courantes que les gens commettent et qui me donnent toujours mal à la tête lorsque je parle à des clients, à savoir la sécurité de la chaîne d'approvisionnement. Qu'est-ce que ce n'est pas ? Il ne s'agit pas d'un outil ou d'un produit. prie. Toute personne qui vous dit qu'un fournisseur vient vous voir et vous dit «  Achetez mon produit » et que vous aurez la sécurité de la chaîne d'approvisionnement logicielle, est totalement faux Cela vous aidera. Cela vous aidera sans aucun doute, mais ce n'est pas le cas. Cela fait partie de la sécurité de la chaîne d'approvisionnement logicielle, non l'objectif final. OK ? Vous ne pouvez pas automatiquement devenir votre chaîne d'approvisionnement logicielle non sécurisée parce que vous avez acheté une solution pour des millions de dollars et que vous l'avez mise en œuvre. Il ne s'agit pas d'une certification. Tout le monde dit qu'il faut utiliser cette liste de contrôle ou ce truc, et maintenant votre chaîne d'approvisionnement est sécurisée Encore une fois, ce n'est pas ainsi que cela fonctionne. Il ne s'agit pas non plus d'une liste de contrôle des fournisseurs. Certaines personnes évaluent risques liés aux fournisseurs et pensent que leur chaîne d'approvisionnement en logiciels est désormais sécurisée. Et ce n'est pas non plus une activité ponctuelle. C'est quelque chose que vous devez continuellement évaluer les risques. Et c'est en dernier lieu que MyF active le MFA. Encore une fois, il n'y a rien de mal à activer le MFA. C'est un élément très important de la sécurité de l'approvisionnement en logiciels. Mais les gens pensent que c'est parce que nous avons activé MFA que notre environnement est désormais sécurisé Je ne sais pas comment cela se produit, mais s'il vous plaît, ne commettez pas cette erreur, n'est-ce pas ? Donc, comme je l'ai dit, pensez à la définition dont je vous ai parlé plus tôt, celle-ci, gardez-la à l'esprit et ne vous laissez pas tromper par ces idées fausses Et lorsque nous parlons sécurisation de la chaîne d'approvisionnement logicielle, nous parlons de multiples contrôles, n'est-ce pas ? Et c'est sur cela que je vais me concentrer dans ces leçons. Nous allons parler des pratiques de codage sécurisé, de ce que vous pouvez faire, des composants tiers, du renforcement de votre environnement, sécurité du pipeline CICD, tests et des scans de sécurité réels, versions logicielles du matériel, de L BOM, si vous ne le connaissez pas, et, bien sûr, de la gestion des fournisseurs occidentaux Tous ces éléments sont réunis pour une sécurité efficace de la chaîne d'approvisionnement logicielle, puis nous verrons également comment créer un véritable programme. Je vais donc aborder tous ces points. Je ne vais pas vous bombarder d'informations. Nous allons procéder étape par étape à la création de votre environnement, n'est-ce pas ? Donc, à la fin, votre environnement ressemblera à ceci. Vous allez avoir des contrôles à plusieurs niveaux, puis vous allez avoir un programme approprié en cours d'exécution, qui garantit que tous ces éléments sont pris en charge et que les risques sont évalués. Donc, comme je l'ai dit, nous allons le faire en un rien de temps. Je vous verrai dans la prochaine leçon, nous allons commencer à approfondir ces contrôles. Merci beaucoup, je vous verrai dans la prochaine leçon. 11. Sécuriser la chaîne d'approvisionnement - 2: Bonjour, tout le monde. Bienvenue Bon retour à la leçon. Et nous poursuivons notre leçon précédente où nous parlons de la sécurisation de la chaîne d'approvisionnement et des contrôles de sécurité, nous pouvons les mettre en œuvre. Donc, si vous vous souvenez bien, je vous ai montré ces contrôles de base savoir les pratiques de codage sécurisées, les composants tiers, les environnements de thésaurisation, les pipelines CICD, les pipelines CICD Nous allons tous y jeter un coup d' œil un par un. Alors allons-y. Et si vous vous souvenez, je vous ai également montré le schéma comme celui-ci si nous avions déjà vu les risques indiqués dans ce schéma, mais si vous insérez les contrôles, contrôles que vous voyez dans le schéma, ces risques sont atténués Commençons donc par le tout premier, qui est le codage sécurisé. Si vous vous souvenez, nous avons parlé des risques, n'est-ce pas ? Et j'ai dit que le code peu sûr est à l'origine de tous les maux Donc, le codage sécurisé, c'est pourquoi nous devons d'abord en discuter. codage sécurisé dans le contexte de sécurité de la chaîne d'approvisionnement fait référence aux développeurs qui développent logiciels de manière à ce que vous vous assuriez qu' aucune vulnérabilité n'est présente dans le code à aucun moment. D'accord ? Et cela nécessite des contrôles, à la fois de la sensibilisation et des contrôles techniques, n'est-ce pas ? Parce que n'oubliez pas que les vulnérabilités peuvent être introduites de plusieurs manières . Nous allons donc parler de la formation au code sécurisé et de la manière d'intégrer commentaires sur la sécurité dans l'identifiant lui-même, un élément essentiel qui est oublié par de nombreuses personnes. Nous allons parler de la manière dont les révisions de code sécurisé peuvent se faire. Et, bien sûr, les tests de sécurité du code soumis, le SAST et la poussière Si vous avez travaillé dans le domaine de la cybersécurité, je suis sûr que cela vous est familier. Commençons donc par l'apprentissage du code sécurisé. Sécurité La prise de conscience d'un code non sécurisé est un très, très, très bon début Vous devez informer vos développeurs du code non sécurisé et de ses dangers, n'est-ce pas ? Il existe de très nombreuses formations de qualité. Le top dix des systèmes d'exploitation est la référence du secteur. Je suis sûr que si vous travaillez dans le domaine de la cybersécurité, vous devez déjà en avoir entendu parler. Donc, les éduquer, leur parler de formations comme celle-ci, leur montrer, leur parler des insécurités, cela peut être, mais très, très important il vous plaît, ne le faites pas mourir avec PowerPoint, c'est-à-dire lorsque vous leur offrez un document PowerPoint de 200 pages. Croyez-moi, personne ne s'en souviendra. Montrez-leur, montrez-leur en fait des morceaux de code non sécurisés et montrez-leur quelles sont les vulnérabilités Montrez-leur que si vous le corrigez dans le code lui-même, combien de temps et d'efforts sont économisés par rapport au fait que quelqu'un le découvre plus tard pour le corriger et combien de temps cela est perdu, n'est-ce pas ? Il existe donc de très nombreuses formations de très bonne qualité sur le code non sécurisé, sur l'OVA, sur des sujets tels que l'injection SQL, les scripts intersites, les scripts intersites, etc. Alors sensibilisez-les. Mais sur un point très, très important, et c'est là que les gens passent à côté d'une occasion, vous devez commencer par la prise de conscience, mais assurez-vous de le faire, à savoir que les gens passent à côté d'une occasion, vous devez commencer par la prise de conscience, mais assurez-vous de le faire, et c'est là que les gens passent à côté d'une occasion, vous devez commencer par la prise de conscience, mais assurez-vous de le faire, à savoir intégrer les informations de sécurité dans l'identifiant. intégrer les informations de sécurité dans l'identifiant. L'ID est l'environnement de développement intégré. Et par là, je veux dire, le codage qu'ils font, ils devraient être en mesure d'obtenir des commentaires sur place. D'accord ? Vous pouvez donner autant de formations que vous le souhaitez Les développeurs ont besoin d'un moyen d'obtenir des commentaires en temps réel. D'accord ? Lorsqu'ils développent le code, comment leur faire savoir que le code n'est pas sécurisé, n'est-ce pas ? Quels sont les problèmes actuels ? Et c'est le moyen le plus simple et le plus fluide de sécuriser Croyez-moi, vous n'avez pas besoin de faire tests de sécurité plus tard si le développeur le sait tout de suite, s'il fait un scan rapide et voit, regardez, ce ne sont pas des solutions sûres Peut-être que le code que j'ai écrit n'est pas sécurisé, je dois le réparer. C'est le moyen le plus simple, et si vous le faites correctement, vous constaterez une augmentation massive de votre code de sécurité. D'accord ? Donc, si vous prenez un exemple, si vous vous souvenez que je vous l'ai montré très tôt, comme s'il s'agissait d'un code qui ne nettoie pas, l'entrée est prise, et bien sûr, cela peut mener à des choses comme l'injection de SQL où les utilisateurs peuvent accéder à vos bases de données principales, vos systèmes d'exploitation, à vos fichiers, si vous ne le nettoyez pas Voici un exemple d'IDE, comme le code Visual Studio, dans lequel les utilisateurs tapent correctement. Et c'est un outil, que vous appelez code whisperer, c'est-à-dire A. Vous pouvez utiliser n'importe quel outil. Je n' aime pas mentionner des outils spécifiques, d'ailleurs. Mais si vous regardez la capture d'écran, c'est donc le code, le même code que je vous ai montré, si je le mets ici et que je lance un scan de sécurité, tout de suite, il me dira, regardez qu'il y a une injection SeQL, et il m'indiquera également la ligne Vous voyez à quel point c' est puissant si vous le faites correctement. Vous pouvez donc dire tout de suite le développeur saura, écoutez, j'introduis une faille de sécurité dans le code. Je dois résoudre ce problème avant de le soumettre au dépôt. Et cela améliorera considérablement la qualité de votre code de sécurité. Encore une fois, si vous vous souvenez, je vous ai montré celui-ci, l'attentat à la bombe zip au cours duquel des personnes envoyaient un fichier susceptible d'être décompressé en une énorme quantité de données en Go et le fait que le serveur soit en panne provoque un déni Donc, si vous le faites, encore une fois, vous verrez immédiatement, cela vous donnera des commentaires, téléchargement illimité d'un fichier dangereux, appuyez sur le bouton que vous pouvez voir en bas et le lien vers la ressource C'est donc un moyen très, très puissant. Je vous ai montré un exemple de code avec Spur, mais vous pouvez utiliser de nombreux outils qui s'intègrent dans l'IDE lui-même et donnent au développeur un feedback en temps réel. À propos du type de code qu'ils soumettent et des raisons pour lesquelles il n'est pas sécurisé Alors, s'il vous plaît, regardez ça. Ne commettez pas l'erreur que font 90 % des gens, qu'ils forment les développeurs au code de sécurité et qu'ils s'attendent à ce qu'ils trouvent tout. Non, ça ne va pas fonctionner comme ça, donnez-leur des outils qui leur donnent un feedback en temps réel. Ensuite, nous parlerons de tests. Maintenant, si vous vous souvenez, nous avons parlé de tests, cela passe par le pipeline du CSED, puis par les tests de qualité C'est ici que vous pouvez présenter vos différents types de tests de sécurité pour le code. Le premier est le test statique de sécurité des applications ou SAS. Il s'agit d'une méthodologie de test qui examine votre code source. Il n'exécute pas le programme, et il est généralement exécuté à un stade précoce de la phase de codage elle-même. Il vous le fera savoir. Il examine donc le code source et découvre, hé, introduisez-vous des failles de sécurité ? Vous pouvez intégrer les outils dans le pipeline CICD et celui-ci effectue une analyse très approfondie de votre base de code Il examine le code car il descend jusqu' au niveau du code. Le second est le DAST, qui est une méthodologie de test en boîte noire, ce qui signifie que le code n'a aucun accès Il ne regarde pas le code source, mais il s'exécute réellement Donc, lors de son exécution, le programme est en cours d'exécution. En fait, je simule des attaques externes telles que l'injection SQL, et cela est effectué ultérieurement dans le pipeline CICD Habituellement, lorsque votre logiciel est en préproduction ou en environnement de préparation, Cela ressemble donc aux pages Web et aux API, et il essaie de les exploiter. Donc, les deux boosters sont utilisés ensemble. Personne n' essaie de dire que SASPTO est DAS B SAS et DAS se complètent DAST identifie les vulnérabilités sous un angle différent, tandis que SAS examine le Ils se complètent donc. Idéalement, vous devriez les examiner tous les deux. Et comment s'assemblent-ils ? Donc, si vous regardez à gauche, vous avez l'identifiant dans lequel vous donnez une formation aux développeurs, et vous y inscrivez des commentaires. Ils écrivent donc du code sécurisé. Une fois qu'ils ont soumis le code, il passe dans le pipeline CI. Il effectue des tests, des rapports, constructions et le SAST intervient Cela ressemble donc au code source. Si le code n'est pas sécurisé, il est renvoyé au développeur. Corrigez ceci s'il vous plaît. S'il passe, donc s' il transmet l'ID, il passe le SAS, il est dirigé vers le pipeline de CD où se trouve la production de révision Dans la mise en scène, les jours passent. C'est un exemple très simpliste, mais c' est un outil très, très puissant Ainsi, si vous répartissez la sécurité tout au long de votre cycle de vie, vous obtiendrez certainement une meilleure qualité de code au sein de votre application. C'était donc le SAST et la poussière. Je voudrais en venir à l'autre exemple, qui est, encore une fois, l'un des exemples les plus cruciaux. Je pense que c'est la chose à laquelle les gens pensent le plus lorsqu'ils parlent de sécurité de la chaîne d'approvisionnement logicielle , à savoir les composants tiers ou la dépendance. Nous avons parlé des bibliothèques, non ? Les bibliothèques parce que personne ne crée d'applications à partir de zéro. Vous allez vous fier à des bibliothèques, des bibliothèques comme Log FoJ, mais vous avez été compromises, n'est-ce pas ? Toutes ces bibliothèques peuvent donc introduire des vulnérabilités, des composants tiers, et elles constituent un énorme angle mort. Alors, que faites-vous ici ? Vous utilisez ce on appelle l'analyse de composition logicielle. Donc, il examine vos dépendances. Quelles sont les dépendances ? Quelles sont les bibliothèques de logiciels, et il identifie réellement les risques de sécurité existants. Tout comme SAST ressemble au code source. Celle-ci ressemble à vos bibliothèques tierces et indique aux développeurs : « Hé, votre composant est vulnérable et il peut en fait l'utiliser manière continue pour savoir si une vulnérabilité est due au fait qu' il n'est pas statique, n'est-ce pas ? Il est possible qu'un composant soit sécurisé et qu'il le devienne demain Donc, l'analyse de la composition du logiciel SCS surveille complètement et ressemble à ce qui se passe Voici donc un exemple tiré de la CISA s'agit d'un site Web du gouvernement, et il contient une très bonne publication . Je vais le relier à un lien sur la sécurisation de la chaîne d'approvisionnement logicielle pour les développeurs Et ils donnent cette recommandation. Donc, dans le pipeline, le développeur sélectionne peut-être un composant à télécharger, n'est-ce pas ? Je ne sais pas, la bibliothèque Log four j. Le composant est donc placé dans un référentiel sécurisé intermédiaire où se trouve l'analyse de la composition logicielle. Il le scannera donc et vous indiquera que, d' accord, c'est sécurisé. n'y a aucun problème et il le déplacera vers le référentiel sécurisé. À partir de là, le développeur peut désormais se connecter, enregistrer et commencer à l'utiliser dans le code. Ou à moins qu'il ne trouve un problème, il revient en arrière. C'est donc une très bonne façon de voir le fonctionnement de la composition et de l'analyse des logiciels. Et si vous l'examinez à nouveau dans le pipeline, c' dans l'identifiant, vous avez un code et des commentaires sécurisés, et vous pouvez également y mettre la composition du logiciel et le flux RSS. Ainsi, lorsque le développeur enregistre une bibliothèque, la composition logicielle Ss intervient et lui indique n'est pas sécurisée ou qu'elle fait également partie du pipeline CI Ainsi, lorsque le SAST se produit, SAS peut s'intégrer à l'analyse de la composition logicielle et vous indiquer, écoutez, le code est sécurisé, mais que vous utilisez une bibliothèque non sécurisée. Et enfin, DAST. Ainsi, lorsque vous utilisez le DAS, vous pouvez également surveiller les bibliothèques présentes, et il peut vous indiquer quels sont et il peut vous indiquer les problèmes rencontrés dans le logiciel en cours d'exécution. s'agissait donc que d'une vue d'ensemble de la toute première partie , à savoir le code non sécurisé et la manière de le sécuriser Donc, maintenant, j'espère que vous avez une bien meilleure idée des contrôles que vous pouvez mettre en place pour sécuriser votre code source. Bon, maintenant, nous allons examiner le renforcement de l'environnement, la manière dont nous renforçons les rapports sur le code source, les serveurs de facturation, les serveurs paquets, et nous allons l'examiner à un niveau supérieur et voir en quoi il complète du code source des logiciels Merci beaucoup, et je vous le demanderai lors de la prochaine leçon. 12. Sécuriser la chaîne d'approvisionnement - 3: Bonjour. Bonjour, tout le monde. Bienvenue, bienvenue. Nous poursuivons notre leçon maintenant. Nous avons abordé le codage, le codage sécurisé blanc, pourquoi c' est important et comment le sécuriser. Et nous avons également parlé de dépendances avec des tiers, n'est-ce pas ? Nous allons donc continuer dans ce cas, et maintenant nous allons parler des environnements. Si vous vous souvenez, nous avons parlé de l'environnement de développement, de l'environnement de pré-production. Et nous allons parler des composants présents dans cette leçon. Donc, tout d'abord, vous savez, fournir des outils pratiques, faire en sorte que les développeurs soient en mesure de faire ce qu'ils veulent C'est l'un des plus grands défis, vous savez, en matière de cybersécurité, car si vous ne leur donnez pas aux développeurs ce dont ils ont besoin pour faire leur travail, développeurs sont très doués sur le plan technique Ils trouveront des façons peu sûres de faire leur travail. C'est donc là que la cybersécurité a toujours été un défi, n'est-ce pas ? Prenons un exemple. Les entreprises et les équipes de cybersécurité ne veulent généralement pas que le personnel exécute du code sur leurs postes de travail ou leurs ordinateurs portables, pour des raisons évidentes Pourtant, les développeurs en ont besoin. Ils doivent être en mesure d'installer outils essentiels et de tester efficacement leurs logiciels. C'est là que vous devez faire preuve de flexibilité, dans l'environnement des développeurs. Et comme je l'ai dit, les développeurs sont très férus de technologie. Si vous ne leur donnez pas ce qu'ils veulent, ils trouveront probablement des moyens de contourner obstacles qui les empêchent de travailler, ce qui créera un environnement peu sûr C'est pourquoi vous devez penser à donner aux développeurs la capacité de faire ce qu'ils doivent faire. Il existe donc de nombreuses façons de le faire. Vous pouvez en fait segmenter le réseau de développeurs. Vous pouvez donc le mettre sur un réseau séparé, non ? Je connais des personnes qui ont complètement installé leur environnement de développement dans le cloud et l'ont séparé du réseau de production La seule chose qui les combine est un dépôt. Mais ils ont tous les droits, car ils savent que même s' il y a un problème, c'est dans le cloud, complètement séparé de leur réseau de production C'est donc à cela que vous devez réfléchir. Si un attaquant le compromet, que va-t-il se passer ? Ainsi, une fois qu'un attaquant le compromet, il peut potentiellement injecter du noyau malveillant et exploiter les appareils compromis Il existe donc de nombreuses façons de le faire. Comme je l'ai dit, vous pouvez séparer votre environnement commercial de votre environnement de développement, isoler vos développeurs du cœur de métier. Assurez-vous donc qu'ils n'ont accès à aucune fonction commerciale critique et réfléchissez aux moyens de sécuriser votre environnement de développement. Vous mettez en place une authentification multifactorielle donnez-leur des éléments tels que le VDI, qui leur donne un Cela leur donne donc la possibilité de faire ce qu'ils veulent, mais ils sont limités. Ils sont placés dans un bac à sable particulier. Ce sont donc les points auxquels vous devez vraiment penser lorsque vous renforcez vos environnements, n'est-ce pas ? Comment isoler vos développeurs de vos environnements de production. Et, bien sûr, vous avez également des environnements de préproduction . Ils ont des données. Assurez-vous de l'anonymiser. Vous le désinfectez du mieux possible. Contrairement aux idées reçues, vous n'avez pas besoin de toutes les données qui s'y trouvent. Vous en avez juste besoin pour simuler une production à l'échelle de la production, mais vous n'en aurez peut-être pas besoin de toutes Par exemple, les données d'une vache ou les données d'identification personnelle, vous pouvez potentiellement les assainir Alors pensez à ces choses. Vous devez disposer d'une surveillance de sécurité. J'ai parlé de l'anonymisation des données. Voici donc les moyens par lesquels vous pouvez renforcer votre environnement de développement et votre environnement de production P. Et nous avons parlé de durcissement. L'un des principaux éléments à prendre en compte est la sécurité de vos dépôts de code source, votre serveur de build, de votre serveur de paquets. Toutes ces choses viennent à l'esprit, que vous ayez un pipeline CICD DevOps ou simplement Allons-y donc étape par étape. Tout d'abord, c'est votre dépôt de code. Si vous vous souvenez, c'est là que vous avez mis tout votre code, oui. C'est là que vos développeurs placent le code et renforcent l'accès au Reaper Vous pouvez penser à des choses comme l' authentification multifactorielle Êtes-vous en train de vérifier qui a accès au dépôt et qui sécurise l' infrastructure sous-jacente ? Si c'est sur site et que quelqu'un peut pirater le serveur lui-même, alors vous ne pouvez pas vraiment vous fier au code, qui se trouvera au-dessus de tout, n'est-ce Et appliquez toujours ce principe du privilège de location. Vous n'allez pas croire le nombre d'entreprises que je connais qui vérifient l'accès à leurs applications, mais oublient complètement les introductions Cela leur manque complètement. Donc, accès des utilisateurs aux dépôts, réfléchissez à la façon dont vous vous êtes authentifié. Existe-t-il une bonne politique en matière de mots de passe ? Appliquez-vous des éléments tels que l'authentification multifactorielle ? Est-ce que vous le limitez aux adresses IP ? Comme nous avons parlé du problème du Cod Cv, non ? Cela aurait pu être le cas si les adresses IP avaient été détruites, car même si elles avaient compromis votre dépôt, elles n'auraient pas pu y accéder Et, bien sûr, l'une des choses les plus dangereuses, veuillez continuer à le scanner. Gardez toujours vos informations d'identification et votre code source séparés. Savez-vous si vos développeurs ont codé en dur des informations d'identification dans votre EPO, séparant logiquement du code source Et en s'assurant qu' ils sont scannés. C'est l'une des choses les plus élémentaires. À ce jour, je peux vous garantir que de nombreuses entreprises ont des informations d'identification codées en dur dans leurs dépôts et qu'elles n'en sont pas conscientes. Alors, tu as ce plan ? Avez-vous une sorte de plan de réponse aux incidents si vous le découvrez, n'est-ce pas ? Ce sont toutes les choses auxquelles vous devez penser lorsque vous parlez de votre dépôt de code Si le dépôt de code avait été sécurisé, des attaques telles que Cod COV auraient pu être bloquées OK, le suivant est le pipeline de construction, non ? Nous en avons parlé une fois que le développeur a validé quelque chose dans le code, le dépôt. C'est là qu'intervient votre pipeline de construction. Cela peut faire partie du pipeline CSCD. Vous devez absolument le sécuriser , car c'est l'une des cibles les plus importantes Nous avons déjà vu cela se produire dans le domaine des éoliennes, n'est-ce pas ? Que fait un attaquant ? Il infiltre un réseau de développement. Il analyse pour découvrir où se trouvent les dépôts du code source, où se trouvent les systèmes construits et où se trouvent les vulnérabilités. Il le compromet Maintenant, il est capable de compromettre le code en cours de validation, et vous pouvez compromettre les fichiers binaires, n'est-ce pas ? Si vous souhaitez garantir l'intégrité de votre code et des artefacts de construction, vous devez vous assurer que votre version est renforcée. Et n'oubliez pas que les fils de construction constituent l'une des menaces les plus dangereuses qui puissent exister, comme en témoigne l'environnement des vents solaires. Alors, que pouvons-nous faire ? Donc, tout d'abord, suivez les directives de durcissement. La plupart des outils de construction disponibles contiennent tous les meilleures pratiques de renforcement que vous pouvez suivre Séparez votre développement, votre réseau d'ingénierie du réseau coopit Nous en avons déjà parlé. Surveillez-vous votre environnement de construction ? ? Y a-t-il des choses comme une authentification multifactorielle Pourquoi ? Auditez-vous les comptes auxquels ils ont accès ? Parce que n'oubliez pas que le serveur de build, s'il déploie automatiquement du code dans différents environnements, aura besoin d'un accès. Comment savez-vous que ces comptes n' ont pas été compromis, n'est-ce pas ? Assurez-vous que vous enregistrez tous les accès. Et nous avons également parlé des versions reproductibles vérifiées , n'est-ce pas ? Donc, des versions que vous pouvez construire sur des environnements distincts, et elles seront toujours les mêmes. Cela vous donne l' assurance que personne n'a altéré une construction comme l'énergie solaire Et en veillant à ce vos secrets et vos informations d'identification soient sécurisés. Il s'agit donc d'une liste de contrôle complète que vous pouvez utiliser pour commencer à sécuriser vos environnements bâtis. Ce sont donc les serveurs de construction. Qu'est-ce que le serveur de packages ? Si vous vous en souvenez, lorsque vous mettez des éléments dans le code source, ils vont sur le serveur de compilation, et de là, ils vont dans le package. Maintenant, le serveur de packages est endroit où votre logiciel est déployé, n'est-ce pas ? Vos progiciels. Et compromission du référentiel de packages. Cela peut constituer une menace importante pour votre chaîne d'approvisionnement en logiciels. Nous en avons parlé tout à l'heure. Si les attaquants parviennent à le compromettre, ils peuvent potentiellement y introduire du code malveillant, n'est-ce pas ? Encore une fois, renforcer le MFA en utilisant des signatures cryptographiques . Qu'est-ce que c'est ? Vous voulez vous assurer de l' intégrité de vos progiciels. Ainsi, si ce package est altéré ou altéré, votre signature cryptographique entrera en jeu Parce que l'emballage aura une empreinte numérique unique, n'est-ce pas ? Et nous pouvons vérifier que personne n'a falsifié. Encore une fois, vous pouvez vous assurer que vous utilisez des canaux sécurisés, assurant que le HDDPS, SFTP ou même des VPN sont utilisés pour vous assurer que les packages sont cryptés en transit afin de vérifier l'intégrité des en vous assurant que le HDDPS, le SFTP ou même des VPN sont utilisés pour vous assurer que les packages sont cryptés en transit afin de vérifier l'intégrité des packages logiciels avant leur distribution. Vous voulez donc comparer la signature cryptographique actuelle de votre package à la signature originale pour vous assurer que personne ne l' a falsifiée, est-ce pas ? Et contre le fait de le signer. Ce sont là certains des contrôles très, très importants. Et maintenant, je voudrais revenir sur l'un des principaux risques dont nous avons parlé. Vous vous souvenez de cette attaque de confusion liée à la dépendance. Il s'agissait d'un problème majeur, très similaire à celui de la chaîne d'approvisionnement, cours duquel un attaquant publie un package malveillant un référentiel de packages public portant le même nom qu' un package populaire. Votre développeur peut donc demander un package, et ce qui se passe, c'est que le package vérifie d'abord le rapport public. Et là, l'attaquant a mis le même nom, mais avec un numéro de version supérieur. Vous avez peut-être la version trois, il mettra la version cinq. Et le dépôt de packages, tel qu'il est configuré, sera d'abord consulté sur Internet pour vérifier, puis il téléchargera le package malveillant De cette façon, le package sera copié sur votre réseau de développeurs et sur Bingo. L'attaquant a accès à votre environnement de développement logiciel et est capable de le compromettre. Il s'agit donc simplement d'un type d'attaque qui exploite le fonctionnement des environnements de développement logiciel et des gestionnaires de packages, vous savez, des éléments tels que le gestionnaire de packages de nœuds ou l'index de packages Python. C'est exactement comme ça que ça marche. Alors, encore une fois, que pouvez-vous faire pour garantir cela ? Vous pouvez utiliser des référentiels privés pour les dépendances critiques Vous pouvez simplement utiliser des référentiels privés dotés de contrôles d'accès stricts pour réduire le risque de consommation accidentelle de packages compromis Vous pouvez utiliser le verrouillage des dépendances, en vous assurant que votre dépendance le package répertorié par le développeur est verrouillée à une version spécifique que vous avez vérifiée. Cela empêche ces mises à jour automatiques de compromettre les nouvelles versions potentiellement compromises. Dans ce schéma, vous pouvez voir que l'attaquant a compromis un dépôt de paquets public, n'est-ce pas ? Et au développeur, il a demandé un package. Le package n'ira pas sur Internet pour le vérifier. Pourquoi ? Parce que vous avez verrouillé la dépendance. Vous avez dit que c'est la seule version que je voulais, que vous avez déjà vérifiée, qui est sur site. Il n'ira donc pas sur Internet et vous pourrez contourner complètement cette attaque. L'attaquant ne pourra pas compromettre votre environnement. Voici donc ce que je veux que vous gardiez à l'esprit, à savoir protection contre les attaques de confusion liées à la dépendance, n'est-ce pas ? Voici les éléments dont vous avez besoin pour vérifier que les noms de tous les packages utilisés dans votre projet sont connus et fiables. Vous pouvez le faire en vérifiant la source et le responsable de chaque package avant de l'ajouter à vos dépendances Signature du package dont on a déjà parlé. C'est comme si vous aviez une signature numérique, non ? En signant le package et en utilisant des référentiels de packages privés, pensez donc à utiliser des référentiels de packages privés où vous hébergez vos dépendances internes Cela peut aider à réduire l'attaquant, comme je l'ai montré dans le schéma précédent. Même s'il introduit un package malveillant, qui porte le même nom que votre dépendance interne, votre gestionnaire de packages n'y ira pas car il restera sur site et n' utilisera que le package interne Et bien sûr, surveiller et scanner vos colis, n'est-ce pas ? Vous devez vous assurer qu'aucune vulnérabilité n' a été introduite dans l'intervalle. Cela peut donc aider à détecter les packages malveillants et à surveiller les téléchargements de packages. Ainsi, en surveillant les téléchargements de votre package, vous pouvez aider à détecter toute activité malveillante. Voici donc tout ce que vous pouvez faire pour vous assurer d' protégé contre les attaques de confusion de dépendance. Nous avons donc abordé à présent les environnements. Je voudrais maintenant aborder un sujet très important qui est crucial lorsqu'il s'agit de la sécurité de la chaîne d'approvisionnement logicielle, à les versions logicielles du matériel, le SBOM Merci Et je n'aborderai pas cela parce que je pense que vous avez déjà assez de choses à comprendre dans cette leçon. Je vous verrai dans la prochaine leçon, nous aborderons ce sujet. Merci beaucoup, je vous verrai lors de la prochaine leçon. 13. SBOM: Bonjour, tout le monde. Bienvenue. Bienvenue dans cette leçon, qui couvre un sujet très, très important en matière de sécurité de la chaîne d'approvisionnement logicielle, savoir SBOYM, une compilation logicielle de matériel Alors, qu'est-ce qu'un SBM ? C'est très simple. Il s'agit essentiellement d'un inventaire imbriqué. C'est une liste d'ingrédients. De tous les composants logiciels présents dans votre logiciel. Et si vous pensez à la chaîne d'approvisionnement logicielle, n'est-ce pas, chaque framework ou build d'outils utilisé pour écrire, créer et exécuter des applications, et c'est là que toutes les vulnérabilités entrent en jeu, n'est-ce pas ? Et vous réutilisez constamment du code, progiciels, et des fournisseurs tiers vendent également des packages commerciaux La complexité de la création de toutes ces applications logicielles rend donc très, très crucial de disposer d'un inventaire de tous les composants utilisés pour créer de telles applications, d'un catalogue, n'est-ce pas ? Et ce catalogue aide les entreprises à identifier et à détecter rapidement les failles de sécurité de l'environnement. C'est donc là qu'intervient le SBM. Cela ressemble beaucoup à une norme en matière de sécurité de la chaîne d'approvisionnement logicielle. Et c'est là que vous pouvez réellement demander aux fournisseurs et l'obtenir. Et nous allons examiner cela plus en détail. Vous pouvez donc le faire vous-même. Vous pouvez même le faire avec une feuille Excel. Je ne le recommande pas du tout, sinon vous pouvez le générer automatiquement. Il existe de très nombreux logiciels qui analysent votre environnement, puis ils génèrent ou programment des versions logicielles de matériaux C'est ce que je recommande d'utiliser un produit généré par machine. Et c'est très, très bénéfique, pourquoi ? Parce que cela vous aide à identifier les composants vulnérables et vous donne une connaissance complète de ce que vous avez, n'est-ce pas ? Que se passe-t-il en cas d'incident impliquant la compromission d' une bibliothèque en particulier ? Comment sauriez-vous si vos applications critiques en sont équipées ou non ? Vous pouvez en fait interroger rapidement votre SBM, s'il existe au format machine pour savoir si cette version particulière de cette bibliothèque est utilisée, n'est-ce pas ? Et cela vous aide également à sélectionner les fournisseurs qui écrivent, par exemple si votre fournisseur est transparent et qu'il dit : «   Hé, voici mon SBM avec l'application Vous savez qu'il s'agit d'un fournisseur mature, n'est-ce pas ? Ils ont tout ce dont ils ont besoin. Et même après avoir cru que c'était grâce à l'énergie solaire, aux fournisseurs de la chaîne d'approvisionnement en logiciels et à la sécurité garantie par le décret exécutif, ils ont également commencé à imposer la nécessité d'un SPOM Donc, comme je l'ai dit, vous pouvez le faire manuellement, en utilisant une feuille Excel. Je ne le recommande absolument pas car vous pouvez avoir des centaines voire des milliers de dépendances. Habituellement, vous pouvez le faire à l'aide d'outils générés par machine , n' est-ce pas, qui le font entièrement automatiquement pour vous. Alors, comme je l'ai dit, à quoi ça sert ? C'est comme un inventaire complètement exhaustif, non ? Il détaille chaque élément open source tiers, les bibliothèques, les packages de code utilisés dans le développement d'une application logicielle, et il vous donne une bonne idée de la composition du logiciel, n'est-ce pas ? De cette façon, vous savez ce qui existe, ce qui ne l'est pas, quelle version vous utilisez, quelles bibliothèques et quels packages de code utilisent ? À quoi ressemblent les composants tiers, quel est le statut du PAT ? Quelles sont les dépendances entre eux ? Et vous pouvez maintenant comprendre si je voulais connaître le statut du PAT parce que je ne sais pas si le logiciel en question est vulnérable ou non à une attaque en particulier, le SBOM peut immédiatement vous aider à l'identifier Et c'est comme un produit généré par une machine . Voilà à quoi ça ressemble. Je veux dire, je ne veux pas que vous le lisiez, mais cela montre simplement que vous pouvez voir quel est le package. Hein ? Quel est le statut ? Quelle est la version ? Quel est le hashcode ? Qui est le fournisseur ? Toutes ces choses entrent donc en jeu. Et en quoi cela aide-t-il ? J'en ai déjà parlé, mais vous savez, tout d'abord, il y a de la transparence. Cela vous donne donc une liste complète de ce que vous avez, non ? Ce niveau de transparence permet aux entreprises de savoir exactement ce que contient le logiciel et de le rendre plus facile à gérer et à sécuriser. Gestion des vulnérabilités Avec SBM, vous pouvez rapidement identifier les composants logiciels susceptibles de présenter des problèmes de sécurité Vous pouvez ainsi identifier les problèmes de manière proactive. Conformité : de nombreux secteurs ont des exigences réglementaires qui imposent normes de sécurité pour les logiciels. Donc, si vous n'en avez pas, même si vous n'avez pas le logiciel chez vous, vous utilisez peut-être un logiciel fourni par un fournisseur. Vous pouvez utiliser un SBOM. Vous pouvez demander le SBM au vendeur, n'est-ce pas ? Et bien sûr, la sécurité de la chaîne d'approvisionnement. L'objectif est d' améliorer la sécurité de votre chaîne d'approvisionnement, et cela contribue également à la réponse aux incidents. Supposons qu'en cas de réponse à un incident, SBM vous permette plus rapidement et plus efficacement aux incidents Vous pouvez rapidement déterminer les composants susceptibles d'être affectés par une attaque. Et encore une fois, le suivi des dépendances. Donc, comme je l'ai dit, il devient tellement compliqué de suivre ce que vous avez et ce que vous n'avez pas. Une SVM vous aide donc à suivre ces dépendances au fil du temps. Et de nos jours, à l'ère du GNAI et de tout le reste, vous pouvez réellement placer une IA au-dessus de ces fichiers interroger et obtenir des réponses complètement humaines, n'est-ce pas ? Vous pouvez donc penser à toutes ces choses. Donc, si je regarde les choses sous cet angle. Supposons donc que vous ayez une équipe de cybersécurité, est-ce pas, et que votre entreprise achète un produit auprès d'un fournisseur Et maintenant, l'équipe de cybersécurité veut savoir quel type de logiciel existe. Est-ce open source ? Comment est-il construit, non ? Vous demandez donc au vendeur, pouvez-vous s'il vous plaît me donner un SBM ? C'est donc ce à quoi le fournisseur répond correctement. Ils vous donnent un SBOM et la personne est maintenant en mesure de le lire et d'obtenir cette assurance OK, qu'est-ce qu'il y a ? Qu'est-ce qui n'y est pas ? Aucun logiciel n'est à l'abri failles de sécurité, n'est-ce pas ? Every There n'existe pas de logiciel totalement sécurisé à 100 %. Vous pouvez donc même le faire avec un SBOM. Vous pouvez donc demander au fournisseur s'il existe des vulnérabilités dans les redes de votre laboratoire logiciel Ils peuvent vous fournir des panneaux OSB ainsi que ce que l'on appelle exploitabilité des vulnérabilités. Qu'est-ce que c'est maintenant ? Il s'agit d'un framework conçu pour communiquer les failles de sécurité du logiciel, en particulier si le logiciel est vulnérable ou non. Les déclarations VX fournissent donc aux fournisseurs un moyen de communication Qu'il y ait une vulnérabilité ou non, vous pouvez le savoir exactement. Donc, si je suis vendeur et qu'un client me le demande, je peux lui donner le SBM plus un VX Et je dis que cette vulnérabilité n' est pas un problème pour notre produit, et vous pouvez détailler les conditions dans lesquelles elle pourrait poser problème, mais vous l'avez atténuée, n'est-ce pas ? Cela fait donc partie du SBOM et cela vous donne Il s'agit donc, encore une fois, d'une norme plus en plus populaire dans la chaîne d'approvisionnement logicielle. Pourquoi parce que vous n'avez pas accès au code source externalisé, n'est-ce pas Mais si vous achetez une application, vous pouvez réellement utiliser le SPM Vous pouvez utiliser le VX pour obtenir cette assurance. Et dans la leçon suivante, nous allons faire une véritable étude de cas, par exemple, comment cela se passerait-il si un client achetait un logiciel et ce que nous pouvons faire ? Je pense donc que cela couvre à peu près tout ce dont nous avons parlé, non ? Nous l'avons donc examiné du point de vue de l'environnement des développeurs, codage sécurisé, du renforcement, analyse des composants, des tests, du renforcement de l' environnement et nous l'avons maintenant examiné du point de vue de SBM J'espère donc que cela vous a été utile pour comprendre à quel point ce monde est vaste, n'est-ce pas ? Vous avez maintenant une bonne idée de la sécurité de la chaîne d'approvisionnement logicielle et des contrôles à chaque étape ainsi que des idées fausses que les gens ont, comme le fait qu'il s'agit d'un produit que vous achetez ou d'une certification que vous obtenez Maintenant que vous êtes en bon état, nous pouvons vous dire : «   D'accord, il y a tellement de contrôles ». Comment puis-je réellement le mettre en œuvre ? Par où commencer ? Est-ce que je commence par le SBM ? Dois-je commencer par Secure Code ? Dois-je commencer par les dépendances ? Que dois-je faire ? C'est ce dont nous parlerons dans la prochaine leçon, où nous parlerons de la création d'une chaîne d'approvisionnement logicielle, d' un programme de sécurité et de gestion des risques. Par exemple, si vous commencez à le faire au sein de votre entreprise, par où commencer et où tous ces différents composants vont entrer en jeu. OK ? J'espère donc que cela vous a été utile. Je te verrai dans la prochaine leçon. Merci 14. Conclusion: Bonjour, bonjour, tout le monde. Bienvenue. Bienvenue à la leçon finale. Et ce n'est que la fin. Merci de m'avoir écoutée, parler Dieu seul sait combien de temps. Mais j'espère que vous avez acquis une bonne compréhension de la sécurité de la chaîne d'approvisionnement logicielle. J'espère que vous avez maintenant une vision globale, et que vous ne pensez pas simplement à acheter un produit ou simplement à activer le MFA ou quelque chose comme ça J'espère avoir amélioré vos connaissances sur les nouveaux types d'attaques. N'oubliez donc pas qu'il s'agit d'un voyage continu. Suivez les meilleures pratiques et tendances du secteur et commencez. Je ne peux pas, s'il vous plaît, ne pas faire partie de ceux qui se contentent de suivre cette leçon et de l' oublier la semaine suivante. OK, commencez, prenez certaines des leçons dont je vous ai parlé et commencez à les mettre en œuvre au sein de votre entreprise. Jetez un œil aux dépôts intégrés, aux dépôts packages et commencez à les implémenter de manière incrémentielle Mais c'est à peu près la fin du cours. J'espère que vous avez aimé m'écouter Babylon pendant tant d'heures. Merci beaucoup de m' avoir supportée. N'oubliez pas que je vous ai donné un projet au début. Vous pouvez prendre cela et comparer votre propre chaîne d'approvisionnement en logiciels au risque dont nous avons parlé et le partager. Et par exemple, faites une simple évaluation de votre situation, de votre chaîne d'approvisionnement, des risques et de la manière dont vous pouvez les atténuer, documentez-la afin de vous faire une meilleure idée. Parce que si vous n' appliquez pas ces connaissances, je peux vous garantir que vous les oublierez. Vous aurez perdu votre temps et votre argent si vous n' appliquez pas les connaissances dont j'ai parlé. C'est donc à peu près tout. S'il vous plaît, n'hésitez pas à me contacter. Je suis là sur Substack, LinkedIn et j'ai également une petite chaîne YouTube Je lie tout dans les commentaires. Désolé, pendant la leçon, vous pouvez cliquer dessus et me contacter si vous pensez que c' était une bonne leçon, veuillez laisser un si vous pensez que c'est le pire cours que vous ayez jamais suivi, faites-le moi savoir, s'il vous plaît, également. Pas de soucis du tout. Je suis heureuse de recevoir des commentaires. Je vous remercie donc beaucoup. Ceci met fin à ce cours. J'espère que vous avez passé un bon moment, et je vous verrai dans le prochain cours que je donnerai. Merci beaucoup et au revoir.