De l’open source à la porte ouverte : le logiciel apparaît comme un risque pour le réseau

La pire vulnérabilité informatique de ces dernières années était dans un logiciel open source omniprésent un bogue aussi simple à exploiter que difficile à corriger.

La faille de sécurité Apache Log4j a ouvert la porte à des millions d’ordinateurs, mais l’étendue des dégâts n’est toujours pas entièrement comprise. Près d’un an plus tard, les responsables fédéraux et le Congrès discutent toujours de la manière d’éviter une autre catastrophe potentielle.

L’open source, c’est-à-dire le code ouvert à tous pour être utilisé ou modifié, peut être trouvé dans presque tous les types de technologies modernes. Il a servi de colonne vertébrale à Internet et est omniprésent dans l’économie, y compris dans le secteur de l’énergie.

Cela en fait un problème imminent pour la cybersécurité énergétique.

Bien sûr, [the Energy Department] est préoccupé par les logiciels open source, a déclaré Cheri Caddy, ancienne conseillère principale au DOE, actuellement directrice de la politique et des plans de cybersécurité au Bureau du directeur national de la cybersécurité. Les logiciels open source font partie de tout développement logiciel, qu’il s’agisse [operational technology] ou informatique. C’est juste omniprésent dans tout maintenant.

La faille de sécurité de Log4j a mis en évidence certaines des principales préoccupations : l’équipe de développement était petite, le logiciel était présent dans presque tous les secteurs et de nombreuses entreprises n’étaient même pas sûres d’avoir le code dans leurs produits.

Le problème, selon les experts, n’est pas que l’open source est intrinsèquement moins sûr que le logiciel propriétaire. Ce n’est pas. Mais quelques lignes de code peuvent être adoptées dans toute une industrie.

Lorsque ces quelques lignes contiennent une vulnérabilité sérieuse, cela peut être un problème pour les infrastructures critiques, y compris le réseau. Cela peut devenir une porte ouverte qui permet à des pirates malveillants d’entrer dans des systèmes critiques, en particulier lorsque les services publics ne savent même pas que la porte existe.

L’open source est partout

Dans le secteur de l’énergie, les logiciels open source sont partout, a déclaré Virginia Wright, responsable du programme de portefeuille de cybersécurité énergétique à l’Idaho National Laboratory (INL).

Wright gère un banc de test de vulnérabilité du réseau DOE appelé Cyber ​​Testing for Resilient Industrial Control Systems (CyTRICS). Le programme, géré par six laboratoires du DOE et dirigé par l’INL, débusque les vulnérabilités du logiciel qui gère le réseau électrique.

« Cent pour cent des systèmes que nous avons examinés contenaient des logiciels open source, a déclaré Wright.

CyTRICS travaille sur une base volontaire avec certains des plus grands fabricants d’équipements de réseau, comme Hitachi Energy et Schweitzer Engineering Laboratories. Une fois qu’une vulnérabilité est trouvée, le laboratoire contacte les fabricants avec des mesures d’atténuation potentielles pour aider à corriger le bogue.

Parfois, cela inclut des vulnérabilités connues du public. Étant donné que les logiciels open source sont disponibles gratuitement et largement utilisés, les fournisseurs peuvent ne pas être conscients qu’une vulnérabilité et un correctif existent même, a déclaré Wright.

Wright a déclaré que les laboratoires ont vu des fournisseurs d’équipements de grille vendre des versions plus anciennes de leurs produits avec des vulnérabilités et des correctifs connus. Certains de ces logiciels sont même mis à jour dans les propres systèmes de ces fournisseurs, et leurs clients l’achètent avec toutes les vulnérabilités associées, a déclaré Wright.

Pour éviter les logiciels présentant des vulnérabilités, les services publics « doivent utiliser eux-mêmes un processus d’évaluation et de test assez rigoureux », a-t-elle déclaré.

Le projet de loi bipartite sur les infrastructures codifie et place le programme CyTRICS sous le programme Cyber ​​Sense. D’ici septembre de l’année prochaine, le DOE vise à analyser environ 10% des composants critiques des systèmes énergétiques et à étendre les programmes de partenariats volontaires pour couvrir environ 15% de part de marché, selon l’objectif de performance sur deux ans du DOE.

Le DOE a également lancé un programme pilote pour une nomenclature logicielle axée sur l’énergie, similaire à l’étiquette des ingrédients de l’industrie alimentaire. Selon les experts, un tel label peut accroître la visibilité sur les logiciels qui exécutent l’infrastructure critique.

Le Congrès a également commencé à prendre de nouvelles mesures. Les sens. Gary Peters (D-Mich.) Et Rob Portman (R-Ohio), respectivement président et membre de premier plan du Comité sénatorial de la sécurité intérieure et des affaires gouvernementales, ont présenté un projet de loi qui ordonnerait à la Cybersecurity and Infrastructure Security Agency d’étudier moyens d’atténuer les risques dans les infrastructures critiques qui utilisent des logiciels open source.

Un compromis

La transparence des logiciels open source signifie que les pirates malveillants peuvent consulter le code source pour trouver de nouvelles vulnérabilités, a déclaré Keith Lunden, responsable de l’analyse des cybermenaces physiques chez la société de cybersécurité Mandiant.

Cependant, c’est une rue à double sens. Les chercheurs en cybersécurité ont le même accès, ils peuvent donc identifier et corriger ces vulnérabilités avant que les pirates malveillants n’aient la possibilité de les exploiter, a déclaré Lunden.

Et contrairement aux logiciels propriétaires, les logiciels open source n’ont pas de durée de vie. Les fournisseurs finiront par cesser de prendre en charge un produit logiciel ; la même chose n’est pas vraie pour l’open-source. Pour les systèmes industriels conçus pour fonctionner pendant des décennies, cette longévité est essentielle.

« Avec les logiciels open source, la communauté a accès à la source et peut développer indépendamment des correctifs indéfiniment, ce qui peut être un facteur important pour la sécurité OT », a déclaré Lunden.

C’est du moins l’idée.

La flexibilité de l’open source peut signifier qu’il se ramifie constamment dans un nouveau code : les particuliers et les entreprises peuvent l’adapter à leur utilisation, créant potentiellement de nouvelles vulnérabilités.

Thomas Pace, co-fondateur de la société de cybersécurité NetRise et ancien sous-traitant du DOE dans le domaine de la sécurité du contrôle industriel, a déclaré qu’il connaissait un important fournisseur de télécommunications qui prendrait des logiciels open source et réécrirait des parties du code.

« Cela introduit alors un ensemble de problèmes différent, n’est-ce pas ? Parce que maintenant, vous devez maintenir votre propre code plutôt que toute la communauté qui maintient le code », a-t-il déclaré. « Est-ce mieux, est-ce pire ? C’est un débat.

Un bogue open source peut également signifier un risque généralisé. En 2014, les pirates ont profité d’une vulnérabilité massive dans un programme de chiffrement open source appelé OpenSSL.

Mais l’incident, appelé Heartbleed, était une vulnérabilité unique. Une fois le bogue corrigé, il incombe aux fournisseurs et aux propriétaires de corriger leur système. Si, au lieu de cela, chaque fournisseur de logiciels créait sa propre version d’OpenSSL, il y aurait plusieurs vulnérabilités dans chaque version.

« Il s’agit donc d’un compromis », a déclaré Wright.

Les leçons de la « pire » vulnérabilité

La découverte de la vulnérabilité Log4j a incité la Maison Blanche à organiser un sommet sur la sécurité des logiciels open source en janvier dernier. La réunion, qui comprenait les meilleurs cyber-experts américains, des responsables d’agences et des leaders de l’open source comme la Linux Foundation, visait à améliorer la collaboration fédérale et privée afin que le logiciel soit plus sécurisé.

Au cours des mois qui ont suivi, la Cybersecurity and Infrastructure Security Agency a promu l’utilisation d’une nomenclature logicielle comme étape pour sécuriser les logiciels open source. CISA prévoit également de travailler avec la communauté de la sécurité open source pour identifier le code couramment utilisé dans les infrastructures critiques, dans le but de mieux comprendre où la collaboration peut avoir lieu.

Mais l’agence a souligné qu’il peut être difficile de travailler avec une communauté open source alors que, par définition, elle est ouverte à tous. Bien qu’il existe certaines fondations qui promeuvent le développement open source, les logiciels sont souvent développés par de petites équipes ou des individus seuls.

Entre-temps, la CISA, l’agence de sécurité nationale et le bureau du directeur du renseignement national ont publié les meilleures pratiques pour les développeurs open source afin de mieux sécuriser leur code.

En ce qui concerne la vulnérabilité Log4j, un risque important demeure, selon un rapport publié cette année par le comité d’examen de la cybersécurité du département de la sécurité intérieure.

Le conseil, créé par décret en 2021, a constaté que les systèmes utilisant la version vulnérable de Log4j seraient un problème majeur pendant « peut-être une décennie ou plus ».

Le rapport conclut que la vulnérabilité n’a pas entraîné de cyberattaques importantes contre les infrastructures critiques.

Mais NetRises Pace a appelé cela une déclaration impossible, et même le rapport note que ce n’est pas si simple.

« Bien que les fournisseurs de cybersécurité aient pu fournir des preuves anecdotiques d’exploitation, aucune source faisant autorité n’existe pour comprendre les tendances d’exploitation à travers les zones géographiques, les industries ou les écosystèmes. De nombreuses organisations ne collectent même pas d’informations sur l’exploitation spécifique de Log4j, et les rapports sont encore largement volontaires », a écrit le conseil dans le rapport.

En bref, les organisations elles-mêmes ne sont parfois pas conscientes d’avoir été ciblées par des pirates informatiques malveillants. Il n’y a pas de liste où le logiciel Log4j est installé.

Le rapport met également en évidence les «risques de sécurité propres à la communauté open source aux ressources limitées et basée sur le volontariat». Il nécessite des ressources centralisées pour aider les développeurs à s’assurer que leur code est créé selon les dernières normes de sécurité.

« Tout comme l’industrie du logiciel a permis la démocratisation de la programmation logicielle, la possibilité pour quiconque de générer des logiciels avec peu ou pas de formation formelle, nous devons également démocratiser la sécurité en assurant la sécurité par défaut dans les plates-formes utilisées pour générer, créer, déployer et gérer des logiciels. à grande échelle », conclut le rapport.