Le système de contrôle industriel (ICS) représente l’ensemble des ressources et machines permettant de superviser et contrôler un processus industriel. Cet article s’intéresse aux problématiques de sécurité sur les machines Windows de la couche de supervision et maintenance des ICS : les serveurs et clients SCADA, les Data Historian ou encore les stations d’ingénierie et poste de maintenance.
Un SCADA (Supervisory Control And Data Acquisition ou Système de contrôle et d’acquisition de données) permet de gérer et de contrôler à distance des installations industrielles. Cela inclut des machines telles que des postes de supervision, serveurs de centralisation de données, portables de maintenance…).
Les postes SCADA incluent trois fonctions principales :
- Acquisition : Des capteurs sont présents sur les automates programmables industriels (API) qui agissent sur le processus industriel. Ces capteurs sont reliés au SCADA afin que les différentes données du processus puissent être récupérées ;
- Supervision : Les opérateurs accèdent aux données récupérées et supervisent en temps réel le bon déroulement du processus industriel ;
- Contrôle : Lorsque le processus industriel le permet, les opérateurs peuvent envoyer certains ordres de contrôles aux automates afin d’adapter le processus industriel.
La nature de ces postes en fait un élément important de la chaîne de production, c’est pourquoi il est nécessaire de sécuriser leur partie logicielle qui fonctionne souvent sous Windows.
Cependant, des contraintes sont présentes par rapport à un poste en environnement bureautique classique :
- Les postes fonctionnent en continu, avec une fréquence de mise à jour très faible (une fois tous les 1 à 2 ans) ;
- De plus, ces postes ont une durée de vie très étendue, pouvant aller jusqu’à plus de 10 ans. Un poste SCADA fonctionnera donc en partie sur un système d’exploitation obsolète qui ne recevra plus de patchs de sécurité durant sa période de fonctionnement ;
- Enfin, les systèmes industriels sont parfois totalement isolés, ce qui empêche l’utilisation de solutions de sécurité telles que des EDR qui ont besoin de communiquer avec une console centrale pour remonter les alertes et récupérer les actions à effectuer.
Les solutions de sécurité classiques ne sont donc pas applicables dans un écosystème soumis à ces contraintes.
Une solution possible : le contrôle d’application
Une des solutions permettant de pallier ces problèmes est le contrôle d’application : cela consiste à gérer quelles applications sont autorisées à être exécutées ou non sur une machine grâce à une liste blanche d’applications autorisées.
Les solutions de contrôle d’application gèrent aussi bien les .exe que d’autres types de programmes tels que les DLL, les pilotes ou encore les scripts (comme PowerShell, CMD ou encore VBS).
Une partie significative des menaces proviennent de programmes malveillants. Ce genre de solutions permet d’autoriser uniquement les applications nécessaires tout en bloquant toute application indésirable ou dangereuse. Le contrôle d’application garde également un bon niveau de sécurité dans un système obsolète et sujet à des vulnérabilités, car durant les étapes de compromission, un attaquant est souvent amené à exécuter des programmes malveillants sur un système.
Par ailleurs, le contrôle d’application s’intègre facilement dans le milieu industriel : les postes de supervision sont soumis à bien moins de changements qu’un poste de bureautique ; il n’y aura donc pas besoin de revoir en permanence la liste blanche afin d’y ajouter des applications à autoriser.
Solutions de contrôle d’application sous Windows
Deux solutions de contrôle d’application sont présentes nativement sous Windows : Windows Defender Application Control (WDAC) et AppLocker. WDAC est apparu avec Windows 10 ; c’est le successeur d’AppLocker qui est présent depuis Windows 7. Les deux solutions partagent un fonctionnement très similaire, cependant WDAC est activement maintenu par Microsoft, avec de l’ajout de nouvelles fonctionnalités, tandis qu’AppLocker ne reçoit que des mises à jour de sécurité.
Lorsqu’une application n’est pas autorisée par la liste blanche, son exécution sera bloquée. Le message d’erreur suivant sera alors affiché à l’utilisateur. Un évènement contenant les informations du blocage sera également inscrit dans les logs de Windows pour revue par le SOC ou les administrateurs du système d’information.
Le contrôle d’application peut fonctionner en mode bloquant ou audit. Le mode audit permet de tester la liste utilisée : les applications non autorisées sont exécutées, mais un évènement de blocage est tout de même inscrit pour indiquer qu’elles ne fonctionneraient pas en mode bloquant.
Afin d’avoir un contrôle d’application efficace, il est nécessaire de constituer une liste blanche la plus restrictive possible tout en autorisant les applications métier. Pour les deux solutions, la liste blanche peut se constituer avec trois règles différentes :
- Règles de chemin : Autorise l’application selon le chemin depuis lequel elle est exécutée. Ce sont les règles les plus faciles à utiliser mais elles peuvent induire des problèmes de sécurité. Il est en effet courant de retrouver des dossiers autorisés dans la liste blanche et accessibles en écriture par les utilisateurs. Ces derniers seront donc en mesure de déposer n’importe quelle application dans le dossier pour pouvoir l’exécuter, contournant ainsi le contrôle d’application ;
- Règles d’éditeur : Autorise l’application en fonction des éléments de sa signature numérique. Ces règles sont tout autant faciles à utiliser que les règles de chemin mais gardent un bon niveau de sécurité en n’autorisant que des applications provenant d’éditeurs légitimes. L’avantage principal de ce type de règle est qu’elles restent valables après une mise à jour des applications car l’éditeur ne change pas. Cependant, cela nécessite que les applications à autoriser soient signées, ce qui n’est pas toujours le cas en milieu industriel ;
- Règles de hash : Autorise l’application selon son hash. Ces règles imposent le plus haut restrictif possible. Le hash de chaque application étant unique, seul le code explicitement autorisé par la politique peut être exécuté. Toutefois, ce type de règle génère un coût organisationnel important : toute modification d’une application change son hash ; la règle doit alors être mise à jour afin d’autoriser correctement l’application.
Pour les choix des types de règles à utiliser, on distingue deux cas de figures :
- Sur les équipements recevant des mises à jour, les règles d’éditeur doivent être privilégiées afin de garder la validité de la liste blanche même après modification des fichiers des applications. Les règles de chemin pourront être utilisées en second lieux pour les applications non signées, en faisant attention aux règles d’accès des répertoires en question ;
- Sur les équipements dont la configuration ne changera pas, les règles éditeurs peuvent être utilisées pour autoriser facilement le code de base de Windows. Les applications métier pourront alors être autorisées avec des règles de hash car elles ne seront pas vouées à changer.
Démarches de déploiement
Maintenant que l’on sait quels types de règles utiliser, il reste à constituer la liste blanche pour la machine à sécuriser. Deux approches sont retenues selon le type de poste à gérer :
Approche temporelle : Déploiement par amélioration continue
Cette méthode consiste à déployer le contrôle d’application en partant d’une politique de base autorisant les composants de Windows qui est ensuite améliorée petit à petit grâce aux évènements générés par l’exécution des applications métier.
Cette approche est particulièrement adaptée pour les postes existants en production sur lesquels les administrateurs n’ont pas beaucoup d’informations. Chaque évènement généré doit alors être revu afin d’estimer si l’application exécutée est légitime ou non. Cela permet d’obtenir une liste blanche exhaustive sans pour autant autoriser des applications illégitimes.
Approche par modèle : Déploiement sur une « golden image » puis réplication sur le reste des machines
Dans cette approche, WDAC sera déployé sur une « golden image », c’est-à-dire une image propre contenant toutes les applications nécessaires à l’utilisation métier de la machine. Une fois la politique correctement configurée, la golden image pourra être clonée sur toutes les autres machines ayant le même rôle. Typiquement, la golden image pourra être produite à l’issue des tests d’acceptation (FAT/SAT) lors de la mise en place d’une nouvelle usine.
Cette approche est préférable pour les nouveaux postes à mettre en production. En partant d’une machine vierge où l’on installe l’ensemble des logiciels nécessaires au métier, on est assuré qu’aucune application illégitime n’est présente sur la machine. Il est alors possible d’utiliser les outils fournis par Microsoft afin de scanner la machine et générer automatiquement une liste blanche autorisant l’ensemble des applications présentes sur la machine.
Limites du contrôle d’application
Il est important de prendre en compte les limites de ces solutions, qui ne sont pas infaillibles. Par nature, les actions d’une application autorisée à être exécutée ne sont plus surveillées, l’application peut elle-même exécuter du code ou lancer d’autres programmes. Par conséquent, si un attaquant venait à découvrir une vulnérabilité sur une application autorisée par la liste blanche, le contrôle d’application n’empêcherait pas son exploitation qui permettrait d’influer sur le procédé industriel, mais cela empêchera l’exécution de programmes malveillants tels que des ransomware.
Il existe ainsi plusieurs manières de contourner le contrôle d’application en utilisant des programmes présents de base dans Windows. C’est notamment le cas de mshta.exe qui permet d’exécuter des applications HTML autonomes (.hta) qui sont capables d’exécuter du code sur une machine. C’est pourquoi Microsoft maintient en permanence une liste d’applications présentes de base dans Windows ou signées par Microsoft à bloquer afin de durcir le contrôle d’application.
Le même principe s’applique aux programmes métier. Il revient aux industriels de faire auditer leurs applications afin de s’assurer qu’aucune vulnérabilité pouvant permettre la compromission du poste ne soit présente.
Contrôle d’application sous Windows : WDAC ou AppLocker ?
Finalement, les deux solutions sont très similaires et compatibles avec les deux modes de déploiement présentés précédemment, il reste donc à choisir entre les deux.
Lorsque possible, il est préférable de choisir WDAC : sa force se trouve dans sa capacité de contrôle global et ses différentes fonctionnalités. En effet, AppLocker ne peut contrôler que les programmes exécutés par l’utilisateur, tandis que WDAC peut aussi contrôler les programmes exécutés par Windows tels que les pilotes.
De plus, WDAC intègre des fonctionnalités supplémentaires telles que des protections contre les élévations de privilèges ou encore la vérification automatique des accès utilisateur sur les règles de chemin. Microsoft continue également de supporter la solution et de l’améliorer en ajoutant de nouvelles fonctionnalités, tandis qu’AppLocker ne reçoit que des mises à jour.
AppLocker quant à lui est généralement plus simple d’utilisation que WDAC et permet de différencier l’application des règles selon les utilisateurs de la machine alors que les règles de WDAC s’appliquent à toute la machine sans distinction.
Cependant, WDAC n’est disponible qu’à partir de Windows 10. Ainsi, sur les machines utilisant Windows 7, encore très présentes sur les réseaux industriels, AppLocker est la seule solution native disponible, qui est donc à utiliser. Sur Windows 10 et supérieur, WDAC est la meilleure solution de contrôle d’application et est à préférer.
En complément, AppLocker peut être utilisé en parallèle de WDAC s’il y a besoin de différencier les règles selon les utilisateurs. WDAC devra alors être implémenté au niveau le plus restrictif possible, puis AppLocker peut être utilisé pour affiner les restrictions.
