Feux de circulation piratés – de la pure fiction ?

La technologie opérationnelle, ou Operational Technology (abrégé OT), nous accompagne au quotidien. Elle commande des processus physiques tels que le système de pompage d’un réseau d’approvisionnement en eau de la ville, le contrôle de la température ambiante dans le logement ou la commande d’un feu de circulation dans le trafic routier. La plupart du temps, un automate programmable industriel (API) est utilisé à cet effet. Il surveille les processus et les états et les gère conformément aux prescriptions.

Les cycles de vie de ces appareils de commande sont nettement plus longs que ceux des appareils informatiques ou de l’électronique grand public. Selon le domaine d’utilisation, ils peuvent durer 15 ans ou plus. En raison de ces longs cycles de vie, la programmation des appareils reste fondamentalement inchangée. Plus précisément, elle ne doit pas changer du tout, car les appareils qui ont été mis en service il y a dix ans et ceux qui sont actuellement mis en service doivent pouvoir être configurés et programmés avec le même logiciel. 

La norme CEI 61131 s’est imposée comme norme pour la programmation d’un API. Les langages de programmation pris en charge sont les suivants :

Le langage utilisé dépend de plusieurs facteurs. En Amérique du Nord, on programme principalement en schémas de contact (LD), alors qu’ici en Europe, on utilise de plus en plus les diagrammes de blocs fonctionnels (FBD) en combinaison avec du texte structuré ou des graphes séquentiels. La liste d’instructions n’est pratiquement plus utilisée. Pour cela, des langages de programmation tels que Python ou Blockly font leur entrée dans les nouveaux modèles d’API.

Dans les langages de programmation standardisés, les fabricants d’API ou les intégrateurs de systèmes fournissent des blocs et des bibliothèques pour permettre, par exemple, la communication entre les appareils ou bien l’affichage sur une interface utilisateur.

Lacune de la Security by Design

Les cinq langages de programmation et les bibliothèques de support des fabricants ont un point commun : les fonctions de sécurité s’y font rare. Pour être honnête, il convient de mentionner qu’il n’existait pratiquement aucune exigence de sécurité pour les appareils d’OT et leurs logiciels jusqu’à il y a cinq ans. Seule la vague de ransomware «NotPetya» qui a fait rage en 2017 a montré de manière impressionnante que l’interconnexion croissante de l’informatique et de l’OT des entreprises pouvait conduire à un risque de cyberattaque dans le domaine de l’OT.

Depuis, les fabricants s’efforcent d’intégrer la sécurité dans leurs produits. Mais là aussi, le long cycle de vie des appareils est un inconvénient, car les produits qui ne sont plus vendus actuellement ne sont généralement pas équipés ultérieurement de fonctions de sécurité. Et les systèmes déjà mis en service ne sont pas facilement modifiés ou ne doivent pas l’être pour des raisons de certification.

Un autre défi que pose l’intégration de la sécurité dans les programmes API est la création des programmes API eux-mêmes. Il est rare que le logiciel API soit créé à partir de zéro pour un nouveau projet. Dans la mesure du possible, les modules de programme déjà testés et mis en service sont réutilisés.

20 meilleures pratiques de programmation API

Afin d’augmenter néanmoins la cyberrésilience des automates programmables, les programmeuses et programmeurs d’API se sont associés et ont rassemblé les «Top 20 Secure PLC Coding Practices» dans le cadre d’un projet commun. Il s’agit de 20 pratiques de programmation visant à renforcer la cybersécurité en matière d’API.

L’objectif du projet est de pouvoir mettre en œuvre les 20 pratiques avec les moyens existants, la norme de programmation CEI 61131 et avec un minimum d’effort de programmation. Les pratiques ont été créées par des programmeuses et programmeurs d’API pour leurs homologues et sont accessibles au public à l’adresse www.plc-security.com. SWITCH-CERT a traduit la description des pratiques en allemand.

La liste des pratiques est également intéressante en raison des références croisées à la norme de sécurité OT/ICS CEI 62443 et à «MITRE ATT&CK for ICS attack collection», un recueil de cyberattaques possibles dans le domaine de la technologie opérationnelle.

Configuration de l’appareil hors connexion

Un exemple : Une vulnérabilité (Advisory-Number : CVE-2023-0053, https://www.cisa.gov/news-events/ics-advisories/icsa-23-012-05) est décrite comme «permettant l’exécution de commandes de configuration sans connexion de l’utilisateur». Cela signifie qu’il est possible d’apporter des modifications à la configuration de l’appareil sans entrer de nom d’utilisateur et de mot de passe si l’on dispose d’un accès réseau à l’appareil. Cela semble grave, mais c’est une réalité dans le monde de la technologie opérationnelle.

La pratique numéro 13 aide à se prémunir contre de telles vulnérabilités : «Désactivez les ports et protocoles de communication inutiles/inutilisés.» Dans cet exemple, il est très probable que les ports de communication de l’appareil, en l’occurrence Telnet (TCP Port 23) et FTP (TCP Port 21), ne puissent pas être désactivés car cela bloque la possibilité de configuration. En d’autres termes : En tant qu’utilisateur, je me verrouillerais moi-même et ne pourrais plus configurer l’appareil. 

L’étape suivante consiste à bloquer l’accès à ces ports sur le réseau, ce qui peut par exemple être configuré à l’aide d’un pare-feu. En l’absence de pare-feu, il reste encore la surveillance du trafic réseau et le déclenchement d’une alarme en cas d’accès non autorisé à ces ports.

Pour les programmeuses et programmeurs d’API expérimentés, certaines pratiques peuvent sembler simples. C’est un choix délibéré pour offrir une aide précieuse aux programmateurs d’API novices. Par exemple, la pratique numéro 12, le contrôle de plausibilité des entrées utilisateur : «Assurez-vous que les utilisateurs ne peuvent saisir que ce qui est faisable physiquement ou en pratique au cours du processus. Réglez une minuterie sur la durée d’un processus physique. Envisagez un message d’avertissement en cas d’écarts. Alertez aussi en cas d’inactivité inattendue.»

Envie d’un scénario catastrophe

Imaginez que des criminels accèdent au réseau d’une installation routière via des e-mails de phishing. Sur LinkedIn, il est facile de trouver les personnes qui s’occupent de ces infrastructures. Une fois introduit dans le réseau, les installations de commande ne sont pratiquement plus protégées. Les données ne sont pas chiffrées. Vous pensez que c’est de la pure invention? Voici un exemple réel, mais anonyme, tiré de ma pratique : Il n’y a pas si longtemps, j’ai découvert sur Internet la commande d’un feu de circulation de Fantasia. L’accès graphique à l’installation était certes limité, mais l’accès via le protocole industriel était libre. Je connais ce protocole et j’ai pu le parcourir jusqu’à ce que je tombe sur les différents bits contrôlant les feux de circulation «rouge / orange / vert». J’aurais pu mettre tous les feux au vert en même temps. J’ai immédiatement signalé l’anomalie aux autorités compétentes. Ensemble, nous avons pu la corriger.

Cet exemple peut être facilement appliqué à d’autres scénarios où des installations de commande manipulées peuvent causer des dégâts considérables et mener à la catastrophe. Contrairement à l’informatique, l’OT se distingue par le fonctionnement disparate de ses installations de commande. Cela augmente considérablement la charge de travail des pirates informatiques pour s’attaquer à de telles cibles.

Que va-t-il advenir du projet commun?

D’une part, nous voulons continuer à faire connaître le projet. Une mise en œuvre exemplaire des pratiques avec l’environnement de programmation «Codesys» est prévue par l’auteur pour le milieu de cette année.

D’autre part, nous essayons de susciter l’enthousiasme des fabricants d’appareils d’OT pour le projet afin de créer avec eux des «Application Notes». Il s’agit donc d’une aide pour les programmeuses et programmeurs sur la manière dont les pratiques peuvent être mises en œuvre avec l’environnement de programmation et les bibliothèques des fabricants.