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

De nombreuses organisations industrielles considèrent toujours la cybersécurité des systèmes informatiques (IT) et les technologies opérationnelles (OT) comme un problème unique, souvent traité de manière isolée. S’il est vrai que les départements informatiques des compagnies d’électricité varient d’un point de vue structurel et fonctionnel entre les départements des protections et ceux du SCADA, le besoin de convergence devient de plus en plus important. Dans cette nouvelle ère de cybermenaces croissantes et omniprésentes, le changement structurel ne peut plus être perçu comme une éventualité ou une option. Bien au contraire : il est nécessaire que la convergence entre les deux domaines devienne un objectif principal.

Pour être efficace, la sécurité doit intégrer les professionnels de la cybersécurité, les techniciens OT et le personnel du support grâce à un apprentissage partagé et à une plate-forme de terminologie commune.  

 

Notre solution StationGuard 

L’équipe OMICRON a adopté les processus et priorités spécifiques à un environnement OT et les a combinés à la capacité à identifier, intégrer et corréler les données sur les menaces et les problèmes de fonctionnement afin de proposer un système de gestion centralisé. Ce système de gestion est conçu pour répondre aux exigences des techniciens en informatique et en électricité. 

 

« Il est temps d’amener les équipes IT et OT sur un terrain qui leur est familier. »  

- Amro Mohamed, Spécialiste régional des ventes en cybersécurité


Notre système de détection d’intrusion (IDS) StationGuard détecte tout trafic interdit ou potentiellement dangereux dans le système de votre centre de téléconduite, votre poste et votre centrale électrique. Les fichiers de configuration, par exemple, peuvent être importés pour créer automatiquement des autorisations de communication et attribuer des rôles aux appareils sur la base de leur fonction. Ensuite, StationGuard déclenche une alerte qui indique la catégorie, la source et la cible, une brève description, ainsi que le moment approximatif où l’événement s’est produit. 

Pour mieux comprendre les alertes d’événements, il faut que les responsables de la sécurité et les techniciens en électricité collaborent. Seuls les techniciens responsables du poste, de la centrale ou du centre de téléconduite savent ce que chaque appareil est censé faire ou ne pas faire. La principale différence entre notre solution et les autres réside dans sa capacité à remonter à la cause réelle du problème dans le réseau électrique. Ainsi, les techniciens de protection et les spécialistes en informatique se comprennent mutuellement lorsqu’ils parlent du problème et des appareils concernés ; en bref, la communication devient plus efficace.

Suivez ce lien pour en savoir plus sur tous les avantages de notre solution StationGuard et ses fonctionnalités.

STATIONGUARD

Étudions les caractéristiques uniques de notre solution StationGuard. Prenons à titre d’exemple le scénario d’un serveur de base de données Historian piraté qui communique avec un logiciel malveillant dans une centrale électrique ou un poste. 

 

Notre solution peut répondre aux questions suivantes relatives à chaque incident :

Quel incident de sécurité s’est produit dans votre système ?

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.

Quand l’incident de sécurité a-t-il eu lieu ?

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 ». 

Où sur le réseau l’événement est-il survenu ?

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.

Qui a été impliqué dans l’événement ?

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. 

Comment s’est déroulé l’incident de sécurité ?

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.

Pourquoi l’IDS a-t-il déclenché une alerte en premier lieu ?

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.

 

Captures d'écran connexes

Que s’est-il passé – Tableau de bord des alertes GridOps
Que s’est-il passé – Vue du diagramme du réseau au niveau du capteur montrant le réseau du poste
Quand cela s’est-il passé – Détails de l’alerte
Où cela s’est-il passé – Mise en correspondance des diagrammes du réseau du poste pour l’architecture de référence Purdue
Qui a été impliqué – Détails sur les appareils source et cible impliqués dans l’alerte
Comment cela s’est-il passé – Détails sur l’application détectée et numéros de port de cette connexion
Pourquoi cela s’est-il passé – Autorisation de communication sur la liste des autorisations pour la connexion à la base de données

Mettez votre StationGuard à niveau avec notre composant GridOps 

Le composant GridOps pour StationGuard constitue la solution centrale pour offrir une vue d’ensemble sur de nombreuses tâches opérationnelles dans le réseau électrique numérique, en commençant par les opérations de sécurité et les fonctions d’inventaire des équipements dans la première version. De l’analyse des alertes de sécurité à l’inventaire des équipements en passant par la gestion des vulnérabilités, GridOps rassemble les techniciens de protection et les spécialistes en informatique dans une application unique. Il permet aux responsables de la sécurité informatique de voir la cybersécurité du réseau renforcée par des connaissances en matière d’OT et permet aux techniciens OT de participer aux opérations de cybersécurité du réseau dans un environnement qui leur est familier. 

Principales fonctions de GridOps 
GridOps offre des fonctions puissantes qui facilitent les opérations de sécurité des réseaux électriques. Vous pouvez... 

  • gérer de manière centralisée tous les capteurs d’IDS StationGuard et voir l’état actuel des menaces, 
  • utiliser des analyses et des statistiques d’alerte avancées, 
  • gérer votre inventaire des équipements dans sa globalité et être alerté des équipements détectés, 
  • bénéficier d’une détection des vulnérabilités et d’un soutien précieux dans vos flux de gestion des risques, et 
  • obtenir un aperçu plus approfondi grâce aux rapports de sécurité et aux informations sur les équipements. 
  •  

 
Inventaire global des équipements  
Il vous permet de suivre facilement tous les équipements détectés et les changements de configuration et de maintenir à jour la liste des équipements publiée par les capteurs StationGuard sur le réseau. 

Tableau de bord des alertes  
Bénéficiez d’une vue d’ensemble de l’état des alertes sur tous les sites et visualisez votre état de sécurité.  

Vue du réseau au niveau du capteur  
Naviguez d’un aperçu au niveau du réseau à une vue spécifique du réseau du centre de téléconduite, de la centrale électrique, ou du poste pour obtenir une vue d’ensemble des alertes.  

Cliquez sur le lien et découvrez les atouts de notre composant GridOps, qui comprend deux avantages supplémentaires : l’inventaire des équipements et la gestion des vulnérabilités.

Découvrez d'autres reportages sur OMICRON

Ecoutez nos podcasts

27 juillet 2022

Predicting Weather Conditions to Mitigate the Risk of Wildfires

with Renny Vandewege & Denton McGregor

Episode 37 - Energy Talks

12 juillet 2022

A New Protection Testing Approach for Greater Accuracy and Efficiency

with Michael Albert

Episode 36 - Energy Talks

30 juin 2022

The Fight for Technical Talent in the Power Industry

with Cordula Böhmer & Ruben Fuentes

Episode 35 - Energy Talks

Vous utilisez une ancienne version de votre navigateur.
Merci de mettre à jour votre navigateur ou d’utiliser un autre navigateur pour afficher cette page correctement.
×