Durcir une architecture OT sous Linux implique de traiter en priorité trois points : la gestion des identités et des privilèges, la segmentation et le filtrage réseau, et une stratégie de mises à jour qualifiée et traçable. Cet article détaille des mesures concrètes (PAM, sudo, MFA, SSH, VLAN/DMZ, nftables, TLS, auditd, dépôts signés, SBOM, rollback) adaptées aux contraintes ICS/SCADA : disponibilité, validation fonctionnelle et stabilité des versions, en cohérence avec les référentiels IEC 62443, NIST et les guides ANSSI.
Pourquoi durcir une architecture OT Linux
Linux en automatisme : bénéfices et nouveaux risques
Les architectures d'automatisation industrielle intègrent de plus en plus de briques Linux : contrôleurs et IPC, passerelles IIoT, panels HMI, serveurs d'historisation, postes d'ingénierie (souvent virtualisés) et services applicatifs en périphérie (edge). Ce socle apporte une forte modularité (services, conteneurs, middleware), une large compatibilité réseau et une meilleure intégration avec les outils IT.
En contrepartie, il introduit une surface d'attaque proche du monde IT (services réseau, authentification, dépendances logicielles, chaînes de mise à jour), dans un contexte OT où la disponibilité, la sûreté de fonctionnement et la stabilité priment. Le durcissement (hardening) doit donc viser un niveau de sécurité élevé sans déstabiliser le process ni compliquer la maintenance.
Objectif : sécurité compatible production et audits
L'objectif est de construire un durcissement pragmatique, structuré autour de trois axes : (1) identités et privilèges, (2) exposition réseau et segmentation, (3) mises à jour maîtrisées. Cette démarche s'aligne notamment sur :
le modèle zones & conduits et les exigences techniques de la série IEC 62443 ;
Sur le terrain, les environnements OT héritent souvent de pratiques historiques : comptes partagés (ex. « maintenance », « admin »), mots de passe rarement renouvelés, accès distants « permanents », et droits trop larges pour réduire les frictions en exploitation. Or, en cas d'incident, l'OT exige une traçabilité sans ambiguïté : qui a fait quoi, quand, et depuis où.
Les dérives typiques sont :
absence d'inventaire des comptes locaux et des clés d'accès (SSH) ;
services exécutés en root sans besoin opérationnel ;
usage de sudo sans règles fines et sans journalisation exploitable ;
authentification reposant uniquement sur le mot de passe ;
non-séparation des rôles (exploitation, maintenance, ingénierie, intégrateur).
Réseau : segmentation incomplète et flux implicites
Les architectures OT modernes sont hybrides (IT/OT) et transportent à la fois des flux industriels (ex. Modbus/TCP, PROFINET, EtherCAT, OPC UA) et des flux de support (HTTP(S), MQTT, SSH, RDP via bastion). Les erreurs récurrentes concernent :
absence de segmentation (VLAN/VRF, cellules, zones) ;
règles de filtrage trop permissives (« any-any ») ;
absence de DMZ industrielle entre OT et IT ;
services inutiles actifs sur Linux (découverte réseau, impression, services de debug) ;
chiffrement inégal : TLS non vérifié, certificats non gérés, suites faibles.
Dans les scénarios d'attaque ICS, l'accès initial peut venir d'identifiants faibles, mais l'impact dépend très souvent d'un manque de contrôle des flux internes (mouvements latéraux east-west).
Patching : éviter à la fois l'immobilisme et l'instabilité
En OT, l'enjeu n'est pas « patcher vite » mais patcher avec preuve et contrôle. Les écueils fréquents incluent : dépôts non maîtrisés, dépendances tirées automatiquement, absence d'environnement de qualification, mises à jour kernel/firmware sans plan de retour arrière, et manque de traçabilité (inventaire, SBOM). Les référentiels industriels (ex. IEC 62443) et les guides ICS (ex. NIST SP 800-82) insistent sur une gestion de vulnérabilités documentée, y compris lorsque l'application d'un correctif est différée après analyse d'impact.
Methode de hardening OT Linux appliquee
Un durcissement en couches, orienté exploitation
Chez LENZE SAS, l'approche vise un compromis opérationnel entre sécurité, maintenabilité et stabilité. Le plan d'action est structuré en couches : gouvernance des identités, réduction de surface d'attaque, segmentation et contrôle des flux, puis cycle de mises à jour qualifié et traçable.
Supprimer les comptes partagés et imposer des comptes individuels. Quand un annuaire est possible, utiliser LDAP/Kerberos (ou équivalent) avec un mécanisme de tolérance aux ruptures (cache local contrôlé) adapté aux contraintes OT.
Politique PAM : complexité et rotation des mots de passe, verrouillage après tentatives, expiration, gestion de session (timeout), verrouillage d'écran sur HMI/panels lorsque c'est compatible avec l'exploitation.
Sudo restrictif : règles par commande (liste blanche), interdiction du NOPASSWD sauf justification, et conservation des journaux de façon exploitable (idéalement centralisée).
Accès distant durci : SSH par clés, désactivation du login root, restriction par groupes, et accès via bastion plutôt que depuis un segment large. Compléter par un second facteur lorsque le contexte l'autorise (ex. maintenance à distance).
Durcissement systemd : exécuter les services en comptes non privilégiés et activer des options de confinement (par exemple NoNewPrivileges, restrictions de capacités, protections de fichiers), après tests de non-régression.
2) Réseau : segmentation, filtrage, chiffrement
Principe : « deny by default », flux explicitement autorisés, séparation IT/OT par zones.
Segmenter selon IEC 62443 : définition de zones cohérentes (cellule/machine, ligne, atelier, DMZ industrielle, IT) et documentation des conduits (flux nécessaires, ports, sens, justification), conformément à l'approche zones & conduits.
Filtrage local Linux (ex. nftables) même en présence d'un firewall périmétrique : cela réduit l'impact d'un mauvais routage ou d'une compromission latérale. Ajouter du filtrage egress (sortant) pour limiter exfiltration et communications de commande et contrôle.
Réduction d'exposition : inventaire des unités systemd, désactivation/masquage des services non indispensables, fermeture des ports. Valider périodiquement par scan depuis un segment d'audit.
Chiffrement et certificats : privilégier des flux avec validation stricte des certificats et une gestion de cycle de vie (autorité interne/PKI, rotation, révocation). Pour les flux IIoT (MQTT/HTTPS), le TLS mutualisé peut renforcer fortement l'authentification machine-à-machine.
Journalisation et supervision : journald persistant, collecte d'événements système et export vers un collecteur lorsque l'architecture le permet. Le guide ANSSI sur la cybersécurité des systèmes industriels rappelle que la supervision doit être adaptée aux contraintes OT.
3) Mises à jour maîtrisées : qualification, signatures, retour arrière
Principe : chaîne de confiance + validation fonctionnelle + capacité de rollback.
Prioriser par criticité : composants exposés réseau (SSH, TLS, bibliothèques), navigateurs HMI, et briques OT spécifiques. Définir des critères d'acceptation (tests de non-régression communication, déterminisme, mouvement, temps de cycle).
Maîtriser les sources : dépôts signés, vérification (GPG), et mécanismes de gel de versions (ex. pinning/version lock selon distribution) pour éviter les dérives non planifiées.
Staging représentatif : environnement de qualification reproduisant versions, options kernel, topologie réseau et charges. Les changements passent par un processus de Management of Change (MOC) documenté.
Rollback : snapshots (LVM, Btrfs) ou images système immuables selon le design. En OT, revenir rapidement à un état connu est souvent plus opérationnel qu'une correction « à chaud ».
Traçabilité : inventaire logiciel, suivi des vulnérabilités évaluées (acceptées, différées, mitigées) et éléments de preuve de déploiement. Le NIST SP 800-82 insiste sur la prise en compte des contraintes de performance, fiabilité et sécurité fonctionnelle propres aux ICS.
Points de vigilance en environnement industriel
Temps réel et dimensionnement : mesurer avant d'imposer
Le durcissement peut générer des surcharges (CPU, I/O, latence) sur des matériels OT dimensionnés au plus juste. La bonne pratique est d'établir un baseline (latence, jitter, charge, temps de cycle), puis d'activer les contrôles progressivement, avec validation sur scénarios représentatifs (pics de production, démarrages, défauts, tempêtes de messages).
Arbitrage risque cyber vs risque process
Un correctif de sécurité peut impacter drivers, compatibilités protocole ou comportement applicatif. La stratégie « mises à jour maîtrisées » admet donc des correctifs différés, à condition de mettre en place des mesures compensatoires (segmentation renforcée, fermeture de ports, durcissement SSH, filtrage sortant) et de documenter puis réévaluer périodiquement la décision, pour éviter le gel permanent.
Le facteur humain : rendre la sécurité opérable
Sans procédures simples et applicables, la maintenance contourne les règles (partage de mots de passe, duplication de clés SSH, comptes génériques). Une approche réaliste combine bastion, comptes temporaires (approches « just-in-time » quand c'est possible), et procédures d'urgence (« break-glass ») encadrées et tracées.
Cas d'usage : intégrer des briques d'automatisation ouvertes
Des composants pensés pour l'architecture segmentée
Pour illustrer la mise en oeuvre dans des architectures d'automatisation ouvertes et segmentées, LENZE SAS propose des composants pouvant s'inscrire dans une logique zones/DMZ, collecte de données et supervision :
des ensembles de contrôle-commande et IHM combinant contrôleur c550 et interface opérateur v450.
Ces briques prennent tout leur sens lorsqu'elles sont intégrées avec des règles d'accès strictes, un durcissement des services exposés et un cycle de mise à jour qualifié, afin de concilier cybersécurité et continuité de production.
Message clé : réduire la surface d'attaque sans casser l'OT
Une démarche incrémentale, testée et documentée
Durcir une architecture OT sous Linux revient à maîtriser trois risques majeurs : authentification et privilèges, exposition réseau et mises à jour non contrôlées. Une stratégie efficace combine des comptes nominaux traçables, une segmentation « deny by default » structurée par zones et conduits (IEC 62443), et un patch management qualifié, signé et réversible, tel que recommandé dans les guides ICS (NIST) et les approches méthodologiques ANSSI.
Conclusion : benefices et demande de devis
Un hardening OT Linux bien conçu permet de réduire la surface d'attaque, de limiter les mouvements latéraux, d'améliorer la traçabilité et de sécuriser la maintenance à distance, tout en conservant la stabilité indispensable aux systèmes industriels. Pour dimensionner ces mesures, les tester sur votre contexte machine et structurer une feuille de route réaliste, contactez LENZE SAS et demandez un devis pour un accompagnement technique (architecture, intégration et durcissement cybersécurité OT).
