Gardez le modèle de Purdue comme carte. Placez une frontière devant chaque machine.
La plupart des échanges sur la sécurité OT commencent par les niveaux de Purdue. Pourtant, presque chaque site réel a des flux qui les contournent. Ce guide couvre les niveaux, ce qu'ont changé l'accès à distance, l'IIoT et l'analytique cloud, et ce qu'il faut appliquer quand redessiner le réseau n'est pas une option.
Dernière mise à jour:
Qu'est-ce que le modèle de Purdue ?
Le modèle de Purdue, de son nom complet Purdue Enterprise Reference Architecture (PERA), organise un système de contrôle industriel en niveaux. Le niveau 0 est le procédé physique, les niveaux 4 et 5 l'informatique d'entreprise. Une DMZ industrielle au niveau 3.5 sépare l'exploitation de la gestion. L'université Purdue l'a rédigé dans les années 1990 comme modèle d'intégration de la production. Il n'a jamais été conçu comme un contrôle de sécurité. L'usage sécurité est venu ensuite et repose sur une hypothèse : le trafic circule verticalement, niveau par niveau, et on peut l'inspecter à chaque frontière.
Cette hypothèse ne tient plus. Les niveaux restent un excellent vocabulaire commun, et cela suffit à les garder. Mais le schéma ne décrit plus la façon dont les paquets circulent dans un site moderne.
Les niveaux du modèle de Purdue et ce qu'on y trouve.
Il y a six niveaux, DMZ comprise. La numérotation monte depuis le procédé physique. La plupart des schémas réseau vont dans l'autre sens, ce qui crée souvent la confusion.
| Niveau | Nom | Ce qui s'y trouve | En cas de compromission |
|---|---|---|---|
| Niveau 5 | Entreprise | Informatique de groupe, ERP, messagerie, réseau métier. | Perturbation du métier, et un point d'appui avec un chemin vers l'exploitation. |
| Niveau 4 | Métier du site | Ordonnancement, logistique, services informatiques du site. | La planification est exposée et l'attaquant est à un saut de la DMZ. |
| Niveau 3.5 | DMZ industrielle | La frontière IT/OT : rebonds, serveurs de correctifs, courtiers de données, historians répliqués. | Tout l'intérêt du modèle disparaît. Les deux côtés sont exposés d'un coup. |
| Niveau 3 | Exploitation du site | Conduite d'usine, historians, postes d'ingénierie, MES. | Recettes et logique de commande deviennent accessibles, et les outils d'ingénierie écrivent vers le bas. |
| Niveau 2 | Supervision | SCADA, HMI, pupitres opérateur DCS. | On peut montrer une chose aux opérateurs pendant qu'une autre se passe sur le procédé. |
| Niveau 1 | Commande de base | Automates, unités de télégestion, variateurs, automates de sécurité. | La logique de commande peut être modifiée. C'est là que commencent les conséquences physiques. |
| Niveau 0 | Procédé physique | Capteurs, actionneurs, vannes, moteurs. | Le procédé lui-même. Les dégâts se mesurent en équipements et en sécurité des personnes, pas en données. |
Le niveau 3.5 est celui qui fait débat. Il ne figure pas du tout dans la PERA d'origine ; il a été ajouté par la communauté sécurité précisément parce que le modèle n'avait pas de réponse pour la frontière IT/OT. Cela mérite d'être rappelé quand on présente la DMZ comme l'idée centrale du modèle.
Trois connexions qui contournent les niveaux.
Aucune n'est une attaque. Ce sont des connexions ordinaires, validées par le métier. C'est pour cela qu'elles sont difficiles à contester, et qu'elles sont toujours là.
L'accès à distance saute tous les niveaux d'un coup.
Un VPN fournisseur se termine près de la bordure entreprise et atteint un rebond capable de parler aux automates. Sur le schéma, ce chemin franchit cinq frontières. Sur le réseau, c'est un seul saut, et un identifiant couvre toute la distance. La séparation existe dans le dessin, pas dans la table de routage.
L'IIoT envoie les données directement hors du site.
Une passerelle en périphérie publie directement vers un service cloud. Elle ne touche jamais les niveaux 1, 2 ou 3, donc aucune frontière ne l'inspecte, et le chemin retour est une entrée non surveillée, située sous tout ce que la DMZ peut voir.
L'analytique cloud brouille les niveaux 3 et 4.
Dès qu'un historien se réplique vers un tableau de bord cloud, la distinction entre exploitation du site et métier relève du contrat, pas d'une mesure réseau. Un locataire cloud compromis atteint des données d'usine que deux pare-feu étaient censés protéger.
La DMZ industrielle concentre le risque en un point.
La réponse du modèle à la frontière IT/OT est un passage unique, partagé et lourdement défendu. C'était sensé quand les passages étaient rares. Cela tient mal quand tout doit passer.
Une brèche expose les deux côtés
Tout ce qui compte est soit devant la DMZ, soit derrière. Il n'y a pas de troisième position. Compromettre le passage, c'est compromettre le dispositif, pas une machine.
Des flux sans rapport partagent un seul point de passage
Sessions fournisseurs, télémétrie, distribution de correctifs et réplication d'historians passent par la même frontière avec la même posture, parce qu'il n'y en a qu'une à leur offrir.
La visibilité s'arrête au passage
La DMZ peut journaliser qu'une connexion a été autorisée. Ce que cette connexion fait ensuite, d'est en ouest, sur un réseau d'usine à plat, n'est pas quelque chose qu'un contrôle de frontière est placé pour voir.
Les changements ont des semaines de retard
Chaque nouvelle intégration est une demande de règle pare-feu. Les règles s'accumulent, personne ne retire les anciennes, et la politique effective s'éloigne de la politique documentée.
Les auditeurs demandent des preuves que les niveaux ne fournissent pas.
C'est souvent ce qui lance la discussion. Les référentiels demandent désormais des preuves par machine et par identité. Une frontière entre niveaux ne les produit pas.
Zones et conduits de l'IEC 62443
La 62443 demande de définir des zones par le risque et les conduits entre elles, puis d'appliquer et de documenter les deux. Les niveaux de Purdue sont un point de départ pour les zones, mais ce n'est pas la même chose, et regrouper tout un niveau dans une zone est rarement défendable sur le plan du risque.
NIST SP 800-82r3
La révision actuelle s'est éloignée de Purdue comme architecture de référence au profit de la segmentation par zones et du Zero Trust. Citer Purdue comme son architecture ne correspond plus proprement aux recommandations.
NERC CIP-005
Le périmètre de sécurité électronique doit être énuméré, et chaque chemin d'accès qui le traverse recensé. Les tunnels fournisseurs qui contournent la hiérarchie sont exactement ce que la norme veut voir listé, et les moins susceptibles de figurer sur le schéma.
CMMC et NIST SP 800-171
Le moindre privilège est exigé par système, avec une trace par accès. Une segmentation grossière qui place des dizaines d'actifs dans une même zone de confiance ne peut pas montrer qui a atteint quel actif, seulement que quelque chose a atteint la zone.
Les options d'application, comparées.
Rien ici ne remplace le modèle de Purdue comme vocabulaire. Ces options le remplacent comme stratégie d'application, un rôle pour lequel il n'a jamais été conçu.
| Approche | Ce qu'elle change | Ce qu'elle coûte |
|---|---|---|
| Zones et conduits (IEC 62443) | Les zones sont tracées par le risque plutôt que par la fonction, et chaque conduit entre elles est explicite et documenté. | Une véritable analyse de risque, et le travail politique de faire valider les zones par l'exploitation et l'informatique. |
| Micro-segmentation | Le rayon d'impact devient un actif ou un petit groupe, plutôt qu'un niveau entier. | Traditionnellement une refonte des VLAN et du routage, d'où les blocages sur les usines existantes. |
| Zero Trust pour l'OT | Identité et politique sont vérifiées à chaque session, au lieu d'être déduites du sous-réseau d'origine du paquet. | Une couche d'identité que les réseaux OT n'ont généralement pas, et un endroit où l'appliquer. |
| Réseau défini par logiciel | La politique est définie centralement puis poussée, ce qui arrête l'accumulation de dérive de configuration. | Une infrastructure et des compétences nouvelles, en pratique réservé aux projets neufs. |
| Garder Purdue, ajouter l'application | Les niveaux restent le langage commun ; le contrôle réel se déplace vers une frontière par actif. | Le moins perturbant, mais cela suppose un point d'application capable de se placer devant des actifs qu'on ne peut pas modifier. |
Protéger chaque machine sans redessiner le réseau.
La plupart des options ci-dessus supposent de restructurer le réseau. Sur un site en production, les équipements ne peuvent souvent être ni patchés, ni arrêtés, ni réadressés. C'est là que le projet s'enlise en général. L'alternative est de laisser la topologie telle quelle. Vous placez une frontière devant les machines qui comptent, une à une.
Se raccorde à votre réseau existant.
L'appliance se raccorde au réseau que vous avez déjà plutôt que de s'y insérer en ligne : le premier jour est sans impact. Vous dirigez ensuite vers elle les flux à protéger, actif par actif, et rien ne bouge tant que vous ne le déplacez pas.
Une frontière par machine.
Chaque actif protégé est derrière sa propre frontière appliquée. En atteindre un ne donne rien vers le suivant : le déplacement latéral que la DMZ ne voyait jamais n'a plus où aller.
Identité vérifiée à chaque session.
Chaque connexion est liée à une identité nommée, à un actif précis et à un protocole, avec une borne de temps. C'est la preuve par actif que réclament CIP-005, CMMC et la 62443, produite par l'exploitation et non par un projet d'audit séparé.
Fonctionne sur des machines qui ne peuvent pas changer.
L'actif garde son IP, son firmware et sa configuration. Un automate d'il y a vingt ans obtient la même frontière appliquée qu'un poste d'ingénierie récent, parce qu'on ne lui demande rien.
Comment évoluer sans remplacer les équipements.
Inutile d'abandonner le modèle ou de reconstruire le réseau. Repérez où le schéma et le site divergent. Puis comblez les écarts par ordre de priorité.
- 01
Cartographier le trafic réel, pas celui que le schéma suppose. Chaque VPN, chaque passerelle en périphérie, chaque réplication cloud. L'écart entre les deux documents est le constat.
- 02
Classer les actifs par conséquence plutôt que par niveau. Un automate de sécurité et un automate d'éclairage sont au même niveau et ne posent pas le même problème.
- 03
Placer une frontière devant les actifs à plus forte conséquence d'abord, et éprouver le schéma sur quelques-uns avant d'engager un déploiement.
- 04
Faire aboutir chaque tunnel partagé sur une passerelle qui donne un accès nommé, restreint et borné dans le temps. Un identifiant fournisseur qui ouvre tout un réseau est le plus gros écart de la plupart des parcs.
- 05
Journaliser à la frontière que vous avez créée, pas seulement en bordure d'usine, et établir ce qui est normal par actif pour rendre l'anormal visible.
- 06
Garder les niveaux de Purdue dans la documentation et dans les échanges. Perdre le vocabulaire commun coûte plus cher que ce que cela rapporte.
Emportez l'analyse complète.
La version longue : comment la hiérarchie s'érode en pratique, pourquoi la DMZ industrielle concentre le risque qu'elle devait réduire, et l'architecture par actif qui la remplace.
12 pages
Ce que vous y apprendrez
Où les cinq niveaux cessent de décrire le trafic réel, et lequel des trois contournements est en général présent en premier sur une usine existante.
L'architecture par actif
Comment déployer des frontières par actif de façon incrémentale face à des équipements qu'on ne peut ni corriger, ni ré-adresser, ni arrêter.
Voyez comment le trafic circule vraiment chez vous.
Votre schéma Purdue et votre trafic réel ont divergé ? Nous pouvons vous montrer où se trouvent les contournements sur votre réseau. Nous pouvons aussi chiffrer ce que demanderait la protection des machines critiques.
Sécurité des réseaux OT
Comment imposer une architecture de zones sur plusieurs sites sans refonte des VLAN.
Voir la solutionPasser en revue votre topologie
Une revue sur votre parc : où le trafic contourne la hiérarchie, quels actifs sont exposés, et à quoi ressemblerait l'application des règles.
Questions fréquentes sur le modèle de Purdue.
Le niveau de la DMZ industrielle, qui n'apparaît pas dans la Purdue Enterprise Reference Architecture d'origine. Il a été ajouté ensuite par la communauté sécurité.
Comme architecture de sécurité, en grande partie oui. Comme vocabulaire commun pour décrire un parc industriel, non : il reste le plus utile qui existe. Les niveaux expliquent toujours bien où se situe un système. L'usage sécurité supposait que le trafic traverse les niveaux dans l'ordre et peut être inspecté à chaque frontière. Ce n'est plus vrai sur un site avec accès distant des fournisseurs, passerelles IIoT et réplication cloud. Gardez les niveaux pour décrire. Ne comptez pas sur eux pour appliquer.
Le modèle de Purdue est une hiérarchie descriptive de niveaux fonctionnels. L'IEC 62443 est une norme qui demande de définir des zones selon le risque, de définir les conduits entre elles, puis d'appliquer et documenter des exigences de sécurité pour chacune. Les niveaux de Purdue servent souvent de première ébauche des zones 62443. Ils ne sont pas équivalents, car une zone se définit par un risque partagé plutôt que par une fonction partagée. Deux actifs du même niveau Purdue relèvent souvent de zones différentes.
Ils décrivent des choses sans rapport et ne sont pas des alternatives. Le modèle OSI comporte sept couches décrivant la structure d'une communication réseau, de la signalisation physique jusqu'à l'application. Le modèle de Purdue comporte des niveaux décrivant où se situent les systèmes dans une usine, du procédé physique jusqu'à l'informatique d'entreprise. OSI répond à comment un paquet est construit ; Purdue répond à ce que fait une machine et où elle se place.
Le niveau 0 est le procédé physique, capteurs et actionneurs. Le niveau 1 est la commande de base, les automates, les unités de télégestion et les automates de sécurité. Le niveau 2 est la supervision, SCADA et HMI. Le niveau 3 est l'exploitation du site, historians, MES et postes d'ingénierie. Le niveau 3.5 est la DMZ industrielle, la frontière IT/OT. Les niveaux 4 et 5 sont le métier du site et l'informatique d'entreprise. La numérotation monte depuis le procédé physique, à l'inverse de la plupart des schémas réseau.
Non, et présenter la question comme un choix aide rarement. Gardez les niveaux comme documentation et langage commun. Changez l'endroit où s'applique la sécurité : d'une frontière entre niveaux à une frontière devant chaque actif, avec une identité vérifiée à chaque session. La plupart des parcs finissent avec Purdue au mur et une application par actif sur le réseau. C'est une position cohérente en soi.
PERA est le nom complet de ce que tout le monde appelle le modèle de Purdue. Theodore Williams et le Purdue University Consortium l'ont publié au début des années 1990 comme modèle de référence pour la production intégrée par ordinateur. Il couvrait bien plus que la sécurité : il décrivait toute l'entreprise, du procédé physique à la planification. Ce qui est resté dans l'usage courant, c'est la hiérarchie des niveaux 0 à 5, plus la DMZ industrielle que les praticiens ont ajoutée ensuite au niveau 3.5. Quand on parle de Purdue reference model ou de Purdue reference architecture, on parle de cette hiérarchie, pas du document d'origine du consortium.
Il fournit une carte commune. Une carte vaut beaucoup quand l'IT et l'OT décrivent le même parc avec des mots différents. Placer un actif au niveau 1 ou au niveau 3 tranche ce qu'il fait, ce qui lui parle et ce que coûterait sa compromission. Le modèle rend aussi les déplacements latéraux visibles : si un flux traverse trois niveaux pour atteindre un automate, cela apparaît comme un fait de conception. En revanche, il n'applique rien. Les niveaux sont de la documentation. La valeur sécurité vient de l'association de la carte avec une application vérifiée à chaque session, devant chaque actif.
Les niveaux sont le point de départ habituel de la segmentation. Chaque niveau devient une zone, et le trafic entre niveaux passe par un conduit contrôlé. La DMZ industrielle est le point de passage entre IT et OT. Cette correspondance explique pourquoi on associe si souvent Purdue et segmentation, et c'est aussi là que le modèle montre son âge. Segmenter par niveau suppose un trafic vertical, un niveau à la fois. Ce n'est plus vrai depuis que des passerelles IIoT publient directement du niveau 0 vers le cloud. La segmentation compte toujours, mais l'unité utile est désormais l'actif plutôt que le niveau.
