Comme l'a clairement montré la crise Log4J, il est essentiel de comprendre ce que contient le logiciel qui sous-tend les applications afin de bien évaluer sa posture de sécurité. Et cela est tout aussi vrai pour les services réseau. Certes, l'infrastructure des réseaux d'entreprise est encore très liée au hardware du datacenter, au réseau local LAN et au réseau étendu WAN, mais elle est de plus en plus liée aux logiciels. À l'ère des réseaux SDN définis par logiciel, les appliances réseau, dont le nombre ne cesse de croître, ne sont plus que des logiciels propriétaires fonctionnant sur du matériel de commutation générique ou même sur un simple serveur x86 avec des cartes réseau supplémentaires. Du fait de ce déplacement du matériel vers le logiciel, les piles logicielles exécutant le réseau ont introduit une nouvelle source de risque et d'inquiétude pour la cybersécurité. La capacité de l’IT à fournir l'accès aux services, et par extension l'intégrité des données de l'entreprise, repose sur une base de logiciels réseau et de gestion du réseau. Mais sur quoi repose cette base ? Probablement que même l'équipe réseau ne le sait pas. Examinons les trois types de logiciels réseau que l’on trouve dans l’entreprise : open source, propriétaire avec open source intégré, et entièrement propriétaire. 

L'Open Source dont on connaît l’existence

Les composants réseau de logiciels open source (OSS) ne manquent pas - ClearOS, Open vSwitch, ONOS, DeNT, pfSense, SoNIC, Stratum, Untangle, pour n'en citer que quelques-uns - tout comme les offres commerciales associées. Les options de commutation, de routage et de sécurité sont de plus en plus nombreuses, et les différents packages autonomes arrivent à maturité. Si l’on ajoute à cela l’ensemble beaucoup plus large d'outils pour la surveillance et la gestion du réseau comme Cacti, Checkmk, Nagios, Pandora, Prometheus, Zabbix, le nombre de possibilités augmente alors de façon spectaculaire. Le problème est que les entreprises ne savent généralement pas ce que contiennent réellement tous ces outils. Et même si un outil donné ne comporte pas de vulnérabilité connue, comme celle qui affectait log4j, rien ne dit qu’il ne sera pas vulnérable au prochain compromis qui se présentera. Et il pourrait se passer beaucoup de temps entre le moment où l’exploitation de la vulnérabilité dans la nature est découverte et celui où l’information parvient au service IT. Tout le monde ne va pas auditer tout son code pour savoir s'il contient des composants vulnérables, mais tout le monde devrait se préparer à effectuer ou à consommer des analyses de code automatisées sur ce type de systèmes. Grâce à une initiative du gouvernement fédéral des États-Unis, il sera bientôt possible de savoir quel code est utilisé grâce aux inventaires logiciels ou Software Bills of Materials (SBOM), qui répertorient de manière détaillée tous les composants entrant dans un logiciel, y compris les composants tiers. 

L'Open Source dont on ne connait peut-être pas l’existence

Il faut garder à l’esprit qu’il y a probablement toujours du code open source caché dans certains logiciels propriétaires du réseau. C’est exactement ce qu’a révélé la faille affectant la bibliothèque Log4j : le logiciel libre avait été utilisé dans toutes sortes d'applications internes et commerciales. Ce que savent peut-être les développeurs, mais probablement pas les membres de l'équipe réseau. La même chose pourrait se produire avec toutes sortes d'outils et de plates-formes réseau propriétaires, avec n'importe lequel des dizaines d'autres projets OSS couramment utilisés : bibliothèques mathématiques, bibliothèques graphiques, bases de données, etc. Au nom de la rapidité et de l'innovation, les développeurs de logiciels travaillent rarement à partir de rien, et un gros logiciel peut s'appuyer sur des dizaines d'autres.

Piles propriétaires cachées

Parfois, la dépendance cachée se trouve dans un autre logiciel propriétaire, et non dans un paquet OSS. C’est le cas de très nombreuses vulnérabilités révélées au cours de la dernière décennie et affectant les piles TCP/IP commerciales : Ripple20, un ensemble de vulnérabilités affectant la pile TCP/IP Treck ; Name:Wreck, un ensemble de vulnérabilités affectant, entre autres, les piles Express Logic (désormais Microsoft) NetX et Siemens Nucleus Net time ; et les piles TCP/IP utilisées dans les appareils IOT largement déployés. Ce type de vulnérabilité peut également affecter la sécurité de l'infrastructure réseau. À ce stade, personne ne s’attend à ce que chaque boutique IT examine chaque ligne de code de chaque application pour y chercher des problèmes de sécurité. Cependant, le gouvernement fédéral prend les devants sur certains aspects de ce problème en demandant aux fournisseurs d'attester qu'ils suivent des pratiques de développement sécurisées ou de dire où ils ne le font pas, comment ils atténuent les risques et quand ils le feront. Et ils doivent, sur demande, produire un inventaire SBOM complet. Les entreprises devraient réclamer des SBOM pour les logiciels qu'elles achètent et exécutent, en particulier ceux sur lesquels elles construisent leur infrastructure de réseau.