Éléments système

Assets

Les assets représentent les composants matériels de votre réseau, tels que les contrôleurs, les stations d'ingénierie, les serveurs, etc. Les fonctions automatisées de découverte, de classification et de gestion des assets de OT Security fournissent un inventaire précis par le biais d'un suivi continu de toutes les modifications apportées aux appareils. Cela simplifie le maintien de la continuité, de la fiabilité et de la sécurité opérationnelles. Cela joue également un rôle clé dans la planification des projets de maintenance, la priorisation des mises à niveau, les déploiements de correctifs, la réponse aux incidents et les efforts d'atténuation.

Évaluation des risques

OT Security utilise des algorithmes sophistiqués pour évaluer le degré de risque posé à chaque asset du réseau. Un score de risque (de 0 à 100) est attribué à chaque asset du réseau. Le score de risque est basé sur les facteurs suivants :

  • Événements – Événements qui se sont produits sur le réseau et qui ont affecté l'appareil (pondérés en fonction de la sévérité de l'événement et de la date à laquelle l'événement s'est produit).

    • Remarque : les événements sont pondérés en fonction de leur actualité, de sorte que les événements les plus récents ont un impact plus important sur le score de risque que les événements plus anciens.

  • Vulnérabilités – Désigne les CVE qui affectent les assets de votre réseau, ainsi que d'autres menaces identifiées sur le réseau (par exemple, systèmes d'exploitation obsolètes, utilisation de protocoles vulnérables, ports ouverts vulnérables, etc.). OT Security les détecte comme des correspondances de plug-in sur vos assets.

  • Criticité de l'asset – Mesure de l'importance de l'appareil pour le bon fonctionnement du système.

    Remarque : le score de risque des contrôleurs PLC connectés à un fond de panier est affecté par le score de risque des autres modules qui partagent ce fond de panier.

Politiques et événements

Les politiques définissent des types spécifiques d'événements suspects, non autorisés, anormaux ou autrement remarquables qui se produisent dans le réseau. Lorsqu'un événement se produit et répond à toutes les conditions de la définition d'une politique, OT Security génère un événement. OT Security consigne l'événement et envoie des notifications conformément aux Actions de politique configurées pour la politique.

Il existe deux types d'événements liés aux politiques :

  • Détection basée sur des politiques – Déclenche des événements lorsque les conditions précises de la politique, telles que définies par une série de descripteurs d'événements, sont réunies.

  • Détection d'anomalies – Déclenche des événements lorsqu'une activité anormale ou suspecte est identifiée sur le réseau.

Le système comporte un ensemble de politiques prédéfinies (prêtes à l'emploi). De plus, le système offre la possibilité de modifier les politiques prédéfinies ou d'établir de nouvelles politiques personnalisées.

Détection basée sur des politiques

Pour la détection basée sur des politiques, vous devez configurer les conditions spécifiques pour les événements du système qui déclencheront des notifications d'événement. Les événements basés sur des politiques ne sont déclenchés que lorsque les conditions précises de la politique sont réunies. Cela garantit l'absence de faux positifs, car le système signale les événements réels qui se produisent dans le réseau ICS, tout en fournissant des informations détaillées significatives sur « qui », « quoi », « quand », « où » et « comment ». Les politiques peuvent être basées sur divers types d'événements et de descripteurs.

Voici quelques exemples de configurations de politique possibles :

  • Activité anormale ou non autorisée du plan de contrôle ICS (ingénierie) – Une interface homme-machine (IHM) ne doit pas interroger la version du firmware d'un contrôleur (peut indiquer une reconnaissance). De même, un contrôleur ne doit pas être programmé pendant les heures de fonctionnement (peut indiquer une activité non autorisée et potentiellement malveillante).

  • Modification du code du contrôleur – Une modification de la logique du contrôleur a été identifiée (Déviation par rapport à l'instantané).

  • Communications réseau anormales ou non autorisées – Un protocole de communication non autorisé a été utilisé entre deux assets du réseau, ou une communication a eu lieu entre deux assets qui n'ont jamais communiqué auparavant.

  • Modifications anormales ou non autorisées de l'inventaire des assets – Un nouvel asset a été découvert, ou un asset a cessé de communiquer sur le réseau.

  • Modifications anormales ou non autorisées des propriétés de l'asset – Le firmware ou l'état de l'asset a changé.

  • Écritures de points de consigne anormales – Des événements sont générés lorsque des modifications sont apportées à des paramètres spécifiques. Vous pouvez définir les plages autorisées pour un paramètre et générer des événements en cas de déviation par rapport à cette plage.

Détection des anomalies

Les politiques de détection des anomalies identifient les comportements suspects dans le réseau grâce aux fonctions intégrées au système qui détectent les écarts par rapport à une activité dite « normale ». Les politiques de détection d'anomalies suivantes sont disponibles :

  • Déviations par rapport au trafic réseau de référence – L'utilisateur définit un trafic réseau « normal » de référence, basé sur la carte du trafic pendant une plage temporelle donnée. Tout écart génère alors une alerte. La référence peut être mise à jour à tout moment.

  • Pic de trafic réseau – Une augmentation spectaculaire du volume du trafic réseau ou du nombre de communications est détectée.

  • Activité potentielle de reconnaissance du réseau/cyber-attaque – Des événements sont générés pour les activités au sein du réseau indiquant une reconnaissance ou une cyber-attaque, telles que les conflits IP, les scans de port TCP et les scans ARP.

Catégories de politiques

Les politiques sont organisées selon les catégories suivantes :

  • Politiques d'événements de configuration – Ces politiques concernent des activités se déroulant sur le réseau. Il existe deux sous-catégories de politiques d'événements de configuration :

    • Validation du contrôleur – Ces politiques concernent les changements ayant lieu au sein des contrôleurs du réseau. Cela peut impliquer des modifications de l'état d'un contrôleur, ainsi que des modifications du firmware, des propriétés des assets ou des blocs de code. Les politiques peuvent être limitées à des planifications spécifiques (par exemple, la mise à niveau du firmware pendant une journée de travail) et/ou à un ou plusieurs contrôleurs spécifiques.

    • Activités du contrôleur – Ces politiques concernent des commandes d'ingénierie spécifiques qui ont un impact sur l'état et la configuration des contrôleurs. Il est possible de définir des activités spécifiques qui génèrent systématiquement des événements ou de désigner un ensemble de critères pour la génération d'événements. Par exemple, si certaines activités sont effectuées à certains moments et/ou sur certains contrôleurs. La création d'une liste de blocage (ou liste rouge) et d'une liste d'autorisations (liste verte) pour les assets, les activités et les calendriers est prise en charge.

  • Politiques d'événements réseau – Ces politiques concernent les assets du réseau et les flux de communication entre les assets. Cela inclut les assets qui ont été ajoutés ou supprimés du réseau. Cela inclut également les modèles de trafic jugés anormaux pour le réseau, ou signalés comme particulièrement préoccupants. Par exemple, si une station d'ingénierie communique avec un contrôleur à l'aide d'un protocole non pré-configuré (par exemple, des protocoles utilisés par des contrôleurs fabriqués par un fournisseur spécifique), un événement est déclenché. Ces politiques peuvent être limitées à des horaires et/ou à des assets spécifiques. Les protocoles spécifiques aux fournisseurs sont organisés par fournisseur pour plus de commodité, tandis que n'importe quel protocole peut être utilisé dans une définition de politique.

  • Politiques d'événement SCADA – Ces politiques détectent les changements dans les valeurs de point de consigne qui peuvent nuire au processus industriel. Ces changements peuvent résulter d'une cyber-attaque ou d'une erreur humaine.

  • Politiques de détection des menaces réseau – Ces politiques utilisent la détection des menaces OT et IT basée sur les signatures pour identifier le trafic réseau qui indique des menaces d'intrusion. La détection est basée sur des règles cataloguées dans le moteur de détection de menaces Suricata.

Groupes

Les groupes sont un aspect essentiel de la définition des politiques dans OT Security. Lors de la configuration d'une politique, chacun des paramètres s'applique à un groupe et non à des entités individuelles. Cela simplifie considérablement le processus de configuration de la politique.

Événements

Lorsqu'un événement qui répond à toutes les conditions d'une politique se produit, un événement est généré dans le système. Tous les événements sont affichés sur l'écran Événements et sont également accessibles via les écrans Inventaire et Politique pertinents. Chaque événement est associé à un niveau de sévérité indiquant son degré de risque. Des notifications peuvent être automatiquement envoyées aux destinataires des e-mails et aux SIEM, comme spécifié dans les Actions de politique de la politique qui a généré l'événement.

Un événement peut être marqué comme résolu par un utilisateur autorisé et un commentaire peut être ajouté.