Cependant, dans le domaine des SI industriels, on ne parle quasiment jamais de la sécurité du code automate qui contrôle le procédé industriel. Pourquoi ?

Genèse du projet

Le projet a débuté avec la présentation de Jake Browdsky lors de la conférence S4 en 2019 

Dans cette conférence, le concept de sécurisation du processus industriel par l’application de pratiques de programmation sécurisée dans le code de l’automate est discuté et plusieurs exemples sont mentionnés.

Cette idée a ensuite été transformée en un projet collaboratif par Sarah Fluchs et Vivek Ponnada, auquel plus de 900 personnes ont contribué avec leurs idées !

Automates Programmables Industriels

Les automates programmables industriels (Programmable Logic Controller en anglais) sont situés au cœur de l’automatisation, au niveau 1 du modèle de Purdue.

Représentation ISA du modèle de Purdue

Le modèle de Purdue est-il mort ? – Dale Peterson : ICS Security Catalyst (dale-peterson.com)

Les automates programmables sont des ordinateurs embarqués avec un système temps-réel qui interagissent directement avec les capteurs et les actionneurs pour surveiller et contrôler une partie du processus industriel.

Ils exécutent une boucle infinie, composée de 4 étapes :

La « logique », ou code de l’automate, peut être écrite dans différents langages, tels que définis dans la norme CEI 61131-3 :

• Ladder Diagram
• Function Block Diagram
• Structured Text
• Instruction List [désormais obsolète]
• Sequential Function Chart

Le document TOP20

Le document TOP20 est le résultat des échanges en ligne visant à identifier les 20 pratiques de programmation les plus importantes et peut être téléchargé sur le site du projet.

Comme le TOP10 de l’OWASP, il ne vise pas à décrire toutes les pratiques de programmation sécurisée possibles, du moins pour le moment.

Chacune des pratiques du TOP20 est détaillée avec les mêmes informations :

Les 20 pratiques peuvent être organisées en trois catégories principales :

Quelques exemples

Voyons un exemple de chaque catégorie. Pour cela, nous utiliserons un automate d’entrée de gamme de notre laboratoire, un feu de signalisation ainsi qu’une supervision SCADA.

Malheureusement, chaque fournisseur d’automates – et même chaque famille d’automates – utilise son propre logiciel de programmation ; les exemples présentés ici ne peuvent donc pas être copiés-collés dans le code d’une autre marque d’automates et nécessiteront une implémentation différente.

Le code de l’automate ainsi que le projet SCADA utilisé pour la démonstration peuvent être téléchargés depuis notre page github.

Règle n°13 : Désactiver les ports et protocoles de communication inutiles / inutilisés

Cette pratique consiste à durcir l’automate. La plupart des automates d’aujourd’hui offrent un support pour plusieurs protocoles industriels, ainsi qu’une variété de services supplémentaires comme un serveur de fichier FTP, un serveur web et bien d’autres.

Désactiver les services non utilisés et renforcer la sécurité de ceux qui sont activés (changer les identifiants par défaut, etc.) est une étape nécessaire pour réduire la surface d’attaque et, par conséquent, limiter le nombre de correctifs de sécurité à appliquer à l’avenir (moins il y a de fonctionnalités activées, plus les vulnérabilités sont pertinentes, facilitant l’effort pour les corriger).

Jetons un coup d’œil à la vidéo :

Règles n°6 et n°8 : Vérification des entrées au niveau de l’automate.

Ces deux règles peuvent être démontrées dans le même exemple car elles suivent le même principe : ne pas faire aveuglément confiance aux entrées externes ! Pour quelqu’un comme moi qui a fait sa part de test d’intrusion d’applications web, je ne pourrais être plus d’accord !

Les plages valides pour les valeurs d’entrée sont souvent mises en œuvre au niveau SCADA, laissant la possibilité à un attaquant d’écrire directement une valeur hors plage dans le bon registre de l’automate.

Cela est particulièrement vrai pour les compteurs et les chronomètres, qui doivent être vérifiés pour s’assurer qu’ils sont supérieurs ou égaux à zéro, et que la valeur est inférieure à une limite supérieure qui a du sens pour le processus.

Jetons un coup d’œil à la vidéo :

Surveillance de l’automate programmable règles n°2 et n°5

Nous pouvons exploiter les données opérationnelles de l’automate pour essayer de détecter des situations anormales qui pourraient être des incidents de cybersécurité.

État de l’automate

S’assurer que l’automate est en mode « RUN » est essentiel pour la sûreté et la sécurité des opérations. Un automate à l’arrêt pourrait empêcher l’IHM SCADA d’afficher les bonnes informations à l’opérateur, ce qui entraînerait de mauvaises décisions.

De même, des fonctions telles que le « forçage » des entrées et des sorties peuvent empêcher l’IHM SCADA d’afficher l’état réel du processus, et doivent être détectées et clairement affichées à l’opérateur.

Jetons un coup d’œil à la vidéo :

Cette technique peut également être utilisée pour détecter les automates en mode « PROGRAM », ce qui permet de programmer l’automate à distance.

Firmware de l’automate et version du code

Ne serait-il pas formidable de pouvoir interroger la version du firmware de votre automate directement à partir d’un registre Modbus ? Eh bien, c’est possible !

En outre, sur notre automate, nous pouvons également obtenir une somme de contrôle du code de l’automate, ce qui signifie que nous pouvons détecter si quelqu’un a altéré le code de l’automate, déclencher une alarme et enquêter si nous ne pouvons pas faire correspondre cela à une entrée dans le registre de gestion des modifications.

Jetons un coup d’œil à la vidéo :

Alors, que pouvez-vous faire ?

Le document sur le top 20 est facilement disponible, mais comment l’utiliser ?

Si vous souhaitez en savoir plus sur la sécurité du code automate, vous pouvez également consulter le contenu que nous avons présenté lors de nos ateliers à DEFCON et BruCON sur notre page Github.

Cet article Top 20 Secure PLC Coding Practices est apparu en premier sur RiskInsight.