Blog Zscaler

Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception

S'abonner
Produits et solutions

Attaques de la chaîne d’approvisionnement

image
MARTIN WALTER
janvier 18, 2021 - 12 Min de lecture

Sommaire

Dans cet article, nous passerons en revue ce que sont les attaques de chaîne d’approvisionnement, comment elles ont évolué et comment nous en sommes arrivés à SUNBURST, une attaque de chaîne d’approvisionnement ciblant la célèbre plateforme de surveillance SolarWinds Orion. Nous verrons également comment cet adversaire sophistiqué a échappé aux solutions de détection courantes et comment déterminer si vous avez été affecté par cette attaque. L’article en outre quelques recommandations sur la manière de faire face à ces types d’attaques à l’avenir, en utilisant des principes communément connus et des technologies disponibles.


Introduction

Les attaques contre la chaîne d’approvisionnement, des attaques menées contre la chaîne d’approvisionnement ou de valeur d’une entreprise afin d’accéder à une cible en aval, font souvent penser à des histoires d’attaques ciblées qui ne se produisent que contre les agences gouvernementales dans les films hollywoodiens. En réalité, même si ces attaques impliquent un haut degré de planification et de sophistication, elles peuvent avoir un impact dévastateur sur les entreprises situées dans le rayon d’action de la compromission initiale, comme dans le cas des récentes attaques menées contre SolarWinds.

De manière générale, nous pouvons distinguer deux grands types d’attaques menées contre la chaîne d’approvisionnement ou de valeur d’une entreprise.

Les attaques par « Island hopping » ciblent des partenaires ou des éléments potentiellement vulnérables de la chaîne de valeur disposant d’un éventuel accès privilégié au réseau cible réel. Dérivé de la stratégie de saut d’île en île des États-Unis lors de la campagne du Pacifique pendant la Seconde Guerre mondiale, ce type d’attaque peut inclure plusieurs éléments vulnérables afin d’accéder à la cible réelle de l’attaque. Nous avons été témoins de ce type d’attaques visant des cibles importantes dans le secteur de la vente au détail, impliquant les fournisseurs qui servaient de point d’entrée initial, ainsi que dans de nombreux autres secteurs, sous des formes similaires.

Les attaques de la « chaîne d’approvisionnement » sont sensiblement différentes, car elles cherchent à exploiter la relation de confiance établie dans des produits légitimes utilisés dans le cadre d’opérations commerciales classiques. Ces types d’attaques visent à obtenir un accès non autorisé à une entreprise cible en implantant des portes dérobées dans les produits utilisés par l’entreprise cible, le plus souvent via la fourniture de correctifs automatisés ou de mises à jour logicielles. Ce type d’attaques a également été observé ciblant des entreprises technologiques, notamment des fournisseurs d’antivirus ou des fabricants d’équipements de sécurité réseau, mais ne se limitent certainement pas à ces entreprises en raison de la multitude d’autres cibles potentielles de grande valeur.

Ces deux types d’attaques peuvent cibler plusieurs entreprises, et leur objectif peut être d’accéder ou de recueillir des informations sur des secteurs entiers, ou à des entreprises de grande envergure, ou encore à des individus Dans le même temps, les entreprises qui servent simplement d’îlots peuvent également subir d’énormes dommages à leur réputation et à leur activité, alors qu’elles ne sont même pas la cible réelle de cette campagne.
 

L’évolution des attaques de la chaîne d’approvisionnement

Lorsque les nouvelles ont éclaté en 2013 et 2014 concernant les attaques menées contre Target et Home Depot, les entreprises du monde entier ont commencé à évaluer leur chaîne de valeur et l’interconnectivité de ses données. Ces attaques correspondaient à la description d’attaques par island hopping, perpétrées par des cybercriminels via des fournisseurs afin de recueillir à grande échelle des informations sur les cartes de paiement.

L’interconnectivité des données entre les entreprises permet à ces dernières de déployer des processus très efficaces : de la conception au prototypage, en passant par la fabrication, la logistique et la livraison dite juste à temps au client final. Si ces connexions étroitement imbriquées aident les sociétés à économiser des milliards de dollars grâce à une meilleure efficacité et à commercialiser des innovations à une vitesse sans précédent, les attaques du début des années 2010 ont rappelé aux entreprises la surface d’attaque qu’une telle connectivité offre aux adversaires.

En conséquence, les professionnels de la sécurité ont commencé à considérer les partenaires commerciaux qui exigent que l’automatisation de leurs processus soit connectée à leurs réseaux avec la même méfiance que toute autre connexion anonyme. Cette évolution a conduit à une conscientisation plus importante de la sécurité et à la mise en place de contrôles supplémentaires pour surveiller l’interconnectivité. Davantage de certifications de sécurité telles que l’ISO 27001 (qui, dans son annexe 15, mentionne spécifiquement l’évaluation de la sécurité des fournisseurs dans la chaîne de valeur) ont été exigées de ces partenaires avant qu’une connexion entre les réseaux ne soit établie.

La plupart de ces attaques par island hopping reposent sur la présence d’un accès autorisé ou d’une vulnérabilité exploitable sous la forme d’une faiblesse logicielle ou d’une mauvaise configuration des systèmes. À mesure que les entreprises deviennent plus diligentes et plus disciplinées concernant l’application des correctifs aux systèmes existants, la mise en œuvre de bonnes pratiques de configuration et la segmentation de leurs réseaux, les hackers éprouvent plus de difficultés à trouver des faiblesses exploitables qu’auparavant.

En 2015, des allégations ont fait état d’une porte dérobée secrète dans le mécanisme d’authentification Secure Shell (SSH) de JunOS de Juniper. Cette attaque, implantée par un acteur malveillant inconnu dans l’équipement d’un important fabricant américain d’équipements de sécurité réseau, pourrait avoir été en place depuis des années. Au cours de la même année, une porte dérobée présumée intégrée dans un produit antivirus populaire a été impliquée dans une fuite très médiatisée d’informations hautement classifiées de la National Security Agency. Bien qu’elle soient passées largement inaperçues du grand public, les nouvelles concernant ces types de portes dérobées mettent de nombreux professionnels de la sécurité en état d’alerte, car ces attaques exploitent la confiance que nous accordons à l’intégrité et à la sécurité inhérente de ces technologies.

L’attaque de la chaîne d’approvisionnement impliquant SolarWinds Orion fin 2020 n’est que le dernier exemple en date de ce type d’attaque.

 

Une tempête solaire

L’attaque de la chaîne d’approvisionnement impliquant la porte dérobée surnommée « SUNBURST » au sein de la plateforme SolarWinds Orion a fait couler beaucoup d’encre. Plutôt que de décortiquer une fois de plus les détails techniques, il est important d’examiner les mesures que les entreprises doivent prendre pour déterminer si elles ont été touchées et ce qu’il convient de faire ensuite.
 

Qui est affecté ?

Le moyen le plus simple de déterminer si votre entreprise est concernée consiste à déterminer si l’un des produits et versions compromis de SolarWinds Orion est utilisé dans votre environnement (lire notre blog). Pour maintenir la sécurité opérationnelle, dans ses efforts pour ne pas être détecté, l’auteur de cette attaque spécifique semble avoir utilisé la porte dérobée de SolarWinds Orion uniquement dans les cas où l’environnement cible semblait présenter un intérêt particulier. Seule une analyse de l’activité du réseau permet de déterminer si un accès a été tenté et obtenu.

En effet, la campagne est censée avoir débuté en mars 2020 ou avant, et n’impliquait aucun indicateur de compromission connu. Étant donné le considérable volume de données concerné, de nombreuses entreprises ne conservent pas les journaux d’accès suffisamment longtemps pour déterminer si une compromissiona été couronnée de succès ou non.
 

Les protections ont-elles échoué ?

Les capacités automatisées existantes, même celles conçues pour identifier des menaces inconnues jusqu’alors, telles que les sandboxes de malwares, permettent difficilement de détecter la porte dérobée SUNBURST implantée dans SolarWinds Orion.

Cette difficulté tient à une série de facteurs qui témoignent du soin extrême apporté par les adversaires à dissimuler leurs traces. La porte dérobée a été diffusée via une mise à jour logicielle légitime d’un outil de surveillance et de gestion connu. Il fallait également que la mise à jour logicielle contenant la porte dérobée soit installée avec succès, ce qui exigeait la présence de composants logiciels spécifiques sur le système cible.

La plupart des sandbox utilisent des versions de système d’exploitation que l’on retrouve couramment sur les systèmes de points de terminaison et n’incluent qu’une liste d’applications courantes pour imiter le système d’un utilisateur final. Même après l’installation de la porte dérobée, le hacker a pris des mesures de précaution pour éviter d’être détecté dans un environnement sandbox, par exemple en attendant plusieurs jours avant tout rappel de l’infrastructure de commande et de contrôle, et en vérifiant si le logiciel s’exécutait dans un environnement de laboratoire ou de production.

La meilleure opportunité de détecter cette porte dérobée et son activité aurait été de surveiller de près l’activité réseau anormale de la plateforme SolarWinds Orion alors qu’elle commençait à téléphoner à la maison. Cependant, dans ce cas-ci, l’acteur a pris soin d’éviter de déclencher les signaux habituels que nous sommes parfaitement préparés à détecter. Par exemple, l’infrastructure de commande et de contrôle a été mise en place dans les pays des victimes, plutôt que dans des zones géographiques que nous sommes entraînés à observer avec méfiance. De plus, pour garantir que les connexions à un domaine nouvellement enregistré n’alertent pas les opérateurs de sécurité, le domaine de commande et de contrôle utilisé a été enregistré bien à l’avance, des mois avant le début présumé de la campagne. Enfin, l’adversaire a inclus les conventions de dénomination des entreprises ciblées dans les noms DNS de l’infrastructure de commande et de contrôle pour tromper les opérateurs de sécurité et les amener à rejeter tout soupçon potentiel en le considérant comme un résultat faussement positif.

Après la compromission initiale, l’adversaire a utilisé des outils et des techniques bien connus pour récupérer les informations d’identification de l’administrateur, établir la persistance et obtenir un accès à distance au système compromis. Cette activité aurait pu être détectée par la plupart des produits de détection et de réponse aux menaces sur les terminaux (EDR) en surveillant l’activité du système sur les systèmes concernés. Cependant, dans de nombreux cas, les produits EDR ne sont pas déployés sur les systèmes serveurs et une plus grande attention est accordée aux terminaux.

En bref, la détection de cette porte dérobée spécifique implantée dans un logiciel légitime était incroyablement difficile à réaliser, bien que loin d’être impossible.
 

Se protéger contre les attaques de la chaîne d’approvisionnement

La grande question est la suivante : comment pouvons-nous traiter la chaîne d’approvisionnement comme un vecteur de menace potentiel à l’avenir ? Bien que la protection contre les portes dérobées ou les vulnérabilités introduites dans des logiciels ou des composants fiables par des tiers malveillants soit un exercice difficile, certains des mêmes principes qui ont contribué à la défense contre les attaques par island hopping peuvent également être appliqués ici.
 

Accès minimal requis

Dans le cas d’attaques contre les technologies que nous utilisons pour gérer nos entreprises, les concepts de base d’une architecture Zero Trust peuvent fournir une couche défensive efficace pour limiter considérablement l’impact des technologies « trojanisées ».

Si des adversaires réussissent à implanter une porte dérobée dans un logiciel ou un matériel connecté à nos réseaux, ou même dans une partie de la structure réseau, ils auront toujours besoin d’un accès au-delà du composant et n’auront qu’un accès à l’environnement proportionnel au composant lui-même. Par conséquent, restreindre l’accès aux composants entrants et sortants au minimum absolument nécessaire pour fonctionner limite la capacité des adversaires à exploiter leur position, parfois de manière spectaculaire.

À cette fin, il est important d’analyser chaque solution non seulement au regards des accès et des privilèges dont elle a besoin pour fonctionner, mais également des personnes qui ont besoin d’accéder à des fonctions spécifiques en son sein. Par exemple, toute application serveur qui tente d’établir une connexion à une ressource accessible sur Internet ne devrait y être autorisée que pour des cas d’utilisation très spécifiques documentés et attendus, tels que la connexion à des serveurs de mise à jour ou à des serveurs de temps de réseau, etc. Dans le même temps, chaque solution doit être analysée et évaluée en fonction de l’accès exact dont elle a besoin pour fonctionner. Par exemple, une solution de surveillance ne nécessitera peut-être pas de privilèges pour écrire ou apporter des modifications à un système. Il se peut même qu’il lui suffise d’accéder en lecture à un service ou à un ensemble de données très spécifique, plutôt qu’à l’ensemble du système.
 

Authentification forte et surveillance

Enfin, il convient d’évaluer soigneusement le niveau d’accès nécessaire pour accéder à une application ou à un système, ainsi que la manière dont cet accès peut et doit être sécurisé. Une telle évaluation déterminera les contrôles d’accès qui, en fin de compte, limiteront la capacité d’un adversaire à atteindre et à utiliser une technologie potentiellement « trojanisée » et à se déplacer latéralement. Par exemple, les systèmes qui dépendent d’un accès privilégié à d’autres systèmes et composants dans un environnement donné constituent par définition des cibles de grande valeur. L’accès à ces composants ou systèmes de réseau doit passer par une authentification multifacteur pour tout accès administratif, qui lui-même devrait être accordé en fonction des besoins.

L’utilité des mesures décrites ici ne se limite en aucun cas à ce que nous avons observé au cours du mois dernier concernant la faille SolarWinds. Ainsi, le fait de limiter l’accès vers et depuis la plateforme SolarWinds Orion et d’exiger une authentification forte pour y accéder aurait pu considérablement gêner l’adversaire dans sa tentative d’exploiter l’environnement et d’y accéder, tout en facilitant la détection d’activités inattendues. Après tout, la découverte de cette attaque a commencé par la détection d’un événement de connexion suspect qui utilisait des informations d’identification volées.
 

Fournisseurs de confiance mais vérifiés

Selon le type de service ou le secteur d’activité, différentes certifications disponibles de pratiques de cybersécurité peuvent aider les entreprises à évaluer dans quelle mesure les fournisseurs de solutions sont équipés pour détecter, prévenir et dissuader les accès non autorisés ou les modifications apportées à leurs données, produits et services. La plus importante de ces certifications est probablement ISO/IEC 27001, car elle stipule qu’une entreprise non seulement suit et adhère à des pratiques de sécurité qui garantissent la confidentialité, l’intégrité et la disponibilité, mais impose également la responsabilité de ces aspects à la direction générale.

Par conséquent, la première stratégie de prévention des attaques contre la chaîne d’approvisionnement consiste à soigneusement évaluer et surveiller la manière dont les fournisseurs de votre entreprise mettent en œuvre et respectent les pratiques de sécurité. Par exemple, ISO/IEC 27001, annexe 5, prévoit expressément un tel examen de la chaîne d’approvisionnement d’une entreprise.

Divers audits de cybersécurité sont disponibles pour fournir aux entreprises des certifications attestant de la sécurité des architectures de systèmes, de la mise en œuvre de processus de sécurité et de réponse et du respect des bonnes pratiques générales de sécurité. Par exemple, des certifications de sécurité pour les fournisseurs de services cloud sont disponibles et devraient être obligatoires pour utiliser de tels services, l’exemple le plus marquant étant la famille de certifications SOC 2. Cette certification élargit les concepts de la norme ISO/IEC 27001 en exigeant que les entreprises mettent en œuvre des mesures de protection techniques et procédurales spécifiques pour garantir non seulement la disponibilité et l’intégrité du service fourni, mais également la sécurité des données spécifiques des clients et des utilisateurs. FedRAMP, avec ses différents niveaux d’impact, exigés par le gouvernement américain, constitue un autre exemple marquant de certification spécifique au secteur pour les fournisseurs de services cloud.

Ce ne sont là que quelques exemples parmi une longue liste de certifications qui existent, dont beaucoup sont spécifiques à des secteurs et à des zones géographiques.

 

Conclusion

SOLARSTORM constitue sans conteste un événement assez rare, simplement en raison du degré de planification, de l’exécution minutieuse et de l’attention portée au nettoyage. Cependant, son impact sur les entreprises affectées ne doit pas être ignoré en tant qu’événement unique.

Les équipes de sécurité disposent des moyens et des capacités nécessaires leur permettant non seulement de détecter ce genre d’attaques plus tôt que ce ne fut le cas ici, mais également d’en minimiser l’impact en limitant la capacité de l’adversaire à prendre pied et à se déplacer latéralement dans l’environnement.

Outre la surveillance de l’activité des systèmes et applications qui disposent d’un accès privilégié ou qui contiennent des informations sensibles, des contrôles d’accès spécifiques peuvent aider à compartimenter les systèmes de grande valeur.

Des contrôles et des restrictions d’accès pour les cibles de grande valeur peuvent être mis en œuvre en appliquant les concepts d’une architecture Zero Trust stricte :

  • Restreindre l’accès du trafic sortant du système ou de l’application à la liste minimale d’applications et de ressources requises pour remplir sa fonction, telle que documentée par le fournisseur.
  • Restreindre l’accès local aux applications à l’ensemble minimum de privilèges requis, tel que documenté par le fournisseur.
  • Restreindre l’accès à l’application ou au système aux seuls utilisateurs qui en ont besoin, exiger une authentification multifacteur et limiter l’autorisation dont disposent ces utilisateurs sur le système au minimum requis pour effectuer les tâches qui leur incombent.

Dans un monde tourné vers le cloud, dans lequel Internet remplace le réseau local, l’application des paradigmes traditionnels de sécurité des réseaux est vouée à l’échec. Alors que nous continuons à utiliser le cloud pour promouvoir un personnel mobile et une entreprise distribuée, les professionnels de la sécurité doivent repenser leur approche de la sécurisation des entreprises. Ce monde doit être sécurisé de manière cloud-native, avec des capacités de sécurité compatibles avec le cloud et une architecture Zero Trust stricte.

form submtited
Merci d'avoir lu l'article

Cet article a-t-il été utile ?

Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception

En envoyant le formulaire, vous acceptez notre politique de confidentialité.