Lorsqu'on évoque les failles de cybersécurité, l'attention du public se porte principalement sur les pirates informatiques, et non sur les ingénieurs logiciels. Pourtant, l'histoire montre que les failles les plus dévastatrices proviennent souvent du code même auquel nous faisons confiance pour sécuriser nos systèmes les plus sensibles. La triste réalité est la suivante : si vous ne pouvez pas consulter le code source et vérifier l'intégrité et la provenance de ses auteurs, vous ne pouvez pas être certain qu'il est exempt de portes dérobées.
Les logiciels propriétaires, par nature, exigent la confiance, non seulement envers le fournisseur, mais aussi envers chaque personne ayant contribué à leur code source. Dans des secteurs comme la défense, le renseignement, la finance et d'autres secteurs réglementés, la confiance aveugle n'est plus acceptable. Nous avons besoin d'une politique stricte : tout fournisseur de logiciels propriétaires vendant des logiciels destinés à des infrastructures critiques devrait être tenu responsable. conditions 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 modèles. L'histoire du cyberespionnage à fort impact regorge d'exemples où des acteurs sophistiqués ont introduit des portes dérobées de manière quasiment indétectable jusqu'à ce que les dégâts soient causés.
Étude de cas 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 pare-feu ScreenOS, le logiciel chargé de sécuriser les réseaux du gouvernement américain, des entreprises de défense et des entreprises du Fortune 500. Il ne s'agissait pas d'un bug négligent. Il s'agissait d'une modification chirurgicale du générateur de nombres aléatoires Dual_EC_DRBG, permettant à l'attaquant de déchiffrer 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é intentionnellement ajoutée par un service de renseignement hautement qualifié. Le code était confidentiel et sa compromission est passée inaperçue pendant des années.
plats à emporter clés: Le code source fermé permettait à un initié bien placé (ou à un ancien initié) de modifier des fonctions cryptographiques de base qui étaient pratiquement impossibles à détecter pour les clients.
Étude de cas 2 : Compromis Solarigate / SolarWinds Orion
L'attaque de la chaîne d'approvisionnement de SolarWinds de 2020, baptisée « Solarigate », a été un chef-d'œuvre de furtivité. Les attaquants ont compromis le système de compilation de la plateforme de surveillance réseau Orion, 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, dont le Département de la Sécurité intérieure des États-Unis, plusieurs agences fédérales et des entreprises du secteur de la défense.
Il ne s'agissait pas d'une simple opération de script ; il s'agissait d'une attaque financée par l'État, dotée de ressources importantes et conçue pour se fondre dans le comportement normal des logiciels. 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.
plats à emporter clés: En l’absence d’audit ouvert, l’intégrité des logiciels à code source fermé dépend entièrement de la fiabilité et de l’expérience des personnes impliquées dans la chaîne de développement et de construction.
Étude de cas 3 : Incident de rootkit chez JPMorgan Chase
En 2014, JPMorgan Chase a subi l'une des plus importantes failles de sécurité de l'histoire du secteur bancaire américain, 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é, exploitant un accès de type 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 qu'une fois que les attaquants ont pu implanter des mécanismes de sécurité de bas niveau, ils peuvent manipuler les données, intercepter les 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 interne, l'incident souligne que les composants à source fermée dans l'infrastructure bancaire sont des cibles de choix pour les modifications furtives et persistantes.
plats à emporter clés: Dans les secteurs financiers et réglementés, une seule porte dérobée cachée dans un module à source fermée peut compromettre des milliards de dollars investis dans les défenses de sécurité et des années de travail de conformité.
Modèles révélés :
Retards de détection sur plusieurs années sont courantes, même dans les organisations dotées de SOC avancés.
Créer des environnements et mettre à jour les serveurs sont des points d’insertion privilégiés pour les acteurs des États-nations.
Le code source fermé masque les modifications malveillantes bien plus efficacement que leurs équivalents open source.
Systèmes de sécurité nationale et financiers de grande valeur sont systématiquement ciblés.
Le fossé politique : l'origine des développeurs est un problème de sécurité nationale
Nous avons des contrôles stricts à l'exportation de cryptographie, des restrictions à l'importation d'équipements de télécommunications en provenance de pays ennemis et des régimes de certification pour les chaînes d'approvisionnement en matériel. Pourtant, nous avons aucune garantie équivalente pour garantir que les humains qui écrivent et compilent le code source fermé pour les infrastructures critiques n'ont pas été formés par - ou n'ont pas travaillé pour - des services de renseignement étrangers connus pour leurs opérations cybernétiques 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 un historique bien documenté de développement et de déploiement de portes dérobées dans des systèmes ouverts et fermés. Si un fournisseur recrute un développeur issu d'un tel profil, sans divulguer ni atténuer les risques, les clients n'ont aucun moyen de savoir qu'ils font potentiellement confiance à du code écrit par quelqu'un spécifiquement formé pour insérer des vulnérabilités indétectables.
L'affirmation audacieuse : pas de certification, pas de déploiement
Les infrastructures critiques dans les secteurs de la défense, du renseignement et réglementés devraient refuser de déployer tout logiciel à code source fermé à moins que le fournisseur ne fournisse une certification contraignante que:
Aucun code du produit n'a été développé, compilé ou révisé par quiconque ayant déjà travaillé pour une organisation étrangère de renseignement ou de défense dans un rôle de cybersécurité, de renseignement sur les signaux ou d'exploitation de réseau.
Le fournisseur maintient un contrôle continu des antécédents de tous les contributeurs à la base de code source fermée.
Le logiciel est soumis à des contrôles d'intégrité périodiques au niveau binaire par un laboratoire de sécurité indépendant basé aux États-Unis et bénéficiant d'une autorisation gouvernementale.
Il ne s'agit pas de xénophobie ou de protectionnisme, mais de réalité opérationnelle. Les incidents de portes dérobées chez Juniper, SolarWinds et bien d'autres ont démontré que la chaîne de développement est 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 exécute ces systèmes.
Conclusion : faire confiance, mais exiger la provenance
Sur le champ de bataille cybernétique moderne, la frontière entre défense et attaque est ténue, et nombre des meilleurs ingénieurs du monde ont porté les deux casquettes. Pour les applications grand public non réglementées, ce risque est peut-être acceptable. Pour les logiciels contrôlant les systèmes de commandement nucléaire, les satellites de défense, les chambres de compensation financières et le contrôle aérien ? Ce n'est pas le cas.
Les logiciels propriétaires sont des boîtes noires, et l'histoire a montré que ces boîtes peuvent cacher des couteaux très tranchants. Tant que nous n'exigerons pas de garanties vérifiables quant à l'auteur du code, chaque déploiement sera un acte de confiance aveugle. Pour les infrastructures critiques, la confiance aveugle ne constitue pas une stratégie de sécurité.