Sécurité des PLC. Protégez les automates qui ne peuvent pas se protéger.
La sécurité des PLC consiste à protéger les automates qui pilotent les procédés physiques, en imposant identité, segmentation et journalisation devant des équipements incapables de se défendre.
Dernière mise à jour:
La sécurité des PLC vise à protéger les automates programmables qui pilotent les procédés physiques. La plupart des automates sur le terrain, comme les Siemens S7, Rockwell ControlLogix et Schneider Modicon, ne savent ni authentifier un utilisateur, ni chiffrer leur trafic, ni recevoir de correctif, ni exécuter un agent. On ne sécurise donc pas un PLC sur l'équipement lui-même. On le sécurise en amont de l'équipement : un proxy industriel sur site arbitre chaque connexion, vérifie qui fait la demande, n'autorise que les commandes dont chaque utilisateur a besoin, tient le PLC à l'écart du réseau à plat et enregistre la session. C'est une mesure compensatoire, qui s'aligne sur l'IEC 62443 et le NIST 800-82. Les enjeux sont physiques : un automate manipulé modifie un procédé, donc une mauvaise commande signifie une ligne arrêtée, des équipements endommagés ou une consigne dangereuse.
Pourquoi les PLC sont difficiles à sécuriser
Un PLC est un automate robuste conçu pour piloter un procédé pendant vingt ans, pas pour se défendre sur un réseau. Les familles présentes dans la plupart des usines, Siemens S7-1200 et S7-1500, Rockwell ControlLogix et CompactLogix, et Schneider Modicon, partagent quatre points faibles.
Ils ne peuvent pas être corrigés
Les fabricants publient rarement des mises à jour de firmware, et vous ne pouvez pas mettre hors ligne un automate en fonctionnement pour les appliquer. Des failles connues restent ouvertes pendant des années, dont beaucoup figurent dans les avis ICS de la CISA. Ainsi, « on ne peut pas le corriger » ne satisfait plus un auditeur ni un cyber-assureur. Ils attendent une mesure compensatoire documentée, pas un risque accepté.
Ils accordent leur confiance par défaut
La plupart des protocoles de PLC n'ont ni authentification ni chiffrement en standard. Modbus/TCP (port 502), Siemens S7comm (port 102), EtherNet/IP CIP (44818), DNP3 (port 20000) et Profinet permettent à n'importe quel équipement du réseau de lire ou d'écrire des registres et d'envoyer des commandes. Des versions sécurisées existent, S7comm-plus, CIP Security et DNP3 Secure Authentication, mais elles sont optionnelles et rarement activées.
Ils sont livrés avec des identifiants par défaut
Les mots de passe par défaut et codés en dur sont fréquents et bien documentés. La plupart ne sont jamais changés, car modifier un mot de passe risque de casser une intégration qui fonctionne.
Un VLAN ne suffit plus
Les PLC, HMI et postes d'ingénierie partagent souvent un seul réseau à plat, et les placer sur un VLAN ne suffit plus aujourd'hui. Un VLAN sépare le trafic, mais il ne contrôle pas qui peut atteindre un automate précis, ni n'enregistre ce qui a été fait. Le contrôle d'accès par port comme 802.1X aide, mais il est complexe à exploiter et à maintenir à l'échelle d'une usine, et ses journaux sont difficiles à relier à ce qu'un utilisateur a réellement fait sur l'automate. Le poste d'ingénierie est le maillon faible, puisqu'il exécute le logiciel qui programme le PLC (TIA Portal, Studio 5000). L'objectif est un accès granulaire et traçable à la machine elle-même, par utilisateur et par commande, pas seulement une zone réseau.
Comment les PLC sont attaqués
La plupart des PLC exécutent toute commande valide reçue sur un protocole non authentifié, si bien que le chemin d'attaque est court. Ce n'est pas de la théorie : des intrusions Unitronics de 2023 chez des distributeurs d'eau américains qui utilisaient encore des identifiants par défaut, jusqu'aux incidents suivis en 2026, la CISA et les chercheurs en menaces OT continuent de trouver des automates exposés sur Internet et laissés avec leurs identifiants par défaut. Les techniques ci-dessous sont les mêmes, mappées sur MITRE ATT&CK for ICS.
| Tactique | Technique (ID) | Ce qui se passe sur un PLC |
|---|---|---|
| Accès initial | External Remote Services (T0822) | Un VPN fournisseur ou un serveur rebond donne à un tiers compromis un large accès au réseau OT. |
| Accès initial | Internet Accessible Device (T0883) | Un PLC exposé sur Internet est repéré par Shodan ou Censys et atteint directement. |
| Déplacement latéral | Default Credentials (T0812) | Des mots de passe par défaut documentés permettent à un attaquant de se connecter à l'automate. |
| Exécution | Unauthorized Command Message (T0855) | Sans authentification, un message Modbus (port 502) ou S7comm (port 102) forgé écrit des registres ou modifie la logique. |
| Exécution | Program Download (T0843) | Un poste d'ingénierie compromis utilise TIA Portal ou Studio 5000 pour pousser une logique altérée vers l'automate, par le même chemin qu'un vrai ingénieur. |
| Altération du contrôle du procédé | Manipulation of Control (T0831) | Des consignes ou une logique modifiées poussent le procédé vers un état dangereux : surdosage d'un produit chimique, surpression d'une conduite, ou dépassement d'une limite d'un équipement. |
Sécuriser un PLC sans y toucher
Vous ne pouvez pas durcir la plupart des PLC directement, alors vous ajoutez les contrôles manquants en amont : identité, moindre privilège, et une traçabilité que l'équipement n'a jamais eue. C'est ce que fait Trout Access Gate. C'est un proxy industriel résilient qui s'exécute sur site devant vos automates et impose un accès lié à l'identité, une liste blanche par commande, la microsegmentation et une journalisation complète, sans agent sur le PLC et sans interruption pour le déployer. Les auditeurs appellent cela une mesure compensatoire. Aucune des six étapes ci-dessous ne touche à l'automate.
01Placer un point de contrôle devant l'automate
Trout Access Gate se place sur le chemin vers le PLC et arbitre chaque connexion. L'automate n'est jamais touché ni corrigé, et le proxy reste transparent pour le procédé, si bien qu'il n'affecte ni la temporisation de la boucle de contrôle ni un système instrumenté de sécurité (SIS) connecté.
02Authentifier chaque connexion par identité
Liez l'accès à un utilisateur ou un équipement nommé via votre annuaire (Active Directory, Microsoft Entra ID), avec MFA au niveau réseau, pas à une IP ou un mot de passe partagés.
03N'autoriser que ce dont chaque utilisateur a besoin
Délimitez l'accès par actif, par protocole et par commande. Un ingénieur atteint les PLC dont il a la charge ; un fournisseur atteint une seule machine pour une seule tâche, dans une fenêtre de temps définie.
04Isoler le PLC du réseau à plat
Utilisez la microsegmentation pour qu'un poste compromis ne puisse pas atteindre l'automate, sans refonte de VLAN et sans réadressage IP.
05Enregistrer chaque session
Conservez une trace inviolable de qui s'est connecté, à quel automate, sur quel protocole, et quelles commandes ont été exécutées, prête pour un audit ou un incident.
06Maintenir le procédé en fonctionnement si le contrôle se dégrade
Le proxy se trouve désormais sur le chemin, alors concevez-le pour la disponibilité : exploitez-le avec basculement pour qu'une seule panne n'arrête jamais le procédé, et donnez aux opérateurs un chemin de secours d'urgence documenté et lui-même journalisé.
Ce qu'une mesure compensatoire doit produire
Un contrôle qui ne peut pas produire de preuve n'est pas un contrôle. Les auditeurs et les cyber-assureurs acceptent des traces, pas des affirmations. Pour chaque automate derrière le proxy, vous devriez pouvoir exporter :
- Attribution d'identité : l'utilisateur ou l'équipement nommé derrière chaque session, pas une IP ni un compte partagé.
- Preuve du moindre privilège : le périmètre par actif et par commande autorisé à chaque identité.
- Traces au niveau des commandes : quelles commandes de protocole et écritures de registres ont atteint l'automate, et lesquelles ont été bloquées.
- Des journaux inviolables et horodatés avec une durée de conservation annoncée, pour qu'une chronologie survive à une enquête.
- Couverture : quels automates se trouvent derrière le contrôle et lesquels non, reliés à l'inventaire des actifs.
- La preuve qu'il ne peut pas être contourné : un contrôle sur le chemin, pas une détection hors bande, avec le chemin de secours d'urgence lui-même journalisé.
- Le mapping : chaque élément relié à l'exigence précise IEC 62443, NIST 800-82, CMMC ou NERC CIP que votre évaluateur teste. Les preuves restent sur site, pas dans le cloud d'un fournisseur.
Checklist de sécurité des PLC
Une séquence concrète pour sécuriser un parc d'automates, de l'inventaire au mapping des référentiels.
| # | Action | Détail |
|---|---|---|
| 01 | Inventorier chaque PLC | Constituez un inventaire vivant des automates, HMI et RTU, y compris les équipements anciens qui ne peuvent pas exécuter d'agent. Utilisez la découverte passive : les CPU plus anciens peuvent tomber en défaut ou perdre des I/O sous un scan actif, alors ne scannez jamais activement un automate en fonctionnement. |
| 02 | Supprimer l'exposition à Internet | Retirez les PLC de tout chemin accessible depuis Internet, et vérifiez qu'aucun n'est exposé via Shodan ou Censys. |
| 03 | Changer les identifiants par défaut ou les protéger en amont | Remplacez les mots de passe par défaut là où vous le pouvez ; là où vous ne le pouvez pas, imposez une authentification devant l'équipement. |
| 04 | Imposer identité et MFA au niveau réseau | Exigez une authentification nominative, appuyée par MFA, avant qu'une session n'atteigne un automate. |
| 05 | Segmenter l'IT de l'OT, et les PLC entre eux | Microsegmentez pour bloquer le déplacement latéral vers les automates, sans recâblage. |
| 06 | Contrôler l'accès fournisseur et distant | Arbitrez l'accès des tiers par actif, dans une fenêtre de temps définie et enregistré, et supprimez les comptes VPN permanents. |
| 07 | Enregistrer et conserver les sessions | Conservez des journaux de session inviolables et horodatés reliés à l'identité, avec une durée de conservation qui satisfait votre auditeur, votre régulateur ou votre assureur. |
| 08 | Organiser les changements autour du procédé, pas contre lui | Basculez le contrôle lors d'une fenêtre de maintenance planifiée, gardez les systèmes de sécurité (SIS) hors du périmètre, et vérifiez que la ligne fonctionne à l'identique avant et après. |
| 09 | Mapper les contrôles aux référentiels dont vous dépendez | Documentez chaque contrôle au regard de l'IEC 62443, du NIST 800-82 Rev 3 et des CISA CPGs, ainsi que des directives TSA, du NERC CIP ou du CMMC lorsqu'ils s'appliquent. |
Sécurité des PLC et IEC 62443
Les PLC anciens ne satisfont presque aucune des exigences fondamentales de l'IEC 62443 par eux-mêmes. Une mesure compensatoire placée devant l'automate comble l'écart et produit les preuves, et le même contrôle couvre les autres référentiels auxquels un opérateur américain doit répondre : NIST 800-82 Rev 3, CISA CPGs, et lorsqu'ils s'appliquent, les directives TSA, le NERC CIP et le CMMC.
| Exigence IEC 62443 | La faille du PLC | Comment la couvrir |
|---|---|---|
| FR 1 Contrôle de l'identification et de l'authentification | Les PLC n'ont pas d'authentification native | Accès lié à l'identité imposé au niveau du proxy |
| FR 2 Contrôle de l'usage | Aucun contrôle par commande sur l'équipement | Liste blanche par actif, protocole et commande |
| FR 3 Intégrité du système | Des commandes non authentifiées peuvent altérer la logique | Seules les commandes autorisées atteignent l'automate |
| FR 4 Confidentialité des données | Les protocoles anciens envoient les commandes en clair | Chiffrer la session côté client ; confiner le trafic en clair au segment placé devant l'automate |
| FR 5 Restriction des flux de données | Réseaux à plat, sans zones ni conduits | Microsegmentation en zones et conduits |
| FR 6 Réponse rapide aux événements | Aucune journalisation native sur l'équipement | Traces de session inviolables pour la détection et l'audit |
| FR 7 Disponibilité des ressources | Aucune protection contre la surcharge ou une intégration défaillante | Contrôle sur le chemin avec basculement et un chemin de secours d'urgence journalisé |
Ce qu'il faut faire cette semaine
- Recensez chaque PLC et sa place sur le réseau.
- Vérifiez si un automate est accessible depuis Internet.
- Repérez quels PLC utilisent encore des identifiants par défaut ou partagés.
- Vérifiez si l'accès distant des fournisseurs repose sur des comptes permanents ou des VPN ouverts.
- Essayez de nommer, pour un automate critique, qui l'a atteint et quelles commandes il a envoyées au cours des 30 derniers jours. Si vous ne le pouvez pas, c'est là qu'est la faille.
- Sortez la section OT de votre dossier de cyber-assurance et lisez comment elle vous demande de traiter les actifs impossibles à corriger.
Questions sur la sécurité des PLC, avec réponses
agent sur le PLC, aucune interruption pour le déployer
La sécurité des PLC consiste à protéger les automates programmables, les équipements qui pilotent les procédés physiques, contre l'accès non autorisé et la manipulation. Comme la plupart des PLC ne savent ni authentifier, ni chiffrer, ni recevoir de correctif, vous imposez la sécurité des PLC en amont de l'automate : accès lié à l'identité, segmentation et journalisation au niveau réseau.
Placez une mesure compensatoire devant lui. Un proxy industriel sur site arbitre chaque connexion à l'automate : il authentifie l'utilisateur, n'autorise que les commandes dont il a besoin, isole le PLC du réseau à plat et enregistre la session. Le PLC n'est jamais modifié et reste en ligne.
Pas sur le PLC lui-même, puisque la plupart des automates ne le prennent pas en charge. Vous imposez plutôt le MFA au niveau réseau : un utilisateur s'authentifie avec MFA contre votre annuaire avant qu'une session n'atteigne l'automate. Le résultat est un accès PLC protégé par MFA sans modifier l'équipement.
Scannez avec précaution. Les automates plus anciens peuvent tomber en défaut, perdre des I/O ou cesser de répondre sous un scan de ports actif, alors la découverte sur une usine en fonctionnement doit être passive : lisez le trafic déjà présent sur le fil plutôt que de sonder l'équipement. Réservez les tests actifs à une fenêtre de maintenance, sur une unité de rechange ou hors ligne.
Les identifiants par défaut, l'exposition à Internet, les protocoles non authentifiés, les firmwares non corrigés, les réseaux à plat, les postes d'ingénierie et ordinateurs portables de fournisseurs compromis, et l'accès distant fournisseur non contrôlé. Chacun permet à un attaquant d'atteindre un automate et d'émettre des commandes, ou de pousser une nouvelle logique, qu'il exécute sans broncher.
Les assureurs l'attendent de plus en plus. Les dossiers de cyber-assurance demandent comment vous gérez les actifs OT impossibles à corriger, le MFA et la segmentation, et « on ne peut pas le corriger » sans contrôle est un signal d'alerte au renouvellement et un litige au moment de la déclaration de sinistre. Une mesure compensatoire qui impose identité, moindre privilège et segmentation devant l'automate, et produit des preuves de session, répond au questionnaire et au sinistre.
Pour chaque automate : l'identité nommée derrière chaque session, le périmètre par actif et par commande qui lui a été autorisé, les commandes qui ont atteint l'équipement, des journaux inviolables et horodatés avec une durée de conservation, la couverture des automates protégés, et un mapping de chaque élément à l'exigence IEC 62443, NIST 800-82, CMMC ou NERC CIP que votre évaluateur teste. Les preuves sont exportées sur site, pas depuis le cloud d'un fournisseur.
L'IEC 62443 attend l'identification et l'authentification, le contrôle de l'usage, l'intégrité du système, le zonage et la journalisation des événements. Les PLC anciens ne satisfont nativement aucun de ces points, alors les opérateurs répondent aux exigences avec une mesure compensatoire qui les impose devant l'automate et documente le mapping.
Oui, car ils demandent les mêmes choses en d'autres termes : accès lié à l'identité, moindre privilège, segmentation et journalisation devant des actifs qui ne peuvent pas le faire eux-mêmes. Un seul point de contrôle devant l'automate produit les preuves pour l'IEC 62443, le NIST 800-82 Rev 3, les CISA CPGs, les directives TSA, le NERC CIP et le CMMC.
Inventoriez chaque automate, vérifiez l'exposition à Internet et les identifiants par défaut, contrôlez la segmentation et l'accès fondé sur l'identité, confirmez que l'accès fournisseur est arbitré et enregistré, et mappez chaque contrôle à l'IEC 62443 ou au NIST 800-82. La checklist de cette page vous guide pas à pas.