Les parcs IoT industriels attirent les attaquants pour une raison simple : ils combinent exposition (réseaux étendus, accès distants, maintenance), hétérogénéité (firmwares et piles réseau multiples) et impact opérationnel (process, qualité, sécurité). Quelques scénarios reviennent régulièrement.

• Rebond vers le SI : un capteur ou une passerelle IoT devient un point d’entrée, puis sert de pivot vers des segments plus riches (bastion, serveur de supervision, annuaire, partages). Le risque n’est pas uniquement l’IoT lui-même, mais sa position dans la chaîne de confiance (comptes techniques, règles de pare-feu trop larges, accès administrateur partagé).
• Sabotage ou dégradation discrète : au lieu d’arrêter brutalement une ligne, un attaquant peut viser une dérive progressive (fausses mesures, paramètres modifiés, commandes non conformes). En OT, l’objectif peut être la perturbation plutôt que le vol.
• Exfiltration : données de production, recettes, paramètres de calibration, historiques de maintenance. L’IoT est parfois connecté à des plateformes cloud ou à des API externes, ce qui crée des chemins d’extraction “légitimes” difficiles à distinguer.

Ce qui rend ces scénarios réalistes, ce n’est pas la sophistication théorique, mais les conditions de terrain : mots de passe par défaut, services inutiles exposés, absence de journalisation, dépendance à un prestataire, ou segmentation réseau IoT insuffisante. Le premier gain de sécurité vient souvent d’un contrôle pragmatique des flux et des accès, avant même de parler de “Zero Trust”.

Sans inventaire fiable, il est impossible de prioriser ni de vérifier l’efficacité des mesures. En IoT/OT, l’inventaire est souvent incomplet parce que les équipements ont été ajoutés par étapes, parfois par des intégrateurs différents, avec des documents non tenus à jour.

Un inventaire utile pour la cybersécurité OT doit couvrir, au minimum :

• Identité technique : type d’équipement, fabricant, modèle, version firmware, services/protocoles activés.
• Rôle opérationnel : à quoi sert l’objet (mesure, action, supervision), criticité et impacts en cas d’arrêt ou de dérive.
• Contexte réseau : adresse IP/MAC, VLAN/zone, passerelle, dépendances (serveurs, cloud, NTP/DNS), flux entrants/sortants observés.
• Accès et administration : méthodes d’accès (web, SSH, API), comptes, présence d’accès distant, prestataire responsable.

Pour l’obtenir sans arrêter la production, combinez plusieurs sources :

1. Découverte passive (écoute des flux, SPAN/TAP, sonde) pour identifier les actifs et communications réelles.
2. Collecte réseau (tables ARP, DHCP, switches, contrôleurs Wi‑Fi, inventaires NAC) pour consolider adresses et ports.
3. Revue documentaire (plans d’architecture, dossiers machines, listes d’actifs maintenance) pour associer les objets à un usage.
4. Validation terrain ciblée sur les points critiques (armoires, baies, ateliers) pour lever les ambiguïtés.

L’objectif n’est pas la perfection immédiate, mais un socle exploitable : une liste d’actifs et de dépendances suffisamment précise pour segmenter, filtrer, surveiller et décider où mettre l’effort (patch, compensation, remplacement).

La segmentation est l’un des leviers les plus efficaces pour réduire l’impact d’un compromis IoT sans toucher aux équipements. L’idée centrale : limiter les chemins disponibles, pas seulement “séparer des VLAN”.

Commencez par une segmentation par zones/fonctions : objets IoT, supervision, maintenance, bureautique, accès prestataires. Les VLAN sont utiles pour structurer, mais ils doivent être associés à des règles de filtrage (pare-feu inter-VLAN, ACL sur switches, pare-feu industriels) ; sinon, ils deviennent une séparation surtout administrative.

Ensuite, mettez en place une politique de flux basée sur le besoin :

• Accès sortant minimal : autoriser uniquement les destinations nécessaires (serveur de supervision, broker, API cloud, NTP/DNS internes), et bloquer le reste.
• Blocage des mouvements latéraux : empêcher un objet IoT de parler à ses pairs si ce n’est pas indispensable.
• Administration contrôlée : interdire l’administration depuis des postes bureautiques ; imposer un bastion, un saut via une zone de maintenance, et des règles temporelles si possible.

La micro-segmentation (au niveau hôte ou groupe d’actifs) devient pertinente pour les zones critiques ou très denses : elle permet d’appliquer des politiques plus fines que “par VLAN”. Dans une trajectoire Zero Trust, on cherche à vérifier et limiter chaque interaction ; en OT, la traduction pragmatique est souvent : liste blanche de flux, contrôles d’accès robustes, réduction des chemins de rebond.

Mesure terrain essentielle : avant de bloquer, observez les flux (baseline) et déployez par étapes. Une segmentation réussie n’est pas celle qui paraît “propre” sur un schéma, mais celle qui n’interrompt pas les dépendances réelles tout en supprimant les communications inutiles.

La sécurité IoT industriel se heurte souvent à un fait : certains équipements ne se patchent pas, pas rapidement, ou pas sans risque pour la production (fenêtres d’arrêt rares, validation fournisseur, dépendance à une version). Il faut donc gérer les correctifs comme un processus de risque, pas comme une injonction.

Mettez en place une boucle simple :

• Qualification : identifier versions firmware et vulnérabilités pertinentes (pas uniquement “toutes les CVE”), en tenant compte du contexte (exposition réseau, privilèges, criticité).
• Tests : si possible sur banc ou environnement représentatif ; sinon, déploiement progressif par lots.
• Fenêtres de maintenance : alignées avec production, avec rollback plan.

Quand le patch est impossible à court terme, appliquez des compensations :

• Filtrage strict des flux vers l’équipement (liste blanche) et suppression des services non nécessaires.
• Durcissement de l’administration : mots de passe uniques, désactivation des comptes par défaut, limitation des interfaces d’admin, accès via bastion.
• Isolement renforcé : placement dans une zone plus restrictive, suppression de l’accès Internet direct, proxy contrôlé si nécessaire.
• Surveillance accrue : détection d’écarts de comportement et d’accès anormaux.

Traitez aussi le sujet des dépendances : certains objets utilisent des bibliothèques ou des mécanismes de mise à jour non maîtrisés. Pour réduire l’incertitude, formalisez des exigences minimales dès l’achat : capacité de mise à jour, support éditeur, signature des firmwares, documentation des ports/protocoles.

L’objectif est d’éviter le faux choix “patcher ou accepter le risque”. En pratique, on réduit l’exploitabilité par l’architecture et l’exploitation, en attendant une mise à jour, un retrofit, ou un remplacement planifié.

En IoT/OT, la supervision efficace repose souvent davantage sur le réseau et les comportements que sur les logs locaux, car beaucoup d’objets ont une journalisation limitée. L’objectif n’est pas d’absorber “tout”, mais de détecter ce qui signale une compromission ou un dérèglement.

Trois axes complémentaires :

• Visibilité des flux : collecter NetFlow/sFlow, miroirs de ports, ou télémétrie équivalente pour comprendre qui parle à qui, sur quels ports, et à quel rythme. Cela permet de repérer des communications nouvelles (exfiltration, C2), ou des scans latéraux.
• Logs utiles : quand disponibles (passerelles, brokers, plateformes IoT, pare-feu, bastion, VPN), centraliser dans un SIEM ou un outil de corrélation. Les événements les plus actionnables portent sur l’authentification, les changements de configuration, et les connexions administratives.
• Détection d’anomalies : établir une baseline par zone (horaires, volumes, destinations attendues). Une alerte pertinente peut être : un capteur qui contacte soudainement une destination externe inconnue, une hausse de trafic, ou une tentative d’accès admin depuis un poste non autorisé.

Pour éviter de “bloquer la production” par sur-réaction, définissez des playbooks gradués :

1. Triage (vérifier dépendances légitimes, maintenance planifiée, changement récent).
2. Confinement (règle pare-feu temporaire, isolement du port switch, quarantaine de la passerelle plutôt que de l’ensemble du réseau).
3. Restauration (retour configuration, réimage si possible, rotation des secrets).

Une supervision réussie n’est pas forcément celle qui génère beaucoup d’alertes, mais celle qui fournit des signaux exploitables et des actions possibles, compatibles avec les contraintes OT.

La gouvernance est ce qui transforme des mesures ponctuelles en capacité durable. Sans règles de cycle de vie, le parc IoT se re-fragmente : nouveaux objets ajoutés “vite”, exceptions réseau, mots de passe partagés, accès prestataires persistants.

Structurez le cycle de vie en étapes, avec des exigences simples et vérifiables :

• Achat / sélection : exiger des informations de sécurité (politique de mise à jour firmware, durée de support, mécanismes d’authentification, documentation des ports/protocoles, options de désactivation de services). Demander une matrice de responsabilités (éditeur, intégrateur, exploitant).
• Onboarding / déploiement : processus standard pour l’adressage, l’enregistrement dans l’inventaire IoT, l’affectation à une zone réseau, et la configuration minimale (mots de passe uniques, accès admin restreint).
• Exploitation : gestion des identités machine (certificats, clés, secrets), rotation planifiée, revue périodique des règles de pare-feu, contrôle des changements.
• Prestataires : accès distant via bastion, traçabilité, comptes nominatifs, fenêtres d’intervention, révocation systématique. Éviter les tunnels permanents non supervisés.
• Fin de vie : plan de remplacement, retrait des règles réseau, effacement des secrets, gestion des composants réutilisés.

Reliez cela à une gestion des risques pragmatique : classer les objets par criticité et exposition, puis appliquer un socle commun (segmentation, supervision, durcissement) et des exigences renforcées pour les actifs les plus critiques. Cette gouvernance est souvent le meilleur moyen de stabiliser la segmentation réseau IoT dans le temps, et d’éviter que la sécurité ne dépende uniquement d’initiatives individuelles.

Un plan en 90 jours vise à produire des résultats visibles sans attendre une refonte. Il doit être piloté par le risque et compatible avec les contraintes de production.

Jours 0 à 30 : quick wins de visibilité et contrôle

• Mettre en place un inventaire initial (découverte passive + collecte réseau) et identifier les dépendances critiques.
• Établir un schéma de zones (IoT, supervision, maintenance, prestataires) et documenter les flux essentiels.
• Fermer les expositions évidentes : services d’administration ouverts inutilement, accès Internet direct non justifié, comptes par défaut quand c’est possible.

Jours 31 à 60 : segmentation et accès maîtrisés

• Déployer ou renforcer le filtrage inter-zones (pare-feu, ACL) avec une logique liste blanche sur les flux critiques.
• Mettre en place un bastion ou un chemin d’administration contrôlé, et interdire l’admin directe depuis le SI bureautique.
• Définir un processus minimal de changement (qui demande, qui valide, comment on rollback).

Jours 61 à 90 : supervision et traitement du non-patchable

• Centraliser les logs disponibles (VPN, bastion, pare-feu, plateformes IoT) et activer la visibilité des flux.
• Définir des alertes priorisées (nouvelles destinations, scans, accès admin anormaux) et des playbooks de confinement.
• Formaliser les compensations pour les équipements non patchables (isolement, durcissement, surveillance) et construire une roadmap de remplacement.

Ce plan est efficace s’il produit des livrables concrets : inventaire exploitable, règles de segmentation en production, accès prestataires traçables, et capacité de détection/confinement.