3.1 Modèle de Purdue, DMZ industrielle & zones IEC 62443

Le modèle de Purdue (Purdue Enterprise Reference Architecture, PERA) a été formalisé à la fin des années 1980 et au début des années 1990 à l'université Purdue, aux États-Unis, pour décrire l'architecture d'une entreprise industrielle — au départ dans une logique d'intégration de la production et de la gestion, pas de sécurité. Il a été repris par la norme ISA-95 (Enterprise-Control System Integration), devenue l'IEC 62264, et sert aujourd'hui de grille de lecture commune à toute la cybersécurité industrielle, notamment à l'IEC 62443.

C'est ce glissement d'usage qu'il faut avoir en tête : un modèle conçu pour faire circuler l'information entre l'atelier et la gestion est devenu le cadre de référence pour l'empêcher de circuler librement. Sa force est d'offrir un vocabulaire partagé entre un automaticien et un RSSI — ce qui, en pratique, est déjà beaucoup.

L'idée fondamentale du modèle est de structurer les systèmes en niveaux hiérarchiques, du process physique (niveau 0) à internet (niveau 5), avec des règles strictes sur les flux d'information entre niveaux. C'est la base de la défense en profondeur OT.

Pour chaque niveau, on définit :

• Le type de matériel qui s'y trouve.
• Les protocoles autorisés.
• Les flux autorisés vers les niveaux adjacents.
• Les règles de sécurité applicables.
• Les autorités (qui peut y accéder, qui peut faire quoi).

Principe directeur : les flux descendent (commandes, configurations) et remontent (mesures, alarmes), mais chaque transition entre niveaux doit être filtrée. On ne saute jamais un niveau directement.

La DMZ industrielle (Demilitarized Zone) est le sas de sécurité entre l'IT et l'OT. Concept directement inspiré des DMZ web (frontaux internet vs serveurs internes), il est adapté aux exigences OT.

Composants typiques d'une DMZ industrielle bien conçue :

• Deux pare-feu industriels en sandwich : un côté IT (4 → 3,5), un côté OT (3,5 → 3), idéalement de constructeurs différents pour qu'une même vulnérabilité ne fasse pas tomber les deux barrières.
• Bastion d'administration (jump server) : seul point d'entrée pour administrer l'OT, avec authentification multifacteur, comptes nominatifs et enregistrement des sessions.
• Miroir Historian / réplication : copie en lecture seule des données OT pour consultation IT (sans accès direct).
• Serveur de mise à jour antivirus / WSUS local : les automates et SCADA ne se mettent pas à jour directement depuis internet.
• Serveur de patch OT : staging et validation des patches avant déploiement.
• Serveur de transfert de fichiers sécurisé (SFTP, MFT) : pour les échanges contrôlés.
• SIEM / collecteur de logs OT : centralisation des journaux pour le SOC.
• Optionnellement : diode de données (data diode) pour les flux les plus critiques — communication purement unidirectionnelle physique.

Règles d'or de la DMZ industrielle :

1. Aucun flux direct niveau 4 ↔ niveau 3.
2. Initiation des flux : depuis OT vers DMZ (pull), pas l'inverse (push). Les automates ne reçoivent pas de connexion entrante de l'IT.
3. Protocoles limités : pas de SMB, RDP, AD entre niveaux. Seuls les protocoles strictement nécessaires.
4. Pas d'identifiants partagés entre IT et OT (comptes AD distincts, ou idéalement AD OT séparé).
5. Inspection profonde du trafic (DPI) avec règles spécifiques aux protocoles industriels.

La norme IEC 62443-3-2 introduit le concept de zones et conduits (zones and conduits) pour structurer la segmentation. Une zone regroupe des actifs ayant des exigences de sécurité communes ; un conduit est le chemin de communication contrôlé entre deux zones.

Critères de regroupement en zones :

• Criticité métier (production, support, exploration).
• Niveau de Purdue (0 à 5).
• Sûreté fonctionnelle (SIL) — un SIS forme toujours une zone à part.
• Type de protocole (Modbus, Profinet, EtherNet/IP).
• Géographie (atelier A, atelier B, site distant).
• Domaine fonctionnel (utilités, production, packaging).

Démarche IEC 62443-3-2 (modèle ZCAR — Zone, Conduit, Asset, Risk) :

1. Identifier l'actif et son périmètre (system under consideration — SuC).
2. Réaliser un cyber risk assessment initial (high-level).
3. Partitionner le SuC en zones et conduits.
4. Pour chaque zone et conduit, conduire une analyse de risque détaillée.
5. Définir le SL-T (Security Level Target) attendu pour chaque zone/conduit (de SL1 à SL4).
6. Comparer avec le SL-A (Security Level Achieved) actuel.
7. Définir un plan de traitement pour combler l'écart.
8. Documenter le tout dans un Cybersecurity Requirements Specification (CRS).

Exemple d'application — usine agroalimentaire :

• Zone A : SIS détection ATEX (SL3, isolée totalement).
• Zone B : ligne de production 1 (PLC + HMI, SL2).
• Zone C : ligne de production 2 (PLC + HMI, SL2).
• Zone D : utilités (compression, vapeur — SL2).
• Zone E : SCADA central + Historian (SL2-SL3).
• Zone F : MES (SL2, dans DMZ industrielle).
• Conduit A↔E : firewall industriel + monitoring passif (uniquement remontée d'alarme).
• Conduit B↔E : flux supervision en bidirectionnel, protocoles précis (S7, OPC UA).
• Conduit F↔IT : DMZ + jump server + MFA.

Pour le détail de la cotation des niveaux de sécurité (SL-T, SL-C, SL-A) et des sept exigences fondamentales qui les composent, voir notre article la norme IEC 62443 expliquée.

L'outil méthodologique de l'ANSSI (« Cas pratique de la segmentation des systèmes industriels ») et les guides de l'ISA Global Cybersecurity Alliance (ISAGCA) détaillent la méthode complète.

Quelques erreurs récurrentes observées par les RSSI et auditeurs cyber industriels :

• Réseau « plat » : un seul grand VLAN couvrant IT et OT, sans cloisonnement. Le pire scénario, encore trop fréquent dans les PME industrielles.
• « Réseau OT séparé » mais avec passerelle non contrôlée : il existe bien deux infrastructures, mais une borne Wi-Fi mal configurée, un PC dual-NIC, un commutateur dual port relient les deux. Cas typique : passerelle de synchronisation Historian non documentée.
• DMZ industrielle « pour la forme » : présente en théorie mais les règles firewall sont en mode allow any any ou avec des règles trop larges.
• VPN constructeur permanent arrivant directement dans la zone OT en contournant la DMZ.
• Active Directory unique partagé entre IT et OT : le compromis d'un compte admin IT donne accès à tout l'OT.
• Postes opérateurs HMI connectés à internet pour la mise à jour ou la consultation web. Cible privilégiée.
• SIS dans le même réseau que le DCS — exactement ce qui a permis Triton.
• Pas de monitoring sur le réseau OT : l'attaquant peut y rester pendant 6 mois sans être détecté.

Audit cyber OT : les 5 premières questions à se poser :

1. Est-ce que mon SCADA reçoit des emails ? (réponse souhaitée : non).
2. Est-ce qu'un poste utilisateur du marketing peut accéder à un automate ? (réponse souhaitée : non).
3. Combien de comptes AD ont accès aux automates ? (réponse souhaitée : minimum nécessaire, nominatifs).
4. Mon SIS partage-t-il un réseau avec mon DCS ? (réponse souhaitée : non, isolé).
5. Combien d'accès distants OT existent aujourd'hui dans mon usine ? (la plupart des entreprises ne savent pas y répondre précisément — c'est inquiétant).

La question revient dans tous les projets, et la réponse honnête est : le modèle reste utile comme grille de lecture, mais il ne décrit plus à lui seul les architectures réelles. Trois évolutions l'ont pris en défaut.

• Les équipements connectés court-circuitent les niveaux. Un capteur IIoT qui remonte ses mesures directement vers un service en ligne relie le niveau 0 au niveau 5 sans passer par aucune des couches intermédiaires. La hiérarchie stricte « on ne saute jamais un niveau » ne tient plus telle quelle.
• La télémaintenance constructeur est transversale par nature. Un intervenant distant doit atteindre un automate : aucun niveau du modèle ne décrit ce flux, qui se traite par un bastion et une autorisation à la demande, pas par un étage supplémentaire.
• Le MES et l'historisation migrent vers le cloud. Le niveau 3 se retrouve partiellement à l'extérieur du site, ce que le modèle d'origine n'envisageait pas.

Ce n'est pas une raison pour l'abandonner. C'est une raison pour le compléter par le raisonnement en zones et conduits de l'IEC 62443-3-2, qui ne raisonne pas en étages mais en ensembles d'actifs partageant les mêmes exigences de sécurité — une logique qui absorbe sans difficulté un capteur connecté ou un service hébergé. Dans la pratique, les deux se combinent : le modèle de Purdue donne le cadre et le vocabulaire, les zones et conduits donnent la granularité et la traçabilité de l'analyse de risque.

Concevoir et tenir cette architecture est un métier : voir les fiches architecte réseau industriel et administrateur réseaux industriels (OT).