Il y a bien longtemps (une vingtaine d’années), les systèmes de contrôle étaient des systèmes autonomes, généralement découplés des réseaux généraux, utilisant leurs propres infrastructures de câblage réseau (via divers bus et protocoles propriétaires) ainsi que des langages de programmation spécifiques. Ce n’est plus le cas aujourd’hui.

Avec l’essor des technologies informatiques « standards », l’interconnectivité et les services informatiques ont eux aussi fait leur apparition. Des premiers essais effectués au CERN et ailleurs ont toutefois démontré qu’une conséquence de cette évolution est que les systèmes de contrôle ont hérité des défauts et des faiblesses inhérents à ces technologies. Or, les systèmes de contrôle ne peuvent pas être corrigés aussi rapidement que les systèmes informatiques. Les cycles de maintenance doivent être respectés, les certificats doivent être renouvelés, et les boucles de régulation doivent être revalidées.

Et pourtant, de plus en plus, les fabricants de systèmes de contrôle intègrent dans leurs produits des systèmes informatiques, alors même que ces outils ne rentrent pas dans leur champ d’expertise, qui est plutôt les systèmes perfectionnés d’acquisition de données, les appareils de mesure de grande précision comme les oscilloscopes, les systèmes de synchronisation précis, etc. Les experts et opérateurs de systèmes de contrôle ont des connaissances et des compétences spécifiques à leur domaine. Ils n’ont pas forcément d’expertise en gestion de réseaux ou de serveurs web, en programmation de logiciels ou en administration de base de données. Malgré cela, les fabricants et les utilisateurs de système de contrôle ont cherché à tirer parti des systèmes informatiques sans prendre en compte les risques associés et les mesures d’atténuation nécessaires.

Dans le cadre de la conférence ICALEPCS, consacrée aux systèmes de contrôle des accélérateurs et des grandes expériences de physique, neuf ateliers sur la cybersécurité pour les systèmes de contrôle ont été organisés en amont de l’évènement pour sensibiliser les spécialistes des systèmes de contrôle et les mettre en relation avec des experts en cybersécurité afin d’améliorer, globalement et au cas par cas, la cybersécurité des systèmes de contrôle des accélérateurs et des grandes expériences scientifiques. Certes, les laboratoires et expériences s’appuyant sur des accélérateurs ont déjà largement commencé à adopter des mesures de protection standard en matière de cybersécurité, mais, en raison de l’environnement complexe des technologies opérationnelles, ainsi que les contraintes liées au calendrier de déploiement, il est très difficile de procéder à des adaptations fondamentales des systèmes de contrôle pour obtenir une architecture et un fonctionnement sécurisés.

Toujours au même point ?

En l’espace de 20 ans, les systèmes de contrôle n’ont guère changé en termes de complexité, de délais et de sécurité. À vrai dire, ils sont devenus encore plus complexes et interconnectés, créant davantage d’interdépendances et rendant le déploiement des mesures de sécurité encore plus difficile. De leur côté, les fabricants et fournisseurs de matériel ont pleinement adopté les nouvelles technologies informatiques.

Des tests d’intrusion récemment menés par l’équipe de sécurité informatique du CERN sur une multitude de systèmes de contrôle, de dispositifs embarqués et d’objets connectés ont mis en évidence des lacunes fondamentales en matière de sécurité :

• Dans des caméras de vidéosurveillance vendues dans le commerce installées au CERN, les mots de passe par défaut, les certificats privés et autres informations secrètes n’avaient aucune protection matérielle, alors qu’il existe des technologies de puce sécurisée, appelées modules d’application sécurisée (SAM). Par ailleurs, dans des dispositifs embarqués issus de l’internet des objets, il s’est avéré impossible de modifier les mots de passe par défaut, ou bien aucun mécanisme de contrôle d’accès n’était présent, de sorte que toute personne ayant accès au réseau pouvait en prendre totalement le contrôle.
• Il existe des casiers connectés, contrôlés par un système en nuage, permettant aux utilisateurs de les ouvrir ou de les fermer en scannant un code QR au lieu d’utiliser un bracelet doté d’une puce d’identification par radiofréquence (RFID), ou encore un jeton ou une clé. Malheureusement, ce service en nuage présentait une configuration informatique vulnérable, permettant à n’importe quel internaute de manipuler la fonctionnalité d’ouverture et de fermeture des casiers n’importe où dans le monde. Dans le cas d’espèce, il en résulte un risque de vol mineur et potentiellement maîtrisable. En revanche, sur des défibrillateurs connectés, une faille du même type pourrait coûter des vies. Par ailleurs, une analyse des machines à laver connectées au nuage, utilisées dans les hôtels du CERN, est en préparation.
• Les modules de cartes de circuits imprimés faits sur mesure, connectés à l’intranet du CERN, se sont révélés dépourvus de toute robustesse face à la réception de paquets réseau inappropriés ou malformés. Au lieu de simplement les ignorer, les modules ont complètement cessé de fonctionner. Dans certains cas, leur redémarrage a nécessité la mise à jour du micrologiciel local.
• Le mécanisme d’authentification d’un système SCADA accessible par le web s’est avéré défectueux ; il était possible de contourner entièrement le processus d’authentification.
• En outre, des mots de passe partagés sont utilisés pour de vastes infrastructures de systèmes de contrôle d'accès et sont transmis sans protection, en clair, alors qu’il faudrait utiliser un chiffrement ainsi que des identifiants ou des certificats propres à chaque appareil.
• Dans d’autres cas, des mots de passe d’experts et d’opérateurs ont été accidentellement divulgués sur des sites web publics. Malheureusement, il s’est avéré impossible de modifier systématiquement ces mots de passe pour des raisons opérationnelles (mots de passe codés en dur) ou de savoir avec certitude dans quels systèmes ils étaient utilisés. De même, ces mots de passe se retrouvent régulièrement dans des référentiels publics Git, GitHub ou GitLab, ou dans leurs branches, leurs duplications, et les journaux d’audit dans les pipelines intégrés.

Quel est le risque ? Y a-t-il réellement un impact sur la sécurité ? Les cybercriminels s’intéressent-ils à nos systèmes de contrôle ?  Ou bien les incidents de cybersécurité liés aux systèmes de contrôle sont-ils des « cygnes noirs », à savoir des évènements rares inutilement montés en épingle ? À quelle fréquence surviennent-ils en réalité ? La suite au prochain Bulletin.

Cet article est une version abrégée de l’article paru dans les actes de l’édition 2025 de la conférence ICALEPCS.

_____

Pour en savoir plus sur les incidents et les problèmes en matière de sécurité informatique au CERN, lisez nos rapports mensuels (en anglais). Si vous souhaitez avoir plus d’informations, poser des questions ou obtenir de l’aide, visitez notre site ou contactez-nous à l’adresse suivante : Computer.Security@cern.ch.