Pourquoi un automate industriel ne se patche pas

Pourquoi un automate industriel ne se patche pas

Un automate industriel n’est pas un serveur Linux oublié derrière un pare-feu. Le corriger modifie un équipement qui pilote un procédé physique, avec des dépendances matérielles, logicielles et parfois humaines qui ne tolèrent pas l’improvisation. Le compromis central est brutal : un correctif réduit une exposition connue, mais peut introduire une indisponibilité ou un comportement dangereux.

Explication de la marmotte

Une machine qui contrôle une chaîne de fabrication ressemble à un appareil dont l’arrêt peut bloquer tout un atelier. Modifier son programme sert à corriger un défaut, mais une mauvaise modification peut aussi empêcher la machine de fonctionner au mauvais moment. Il faut donc préparer l’intervention avant de toucher au bouton.

→ Lire l’explication complète de la marmotte

Le compromis entre vulnérabilité et disponibilité OT

L’OT (Operational Technology) regroupe les systèmes qui surveillent ou commandent un procédé physique : fabrication, énergie, traitement de l’eau, transport ou bâtiment. L’ICS (Industrial Control Systems) désigne les systèmes de contrôle industriel qui composent cet environnement : automates programmables, postes d’ingénierie, interfaces opérateur, relais et équipements réseau industriels.

Patcher un automate consiste souvent à remplacer son micrologiciel, modifier un environnement d’exécution ou mettre à jour un logiciel de programmation. Ce changement ne corrige pas seulement une vulnérabilité. Il peut changer le comportement d’une bibliothèque de communication, invalider une signature de projet, imposer une nouvelle version d’outil d’ingénierie ou retirer la compatibilité avec une carte d’extension. Un correctif qui redémarre l’équipement au milieu d’une séquence de production ne constitue pas un succès de cybersécurité.

La position à tenir est donc nette : ne jamais appliquer un correctif directement sur un automate en exploitation parce qu’un bulletin de sécurité vient de tomber. Évaluer l’exploitabilité, qualifier l’impact du changement, tester sur une configuration représentative et préparer le retour arrière. L’absence de patch ne devient acceptable que si des mesures compensatoires mesurables réduisent réellement le chemin d’attaque.

Un score CVSS (Common Vulnerability Scoring System) élevé ne suffit pas à déclencher une opération. Une vulnérabilité accessible uniquement depuis le réseau d’ingénierie, lui-même isolé et sans accès distant, ne porte pas le même risque qu’une faille exploitable depuis un poste bureautique compromis. Les slides de vendeurs adorent les scores rouges. Un attaquant, lui, préfère les chemins réellement ouverts.

Avant toute campagne, maintenir un inventaire avec le modèle exact, la version de micrologiciel, les modules installés, le programme chargé, l’outil d’ingénierie compatible, les dépendances de réseau et la fenêtre d’arrêt validée. Sans cet inventaire, la gestion des correctifs devient une fouille archéologique avec un bouton de redémarrage.

Surface d’attaque des automates et contre-mesures

L’automate est rarement la première machine compromise. Le chemin habituel passe par un poste d’ingénierie, une station opérateur, un accès de maintenance distant, une clé amovible ou un équipement de réseau mal segmenté. Corriger l’automate tout en laissant le poste qui téléverse les programmes exposé revient à changer la serrure en laissant le passe-partout sur le paillasson.

Les protocoles industriels historiques présentent souvent peu ou pas d’authentification, de chiffrement ou de contrôle d’intégrité. Modbus/TCP, par exemple, permet d’émettre des commandes de lecture et d’écriture sans identité cryptographique native. Lorsqu’un attaquant atteint le segment concerné, il peut lire des registres, modifier des consignes ou provoquer des arrêts selon les droits implicites de l’équipement.

Les contre-mesures doivent couper le chemin avant l’automate :

• isoler les zones industrielles du réseau bureautique par filtrage explicite ;
• interdire les flux directs entre postes utilisateur et automates ;
• placer les services d’échange dans une DMZ (Demilitarized Zone), réseau tampon contrôlé entre deux zones de confiance différente ;
• imposer un bastion d’administration journalisé pour les opérations d’ingénierie ;
• contrôler les supports amovibles et analyser leur contenu avant introduction ;
• désactiver les services et ports non nécessaires, après validation par le fournisseur ;
• surveiller passivement les protocoles industriels sans injecter de trafic sur un réseau fragile.

La segmentation réseau réduit la probabilité d’atteindre l’automate, mais elle ne transforme pas un protocole sans authentification en protocole authentifié. Un flux autorisé vers Modbus/TCP autorise aussi les écritures Modbus/TCP. Le pare-feu ne lit pas les intentions, malgré les brochures qui lui prêtent parfois des dons de télépathie.

Le patch ne garantit pas non plus l’intégrité du programme chargé dans l’automate, l’absence de compte partagé sur le poste d’ingénierie, la qualité des règles de sûreté ou la disponibilité d’une pièce de rechange. La sûreté de fonctionnement reste un domaine distinct : empêcher une commande malveillante ne démontre pas qu’une commande légitime est sans danger.

Qualification d’un correctif de micrologiciel

La décision commence par quatre questions : la faille est-elle atteignable, une exploitation est-elle publiquement documentée, quels privilèges demande-t-elle et quelle conséquence physique résulte d’une compromission ? Cette analyse doit distinguer l’accès réseau, l’accès local et l’accès déjà privilégié. Une vulnérabilité nécessitant un accès physique au port de maintenance ne se traite pas comme une exécution de code à distance depuis une zone non maîtrisée.

La qualification doit reproduire la configuration de production : même référence d’automate, même modules d’entrée-sortie, même version du projet, mêmes échanges réseau et même séquence de redémarrage. Tester uniquement la mise à jour sur un châssis vide vérifie que le fichier se téléverse. Cela ne vérifie ni les temporisations, ni les alarmes, ni les interactions avec les équipements voisins.

Le plan de changement doit contenir les éléments suivants :

1. une sauvegarde exportée et vérifiée du programme, des paramètres et de la version précédente ;
2. un hash cryptographique du paquet de correctif récupéré depuis une source vérifiée ;
3. un média de restauration hors ligne et un poste d’ingénierie compatible ;
4. une procédure de retour arrière qui ne dépend pas d’un téléchargement Internet ;
5. des critères d’acceptation fonctionnels définis avec l’exploitation ;
6. une fenêtre d’intervention incluant le temps de diagnostic, pas seulement le temps théorique de mise à jour.

Un correctif sans procédure de retour arrière n’est pas une maintenance, c’est un pari. Or les automates ne négocient pas avec l’optimisme.

Le choix entre mise à jour immédiate et isolement renforcé dépend de la possibilité de maintenir les barrières compensatoires. Si un accès distant non maîtrisé, un protocole exposé ou un poste d’ingénierie partagé rendent la vulnérabilité atteignable, le correctif prioritaire est justifié après qualification accélérée. Si le procédé ne tolère aucun arrêt et que l’automate est isolé par conception, documenter le risque résiduel, renforcer la segmentation et planifier le correctif au prochain arrêt maîtrisé.

Exemple de filtrage entre bastion et réseau industriel

Le filtrage ne remplace pas une mise à jour, mais il réduit la surface exposée pendant la qualification. L’exemple suivant applique une politique restrictive avec nftables : seul le bastion d’ingénierie 10.42.10.20 peut joindre les automates Modbus/TCP du sous-réseau 10.42.30.0/24.

#!/usr/sbin/nft -f

table inet ot_filter {
  chain forward {
    type filter hook forward priority filter;
    policy drop;

    # Autoriser les réponses aux connexions déjà établies.
    ct state established,related accept

    # Autoriser uniquement le bastion vers Modbus/TCP des automates.
    ip saddr 10.42.10.20 ip daddr 10.42.30.0/24 tcp dport 502 accept

    # Tout autre flux entre les deux zones reste bloqué.
  }
}

Charger ce fichier avec nft -f /etc/nftables.d/ot-filter.nft uniquement après avoir validé que le pare-feu route effectivement les deux réseaux. Le port 502 donne accès au protocole, pas à une opération particulière : un bastion compromis peut toujours envoyer des écritures. Limiter la source, journaliser les sessions et retirer le flux hors fenêtre de maintenance réduisent cette exposition.

L’accès au bastion doit reposer sur des identités nominatives, une authentification multifacteur et des comptes d’administration séparés. Les principes décrits dans la section identités et fédération restent applicables, avec une réserve : certains environnements industriels ne supportent pas les agents modernes. Dans ce cas, placer le contrôle d’identité en amont, sur le bastion ou la passerelle distante, plutôt que d’installer un logiciel non validé sur le poste d’ingénierie.

Exploitation, sauvegarde et reprise après échec

Les sauvegardes d’automates doivent inclure plus que le projet applicatif : micrologiciel, configuration matérielle, tables de variables, paramètres de communication, licences d’outils et documentation des versions. Une archive de programme sans l’outil capable de la restaurer est un objet décoratif, parfois très cher.

Stocker ces sauvegardes hors ligne ou dans un dépôt à accès fortement contrôlé. Vérifier périodiquement qu’une restauration est possible sur un équipement de test. La sauvegarde qui échoue lors du premier incident n’était pas une sauvegarde, c’était une croyance.

Superviser les changements de programme, les redémarrages, les connexions de maintenance et les flux réseau anormaux. Un IDS (Intrusion Detection System), système qui détecte des comportements suspects, doit fonctionner passivement sur les segments où une sonde active risquerait de perturber les communications. Conserver les journaux du bastion, du pare-feu et des postes d’ingénierie avec une horodatation cohérente.

La rotation des mots de passe et certificats doit respecter les contraintes de disponibilité. Un certificat expiré sur une passerelle industrielle peut bloquer une maintenance urgente ; un compte partagé empêche d’attribuer une modification. Prévoir des comptes d’urgence scellés, des identités nominatives pour l’usage courant et une procédure de révocation qui indique explicitement quelles sessions déjà ouvertes resteront actives.

L’architecture doit enfin séparer la reprise cyber de la reprise physique. Restaurer un automate ne suffit pas si les actionneurs sont dans un état dangereux, si les capteurs ont dérivé ou si l’opérateur n’a pas reçu l’information. La conception d’architecture cyber doit relier les contrôles techniques, les états sûrs du procédé et les procédures d’exploitation.

🐝 Ce qui arrive si on s’en passe

Sans inventaire, qualification et retour arrière formalisés, chaque bulletin de sécurité devient une décision prise à l’aveugle : impossible de dire quels automates sont concernés, donc impossible de justifier une intervention ou son report. Le remplacement d’une carte ou d’un châssis réintroduit alors silencieusement un micrologiciel antérieur, et la version réellement en service cesse de correspondre à ce que la documentation affirme. Sans journalisation du bastion et des chargements de programme, un arrêt de production ne peut plus être distingué d’une modification illégitime : l’écart observé est attribué par défaut à une panne mécanique, et l’analyse post incident perd sa base horodatée. Sans restauration testée sur matériel représentatif, la reprise dépend de la disponibilité d’un outil d’ingénierie compatible, condition qui se vérifie au pire moment. Le risque résiduel non écrit ne disparaît pas, il devient seulement invisible aux arbitrages suivants.

🦫 Explication de la marmotte 🍫

Un automate industriel est un ordinateur spécialisé qui reçoit des informations de capteurs et envoie des ordres à des machines. Il peut ouvrir une vanne, arrêter un moteur ou maintenir une température. Une mise à jour change le logiciel interne de cet équipement pour corriger un défaut connu.

Avant de faire cette mise à jour, il faut identifier exactement le modèle, la version installée, les équipements reliés et le logiciel utilisé pour charger les programmes. Il faut ensuite tester la modification sur un matériel représentatif. Le test vérifie que l’automate redémarre, mais aussi que les capteurs, les alarmes et les machines commandées réagissent encore correctement.

Pendant ce temps, la sécurité réduit les possibilités d’attaque. Le réseau industriel est séparé du réseau de bureau. Seul un poste de maintenance contrôlé peut joindre les automates. Les connexions et les changements sont enregistrés. Cette séparation limite les attaques, mais elle ne corrige pas le défaut présent dans l’automate.

Avant l’intervention, une copie vérifiée du programme et des réglages doit être disponible, avec les outils nécessaires pour restaurer l’état précédent. Si la mise à jour échoue, l’équipement peut être remis dans sa version antérieure, puis le procédé doit être vérifié avant reprise. Sans test, sauvegarde et procédure de retour, corriger un défaut informatique peut créer un arrêt de production ou une situation dangereuse.

À lire aussi

• Faire cohabiter équipements industriels anciens et neufsRétrocompatibilité industrielle : faire cohabiter du neuf et du matériel des années 1990 sans étendre la surface d'attaque ni rendre l'exploitation impossible.
• Sécuriser un SCADA d’eau et d’énergieSécurisation des systèmes SCADA d’eau et d’énergie face aux protocoles historiques, aux effets physiques des commandes et aux exigences de NIS2.
• Sécuriser une interface HMI industrielle WindowsCette page décrit comment réduire le rôle de pivot d'une interface homme-machine industrielle entre le réseau informatique et les automates.
• Réseaux spécialisés, sobriété avancée et futurs raisonnablesRegrouper les domaines spécialisés et pistes d’évolution à connaître sans les présenter comme des certitudes : OT, industriel, quantique, participatif, blockchain et réseaux futurs.

Pages voisines

La citent

• Faire cohabiter équipements industriels anciens et neufs
• Réseaux spécialisés, sobriété avancée et futurs raisonnables
• IEC
• Nmap pour cartographier un réseau, des hôtes aux services exposés

Pourquoi un automate industriel ne se patche pas

Elle cite

• ⇄Lien dans les deux sens :DMZ industrielle pour protéger le réseau de production
• Sécuriser un SCADA aux protocoles non authentifiés
• Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition

⇄ : les deux pages se citent l’une l’autre.