Sécurité OT NIS2 : cartographie ISO 27001 et IEC 62443

À 02 h 17 un lundi, un opérateur de traitement de l’eau reçoit une alarme d’un système de dosage. L’alimentation chimique reste dans les limites de sûreté, mais un PLC signale des commandes irrégulières, le poste d’ingénierie affiche des échecs de connexion depuis un compte VPN fournisseur, et l’analyste SOC de permanence pose une question à laquelle personne ne souhaite répondre sous pression.

S’agit-il d’un incident informatique, d’un incident OT, d’un événement de sûreté ou d’un incident important à notifier au titre de NIS2 ?

L’usine dispose de pare-feu. Elle dispose d’une documentation ISO. Elle dispose d’un tableur fournisseurs. Elle a même un plan de réponse aux incidents. Mais ce plan a été rédigé pour des compromissions de messagerie et des interruptions de services cloud, pas pour un contrôleur hérité qui ne peut pas être corrigé en production, un fournisseur qui a besoin d’un accès à distance pour rétablir le service, et une autorité de régulation qui attend des éléments de preuve dans les délais de notification NIS2.

Le même problème se pose dans les conseils d’administration. Un RSSI chez un fournisseur régional d’énergie peut disposer d’un système de management de la sécurité de l’information (SMSI) certifié ISO/IEC 27001:2022 pour l’informatique d’entreprise, tandis que le parc de technologies opérationnelles reste un enchevêtrement de PLC, de RTU, d’IHM, de serveurs d’historisation, de postes d’ingénierie, de commutateurs industriels et de canaux d’accès fournisseur. La question du directeur général est simple : « Sommes-nous couverts ? Pouvez-vous le prouver ? »

Pour de nombreuses entités essentielles et importantes, la réponse honnête est inconfortable. Elles sont partiellement couvertes. Elles peuvent partiellement le prouver. Mais la sécurité OT NIS2 exige davantage qu’une conformité informatique générique.

Elle exige un modèle opérationnel unifié qui relie la gouvernance ISO/IEC 27001:2022, le langage de contrôle ISO/IEC 27002:2022, les pratiques d’ingénierie industrielle IEC 62443, les mesures de gestion des risques de cybersécurité de NIS2 Article 21 et les éléments de preuve de notification des incidents de NIS2 Article 23.

C’est le pont que construit ce guide.

Pourquoi la sécurité OT NIS2 diffère de la conformité informatique ordinaire

NIS2 s’applique à de nombreuses entités publiques et privées qui fournissent des services entrant dans son champ d’application dans l’UE, notamment des entités essentielles et importantes dans des secteurs tels que l’énergie, les transports, la banque, les infrastructures des marchés financiers, la santé, l’eau potable, les eaux usées, les infrastructures numériques, la gestion des services TIC, l’administration publique, l’espace, les services postaux, la gestion des déchets, la fabrication, la chimie, l’alimentation, les fournisseurs numériques et la recherche.

La directive exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques cyber, prévenir ou réduire au minimum l’impact des incidents et protéger la continuité des services. Article 21 prévoit une approche tous risques couvrant l’analyse des risques, les politiques de sécurité, la gestion des incidents, la continuité d’activité, la gestion de crise, la sécurité de la chaîne d’approvisionnement, l’acquisition et la maintenance sécurisées, la gestion et la divulgation des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs, l’authentification multifacteur ou l’authentification continue, les communications sécurisées et, le cas échéant, les communications d’urgence.

Ces exigences semblent familières à une équipe ISO/IEC 27001:2022. En OT, chacune d’elles se comporte différemment.

Une vulnérabilité dans un serveur web peut souvent être corrigée en quelques jours. Une vulnérabilité dans un contrôleur de turbine peut nécessiter une validation fournisseur, une fenêtre de maintenance, une revue de sûreté et des procédures d’exploitation de secours. Un ordinateur portable peut être reconstruit. Une IHM de production peut dépendre d’un système d’exploitation hérité parce que l’application industrielle n’a pas été certifiée pour une plateforme plus récente. Une procédure SOC peut indiquer « isoler l’hôte », tandis que l’ingénieur OT répond : « pas tant que nous ne savons pas si l’isolement affecte le contrôle de pression ».

La différence n’est pas seulement technique. L’IT priorise généralement la confidentialité, l’intégrité et la disponibilité. L’OT priorise la disponibilité, l’intégrité des procédés et la sûreté. Un contrôle de sécurité qui introduit de la latence, exige un redémarrage ou interrompt un processus physique peut être inacceptable sans approbation d’ingénierie.

NIS2 n’exonère pas l’OT de la gestion des risques de cybersécurité. Elle attend de l’organisation qu’elle prouve que les contrôles sont adaptés au risque et proportionnés à la réalité opérationnelle.

La pile de contrôles : NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 et IEC 62443

Un programme défendable de sécurité OT NIS2 commence par une pile de contrôles en couches.

ISO/IEC 27001:2022 fournit le système de management. Elle exige que l’organisation définisse le contexte, les parties intéressées, les obligations réglementaires, le domaine d’application du SMSI, les interfaces et les dépendances. Elle exige également la responsabilité de la direction, une politique de sécurité de l’information, l’appréciation des risques, le traitement des risques, une Déclaration d’applicabilité, des informations documentées, l’audit interne, la revue de direction et l’amélioration continue.

ISO/IEC 27002:2022 fournit le vocabulaire des contrôles. Pour l’OT, les contrôles les plus importants incluent souvent la sécurité des fournisseurs, la gestion des risques liés à la chaîne d’approvisionnement TIC, la planification de la réponse aux incidents, la préparation des TIC à la continuité d’activité, les exigences légales et contractuelles, la gestion des actifs, le contrôle d’accès, la gestion des vulnérabilités, les sauvegardes, la journalisation, la surveillance, la sécurité réseau et la séparation des réseaux.

IEC 62443 fournit le modèle d’ingénierie de la sécurité industrielle. Elle aide à traduire les exigences du système de management en pratiques OT telles que les zones, les conduits, les niveaux de sécurité, les responsabilités du propriétaire de l’actif, les responsabilités de l’intégrateur système, les attentes envers les fournisseurs de produits, les restrictions d’accès à distance, le principe de fonctionnalité minimale, la gestion des comptes, le durcissement et les contrôles du cycle de vie.

Clarysec utilise cette pile parce qu’elle évite deux écueils fréquents. Premièrement, elle empêche la mise en œuvre ISO de devenir trop générique pour l’OT. Deuxièmement, elle évite que les travaux d’ingénierie IEC 62443 soient déconnectés de la responsabilité du conseil d’administration, des obligations de notification NIS2 et des éléments de preuve d’audit.

La Politique de sécurité IoT / OT de Clarysec exprime directement ce pont :

Garantir que tous les déploiements sont alignés sur les contrôles ISO/IEC 27001 et les lignes directrices sectorielles applicables (par exemple IEC 62443, ISO 27019, NIST SP 800-82).

Cette phrase est importante. La politique n’est pas seulement une liste de contrôle de durcissement des équipements. Elle relie la gouvernance ISO, les lignes directrices sectorielles OT et la sécurité opérationnelle.

Commencer par le périmètre : quel service OT doit être protégé ?

Avant de cartographier les contrôles, définissez le service OT en langage métier et réglementaire.

Un responsable d’usine peut dire : « Nous exploitons la ligne d’emballage. » Une appréciation NIS2 devrait dire : « Ce processus de production soutient un service essentiel ou important et dépend de PLC, d’IHM, de postes d’ingénierie, de serveurs d’historisation, de commutateurs industriels, d’un accès fournisseur à distance, d’un prestataire de maintenance, d’un flux d’analyse cloud et d’un service d’identité d’entreprise. »

Les clauses 4.1 à 4.4 d’ISO/IEC 27001:2022 sont utiles parce qu’elles obligent l’organisation à identifier les enjeux internes et externes, les parties intéressées, les exigences légales et contractuelles, les limites du SMSI, les interfaces et les dépendances. Pour la sécurité OT NIS2, cela signifie cartographier non seulement le réseau du siège, mais aussi les systèmes industriels et les dépendances de service qui affectent la continuité, la sûreté et la fourniture réglementée.

NIST CSF 2.0 renforce la même logique. Sa fonction GOVERN impose de comprendre la mission, les parties prenantes, les dépendances, les obligations légales et réglementaires, les services critiques et les services dont dépend l’organisation. Les profils organisationnels fournissent une méthode pratique pour délimiter l’état actuel, définir un état cible, analyser les écarts et produire un plan d’action priorisé.

Pour un environnement OT, Clarysec commence généralement par cinq questions :

1. Quel service réglementé ou critique cet environnement OT soutient-il ?
2. Quels actifs OT, réseaux, flux de données et tiers sont nécessaires à ce service ?
3. Quelles contraintes de sûreté, de disponibilité et d’exploitation affectent les contrôles de sécurité ?
4. Quelles obligations légales, contractuelles et sectorielles s’appliquent, y compris NIS2, GDPR, DORA le cas échéant, les contrats clients et les règles nationales ?
5. Quelles parties de l’environnement relèvent du SMSI et quelles dépendances externes nécessitent des contrôles fournisseurs ?

De nombreux programmes NIS2 échouent à ce stade. Ils définissent le périmètre autour de l’informatique d’entreprise parce qu’elle est plus facile à inventorier. Les auditeurs et les autorités de régulation ne seront pas convaincus si la dépendance la plus critique du service n’apparaît que comme une ligne vague intitulée « réseau d’usine ».

Une cartographie pratique des contrôles OT NIS2

Le tableau ci-dessous montre comment transformer les thèmes de NIS2 Article 21 en éléments de preuve ISO/IEC 27001:2022, ISO/IEC 27002:2022 et IEC 62443. Il ne remplace pas une appréciation formelle des risques, mais fournit aux RSSI, responsables OT et équipes de conformité un point de départ opérationnel.

Cette cartographie est volontairement centrée sur les éléments de preuve. Au titre de NIS2, dire « nous avons une segmentation » ne suffit pas. Vous devez montrer pourquoi la segmentation est appropriée, comment elle est mise en œuvre, comment les dérogations sont approuvées et comment la conception réduit l’impact sur le service réglementé.

Segmentation : le premier contrôle OT que les auditeurs testeront

Si l’incident de 02 h 17 impliquait un attaquant se déplaçant d’un ordinateur portable bureautique vers un poste d’ingénierie, la première question d’audit serait évidente : pourquoi ce chemin pouvait-il exister ?

La Politique de sécurité IoT / OT est explicite :

Les systèmes OT doivent fonctionner dans des réseaux dédiés isolés de l’IT d’entreprise et des systèmes exposés à Internet.

Pour les environnements de plus petite taille, la Politique de sécurité Internet des objets (IoT) / technologies opérationnelles (OT) - PME fournit un référentiel pratique :

Tous les appareils Internet des objets (IoT) et technologies opérationnelles (OT) doivent être placés sur un réseau Wi‑Fi ou VLAN distinct

Pour un opérateur d’infrastructure critique mature, la segmentation doit être conçue autour de zones et de conduits OT. Les utilisateurs d’entreprise ne doivent pas accéder directement aux réseaux PLC. Les connexions fournisseurs doivent aboutir dans des zones d’accès contrôlées. La réplication des serveurs d’historisation doit utiliser des chemins approuvés. Les systèmes de sûreté doivent être isolés selon les risques et les exigences d’ingénierie. Les réseaux OT sans fil doivent être justifiés, durcis et surveillés.

Zenith Blueprint: An Auditor’s 30-Step Roadmap, dans la phase Controls in Action, Step 20, explique le principe sous-jacent à la sécurité réseau ISO/IEC 27002:2022 :

Les systèmes de contrôle industriel doivent être isolés du trafic bureautique.

Il rappelle également que la sécurité réseau exige une architecture sécurisée, une segmentation, un contrôle d’accès, le chiffrement des données en transit, une surveillance et une défense en profondeur.

Dans Zenith Controls: The Cross-Compliance Guide, la mesure ISO/IEC 27002:2022 8.22, Séparation des réseaux, est traitée comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur le concept de cybersécurité Protect, avec la sécurité des systèmes et des réseaux comme capacité opérationnelle et Protection comme domaine de sécurité.

Cette classification est utile pour les éléments de preuve NIS2, car la segmentation n’est pas un schéma décoratif. C’est un contrôle préventif conçu pour réduire le périmètre d’impact et préserver la continuité des services essentiels.

Gestion des vulnérabilités lorsque les systèmes OT ne peuvent pas simplement être corrigés

NIS2 exige l’acquisition, le développement et la maintenance sécurisés des réseaux et systèmes d’information, y compris la gestion et la divulgation des vulnérabilités. En IT, la gestion des vulnérabilités signifie souvent détecter, prioriser, corriger et vérifier. L’OT ajoute des contraintes.

Une IHM critique peut n’être corrigeable que pendant un arrêt planifié. Une mise à jour de micrologiciel PLC peut nécessiter l’intervention du fournisseur. Un système certifié pour la sûreté peut perdre sa certification s’il est modifié incorrectement. Certains équipements hérités peuvent ne plus bénéficier d’aucun support fournisseur.

Zenith Blueprint, dans la phase Controls in Action, Step 19, fournit la bonne logique d’audit pour les vulnérabilités techniques :

Pour les systèmes qui ne peuvent pas être corrigés immédiatement, par exemple en raison de logiciels hérités ou de restrictions d’indisponibilité, mettez en œuvre des contrôles compensatoires. Cela peut inclure l’isolement du système derrière un pare-feu, la limitation des accès ou l’augmentation de la surveillance. Dans tous les cas, consignez et acceptez formellement le risque résiduel, afin de montrer que le problème n’est pas oublié.

Le référentiel de la politique PME est tout aussi pratique :

L’inventaire doit être revu trimestriellement afin d’identifier les appareils obsolètes, non pris en charge ou non corrigés

Dans Zenith Controls, la mesure ISO/IEC 27002:2022 8.8, Gestion des vulnérabilités techniques, est cartographiée comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur Identify et Protect, avec la gestion des menaces et des vulnérabilités comme capacité opérationnelle dans les domaines Gouvernance, Écosystème, Protection et Défense.

Un dossier robuste de vulnérabilité OT doit inclure :

• Identifiant de l’actif, propriétaire, zone et criticité
• Source de la vulnérabilité, telle qu’un avis fournisseur, un scanner, une notification d’intégrateur ou du renseignement sur les menaces
• Contraintes de sûreté et de disponibilité
• Faisabilité du correctif et fenêtre de maintenance planifiée
• Mesures compensatoires, telles que l’isolement, les listes de contrôle d’accès, les services désactivés ou une surveillance accrue
• Approbation du propriétaire du risque et acceptation du risque résiduel
• Éléments de preuve de vérification après remédiation ou mise en œuvre de la mesure compensatoire

Cela transforme « nous ne pouvons pas corriger » d’une excuse en traitement des risques auditable.

Accès fournisseur à distance : le point de tension NIS2 et IEC 62443

La plupart des incidents OT ont quelque part une dimension liée aux tiers. Un compte fournisseur. Un ordinateur portable d’intégrateur. Un outil de maintenance à distance. Un identifiant partagé. Une exception de pare-feu qui devait être temporaire il y a trois ans.

NIS2 Article 21 inclut explicitement la sécurité de la chaîne d’approvisionnement, les vulnérabilités propres aux fournisseurs, les pratiques de cybersécurité des fournisseurs et les procédures de développement sécurisé. NIST CSF 2.0 est également détaillé sur ce point, avec la criticité des fournisseurs, les exigences contractuelles, la diligence raisonnable, la surveillance continue, la coordination des incidents et les dispositions de sortie.

La Politique de sécurité des tiers et des fournisseurs - PME de Clarysec énonce le principe en termes simples :

Les fournisseurs ne doivent recevoir un accès qu’aux systèmes et aux données minimaux nécessaires à l’exécution de leur fonction.

Pour l’OT, l’accès minimal signifie davantage que le contrôle d’accès fondé sur les rôles dans une application. L’accès fournisseur doit être :

• Préapprouvé pour un objectif de maintenance défini
• Limité dans le temps et désactivé par défaut
• Protégé par MFA ou authentification continue, le cas échéant
• Acheminé par un bastion sécurisé ou une plateforme d’accès à distance contrôlée
• Limité à la zone ou à l’actif OT pertinent
• Journalisé, surveillé et, pour les accès à haut risque, enregistré au niveau de la session
• Revu après achèvement
• Couvert par des obligations contractuelles de sécurité et de notification des incidents

La Politique de sécurité IoT / OT d’entreprise inclut une exigence dédiée d’accès à distance :

L’accès à distance (pour l’administration ou la maintenance fournisseur) doit :

Cette clause ancre le point de gouvernance, tandis que les exigences détaillées doivent être mises en œuvre dans les procédures d’accès, les accords fournisseurs, la configuration technique et les flux de travail de surveillance.

Dans Zenith Controls, la mesure ISO/IEC 27002:2022 5.21, Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, est classée comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur le concept Identify, avec la sécurité des relations fournisseurs comme capacité opérationnelle et Gouvernance, Écosystème et Protection comme domaines.

Pour l’OT, cette cartographie aide à expliquer pourquoi les éléments de preuve relatifs à l’accès à distance relèvent simultanément des dossiers de risque fournisseur, de gouvernance des identités, de sécurité réseau, de réponse aux incidents et de continuité.

Réponse aux incidents : l’horloge NIS2 rencontre la salle de contrôle

Revenons à l’alarme de 02 h 17. L’organisation doit décider si l’événement est important au sens de NIS2. Article 23 exige la notification, sans retard injustifié, des incidents importants affectant la fourniture de services. La séquence comprend une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d’incident dans les 72 heures, des mises à jour intermédiaires si elles sont demandées, et un rapport final au plus tard un mois après la notification d’incident, ou un rapport d’avancement si l’incident est toujours en cours.

En OT, la réponse aux incidents doit répondre à des questions que les procédures IT ignorent souvent :

• L’équipement affecté peut-il être isolé sans créer de risque de sûreté ?
• Qui a l’autorité pour arrêter la production ou passer en mode manuel ?
• Quels journaux sont volatils et nécessitent une conservation immédiate ?
• Quel fournisseur ou intégrateur doit être contacté ?
• L’événement est-il malveillant, accidentel, environnemental ou causé par une mauvaise configuration ?
• Pourrait-il avoir un impact transfrontalier ou un impact sur les destinataires du service ?
• Des données à caractère personnel sont-elles concernées, telles que des journaux de badges, de la vidéosurveillance, des données du personnel ou des enregistrements de service client ?

La politique OT PME donne une règle simple d’escalade des anomalies :

Toute anomalie doit être immédiatement signalée au Directeur général pour suite à donner

Elle inclut également un principe de confinement tenant compte de la sûreté :

L’appareil doit être immédiatement déconnecté du réseau, lorsque cela peut être fait en toute sécurité

Ces cinq derniers mots sont critiques. La réponse OT ne peut pas copier aveuglément les actions de confinement IT. « Lorsque cela peut être fait en toute sécurité » doit être reflété dans les procédures opérationnelles, les matrices d’escalade, la formation et les exercices sur table.

NIST CSF 2.0 s’y prête bien. Ses résultats Respond et Recover couvrent le triage, la catégorisation, l’escalade, l’analyse de la cause racine, l’intégrité des éléments de preuve, la notification des parties prenantes, le confinement, l’éradication, la restauration, les vérifications d’intégrité des sauvegardes et les communications de rétablissement.

Construire une ligne d’éléments de preuve du risque au contrôle

Une manière pratique d’éviter une conformité fragmentée consiste à construire une ligne unique d’éléments de preuve, du risque à la réglementation, puis au contrôle et à la preuve.

Scénario : un fournisseur de compresseur à distance nécessite un accès à un poste d’ingénierie dans le réseau OT. Le poste peut modifier la logique PLC. Le compte fournisseur est toujours activé, partagé par plusieurs ingénieurs du fournisseur et protégé uniquement par un mot de passe. Le poste exécute un logiciel qui ne peut pas être mis à niveau avant le prochain arrêt de maintenance.

Inscrivez le scénario de risque dans le registre des risques :

« Un accès fournisseur à distance non autorisé ou compromis au poste d’ingénierie OT pourrait entraîner des modifications non autorisées de la logique PLC, une interruption de production, un impact sur la sûreté et une interruption de service notifiable au titre de NIS2. »

Puis cartographiez les contrôles et obligations.

Le plan de traitement doit désactiver l’accès fournisseur permanent, imposer des identités fournisseurs nominatives, appliquer MFA, acheminer l’accès par un serveur de rebond contrôlé, limiter l’accès au poste d’ingénierie, exiger l’approbation d’un ticket de maintenance, enregistrer les sessions à privilèges, surveiller les commandes et le trafic anormal, documenter le poste non corrigé comme dérogation de vulnérabilité et tester la réponse aux incidents pour les activités fournisseurs suspectes.

Zenith Blueprint, phase Risk Management, Step 13, donne la logique de traçabilité de la SoA :

Référencer les réglementations de manière croisée : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez l’indiquer soit dans le registre des risques (dans la justification de l’impact du risque), soit dans les notes de la SoA.

La leçon pratique est simple. Ne conservez pas les éléments de preuve NIS2, ISO et d’ingénierie OT dans des silos séparés. Ajoutez dans le registre des risques et la SoA des colonnes pour le thème NIS2 Article 21, la mesure ISO/IEC 27002:2022, la famille d’exigences IEC 62443, le propriétaire des éléments de preuve et le statut d’audit.

Où GDPR et DORA s’insèrent dans la sécurité OT

La sécurité OT ne concerne pas toujours uniquement les machines. Les environnements d’infrastructures critiques traitent souvent des données à caractère personnel au moyen de vidéosurveillance, de systèmes de contrôle d’accès, de journaux de badges, de systèmes de sûreté du personnel, de tickets de maintenance, de suivi des véhicules, de systèmes visiteurs et de plateformes de service client.

GDPR exige que les données à caractère personnel soient traitées de manière licite, loyale et transparente, collectées pour des finalités déterminées, limitées à ce qui est nécessaire, tenues exactes, conservées uniquement aussi longtemps que nécessaire et protégées par des mesures techniques et organisationnelles appropriées. Il impose également la responsabilité, ce qui signifie que le responsable du traitement doit être en mesure de démontrer la conformité.

Pour l’OT, cela signifie que les journaux d’accès et les enregistrements de surveillance ne doivent pas devenir des entrepôts de données de surveillance non maîtrisés. La conservation, les droits d’accès, la limitation des finalités et l’évaluation des violations doivent être intégrés à la journalisation et à la surveillance.

DORA peut s’appliquer lorsque des entités financières sont concernées, ou lorsqu’un fournisseur de services TIC tiers soutient la résilience opérationnelle du secteur financier. DORA couvre la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience et les risques liés aux prestataires TIC tiers. Pour les entités financières qui sont également des entités essentielles ou importantes au titre des règles de transposition de NIS2, DORA peut constituer le régime sectoriel spécifique pour les obligations qui se recoupent, tandis qu’une coordination avec les autorités NIS2 peut rester pertinente.

Les mêmes disciplines de preuve s’appliquent : identification des actifs, protection, détection, continuité, sauvegarde, risque tiers, tests, formation et supervision par la direction.

Le prisme de l’audit : un contrôle, plusieurs perspectives d’assurance

Une mise en œuvre solide de la sécurité OT NIS2 doit résister à plusieurs perspectives d’audit.

C’est pourquoi Clarysec traite Zenith Controls comme une boussole de conformité croisée. Ses attributs de contrôle aident à expliquer l’objectif des contrôles officiels ISO/IEC 27002:2022, tandis que l’approche de cartographie relie ces contrôles à NIS2, NIST CSF, la gouvernance des fournisseurs, la continuité et les éléments de preuve d’audit.

Pièges courants de mise en œuvre OT NIS2

Les défaillances les plus courantes de sécurité OT sont rarement causées par une absence de documents. Elles sont causées par des documents qui ne correspondent pas à l’usine.

Piège 1 : l’IT porte le programme NIS2, mais l’OT porte le risque. Les opérations, l’ingénierie, la sûreté et la maintenance doivent être impliquées.

Piège 2 : l’inventaire des actifs s’arrête aux serveurs. Un inventaire OT doit inclure les PLC, RTU, IHM, serveurs d’historisation, postes d’ingénierie, commutateurs industriels, capteurs, passerelles, équipements d’accès à distance et composants administrés par les fournisseurs.

Piège 3 : la segmentation existe sur un schéma, mais pas dans les règles de pare-feu. Les auditeurs demanderont des éléments de preuve d’application, de gestion des changements et de surveillance.

Piège 4 : les dérogations de vulnérabilité sont informelles. Les contraintes liées aux systèmes hérités ne sont acceptables que si elles sont documentées, approuvées, surveillées et réexaminées.

Piège 5 : l’accès fournisseur est traité uniquement comme un sujet fournisseur. C’est aussi un sujet de contrôle d’accès, de journalisation, de surveillance, de sécurité réseau, de réponse aux incidents et de continuité.

Piège 6 : la réponse aux incidents ignore la sûreté. Les procédures OT doivent définir qui peut isoler des appareils, arrêter des processus, changer de mode ou contacter les autorités de régulation.

Piège 7 : la notification NIS2 n’est pas exercée. Le processus de décision à 24 heures et 72 heures doit être testé avant un événement réel.

Le chemin de mise en œuvre Clarysec : de la responsabilité du conseil aux éléments de preuve OT

Une mise en œuvre pratique de la sécurité OT NIS2 peut suivre cette séquence :

1. Confirmer le périmètre NIS2, la classification de l’entité et la criticité du service.
2. Définir le périmètre OT dans le SMSI, y compris les interfaces et les dépendances.
3. Construire un inventaire des actifs OT et des flux de données.
4. Identifier les obligations légales, contractuelles, de sûreté, de protection des données et sectorielles.
5. Organiser des ateliers d’appréciation des risques propres à l’OT avec l’ingénierie, les opérations, l’IT, le SOC, les achats et la direction.
6. Cartographier le traitement des risques avec les contrôles ISO/IEC 27002:2022, les thèmes NIS2 et les modèles de mise en œuvre IEC 62443.
7. Mettre à jour la Déclaration d’applicabilité avec la justification OT et les propriétaires des éléments de preuve.
8. Mettre en œuvre les contrôles prioritaires : segmentation, accès fournisseur, gestion des vulnérabilités, surveillance, sauvegardes et réponse aux incidents.
9. Mettre à jour les politiques et procédures, notamment sécurité OT, sécurité des fournisseurs, accès à distance, réponse aux incidents et continuité d’activité.
10. Réaliser des exercices sur table et des validations techniques.
11. Préparer des dossiers d’audit pour NIS2, ISO/IEC 27001:2022, les programmes d’assurance demandés par les clients et la gouvernance interne.
12. Alimenter la revue de direction et l’amélioration continue avec les constats.

Cela reflète le modèle opérationnel de Zenith Blueprint, notamment Step 13 pour le traitement des risques et la traçabilité de la SoA, Step 14 pour l’élaboration des politiques et les références réglementaires croisées, Step 19 pour la gestion des vulnérabilités et Step 20 pour la sécurité réseau.

La même approche utilise les politiques Clarysec pour transformer le langage des référentiels en règles opérationnelles. La Politique de sécurité IoT / OT d’entreprise exige une revue d’architecture de sécurité avant le déploiement :

Tous les nouveaux appareils IoT/OT doivent faire l’objet d’une revue d’architecture de sécurité avant leur déploiement. Cette revue doit valider :

Elle indique également :

Tout le trafic au sein des réseaux IoT/OT et entre ceux-ci doit être surveillé en continu au moyen de :

Ces clauses créent des ancrages de gouvernance. Les éléments de preuve de mise en œuvre peuvent inclure des alertes IDS OT, des journaux de pare-feu, des corrélations SIEM, des profils de trafic de référence, des tickets d’anomalie et des enregistrements de réponse.

À quoi ressemblent de bons éléments de preuve OT NIS2

Un dossier d’éléments de preuve OT NIS2 doit être assez pratique pour les ingénieurs et assez structuré pour les auditeurs.

Pour la segmentation, incluez l’architecture approuvée, les schémas de zones et de conduits, les exports de règles de pare-feu, les enregistrements de changements, les revues périodiques des règles, les enregistrements de dérogations et les alertes de surveillance.

Pour l’accès fournisseur, incluez l’évaluation de la criticité du fournisseur, les clauses contractuelles, la procédure d’accès approuvée, les comptes nominatifs, les éléments de preuve MFA, les journaux d’accès, les enregistrements de session, la revue périodique des droits d’accès et les enregistrements de départ.

Pour la gestion des vulnérabilités, incluez l’inventaire, les sources d’avis, les résultats de découverte passive, les tickets de vulnérabilité, les plans de correctifs, les mesures compensatoires, l’acceptation du risque et les éléments de preuve de clôture.

Pour la réponse aux incidents, incluez les procédures, les contacts d’escalade, l’arbre de décision de notification NIS2, les résultats d’exercices sur table, les tickets d’incident, les projets de notification aux autorités, les règles de traitement des éléments de preuve et le retour d’expérience.

Pour la continuité, incluez la stratégie de sauvegarde OT, les sauvegardes hors ligne ou protégées, les résultats des tests de restauration, la liste des pièces de rechange critiques, les procédures d’exploitation manuelle, les priorités de reprise et les plans de communication de crise.

Pour la gouvernance, incluez l’approbation du conseil ou de la direction, l’attribution des rôles, les enregistrements de formation, les résultats d’audit interne, les KPI, les comptes rendus de revue des risques et les décisions de revue de direction.

Ce modèle d’éléments de preuve s’aligne sur ISO/IEC 27001:2022 parce qu’il soutient le traitement des risques, les informations documentées, l’évaluation de la performance et l’amélioration continue. Il s’aligne sur NIS2 parce qu’il démontre des mesures appropriées et proportionnées. Il s’aligne sur IEC 62443 parce qu’il peut être rattaché à l’architecture OT et aux contrôles d’ingénierie.

Transformer votre programme de sécurité OT en préparation NIS2 auditable

Si votre environnement OT soutient un service critique ou réglementé, attendre qu’une autorité de régulation, un client ou un incident révèle les lacunes est la mauvaise stratégie.

Commencez par un cas d’usage à fort impact : accès fournisseur à distance à une zone OT critique, gestion des vulnérabilités pour des actifs industriels non pris en charge, ou segmentation entre l’IT d’entreprise et l’OT. Construisez le scénario de risque, cartographiez-le avec NIS2 Article 21, sélectionnez les contrôles ISO/IEC 27002:2022, traduisez-les en modèles de mise en œuvre IEC 62443 et collectez les éléments de preuve.

Clarysec peut vous aider à accélérer ce travail avec Zenith Blueprint, Zenith Controls, la Politique de sécurité IoT / OT, la Politique de sécurité Internet des objets (IoT) / technologies opérationnelles (OT) - PME et la Politique de sécurité des tiers et des fournisseurs - PME.

Votre prochaine action : choisissez un service OT, cartographiez ses actifs et dépendances, et créez cette semaine une ligne d’éléments de preuve du risque au contrôle. Si vous souhaitez un chemin de mise en œuvre structuré, la feuille de route en 30 étapes de Clarysec et sa boîte à outils de conformité croisée peuvent transformer cette première ligne en programme complet de sécurité OT NIS2.