L’acte de cyberespionnage révélé en décembre dernier n’en finit pas de surprendre. Baptisé Solorigate par Microsoft, il s’agit d’une série de compromissions dont le vecteur principal fut la plateforme de gestion et de surveillance informatique Orion de la firme Solarwinds. Si l’attaque impressionne par la nature de ses victimes et par son ampleur, à ce jour, toute la lumière n’a toujours pas été faite sur cette affaire. D’un côté, la liste des victimes de cet acte n’est pas arrêtée et de l’autre, des zones d’ombres persistent toujours sur les modalités d’exécution ainsi que sur ses véritables auteurs.
Pour autant, cela n’empêche pas aujourd’hui de s’interroger sur les raisons qui ont permis le succès de cette attaque ainsi que sur les actions à mettre en œuvre afin d’empêcher que cela ne puisse se reproduire.
S’agissant ici d’une attaque supply chain, il est nécessaire d’avoir une double perspective si nous souhaitons apporter des réponses à ces questions. Un premier niveau de réponse sera apporté dans cet article selon le point de vue des éditeurs, tandis qu’un second niveau tentera d’apporter des éclaircissements selon le point de vue des entreprises clientes. Cette deuxième partie sera traitée dans un prochain article.
Cet article fait partie d’une série de 3 autres articles, retrouvez la première partie : [Solarwinds : quelles leçons tirer de la cyberattaque ciblant la supply chain ?]
Infrastructure vs application
Tout d’abord, comme il a été développé dans la première partie de cette série d’articles, une attaque sur la chaîne d’approvisionnement cherche généralement à exploiter le point le plus vulnérable de cette chaîne pour ensuite opérer un rebond sur la cible finale. Dans le cas de Solarwinds, on pourrait supposer qu’Orion n’a pas été ciblé en premier lieu parce qu’il s’agissait du maillon le plus faible de la chaîne, mais plutôt pour ses accès privilégiés dans le cœur des réseaux de ses 18 000 entreprises utilisatrices. Le maillon le plus faible a été troqué contre celui pouvant apporter le plus d’impact.
Il faut reconnaitre que les attaquants ont procédé avec patience, méthodologie et minutie. En octobre 2019, ils testent pour la première fois leur capacité à insérer du code dans les environnements de développement d’Orion en y ajoutant une classe bénigne. En mars 2020, ils ont pu insérer du code malicieux dans une version de mise à jour de la plateforme, ladite version ayant été signée numériquement par Solarwinds avant d’être packagée puis envoyée sous forme de mise à jour légitime aux firmes utilisatrices.
Et pourtant, de nos jours, les standards de développement tendent vers plus de sécurité notamment sur la mise en place de différents points de contrôle de sécurité tout au long du cycle de vie de développement d’applications (audit de code, tests de vulnérabilités, tests de pénétration…). Le code lui, est signé avant d’être packagé puis déployé.
Toutefois, si malgré ces éléments, de telles compromissions sont encore possible, c’est parce que les actions de sécurité réalisées dans le cadre du cycle de vie de développement des applications se portent uniquement sur les applications développées et non sur l’infrastructure de développement elle-même. En novembre 2019 par exemple, un analyste sécurité a alerté les responsables de Solarwinds sur le fait que leur serveur de mise à jour était accessible via un mot de passe particulièrement faible et que celui-ci pouvait être retrouvé sur les dépôts publics Github. Évidemment, rien ne dit qu’il s’agit là du point d’entrée des attaquants, mais il illustre à quel point les questions de sécurité relatives à l’infrastructure sont quelque peu délaissées.
Rectifier le tir
De toute évidence, il faut remédier à cela. Il est donc impératif de renforcer la sécurité l’infrastructure de développement ainsi que des applications à développer elles-mêmes.
Pour ce faire, il est nécessaire d’implémenter tout un panel de contrôles. Le premier d’entre eux consiste à réaliser un inventaire exhaustif de l’ensemble des actifs composant l’infrastructure de développement. Ensuite, il est nécessaire d’auditer l’intégralité de ces éléments, et ces audits devront remonter la présence de secrets codés en durs et/ou remonter la présence de mots de passe par défaut lorsqu’il y en a. Il peut également être pertinent de procéder à une recherche des codes pouvant appartenir à l’organisation sur des dépôts publics, de potentiels secrets peuvent également y figurer.
Une attention particulière doit également être apportée sur la gestion des identités et des accès. Il est impératif que chaque accès à l’infrastructure soit sécurisé par un mécanisme d’authentification forte. A cela s’ajoute la mise en place d’une gestion fine des identités et des droits avec une revue périodique de ces dernières. L’attribution des droits s’effectuant selon les principes du moindre privilège.
Enfin, il est essentiel d’assurer l’intégrité de l’intégralité du tunnel de développement. Dans le cas de Solarwinds, du code malicieux a pu être inséré dans l’environnement de développement et signé par Solarwinds lui-même. Cela indique l’importance de s’assurer que les éléments produits en sortie de chaque phase de développement correspondent effectivement à ce qui est a été attendu. Enfin, il faut permettre à chaque développeur de signer sa production de sorte que l’on puisse garantir à chaque instant que le code a bien été poussé par le bon développeur.
Pour vous assurer une bonne protection, n’hésitez pas à consulter notre développement d’applications sécurisées “by design”, qui repose sur nos équipes SecDevOps, comme le développe davantage la deuxième partie de cet article.
Par ailleurs, il peut être intéressant de baser une partie de son infrastructure sur le cloud car cela permet de partager les responsabilités de sécurité informatiques.
Des prestataires tels que Devoteam peuvent vous accompagner dans cette transformation et vous permettre de vous garantir la bonne sécurisation de votre réseau informatique.
