Mises à jour firmware OT : qui les applique vraiment, et comment reprendre la main

Dans la plupart des usines, personne ne sait avec certitude qui est responsable des mises à jour firmware des équipements industriels.

La plateforme de ressources opérationnelles Cyberlead version Beta est désormais disponible gratuitement et sans engagement

Contexte

Le non-sujet qui devient un sujet

D’expérience, quand on pose la question en audit, la réponse est toujours la même. Les équipes de production pensent que c’est la DSI. La DSI pense que c’est le fournisseur. Et le fournisseur attend qu’on lui passe une commande de prestation. Résultat : les firmwares des automates, des capteurs et des équipements de supervision ne sont jamais mis à jour, ou alors lors d’une migration lourde tous les cinq à dix ans. Entre-temps, les vulnérabilités s’accumulent et les attaquants en profitent.

En 2025, la CISA a publié un rapport signalant une hausse de 40% des dispositifs ICS exposés sur Internet entre 2024 et 2025. Des éditeurs comme Siemens, Rockwell Automation et Schneider Electric publient des correctifs critiques tous les trimestres sur leurs gammes phares. Ces correctifs concernent des failles permettant, dans certains cas, une exécution de code à distance sur des automates en production. Le problème n’est pas le manque de correctifs disponibles. C’est l’absence totale de processus pour les appliquer.

Pourquoi c’est fondamentalement différent du patch IT classique

Dans le monde IT, on déploie des mises à jour via un gestionnaire centralisé, avec des fenêtres de maintenance nocturnes et un rollback automatique en cas de problème. En OT, rien de tout ça n’existe. Mettre à jour le firmware d’un automate Siemens S7-1500 en production, c’est souvent arrêter la ligne. Et arrêter la ligne, c’est une décision qui remonte au niveau direction générale, pas à la DSI.

Autre différence majeure : la durée de vie des équipements. Un serveur IT tourne 3 à 5 ans. Un automate OT peut rester en production 15 à 25 ans. Sur cette durée, le constructeur peut avoir arrêté le support ou décidé de ne plus publier de correctifs pour les versions anciennes. Le RSSI se retrouve à gérer un parc dont certains firmwares n’ont pas été touchés depuis l’installation initiale parfois en 2008 ou 2010.

Il faut aussi compter avec la validation fournisseur. En IT, on teste sur un environnement de préproduction et on déploie. En OT, le patch doit être validé par le constructeur pour chaque configuration terrain. Cette validation peut prendre des semaines, parfois des mois. C’est un frein réel mais un frein qu’on peut anticiper si on s’y prend suffisamment tôt.

5 mesures concrètes pour reprendre le contrôle

1. Inventorier les firmwares existants, version par version

Impossible de gérer ce qu’on ne connaît pas. La première étape est de constituer un inventaire exhaustif des équipements OT avec leur version de firmware actuelle. Des outils comme Claroty, Nozomi Networks ou Dragos permettent cette collecte de manière passive, sans perturber la production. L’objectif n’est pas la perfection : c’est d’identifier les équipements en version connue comme vulnérable, surtout ceux exposés à d’autres segments réseau.

2. Formaliser qui est responsable : RSSI, DSI ou équipes OT ?

C’est la question de gouvernance que personne ne veut trancher. Il faut la poser explicitement en réunion avec la direction de production, la DSI et la direction technique, et définir une matrice RACI claire. Dans la plupart des organisations matures que j’ai accompagnées, c’est l’équipe OT qui porte l’exécution, avec le RSSI comme garant du processus et de la conformité réglementaire.

3. Intégrer les mises à jour dans les fenêtres de maintenance planifiées

Les arrêts machines existent déjà dans toute usine : maintenance préventive annuelle, arrêts techniques trimestriels, révisions hebdomadaires sur certaines lignes. L’enjeu est de ne pas créer de fenêtres supplémentaires mais d’intégrer les mises à jour cybersécurité au même titre que les contrôles mécaniques. Cela nécessite d’anticiper avec les fournisseurs, souvent 3 à 6 mois à l’avance.

4. Exiger la validation fournisseur par écrit avant tout déploiement

Certains correctifs publiés par les éditeurs ne sont pas compatibles avec toutes les configurations terrain. Avant de déployer quoi que ce soit, obtenez par écrit la validation du fournisseur que le firmware est compatible avec votre configuration spécifique. Cette démarche protège aussi l’organisation en cas de dysfonctionnement post-mise à jour et peut valoir de l’or lors d’un audit ou d’une procédure assurance.

5. Mettre en place un suivi des CVE OT par équipement

Abonnez-vous aux bulletins de sécurité de vos principaux fournisseurs et croisez-les avec le catalogue KEV de la CISA. L’objectif n’est pas de traiter chaque CVE publiée, il y en a des centaines par an, mais d’identifier celles qui sont activement exploitées dans la nature et qui touchent vos équipements critiques. Ce suivi peut être assuré par un ingénieur cybersécurité industrielle ou délégué à un prestataire spécialisé.

Un cas concret : ce que révèle vraiment l’inventaire

Un industriel du secteur chimique avec qui j’ai travaillé avait 340 automates en production, sans aucun inventaire firmware existant. Quand on l’a constitué et croisé avec les CVE connues, on a identifié 23 équipements avec des failles critiques actives, dont 4 automates directement impliqués dans le contrôle de procédés à risque élevé. Le directeur de production ne savait pas. La DSI ne savait pas. Personne n’avait la mission explicite de le vérifier.

La bonne nouvelle : une fois la gouvernance clarifiée et l’inventaire constitué, les mises à jour prioritaires ont été traitées en moins de six mois, dans les fenêtres de maintenance existantes, sans arrêt supplémentaire de production. Le coût opérationnel réel était marginal. C’est toujours l’absence de processus qui coûte cher, jamais le patch lui-même.

Ce qu’il faut retenir

Le firmware est le socle de confiance d’un équipement industriel. Laisser cette couche non gérée, c’est accepter que n’importe qui ayant connaissance d’une CVE publique puisse potentiellement prendre la main sur vos machines. Le problème n’est pas technique, c’est organisationnel. La solution passe d’abord par clarifier qui est responsable, avant même de parler d’outils.

Ressources CyberLead

CyberLead met à disposition en mode béta une plateforme de ressources opérationnelles pour les professionnels de la cybersécurité : plus de 150 documents structurés, templates RSSI, régulations décryptées, guides ANSSI et ISO, fiches autorités, retours d’expérience.

Un accès unique, gratuit, sans engagement.

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !