Faire cohabiter équipements industriels anciens et neufs

Faire cohabiter équipements industriels anciens et neufs

Faire communiquer un automate programmable industriel ancien avec une infrastructure récente n’est pas un exercice de nostalgie. Le compromis central est brutal : préserver la disponibilité et le savoir-faire métier existant, tout en acceptant le coût d’une segmentation, d’une médiation protocolaires et de procédures d’exploitation plus strictes. La bonne décision consiste rarement à connecter directement l’ancien au neuf.

Explication de la marmotte

Faire vivre ensemble des machines anciennes et récentes ressemble à l’entretien d’un vieux bâtiment habité : on ne remplace pas un mur porteur parce qu’il est démodé, mais on évite aussi d’y percer n’importe où. Le but est de garder ce qui fonctionne sans laisser une faiblesse ancienne contaminer le reste.

→ Lire l’explication complète de la marmotte

Le compromis de la rétrocompatibilité industrielle

Les équipements industriels conçus dans les années 1990 supposent souvent un réseau de confiance implicite. Un automate programmable industriel, ou PLC (Programmable Logic Controller), accepte parfois une commande sans authentification, sans chiffrement et sans journalisation locale exploitable. Ce comportement n’est pas un défaut accidentel : il découle d’une époque où le câble réseau s’arrêtait au pied de l’atelier. Le câble a depuis rencontré le réseau d’entreprise, puis Internet, puis une présentation PowerPoint sur la convergence. Mauvaise rencontre.

La rétrocompatibilité ne doit donc pas chercher à moderniser artificiellement chaque protocole. Il faut préserver le comportement déterministe de l’équipement ancien et déplacer les contrôles de sécurité autour de lui. Un PLC qui ne sait ni vérifier l’identité de son interlocuteur ni chiffrer ses échanges ne devient pas sûr parce qu’un pare-feu porte le mot « next-generation » sur sa boîte.

La règle d’architecture est la suivante : aucun actif ancien ne doit être une dépendance réseau directe d’un système moderne exposé, bureautique, cloud ou d’administration générale. Les flux doivent traverser une zone intermédiaire, être limités à des pairs identifiés, et rester observables. Cette médiation coûte des équipements, des règles et du temps d’exploitation. Elle coûte moins cher qu’un arrêt de production déclenché par une trame de diffusion envoyée depuis le mauvais segment.

Le remplacement complet est justifié lorsque l’équipement impose un protocole non segmentable, une pile réseau instable ou un poste d’ingénierie impossible à maintenir. Sinon, le remplacement préventif peut être plus dangereux que l’ancien matériel lui-même : modifier un cycle de commande validé depuis longtemps introduit un risque fonctionnel qui n’a rien de théorique. La sécurité ne donne pas le droit de casser le procédé.

Pour cadrer ce choix, consulter les principes de résilience et d’architecture cyber avant de choisir un produit ou une passerelle. L’objectif est de réduire le rayon d’explosion, pas d’obtenir un inventaire plus coloré.

Segmentation OT, zones et conduits réseau

La technologie opérationnelle, ou OT (Operational Technology), regroupe les systèmes qui pilotent ou surveillent un procédé physique. Elle doit être séparée du système d’information bureautique, même lorsque les mêmes équipes exploitent les deux environnements. Une séparation logique par réseau local virtuel, ou VLAN (Virtual Local Area Network), ne suffit pas : une erreur de configuration, une liaison de niveau 2 ou un poste doublement raccordé peuvent rétablir le chemin. La frontière doit être routée et filtrée.

L’architecture recommandée comporte au minimum quatre zones :

1. une zone de procédé, contenant les automates, interfaces de terrain et postes de supervision ;
2. une zone de supervision, contenant les serveurs d’historisation, d’ingénierie et de maintenance ;
3. une zone démilitarisée, ou DMZ (Demilitarized Zone), industrielle pour les relais, sauts d’administration et collecteurs ;
4. le réseau d’entreprise, qui ne contacte jamais directement les actifs de procédé.

Les flux entre zones doivent être explicitement déclarés par source, destination, protocole, port et sens. Autoriser « tout le trafic entre supervision et automates » revient à installer une cloison coupe-feu avec une porte de hangar maintenue ouverte par une palette. Les protocoles industriels anciens utilisent fréquemment des ports fixes, des diffusions locales ou des connexions initiées dans un seul sens. Ce comportement doit être testé sur maquette avant tout filtrage, car certains outils d’ingénierie échouent silencieusement puis laissent croire à une panne d’automate.

Quand un protocole exige des diffusions Ethernet ou ne survit pas au routage, deux options existent. Soit conserver son domaine de diffusion dans une zone de procédé strictement isolée. Soit introduire une passerelle applicative qui traduit les données nécessaires vers un protocole contemporain. Le choix dépend de la fonction : un flux de télémétrie peut être relayé, une commande temps réel ne doit pas traverser un traducteur non qualifié.

L’accès distant doit se terminer dans la DMZ industrielle sur un bastion administré. Le bastion doit enregistrer les sessions, appliquer une authentification forte et n’ouvrir les flux vers la zone de supervision qu’à la demande. Une connexion de maintenance permanente vers un automate est une dette technique qui porte un casque de chantier.

Les mécanismes de filtrage, de proxy et de journalisation décrits dans les contenus réseaux restent applicables, avec une contrainte supplémentaire : la disponibilité du procédé prime sur toute inspection susceptible d’altérer les délais ou les paquets.

Protocoles anciens, passerelles et dette cryptographique

La cohabitation échoue souvent sur la cryptographie, ou plutôt sur son absence. Des équipements anciens proposent parfois Telnet, FTP (File Transfer Protocol), Hypertext Transfer Protocol ou des protocoles propriétaires sans chiffrement. Le trafic peut alors exposer des mots de passe, des recettes de production, des configurations et des commandes. Un réseau isolé réduit le risque, il ne chiffre rien. Un attaquant déjà présent dans la zone, ou un poste de maintenance compromis, lit toujours ce qui circule.

Le choix à privilégier est une passerelle de terminaison placée hors de la zone de procédé. Elle reçoit le protocole moderne côté supervision, vérifie l’identité du client, journalise l’action, puis établit le flux minimal vers l’équipement ancien. La passerelle ne doit pas prétendre donner une identité cryptographique à un automate qui n’en possède pas. Elle contrôle qui peut lui parler, pas ce que l’automate est capable de prouver.

Pour les échanges modernes, utiliser Transport Layer Security, ou TLS, avec authentification mutuelle quand le serveur et le client le supportent. Les certificats doivent être émis par une autorité interne dédiée aux usages industriels ou par une hiérarchie explicitement séparée. Une clé privée de passerelle peut être protégée dans un HSM (Hardware Security Module), mais le HSM ne répare pas une règle pare-feu trop large ni un compte d’ingénierie partagé. La gestion des certificats et TLS mérite une architecture propre, surtout lorsque les passerelles se multiplient.

Une passerelle n’est acceptable que si elle respecte trois propriétés : maintien des délais requis, comportement documenté en cas de panne, et capacité à fonctionner sans accès extérieur. Une appliance qui exige un service distant pour continuer à autoriser les flux de production n’est pas un contrôle de sécurité, c’est une panne différée avec abonnement.

Ce mécanisme ne garantit pas l’intégrité fonctionnelle des commandes. Si un opérateur autorisé envoie une mauvaise consigne, la passerelle la transporte avec une discipline admirable. La validation métier doit venir des limites configurées dans l’automate, des procédures de conduite, des revues de changement et, lorsque le procédé le permet, de capteurs indépendants.

Exemple de filtrage entre supervision et automate

L’exemple suivant utilise nftables sur une passerelle Linux placée entre une zone de supervision et un segment d’automates. Il autorise uniquement une station de supervision à joindre un automate sur un port de protocole industriel déterminé. Les adresses et le port sont volontairement documentés pour faciliter l’audit.

#!/usr/sbin/nft -f
# Passerelle industrielle : politique restrictive par défaut.
# 10.20.10.15 = serveur de supervision autorisé.
# 10.20.30.42 = automate cible.
# TCP 502 = Modbus TCP, à n'autoriser que si le procédé l'exige réellement.

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

    # Autoriser le retour des connexions déjà établies.
    ct state established,related accept

    # Autoriser uniquement le serveur de supervision vers l'automate.
    ip saddr 10.20.10.15 ip daddr 10.20.30.42 tcp dport 502 ct state new accept

    # Journaliser les refus avec limitation pour éviter de saturer les journaux.
    limit rate 10/minute log prefix "OT-DROP " level warning
    drop
  }
}

Avant d’appliquer cette règle, vérifier le comportement réel de l’outil de supervision avec une capture réseau. Certains logiciels ouvrent une connexion de découverte sur un autre port, ou tentent de diffuser sur le segment. Il faut décider si ce flux est nécessaire, puis l’autoriser explicitement ou l’éliminer. Ajouter une plage entière « parce que le logiciel cherche parfois » est une manière coûteuse de transformer une exception en accès permanent.

Le pare-feu ne protège pas contre un poste de supervision compromis. Il limite les destinations atteignables depuis ce poste et fournit des traces. La protection du poste impose une liste de logiciels autorisés, une gestion des correctifs compatible avec le procédé, des comptes nominatifs et une collecte centralisée des événements.

Surface d’attaque et contre-mesures exploitables

Les attaques les plus fréquentes contre les environnements hybrides ne demandent pas de vulnérabilité exotique. Elles exploitent une station d’ingénierie sous ancien système d’exploitation, un mot de passe partagé, un partage de fichiers non contrôlé ou un accès fournisseur persistant. Les automates ne sont pas les seuls actifs fragiles : le poste qui les programme est souvent le chemin le plus court vers une modification dangereuse.

Un poste d’ingénierie ancien doit être traité comme un actif à usage unique. Pas de navigation web, pas de messagerie, pas d’accès direct à Internet, pas de logiciel bureautique installé par confort. Les médias amovibles doivent passer par une station de contrôle dédiée, avec analyse antimalware et journalisation. Cette mesure ne garantit pas l’absence de code malveillant inédit, mais elle réduit les contaminations opportunistes, celles qui arrivent gratuitement avec une archive mal nommée.

La synchronisation du temps doit être conçue avant de déployer la supervision. Un serveur de temps unique ou redondé fournit une référence aux équipements qui le supportent, tandis que les autres doivent être identifiés comme non fiables pour la corrélation. Une horloge fausse n’empêche pas un incident, elle rend son analyse péniblement inventive.

La détection doit combiner journaux des pare-feux, authentification du bastion, événements des serveurs et observation passive du réseau industriel. L’observation passive ne bloque rien et ne modifie pas les trames, ce qui la rend préférable à une inspection active sur les segments fragiles. Détecter un changement de programme automate reste toutefois impossible si aucun mécanisme ne produit ou ne collecte cette information. Le réseau n’est pas télépathe, malgré les brochures.

Exploitation : secrets, sauvegardes et reprise

Les comptes partagés sont incompatibles avec une traçabilité sérieuse. Quand l’équipement ancien ne permet qu’un identifiant local unique, l’accès doit être médié par le bastion et soumis à une procédure d’autorisation. Le mot de passe local doit être conservé dans un coffre de secrets, changé lors des départs ou des interventions à risque, puis testé immédiatement. Une rotation non testée est une interruption de service programmée, avec moins de poésie.

Les configurations d’automates, projets d’ingénierie, firmwares et paramètres de passerelles doivent être sauvegardés hors de la zone de procédé. Une sauvegarde exploitable contient la version de l’outil nécessaire à sa restauration, les dépendances système, les sommes de contrôle et une procédure de retour arrière. Conserver uniquement le fichier projet sans l’environnement qui sait l’ouvrir revient à archiver une serrure avec la photo de sa clé.

Tester la reprise exige un environnement isolé ou un équipement de rechange représentatif. La restauration sur le procédé réel ne constitue pas un test, c’est une opération de production avec un vocabulaire rassurant. Les délais de remplacement matériel doivent être intégrés au plan : certaines cartes, interfaces série et licences anciennes ne sont pas remplaçables en quarante-huit heures.

Enfin, documenter les exceptions. Chaque équipement non corrigeable doit avoir un propriétaire, une justification, des flux approuvés, une date de revue et une stratégie de retrait. Cette discipline rejoint la gouvernance de la cybersécurité : accepter un risque peut être rationnel, l’oublier ne l’est jamais.

🐝 Ce qui arrive si on s’en passe

Sans zone intermédiaire ni médiation, un poste bureautique ordinaire atteint l’automate sur son port industriel : la commande part sans authentification, sans chiffrement et sans trace locale, donc rien ne permet ensuite de distinguer un ordre légitime d’un ordre injecté. Les identifiants circulant en clair sur les protocoles anciens deviennent réutilisables par quiconque capture une trame sur le même domaine de diffusion. L’absence de bastion supprime l’enregistrement des sessions de maintenance et l’attribution nominative : les actions se confondent dans un compte local unique. Sans sauvegarde couplée à sa version d’outil et sans matériel de rechange qualifié, la reprise après incident dépend d’un poste d’ingénierie dont la panne suffit à immobiliser la reprogrammation, et un arrêt de ligne peut durer aussi longtemps que le délai d’approvisionnement d’une carte.

🦫 Explication de la marmotte 🍫

Les machines industrielles anciennes contrôlent parfois directement un moteur, une vanne ou une ligne de fabrication. Elles ont été conçues à une époque où les personnes connectées au réseau étaient déjà supposées autorisées. Elles peuvent donc accepter des ordres sans vérifier précisément leur origine, transmettre des mots de passe lisibles ou ne garder presque aucune trace des actions.

Pour les garder en service, il faut d’abord les placer dans une partie séparée du réseau. Les ordinateurs de bureau et les services accessibles depuis l’extérieur ne doivent pas pouvoir les joindre directement. Entre les deux, une machine intermédiaire autorise uniquement les communications nécessaires, par exemple entre un serveur de supervision précis et un automate précis.

Les personnes qui entretiennent les équipements passent par un poste d’accès contrôlé. Les connexions y sont enregistrées et les droits sont accordés pour une durée limitée. Les mots de passe sont stockés dans un service réservé à cet usage et doivent pouvoir être changés sans perdre l’accès aux machines.

Le réseau est surveillé pour repérer une communication inhabituelle. Les réglages des automates et les logiciels nécessaires pour les reprogrammer sont sauvegardés avec leur version exacte. Si une passerelle, un poste de maintenance ou un automate tombe en panne, la reprise dépend de ces sauvegardes et d’un matériel de remplacement compatible. Cette organisation réduit les risques, mais elle n’empêche pas une erreur faite par une personne autorisée ni une commande dangereuse prévue par le procédé lui-même.

À lire aussi

• 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.
• NCSC-NL et coordination cyber portuaire néerlandaiseFiche du NCSC-NL néerlandais, de sa coordination avec le privé et de ses implications pour les infrastructures portuaires et logistiques.

Pages voisines

La citent

• Choisir ECDSA, EdDSA ou RSA pour un certificat TLS
• Comprendre pourquoi les systèmes communiquent
• IEC

Faire cohabiter équipements industriels anciens et neufs

Elle cite

• DMZ industrielle pour protéger le réseau de production
• Pourquoi un automate industriel ne se patche pas
• Sécuriser un SCADA aux protocoles non authentifiés