Blog Zscaler
Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception
Sécurité OT : Ce que la directive « Prepare to Disconnect » de CI Fortify change pour les infrastructures critiques
En bref : CI Fortify est une recommandation conjointe publiée le 28 juillet 2026 par la CISA, l’ACSC de l’Australian Signals Directorate, le FBI, le NCSC britannique et le Canadian Centre for Cyber Security. Elle exige que les opérateurs d’infrastructures critiques soient en mesure d’isoler les systèmes OT vitaux de tous les autres réseaux lors d’un incident de cybersécurité, tout en continuant à fournir les services essentiels pendant cette période de déconnexion. Dans la plupart des environnements OT, le problème ne tient pas au plan prévu, mais à sa mise en œuvre : les réseaux plats ne disposent d’aucun point d’isolation préconfiguré permettant de l’appliquer.
Le 28 juillet 2026, la CISA, en collaboration avec l’Australian Signals Directorate (ASD) et son Australian Cyber Security Centre (ACSC), le FBI, le National Cyber Security Centre (NCSC) du Royaume-Uni et le Canadian Centre for Cyber Security, a publié conjointement des recommandations intitulées CI Fortify: Advice for Isolating Vital Systems. Le message est sans ambiguïté : en cas de cyberattaque ou de crise géopolitique, les opérateurs d’infrastructures critiques doivent être en mesure de déconnecter les systèmes OT vitaux des réseaux d’entreprise, d’Internet et des tiers, tout en continuant à fournir les services essentiels pendant cette période de déconnexion.
Il ne s’agit pas d’un simple discours général sur la préparation aux incidents. Les agences décrivent explicitement le contexte : des acteurs soutenus par des États qui s’implantent à l’avance dans les infrastructures critiques (Volt Typhoon est resté dissimulé dans les réseaux de ses victimes pendant au moins cinq ans) ainsi que des groupes de ransomwares qui ont compris que les industriels, les hôpitaux et les services publics paient plus rapidement lorsque leur production est à l’arrêt.
Les recommandations placent chaque opérateur OT face à une question difficile : si vous deviez isoler le réseau de votre site industriel dans les dix prochaines minutes, seriez-vous en mesure de le faire ? Sauriez-vous où intervenir, qui doit en autoriser l’isolement et quelles seraient les conséquences ? Pour la plupart des entreprises, la réponse est non. C’est précisément cet écart – entre un plan d’isolation qui existe sur le papier et une capacité d’isolation réellement conçue et testée – que CI Fortify cherche à combler.
Que requiert concrètement CI Fortify ?
Si l’on va au-delà du vocabulaire propre au cadre de référence, les recommandations définissent une démarche en six étapes :
- Identifier les systèmes vitaux – les systèmes OT et les systèmes auxiliaires indispensables au maintien du service critique.
- Identifier les clients critiques et les dépendances en amont.
- Définir les niveaux de criticité et de confiance pour les réseaux et les hôtes.
- Cartographier toutes les connexions aux systèmes vitaux : informatique d’entreprise, accès distant des fournisseurs, plateformes cloud, services accessibles depuis Internet, autres opérateurs.
- Définir à l’avance les points de séparation et d’isolation, ainsi que les autorisations et critères de déclenchement applicables avant tout incident.
- Créer et tester un plan d’isolation graduée – des exercices portant sur l’ensemble du système, et non des tests partiels, car ces derniers ne permettent pas d’identifier les dépendances partagées (services d’identité, DNS, historiens, licences) qui deviennent inaccessibles dès que le périmètre est isolé.
Les recommandations présentent l’isolation physique comme la protection la plus efficace, tout en reconnaissant qu’une déconnexion physique complète est impraticable pour les entreprises qui dépendent de réseaux d’opérateurs, de services cloud ou d’installations géographiquement disséminées. C’est le cas de la plupart des sites industriels modernes. Pour ces environnements, les agences recommandent de renforcer les périmètres OT, de supprimer les dépendances inutiles vis-à-vis du réseau d’entreprise et de conserver la capacité à restreindre progressivement les accès à mesure que la menace s’intensifie.
Ce modèle d’escalade porte un nom dans les recommandations : l’isolation graduée. La première étape consiste à couper les accès des télétravailleurs et des fournisseurs. Puis la connectivité au réseau d’entreprise. Ensuite, les systèmes connectés et, enfin, toutes les connexions externes, avec des critères de déclenchement définis à l’avance pour chaque étape et l’isolation complète des systèmes les plus vitaux comme état cible.
Pourquoi l’isolation graduée échoue-t-elle sur un réseau plat ?
L’isolation graduée présuppose que ces différents niveaux d’isolation sont déjà en place. Or, sur un réseau OT brownfield classique, ce n’est pas le cas. Sur le papier, la plupart des sites industriels sont encore décrits selon le modèle Purdue, avec des niveaux soigneusement cloisonnés et des conduits contrôlés entre eux. En pratique, des décennies de convergence IT/OT ont créé des environnements plats dans lesquels l’IHM, l’historien, le poste de travail d’ingénierie, le jump box du fournisseur et des centaines d’appareils non gérés partagent les mêmes domaines de diffusion. Les « points d’isolation » prévus par les recommandations devraient alors être improvisés en pleine intervention : règles de pare-feu d’urgence, modifications des VLAN, débranchement de câbles, le tout en s’appuyant à 2 heures du matin sur des connaissances détenues par quelques personnes, alors que l’attaquant est déjà à l’œuvre.
Les recommandations elles-mêmes considèrent les contrôles administratifs tels que les VLAN et les listes de contrôle d’accès comme « peu efficaces » : des mesures provisoires en attendant une véritable isolation, sur lesquelles il ne faut pas compter à long terme. Et les raisons sont connues de tous les opérateurs : ces contrôles sont statiques, sources d’erreurs à grande échelle et n’ont jamais été conçus pour contenir une menace qui se déplace déjà au sein du réseau. Un plan d’isolation qui repose sur la modification manuelle des listes de contrôle d’accès pendant une intrusion en cours équivaut à découvrir ses dépendances cachées au pire moment.
Le problème d’ingénierie est donc le suivant : comment doter un environnement OT de véritables points d’isolation préconfigurés et immédiatement activables, sans refaire le réseau, sans installer d’agents sur des appareils qui ne peuvent pas en accueillir et sans lancer un projet de segmentation qui s’enlise dès la première réunion de gestion des changements ?
Comment un kill switch anti-ransomware permet-il d’appliquer l’isolation graduée ?
C’est ici que la segmentation des appareils selon les principes du Zero Trust change véritablement la donne. Zscaler applique les règles au niveau de la passerelle locale: chaque appareil du réseau OT est isolé dans un segment qui lui est propre, tandis que chaque flux est-ouest est contrôlé selon des politiques fondées sur l’identité et le contexte, sans agent, sans modification de l’architecture réseau du site et sans prolifération d’ACL statiques.
Le kill switch anti-ransomware s’appuie sur cette infrastructure d’application des politiques et reprend presque à l’identique le modèle d’isolation graduée de CI Fortify. Plutôt que d’improviser le confinement en pleine attaque, les opérateurs définissent à l’avance des ensembles de politiques correspondant à des niveaux de gravité croissants. À un niveau de gravité élevé, ils peuvent bloquer sur l’ensemble du site les protocoles connus pour être utilisés lors des déplacements latéraux ; à un niveau supérieur, couper les accès distants des fournisseurs et des tiers ; et, au niveau de gravité maximal, désactiver en une seule action les communications avec des segments réseau entiers (une ligne de production ou un atelier, par exemple) tout en maintenant les flux critiques autorisés.

À la lumière du vocabulaire même des recommandations :
- Les points d’isolation ne sont plus des emplacements physiques qu’il faut identifier : ils deviennent des règles de politique documentées, activables en quelques secondes.
- L’isolation graduée n’est plus une succession de demandes de modification à traiter en urgence : elle devient un curseur de gravité, avec des mesures prédéfinies et testées pour chaque niveau.
- Les autorisations et les critères de déclenchement ne reposent plus sur une chaîne téléphonique : ils prennent la forme de contrôles d’accès et de mécanismes d’automatisation. Le kill switch étant accessible via une API, les outils SIEM, SOAR et EDR peuvent déclencher le confinement dès que le niveau de confiance dans la détection franchit un seuil.
- Les tests ne sont plus une opération perturbatrice annuelle : ils deviennent une pratique courante. L’isolation reposant sur des politiques, il est possible de la tester, d’observer ce qui cesse de fonctionner, de corriger les dépendances et de recommencer – un cycle itératif que les tests partiels ne permettent jamais de mener à bien.
Un point mérite d’être précisé : CI Fortify exige deux capacités distinctes, à savoir isoler rapidement les systèmes vitaux et pouvoir continuer à fonctionner dans cet état d’isolement pendant une période prolongée. Un kill switch répond directement au premier besoin : il permet de ramener le confinement de plusieurs heures d’improvisation à quelques secondes d’exécution. Or ces premières heures déterminent généralement si un incident se transformera en simple interruption de service ou en catastrophe. Le maintien d’un fonctionnement totalement déconnecté sur la durée relève de l’architecture et de la planification opérationnelle, aucun dispositif unique ne peut à lui seul résoudre cette question. Chaque opérateur doit vérifier dans son propre environnement s’il est réellement possible de maintenir cette situation, notamment en tenant compte des dépendances aux services d’identité, aux historiens et aux licences, qui ne se révèlent qu’au moment où le périmètre est effectivement isolé, plutôt que de se fier à une architecture de référence.
Par où les opérateurs OT doivent-ils commencer ?
La démarche préconisée par CI Fortify est la bonne, et la segmentation moderne des appareils permet d’accélérer chacune de ces étapes : découverte et classification automatiques pour identifier les systèmes vitaux et révéler les connexions dont vous ignoriez l’existence ; politiques fondées sur l’identité pour définir les points d’isolation sans revoir l’architecture du réseau ; politiques de kill switch fondées sur le niveau de gravité pour permettre de mettre immédiatement en œuvre l’isolation graduée ; et tests réguliers à faible risque pour identifier les dépendances avant qu’un adversaire ne les découvre.
Les agences ont clairement demandé aux opérateurs de se tenir prêts à déconnecter leurs systèmes. Les entreprises les mieux préparées ne seront pas celles dont les procédures d’isolation seront les plus étoffées. Ce seront celles pour lesquelles l’isolation sera une fonction déjà testée et immédiatement disponible.
Vous souhaitez voir concrètement à quoi ressemble une isolation conçue à l’avance dans votre environnement ? Demandez un atelier d’architecture OT pour cartographier vos systèmes vitaux, vos connexions et vos points d’isolation au regard du modèle CI Fortify.
FAQs
CI Fortify est une recommandation conjointe publiée le 28 juillet 2026 par la CISA, l’ACSC de l’Australian Signals Directorate, le FBI, le NCSC britannique et le Canadian Centre for Cyber Security. Elle fournit aux opérateurs d’infrastructures critiques des mesures concrètes pour isoler les systèmes OT vitaux et les systèmes auxiliaires de tous les autres réseaux en cas d’incident de cybersécurité ou de crise géopolitique, tout en continuant à fournir les services essentiels pendant l’isolement.
Non. Les recommandations présentent l’isolation physique comme la protection la plus efficace, mais reconnaissent qu’elle est impraticable pour les entreprises qui dépendent de services cloud, de réseaux d’opérateurs ou d’installations réparties sur plusieurs sites. Pour ces environnements, elles recommandent de renforcer les périmètres OT, de réduire les dépendances vis-à-vis du réseau d’entreprise et de disposer d’une capacité d’isolation graduée pouvant être rapidement mise en œuvre lorsque la menace s’intensifie.
L’isolation graduée consiste, selon les recommandations, à restreindre progressivement la connectivité à mesure que le niveau de menace augmente : d’abord en bloquant les accès des télétravailleurs et des fournisseurs, puis la connectivité au réseau d’entreprise, ensuite les systèmes connectés et les connexions externes, avec des critères de déclenchement et des autorisations définis avant tout incident, jusqu’à l’isolation complète des systèmes les plus vitaux.
Un kill switch anti-ransomware est un mécanisme de confinement préconfiguré intégré à Zscaler Zero Trust Device Segmentation. Les opérateurs sélectionnent des niveaux de gravité croissants qui permettent de verrouiller progressivement les protocoles et les ports vulnérables, de couper les accès des tiers et les accès distants et, en un instant, de désactiver les communications avec des segments réseau entiers, comme une ligne de production, afin d’empêcher les déplacements latéraux sans devoir improviser des modifications du pare-feu. Il peut être piloté via une API afin d’automatiser le déclenchement des mesures de confinement à partir des outils SIEM, SOAR ou EDR.
La segmentation par pare-feu et par VLAN repose sur des règles statiques complexes à maintenir, qui se dégradent au fil du temps et dont la modification nécessite des fenêtres de maintenance, autant de contraintes que les recommandations identifient comme les limites des contrôles administratifs. La segmentation des appareils fondée sur l’identité isole chaque appareil dans un segment qui lui est propre au niveau de la passerelle locale, sans agents ni modification de l’architecture du réseau. Les points d’isolation sont ainsi définis par des politiques, qui peuvent être testées et modifiées sans interruption de service.
Cet article a-t-il été utile ?
Clause de non-responsabilité : Cet article de blog a été créé par Zscaler à des fins d’information uniquement et est fourni « en l’état » sans aucune garantie d’exactitude, d’exhaustivité ou de fiabilité. Zscaler n’assume aucune responsabilité pour toute erreur ou omission ou pour toute action prise sur la base des informations fournies. Tous les sites Web ou ressources de tiers liés à cet article de blog sont fournis pour des raisons de commodité uniquement, et Zscaler n’est pas responsable de leur contenu ni de leurs pratiques. Tout le contenu peut être modifié sans préavis. En accédant à ce blog, vous acceptez ces conditions et reconnaissez qu’il est de votre responsabilité de vérifier et d’utiliser les informations en fonction de vos besoins.
Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception
En envoyant le formulaire, vous acceptez notre politique de confidentialité.



