Vulnérabilités OT/ICS (CVE)

Définition

Les vulnérabilités OT/ICS désignent les failles de sécurité — référencées ou non par un identifiant CVE (Common Vulnerabilities and Exposures) — qui affectent les équipements des systèmes industriels : automates programmables (API/PLC), interfaces homme-machine (IHM/HMI), serveurs SCADA, systèmes numériques de contrôle-commande (DCS), passerelles de protocole, variateurs de vitesse ou capteurs intelligents. Leur particularité tient moins à leur nature technique qu'à leur contexte d'exploitation : ces équipements pilotent des procédés physiques (production continue, distribution d'eau, énergie, transport) dont l'arrêt coûte cher, voire met en jeu la sécurité des personnes. Résultat : une part importante de ces CVE reste non corrigée pendant des mois ou des années, faute de fenêtre de maintenance, de correctif disponible ou d'homologation constructeur du patch.

Pourquoi le modèle IT ne s'applique pas

Dans le monde bureautique, la réponse à une CVE est réflexe : appliquer le correctif. En OT, plusieurs contraintes structurelles bloquent ce réflexe.

• Disponibilité prioritaire : le triptyque classique confidentialité–intégrité–disponibilité s'inverse en D-I-C. Redémarrer un automate signifie souvent arrêter une ligne de production.
• Cycle de vie long : un automate déployé en 2008 peut encore tourner en 2030. Le firmware n'est plus maintenu, l'éditeur du logiciel d'ingénierie a disparu ou la version supportée exige un changement de matériel.
• Homologation et garantie : appliquer un correctif Windows sur un poste d'ingénierie peut rompre le support constructeur ou invalider une qualification réglementaire (pharmaceutique, nucléaire, ferroviaire).
• Vulnérabilités « by design » : beaucoup de protocoles industriels (Modbus/TCP, DNP3, S7comm, EtherNet/IP) n'intègrent ni authentification ni chiffrement. Ces faiblesses ne relèvent pas d'un bug corrigeable : ce sont des choix d'architecture historiques, que l'initiative OT:ICEFALL (56 failles publiées en 2022 chez 10 constructeurs) a largement documentés.

Fonctionnement technique et vecteurs d'exploitation

Les CVE industrielles se regroupent en quelques grandes familles récurrentes :

• Authentification absente ou contournable : envoi direct de commandes d'arrêt/démarrage, téléversement de logique automate sans contrôle d'identité.
• Secrets codés en dur : clés privées ou mots de passe identiques sur toute une gamme d'équipements, permettant de forger des sessions légitimes.
• Débordements mémoire dans les piles réseau : les campagnes URGENT/11 (VxWorks) et Ripple20 (pile TCP/IP Treck) ont touché des centaines de millions d'équipements embarqués, souvent sans que l'intégrateur sache même quelle pile tournait dans son produit — d'où l'importance du SBOM.
• Déni de service par paquet malformé : un simple scan agressif peut faire basculer un automate en mode défaut, ce qui explique la prudence extrême sur les tests intrusifs en OT.
• Manipulation de la logique métier : altération des points de consigne, des seuils d'alarme ou du programme ladder, sans exploiter la moindre faille mémoire.

Les exemples marquants ne manquent pas : Stuxnet (2010) qui modifiait la vitesse des variateurs tout en rejouant des valeurs normales vers l'IHM ; les failles Siemens SIMATIC S7-1200/1500 permettant de contourner la protection de la logique ; les correctifs Rockwell Automation liés à des clés cryptographiques statiques ; ou le framework offensif PIPEDREAM/INCONTROLLER (2022), conçu pour cibler nativement des équipements Schneider et Omron.

Liens avec les autres concepts cyber

Une CVE OT ne s'exploite presque jamais depuis Internet directement : elle constitue le maillon final d'une chaîne d'intrusion qui commence côté IT. Compromission d'un compte via phishing, latéralisation dans l'Active Directory, rebond par un VPN de télémaintenance ou une station d'ingénierie, puis franchissement de la DMZ industrielle vers les niveaux inférieurs du modèle de Purdue. C'est également le scénario type des attaques ransomware ayant provoqué des arrêts industriels, où l'OT est stoppé par précaution plus que réellement chiffré. Le cadre réglementaire suit : la directive NIS 2, la LPM pour les OIV et le Cyber Resilience Act imposent désormais une gestion documentée des vulnérabilités sur ces périmètres, tandis que la norme ISA/IEC 62443 fournit le référentiel technique de référence.

Bonnes pratiques

• Construire un inventaire exhaustif : sans cartographie des marques, modèles, versions de firmware et composants tiers, aucune veille CVE n'est exploitable. Privilégier la collecte passive (analyse de flux réseau) plutôt que le scan actif.
• Prioriser par le risque procédé, pas par le score CVSS : une CVE 9.8 sur un équipement isolé sans impact sécurité pèse moins qu'une CVE 6.5 sur un système instrumenté de sécurité (SIS).
• Segmenter en zones et conduits selon l'IEC 62443, avec pare-feu industriels filtrant au niveau protocolaire et suppression de tout accès direct depuis l'IT.
• Appliquer le virtual patching quand le correctif est impossible : règles IPS spécifiques, listes blanches d'applications sur les postes d'ingénierie, restriction des commandes autorisées.
• Maîtriser les accès distants : télémaintenance constructeur avec authentification forte, session enregistrée, ouverture à la demande et journalisée.
• Suivre les sources officielles : avis CISA ICS-CERT, bulletins CERT-FR et notifications éditeurs, intégrés à un processus formel de qualification puis de déploiement lors des arrêts planifiés.
• Préparer la réponse à incident en OT : procédures de repli manuel, sauvegardes hors ligne des programmes automates et exercices de crise associant automaticiens et équipes SSI.