IDS : fonctionnement classique d’un système de détection d’intrusion industriel

Introduction

Les environnements de production industriels, historiquement isolés physiquement d’internet, se retrouvent de plus en plus connectés et vulnérables à des attaques. Ceci est dû à la démocratisation des objets IoT dans ces environnements, mais aussi car une connexion à Internet rend possible la maintenance ou la supervision à distance. Ces environnements sont très vulnérables n’étant pas ou peu protégés par design, il a rapidement été nécessaire d’ajouter des couches de sécurité sur l’existant afin de limiter le risque au maximum.

En effet, vu que les processus industriels sont prévus pour des temps de fonctionnement conséquents, il est inenvisageable de fabriquer de nouveaux systèmes qui seraient au maximum sécurisés nativement. La sécurité doit donc venir d’une surcouche qui ne modifiera pas le comportement de la couche sous-jacente, et qui amènera une sécurité maximale dans ce contexte. Il a donc été imaginé des solutions logicielles et matérielles afin de résoudre ce problème grandissant, ces solutions sont regroupées sous le terme d’IDS.

Un IDS (Intrusion Detection System) est une brique logicielle et/ou matérielle qui vise à détecter des comportements inhabituels d’un système cyber-physique sous-jacent sans modifier le comportement de celui-ci ¹. Ces comportements inhabituels peuvent provenir d’une panne matérielle ou d’une attaque. Nous vous proposons dans cet article de mieux comprendre les mécanismes de détection utilisés par les IDS courants.

Les systèmes de détection IDS comprennent deux parties principales et complémentaires qui seront détaillées dans la suite de l’article :

• L’analyse passive du réseau
• L’analyse comportementale du processus physique

Cet article concerne les IDS réseau (NIDS) basés sur la détection d’anomalie² par rapport à un modèle de comportement normal, contrairement aux IDS basés sur la détection de signatures². Ces deux approches peuvent être complémentaires, mais nous ne détaillerons ici que la première.

Analyse passive du réseau

Récupération des flux de l’IDS

Les flux réseau sont récupérés par des sondes, qui sont connectées au port miroir d’un switch ou d’un routeur à surveiller. Les sondes peuvent faire un certain travail d’analyse sur les flux et n’envoyer que les métadonnées au serveur chargé de centraliser et d’analyser les flux, ou alors envoyer les flux bruts au serveur, qui sera donc chargé de l’analyse des paquets. Dans les deux cas, les informations extraites sont principalement les suivantes :

• Adresses IP source et destination
• Protocole IP utilisé (Ou Ethernet si le paquet n’est pas un paquet IP)
• Ports source et destination
• Adresses MAC source et destination
• Informations provenant de la DPI (Deep Packet Inspection) pour récupérer la couche applicative et plus d’informations en fonction du protocole applicatif utilisé.

Par exemple, pour Modbus, une DPI va permettre de récupérer beaucoup d’informations :

• Fonction Modbus utilisée (read/write...)
• Le registre concerné par la requête
• La valeur écrite ou récupérée

Le schéma suivant représente le fonctionnement de plusieurs sondes sur un sous réseau surveillé par un IDS.

À noter qu’il existe certains IDS dont le fonctionnement n’est pas centralisé sur un IDS principal. Dans ce cas, chaque sonde récupère les flux et les analyse comme le ferait l’IDS principal, sans avoir de vision plus globale du réseau.

Apprentissage et analyse des flux

Apprentissage

Dans un premier temps, l’IDS n’a pas de modèle sur lequel s’appuyer pour déterminer si un comportement est inhabituel ou non. Il y a donc une plus ou moins longue phase d’apprentissage, durant laquelle le système va stocker toutes les trames réseau qu’il reçoit, afin de créer un modèle du fonctionnement du réseau.

Il est important que cette phase d’apprentissage soit la plus exhaustive possible, pour limiter le nombre de faux positifs durant la phase de détection. L’apprentissage lui-même représente simplement la création d’une cartographie du sous réseau, que la plupart des IDS modernes proposent d’afficher graphiquement pour avoir une meilleure représentation des composants surveillés.

Cette cartographie n’est qu’une compilation des liens IP et applicatifs autorisés entre toutes les machines détectées. La figure ci-après montre un exemple d’une cartographie simpliste qui aurait pu être créée par un IDS :

Il est important de noter qu’il s’agit d’une cartographie logique et non physique, donc il est normal que les switch et routeurs n’y apparaissent pas.

Quand tous les comportements ont été appris (Mise à jour du programme d’un PLC, fonctionnement courant...), alors le système peut passer dans une phase de détection. Le modèle ainsi créé représente concrètement tous les liens IP et applicatifs entre les différentes machines du sous réseau. En se basant sur ce modèle, il sera alors relativement simple de détecter un comportement inhabituel, comme par exemple une machine qui se met à interagir avec une machine avec laquelle elle n’avait jamais interagi auparavant, ou avec un protocole applicatif non autorisé.

Dans l’exemple précédent, si l’un des postes utilisateur se met à communiquer avec le serveur via SSH, ou directement avec la base de données, alors ce comportement sera considéré comme anormal.

Dans le cas de flux chiffrés, ce qui est relativement rare dans un environnement industriel, alors seules les métadonnées du paquet chiffré peuvent être appris par l’IDS, ce qui limite son champ d’apprentissage et de détection, vu que la DPI est impossible.

Détection et remontée d’alertes au SIEM ou au SCADA

Une fois la phase d’apprentissage terminée, l’IDS est prêt à commencer la détection. L’IDS fonctionne exactement de la même manière, sauf qu’au lieu de mettre à jour sa cartographie du réseau à chaque nouveau comportement, l’IDS générera une alerte qui sera envoyée à un SIEM ou au SCADA pour que l’opérateur puisse la traiter. Ce dernier aura donc les cartes en main pour juger s’il s’agit en effet d’un comportement non souhaité et agir en conséquence, ou si le comportement est normal, ce qui causera donc une mise à jour du modèle de l’IDS pour y ajouter ce comportement réseau.

Ce système de détection fonctionne aussi bien pour un réseau d’entreprise classique composé uniquement de postes utilisateurs et de serveurs. Mais il est particulièrement adapté à un environnement industriel car dans ce dernier, les communications sont très souvent répétitives et prédictives ; alors qu’un environnement classique IT sera plus susceptible de générer des faux positifs, et il est plus difficile de les différencier des vrais. Cela vient du fait que les réseaux IT sont souvent composés de postes utilisateurs et que ceux-ci ont un comportement moins prédictible que des automates programmés pour une tâche précise. De plus, les communications dans un réseau IT classique sont très souvent chiffrées, ce qui supprime l’intérêt de la DPI, très utile dans un réseau OT.

Il existe cependant une génération plus avancée d’IDS qui ne fonctionne qu’avec les réseaux OT, car leur but est d’apprendre et prédire la dynamique du processus physique en se basant sur les variables que ce dernier utilise, et c’est ce que nous allons voir dans la suite de cet article.

Analyse du comportement du processus physique

Variables process

Les variables process sont l’ensemble des variables utilisées par un système cyber-physique pour son bon fonctionnement. Dans le cas de Modbus par exemple, il s’agit souvent de la valeur de tous les registres Modbus utiles. Il existe notamment deux types de variables process :

• Les entrées
• Les sorties

Les entrées sont prises en compte par le ou les PLC afin de déterminer les sorties en fonction de sa programmation. Les entrées proviennent de différents capteurs (température, niveau de remplissage, …) et les sorties représentent des actions physiques en cours (Mise en route d’un moteur, actionneur...).

Le schéma suivant représente ce processus où la sortie Xout dépend des entrées X1 et X2.

Entrée X1
PLC
Entrée X2
Ecriture de Xout

Les valeurs sont donc lues sur le serveur Modbus (ou autre), et envoyées à l’IDS pour avoir un snapshot de l’état du processus à un moment donné. Il s’agit donc de surveillance active, vu que l’IDS va faire des requêtes auprès du serveur de données.

Il est aussi possible de reconstruire l’état courant du serveur de données dans l’IDS en écoutant passivement le réseau, et en mettant à jour la copie locale des données à chaque fois qu’une trame réseau fait de même, dans ce cas, l’IDS est complètement passif.

Apprentissage et détection

Comme ces variables process sont le plus souvent numériques, il est possible de voir le schéma précédent comme la formule mathématique suivante :

PLC(X1,X2)=Xout \\PLC(X1,X2)=Xout PLC(X1,X2)=Xout  

Le but de l’apprentissage dans ce cas va donc être de comprendre le comportement de la fonction PLC afin de pouvoir prédire par la suite si la sortie Xout calculée correspond bien à ce qu’elle devrait être en fonction des entrées. Le modèle ainsi créé peut donc permettre de valider les sorties par rapport aux entrées et donc vérifier qu’il n’y a pas de dérive progressive du système vers un état critique.

Appliqué à des cas plus compliqués que cet exemple, l’apprentissage peut être long et nécessiter un nombre extrêmement conséquent de snapshot de l’état du processus pour obtenir un modèle de fonctionnement fiable. Cet apprentissage peut être fait via un ensemble d’algorithmes de machine learning, tous donnant des résultats différents au niveau de la détection.³

Une fois l’apprentissage terminé, la phase de détection débute. L’IDS va lire les entrées, calculer en fonction du modèle appris les sorties supposées et les comparer aux sorties réelles. S’il y a une différence trop importante, alors une alerte est levée. Ce genre de mécanisme peut permettre de détecter une défaillance physique dans le processus, mais aussi des attaques visant à modifier le comportement d’un PLC en modifiant sa programmation afin de créer une dérive fatale du système.

Conclusion

Un IDS utilisant ces deux mécanismes de détection permettrait une surveillance avancée du système cyber-physique, car la plupart des attaques sont détectables par l’un ou l’autre de ces mécanismes. Par exemple, les attaques sur le réseau de type Man in The Middle visant à usurper l’identité du SCADA pour envoyer des ordres malveillants au PLC ou pour causer un déni de service seraient détectées par la surveillance basique des trames, alors qu’une attaque où un opérateur se brancherait physiquement sur un PLC dans le but de modifier son comportement serait détectée par l’analyse comportementale.

La propagation d’un ransomware serait aussi rapidement détectée, vu que ce dernier provoque des communications réseau inédites.

En revanche, ce système de détection par port mirroring ne permet pas d’agir directement en cas de détection d’un comportement inhabituel au sein du système industriel, car l’IDS ne fait que travailler sur une copie des données pour générer les alertes. Pour résoudre ce problème, il faudrait utiliser des IPS (Intrusion Prevention System) qui viendraient se greffer directement sur les communications réelles et qui jugerait à la manière d’un pare-feu quelle trame est légitime ou non. Mais les technologies ne sont pas encore assez mûres pour qu’un tel système soit mis en place et puisse se passer d’une vision humaine pour la gestion des faux positifs.