Vos périphériques réseau exécutent un firmware vulnérable. Vous ne le savez pas.
Un angle mort de la sécurité d’entreprise déjà identifié par les attaquants
1. La couche oubliée de votre surface d'attaque
Chaque équipe de sécurité a un processus de gestion des vulnérabilités. Qualys scanne les serveurs. Tenable regarde les points finaux. SIEM collecte les journaux. Le Patch Tuesday est sur tous les calendriers.
Mais posez une question simple à votre équipe : Quels sont les périphériques réseau qui exécutent un firmware avec un CVE critique connu en ce moment ?
La plupart des organisations ne peuvent pas répondre à cette question. Non pas parce qu'ils s'en fichent, mais parce que l'outillage n'a jamais été construit pour cela.
L’infrastructure réseau est le squelette de votre organisation. Les commutateurs transportent chaque paquet. Les routeurs connectent chaque site. Les pare-feu appliquent toutes les politiques. Les points d'accès sont le point d'entrée pour tous les appareils sans fil dans vos bâtiments. Ces appareils fonctionnent 24 heures sur 24, 7 jours sur 7, ils sont rarement redémarrés et leurs versions de firmware ne sont presque jamais suivies avec la même rigueur que les logiciels sur les serveurs ou les points de terminaison.
Les points d’accès méritent une mention spéciale ici. Ils sont souvent déployés en grand nombre, gérés par des contrôleurs sans fil ou des plates-formes cloud distinctes, et discrètement oubliés une fois en ligne. Pourtant, ils exécutent des piles de firmware intégrées complètes - et ils se trouvent à la périphérie physique de votre réseau, accessible par toute personne disposant d'un adaptateur Wi-Fi à portée.
La vérité inconfortable : un commutateur ou un point d'accès qui exécute le même firmware depuis 3 ans présente presque certainement au moins une vulnérabilité critique connue du public. La question est de savoir si quelqu'un dans votre organisation sait lequel.
2. Pourquoi le firmware est différent - et plus difficile à suivre
Les scanners de vulnérabilité traditionnels ont été construits autour des systèmes d'exploitation et des applications. Ils interrogent un inventaire logiciel connu, croisent une base de données CVE et produisent une liste.
Le firmware du périphérique réseau casse chacune de ces hypothèses :
Aucune interface de requête standard - Les versions du firmware ne sont pas exposées par les protocoles de numérisation comme les versions du système d'exploitation le sont
Schémas de versionnage fragmentés —
15.2(4)M,ArubaOS 10.4.0.3,FortiOS 7.4.1- aucune de ces cartes n'est propre aux identifiants CVE sans logique spécifique au fournisseurSensibilité des sous-versions - la même branche de firmware peut être vulnérable dans une sous-version et patchée dans la suivante
Hétérogénéité du protocole - de nombreux périphériques exposent uniquement les informations de version via SSH CLI, API REST propriétaires ou NETCONF, chacun variant selon le fournisseur
Complexité multi-fournisseur - Cisco + Aruba + Fortinet + Juniper + Ubiquiti + Ruckus multiplie cette fragmentation de façon exponentielle, en particulier lorsque les contrôleurs sans fil gèrent des centaines d'AP chacun exécutant leur propre version du firmware
Le résultat ? La plupart des organisations maintiennent une visibilité structurée nulle sur la posture de sécurité du firmware de leur infrastructure réseau. Au mieux, une feuille de calcul mise à jour il y a six mois.
3. Le problème du cycle de vie: les appareils EoL se cachent en pleine vue
Les vulnérabilités du firmware sont une partie du problème. Le matériel de fin de vie (EoL) est l'autre - et ils sont étroitement liés.
Lorsqu'un fournisseur déclare la fin de vie d'un appareil, il cesse d'émettre des mises à jour du firmware. Tout CVE découvert après cette date ne sera jamais corrigé. L'appareil devient vulnérable de façon permanente par conception.
Pourtant, dans la plupart des environnements d’entreprise, les appareils EoL continuent de fonctionner pendant des années après la fin de leur cycle de vie. Les raisons sont toujours les mêmes : cycles budgétaires, complexité de la migration, et le fait que le commutateur « fonctionne toujours » et que personne ne l’a remarqué vieilli. Les points d'accès sont particulièrement enclins à cela - déployés dans des carreaux de plafond sur des dizaines d'étages, ils ont tendance à survivre à leur fenêtre de support simplement parce que personne ne les suit individuellement.
Un appareil qui est EoL n'est pas seulement une infrastructure vieillissante - c'est une vulnérabilité non corrigée avec un statut permanent. Il n'y a pas de solution. La seule solution est le remplacement.
Le problème de la composition: les informations sur le cycle de vie sont dispersées sur les portails des fournisseurs, les bulletins de produits et les PDF qui changent sans préavis. Il n'y a pas de flux unique faisant autorité. Le suivi manuel de l'EoL dans un environnement multifournisseur n'est pas une tâche opérationnelle réaliste.
La plupart des organisations découvrent leur exposition à l’EoL de deux façons : lors d’un audit de conformité ou après un incident. Ce n'est pas non plus le bon moment pour le découvrir.
4. Suivre les CVE sans connaître les firmwares produit surtout du bruit
Les équipes de sécurité reçoivent des flux CVE. Ils souscrivent aux avis aux vendeurs. Ils ont des règles SIEM qui tirent sur de nouveaux CVE critiques. Mais sans savoir exactement quelle version du firmware chaque appareil exécute, chaque alerte CVE n’a aucun sens.
CVE-2025-20352 - le SNMP zero-day critique affectant plus de 2 millions de périphériques Cisco - affecte-t-il réellement votre réseau ?
Vous ne pouvez répondre que si vous savez :
Quels appareils de votre infrastructure exécutent Cisco IOS ou IOS-XE
La version exacte du firmware qui fonctionne sur chacun de ces appareils
Si ces versions entrent dans la gamme affectée dans l'avis
Si un firmware patché a déjà été déployé
Sans cet inventaire, les équipes de sécurité sont laissées à choisir entre deux mauvaises options: traiter chaque CVE comme potentiellement affecter chaque appareil (fatigue d'alerte, paralysie opérationnelle), ou supposer que les appareils sont bien parce que personne n'a signalé un problème (optimisme aveugle).
Ce n’est pas non plus une posture de sécurité. Les deux sont des passifs.
5. À quoi ressemble une véritable gestion des vulnérabilités fondée sur les firmwares
Une gestion efficace de la sécurité du firmware nécessite trois fonctionnalités :
Inventaire précis et en temps réel du firmware
Vous devez savoir, pour chaque appareil sur votre réseau, la version exacte du firmware - pas une estimation, pas ce qui a été déployé le trimestre dernier. L'inventaire doit être mis à jour automatiquement lorsque les appareils sont corrigés ou remplacés, et couvrir l'hétérogénéité complète du fournisseur de votre environnement.
Corréler les CVE avec les versions de firmware
Un CVE affectant "Cisco IOS" n'est pas utile. Un CVE affectant "Cisco IOS 15.2(4)M à 15.6(3)M" est. Le moteur de vulnérabilité doit mapper la version exacte du firmware de chaque appareil aux plages spécifiques affectées publiées dans les avis aux fournisseurs - et ne faire apparaître que les CVE qui sont véritablement pertinentes pour votre inventaire.
Suivre la fin de vie de chaque équipement
Chaque appareil doit porter son état de cycle de vie : actuellement pris en charge, approchant EoL, ou déjà passé. Ce contexte transforme les données de vulnérabilité en priorisation exploitable. Un appareil qui est EoL avec deux CVE critiques est fondamentalement différent d'un appareil pris en charge qui peut être patché.
6. Comment ConnectMyAssets résout ce problème
ConnectMyAssets a conçu le module de vulnérabilité qui manquait aux équipes réseau - et nous sommes la seule plate-forme sur le marché à aborder la sécurité des périphériques réseau de cette façon.
Découverte automatique du firmware sur l'ensemble de votre infrastructure
ConnectMyAssets se connecte à tous les appareils de votre infrastructure réseau grâce à un moteur d'intelligence propriétaire multi-constructeurs - spécialement conçu pour gérer toute la diversité des fabricants, des générations de firmwares et des modèles de communication trouvés dans les environnements d'entreprise réels. Commutateurs, routeurs, pare-feu et points d'accès. Pas d'agents. Aucun inventaire manuel. Pas de tableurs. La CMDB reste à jour automatiquement, dans des environnements multi-constructeurs couvrant Cisco, Aruba, Fortinet, Juniper, Ubiquiti, Ruckus et bien d'autres - y compris les contrôleurs sans fil gérant de grands déploiements AP.
Évaluer les CVE en fonction du firmware
Notre moteur de vulnérabilité croise la version du firmware de chaque appareil avec une base de données CVE activement maintenue avec une normalisation spécifique au fournisseur. Nous ne nous contentons pas de surface CVE qui mentionnent un nom de fournisseur - nous correspondons exactement aux plages de versions affectées. Le résultat : une liste des appareils réellement exposés, avec des scores CVSS et des conseils de remédiation. Pas une liste des appareils qui pourraient être affectés.
Lorsqu'un nouveau CVE critique est publié - comme CVE-2025-20352, le SNMP zero-day qui a exposé plus de 2 millions de périphériques Cisco - ConnectMyAssets vous indique immédiatement quels périphériques de votre infrastructure exécutent le firmware affecté. Pas hypothétiquement. Concrètement.
Une visibilité intégrée sur les fins de vie
Chaque appareil de votre inventaire ConnectMyAssets porte son statut de cycle de vie. Les appareils approchant de la fin de vie sont signalés de manière proactive. Les appareils qui ont déjà dépassé leur date d'EoL apparaissent dans une vue dédiée, de sorte que vous pouvez gérer la planification du remplacement avant d'utiliser une infrastructure non prise en charge indéfiniment.
Combiné avec les données du firmware CVE, cela vous donne une matrice de risques qui n'existait pas auparavant: quels appareils sont EoL, qui transportent des CVE non corrigés, et qui sont les deux - ceux qui appartiennent immédiatement en haut de votre carnet de travail de remédiation.
L’essentiel à retenir
L'infrastructure réseau est trop critique pour être gérée avec des feuilles de calcul et des PDF de fournisseurs. Les vulnérabilités du firmware sont réelles, elles sont activement exploitées et elles affectent les appareils que votre outillage de sécurité existant n’a jamais été conçu pour couvrir.
Les organisations qui seront résilientes sont celles qui comblent cet écart avant qu’un attaquant ne le trouve. Cela signifie savoir exactement quel firmware chaque appareil exécute, quels CVE l'affectent et quels appareils ont dépassé leur cycle de vie pris en charge.
C'est ce que ConnectMyAssets a été conçu pour vous donner.
