Notre solution globale pour les incidents de sécurité et les erreurs de fonctionnement

En commençant avec le tableau de bord des alertes GridOps, nous allons étudier une alerte qui a été signalée par le capteur de l’IDS StationGuard situé au niveau du poste « Munich North ».

Le tableau de bord des alertes GridOps fait partie intégrante de notre solution StationGuard. Sa fonction consiste à résumer ce qui s’est exactement passé dans votre système. 
 
Nous utilisons la vue au niveau du capteur pour étudier de manière plus approfondie l’alerte en question et son environnement de réseau.
 
Dans le tableau de bord, vous pouvez passer de la vue d’ensemble de votre réseau à celle du réseau de votre centrale, poste ou centre de téléconduite. Cela vous donnera une image claire d’une alerte spécifique.
 
Chaque alerte est contextualisée pour vous aider à comprendre la nature de l’événement et vous permettre de maîtriser l’incident.
 
L’IDS StationGuard a détecté une activité anormale et l’a signalée. L’IHM a envoyé un trafic réseau « Socks » inattendu à un serveur de base de données Historian externe via le routeur dans le poste. Du point de vue du poste, nous voyons la communication entre l’IHM et le routeur vers le réseau étendu (WAN). La base de données Historian se trouve derrière le routeur. De ce point de vue, c’est donc le routeur qui est l’acteur.
 
Vous pouvez étudier les problèmes de sécurité et de fonctionnement en temps réel en visualisant le tableau de bord du capteur de l’IDS au niveau du réseau, ainsi que notre visualisation unique du réseau, utile pour les professionnels de l’informatique et des OT.
 
Dans le journal de bord, les détails du message fournissent des informations supplémentaires, par exemple, sur le ou les appareils concernés, les adresses MAC/IP, les applications utilisés, les protocoles, etc. 
 
Remarque : il est assez courant d’avoir une connexion entre l’IHM et une base de données Historian externe. Dans ce système, cette connexion est basée sur MySQL et, par conséquent, une connexion MySQL a été autorisée pour l’IHM. Or, cette autorisation n’a pas été respectée puisque la communication a changé pour devenir une connexion Socks utilisant les mêmes numéros de port. Ce problème peut être dû à une application malveillante sur l’IHM et/ou sur la base de données Historian externe. 
Chaque fois que StationGuard affiche des informations sur un acteur (routeur) ou une victime (IHM) dans une alerte, il indique le nom actuel de l’appareil et la couche OSI identifiée la plus élevée est affichée dans le message d’alerte. Ici, c’est l’application « Socks » qui a été identifiée. « Socks » est une application de proxy utilisée pour rediriger la communication vers un appareil tiers pour faciliter la communication via un pare-feu. Elle peut être utile dans l’environnement informatique, mais elle est aussi utilisée par des pirates pour créer un tunnel et exfiltrer des données ou établir une connexion à un serveur de commande et de contrôle. Il est probable que cette technique ait également été utilisée dans le cadre de la cyberattaque en Ukraine « Industroyer » en 2016.

Chaque alerte fournit l’heure approximative de l’événement et de la dernière mise à jour avec des informations supplémentaires sur l’activité. Ainsi, le dernier horodatage reflète généralement la durée de l’activité. Celle-ci peut aller de quelques microsecondes pour la communication entre les appareils à des dizaines de secondes pour, par exemple, les commandes de l’organe de coupure.
 
L’alerte s’est déclenchée dans notre système le 10/05/2022 à 19:43:01.607 décalage UTC +03:00. 
 
Bien souvent, les alertes se déclenchent lorsque les techniciens sont présents sur le site et effectuent des travaux de maintenance ou des tests de routine. Les détails indiquent également si une alerte a été détectée durant un fonctionnement normal ou durant la maintenance.
 
Ici, l’activité a eu lieu durant un fonctionnement normal. Aucune équipe de techniciens n’était présente sur le site lorsqu’elle s’est produite. Ainsi, « Survenu pendant la maintenance » est défini sur « Non ». 

GridOps nous fournit notamment un tableau de bord d’inventaire des équipements qui maximise la visibilité sur le réseau. Le diagramme du réseau nous montre que l’acteur et la victime se trouvent tous deux au niveau du contrôle du poste, correspondant au niveau 2 Purdue, tel qu’indiqué dans la mise en correspondance ci-dessous. 

En s’appuyant sur l’inventaire des équipements en temps réel et sur la mise en correspondance de la topologie, chaque alerte affichée sur le tableau de bord des alertes GridOps fournira des informations sur la source de l’événement et le site dans lequel il a eu lieu.

Comme StationGuard utilise une approche de listes d’autorisation pour détecter le trafic suspect ou interdit, nous avons initialement défini et approuvé chaque communication par tous les appareils dans le poste.
 
Ces informations peuvent être importées dans StationGuard, soit à partir de la description de la configuration de poste (SCD) CEI 61850 que vous pouvez exporter à partir d’outils d’ingénierie, soit à partir de feuilles de calcul qui documentent l’ingénierie du réseau.
 
L’alerte nous indique que le trafic n’est pas approuvé. On trouve un acteur interne associé à l’incident. L’adresse IP de l’acteur est 192.168.1.123 et l’adresse IP de la cible est 192.168.1.200. 
 
Pour permettre une communication efficace entre les responsables de la sécurité et les techniciens de protection et SCADA, GridOps affiche les noms techniques de chaque équipement, plutôt que de simples adresses IP. Ces noms techniques peuvent être importés à partir de fichiers techniques et de tableurs.
 
Chaque alerte déclenchée par StationGuard met en évidence les entités qui ont causé ou contribué à l’événement, le type d’équipement impliqué, l’identité de l’acteur et les personnes identifiées comme la ou les cibles.
 
Nous pouvons à présent facilement lire le niveau de tension, la cellule, et les noms d’équipement impliqués dans l’événement. 

Nous découvrons que le pirate a essayé d’établir une connexion proxy Socks sur le même port utilisé pour la connexion MySQL (port TCP 3306). 
 
Chaque alerte déclenchée par StationGuard donne un aperçu de la nature de l’action, de la manière dont l’activité a été réalisée et de ce que l’acteur a fait pour la provoquer. Un incident est causé au minimum par une action, mais la plupart comprennent plusieurs activités.

Certaines questions demeurent : 
•            Pourquoi l’IDS a-t-il déclenché une alerte ici ?
•            Quelles autorisations de communication ou politiques n’ont pas été respectées ? Pourquoi les autorisations de communication ont-elles été définies de cette manière ?
•            Pourquoi ne s’agissait-il pas d’une communication légitime de l’appareil source ?

StationGuard visualise les communications autorisées ; tout le reste est interdit par défaut. Nous pouvons voir qu’une connexion est autorisée entre l’IHM et le serveur de base de données Historian via le routeur. De plus, l’application « MySQL » a été autorisée pour cette connexion, l’alerte s’est produite car il ne s’agit plus de MySQL.
 
Finalement, l’aide de StationGuard nous indique les problèmes possibles qui ont causé l’incident. Elle nous fournit un guide détaillé pour répondre à toutes les questions susmentionnées concernant la raison de l’incident. L’alerte est notre point de départ pour l’analyse. Sur ce point, ce qui nous intéresse le plus, ce sont les questions suivantes :

Q : S’agit-il d’une connexion différente à un service sur un nouveau numéro de port (côté serveur) ou l’application de cette même connexion a-t-elle changé ? 
R : Nous constatons que c’est la seconde option. Le numéro de port de la destination était le même, mais la couche d’application est passée de MySQL à Socks. Cette activité semble suspecte.
Q : Tous les appareils correspondants ont-ils les rôles corrects qui leur sont attribués ? Y-a-t-il une fonction de cet appareil qui n’était pas utilisée jusqu’à présent ? 
R : Cette question nécessite des connaissances en matière d’OT concernant l’appareil et son objectif. Les techniciens OT concernés ont confirmé qu’aucune connexion sortante n’est attendue de l’IHM, à l’exception d’une connexion à la base de données.

On peut donc soupçonner que le comportement pourrait être causé par un logiciel malveillant sur l’IHM. StationGuard enregistre une capture réseau de chaque événement. Nous recueillons cette preuve et contactons le fournisseur de l’IHM. 
 
Le contexte de cette alerte vous aide à comprendre pourquoi l’incident a été possible en premier lieu. De telles informations sont utiles à plusieurs niveaux ; par exemple, pour évaluer les failles des contrôles de sécurité et évaluer les vulnérabilités des équipements et identifier les stratégies d’atténuation.  

Dans l’exemple fictif ci-dessus, nous avons documenté une chaîne de réponse possible depuis la détection d’un comportement suspect par une IHM dans un poste jusqu’au traçage d’une infection par un logiciel malveillant sur cet appareil IHM. Il illustre la manière dont StationGuard, en combinaison avec GridOps, permet la détection, le traçage, la visualisation et l’analyse des comportements suspects dans les réseaux OT électriques dans une seule application. Lorsqu’il s’agit de répondre aux questions que l’on se pose en matière d’incidents de sécurité, notre interface unifiée permet une collaboration efficace entre les responsables informatiques et les experts en OT, afin que capacités combinées puissent être pleinement exploitées.