Si vous avez prêté attention aux menaces réseau au cours des dernières années, vous avez probablement remarqué un changement. Bien que les acteurs malveillants continuent à mener des botnets et des attaques automatisées par rançongiciel, ils consacrent plus d’énergie à la chasse aux grands jeux , attaquant les chaînes d’approvisionnement qui fournissent les logiciels utilisés dans d’innombrables organisations.
Les noms de ces attaques sont désormais tristement célèbres : SolarWinds, Kaseya, NotPetya et 2023’s MoveIT , pour n’en citer que quelques-uns, et l’avantage de cibler la chaîne d’approvisionnement est évident : un bénéfice plus important. Que les pirates informatiques compromettent une bibliothèque open source ou tierce via un référentiel GitHub, trouvent une vulnérabilité dans des logiciels emballés ou tirent parti de l’ingénierie sociale pour infiltrer un environnement de développement, un exploit unique peut pénétrer des centaines ou des milliers de réseaux privés et publics dans le monde entier.
L’attaque SolarWinds a touché quelque 18 000 entreprises ; MoveIT, plus de 2 500 organisations (et ce n’est pas fini), affectant quelque 67 millions de personnes.
Juniper Research prévoit que d’ici 2026, les attaques de la chaîne d ’approvisionnement logicielle coûteront à l’économie mondiale près de 81 milliards USD, la majorité de ces coûts touchant les secteurs de la santé, de la finance, du gouvernement et de l’automobile.
L’objectif d’un leader de la sécurité est d’éradiquer les vulnérabilités et de réduire votre surface d’attaque. Les compromis sur les réseaux informatiques se produisent de manière de plus en plus insidieuse (et subtile), de l’installation de logiciels de confiance qui ont été détournés par un attaquant à la négligence des menaces de l’ informatique fantôme. Dans ce dernier cas, une action négligente d’un employé téléchargeant un programme d’installation ou un logiciel gratuit non approuvé peut perturber des mois ou des années d’efforts de sécurité.
Alors, qu’est-ce qu’un directeur de la sécurité de l’information (RSSI) doit faire ? Les pirates informatiques se concentrant sur ces cibles à fort impact, les RSSI doivent être proactifs. Le conseil standard qu’ils obtiennent est « Faire confiance, mais vérifier ». Mais cela suppose d’abord la confiance et cette hypothèse devient de plus en plus problématique. Ce que je dis aux RSSI, c’est : Zero Trust , jusqu’à ce que vous vérifiiez.
Une chaîne d’approvisionnement complexe confrontée à des menaces constantes
L’installation de logiciels était autrefois assez simple : vous avez trouvé un fournisseur en qui vous pouviez faire confiance et vous avez téléchargé son produit. Aujourd’hui, la chaîne d’approvisionnement comprend non seulement la société auprès de laquelle vous avez acheté une licence, mais également les composants tiers qui composent le logiciel, les utilitaires que votre personnel construit et augmente en interne, et les logiciels que vous utilisez sur le cloud.
« Les RSSI doivent être proactifs et suivre une [nouvelle] devise simple : Zero Trust, jusqu’à ce que vous vérifiiez. »
De nouvelles vulnérabilités dans la chaîne d’approvisionnement des logiciels (telles que celles observées dans Apache Struts, OpenSSL, cURL et d’autres utilitaires et bibliothèques partagés) apparaissent avec une régularité désavantageuse. Lorsque les malfaiteurs regroupent ces codes compromis et les insèrent dans des logiciels connus, ils exploitent non seulement une vulnérabilité, mais également la confiance entre le fournisseur et le client que les logiciels sont « sûrs ». Si un mauvais acteur pénètre dans la technologie qu’une société de logiciels utilise pour signer un code comme authentique, ce code malveillant se propage désormais sans que les gens sachent qu’il a été corrompu.
Pour aggraver les choses, les pirates informatiques peuvent également voler des certificats de signature ou des informations d’identification de développeur et utiliser cette identité privilégiée pour s’assurer que leur intention malveillante contourne vos détections de sécurité.
Heureusement, avec les bons outils, une préparation minutieuse, une automatisation et une approche Zero Trust-Till-Vérifier de l’architecture réseau, les responsables de la sécurité peuvent apprendre à identifier et neutraliser rapidement ces menaces. Nous vous suggérons de suivre ces sept étapes :
1. Commencer par un inventaire réseau
Comme le dit le dicton, « Vous ne pouvez pas protéger ce que vous ne voyez pas. » Vous devez disposer des outils, des processus et du personnel formé en place qui peuvent vous donner une connaissance complète de tous les appareils et logiciels de votre organisation. Un système automatisé de gestion ou de protection des endpoints peut vous aider à protéger votre surface d’attaque, tant qu’elle s’exécute sur tous vos endpoints.
L’automatisation peut également vous aider à protéger votre chaîne d’approvisionnement logicielle. Du seul point de vue des chiffres, il y a beaucoup plus de problèmes, d’endpoints et de défis auxquels les organisations individuelles sont confrontées que les professionnels de la cybersécurité du personnel. Dans son rapport Cost of a Data Breach 2023, IBM note que « les organisations qui utilisaient [l’IA et l’automatisation] ont connu, en moyenne, un délai plus court de 108 jours pour identifier et contenir la violation », et ont économisé en moyenne 1,76 millions USD en coûts de violation de données.
L’IA sera également un allié dans ce combat. Bien qu’il s’agisse toujours d’une technologie émergente, il existe un potentiel prometteur dans les façons dont l’IA, que je appelle souvent intelligence augmentée , aidera les équipes de sécurité à trier plus rapidement et avec une plus grande précision globale.
Grâce à l’utilisation d’une technologie avancée, vous pouvez réduire non seulement la charge de travail qui accompagne une réponse aux attaques, mais également le burnout humain associé, et l’erreur humaine qui s’accompagne d’une « fatigue d’alerte ».
2. Mettre les SBOM au travail
L’une des fonctionnalités des logiciels modernes qui les rendent si facilement exploitables est qu’ils ne sont plus écrits à partir de zéro. Les développeurs saisissent des extraits de code à partir de bibliothèques de code en ligne tierces, et chaque extrait présente une vulnérabilité potentielle. Il ne suffit donc plus de savoir quel logiciel se trouve sur votre système ; vous devez maintenant répertorier chacune des bibliothèques ou modules qui ont été utilisés pour construire le logiciel que vous souhaitez installer.
« Maintenir un inventaire précis de tous les composants de tous les logiciels sur votre réseau serait suffisamment difficile si cet inventaire était statique. Ce n’est pas le cas. »
Ce type de liste, appelée nomenclature logicielle (SBOM), permet de suivre les vulnérabilités dans les fichiers, bibliothèques et composants tiers. C’est utile, et bien au-delà de la capacité des humains à créer manuellement.
Idéalement, les fournisseurs et les créateurs de logiciels adopteront leur rôle de source unique de vérité pour leurs logiciels et incluront des SBOM pour leurs applications logicielles. Il existe également des outils qui automatisent la création de ces listes. Et le gouvernement fédéral est également intervenu : le décret 2021 du président Biden sur l’amélioration de la cybersécurité de la nation exige que les fournisseurs qui fournissent des logiciels au gouvernement fédéral incluent une SBOM pour tout ce qui concerne leurs produits.
Maintenir un inventaire précis de tous les composants de tous les logiciels sur votre réseau serait suffisamment difficile si cet inventaire était statique. Ce n’est pas le cas : si les développeurs de logiciels téléchargent le code source publique et changent son nom ou le modifient légèrement, ce téléchargement peut sembler différent dans leur logiciel que dans celui d’une autre personne. Ou si un référentiel de code GitHub est sûr mardi, mais qu’un pirate informatique effectue un « engagement » malveillant ou une modification du code mercredi, votre réseau est à nouveau vulnérable dès que quelqu’un réimporte ce référentiel.
3. Créer un environnement de test logiciel
Si vous créez un logiciel, vous devez ajouter une autre couche de défense avec un référentiel privé de tout code que vous avez mis en œuvre. Ce code doit être audité et sécurisé, et ne doit jamais être extrait directement des sources amont d’origine sans examen de sécurité. Avec un référentiel sécurisé en place, vous pouvez télécharger un logiciel et le parcourir ligne par ligne en privé, en toute sécurité, sachant que personne en dehors de votre organisation ne peut y apporter des modifications.
Si, par exemple, vous souhaitez utiliser la bibliothèque logicielle OpenSSL, vous pouvez saisir le code source et l’apporter à votre environnement de développement privé où vous pouvez mettre en œuvre des correctifs et des mises à niveau à mesure que de nouvelles versions sortent. L’avantage de cette approche est qu’elle vous permet de transférer le code et de contrôler vos examens de tout nouveau code ajouté. Le référentiel vous donne l’opportunité de tester le logiciel et de vous assurer qu’il ne cassera rien dans votre environnement, avant de le déployer.
4. Établir un plan de gestion des vulnérabilités
Même avec un environnement de test, il est probable que certaines attaques réussiront. Vous devez donc créer un plan de gestion des vulnérabilités et vous demander :
- Suis-je prêt à agir lorsque quelque chose passe ? Qui sera responsable de la réponse ?
- Avons-nous mis en place des politiques et procédures pour guider la manière dont nous gérons la gestion des correctifs lorsqu’une vulnérabilité critique apparaît ?
- Quel est notre plan de gestion des risques tiers : si une bibliothèque tierce présente une vulnérabilité critique, comment identifierons-nous les applications utilisant cette bibliothèque tierce et comment mettrons-nous les services critiques hors ligne pour les corriger ?
- Pouvons-nous neutraliser l’attaque sans impact significatif sur nos opérations critiques pour l’entreprise ?
- Avons-nous établi des politiques de communication efficaces pour les parties prenantes internes et externes dans le cadre de nos plans de remédiation d’urgence ?
5. Mettez des dents d’application dans vos politiques
Après tant d’attaques, les RSSI savent qu’il est important de former les employés pour éviter de télécharger quoi que ce soit à partir de sites suspects ou, par exemple, de laisser leurs enfants installer Minecraft sur un appareil de travail. Et les travailleurs sont de plus en plus prudents avec les appareils Internet des objets (IOT) tels que les caméras, les imprimantes et les téléphones VoIP (qui utilisent une connexion Internet et la technologie « Voix sur protocole Internet » pour passer des appels).
« Vous devez avoir à la fois une politique écrite sur l’utilisation acceptable des logiciels et un moyen de l’appliquer techniquement. Il ne s’agit pas d’une tâche simple, mais elle peut être simplifiée... grâce à l’automatisation. »
Mais une couche critique dans toute défense est les contrôles techniques qui empêchent les intrusions indésirables de se produire en premier lieu. C’est une chose de dire aux employés de ne pas installer de clés USB ou de logiciels non approuvés sur leur ordinateur portable ; c’est une autre chose de rendre techniquement impossible pour eux de le faire.
C’est la couche avec laquelle de nombreuses entreprises ont du mal. Si pour aucune autre raison que la conformité réglementaire, vous devez avoir à la fois une politique écrite sur l’utilisation acceptable des logiciels et un moyen de l’appliquer techniquement. Il ne s’agit pas d’une tâche simple, mais elle peut être simplifiée, une fois de plus, grâce à l’automatisation. Vérifier régulièrement vos « politiques papier » et vérifier si vous avez créé des mesures de mise en œuvre techniques pour les compléter est une stratégie exceptionnelle pour faire évoluer la posture de sécurité de votre organisation.
[Lire également : Pourquoi les travailleurs violent les politiques de cybersécurité]
6. Effectuer une évaluation approfondie des capacités
En planifiant de se préparer à l’inévitable catastrophe de la chaîne d’approvisionnement, les RSSI feraient bien de répondre aux questions posées dans ce graphique :
Développé par l’ expert en sécurité de Microsoft Matt Swann, ce graphique représente une « hiérarchie des besoins » de réponse aux incidents. Il est inspiré de la hiérarchie des besoins du psychologue américain Abraham Maslow, qui décrit les besoins humains, en commençant par le plus basique. La version de Swann décrit les capacités que les organisations doivent développer pour défendre leurs actifs commerciaux. Cela commence également par le plus basique, un inventaire des actifs, et chaque niveau sert de prérequis pour la capacité au-dessus.
Les responsables de la sécurité peuvent avoir besoin d’avoir des conversations internes difficiles sur la position de leurs organisations sur cette pyramide en termes de maturité. Certaines entreprises peuvent se trouver bloquées aux niveaux les plus bas, ne sachant pas si elles peuvent nommer et assurer la visibilité de tous les actifs qu’elles défendent. Si vous ne pouvez pas nommer et localiser tous vos actifs, tout ce que vous faites à partir de ce niveau peut n’atteindre qu’une partie de votre surface d’attaque totale et causer des impacts critiques sur l’efficacité de votre équipe.
Vos chasseurs de menaces seront beaucoup plus efficaces lorsqu’ils chassent dans un environnement doté d’une télémétrie et d’une visibilité robustes.
7. Nourrir l’écosystème des relations
Dans le cadre de mon mandat de directeur de la recherche sur la sécurité des endpoints chez Tanium (qui détient cette publication), j’ai vu des clients essayer de sécuriser leur chaîne d’approvisionnement logicielle avec une grande variété d’approches, des outils développés en interne aux solutions prêtes à l’emploi. Le problème est que, s’ils ne sont pas effectués de manière réfléchie, les tentatives d’identification, d’isolation et de neutralisation du mauvais code peuvent ralentir ou, pire encore, détruire l’ensemble d’un système.
Une stratégie plus efficace consiste à entretenir des relations entre toutes les parties prenantes, à travers votre organisation, votre réseau de fournisseurs et votre chaîne d’approvisionnement. Les RSSI sont plus efficaces lorsqu’ils comprennent comment leurs employés utilisent la technologie, comment les fournisseurs sécurisent leurs logiciels et comment le gouvernement et d’autres partenaires du secteur peuvent aider à soutenir ces efforts.
Votre chaîne d’approvisionnement logicielle est composée de nombreux liens. Il en va de même pour le meilleur plan de protection.
Le graphique de Matt Swann « Hiérarchie des besoins en matière de réponse aux incidents » fourni par permission.
