Lorsqu'il est question de failles dans la cybersécurité, l'attention du public se concentre sur les pirates informatiques, et non sur les ingénieurs en informatique. Pourtant, l'histoire a montré que les failles les plus dévastatrices proviennent souvent de l'intérieur même du code auquel nous faisons confiance pour sécuriser nos systèmes les plus sensibles. L'inconfortable vérité est la suivante : si vous ne pouvez pas voir le code source et si vous ne pouvez pas vérifier l'intégrité et la provenance des personnes qui l'ont conçu, vous ne pouvez pas être certain qu'il ne comporte pas de portes dérobées.
Les logiciels à code source fermé, de par leur nature, requièrent la confiance, non seulement du fournisseur, mais aussi de chaque personne ayant contribué à la base de code. Dans des secteurs comme la défense, le renseignement, la finance et d'autres industries réglementées, la confiance aveugle n'est plus acceptable. Nous avons besoin d'une politique stricte : tout fournisseur de logiciels à code source fermé vendant à des infrastructures critiques doit être requis de certifier qu'aucun de leurs développeurs n'a jamais travaillé pour un service de renseignement ou de défense étranger, notamment dans le domaine de la cybersécurité, ce qui pourrait leur permettre d'implanter des vulnérabilités cachées.
Il ne s'agit pas de paranoïa, mais de reconnaissance de schémas. L'histoire du cyber-espionnage à fort impact est jalonnée d'exemples où des acteurs sophistiqués ont introduit des portes dérobées de manière pratiquement indétectable jusqu'à ce que le mal soit fait.
Étude de cas n° 1 : la porte dérobée NetScreen / ScreenOS (Juniper Networks)
Fin 2015, Juniper Networks a révélé qu'un code non autorisé avait été inséré dans son système d'exploitation de pare-feu ScreenOS - le logiciel chargé de sécuriser les réseaux du gouvernement américain, des entreprises de défense et des sociétés figurant au classement Fortune 500. Il ne s'agissait pas d'un bogue négligé. Il s'agissait d'une modification chirurgicale du générateur de nombres aléatoires Dual_EC_DRBG, qui permettait à l'attaquant de décrypter le trafic VPN à volonté.
Les chercheurs en sécurité ont ensuite conclu que l'explication la plus plausible était que la porte dérobée avait été ajoutée intentionnellement par un service de renseignement très compétent. Le code était fermé et sa compromission est passée inaperçue pendant des années.
Principaux enseignements : Le code source fermé permettait à un initié bien placé (ou à un ancien initié) de modifier les fonctions cryptographiques de base, ce qui était pratiquement impossible à détecter pour les clients.
Étude de cas 2 : Compromission Solarigate / SolarWinds Orion
L'attaque de la chaîne d'approvisionnement de SolarWinds en 2020, baptisée "Solarigate", était un chef-d'œuvre de furtivité. Les attaquants ont compromis le système de construction de la plateforme de surveillance du réseau Orion, en injectant une porte dérobée signée numériquement et distribuée dans le cadre de mises à jour logicielles légitimes. Des milliers de clients l'ont installée, notamment le ministère américain de la sécurité intérieure, plusieurs agences fédérales et des entreprises de défense.
Il ne s'agissait pas d'une opération de script-kiddie, mais d'une attaque financée par l'État et disposant de ressources importantes, conçue pour se fondre dans le comportement normal d'un logiciel. La base de code d'Orion était fermée, le processus de construction opaque et le point d'insertion contrôlé par des initiés de confiance.
Principaux enseignements : En l'absence d'audit ouvert, l'intégrité des logiciels à code source fermé dépend entièrement de la fiabilité et des antécédents des personnes qui interviennent dans la chaîne de développement et de fabrication.
Étude de cas n° 3 : l'incident du Rootkit de JPMorgan Chase
En 2014, JPMorgan Chase a subi l'une des plus grandes violations de l'histoire bancaire américaine, avec le vol des données personnelles de plus de 83 millions de clients. Les enquêtes ont révélé que les attaquants avaient atteint un niveau de persistance élevé, en s'appuyant sur un accès au niveau du rootkit pour garder le contrôle et échapper à la détection. Bien que l'attaque ait impliqué plusieurs étapes et acteurs, elle a mis en évidence le fait qu'une fois que les attaquants peuvent implanter des crochets de bas niveau, ils peuvent manipuler des données, intercepter des transactions et contourner les contrôles de sécurité standard.
Bien que JPMorgan n'ait pas confirmé publiquement si le rootkit provenait d'une infiltration de la chaîne d'approvisionnement ou d'une compromission par un initié, l'incident souligne que les composants à source fermée de l'infrastructure bancaire sont des cibles de choix pour des modifications furtives et persistantes.
Principaux enseignements : Dans la finance et les secteurs réglementés, une simple porte dérobée cachée dans un module fermé peut compromettre des milliards de dollars investis dans les défenses de sécurité et des années de travail de mise en conformité.
Motifs révélés :
Décalages de détection pluriannuels sont courantes, même dans les organisations dotées d'un SOC avancé.
Création d'environnements et mise à jour des serveurs sont des points d'insertion privilégiés pour les acteurs étatiques.
Les codes fermés masquent les modifications malveillantes bien plus efficacement que les équivalents à code source ouvert.
Systèmes financiers et de sécurité nationale de grande valeur sont systématiquement ciblés.
Le fossé politique : l'origine des développeurs est une question de sécurité nationale
Nous avons mis en place des contrôles stricts des exportations de cryptographie, des restrictions à l'importation de matériel de télécommunications provenant de pays adverses et des régimes de certification pour les chaînes d'approvisionnement en matériel. Pourtant, nous avons pas de garantie équivalente pour s'assurer que les personnes qui écrivent et compilent le code source fermé des infrastructures critiques n'ont pas été formées par - ou n'ont pas travaillé pour - des services de renseignement étrangers connus pour leurs cyber-opérations offensives.
L'unité 8200 en Israël, les unités cybernétiques du GRU et du SVR en Russie, l'unité 61398 de l'APL en Chine et d'autres divisions cybernétiques offensives dans le monde ont des antécédents bien documentés de développement et de déploiement de portes dérobées dans des systèmes ouverts et fermés. Si un fournisseur engage un développeur issu d'un tel milieu - sans divulguer ou atténuer le risque - les clients n'ont aucun moyen de savoir qu'ils font potentiellement confiance à un code écrit par quelqu'un qui a été explicitement formé pour insérer des vulnérabilités indétectables.
Une affirmation audacieuse : pas de certification, pas de déploiement
Les infrastructures critiques des secteurs de la défense, du renseignement et des secteurs réglementés doivent refuser de déployer tout logiciel à source fermée à moins que le vendeur ne fournisse une certification contraignante que :
Aucun code contenu dans le produit n'a été développé, compilé ou révisé par une personne ayant déjà travaillé pour une organisation étrangère de renseignement ou de défense dans un rôle de cybersécurité, de renseignement d'origine électromagnétique ou d'exploitation de réseau.
Le fournisseur vérifie en permanence les antécédents de tous les contributeurs à la base de code fermée.
Le logiciel est soumis à des contrôles d'intégrité périodiques de niveau binaire par un laboratoire de sécurité indépendant basé aux États-Unis et habilité par le gouvernement.
Il ne s'agit pas de xénophobie ou de protectionnisme, mais de réalité opérationnelle. Les incidents liés aux portes dérobées chez Juniper, SolarWinds et d'innombrables autres entreprises ont démontré que la chaîne de développement constitue une surface d'attaque pour la sécurité nationale. Nous verrouillons déjà l'accès physique aux sites critiques et aux chaînes d'approvisionnement en matériel ; il est temps d'appliquer la même rigueur aux personnes qui écrivent et compilent le code qui fait fonctionner ces systèmes.
Conclusion : Faire confiance, mais exiger la preuve
Sur le champ de bataille cybernétique moderne, la frontière entre la défense et l'attaque est mince, et bon nombre des meilleurs ingénieurs du monde ont porté les deux casquettes. Pour les applications grand public non réglementées, il s'agit peut-être d'un risque acceptable. Mais pour les logiciels qui contrôlent les systèmes de commandement nucléaire, les satellites de défense, les chambres de compensation financière et le contrôle du trafic aérien ? Ce n'est pas le cas.
Les logiciels à code source fermé sont des boîtes noires - et l'histoire a montré que les boîtes noires peuvent cacher des couteaux très aiguisés. Tant que nous n'exigerons pas des garanties vérifiables sur l'identité des concepteurs du code, chaque déploiement sera un acte de foi aveugle. Pour les infrastructures critiques, la confiance aveugle n'est pas une stratégie de sécurité.