Qu'est-ce que la sécurité IT et OT ?
La sécurité IT et OT protège deux domaines distincts que les attaquants exploitent désormais comme une seule surface d’attaque. L’ampleur du problème est documentée : le rapport 2024 sur la criminalité Internet du FBI a reçu plus de 4 800 plaintes d’organisations d’infrastructures critiques victimes de cyberattaques, avec les ransomwares, la menace la plus répandue dans ces secteurs, en hausse de 9 % d’une année sur l’autre. La sécurité IT et OT réduit ce risque en séparant les systèmes métiers des processus industriels et en vous aidant à stopper la compromission IT avant qu’elle ne devienne une perturbation physique.
La sécurité IT protège les systèmes que vous utilisez pour traiter, stocker et transmettre les informations métier. Les serveurs, ordinateurs portables, plateformes cloud et applications d’entreprise relèvent tous de ce domaine. Le modèle de priorité suit la triade classique CID : Confidentialité d’abord, puis Intégrité, puis Disponibilité. Si un serveur nécessite un correctif d’urgence, vous le mettez hors ligne, appliquez la mise à jour, puis le remettez en service.
La sécurité OT protège les systèmes qui interagissent directement avec le monde physique. Les systèmes SCADA surveillant un réseau électrique, les API contrôlant un processus chimique et les IHM pilotant une station de traitement d’eau sont des actifs OT. Le guide NIST sur la sécurité OT définit l’OT comme « un large éventail de systèmes et dispositifs programmables qui interagissent avec l’environnement physique ». Le modèle de priorité s’inverse en DIC : Disponibilité d’abord, puis Intégrité, puis Confidentialité. Vous ne pouvez pas arrêter un réacteur en fonctionnement pour un cycle de correctifs le mardi.
La distinction essentielle réside dans la conséquence. Une violation IT vous coûte des données et de l’argent. Une violation OT peut coûter des vies. C’est pourquoi comprendre comment ces domaines diffèrent, et comment ils sont désormais connectés, est crucial pour tout défenseur opérant dans des environnements cyber-physiques modernes. Le point de départ de cette compréhension est la convergence : le processus qui a rendu ces deux domaines indissociables.
Qu’est-ce que la convergence IT/OT ?
La convergence IT/OT est la disparition de la séparation historique entre les systèmes IT d’entreprise et les systèmes OT industriels. Pendant la majeure partie du XXe siècle, les environnements OT fonctionnaient en isolation, physiquement déconnectés des réseaux d’entreprise, utilisant des protocoles propriétaires inaccessibles aux outils d’entreprise, et gérés par des ingénieurs d’usine plutôt que par des équipes de sécurité IT. Cette isolation était intentionnelle. Elle était aussi, pendant longtemps, efficace.
Trois forces ont fait s’effondrer ce modèle :
- Internet industriel des objets (IIoT) : Les capteurs, contrôleurs et dispositifs de terrain ont été connectés aux réseaux d’entreprise et aux plateformes cloud pour permettre la surveillance à distance et l’efficacité opérationnelle, mettant en ligne les actifs OT pour la première fois.
- Industrie 4.0 : Les principes de fabrication modernes ont exigé une intégration des données en temps réel entre les systèmes de production et les outils de business intelligence, créant des chemins de données directs à travers ce qui était auparavant une frontière étanche.
- Expansion de l’accès à distance : La connectivité VPN d’entreprise et cloud s’est étendue aux environnements industriels qui nécessitaient auparavant une présence physique, souvent sous l’impulsion des exigences de support fournisseur et des changements liés à la pandémie.
Chacune de ces forces a indépendamment accru l’exposition OT. Ensemble, elles ont démantelé l’hypothèse d’isolation sur laquelle la sécurité industrielle reposait depuis des décennies.
Le résultat est que l’isolation physique a en grande partie disparu. Les postes d’ingénierie se connectent aux domaines d’entreprise, les systèmes SCADA envoient des télémétries vers des plateformes d’analytique cloud, et les accès distants fournisseurs franchissent quotidiennement la frontière IT/OT. L’analyse de la convergence IT/OT de la CISA documente comment cette expansion de la connectivité a rendu les environnements OT directement accessibles depuis le réseau d’entreprise, et par extension, depuis Internet.
Pour les équipes de sécurité, la convergence signifie que votre SOC doit désormais assurer la visibilité sur des environnements utilisant Modbus, DNP3 et des protocoles industriels que votre SIEM n’a jamais analysés, en gérant des dispositifs en service depuis 20 ans sans correctif de sécurité. Le défi n’est pas seulement technique. Il exige une gouvernance partagée, une réponse aux incidents conjointe et une stratégie de visibilité unifiée à travers deux domaines aux priorités opérationnelles différentes. Pour comprendre les implications de la convergence sur la sécurité, il est utile de savoir d’abord de quoi chaque domaine est réellement constitué.
Composants clés de la sécurité IT et OT
Les deux domaines protègent des actifs fondamentalement différents, fonctionnent sur des protocoles différents et reposent sur des hypothèses opérationnelles distinctes. Comprendre ces actifs, ce qu’ils sont et pourquoi ils ont été conçus ainsi, permet de rendre intelligibles les différences de sécurité entre IT et OT.
Composants de la sécurité IT
Votre pile de sécurité IT protège les systèmes d’information d’entreprise à plusieurs niveaux :
- Terminaux : Serveurs, postes de travail, ordinateurs portables et appareils mobiles
- Réseaux d’entreprise : LAN, WAN et infrastructures réseau supportant les opérations métier
- Plateformes cloud : IaaS, SaaS et contrôles au niveau applicatif
- Gestion des identités et des accès : Authentification, autorisation et gestion des privilèges
Ces couches transportent la majorité de vos données métier et de l’activité utilisateur. Les plateformes d’opérations de sécurité les relient via SIEM, EDR/XDR et des workflows de réponse aux incidents.
Composants de la sécurité OT
La sécurité OT protège les systèmes de contrôle industriel et leur infrastructure de support. Le guide NIST sur la sécurité OT catégorise les composants clés :
- Systèmes SCADA : Supervision et contrôle sur des infrastructures distribuées telles que réseaux électriques, pipelines et systèmes d’eau
- Systèmes de contrôle distribués : Éléments de contrôle répartis dans les installations de production, courants dans la fabrication en processus continu
- Automates programmables industriels : Contrôleurs dédiés pour des processus discrets comme les chaînes d’assemblage
- Interfaces homme-machine : Interfaces opérateur pour la surveillance et le contrôle des processus industriels
Les systèmes instrumentés de sécurité ajoutent une couche dédiée pour les arrêts de protection lorsque les variables de processus dépassent les limites de sécurité. Les protocoles industriels tels que Modbus, DNP3, PROFINET, EtherNet/IP et OPC UA sont conçus pour la fiabilité et la performance temps réel, pas pour la sécurité.
Ces composants fonctionnent dans l’architecture de référence d’entreprise Purdue, le modèle standard du secteur organisant les environnements OT en niveaux hiérarchiques, des dispositifs de terrain aux systèmes externes. Le niveau 3.5, la DMZ à la frontière IT/OT, concentre la majorité des contrôles de sécurité. Le guide NIST sur la segmentation réseau recommande d’empêcher toute communication directe des dispositifs de niveau 4 vers les niveaux opérationnels inférieurs. Ces différences architecturales ne sont pas seulement structurelles ; elles déterminent comment les équipes de sécurité peuvent réagir de manière réaliste aux menaces dans chaque environnement.
Opérations de sécurité IT vs OT
La même menace, une compromission d’identifiants, un appareil malveillant ou une connexion réseau inhabituelle, exige une réponse très différente selon qu’elle apparaît dans un environnement IT ou OT. Les contraintes opérationnelles de chaque domaine influencent chaque décision qu’une équipe de sécurité peut prendre.
Opérations de sécurité IT
La sécurité IT fonctionne sur un cycle de réponse rapide. Votre SOC collecte la télémétrie des terminaux, équipements réseau, charges de travail cloud et systèmes d’identité dans une plateforme centralisée. L’IA comportementale et les moteurs de corrélation analysent ces données en temps réel, signalant les anomalies par rapport aux schémas d’attaque connus et aux comportements de référence. Lorsqu’une menace est détectée, vous pouvez isoler le terminal, tuer le processus, forcer une réinitialisation de mot de passe ou déployer un correctif d’urgence en quelques secondes car l’impact métier est limité.
Opérations de sécurité OT
La sécurité OT fonctionne sous des contraintes différentes. Vous ne pouvez pas installer d’agents sur la plupart des API ou RTU car ils n’ont pas les ressources nécessaires. Vous ne pouvez pas effectuer de scans de vulnérabilité actifs car, comme le guide NIST sur la sécurité OT le précise, « l’utilisation indiscriminée des pratiques de sécurité IT en OT peut provoquer des perturbations de disponibilité et de synchronisation ». Un scan réseau qui serait routinier sur votre LAN d’entreprise peut faire planter une API à ressources limitées ou la forcer à passer en mode sécurisé.
La surveillance OT repose sur l’analyse passive du réseau, l’inspection approfondie des paquets des protocoles industriels et l’identification d’anomalies comportementales au niveau réseau. Vous établissez une base de référence des communications normales entre contrôleurs, capteurs et IHM, puis signalez les écarts. Le modèle de réponse privilégie la stabilité des processus : vous n’isolez pas un réacteur chimique en fonctionnement comme vous mettriez en quarantaine un ordinateur portable. Les décisions de réponse nécessitent des procédures et des droits décisionnels différents, et doivent prendre en compte la sécurité des processus en plus du risque cyber. Ces différences opérationnelles sont l’expression concrète d’un ensemble plus profond de divergences architecturales, de cycle de vie et de modèles de priorité qui séparent les deux domaines.
Différences clés entre la sécurité IT et OT
Sept dimensions critiques distinguent ces domaines :
| Dimension | Sécurité IT | Sécurité OT |
| Modèle de priorité | CID (Confidentialité d’abord) | DIC (Disponibilité d’abord) |
| Cycle de vie des systèmes | Cycles de renouvellement courts | Systèmes longue durée, souvent non corrigés |
| Gestion des correctifs | Continue, souvent automatisée | Fenêtres de maintenance planifiées uniquement |
| Protocoles | Standards (HTTP, SMB, TLS) | Industriels (Modbus, DNP3, PROFINET) |
| Support des agents | Déploiement complet d’agents sur les terminaux | Surveillance sans agent pour la plupart des dispositifs |
| Réponse aux incidents | Isolement et confinement agressifs | Stabilité et sécurité des processus en priorité |
| Conséquence d’une défaillance | Perte de données, interruption métier | Dommages physiques, impact environnemental, perte de vies humaines |
Deux de ces dimensions, le modèle de priorité et l’écart de cycle de vie, ont le plus d’impact opérationnel. Elles sont la cause principale de la plupart des frictions rencontrées par les équipes de sécurité lorsqu’elles tentent d’appliquer des outils et processus d’entreprise aux environnements industriels.
L’inversion des priorités
Pour les environnements OT, le rapport CISA sur la convergence IT/OT met l’accent sur la disponibilité, ainsi que sur le contrôle des processus sûr et fiable. L’authentification multifacteur qui retarde l’accès d’urgence, le chiffrement qui ajoute de la latence, ou les contrôles de sécurité nécessitant des redémarrages sont tous en conflit direct avec l’exigence OT de disponibilité immédiate.
L’écart de cycle de vie
Les systèmes OT restent généralement en service bien plus longtemps que les actifs IT d’entreprise et ne peuvent souvent pas être corrigés selon les calendriers IT classiques. Cela crée une exposition persistante gérée par la segmentation, la surveillance, des contrôles compensatoires et une revue d’ingénierie plutôt que par le simple correctif de routine.
Ces différences expliquent pourquoi appliquer directement les contrôles IT aux environnements OT crée du risque, et pourquoi les cadres de conformité qui régissent chaque domaine sont également fondamentalement différents.
Conformité et exigences réglementaires en sécurité OT
La sécurité OT n’est pas seulement une question de bonnes pratiques : pour de nombreux secteurs, c’est une obligation légale. Le paysage réglementaire s’est considérablement élargi depuis que des incidents très médiatisés ont démontré les implications de sécurité nationale des cyberattaques industrielles.
- NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) : Obligatoire pour les opérateurs du réseau électrique nord-américain. Les normes NERC CIP imposent aux services publics de mettre en œuvre des contrôles spécifiques pour l’accès électronique, la sécurité physique, la déclaration d’incidents et la gestion des risques liés à la chaîne d’approvisionnement. Le non-respect entraîne des amendes pouvant aller jusqu’à 1 million de dollars par infraction et par jour.
- Directives TSA pour les pipelines et chemins de fer : Suite à l’attaque contre Colonial Pipeline, la TSA a publié des directives de cybersécurité désormais dans leur troisième version. Elles imposent la déclaration d’incidents à la CISA, la désignation d’un coordinateur cybersécurité, et des exigences spécifiques de contrôle d’accès et de segmentation réseau pour les opérateurs de pipelines et de chemins de fer.
- NIST SP 800-82 : La principale référence technique du gouvernement fédéral pour la sécurité ICS et OT. Non légalement obligatoire pour toutes les organisations privées, mais c’est la norme à laquelle la CISA se réfère dans ses propres recommandations et elle est effectivement requise pour les organisations cherchant des contrats fédéraux ou opérant dans des secteurs d’infrastructures critiques réglementés.
- Directive NIS2 (UE) : La directive Network and Information Security 2 a étendu les exigences obligatoires de cybersécurité aux opérateurs de l’UE en octobre 2024, couvrant l’énergie, l’eau, la fabrication et le transport. Les organisations doivent mettre en œuvre des mesures de gestion des risques, signaler les incidents majeurs sous 24 heures et assurer la sécurité de la chaîne d’approvisionnement.
La plupart des organisations réglementées utilisent IEC 62443 comme norme OT de base et cartographient ses contrôles vers les exigences NERC CIP, NIST 800-82 ou NIS2 selon leur secteur et leur géographie. Les cadres de conformité indiquent ce qu’il faut atteindre ; comprendre pourquoi vos outils IT existants ne peuvent pas l’atteindre en OT est tout aussi important.
Pourquoi les contrôles IT traditionnels échouent dans les environnements OT
Les outils de sécurité IT standards ont été conçus pour les environnements d’entreprise. En OT, chaque catégorie d’outil échoue d’une manière spécifique et documentée.
- Agents sur les terminaux : Les agents IT peuvent interférer avec les systèmes d’ingénierie, identifier à tort des comportements de contrôle légitimes comme malveillants et créer de l’instabilité dans des systèmes jamais conçus pour héberger des logiciels de sécurité modernes.
- Cécité protocolaire : Les outils IT inspectent les protocoles standards comme HTTP, HTTPS et SMB. Ils ne peuvent pas décoder Modbus, DNP3, PROFINET ou les protocoles industriels propriétaires. Cela signifie qu’ils ne peuvent pas identifier les changements d’ingénierie non autorisés, détecter des commandes OT malveillantes ou distinguer une modification légitime d’un point de consigne d’une manipulation malveillante d’un processus chimique.
- Risques de quarantaine : Les procédures d’entreprise prévoient l’isolement immédiat des systèmes compromis. En OT, isoler un contrôleur gérant une turbine, une vanne de pipeline ou un lot chimique peut déclencher des défaillances physiques en cascade. La décision de réponse doit prendre en compte la sécurité des processus.
- Incompatibilité des correctifs : Le guide CISA sur les correctifs OT explique que la gestion des correctifs OT ne suit pas les processus, calendriers ou méthodologies IT traditionnels. Elle nécessite une analyse informée par l’ingénierie et une coordination étroite avec les équipes d’exploitation pour prioriser la sécurité et la continuité.
Comprendre où les outils IT sont insuffisants est la base pour construire un modèle de sécurité efficace dans les deux domaines. Mais les limites des outils ne sont qu’une partie du problème. Les environnements convergés introduisent aussi des défis structurels qu’aucun produit ne résout à lui seul.
Défis de visibilité et de surface d’attaque
Deux problèmes structurels rendent les environnements IT/OT convergés systématiquement plus difficiles à défendre que chaque domaine isolé : vous ne pouvez souvent pas voir ce que vous essayez de protéger, et le périmètre à défendre ne cesse de s’étendre.
Le déficit de visibilité
De nombreuses organisations manquent encore de visibilité complète sur leur parc OT, en particulier au niveau des contrôleurs et des dispositifs de terrain où le risque opérationnel est le plus élevé. Cela complique la détection des changements non autorisés, des dérives d’actifs ou des mouvements d’attaquants avant que des conséquences physiques n’apparaissent.
L’expansion de la surface d’attaque
À mesure que les organisations industrielles connectent les usines aux services cloud, plateformes d’accès à distance, fournisseurs et systèmes d’entreprise, la surface d’attaque s’étend bien au-delà du périmètre traditionnel de l’usine. L’hypothèse d’isolation OT n’est plus valable dans les environnements modernes. Chaque nouveau point de connectivité est une voie d’entrée potentielle de l’IT vers l’OT, et les incidents qui ont façonné le paysage réglementaire et sécuritaire actuel prouvent que les attaquants ont appris à exploiter précisément cela.
Exemples réels d’attaques IT/OT
Les risques théoriques de la convergence IT/OT se sont matérialisés dans des incidents documentés dans l’énergie, l’industrie et l’eau. Chaque cas ci-dessous a commencé par un vecteur d’attaque IT classique et a dégénéré en perturbation opérationnelle ou danger physique, démontrant que la frontière IT/OT n’est pas un contrôle de sécurité : c’est une cible.
- Colonial Pipeline, 2021 : Colonial Pipeline a révélé qu’une attaque par ransomware a conduit l’entreprise à arrêter proactivement les opérations du pipeline. L’arrêt a affecté la distribution de carburant sur la côte Est des États-Unis pendant plusieurs jours, et l’entreprise a déclaré avoir payé environ 4,4 millions de dollars de rançon.
- Triton dans une usine pétrochimique saoudienne, 2017 : Le département de la Justice américain a incriminé un chercheur du gouvernement russe en lien avec le malware Triton, qui visait le système instrumenté de sécurité d’une usine pétrochimique. Le DOJ a indiqué que le malware était conçu pour provoquer des arrêts d’urgence et créait un risque de dommages physiques en interférant avec la logique SIS.
- Usine d’eau d’Oldsmar, 2021 : En Floride, un intrus a accédé à la station de traitement d’eau de la ville d’Oldsmar et a tenté d’augmenter le niveau d’hydroxyde de sodium de 100 parties par million à 11 100 parties par million, selon les détails officiels partagés par les autorités locales et fédérales.
Ces incidents présentent un schéma constant : la compromission commence par un accès IT classique, mais l’impact devient opérationnel, physique ou lié à la sécurité. Ils partagent aussi des lacunes exploitées : visibilité insuffisante, segmentation inadéquate, absence de réponse aux incidents spécifique OT et équipes IT et OT déconnectées. Les pratiques suivantes répondent directement à chacune de ces lacunes.
Bonnes pratiques de sécurité IT et OT
Sécuriser les environnements IT et OT ensemble nécessite plus que de meilleurs outils. Cela exige une stratégie délibérée qui respecte les contraintes opérationnelles de l’OT tout en appliquant la rigueur de surveillance et de réponse de la sécurité d’entreprise. Ces six pratiques constituent la base de cette stratégie.
1. Adopter des cadres de gouvernance intégrés
Utilisez IEC 62443 comme norme de sécurité OT de référence et cartographiez-la avec NIST CSF 2.0 et ISO 27001, en vous appuyant sur le rapport CISA sur la convergence IT/OT pour aligner la gouvernance sur les environnements d’entreprise et industriels.
2. Appliquer la segmentation réseau à la frontière IT/OT
Mettez en œuvre le modèle de zones et conduits ISA/IEC 62443 pour limiter les mouvements latéraux de l’IT vers les environnements de production. Suivez le guide NIST sur la segmentation réseau pour appliquer des règles de pare-feu empêchant les dispositifs de niveau 4 de communiquer directement avec les dispositifs opérationnels. Appliquez les principes Zero Trust au niveau 3.5 Purdue DMZ, en considérant le réseau IT comme une zone non fiable par rapport à l’OT.
3. Construire une visibilité complète des actifs OT
Vous ne pouvez pas protéger ce que vous ne voyez pas. Inventoriez chaque API, serveur SCADA, IHM, passerelle et appareil IoT. Utilisez la découverte sans agent pour les dispositifs OT à ressources limitées, complétée par une couverture avec agent sur les postes d’ingénierie et serveurs OT qui le permettent. Un meilleur contexte des actifs renforce la sécurité ICS et améliore les décisions de segmentation réseau.
4. Déployer l’analyse comportementale des protocoles industriels
Allez au-delà des outils basés sur les signatures. Une surveillance OT efficace nécessite une analyse approfondie des protocoles industriels comme Modbus, DNP3 et OPC UA pour détecter des schémas de commandes inhabituels, des interactions non autorisées entre dispositifs et des tentatives de manipulation de protocole. Intégrez les données de surveillance OT dans le workflow de votre SOC plutôt que de les traiter isolément.
5. Créer des plans de réponse aux incidents spécifiques OT
Votre plan de réponse aux incidents IT causera des dommages s’il est appliqué tel quel à l’OT. Élaborez des plans distincts qui privilégient la sécurité et la continuité de la production, et incluez des exercices de simulation avec les fournisseurs et prestataires OT comme le recommande le NIST IR 8576. Une planification solide de la réponse aux incidents est un pilier de la sécurité ICS.
6. Unifier les équipes de sécurité IT et OT
Cessez de gérer la sécurité IT et OT comme des îlots séparés. Des équipes cyber intégrées combinant l’analyse des menaces IT et la connaissance des processus OT, avec des workflows partagés et une réponse coordonnée aux incidents, sont nettement plus résilientes sous pression.
La mise en œuvre de ces bonnes pratiques à grande échelle nécessite une plateforme conçue pour les environnements convergés.
Une cybersécurité alimentée par l'IA
Améliorez votre posture de sécurité grâce à la détection en temps réel, à une réponse à la vitesse de la machine et à une visibilité totale de l'ensemble de votre environnement numérique.
Obtenir une démonstrationPoints clés à retenir
La sécurité IT et OT répond à des priorités différentes : confidentialité des données contre sécurité opérationnelle. La convergence IT/OT a éliminé l’isolation physique qui protégeait autrefois les environnements industriels, créant des surfaces d’attaque partagées qui exigent une gouvernance unifiée. Les contrôles IT standards échouent en OT car ils ne peuvent pas analyser les protocoles industriels, supporter la durée de vie des dispositifs ou respecter l’impératif de continuité des processus physiques.
Sécuriser les environnements convergés exige la conformité à des exigences sectorielles comme NERC CIP et NIS2, une gouvernance intégrée sous ISA/IEC 62443, une segmentation réseau stricte à la frontière IT/OT, une visibilité OT sans agent, l’analyse comportementale des anomalies et des plans de réponse aux incidents spécifiques OT.
FAQ
La sécurité informatique protège les systèmes d'information : serveurs, postes de travail, plateformes cloud et réseaux d'entreprise où résident les données métier. La sécurité OT protège les systèmes de contrôle industriel qui interagissent avec les processus physiques, y compris les systèmes SCADA, les automates programmables industriels (API) et les interfaces homme-machine (IHM) dans des environnements tels que les réseaux électriques, les stations de traitement de l'eau et les usines de fabrication.
Les deux domaines suivent des modèles de priorités différents : l'informatique privilégie la confidentialité, tandis que l'OT accorde la priorité à la disponibilité. Sécuriser les deux ensemble devient de plus en plus nécessaire à mesure que ces environnements convergent.
La plupart des dispositifs OT, tels que les PLC et les RTU, fonctionnent sous des systèmes d'exploitation temps réel avec des ressources limitées en CPU, mémoire et stockage. Ils ne peuvent souvent pas prendre en charge des agents de sécurité modernes sans risquer une latence ou une instabilité. C'est pourquoi les équipes OT s'appuient plutôt sur la surveillance passive, l'empreinte réseau et une couverture sélective sur les systèmes de support.
Cette approche préserve la stabilité des processus tout en améliorant la sécurité des ICS et la visibilité globale.
Le modèle Purdue organise les environnements industriels en couches, des dispositifs de terrain jusqu’aux systèmes d’entreprise et externes. Sa valeur pratique réside dans la segmentation. Vous l’utilisez pour définir des frontières de confiance, en particulier au niveau de la DMZ 3.5 entre l’IT et l’OT.
Cette structure favorise la segmentation du réseau, réduit le risque de mouvement latéral et vous offre un cadre plus clair pour protéger la sécurité SCADA dans des environnements connectés.
L'ISO 27001 fournit un cadre général pour la gestion de la sécurité de l'information, mais ne se concentre pas sur la sécurité des installations industrielles ou la fiabilité des systèmes de contrôle. ISA/IEC 62443 est spécifiquement conçue pour la cybersécurité industrielle, couvrant l'architecture des systèmes, la sécurité des composants et les pratiques de cycle de vie propres aux environnements OT.
Il est possible de faire une correspondance entre les deux normes, mais 62443 répond à des exigences de sécurité ICS que l'ISO 27001 n'a jamais été conçue pour couvrir.
Les principaux risques sont l’augmentation de la connectivité, la visibilité limitée sur les contrôleurs et les dispositifs de terrain, ainsi qu’une coordination insuffisante entre les équipes IT et OT. Un incident qui semble mineur dans les outils d’entreprise peut avoir des conséquences opérationnelles majeures dans les environnements OT.
Pour atténuer ces risques, il est nécessaire de partager le contexte entre les deux équipes, de mettre en place une segmentation réseau robuste à la frontière IT/OT, et d’utiliser des plans de réponse aux incidents spécifiques à l’OT afin d’éviter qu’un compromis de routine ne se transforme en perturbation physique.
Oui, mais il faut l’appliquer avec précaution. Zero trust fonctionne le mieux aux points de frontière tels que les chemins d’accès à distance et la DMZ IT/OT, où l’authentification et l’autorisation peuvent être appliquées sans perturber le trafic de contrôle.
À l’intérieur des réseaux OT, vous adaptez généralement le modèle via la segmentation, les contrôles de politiques et la surveillance. Cela permet d’améliorer la sécurité SCADA sans ajouter de latence dangereuse aux processus critiques.
