texte présentant "IT vs OT" avec un fond de cybersécurité

IT vs OT : Pourquoi connecter votre réseau industriel au cloud crée de nouvelles surfaces d’attaque

Partager

Table des matières

La plupart des cyberattaques contre les infrastructures industrielles ne commencent pas dans l’usine. Elles débutent au bureau. Un e-mail de phishing atteint un administrateur IT. Un prestataire connecte un ordinateur portable compromis. Une session à distance est détournée. Le réseau IT est d’abord infiltré. L’attaquant pivote ensuite vers l’OT à partir de là.

Ce pivot est possible parce que l’IT et l’OT sont connectés. L’intérêt commercial de les connecter est réel — analyse de production, surveillance à distance, maintenance prédictive. Mais les hypothèses de sécurité intégrées à l’IT ne se transfèrent pas à l’OT. Lorsqu’elles sont appliquées sans changement, elles ouvrent des chemins d’attaque qui n’existaient pas avant la connexion.

Comprendre la fracture IT/OT est la condition préalable à la construction d’une architecture de sécurité qui tient réellement la route.

L’IT vs OT en bref : les systèmes IT gèrent les données, les applications et les processus métier.

Les systèmes OT surveillent et contrôlent les processus industriels physiques. La sécurité IT donne la priorité à la confidentialité ; la sécurité OT privilégie la disponibilité, la sûreté et la continuité des processus. Lorsque les réseaux IT et OT convergent, le risque principal est qu’une compromission de l’IT devienne une voie d’accès aux systèmes de contrôle industriel.

IT et OT : deux mondes différents

Les technologies de l’information (IT) couvrent les systèmes qui traitent, stockent et transmettent les données : serveurs, postes de travail, applications d’entreprise, infrastructure cloud. Le cadre de référence est la triade CIA — Confidentialité, Intégrité, Disponibilité. La confidentialité prime. Un système temporairement hors ligne pour une mise à jour est un compromis acceptable. Un système qui laisse fuiter des données ne l’est pas.

Les technologies opérationnelles (OT) couvrent le matériel et les logiciels qui surveillent et contrôlent les processus physiques : automates programmables (API), systèmes SCADA, DCS, RTU, IHM. Ces systèmes gèrent les réseaux électriques, les usines de traitement des eaux, les oléoducs, les lignes de fabrication. La priorité absolue est la disponibilité et la sécurité physique. Quelques minutes d’arrêt peuvent déclencher des systèmes de sécurité. Un processus non contrôlé peut blesser des personnes ou endommager des équipements valant des millions.

Au-delà des priorités, l’équipement OT est physiquement différent de l’équipement IT. Les dispositifs OT sont conçus pour des environnements industriels — températures extrêmes, vibrations, interférences électromagnétiques, sites isolés et dangereux. Une baie de serveurs conçue pour un centre de données n’a pas sa place dans une sous-station ou dans une raffinerie. Cette séparation physique a renforcé la séparation opérationnelle pendant des décennies.

IT (Information Technology)

OT (Operational Technology)

Priorité principale

Confidentialité

Disponibilité & sécurité physique

Cycle de mise à jour

Semaines à mois

Années à décennies (voire jamais)

Durée de vie typique

3–5 ans

10–30 ans

Tolérance aux arrêts

Faible (heures)

Proche de zéro (quelques minutes peuvent déclencher les systèmes de sécurité)

Protocoles

TCP/IP, HTTP, TLS

Modbus, DNP3, OPC-UA, Profibus, IEC 61850

Authentification

Standard (MFA, SSO)

Souvent absente ou minimale

Environnement physique

Contrôlé (centre de données)

Hostile (chaleur, vibrations, sites isolés)

Modèle de sécurité

Défense en profondeur

Historiquement : isolation physique (air gap)

Conséquence d’une brèche

Perte de données, préjudice financier

Interruption de processus, risque de sécurité, dommages physiques

Deux équipes, deux cultures et un problème partagé

L’IT et l’OT ne sont pas seulement des systèmes différents. Ils sont gérés par des personnes différentes avec des formations, des vocabulaires et des définitions de la réussite différents.

Les équipes IT — administrateurs réseau, ingénieurs sécurité, administrateurs systèmes — pensent en termes de cycles de mise à jour, de scores de vulnérabilité, de contrôles d’accès et de réponse aux incidents. Le temps d’arrêt est une métrique à minimiser. La sécurité est un mandat central.

Les équipes OT — ingénieurs de contrôle, opérateurs de machines, spécialistes des processus — pensent en termes de disponibilité, de stabilité des processus et de sécurité. Un changement de sécurité proposé qui nécessite un redémarrage du système est un risque de production, pas une fenêtre de maintenance routinière. La sécurité est importante, mais elle entre en concurrence directe avec la disponibilité.

Cette tension est réelle et elle compte. Les décisions de sécurité prises par les équipes IT sans l’avis de l’OT créent régulièrement des risques opérationnels. Un correctif déployé sur un serveur SCADA sans validation par rapport à la configuration de production peut interrompre un processus en cours. Une règle de pare-feu qui bloque un protocole OT légitime arrête une ligne de production.

Le problème de sécurité IT/OT n’est pas seulement technique. Il est organisationnel. Les équipes responsables de la sécurisation des infrastructures industrielles ne parlent pas toujours la même langue — et les attaquants le savent.

Combler cet écart nécessite une architecture de sécurité qui ne dépend pas d’une coordination parfaite entre les équipes. Une frontière matérielle qui impose physiquement le sens du flux de données élimine le mode de défaillance organisationnel — elle fonctionne que les équipes IT et OT soient alignées ou non.

Pourquoi la convergence a lieu et ce qu’elle ouvre

Pendant la majeure partie de l’histoire industrielle, l’IT et l’OT ont fonctionné dans des silos séparés. Les réseaux OT étaient isolés par défaut (air-gap) — physiquement déconnectés des réseaux d’entreprise. Cette isolation n’était pas une architecture de sécurité délibérée. C’était un sous-produit de protocoles propriétaires et de normes incompatibles. Mais cela fonctionnait comme une frontière de fait.

L’Industrie 4.0 et l’IIoT ont démantelé cette frontière. L’intérêt commercial est légitime : données de production en temps réel dans les analyses d’entreprise, maintenance prédictive réduisant les arrêts imprévus, surveillance à distance réduisant les effectifs sur site. Chacun de ces cas d’usage nécessite un chemin de données entre l’OT et l’IT.

La couche cloud ajoute un troisième niveau

L’adoption du cloud a encore étendu l’architecture. Des plateformes comme Azure IoT Hub, AWS IoT Greengrass et des historiens hébergés dans le cloud se situent désormais entre les sources de données OT et les analyses d’entreprise. Une passerelle edge collecte les données des API et des systèmes SCADA, les normalise et les pousse vers un point de terminaison cloud.

Chaque couche introduit une nouvelle surface d’attaque. La passerelle edge exécute des logiciels qui nécessitent des mises à jour. La connexion cloud nécessite des identifiants qui peuvent être compromis. Un attaquant qui compromet l’environnement cloud, ou les identifiants le connectant à l’edge OT, dispose d’un chemin qui n’existait pas à l’ère de l’isolation physique — et si la passerelle est bidirectionnelle, ce chemin fonctionne dans les deux sens.

Chaque chemin de données créé pour l’efficacité opérationnelle est aussi un chemin d’attaque potentiel. Ce n’est pas une raison pour ne pas se connecter. C’est une raison d’être précis sur la manière de le faire.

Le problème de la visibilité des actifs

Avant de concevoir une architecture de sécurité, les opérateurs doivent savoir ce qui se trouve sur le réseau. Cela semble évident. En pratique, la plupart des environnements OT n’ont pas d’inventaire complet et précis des actifs. Des équipements sont ajoutés au fil des décennies, des fournisseurs connectent des appareils pour la maintenance sans les documenter, des systèmes hérités utilisent des protocoles que les outils de scan passif ne reconnaissent pas.

Un attaquant n’a pas besoin de votre liste d’inventaire. Il peut énumérer les actifs lui-même en utilisant les mêmes protocoles non authentifiés auxquels vos appareils répondent. Modbus, DNP3 et Profibus répondent à toute requête sur le segment — aucun identifiant requis, aucune entrée de journal générée. Une cartographie complète de la topologie d’un réseau OT mal segmenté prend quelques minutes.

La visibilité des actifs est importante pour une autre raison : vous ne pouvez pas corriger ce que vous ne savez pas posséder. La segmentation matérielle à la frontière du réseau limite le rayon d’action des actifs inconnus — un attaquant qui atteint le réseau IT ne peut toujours pas énumérer le segment OT s’il n’y a pas de canal de retour à travers la frontière.

Pourquoi les contrôles de sécurité IT ne se transfèrent pas à l’OT

La pile de sécurité IT standard — pare-feu, EDR, SIEM, gestion des correctifs, MFA — a été conçue pour les contraintes de l’IT. Appliqué à l’OT, chaque composant se heurte à des hypothèses qui ne tiennent pas.

Les pare-feu sont des logiciels. Un logiciel peut être mal configuré.

Un pare-feu applique une politique. Les politiques peuvent être mal configurées, exploitées ou contournées. En 2024, des acteurs malveillants ont exploé des vulnérabilités dans les pare-feu Ivanti, Palo Alto Networks et Fortinet pour obtenir un accès initial. Le pare-feu qui était censé assurer la frontière IT/OT est devenu le point d’entrée. Les failles zero-day dans le micrologiciel des pare-feu sont un vecteur d’attaque documenté et récurrent, pas un cas isolé.

Une diode de données matérielle n’a aucune configuration à compromettre. La directionnalité est une contrainte physique — des composants optiques qui ne transmettent que dans un seul sens. Il n’existe aucune exploitation de micrologiciel capable de créer un canal de retour.

On ne peut pas corriger l’OT comme on corrige l’IT

Les cycles de mise à jour IT sont hebdomadaires ou mensuels. La correction de l’OT est limitée par les exigences de continuité opérationnelle, les délais de support des fournisseurs et les processus de validation. Un API exécutant un micrologiciel de 2012 peut se trouver sur une ligne de production qui ne peut être arrêtée pour une mise à jour contrôlée. Le fournisseur peut ne plus le supporter. Le correctif peut ne pas avoir été validé par rapport à la configuration de production.

Un actif OT non corrigé situé derrière une frontière logicielle est une position ouverte à cette vitesse. L’isolation au niveau du réseau est un contrôle plus fiable que la gestion des correctifs pour les actifs OT hérités — car elle ne nécessite pas que l’actif soit mis à jour.

Les protocoles OT n’ont pas été conçus pour des réseaux hostiles

Modbus, DNP3, Profibus et IEC 61850 ont été conçus pour le déterminisme et la fiabilité dans des réseaux physiquement isolés. L’authentification ne faisait pas partie du cahier des charges. Un appareil parlant Modbus répond à toute interrogation de n’importe quel hôte sur le même segment — aucun identifiant requis, aucune entrée de journal générée. La détection d’anomalies comportementales peut signaler un trafic inhabituel après coup. La segmentation matérielle supprime le canal de retour avant que la requête ne puisse obtenir de réponse.

À quoi ressemble réellement une architecture IT/OT sécurisée

La réponse au risque de convergence n’est pas d’arrêter de converger. La réponse est de concevoir la frontière de manière à ce que les données circulent dans la direction dont l’entreprise a besoin, tandis que les chemins d’attaque ne peuvent pas exister dans la direction dont l’entreprise n’a pas besoin.

Le flux de données unidirectionnel comme base de référence

Dans la plupart des flux de données IT/OT, la direction dont l’entreprise a besoin est de l’OT vers l’IT : réplication d’historien, exportations d’alarmes SCADA, transfert d’événements de sécurité vers le SIEM du SOC, données de production pour l’analyse. L’entreprise n’a généralement pas besoin que les systèmes IT envoient des commandes non sollicitées aux appareils OT en temps réel. Cette asymétrie rend une architecture unidirectionnelle à la fois opérationnellement viable et architecturalement correcte.

Une diode de données matérielle impose physiquement cette asymétrie. Les données circulent de l’OT vers l’IT. Aucun chemin entrant n’existe au niveau matériel. Un attaquant ayant le contrôle total du réseau d’entreprise ne peut pas atteindre le DCS, le SIS ou l’historien — car il n’y a pas de canal de retour permettant à un protocole d’établir une session à travers la frontière.

Le modèle Purdue, avec renforcement matériel

La Purdue Enterprise Reference Architecture définit des zones logiques pour l’OT : appareils de terrain aux niveaux 0–1, systèmes de contrôle au niveau 2, systèmes de supervision au niveau 3, systèmes d’entreprise aux niveaux 4–5. Ce modèle est l’architecture de référence depuis trente ans. Le problème est que ses limites de zone sont logiques, pas physiques. Un pare-feu au niveau 3.5 est une politique logicielle. Les politiques logicielles peuvent être exploitées.

Les diodes de données matérielles déployées au niveau 3.5 convertissent la limite de zone logique en une contrainte physique. La DMZ devient une valve à sens unique. L’historien se réplique vers l’extérieur. Le SOC reçoit les événements de sécurité. Rien ne pénètre vers l’intérieur à travers la frontière que le matériel ne permet pas par conception.

Quand l’IT doit envoyer des données vers l’OT

Certains flux de travail nécessitent des flux IT vers OT : mises à jour de micrologiciels, synchronisation de recettes, envois de configurations. Une architecture strictement unidirectionnelle ne peut pas les accommoder. Une architecture à « 1,5 voie » utilisant des passerelles unidirectionnelles jumelées les gère via des transferts asynchrones, basés sur des fichiers et imposés par le matériel. Chaque transfert est discret et journalisé. Il n’y a pas de session persistante qu’un attaquant puisse maintenir à travers la frontière.

Ce que disent les normes

L’IEC 62443, la norme internationale pour la sécurité des systèmes de contrôle industriel, définit les zones et les conduits comme modèle pour l’architecture réseau OT. Ses niveaux de sécurité les plus élevés reconnaissent les passerelles de sécurité unidirectionnelles comme un contrôle conforme pour imposer la séparation des zones. NIS2, désormais transposée dans le droit national des États membres de l’UE, impose des contrôles techniques adaptés aux risques pour les opérateurs de services essentiels — énergie, eau, transport, industrie. NERC CIP, applicable aux opérateurs du secteur électrique en Amérique du Nord, identifie les passerelles unidirectionnelles comme un mécanisme conforme pour franchir les périmètres de sécurité électronique.

Les cadres ont été développés indépendamment. Ils convergent vers la même architecture.

En savoir plus sur les passerelles unidirectionnelles Cyberium et les architectures cross-domain conçues pour la segmentation OT et le transfert de données sécurisé.

FAQ - IT vs OT

La sécurité IT donne la priorité à la confidentialité — empêcher l’accès non autorisé aux données. La sécurité OT privilégie la disponibilité et la sécurité physique — maintenir les processus industriels en fonctionnement sans interruption. Ces priorités divergentes entraînent des cycles de mise à jour différents, des modèles d’authentification différents, une tolérance aux arrêts différente et, finalement, des architectures de sécurité différentes. Les contrôles conçus pour les contraintes de l’IT créent des problèmes lorsqu’ils sont appliqués sans changement aux environnements OT.

Elles le peuvent — et le devraient. Mais l’alignement organisationnel ne remplace pas l’application architecturale. Les équipes IT et OT ont des priorités différentes qui créent une réelle tension : un correctif de sécurité nécessitant un redémarrage est acceptable pour une équipe IT mais inacceptable pour un opérateur OT en plein cycle de production. Une frontière matérielle qui impose physiquement le sens du flux de données fonctionne que les équipes soient alignées ou non.

Les dispositifs OT gèrent des processus industriels qui ne peuvent pas être arrêtés pour une maintenance de routine. Un API contrôlant un processus chimique ne peut pas être mis hors ligne pour une mise à jour de micrologiciel sans coordonner un arrêt complet du processus. De nombreux appareils OT utilisent des micrologiciels que les fournisseurs ne supportent plus, et toute modification nécessite une validation par rapport à la configuration de production. Les actifs OT exécutent régulièrement des logiciels vulnérables pendant des années — faisant de l’isolation au niveau du réseau un contrôle plus fiable que la gestion des correctifs.

La convergence IT/OT désigne l’intégration des systèmes IT d’entreprise — réseaux, plateformes cloud, analyses — avec les technologies opérationnelles — API, SCADA, DCS. Cette intégration permet une visibilité de la production en temps réel, une maintenance prédictive et des opérations à distance. Le risque de sécurité réside dans le fait que chaque chemin de données créé à des fins opérationnelles est aussi un chemin d’attaque potentiel. Si la frontière n’est pas imposée au niveau matériel, une compromission du réseau IT peut devenir une voie d’accès à l’environnement OT.

Un pare-feu applique une politique. Les politiques peuvent être mal configurées, exploitées ou contournées. Plusieurs grands fournisseurs de pare-feu ont présenté des vulnérabilités critiques utilisées pour l’accès initial en 2024. Les réseaux OT contiennent des appareils hérités utilisant des protocoles non authentifiés sur des micrologiciels qui ne peuvent pas être corrigés. Un pare-feu réduit la surface d’attaque. Une diode de données matérielle supprime le chemin d’attaque entrant au niveau de la couche physique — sans équivalent logiciel et sans configuration à compromettre.

Une diode de données matérielle impose une communication unidirectionnelle au niveau de la couche physique à l’aide de composants optiques. Les données circulent dans un seul sens — généralement de l’OT vers l’IT — et l’architecture matérielle rend un canal de retour physiquement impossible. Déployée à la frontière IT/OT, elle permet à la réplication d’historien, aux exportations d’alarmes et au transfert d’événements de sécurité d’atteindre les systèmes d’entreprise, tandis qu’aucun chemin entrant n’existe pour un attaquant ayant compromis le réseau IT.

Plus d'articles