Sécuriser une interface HMI industrielle Windows

Sécuriser une interface HMI industrielle Windows

L’interface homme-machine (HMI) est souvent le poste qui affiche les alarmes, lance une séquence et transmet les consignes aux automates programmables industriels. Elle concentre donc une capacité d’action que le réseau bureautique n’a jamais à posséder. La traiter comme un PC Windows ordinaire relié à un réseau industriel revient à placer le passe-partout dans le hall d’entrée, avec un post-it sur la porte.

Explication de la marmotte

Une interface de supervision ressemble au tableau de commande d’un grand bâtiment : elle permet de voir ce qui se passe et d’agir rapidement quand quelque chose change. Si une personne non autorisée prend sa place, elle peut aussi déclencher des actions qui touchent directement les machines.

→ Lire l’explication complète de la marmotte

HMI : le pivot entre administration Windows et procédé industriel

Une HMI n’est pas un équipement de transit neutre. Elle possède des projets de supervision, des recettes de production, des identifiants techniques, parfois des certificats et souvent une relation de confiance implicite avec les automates. Une compromission de session interactive permet donc plus qu’une lecture des données : elle donne accès aux commandes présentées par l’éditeur, avec les droits du compte connecté.

Le compromis central est brutal : plus une HMI reste ouverte aux outils d’administration informatique classiques, plus son exploitation quotidienne est fluide ; plus elle est isolée, plus les opérations de support deviennent coûteuses et doivent être préparées. La recommandation est de payer ce coût : une HMI de conduite doit être une station dédiée, sans messagerie, navigation web, bureautique ni accès direct aux services d’entreprise. Le confort d’un accès polyvalent est un privilège trop cher lorsqu’une écriture de registre Modbus ou une commande automate est au bout du clic.

La plupart des attaques ne commencent pas sur le protocole industriel. Elles arrivent par hameçonnage, réemploi de mot de passe, vol de jeton de session, outil de télémaintenance exposé ou mouvement latéral depuis Active Directory. Une HMI joint au domaine peut être justifiée si les contraintes de gestion l’imposent, mais elle ne doit jamais recevoir les mêmes stratégies, groupes d’administration locale et logiciels que les postes bureautiques. Joindre un domaine n’est pas une segmentation. C’est une dépendance d’identité, ce qui est nettement moins vendeur sur une slide de zero trust.

Le compte qui exécute le logiciel de supervision ne doit pas être administrateur local. Les droits nécessaires à l’accès aux pilotes, services ou dossiers de projet doivent être identifiés puis accordés explicitement. Un compte de service distinct, sans ouverture de session interactive, doit porter les accès techniques persistants. Toute exception doit être documentée avec le composant qui l’exige : « l’éditeur le recommande » ne décrit pas un besoin de privilège, seulement une ambiance.

Les mécanismes de sécurité Windows ne compensent pas un réseau plat. Un logiciel malveillant exécuté dans le contexte d’un opérateur peut piloter ce que l’opérateur peut piloter. La protection du poste réduit la probabilité de l’intrusion ; la segmentation réduit l’étendue de ses effets. Les deux sont nécessaires.

Les principes réseau utiles sont détaillés dans l’architecture cyber et dans les pages consacrées aux réseaux, mais le cas HMI impose une règle supplémentaire : toute communication entre la zone d’administration et la zone de conduite doit avoir un propriétaire, une justification et une direction connue.

Segmentation HMI, automates et postes d’administration

Séparer au moins quatre zones : administration informatique, poste d’administration industrielle, HMI de conduite et automates programmables industriels (API). Le poste d’administration industrielle sert aux mises à jour, à l’ingénierie et au transfert de projet. Il ne doit pas être confondu avec la HMI utilisée pendant l’exploitation. Une station qui compile, télécharge et conduit est pratique jusqu’au jour où un fichier de projet reçu par courriel devient aussi un outil de production. Ce jour arrive avec une régularité presque comique.

Le pare-feu entre HMI et automates doit autoriser les flux strictement requis : adresses source et destination fixes, ports et protocoles identifiés, direction limitée. Autoriser tout le sous-réseau industriel au motif que « les équipements se découvrent parfois » transforme une contrainte d’éditeur en autorisation permanente. Quand la découverte est nécessaire, la réaliser depuis une station d’ingénierie isolée et durant une fenêtre contrôlée.

Une zone démilitarisée industrielle doit accueillir les relais de données vers l’informatique : historien, passerelle de collecte ou serveur de rapports. La HMI ne doit pas publier directement ses données vers un serveur de fichiers, une base de données ou une application web située dans le réseau d’entreprise. Un flux sortant depuis la HMI vers une passerelle dédiée est préférable à un accès entrant depuis l’informatique vers le poste de conduite.

L’accès distant doit terminer sur un bastion dédié, pas sur la HMI. Le protocole RDP (Remote Desktop Protocol) ne doit être exposé ni depuis Internet ni depuis le réseau bureautique général. Le bastion impose une authentification multifacteur (MFA, Multi-Factor Authentication), enregistre les sessions quand le cadre d’exploitation le permet et n’autorise que les destinations déclarées. Le chiffrement d’une session ne rend pas légitime un opérateur volé : il protège le trajet, pas l’intention.

Les flux d’administration Windows méritent une attention particulière : SMB (Server Message Block), Windows Remote Management et RDP facilitent autant la maintenance que le mouvement latéral. Leur filtrage doit être nominatif. Désactiver les authentifications NTLM (NT LAN Manager) anciennes ou les restreindre exige une validation applicative, mais conserver NTLM par défaut sur un poste industriel revient à laisser une serrure historique parce que les clés traînent encore dans un tiroir. La page sur le durcissement de NTLM détaille les faiblesses de ce protocole.

Exemple de filtrage entre HMI et automates

Le filtrage ci-dessous illustre une HMI ayant besoin de lire et écrire sur deux automates via Modbus TCP (Transmission Control Protocol), protocole industriel utilisant le port 502. Il ne remplace pas la validation avec l’éditeur : certains logiciels ouvrent aussi des flux de diagnostic, de synchronisation d’heure ou de licence qu’il faut recenser avant blocage.

# Autoriser uniquement la HMI 10.40.20.10 vers deux automates Modbus TCP.
# La règle est placée sur le pare-feu interzone, pas sur la HMI elle-même.
table inet industriel {
  chain forward {
    type filter hook forward priority filter; policy drop;

    ip saddr 10.40.20.10 ip daddr { 10.40.30.21, 10.40.30.22 } \
      tcp dport 502 ct state new,established accept

    # Autoriser exclusivement les réponses associées à un flux déjà validé.
    ip saddr { 10.40.30.21, 10.40.30.22 } ip daddr 10.40.20.10 \
      tcp sport 502 ct state established accept
  }
}

Cette règle ne distingue pas une lecture Modbus d’une écriture Modbus : le protocole transporte les deux sur la même session. Si le procédé exige une séparation entre consultation et commande, elle doit être portée par le logiciel de supervision, les rôles opérateurs et, lorsque disponible, la logique de l’automate. Le pare-feu de niveau 3 ou 4 ne lit pas les intentions métier par télépathie.

Tester d’abord en observation : capturer les flux autorisés pendant un cycle représentatif, comparer aux flux déclarés, puis passer en blocage contrôlé. Une HMI peut appeler un serveur de licences à heure fixe ou tenter une résolution DNS (Domain Name System) oubliée dans une configuration ancienne. Bloquer ces flux sans inventaire provoque souvent une panne différée, le genre qui attend le changement d’équipe pour se manifester.

Durcissement Windows et intégrité des projets HMI

Le durcissement doit commencer par une image de référence validée avec la version exacte du logiciel HMI, de ses pilotes et de ses correctifs. Les environnements industriels supportent parfois des versions Windows en fin de support ; ce fait ne transforme pas une vulnérabilité connue en risque acceptable. Si la mise à jour est impossible, compenser par une isolation plus stricte, un contrôle d’exécution applicative et l’absence d’accès aux zones moins fiables.

Mettre en liste blanche les exécutables, bibliothèques et scripts autorisés. Windows Defender Application Control, ou un mécanisme équivalent validé par l’éditeur, bloque l’exécution d’un binaire non approuvé même après compromission d’un partage ou d’un compte opérateur. Cette mesure est plus déterminante qu’un antivirus seul : un logiciel malveillant récent peut ne pas être identifié, tandis qu’un exécutable absent de la liste n’a pas à négocier son innocence.

Désactiver les médias amovibles quand l’exploitation le permet. Sinon, imposer un poste de décontamination distinct avec analyse, inventaire et transfert contrôlé. Les clés USB restent remarquablement efficaces : elles n’ont besoin ni de tunnel chiffré, ni de présentation PowerPoint, ni de budget innovation.

Les fichiers de projet HMI doivent être exportés après chaque modification approuvée, chiffrés au repos et stockés hors de la zone de conduite. Leur intégrité doit être vérifiée par une empreinte cryptographique, par exemple SHA-256 (Secure Hash Algorithm 256 bits), associée à la demande de changement. Une sauvegarde qui contient seulement l’image système sans le projet, les recettes, les licences et la documentation de restauration est une décoration de conformité.

Le journal des événements de sécurité doit quitter la HMI vers un collecteur dédié, avec une capacité tampon locale limitée. Surveiller au minimum les ouvertures de session, élévations de privilèges, connexions distantes, création de services, modifications des projets et échecs répétés d’authentification. Une supervision qui collecte uniquement la disponibilité du poste détecte très bien une panne électrique, puis regarde poliment l’intrusion passer.

Exploitation, rotation et reprise d’une HMI

Les comptes opérateurs doivent être nominatifs, y compris lorsque l’application HMI ne sait gérer qu’un nombre restreint de rôles. Un compte partagé détruit l’attribution des actions et rend une enquête inutile avant même son début. Si le logiciel impose un compte partagé, compenser par une authentification nominative en amont sur le poste et par un journal de session corrélé ; ce n’est pas équivalent, mais c’est mieux que l’amnésie organisée.

Les mots de passe de comptes locaux d’urgence doivent être stockés dans un coffre avec accès journalisé, testés et renouvelés après utilisation. Les certificats utilisés par une passerelle ou une authentification applicative nécessitent un inventaire de l’émetteur, de l’usage, de l’échéance et du responsable de renouvellement. La révocation d’un certificat ne coupe pas forcément les sessions déjà établies : prévoir le redémarrage ordonné du service ou la fermeture des sessions dans la procédure d’incident. Les principes de cycle de vie sont détaillés dans la gestion PKI et TLS.

La sauvegarde doit couvrir trois objets distincts : l’image du poste, la configuration HMI et les données de procédé nécessaires à une reprise cohérente. Restaurer une image ancienne sans restaurer les recettes ou les paramètres de communication peut reconnecter la HMI avec une représentation périmée du procédé. La reprise doit être testée hors production, avec vérification des versions de projet, des licences, de l’heure système et des flux réseau.

Une HMI durcie ne garantit ni la sûreté physique, ni la justesse d’une logique automate, ni l’absence d’erreur opérateur. Les interverrouillages critiques doivent vivre dans les automates et les systèmes de sécurité dédiés, pas dans un écran graphique. La HMI affiche, commande et alarme ; elle ne doit pas devenir la dernière barrière entre une erreur et un dommage.

🐝 Ce qui arrive si on s’en passe

Sans segmentation ni filtrage nominatif, Modbus TCP n’offrant aucune authentification native, tout hôte capable d’atteindre le port 502 d’un automate peut y écrire des registres directement, sans passer par la HMI ni par ses rôles opérateurs : les restrictions configurées dans le logiciel de supervision sont alors simplement contournées. Une HMI compromise peut aussi acquitter ou masquer des alarmes et afficher des valeurs cohérentes pendant que le procédé dérive ; l’opérateur conduit sur une représentation falsifiée. Enfin, un chiffrement ou un effacement du poste prive l’exploitation de sa vue sur l’installation : même si les automates poursuivent leur cycle, la conduite sans supervision peut imposer un fonctionnement en mode dégradé ou un arrêt de la production, le temps de restaurer une station dont l’intégrité n’est plus garantie.

🦫 Explication de la marmotte 🍫

Une interface homme-machine est un ordinateur qui montre l’état d’installations industrielles et permet à un opérateur d’envoyer des commandes. Elle communique avec des automates, qui sont des équipements chargés de piloter des machines. Si cet ordinateur est infecté ou contrôlé par une personne non autorisée, cette personne peut utiliser les commandes prévues pour l’opérateur.

La protection commence donc par séparer les réseaux. L’ordinateur de conduite ne doit pas servir à lire ses courriels, naviguer sur Internet ou installer des logiciels ordinaires. Les ordinateurs chargés de modifier les programmes industriels doivent être différents de ceux utilisés pour conduire les machines. Un équipement de filtrage réseau n’autorise que les communications nécessaires entre l’écran de conduite et les automates.

Les accès à distance passent par un poste intermédiaire protégé par plusieurs preuves d’identité. Chaque opérateur utilise son propre compte afin de savoir qui a effectué une action. Le système enregistre les connexions, les changements et les tentatives anormales dans un journal envoyé vers un autre ordinateur.

Les programmes autorisés sont limités à une liste décidée à l’avance. Les copies de secours doivent contenir le système, les réglages de supervision et les données nécessaires au redémarrage. Si une protection échoue, la séparation réseau limite la propagation ; si une restauration échoue, une procédure testée permet de remettre en service une version connue sans envoyer de commande imprévue aux machines.

À 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.
• Pourquoi un automate industriel ne se patche pasSécurité OT/ICS : pourquoi le correctif d'un automate industriel exige une stratégie de risque, de validation et de reprise.
• 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.
• Comment limiter le mouvement latéral après compromissionLe mouvement latéral permet à un attaquant déjà présent de progresser vers des systèmes plus sensibles, mais la segmentation et la détection interne en réduisent fortement la portée.

Pages voisines

La citent

• Sécuriser un SCADA d’eau et d’énergie
• Chaîne d'alimentation et refroidissement d'un datacenter

Sécuriser une interface HMI industrielle Windows

Elle cite

• ⇄Lien dans les deux sens :Sécuriser un SCADA aux protocoles non authentifiés
• DMZ industrielle pour protéger le réseau de production
• NTLM : protocole authentification LAN Manager New Technology Microsoft
• RDP exposé sur Internet : risques, durcissement et détection

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