Cybersécurité OT
Le modèle du château et des douves : comment pense (et échoue) la cybersécurité OT classique
Par Raúl Bricio ·
Si vous avez déjà discuté avec un ingénieur cybersécurité de la protection d'un site industriel, vous avez probablement entendu l'expression « modèle château et douves » (castle-and-moat). C'est l'une des analogies les plus anciennes — et les plus utiles — du secteur pour expliquer, sans jargon technique, comment les réseaux industriels (OT) ont traditionnellement été protégés. C'est aussi l'analogie parfaite pour expliquer pourquoi cette protection, laissée telle quelle, ne suffit plus.
L'idée d'origine : un seul grand mur
Un château médiéval se défendait avec une logique simple : un haut mur d'enceinte, des douves tout autour, une seule porte gardée. Tout ce qui était à l'intérieur était considéré comme « de confiance » ; tout ce qui était à l'extérieur était hostile. Si le mur tenait, l'intérieur était en sécurité.
Pendant des décennies, les réseaux OT (les systèmes qui pilotent automates, SCADA, robots et lignes de production) ont été conçus exactement de cette façon :
- Le mur est le pare-feu périmétrique entre le réseau de l'usine (OT) et le réseau de l'entreprise (IT).
- Les douves représentent la séparation physique ou logique qui complique l'accès direct depuis l'extérieur.
- La porte gardée est l'unique point d'accès distant, généralement un VPN ou un serveur relais (jump server).
- L'intérieur du château, c'est tout le réseau d'usine : automates, IHM, historiens de données — tout traité comme « zone de confiance » une fois à l'intérieur.
Cette logique a raisonnablement bien fonctionné tant que les réseaux OT étaient physiquement isolés (« air-gapped ») et que personne à l'extérieur n'avait besoin d'y accéder. Le problème, c'est que ce postulat n'est plus vrai depuis plus de dix ans.
Pourquoi le château à un seul mur ne protège plus
Le modèle à périmètre unique a un défaut structurel : une fois le mur franchi, on a accès à tout. Et aujourd'hui, il existe bien plus de façons de le franchir qu'à l'époque où ce modèle a été conçu :
- Un prestataire externe se connecte avec son propre ordinateur portable pour dépanner une machine — et cet ordinateur est déjà infecté.
- Un employé branche une clé USB contenant une mise à jour firmware qui transporte un malware à son insu.
- Un VPN de maintenance à distance a été ouvert il y a des années et personne ne l'a revu depuis.
- La convergence IT/OT (portée par l'Industrie 4.0, la maintenance prédictive, les tableaux de bord cloud) multiplie les points de connexion entre le réseau de l'entreprise et l'atelier.
Dans tous ces cas, l'attaquant ne franchit pas le mur depuis l'extérieur : il est déjà dans les douves, et le modèle château-et-douves n'a aucune réponse à cela. C'est la même raison pour laquelle l'IT migre depuis des années vers des modèles « zero trust » — sauf qu'en OT, on ne peut pas appliquer le zero trust de la même façon : un automate de 2008 ne peut pas s'authentifier avec des certificats modernes, et un arrêt non planifié causé par un incident de sécurité peut coûter bien plus cher que sur un serveur de bureau.
La traduction réelle : zones et conduits (IEC 62443)
C'est ici que l'analogie cesse d'être une jolie métaphore pour devenir de l'ingénierie appliquée. La norme IEC 62443 — la référence en matière de cybersécurité pour les systèmes d'automatisation et de contrôle industriels — ne propose pas « un mur plus grand ». Elle propose de nombreux murs plus petits, organisés par criticité.
En termes de château : au lieu d'un seul périmètre extérieur, on a une basse-cour, une enceinte intérieure, un donjon — et chaque anneau a sa propre porte et son propre niveau de surveillance. En termes IEC 62443, cela s'appelle la segmentation en zones et conduits :
- Zones : les actifs sont regroupés par fonction et par criticité — le réseau d'un automate de sécurité fonctionnelle n'a rien à voir avec celui d'une imprimante d'étiquettes. Chaque zone a son propre niveau de sécurité cible (Security Level, SL 1 à 4).
- Conduits : toute communication entre zones passe par un point contrôlé et audité — pas de trafic libre juste « parce qu'on est déjà dans le château ».
- Défense en profondeur : si un attaquant compromet une zone, la segmentation limite le mouvement latéral vers les zones plus critiques — la basse-cour peut tomber sans que le donjon tombe avec elle.
Cela ne supprime pas le périmètre (le mur extérieur reste nécessaire), mais il cesse d'être l'unique ligne de défense. La question n'est plus « le mur tient-il ? » mais « si le mur tombe, à quoi l'attaquant a-t-il vraiment accès ? »
Ce que cela signifie dans un audit réel
Quand nous auditons un site, la question qui compte vraiment n'est pas de savoir si vous avez un pare-feu (presque tout le monde en a un), mais :
- Le réseau d'usine est-il segmenté en zones de criticité réelle, ou est-ce un seul réseau plat avec un pare-feu à l'entrée ?
- Y a-t-il de la visibilité sur ce qui communique entre les zones, ou suppose-t-on que « tout ce qui est interne est de confiance » ?
- Les accès distants (prestataires, maintenance) passent-ils par un conduit audité, ou est-ce un VPN ouvert depuis 2015 ?
- Les actifs les plus critiques — ceux qui arrêtent la production ou mettent des personnes en danger — sont-ils dans la zone au niveau de sécurité le plus élevé, ou mélangés avec le reste ?
Un château à un seul mur coûte moins cher à construire. Mais quand il tombe, il tombe entièrement. Un site segmenté en zones et conduits coûte plus cher à concevoir — mais quand quelque chose casse, c'est une zone qui tombe, pas tout le site.
Si vous voulez savoir où se situe votre installation sur ce spectre, c'est exactement ce qu'évalue un audit IEC 62443 : non pas si vous avez un mur, mais combien de murs vous avez et où ils sont placés.