MOC (Management of Change OT)
otDéfinition
Le Management of Change OT (MOC) est un processus formel de gestion des modifications appliqué aux systèmes de contrôle industriel, garantissant que chaque changement dans l'environnement OT (logiciel, matériel, configuration réseau, programme de contrôle) est planifié, autorisé, testé, documenté, et supervisé avant sa mise en production, afin d'éviter les incidents de sécurité (cyber et physique) résultant de modifications non contrôlées. Le MOC OT est une extension du processus de Process Safety Management (PSM/HAZOP) traditionnel à la dimension cybersécurité. Le processus MOC OT standard comprend plusieurs étapes formelles : (1) Demande de changement : documentation de la modification proposée (description technique, justification, équipements affectés, risques potentiels), (2) Analyse de l'impact cyber : évaluation des implications cybersécurité du changement (nouveau vecteur d'attaque introduit, modification de la surface d'exposition réseau, impact sur la segmentation), (3) Test en environnement staging : validation du changement dans un environnement de test qui réplique l'environnement de production OT (factory acceptance test, site acceptance test) avant le déploiement en production, (4) Autorisation formelle : approbation par les responsables OT, cybersécurité, et si nécessaire sécurité physique (pour les modifications impactant les systèmes de sécurité), (5) Fenêtre de maintenance planifiée : exécution du changement pendant une fenêtre planifiée avec le minimum d'impact opérationnel, (6) Vérification post-changement : vérification que la modification a été correctement implémentée et que les systèmes fonctionnent normalement, (7) Documentation : mise à jour de la documentation technique et de l'inventaire d'actifs OT. L'absence de processus MOC OT formel est l'une des causes les plus fréquentes d'incidents cybernétiques et opérationnels dans les environnements industriels : des configurations de firewall modifiées sans test laissant des ports ouverts, des programmes PLC modifiés par un technicien sans revue de code créant des instabilités de processus, ou des équipements ajoutés sans inventaire créant du "shadow OT" non surveillé. Le MOC OT est donc à la fois un outil de gestion des risques cybersécurité et de gestion des risques opérationnels.
Fonctionnement du MOC OT pour un patch firmware d'un PLC
La mise à jour firmware d'un PLC Rockwell Automation ControlLogix en production illustre le processus MOC OT : (1) Demande de changement : l'ingénieur cybersécurité OT identifie via Claroty CTD une CVE critique (CVSS 9.8) dans la version firmware actuelle du PLC et initie une demande de changement MOC documentant la vulnérabilité, le firmware cible, et les risques de l'application du patch vs les risques de ne pas l'appliquer, (2) Analyse d'impact : vérification de la compatibilité du firmware cible avec le programme PLC existant (consultation des release notes Rockwell et contact du support Rockwell si nécessaire), identification des équipements communicant avec ce PLC qui pourraient être affectés par la mise à jour, (3) Test en staging : application du firmware sur un PLC de test avec le même programme de contrôle, validation du fonctionnement normal pendant 48 heures, (4) Autorisation : approbation de l'ingénieur OT senior et du RSSI, (5) Planification de la fenêtre de maintenance : coordination avec l'exploitation pour un arrêt programmé de la ligne, (6) Déploiement et vérification : application du firmware, validation du démarrage et du comportement normal de la ligne de production, (7) Documentation : mise à jour de la fiche d'actif du PLC dans l'outil CMDB avec la nouvelle version firmware.
Contexte OT/ICS et liens avec le PSM
Le MOC OT s'intègre dans le cadre plus large du Process Safety Management (PSM) défini par OSHA 29 CFR 1910.119 aux États-Unis et ses équivalents européens : le PSM impose déjà un processus MOC pour les modifications des procédés dangereux (modifications des paramètres de process, des équipements de production, des systèmes de sécurité instrumentés). L'extension de ce processus MOC existant pour couvrir les modifications cybernétiques est souvent plus facile que de créer un processus MOC OT séparé : les équipes sont déjà familières avec la démarche, les outils de gestion des demandes de changement (outils ITSM) sont déjà en place, et la culture de la gestion des risques de modification est établie.
Sécurité et mitigation
Implémentation d'un MOC OT efficace : intégrer l'évaluation cybersécurité (analyse d'impact cyber) dans tous les processus MOC OT existants plutôt que de créer un processus séparé, former les techniciens OT à l'importance du MOC cybersécurité (sensibilisation aux risques des modifications non contrôlées), utiliser un outil de gestion des demandes de changement avec workflow d'approbation intégrant les rôles cybersécurité, maintenir un environnement de test OT représentatif de la production pour valider les changements avant déploiement, et mesurer le respect du processus MOC (% de changements OT réalisés sans MOC préalable comme KPI cybersécurité).
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h