Comment sécuriser les systèmes OT hérités sans les casser

Les opérateurs des environnements industriels et des infrastructures critiques sont souvent confrontés à un paradoxe cruel : l'obligation de sécuriser des systèmes de technologie opérationnelle (OT) hérités, dont l'architecture et les protocoles n'ont jamais été conçus en pensant à la sécurité. La plupart des installations OT héritées (pensez aux DCS, SCADA, PLCs des années 1980, 90 et même début des années 2000) sont antérieures aux concepts modernes de sécurité informatique et manquent de capacités aussi fondamentales qu'une authentification forte, des communications chiffrées, des mécanismes de mise à jour de code sécurisés, que même les ingénieurs informatiques débutants pourraient considérer comme acquis.

Cet article présente une approche concrète et techniquement précise pour sécuriser ces environnements hérités, en mettant particulièrement l'accent sur une réduction des risques pratique qui ne « casse pas l'usine ». Il est destiné aux RSSI, directeurs informatiques et ingénieurs réseau dont le pain quotidien est la disponibilité, la sécurité et les contraintes du monde réel.

Table des matières

1. Contexte historique : Insécurité des systèmes OT

2. Défis de sécurité OT : Réalités pratiques et architecturales

3. Architecture réseau : Segmentation et confinement

4. Protocoles hérités : Faire face à l’irréparable

5. Surveillance et détection des intrusions : Visibilité sans perturbation

6. Collaboration IT/OT : Combler le fossé culturel

7. Étapes de déploiement pratiques : Sécuriser sur place, pas démolir et remplacer

8. Conclusions et références

Contexte historique : Insécurité des systèmes OT

La plupart des architectures de systèmes OT hérités ont vu le jour à une époque où la sécu rité par l’obscurité était une option pragmatique mais imparfaite. Considérons :

• L'architecture de référence d'entreprise Purdue (PERA), datant des années 1990, organisait les réseaux en « niveaux » distincts principalement pour optimiser l'efficacité des processus et NON la sécurité. Voir la figure 1 ci-dessous pour le modèle classique de Purdue.

• Les protocoles industriels—Modbus (1979), DNP3 (1993), Profibus (1989), OPC DA (1996)—ont été conçus pour la durabilité et la simplicité, pas pour le chiffrement, l'authentification ou la résistance aux attaques.

• Jusqu’aux années 2000, la plupart des réseaux OT étaient isolés. « Pas de connexion, pas de risque », pensait-on. Aujourd'hui, la surveillance à distance, l'intégration avec les systèmes informatiques et les exigences réglementaires ont brisé la barrière d'isolement physique—parfois délibérément, parfois par accident.

Leçon clé : La majorité des systèmes OT déployés n'ont jamais été conçus pour résister à un attaquant capable. Ils sont, par défaut, vulnérables même aux techniques d'attaque modestes.

Défis de sécurité OT : Réalités pratiques et architecturales

Les lois de la physique (et du contrôle de processus)

Contrairement aux systèmes informatiques, les réseaux de contrôle industriel sont étroitement liés aux équipements physiques et aux processus du monde réel. Un scan imprévu, un correctif trop zélé, ou même un pare-feu mal configuré peut provoquer un arrêt de production voire un événement critique pour la sécurité.

Piles fournisseurs et systèmes fermés

De nombreux contrôleurs et stations de travail hérités encore utilisés sont verrouillés par le fournisseur—un fait qui constitue à la fois un obstacle pratique et légal. Certains fournisseurs annuleront le support si un logiciel « étranger » (comme un agent de sécurité des points d'extrémité ou de surveillance intrusive) est installé. D'autres ont des mots de passe codés en dur, des vulnérabilités non corrigibles ou nécessitent de vieilles versions obsolètes de Windows, VMS ou QNX.

Contrôle du changement : « Ne touchez pas à ça » (à moins d'avoir un plan)

Une gestion du changement approfondie est nécessaire pour toute mise à jour des systèmes de production. Si vous prévoyez de « déployer la sécurité », préparez-vous à justifier chaque changement auprès des opérateurs OT, des gestionnaires d'usine et même des auditeurs de conformité.

Architecture réseau : Segmentation et confinement

Défense en profondeur : Ce n'est pas juste un mot à la mode

Étant donné que les dispositifs OT hérités sont intrinsèquement peu sûrs, le moyen le plus important de contrôle compensatoire est la segmentation du réseau—une compartimentation architecturale pour limiter le rayon de dissémination d'une brèche.

• VLANs et segments locaux : Bon pour une première approche—séparer le trafic OT du trafic IT, regrouper les points d'extrémité par fonction et risque. Mais les VLANs seuls ne fournissent rarement une vraie contenance à l'attaque (les paramètres par défaut fuient le trafic broadcast/multicast; le détournement de VLAN est réel).

• Segmentation de niveau 3 et pare-feux : Introduire une segmentation par zone (voir IEC 62443-3-2 pour les meilleures pratiques de zonage). Utiliser des pare-feux internes pour contrôler strictement non seulement le trafic Nord-Sud mais aussi Est-Ouest entre les segments OT.

• Liste blanche explicite (refuser par défaut) : Créer et appliquer des règles de pare-feu (ou ACL de routeur) spécifiant quels dispositifs peuvent communiquer, sur quels ports et dans quelles directions. Bloquer « tout le reste »—en particulier les initiations de l'Internet et de l'IT externe vers l'OT.

• Serveurs relais / Zones démilitarisées (DMZ) : Mettre en place des points d'accès intermédiaires pour la connexion IT/OT, les mises à jour logicielles, le support à distance des vendeurs, etc. Pas de pontage direct; utiliser des sous-réseaux filtrés, une authentification spécifique au segment et une journalisation stricte.

Note historique :

Le concept de « Zone démilitarisée industrielle » (IDMZ) a gagné en popularité après la publication des normes ISA-99 / IEC 62443 au milieu des années 2000, en partie inspiré par les modèles d'isolement de réseau militaire et bancaire antérieurs.

Évitez les réseaux plats à tout prix

Les environnements OT avec connectivité étendue de niveau 2 sont des cibles faciles—la compromise d'un seul point d'extrémité peut se propager en cascade, grâce aux protocoles de diffusion énergiques et à l'absence de contrôles internes. Plus plat n'est pas plus sûr. Commencez à diviser ces segments (avec vos ingénieurs processus impliqués).

Protocoles hérités : Faire face à l’irréparable

La triste vérité : les protocoles ne peuvent pas être « sécurisés » par pure volonté

Les ingénieurs informatiques demandent parfois : « Ne peut-on pas patcher Modbus ou DNP3 pour ajouter du chiffrement ? » Pas vraiment. Ces protocoles ont été conçus pour des environnements à faible latence, à faible résilience et manquent simplement de provisions pour les en-têtes de sécurité. Même les tentatives de versions « fortifiées » (comme l'authentification sécurisée DNP3, IEC 62351 pour l'énergie) restent rarement déployées sur des actifs hérités.

Quelques dures réalités :

• Pas d'authentification intégrée : Tout hôte qui peut parler le protocole et atteindre l'appareil peut émettre des commandes; il n'y a généralement pas de connexion, pas de contrôle d'accès. Voir de nombreuses déploiements de Siemens S7, Allen-Bradley ou Modicon pour preuve vivante.

• Pas de chiffrement : Les données—including les commandes comme « relais d'arrêt »—sont envoyées en clair. Les attaques MITM (Man-in-the-Middle) sont triviales si vous avez accès.

• Pas de vérification d'intégrité : Les « vérifications » au niveau du protocole se concentrent sur le format du message, pas sur sa légitimité.

Contrôles compensatoires : Enveloppes et proxys

Si les correctifs au niveau du protocole ne sont pas envisageables, les contrôles basés sur le réseau sont votre meilleur espoir:

• Proxys de contrôle d'accès : Déployer des pare-feux ou des proxys d'application qui surveillent les transactions autorisées, empêchent les paquets mal formés et (en option) limitent le débit ou enregistrent les anomalies de trafic.

• Transport segmenté / VPNs (avec précautions) : Vous pouvez déplacer le trafic de protocole hérités à l'intérieur de tunnels VPN IPsec ou TLS entre des points définis. Mais attention: cela ne « sécurise » pas le protocole en lui-même, seulement le transit. Un émetteur ou récepteur compromis reste un risque. Utilisez judicieusement, et testez de manière approfondie—une latence supplémentaire ou des saccades peuvent casser les communications en temps réel.

• Appareils d'inspection approfondie des paquets (DPI) : Les pare-feux industriels modernes et les systèmes IDS peuvent « comprendre » les flux de protocoles, bloquer les charges utiles dangereuses connues et tenter d’exploiter les particularités des protocoles.

Surveillance et détection des intrusions : Visibilité sans perturbation

Il ne s'agit pas seulement de prévention : La détection nous fait gagner du temps de réaction

Puisque le durcissement direct est souvent impossible, vous devez compenser par une surveillance approfondie—idéalement déployée hors bande.

• Surveillance basée sur Span/TAP : Utilisez des TAP réseau ou des ports SPAN pour envoyer le trafic vers un système d'analyse dédié. Cela garantit aucun impact ou latence ajoutée au réseau OT en direct.

• IDS compatible ICS : Déployez un IDS (Suricata, Zeek ou spécifique à l'industrie comme Nozomi Networks ou Claroty) avec des analyseurs pour les protocoles industriels, capable de signaler une mauvaise utilisation des commandes, des accès non autorisés ou des interactions d'appareils inattendues.

• Agrégation de logs : Centralisez les syslogs, événements Windows et logs d'appareils (si possible), filtrant les nouvelles apparitions d'appareils, les échecs de connexion (s'il y en a), et les modifications de configuration—envoyant des alertes dans votre SIEM/SOC.

Important : Ne connectez jamais un outil de sécurité en ligne (c'est-à-dire, de façon à ce qu'une panne de l'outil de sécurité bloque les communications du processus) à moins que l'outil ne soit classé pour une utilisation OT et que vous l'ayez testé dans votre environnement sous trafic réaliste. Les pannes de « boîte aveugle » peuvent arrêter une usine.

Collaboration IT/OT : Combler le fossé culturel

Sécuriser les systèmes hérités est autant une question de personnes et de processus que de contrôles techniques. Les praticiens de l'informatique doivent comprendre les réalités opérationnelles, légales, et même de « savoir tribal » en OT.

• Intégrer l'OT dans la modélisation des menaces : Ne « faites pas de la sécurité sur eux ». Co-développez des étiquettes de réseau, la segmentation et les contrôles d'accès avec les opérateurs qui savent quels hôtes peuvent être interrompus et quand.

• Respecter les procédures de gestion des changements : Chaque patch, scan ou changement de configuration doit faire l'objet d'un examen—avec des plans de test sécurisés et des stratégies de retour en arrière. Le coût des temps d'arrêt dans le monde des processus se mesure en millions.

• Donner à l'OT les connaissances en sécurité : Offrez une sensibilisation à la sécurité adaptée qui s’ancre dans les risques et vecteurs d’attaque les plus probables dans leur contexte (propagation de ransomware, compromission d’accès distant—pas des tentatives de phishing aléatoires en informatique).

ENCADRÉ : Une étude de cas en échec

En 2008, un opérateur majeur de pipeline a accidentellement arrêté le SCADA contrôlant la moitié du pays lorsqu'un administrateur informatique animé de bonnes intentions a lancé un scan de vulnérabilité Nessus sur le « VLAN OT ». Le scan a perturbé des passerelles série-à-IP fragiles et intolérantes au protocole, provoquant un arrêt en mode « fail-safe ». La leçon : testez, mettez en scène, et impliquez les experts de processus—toujours.

Étapes de déploiement pratiques : Sécuriser sur place, pas démolir et remplacer

Actions à court terme (premiers 90 jours)

1. Cartographiez l'ensemble du réseau OT, y compris les appareils non gérés et les « boîtes mystères ». Utilisez d'abord la cartographie passive.

2. Documentez toutes les connexions externes : accès à distance des vendeurs, lignes de modem, « jumpboxes » temporaires (devenues permanentes), hotspots WiFi.

3. Appliquez la segmentation réseau—d'abord au niveau du routage/pare-feu, puis avec des règles plus strictes au fil du temps. Tout passage IT/OT doit passer par une DMZ intermédiaire.

4. Installez des appareils de surveillance hors bande; assurez-vous que le trafic span/tap couvre tous les segments du système de contrôle.

5. Bloquez tous les protocoles et ports « non utilisés » découverts; enregistrez les tentatives de violations pour enquête.

Actions à moyen terme (3-12 mois)

1. Déployez des pare-feux/proxys DPI à des frontières de confiance clés; configurez avec des règles conservatrices (n'autorisez que les commandes et flux « de bonne réputation »).

2. Construisez des guides d'alerte pour le comportement anormal des dispositifs critiques; exercices avec l'équipe OT sur des procédures rapides d’isolement/déconnexion (exercices de table).

3. Évaluez la faisabilité de l'encapsulation de protocole (VPN, SSL) par connexion—considérez l'impact, et travaillez avec les vendeurs pour valider les méthodes.

4. Commencez un plan de cycle de vie des actifs. Signalez les appareils pour une mise à jour ou un remplacement progressif, mais prévoyez une dizaine d'années de « maintien en vie ».

5. Là où les fournisseurs supportent le durcissement (désactivation des services inutilisés, comptes par défaut), exécutez selon les règles de gestion du changement.

Actions à long terme (>1 an)

1. Établissez des évaluations de risque récurrentes des actifs OT hérités; suivez la mise en œuvre des étapes d'atténuation au fil du temps.

2. Pilotez de nouvelles architectures de segment sur des lignes à moindre risque en premier—migrez lentement, avec des mesures d’urgence en place.

3. Influencez l'approvisionnement et la gestion des vendeurs avec un œil vers la sécurité future (exigez que les nouveaux appareils supportent les standards de sécurité des protocoles, l'auditabilité et la patchabilité de l'industrie).

4. Créez un plan de réponse aux incidents combiné IT/OT, régulièrement exercé entre les équipes.

Conclusions et références

Sécuriser les systèmes OT hérités est un exercice de confinement mesuré, de surveillance attentive et de politique collaborative—pas de « sécurité instantanée ». Ce n'est pas toujours joli, et cela ne peut jamais être parfait, mais c'est à la fois possible et nécessaire. Concentrez-vous sur l'architecture réseau, les contrôles compensatoires, et une profonde visibilité—et surtout, ne déployez ou changez jamais en isolation des opérations OT.

Lectures supplémentaires et normes :

• ISA/IEC 62443 — Normes de sécurité OT fondamentales, incluant les principes de zonage et de canaux.

• NIST SP 800-82 — Guide de sécurité ICS; contrôles pratiques et directives de traitement d'incidents.

• Référence du modèle Purdue — « Le modèle industriel Purdue », voir la documentation ISA et les livres blancs SANS.

• ENISA : Dépendances des réseaux de communication pour les systèmes ICS/SCADA (2017)

• Protocoles historiques: Modbus (1979) | DNP3 (1993) | Profibus (1989)

Si vous ne retenez rien d'autre : Vous n'allez pas renforcer la sécurité OT par des patchs. Vous devez architecturer votre chemin, itérer, et respecter vos opérateurs.