Sécuriser automates PLC et RTU en production industrielle

Les automates programmables industriels transforment les instructions logiques en actions physiques : ouverture de vannes, régulation de température, contrôle de vitesse de moteurs, séquencement de processus chimiques. Leur compromission donne à l'attaquant un contrôle direct sur le monde physique, avec des conséquences potentiellement catastrophiques allant de la destruction d'équipements à la mise en danger de vies humaines. Pourtant, ces dispositifs critiques fonctionnent souvent avec des firmwares obsolètes, des mots de passe constructeur par défaut jamais modifiés, des services réseau superflus activés et une absence totale de mécanismes de détection de modification. La sécurisation des PLC et RTU en environnement de production représente un défi technique majeur, car toute intervention doit préserver la disponibilité du processus industriel et la sûreté de fonctionnement. Les attaques documentées contre ces dispositifs, de Stuxnet ciblant les S7-300 de Siemens au malware Triton visant les contrôleurs de sécurité Triconex de Schneider Electric, démontrent que les groupes de menaces avancés maîtrisent parfaitement les techniques d'exploitation des automates industriels et exploitent systématiquement les faiblesses de sécurité au niveau le plus bas de l'architecture de contrôle.

Durcissement des configurations automates

Le durcissement des PLC commence par l'élimination des configurations par défaut. Chaque automate livré en usine dispose de mots de passe par défaut documentés publiquement : « password » pour Allen-Bradley, des mots de passe vides pour certains Siemens, des PIN numériques triviaux pour Schneider Electric. La première action consiste à modifier ces identifiants avec des mots de passe robustes et à activer les mécanismes de protection d'accès lorsqu'ils existent.

Les modes de protection des automates modernes offrent plusieurs niveaux de restriction. Siemens S7-1500 propose quatre niveaux de protection (aucun, lecture seule, lecture/écriture avec HMI, protection complète). Allen-Bradley ControlLogix/CompactLogix supporte le verrouillage de programme avec mot de passe. Ces modes doivent être activés au niveau le plus restrictif compatible avec les besoins opérationnels. En production, le mode « run » protégé, interdisant les modifications de programme sans authentification et arrêt manuel, constitue la configuration minimale recommandée par les guides de sécurisation de l'ANSSI pour les systèmes industriels.

La désactivation des services réseau non nécessaires réduit la surface d'attaque. Les serveurs web intégrés aux automates modernes, utiles pendant la mise en service, doivent être désactivés en production. Les services FTP, Telnet, SNMP et les ports de diagnostic distants constituent autant de vecteurs d'attaque exploitables. Un inventaire exhaustif des services activés sur chaque automate, suivi de la désactivation systématique des services non requis, forme la base du durcissement. Cette démarche s'inscrit dans la stratégie globale de segmentation réseau et Zero Trust appliquée aux environnements industriels.

Comment surveiller l'intégrité des programmes automates ?

La surveillance de l'intégrité des programmes constitue la défense la plus efficace contre les attaques type Stuxnet. La technique de base consiste à extraire périodiquement le programme de l'automate et à comparer son empreinte cryptographique (hash SHA-256) avec une référence validée. Toute modification non autorisée déclenche une alerte immédiate. Les solutions commerciales comme Claroty CTD et Nozomi Networks Guardian automatisent cette surveillance en interrogeant régulièrement les automates via leurs protocoles natifs pour détecter les changements de programme, de configuration et de firmware.

Les automates de dernière génération intègrent des fonctions d'intégrité natives. Siemens S7-1500 supporte la vérification d'intégrité du firmware par signature numérique et la détection de modification du programme chargé. Rockwell Automation ControlLogix 5580 propose le Change Detection pour alerter sur les modifications de programme non planifiées. Schneider Electric Modicon M580 intègre des mécanismes de Secure Boot vérifiant l'intégrité du firmware au démarrage. Pour les automates legacy ne disposant d'aucune de ces fonctions, la surveillance réseau passive détectant les commandes de programmation (Modbus fonction 8, S7comm Write Var) en dehors des fenêtres de maintenance planifiées constitue la mesure compensatoire principale.

Pourquoi la gestion des firmwares PLC est critique ?

Les firmwares des automates contiennent des vulnérabilités régulièrement publiées par les constructeurs et les organismes comme ICS-CERT. L'exploitation de ces vulnérabilités peut permettre l'exécution de code arbitraire, le contournement de l'authentification ou le déni de service de l'automate. Pourtant, la mise à jour des firmwares en environnement OT reste l'un des processus les plus complexes et les plus redoutés par les équipes d'exploitation.

La mise à jour d'un firmware PLC nécessite généralement un arrêt de l'automate, donc du processus industriel qu'il pilote. Les fenêtres de maintenance, parfois espacées de plusieurs mois voire d'années dans l'industrie continue, sont les seules opportunités pour appliquer ces mises à jour. Le processus doit inclure un test préalable sur un automate de spare ou un simulateur, une sauvegarde complète du programme et de la configuration, une procédure de rollback documentée et un plan de continuité en cas d'échec de la mise à jour. La mise en place d'une stratégie de gestion des logs et rétention permet de tracer chaque intervention sur les automates.

Quelles mesures pour les automates legacy sans sécurité native ?

Les automates anciens (Siemens S7-300, Allen-Bradley SLC 500, Schneider Premium/Quantum) ne supportent aucune fonction de sécurité native : pas d'authentification robuste, pas de chiffrement, pas de détection de modification. Ces dispositifs, encore massivement déployés dans l'industrie avec des durées de vie dépassant 20 ans, nécessitent des mesures compensatoires rigoureuses pour atteindre un niveau de sécurité acceptable.

La première mesure est l'isolation réseau maximale : chaque automate legacy doit être placé dans un micro-segment réseau avec un contrôle d'accès strict au niveau du commutateur industriel. Seuls les dispositifs explicitement autorisés (serveur SCADA principal, poste d'ingénierie dédié) peuvent communiquer avec l'automate. La deuxième mesure est la surveillance continue du trafic réseau à destination de l'automate : toute commande de programmation, tout accès depuis une source non autorisée, toute communication sur un port inhabituel doit déclencher une alerte. L'approche de détection engineering fournit les méthodologies pour créer ces règles de surveillance spécifiques.

La troisième mesure est le contrôle d'accès physique renforcé : les armoires contenant les automates legacy doivent être verrouillées avec un contrôle d'accès traçable (badge, clé unique, journal des accès). Un accès physique à un automate sans protection logicielle signifie un contrôle total et immédiat. La quatrième mesure consiste à maintenir des sauvegardes régulières et vérifiées des programmes automates, permettant une restauration rapide en cas de compromission détectée.

Disposez-vous d'un inventaire à jour de tous vos automates avec leur version de firmware et la date de dernière mise à jour de sécurité ?

Faut-il migrer vers des automates certifiés IEC 62443 ?

La migration vers des automates certifiés IEC 62443-4-2 offre des garanties de sécurité natives impossibles à reproduire par des mesures compensatoires sur des dispositifs legacy. Les automates certifiés intègrent le Secure Boot, le chiffrement des communications, l'authentification forte des accès de programmation, la détection d'intégrité du programme et la journalisation des événements de sécurité. Le surcoût à l'achat, typiquement 15 à 30% par rapport à un modèle non certifié, est largement compensé par la réduction des mesures compensatoires nécessaires et la simplicité d'atteinte du Security Level cible défini par la norme NIS 2.

La migration doit s'inscrire dans une stratégie pluriannuelle alignée sur les cycles de renouvellement naturels des automates. Remplacer un automate fonctionnel uniquement pour des raisons de cybersécurité est rarement justifiable économiquement, sauf pour les systèmes les plus critiques. L'approche recommandée consiste à spécifier systématiquement des automates certifiés IEC 62443 pour tout nouveau projet et tout remplacement, tout en renforçant les mesures compensatoires sur le parc legacy existant selon une priorisation basée sur la criticité du processus piloté et l'exposition réseau de chaque automate.

Comment sécuriser les accès de maintenance distante aux automates ?

La maintenance distante des automates constitue un vecteur d'attaque majeur qui nécessite des contrôles stricts. Les accès VPN directs vers les automates, encore pratiqués par de nombreux intégrateurs et constructeurs pour le support technique, exposent les dispositifs les plus critiques à des compromissions via les postes de travail des intervenants externes. L'architecture de maintenance distante sécurisée repose sur des jump hosts durcis positionnés dans la DMZ industrielle, avec authentification multifacteur, enregistrement vidéo des sessions et limitation temporelle des accès.

Les solutions de type Privileged Access Management (PAM) adaptées aux environnements OT, comme celles proposées par Wallix ou CyberArk, gèrent le cycle de vie complet des accès de maintenance : demande justifiée, approbation par le responsable OT, ouverture d'un créneau limité, supervision en temps réel de la session et clôture automatique. Chaque commande envoyée à l'automate pendant la session de maintenance est journalisée et peut être rejouée en cas d'investigation forensique. Les équipes de SOC reçoivent des alertes sur les sessions de maintenance active pour garantir une surveillance renforcée pendant ces périodes d'exposition accrue.

Sources et références : CISA ICS · ANSSI

Quelles bonnes pratiques pour la sauvegarde des programmes automates ?

La sauvegarde régulière des programmes automates constitue la dernière ligne de défense contre une compromission ou une corruption du code. Chaque version de programme validée en production doit être archivée avec son contexte : date de mise en service, modifications apportées, responsable de la validation et empreinte cryptographique SHA-256. Les outils de gestion de version comme PLC Version Control ou CODESYS Automation Server automatisent la capture périodique et la comparaison des programmes, alertant sur toute modification détectée entre deux captures.

Les sauvegardes doivent être stockées en dehors du réseau OT, idéalement sur un support déconnecté et dans un coffre physique sécurisé. La capacité de restauration doit être testée régulièrement lors des fenêtres de maintenance : télécharger une sauvegarde sur un automate de spare et vérifier le fonctionnement correct du programme constitue le test de restauration minimal. Les organisations les plus matures maintiennent un automate de spare pré-configuré pour chaque modèle critique, permettant un remplacement rapide en cas de compromission avérée d'un automate en production, en cohérence avec les pratiques de réponse aux incidents industriels.

Plan de résilience et continuité opérationnelle des automates industriels

La sécurisation des automates PLC et RTU ne se limite pas à la prévention des intrusions : la capacité à répondre à un incident cyber et à reprendre l'activité industrielle dans des délais acceptables est tout aussi critique pour les opérations. L'incident Triton/TRISIS de 2017 a démontré que des attaquants étatiques sophistiqués ciblent les systèmes de sécurité instrumentée pour créer des conditions d'accident physique, une réalité que tout responsable de sécurité OT doit intégrer dans sa stratégie de résilience opérationnelle. Un rançongiciel chiffrant les programmes automates ou une attaque altérant les paramètres de processus peut provoquer des arrêts de production particulièrement coûteux dans les industries à processus continus, comme la chimie, l'énergie ou la métallurgie, voire présenter des risques pour la sécurité physique des opérateurs et des installations environnantes. La résilience cyber industrielle ne se limite donc pas à la disponibilité informatique mais intègre la sûreté des personnes et des installations physiques.

La sauvegarde régulière des programmes automates, des configurations réseau et des paramètres de processus constitue le premier pilier de la résilience opérationnelle. Cette sauvegarde doit être réalisée de manière automatisée via les logiciels de programmation natifs, TIA Portal pour Siemens, Studio 5000 pour Allen-Bradley, EcoStruxure Machine Expert pour Schneider Electric, ou via des outils tiers de sauvegarde industrielle spécialisés. La fréquence des sauvegardes doit être alignée sur la fréquence réelle des modifications des programmes en production. Les sauvegardes doivent être stockées hors ligne sur des supports physiques sécurisés en armoire ignifugée et dans un environnement de stockage déconnecté du réseau OT pour éviter qu'un incident cyber sur le réseau industriel compromette également les sauvegardes. La règle classique des trois copies sur deux supports différents dont une hors site s'applique en environnement industriel. Testez la restauration au moins trimestriellement sur des équipements de test ou des simulateurs logiciels : une sauvegarde non testée est une fausse assurance qui donnera une mauvaise surprise au pire moment opérationnel. Ces exercices de restauration, documentés et intégrés au plan de continuité d'activité industrielle, valident que les équipes de maintenance maîtrisent réellement la procédure et que les versions de firmware des équipements de remplacement sont compatibles avec les programmes sauvegardés.

Définissez pour chaque automate critique un mode dégradé sûr, ou mode fail-safe, décrivant précisément le comportement de l'automate en cas de perte de communication avec le superviseur SCADA, les automates adjacents dans la chaîne de contrôle automatisée ou les capteurs de terrain. Ce mode fail-safe doit maintenir le processus dans un état sûr pour les personnes et les équipements même si la production est réduite ou arrêtée transitoirement. Vérifiez lors de chaque maintenance préventive que ces modes sont correctement configurés et fonctionnels dans les automates en production, car des mises à jour de firmware peuvent altérer ces paramètres de sécurité sans que les équipes de maintenance en soient automatiquement averties par les fabricants.

Gestion des fournisseurs et intégration de la sécurité dans les achats OT

La sécurité des automates industriels se joue aussi lors de leur acquisition, bien avant leur installation en production. Intégrer des exigences de cybersécurité dans les cahiers des charges d'achat, conformité IEC 62443-4-2, fourniture des SBOM (Software Bill of Materials), politique documentée de publication des correctifs de sécurité sur toute la durée de vie de l'équipement, est bien plus efficace et économique que de sécuriser a posteriori des équipements livrés sans conception sécurisée native. Cette approche Security by Design dans les achats OT est recommandée par l'ANSSI dans son guide de cybersécurité des systèmes industriels, par l'ENISA et dans le cadre du programme américain CISA ICS-CERT.

La directive NIS 2 et ses textes d'application poussent les industriels européens à évaluer sérieusement la maturité cybersécurité de leurs fournisseurs d'automates et de systèmes de contrôle industriel. Demandez systématiquement à vos fournisseurs les coordonnées de leur équipe PSIRT (Product Security Incident Response Team), les délais moyens constatés de publication des correctifs de sécurité pour les vulnérabilités critiques, et la présence d'un programme formel de divulgation coordonnée des vulnérabilités. Ces informations influencent directement le risque résiduel de votre installation sur toute sa durée de vie opérationnelle, souvent supérieure à dix ou quinze ans pour des équipements industriels, soit une durée pendant laquelle de nombreuses vulnérabilités seront inévitablement découvertes et devront être traitées avec diligence.

Pour les automates en fin de support dont le fabricant ne publie plus de correctifs de sécurité, documentez explicitement le risque résiduel accepté dans le registre des risques OT de l'organisation, mettez en place des mesures compensatoires proportionnées incluant une segmentation réseau stricte limitant les communications de l'automate au strict nécessaire fonctionnel, un monitoring comportemental renforcé sur les flux réseaux entrants et sortants, et une limitation maximale des accès distants de maintenance. Planifiez également le remplacement de ces équipements legacy dans votre feuille de route industrielle pluriannuelle. La décision de maintenir un automate sans support actif doit être une décision consciente et documentée, non une situation subie par défaut de planification budgétaire. Chaque automate critique sans support actif représente un risque accepté qui doit être inscrit formellement dans le registre des risques et réexaminé annuellement.

Conclusion

Face à l'évolution constante des menaces, une posture de sécurité proactive est indispensable. Les techniques et recommandations présentées dans cet article constituent des fondations solides pour renforcer la résilience de votre infrastructure.

Sécurisez vos systèmes industriels

Audit OT/ICS, segmentation IT/OT, conformité IEC 62443 — par un expert terrain.

Audit OT — Devis gratuit [email protected]