mercredi, 28 février 2024

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

Crédit : Dreamstime

Comme la crise de Log4J a été claire, comprendre ce qui se trouve dans les applications de désépinglage du logiciel est crucial pour comprendre la posture de sécurité. Cela n’est pas moins vrai pour les services réseau.

L’infrastructure réseau d’entreprise est encore très liée au matériel dans les centres de données et les réseaux locaux et WAN, mais maintenant, il s’agit de plus en plus de logiciels.

En cette ère de 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 un 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 types différents 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.

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 à 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é n’a pas de vulnérabilité connue en son sein, un lá 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.

Open Source que vous ne connaissez peut-être pas

Considérez que l’OSS est probablement dissimulé 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 rapidité 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 de 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.

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 des fournisseurs qu’ils attestent qu’ils suivent des pratiques de développement sécurisées ou qu’ils montrent ce qu’ils ne 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.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici