Nouvelles Du Monde

Les vulnérabilités logicielles présentent un risque pour l’infrastructure réseau

Les vulnérabilités logicielles présentent un risque pour l’infrastructure réseau

Comme l’a clairement montré la crise de Log4J, il est essentiel de comprendre ce qui se trouve dans le logiciel désépinglant vos applications pour comprendre votre posture de sécurité. Cela n’est pas moins vrai pour vos services réseau.

L’infrastructure de réseau d’entreprise concerne encore beaucoup le matériel dans les centres de données et les réseaux LAN et WAN, mais elle devient de plus en plus une question de logiciel.

À l’ère des réseaux définis par logiciel, un nombre toujours croissant d’appliances réseau ne sont que des logiciels propriétaires exécutés sur du matériel de commutation générique ou même un serveur x86 standard avec des cartes réseau supplémentaires. Ce changement d’accent du matériel au logiciel a fait des piles logicielles exécutant le réseau une nouvelle source de risque et d’inquiétude pour la cybersécurité.

La capacité de l’informatique à fournir l’accès aux services, et par extension l’intégrité des données d’entreprise, repose sur une base de réseau et de logiciels de gestion de réseau. Mais sur quoi repose cette fondation ? Même l’équipe réseau ne le sait probablement pas.

Examinons trois différents types de logiciels de réseau que l’on trouve dans l’entreprise : open source, propriétaire avec open source intégré et entièrement propriétaire.

Lire aussi  Haaland pourrait être le meilleur joueur de l'ère de la Premier League

Open Source que vous connaissez

Les composants réseau de logiciels open source (OSS) abondent – ClearOS, Open vSwitch, ONOS, DeNT, pfSense, SoNIC, Stratum, Untangle, pour n’en nommer que quelques-uns – et les offres commerciales les entourent. Le nombre d’options de commutation, de routage et de sécurité augmente et les packages individuels arrivent à maturité. Ajoutez à cela l’ensemble beaucoup plus large d’outils disponibles pour la surveillance et la gestion du réseau – Cacti, Checkmk, Nagios, Pandora, Prometheus, Zabbix – et le nombre de possibilités augmente considérablement.

Le fait est que les entreprises ne savent généralement pas ce qu’il y a réellement dans tous ces outils. Et même si un outil donné ne contient pas de vulnérabilité connue, comme le log4j, il pourrait certainement être vulnérable au prochain compromis de ce type qui se présente. Et il pourrait y avoir un intervalle inconfortablement long entre le moment où un exploit de cette vulnérabilité est découvert dans la nature et le moment où l’information parvient au service informatique.

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 à faire ou à utiliser des analyses de code automatisées sur ces types de systèmes. Grâce à une poussée du gouvernement fédéral, il y aura bientôt un moyen de découvrir quel code est utilisé : les nomenclatures logicielles (SBOM), qui sont des listes détaillées de tous les composants qui entrent dans un progiciel, y compris les composants tiers .

Lire aussi  La NASA confirme qu'un astéroïde de 310 pieds survolera la Terre aujourd'hui

Open Source que vous ne connaissez peut-être pas

Considérez que l’OSS est probablement caché sous les couvertures de certains des logiciels propriétaires de votre réseau. C’était un élément majeur du gâchis log4j : OSS avait été utilisé dans toutes sortes d’applications internes et commerciales. Les développeurs le savent peut-être, mais les membres de l’équipe réseau ne le savent probablement pas.

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 vitesse et de l’innovation, les développeurs de logiciels travaillent rarement entièrement à partir de zéro, et un gros progiciel 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 package OSS. Considérez les très nombreuses vulnérabilités révélées au cours de la dernière décennie 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 piles, Express Logic (maintenant 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.

Lire aussi  grèves - Prenez-vous et taureau!

Personne ne suggère à ce stade que chaque magasin informatique puisse examiner chaque ligne de code dans chaque application pour des problèmes de sécurité. Cependant, le gouvernement fédéral prend les devants sur certains aspects de ce problème en exigeant que les fournisseurs attestent qu’ils suivent des pratiques de développement sécurisées ou montrent où ils ne le font pas, comment ils atténuent les risques et quand ils le feront. Et ils doivent, sur demande, produire un SBOM complet.

Les entreprises devraient réclamer des SBOM pour les logiciels qu’elles achètent et exécutent, en particulier les éléments sur lesquels elles construisent leur infrastructure réseau.

Rejoignez les communautés Network World sur Facebook et LinkedIn pour commenter les sujets qui vous tiennent à cœur.

Copyright © 2022 IDG Communications, Inc.

Facebook
Twitter
LinkedIn
Pinterest

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

ADVERTISEMENT