De la conformité à l’efficacité : un changement de paradigme dans les KPI 

KPI signifie Key Performance Indicator (indicateur clé de performance). Cependant, nous avons tendance à créer des KPI pour suivre la progression par rapport à nos plans, non la performance réelle. Bien que cela soit utile, surveiller uniquement le déploiement ou la couverture (nombre de sites connectés au SOC, déploiement d’EDR sur les machines OT, nombre de sondes enregistrées sur la console de gestion) en dit très peu sur la capacité réelle de votre SOC à détecter un attaquant. 

Alors, quel niveau de confiance avez-vous dans vos outils de détection, vos use cases et vos processus ? La seule façon d’en être sûr est simple : les tester.  

Et le meilleur moyen de les tester est d’organiser des exercices de Purple Team. 

Qu’est-ce que le Purple Teaming en OT ? 

Un exercice de Purple Team est une mission collaborative entre la Red Team (attaquants) et la Blue Team (défenseurs). Contrairement à une évaluation Red Team classique, où les équipe de défense ne sont pas tenus informés, un exercice de Purple Team est un effort conjoint et itératif. 

Cette approche collaborative permet aux deux équipes de : 

• Partager les hypothèses sur l’environnement OT 
• Valider la logique de détection en temps réel 
• Identifier les zones d’ombre 
• Améliorer les playbooks et les pipelines de détection 
• Aligner tout le monde sur un modèle de menace réaliste 

Réaliser un exercice de Purple Team 

Un exercice Purple Team se déroule en trois grandes phases : 

1. Préparation

La phase de préparation est souvent la plus difficile, en particulier en OT, où la sureté de fonctionnement, la disponibilité de l’outil industriel et la dépendance aux fournisseurs doivent être prises en compte. 

Selon la maturité de l’organisation, la préparation peut aller du très simple au très sophistiqué : 

• Tests unitaires 
  Petits tests isolés de règles de détection spécifiques (ex. : « Détecter le code fonction Modbus 90 »). 
• Tests basés sur des scénarios redoutés 
  Construire des scénarios autour des « crown jewels » de l’organisation et des modes de défaillance (ex. : « Téléversement non autorisé d’un programme sur un automate contrôlant un procédé critique »). 
• Tests enrichis par la CTI 
  Intégrer la Threat Intelligence : tester les techniques utilisées par de vrais attaquants ciblant l’OT (ex. TTP de Volt Typhoon, Sandworm, Xenotime ou de groupes ransomware visant les environnements industriels). 

Pour structurer la phase de préparation, deux éléments sont essentiels : 

• Une bonne connaissance de votre environnement OT 
  Planifier un exercice pertinent pour les risques métier et la détection OT, sans impacter le procédé, nécessite une connaissance approfondie du site et de son automatisation. 
• Un mapping sur la matrice MITRE ATT&CK for ICS 
  Mapper vos tests avec la matrice ATT&CK vous donne un langage commun avec les équipes de détection. Cela permet de sélectionner les techniques pertinentes, d’éviter les angles morts et de garantir une couverture sur plusieurs couches : postes opérateurs, automates, IHM … 

2. Jour J (Exécution)

L’exécution est réalisée conjointement : 

• La Red Team lance des actions contrôlées et autorisées 
• La Blue Team surveille les évènements détectés en temps réel 
• Les deux équipes ajustent, documentent et valident les résultats tout au long de l’exercice 

Selon le périmètre et la complexité des tests, une opération Purple Team en milieu industriel peut durer de quelques heures à quelques jours. 

Assurer la reproductibilité des tests avec Caldera 

Pour garantir la répétabilité et la cohérence entre les exercices Purple Team, l’automatisation devient essentielle. Nous utilisons Caldera, un framework open-source de Breach & Attack Simulation (BAS) développé par MITRE pour cela. 

En tant qu’ancien pentester, je n’ai jamais aimé le terme « pentest automatisé », mais les outils BAS sont ce qui se rapproche le plus d’une exécution de stimulis d’attaque répétable et sûre. 

Pourquoi utiliser Caldera plutôt que de réaliser tous les tests manuellement ? 

Caldera permet de : 

• Préparer et valider une liste contrôlée de tests sur une liste contrôlée d’actifs 
• S’assurer que seules des actions autorisées sont exécutées 
• Garantir la reproductibilité entre les environnements 
• Rejouer exactement les mêmes actions pour mesurer les améliorations après des changements de configuration 

Des plugins OT spécifiques existent déjà dans le module Caldera-OT, prenant en charge Modbus, Profinet, DNP3, etc. 

Récemment, Wavestone a publié deux plugins OT supplémentaires : 

• Support du protocole Siemens S7 
• Actions de communication OPC-UA 

Caldera en bref 

L’utilisation de Caldera repose sur quatre notions de base : 

• Abilities : actions techniques atomiques (ex. lecture de coils, écriture de tags, scan d’un automate) 
• Adversaries : collections d’abilities formant un scénario 
• Operations : exécution en temps réel de ces adversaries sur une cible 
• Fact sources : paramètres fournis pour une opération ; on peut ainsi lancer les mêmes opérations sur différents environnements en changeant seulement la source de facts 

La vidéo suivante présente une démonstration de Caldera sur notre maquette ICS : 

3. Débriefing

La majorité de la valeur ajoutée de l’exercice provient du debrief. Les types suivants de KPI peuvent être utilisés : 

• Couverture de détection – quel pourcentage des stimuli exécutés a été détecté ? 
• Qualité des alertes – les alertes étaient-elles exploitables, précises et compréhensibles ? 
• Temps de réaction – combien de temps avant qu’une alerte soit déclenchée puis reconnue ? 
• Efficacité des playbooks – les bonnes actions ont-elles été prises dans les délais attendus ? 

Ces résultats peuvent permettre d’aboutir à : 

• Des règles de détection mises à jour 
• Des playbooks SIEM/SOC améliorés 
• Une meilleure architecture de supervision 
• Du matériel de formation pour les analystes et ingénieurs 

Commencez à tester dès maintenant ! 

Le Purple Teaming apporte une valeur immédiate, quel que soit votre niveau de maturité actuel : 

• Il valide vos outils dans des conditions réelles 
• Il forme vos équipes SOC et OT 
• Il révèle les angles morts tôt dans le programme 
• Il fournit des KPI quantitatifs pour piloter les améliorations de détection 

Et oui, cela est possible dans la plupart des environnements de production, sous les conditions suivantes : 

• Périmètre strictement contrôlé 
• Actions approuvées par les fournisseurs 
• Pas d’exécution de fonctions perturbatrices 
• Implication des équipes opérationnelles et sécurité 
• Surveillance continue du comportement du système pendant les tests 

En bref : commencez petit, restez prudent, et itérez. 

N’attendez pas que votre programme de sécurité OT soit “terminé” pour commencer à en tester l’efficacité ! 

Cet article Purple Teaming pour l’OT : Comment passer de la conformité à la performance ? est apparu en premier sur RiskInsight.

Dans cet article précédent : Quelle détection pour l’OT ?  Situation actuelle & perspectives, nous avons constaté que l’OT, bien que moins touché que l’IT, n’est pas exempt ni immunisée contre les cyberattaques. Toutefois, en raison de la difficulté à mettre à jour les systèmes de contrôle industriels (ICS), les mesures de cybersécurité sont souvent ajoutées après le déploiement. Le monitoring continu est perçu comme un substitut pratique à une protection intégrée dès la conception (cyber-by-design).

En matière d’outillage de monitoring, nous avons observé que 100 % de nos clients disposent d’outils de détection déployés du côté IT. Cependant, seul un tiers étend cette surveillance jusqu’aux couches inférieures de l’environnement industriel :

Il existe une grande variété de sources de détection permettant une surveillance (monitoring) à travers les différents niveaux du modèle Purdue :

• Logs de pare-feu (y compris industriels)
• Logs des protection des endpoints (antivirus, whitelisting d’applications, EPP, EDR, etc.)
• Logs d’authentification et d’accès (par exemple, Active Directory ou authentification locale)
• Logs d’accès distant (par exemple, VPN, serveurs de rebond, bastion)
• Les honeypots et autres
• Sondes de détection et de surveillance réseau (écoute des réseaux industriels)
• Logs des stations blanches (par exemple, bornes USB)
• Logs industriels (provenant des systèmes SCADA, IHM, PLC… lorsqu’ils sont disponibles)

Traditionnellement, peu de ces logs sont collectés et analysés par les solutions SIEM et/ou SOAR, avec ou sans modèles de détection OT spécifiques. Pourtant, ils devraient permettre à l’équipe du SOC de détecter, d’enquêter sur les événements de sécurité et d’y répondre.

Élaborer une stratégie de détection cohérente pour les environnements OT ne nécessite pas de collecter les données de toutes les sources possibles. En réalité, quelques sources bien choisies, correctement configurées, peuvent permettre d’offrir une forte visibilité et de solides capacités de détection. L’essentiel est de se concentrer sur les sources de logs qui sont à la fois pertinentes au regard de l’architecture OT et facile à mettre en place sans perturber les opérations. Prioriser la qualité et la pertinence opérationnelle des sources de détection plutôt que leur quantité permet d’assurer une posture de cybersécurité plus efficace et durable.

Comment tirer le meilleur parti des sources de détection ?

Commencer avec les logs déjà disponibles

Une approche pragmatique et rentable de la détection OT consiste à commencer par exploiter les logs et les modèles de détection déjà disponibles dans l’environnement industriel, en particulier ceux qui sont déjà utilisés pour vos environnements IT. Par exemple, les logs des pares-feux, notamment ceux qui surveillent les périmètres IT/OT, peuvent fournir des informations précieuses sur les schémas de trafic réseau, les violations de segmentation ou les tentatives d’accès distant suspectes. De même, les logs Active Directory (AD) peuvent révéler des comportements utilisateurs anormaux, des échecs d’authentification ou des élévations de privilèges — tous étant des signaux critiques dans les contextes IT et OT. L’exploitation de ces sources existantes permet aux organisations de mettre en place des capacités de détection initiales sans investissement lourd, tout en posant une base solide pour une surveillance plus avancée à l’avenir.

Plutôt que de commencer par le déploiement d’outils de détection complexes spécifiques à l’OT, les organisations devraient construire leurs capacités de détection initiales en utilisant ce qui est déjà déployé, configuré et maîtrisé. Cette approche permet non seulement de réduire les coûts, mais aussi d’accélérer la mise en œuvre sur l’ensemble des sites industriels. L’objectif est d’assurer un niveau de visibilité de base cohérent sur les applications, les systèmes et les infrastructures critiques avant d’approfondir la surveillance.

En commençant par l’existant et en se concentrant sur la couverture plutôt que sur la complexité, les organisations peuvent aborder la détection OT avec rapidité, pertinence et réalisme opérationnel, tout en préparant le terrain pour des capacités plus avancées à l’avenir.

Nous allons maintenant aller plus loin en nous concentrant sur les deux outils de détection les plus déployés et discutés dans les environnements industriels aujourd’hui : les solutions EDR et les sondes de détection réseau.

EDR

Les solutions EDR (Endpoint Detection & Response) offrent une surveillance et une analyse continues des activités des points de terminaison afin de détecter les cybermenaces, d’y enquêter et d’y répondre en temps réel. L’EDR collecte des données détaillées telles que l’exécution des processus, les modifications de fichiers, les connexions réseau et le comportement des utilisateurs. En s’appuyant sur l’analyse comportementale et les renseignements sur les menaces (threat intelligence), les outils EDR peuvent identifier des activités suspectes comme les infections par logiciels malveillants, les mouvements latéraux ou les élévations de privilèges.

Cet outil de détection, largement utilisé dans les environnements IT, est désormais adopté par la majorité de nos clients pour un déploiement au sein de leurs environnements industriels.

Cependant, cela ne signifie pas que 100 % des dispositifs OT sont compatibles avec les solutions EDR. En réalité, la compatibilité des EDR varie considérablement selon la diversité des systèmes industriels et leurs contraintes opérationnelles. Le déploiement de l’EDR est généralement simple aux niveaux supérieurs du modèle Purdue, tels que la Couche 3 et la Couche 3.5, où les systèmes (serveurs et postes de travail) ressemblent à des environnements IT traditionnels. À la Couche 2, l’implémentation exige des tests approfondis et une personnalisation, car les dispositifs et les protocoles sont plus spécialisés et leurs ressources limitées. Enfin, aux niveaux les plus bas (contrôleurs, PLC et équipements de terrain), l’EDR n’est généralement pas viable en raison de leur capacité de traitement limitée, de leurs systèmes d’exploitation propriétaires et de leurs exigences de performance en temps réel. Le déploiement sur de tels dispositifs risque de perturber les processus critiques ou de provoquer l’instabilité du système, et doit donc être évité.

Pour les environnements qui le supportent, l’extension de la couverture EDR permet :

• Répondre à la faible maturité : Commencer par des outils plus simples à mettre en œuvre et nécessitant une maturité moindre.
• Couverture étendue : Se concentrer sur la couverture rapide d’un large éventail de systèmes, de sites et d’applications critiques.
• Exploiter les outils IT : Utiliser des solutions basées sur la IT, comme l’EDR, pour une détection efficace sans nécessiter de lourdes exigences d’infrastructure.

Pour conclure, le déploiement d’agents EDR sur les serveurs et les postes de travail OT devient de plus en plus pertinent et représente une possibilité de gain rapide pour la détection OT, selon les retours de nos clients.

Les Sondes de Détection OT

Une sonde de détection (detection probe) est un équipement, qu’il soit virtuel ou physique, connecté au système d’information afin de le cartographier et de le surveiller. Elle est composée de capteurs distribués à travers le réseau pour collecter des données, et typiquement, d’une console centrale pour agréger, corréler et analyser ces informations.

 Les sondes destinées aux environnements industriels, que nous appellerons ici simplement sondes OT, se caractérisent par leur écoute passive et non invasive sur le réseau, ainsi que par leur compréhension des protocoles et comportements industriels. Toutes ces solutions de sondes fonctionnent sur le même principe : le trafic réseau est collecté via une duplication de flux (SPAN, ERSPAN…) ou un duplicateur physique (Taps, etc.). Les paquets sont inspectés en temps réel pour fournir plusieurs types de données : inventaire et cartographie des flux, gestion des actifs et des vulnérabilités, et enfin, détection des anomalies et des incidents. Ce sont précisément les larges capacités de détection promises ainsi que la variété des cas d’usage possibles de ces données et des types d’utilisateurs impliqués (équipes opérationnelles et métiers, équipes de cybersécurité, etc.) qui rendent les sondes OT si populaires.

Cependant, nos clients sont souvent confrontés à des défis importants lorsqu’il s’agit de déployer ces sondes à grande échelle et de les exploiter efficacement pour la détection sur l’ensemble des réseaux industriels.

Voici les défis fréquemment rencontrés lors du déploiement des sondes OT :

• Défis liés aux capacités et aux ressources du réseau des sites industriels : Le déploiement des sondes OT présente souvent des défis significatifs en raison des limites de l’infrastructure réseau industrielle. Les taps réseau et les ports SPAN sur les commutateurs, couramment utilisés pour la surveillance du trafic, ne sont pas toujours manageables ou disponibles dans les environnements OT, ce qui limite les options de capture de trafic passif. De plus, les coûts associés à l’installation de taps réseau peuvent être prohibitifs. Enfin, le déploiement et la maintenance des sondes exigent des ressources qualifiées sur place.
• Défis liés à la sélection des points d’écoute : Les sondes OT collectent et corrèlent l’information via la capture de trafic réseau. Pour être efficace, leur déploiement nécessite une sélection minutieuse des points d’écoute en fonction des cibles visées. Les points d’écoute doivent être adaptés à l’architecture de chaque site, un processus souvent limité par les connaissances des équipes locales et le manque de documentation. De plus, comme les environnements industriels varient d’un site à l’autre au sein d’une même organisation, il est très difficile d’établir un standard unique. Par conséquent, la sélection et la configuration des points d’écoute constituent un processus répétitif et itératif qui doit être ajusté pour chaque déploiement afin de garantir une visibilité et des capacités de détection optimales.

Au-delà du déploiement, l’exploitation de ces sondes s’accompagne également de défis et exige une charge de travail significative. Elles ont tendance à générer un nombre élevé de faux positifs, ce qui oblige les équipes à créer des règles de détection et des playbooks sur mesure pour filtrer et répondre efficacement aux alertes. En moyenne, nous estimons qu’un analyste SOC à temps plein est requis pour gérer les alertes générées par 50 sondes.

En conclusion, bien que les sondes OT soient populaires, les coûts et les ressources nécessaires à leur déploiement et à leur exploitation limitent leur pleine utilisation. Notre recommandation est de prioriser le déploiement des sondes OT sur les sites critiques ou au sein des segments réseau clés qui exigent des capacités avancées de surveillance industrielle. Cette approche ciblée permet de maximiser le retour sur investissement tout en garantissant une détection efficace là où elle est essentielle pour nos clients.

Envisager d’autres solutions ?

Concernant la détection pour le périmètre industriel, bien que cet article se concentre sur des sources clés comme les solutions EDR et les sondes réseau OT, il est important de reconnaître que d’autres solutions, telles que les technologies de leurre comme les honeypots, peuvent également jouer un rôle précieux et être pertinentes dans des scénarios ou environnements spécifiques, en fonction de l’architecture de vos sites industriels ou des scénarios de compromission redoutés.

Conclusion

Pour conclure, voici les recommandations clés pour élaborer une stratégie d’outillage de détection efficace pour mettre sous surveillance des environnements industriels :

1. Tirez parti des outils existants pour un impact immédiat

Commencez par maximiser la valeur des sources de détection déjà disponibles dans votre environnement industriel : logs de pare-feu, EDR, Active Directory, logs d’accès distant, etc. L’adaptation à l’OT des patterns de détection IT éprouvés permet aux organisations d’atteindre rapidement un niveau de visibilité de base sans nécessiter d’investissements lourds. Cette première approche garantie un déploiement plus rapide et une couverture plus large de vos assets industriels.

2. Déployer des solutions avancées là où elles sont pertinentes

Lorsque vous étendez vos capacités de détection, donnez la priorité au déploiement d’outils avancés tels que les sondes réseau OT là où ils apportent le plus de valeur. Pour les sondes réseau, concentrez-vous sur les sites ou segments critiques et sélectionnez soigneusement les points d’écoute afin d’optimiser la visibilité, le coût et les frais généraux opérationnels. Cette approche de déploiement ciblée garantit une utilisation efficace et stratégique des ressources.

3. Prioriser la qualité et la pertinence plutôt que la quantité

Pour élaborer une stratégie de détection OT efficace, il n’est pas nécessaire d’écouter toutes les sources de données possibles. Concentrez-vous plutôt sur les sources qui sont à la fois pertinentes pour votre environnement et techniquement exploitables, sans perturber les opérations. Cette approche permet de réduire les coûts de stockage et de gestion des journaux et de créer des règles de détection pertinentes et de meilleure qualité.  

N’hésitez pas à nous contacter pour discuter de la manière dont vous pouvez élaborer et améliorer votre stratégie de détection pour surveiller vos actifs industriels !

Dans notre prochain article, nous examinerons comment évaluer la détection en environnements industriels en utilisant des exercices de purple team, une méthode pratique pour évaluer et améliorer vos capacités de détection.

Cet article ​​Stratégie d’outillage cybersécurité pour une détection industrielle efficace​ est apparu en premier sur RiskInsight.

L’OT, bien que globalement moins touché que l’IT, n’est pas exempt de cybermenaces. Voici une vue simplifiée de ces principales menaces :  

• Hacktivisme : Les tensions géopolitiques accrues en 2025 ont entraîné des attaques de faible intensité par des groupes comme CyberArmyofRussia_Reborn et CyberAv3ngers.  
• Cybercriminalité / Ransomware : Une augmentation de 87 % des attaques par ransomware dans les groupes industriels a été constatées en 2025 d’après les chiffres de Dragos dans son rapport annuel.  
• Menaces étatiques : On note les campagnes récentes telles que Voltzite (vol d’informations OT) ou IOControl.

Ce panorama des menaces a notamment été dépeint par Chris Sistrunk, ICS/OT Technical Leader chez Mandiant, Google Cloud Security, lors de la Black Hat 2025 :  

Face à l’augmentation des menaces ciblant les environnements OT, leur surveillance continue est devenue essentielle. Les systèmes d’information industriels doivent être étroitement surveillés, et nous savons que nos clients y travaillent activement. Mais une question demeure : comment mesurer l’efficacité de la détection en environnement industriel, et surtout, comment l’améliorer ?  

Comment mesurer et améliorer l’efficacité de la détection en environnement industriel ? 

Pour répondre à cette question, nous avons élaboré une méthodologie visant à évaluer les capacités de détection au sein des SOC industriels.  

Cette évaluation s’articule autour des activités clés d’un SOC, réparties en quatre grands piliers : gouvernance & stratégie, prévention, détection et réponse.

En nous appuyant sur cette méthode, nous avons évalué une quinzaine de clients industriels afin de mieux comprendre leur niveau de maturité. Dans cet article, nous partageons les principales tendances qui en ont émergé, en nous concentrant spécifiquement sur les questions liées à la détection.  

Deux articles complémentaires seront publiés : l’un dédié à l’efficacité des différentes stratégies et solutions de détection, et l’autre aux méthodes de test des capacités de détection dans des environnements industriels à l’aide d’exercices de purple teaming et des modules dédiés que nous avons développés.  

Gouvernance et Stratégie  

La première question sur laquelle nous nous sommes concentrés était de savoir si la supervision des sites et environnements industriels est assurée par une équipe dédiée utilisant des outils spécifiques ou si, au contraire, elle est intégrée dans une approche d’un SOC unique et centralisé.  

Les réponses sont unanimes :  

Ces chiffres peuvent s’expliquer par plusieurs facteurs. L’une des principales raisons est l’optimisation financière. Maintenir deux équipes distinctes aux compétences et rôles similaires : gestion des alertes, configuration des outils … représente un coût important.  

Cependant, un SOC unifié implique généralement une extension du périmètre de son SOC IT pour inclure l’OT, sans pour autant garantir la présence d’outils ou d’expertises spécifiques à l’OT, et donc de véritables capacités de détection pour couvrir les environnements industriels.  

Même si cette approche ne garantit pas une détection et une réponse efficace sur l’ensemble du périmètre industriel, un SOC unifié peut tout de même gérer efficacement les incidents OT, à condition de : 

Assurer supervision de bout en bout  

En examinant de plus près le paysage simplifié des menaces, on constate que les cyberattaques ne sont pas forcément spécifiques à l’IT ou à l’OT (hacktivisme, ransomware …).  

Les ransomwares par exemple, qui représentent toujours aujourd’hui la principale menace, ne se limitent pas à un environnement industriel ou bureautique. Ils se propagent souvent à travers les deux, rendant indispensable le suivi des alertes de bout en bout.  

Ainsi, unifier les équipes et les outils de détection fait sens, puisque les attaques ne se limitent pas à l’IT ou OT. 

Faire le lien avec les sites industriels 

En cas d’incident cyber, le temps de réponse et le partage d’informations est essentiel. Comme la plupart des équipes de sécurité sont centralisées en un seul lieu, il est nécessaire d’établir un lien, au travers d’un relais cyber local, entre ces équipes centrales et les sites industriels locaux dans le processus de gestion des incidents cyber :  

• Ce relais connaît bien les sites industriels, leurs caractéristiques, contexte opérationnel et modes de fonctionnement.  
• Il maintient également un contact direct sur site pour recueillir rapidement les informations nécessaires au triage, ou à l’investigation.  
• De plus, dans les organisations globales, disposer de ressources situées dans les bons fuseaux horaires et capables de communiquer dans la langue locale est indispensable, en particulier dans le monde industriel.  

Appelés dans le schéma ci-dessous des « référents Cyber-OT », ces relais jouent un rôle actif dans le processus de résolution des incidents, en particulier durant les phases d’investigation et de remédiation :

En conclusion, bien que ces SOC unifiés couvrant à la fois les périmètres IT et l’OT résultent généralement d’un besoin d’optimisation des coûts, ce modèle fait sens dans la mesure où de nombreuses menaces concernent les deux environnements. Toutefois, il ne faut pas considérer un SOC unifié comme une simple extension du périmètre à couvrir : des relais OT dédiés et une expertise spécifique sont indispensables pour adresser efficacement les environnements industriels. 

Outillage et solution de détection  

En ce qui concerne les solutions de détection, nous avons constaté que 100 % de nos clients disposent d’outils de détection déployés côté IT. Cependant, seulement un tiers étend la supervision jusqu’aux couches inférieures de l’environnement industriel.  

Nous nous concentrerons par la suite sur les solutions les plus populaires pour adresser la détection dans les environnements industriels : les EDR et les sondes OT.  

EDR  

Quelques chiffres concernant les EDR :  

La plupart de nos clients ont commencé à déployer des EDR dans leurs environnements industriels. Cependant, cela ne signifie pas que 100 % des machines industrielles compatibles avec les EDRs sont couvertes.  

Pour les environnements qui le permettent, étendre la couverture EDR permet de :  

• Répondre à une maturité faible : commencer par des outils simples à déployer et qui ne nécessitent pas de connaissances avancées de l’architecture des sites.  
• Assurer une couverture large spectre : se concentrer sur la couverture rapide d’un large éventail de systèmes, de sites et d’applications critiques.  
• Tirer parti des solutions de l’IT : utiliser des solutions IT comme les EDRs pour une détection efficace sans nécessiter d’adaptation majeure des équipes SOC.  

Pour cette dernière raison, la plupart des organisations choisissent d’utiliser la même solution EDR pour les environnements IT et OT. Cela permet un déploiement plus rapide grâce à un outil connu et déjà intégré. Selon les besoins et les ressources disponibles, une solution différente peut toutefois être sélectionnée afin d’améliorer la résilience et la compatibilité OT.

Pour conclure, dans un contexte de convergence IT/OT, déployer des EDR sur les serveurs et postes de travail industriels devient de plus en plus pertinent et selon les retours d’expérience de nos clients, permet d’étendre rapidement et efficacement la couverture de détection des périmètres industriels.   

Sondes de détection OT 

Quelques chiffres concernant les sondes :   

En ce qui concerne les sondes, l’écart entre ces deux chiffres met en lumière le défi que représente leur déploiement à grande échelle et leur utilisation efficace pour la détection dans les réseaux industriels.  

En effet, les sondes collectent des informations via la capture du trafic réseau. Pour être efficaces, leur déploiement nécessite une sélection des points d’écoute en fonction des objectifs cibles. Ces points d’écoute doivent être adaptés à l’architecture spécifique de chaque site, souvent limité par la connaissance locale des équipes ou le manque de documentation.  

L’exploitation de ces sondes demande également une charge de travail importante. Elles ont tendance à générer un grand nombre de faux positifs, ce qui oblige les équipes à créer des règles de détection personnalisées et des playbooks pour filtrer et répondre efficacement.  

En conclusion, les sondes de détection OT sont peut-être populaires, mais les coûts et les ressources nécessaires pour leur déploiement et leur ajustement limitent leur pleine utilisation.  

Commencer par couvrir l’essentiel avec la détection d’outils OT 

En définitive, pour la détection OT, nous pensons qu’il faut commencer par des mesures basiques en tirant parti des outils « IT » afin d’assurer un premier niveau de couverture sur l’ensemble des sites, des applications critiques et de l’infrastructure en :  

• Priorisant les assets critiques : Se concentrer sur les systèmes clés (MES, outils de sécurité, infrastructure réseau) essentiels à la production, en veillant à leur mise sous supervision avant d’étendre le déploiement aux couches inférieures du modèle de Purdue.  
• Mettant en place une détection basique : Établir une détection fondamentale sur les sites et l’infrastructure pour permettre une identification en amont des incidents, avant de passer à des solutions OT plus avancées.  

S’entraîner et se tester 

Les capacités de détection ne reposent pas uniquement sur le déploiement d’outils ; cette dernière partie des conclusions du benchmark se concentrera sur la capacité des équipes à les exploiter efficacement.  

La nécessité de renforcer les connaissances spécifiques à l’OT 

Les chiffres issus du benchmark révèlent une connaissance et adaptation limitées des équipes et des processus aux environnements industriel :   

Pour combler cet écart, les équipes doivent bénéficier de formations spécifiques aux contextes industriels : une formation de base pour l’ensemble des analystes SOC, et une formation approfondie pour les spécialistes OT.   

De la même manière, les processus d’investigation et de réponse doivent également être adaptés pour répondre aux spécificités des environnements industriels, en prenant en compte des priorités comme la disponibilité.  

Testez vos capacités de détection !  

Enfin, l’amélioration de la détection commence par son évaluation, mais aujourd’hui… 

Seule une petite minorité de nos clients teste réellement ses capacités de détection, mais nous sommes convaincus de la valeur ajoutée des exercices de purple teaming dans les environnements industriels. Ces exercices collaboratifs avec le SOC OT, adaptés à son niveau de maturité et à ses objectifs, permettent de tester et d’améliorer à la fois les outils de détection et les processus du SOC OT.   

Il est possible de commencer simplement : en sélectionnant des environnements de production appropriés et en réalisant quelques tests basiques, comme l’insertion d’une clé USB contenant un échantillon de malware standard ou la tentative de quelques actions d’élévation de privilèges… 

On peut ainsi évaluer si l’EDR déployé sur un poste de travail connecté au SOC déclenchera une alerte et une investigation.  

Ces exercices permettent d’identifier les angles morts et d’ajuster en conséquence les outils déployés, les processus et les playbooks.  

Conclusion : Comment renforcer le faible niveau de maturité en matière de détection pour les systèmes industriels ? 

La première conclusion du benchmark est claire : les niveaux de maturité sont faibles, et cette réponse est constante dans toutes les réponses recueillies. Comment améliorer cette maturité globalement faible en matière de détection pour les systèmes industriels ? 

Voici les principaux enseignements concernant les trois thématiques abordées dans cet article : 

N’hésitez pas à nous contacter pour échanger sur la manière de renforcer vos capacités de détection et d’évaluer votre maturité par rapport au marché ! 

Cet article ​Quelle détection pour l’OT ?  Situation actuelle & perspectives est apparu en premier sur RiskInsight.

Ainsi, devriez-vous vous lancer dans l’aventure des sondes OT ? Et si oui, comment réussir le déploiement d’un service de sondes ?  

Sondes OT : Un outil pour surveiller les réseaux industriels 

Image 1 : Écouter le réseau pour l’inventorier et détecter 

Une sonde de détection est un équipement, virtuel ou physique, connecté au système d’information (SI) afin de le cartographier et de le surveiller. Elle se compose de capteurs répartis dans le réseau pour collecter des données et d’un équipement central pour corréler ces données. Les sondes pour environnements industriels – que nous appellerons ici sondes OT – se caractérisent par leur écoute passive et non invasive du réseau, et leur compréhension des protocoles et comportements industriels. De nombreux acteurs sont présents, vous pouvez retrouver notre vision du marché ici : https://www.riskinsight-wavestone.com/2021/03/les-sondes-de-detection-en-milieu-industriel-notre-vision-du-marche/  

Toutes leurs sondes fonctionnent sur le même principe : le trafic réseau est collecté en utilisant de la duplication de flux (SPAN, ERSPAN …) ou des duplicateurs physiques comme les taps. Les paquets sont inspectés en temps réel pour fournir plusieurs types de données : inventaire et cartographie des flux, gestion des vulnérabilités, et enfin détection des anomalies et des incidents. 

La grande diversité des cas d’utilisation possibles de ces données et la variété de ses utilisateurs (équipe opérationnelle et commerciale, équipe de cybersécurité, etc.) font la popularité de ces sondes OT.  

Cependant, ces solutions, tout comme leur déploiement et exploitation, sont coûteuses et nécessitent une bonne compréhension des besoins, des utilisateurs potentiels et de la valeur ajoutée avant de se lancer. 

Prenons deux exemples … 

Imaginons deux entreprises envisageant de déployer des sondes OT sur leurs sites industriels.

1ère entreprise : WavePetro 

WavePetro possède un large site sensible, avec une bonne maturité cyber et une architecture très segmentée. L’entreprise souhaite déployer des sondes OT pour se conformer à la réglementation et améliorer ses capacités de détection. 

Compte tenu de son architecture et de ses besoins de détection, de nombreux points d’écoute seront nécessaires. WavePetro peut compter sur ses équipes locales et leur expertise et connaissance du site pour réaliser le déploiement. 

2nd entreprise : RenewStone 

RenewStone est une entreprise possédant de nombreux petits sites géographiquement dispersés et sans équipe locale, avec une maturité cyber hétérogène. Ses sites sont interconnectés avec l’infrastructure du groupe. 

L’entreprise souhaite déployer des sondes OT pour gagner en visibilité sur ses sites en utilisant les fonctions d’inventaire et de cartographie.  

Ainsi, RenewStone a besoin de standardiser un service de sondes OT pour ses sites et de pouvoir proposer des déploiements avec le moins de complexité locale possible.  

Image 2 : 2 entreprises, 2 besoins, 2 implémentations 

… et leurs déploiements vers un service de sondes fonctionnel 

Bien que ces deux entreprises aient des besoins et maturités cyber différentes, les 5 étapes clés de déploiement restent les mêmes, bien qu’avec des approches différentes.   

1.Preuve de concept 

La première étape est la preuve de concept (PoC : Proof of Concept).  
L’objectif pour les deux entreprises est de tester la faisabilité et la valeur ajoutée des sondes OT sur leurs périmètres. 

Alors que WavePetro doit valider la faisabilité sur un périmètre réduit dans son usine, RenewStone doit se concentrer sur la validation de la valeur du service de sonde OT sur quelques-uns de ses sites. 

Pour tirer le maximum du PoC, il est important de : 

• Adapter la sélection des fournisseurs à vos besoins : Le marché est très diversifié entre les pure-players, ceux spécialisé au secteur industriel ou qui étendent leurs solutions IT à l’OT …  
  Les questions à se poser : Est-ce que je veux de fortes capacités de détection ? Est-ce que je veux un service managé ? Est-ce que je veux une solution unifiée pour l’IT et l’OT ?  
• Sélectionner le champ d’application du PoC : Identifier un périmètre représentatif avec des ressources à tester afin que les résultats puissent être reproduits à l’échelle.  
• Rédiger une architecture cible avant le PoC : tester une architecture représentative de ce qui serait déployé à l’échelle, afin de valider les tests effectués. 

Le PoC est essentiel pour s’assurer que les sonde OT apporte de la valeur, mais également pour pouvoir convaincre de les déployer, en particulier lorsqu’elles ne sont pas contraintes par des réglementation. 

2.Construction d’un modèle opérationnel 

Dès le début du projet, il est important de se rappeler que l’objectif final du déploiement des sondes OT : Collecter des informations utilisables et valorisables. Pour ce faire, il est important de : 

• Définir un modèle opérationnel pour le traitement des alertes, de l’inventaire et la gestion des sondes. Alors que WavePetro peut avoir un modèle d’exploitation reposant sur les connaissances et l’expertise locales, RenewStone doit construire un modèle d’exploitation central avec les équipes du groupe telles que le SOC, la sécurité OT, le réseau, l’infrastructure, etc. 
• Décider de faire appel à un tiers ou de gérer vos sondes en interne : Peu de fournisseurs proposent des services de gestion, vous devrez donc créer votre propre modèle, qui pourrait également s’appuyer – en totalité ou partiellement – sur de l’externalisation. 
• Créer un RACI : Compte tenu des différents cas d’usage et du nombre d’acteurs impliqués dans l’utilisation ou la maintenance des sondes, un RACI est essentiel pour s’assurer que toutes les parties prenantes nécessaires seront impliquées et mobilisées. 

Cette étape doit être traitée en amont pour faciliter les étapes suivantes du déploiement. 

3.Préparation au déploiement 

Une fois que la première étape a démontré la valeur ajoutée d’une sonde et que son modèle de fonctionnement a été défini, préparons le déploiement ! Vous devez définir la cible finale : 

• Où déployer la sonde : En particulier si vous avez de nombreux sites différents, comme RenewStone, vous devez prioriser : quels sont vos sites sur lesquels déployer ? Vous pouvez vouloir déployer sur les sites les plus critiques seulement et rendre le service disponible pour d’autres à la demande. Les sites sélectionnés doivent également permettre un déploiement. Quels sont les prérequis au déploiement ? Ils peuvent par exemple être définis selon les équipements réseaux disponibles. 
• Quand déployer : Travaillez sur dès que possible sur des estimations budgétaires afin que les sites soient en mesure de prévoir un déploiement. Les sondes sont une solution coûteuse, non seulement en termes de matériel et de licences, mais également en ressources, pour les déployer et les exploiter. 
• Comment déployer : Dans tous les cas, vous devez construire une architecture pour le déploiement des sondes OT. En particulier, si vous avez de nombreux sites à déployer ou des ressources locales très limitées, vous devez travailler à l’élaboration d’une offre de service packagée à déployer.  

Cette préparation est un passage obligé pour éviter de perdre du temps lors des déploiements et garantir leur succès. 

4.Déploiement 

Il est temps de s’attaquer au déploiement ! Le mot d’ordre est la même pour les deux entreprises : Avancer pas à pas. La différence réside dans l’échelle : 

• Un déploiement progressif sur le site de WavePetro : Il faudra du temps pour pouvoir « écouter » efficacement partout. Concentrez-vous sur les données attendues pour prioriser l’emplacement initial de la sonde et ses points d’écoute. 
• Apprendre et s’améliorer d’un déploiement à l’autre pour RenewStone : Les déploiements sont centralisés et plus standardisés, donc les équipes apprendront et s’amélioreront d’un déploiement à l’autre. Inclure un panel de sites représentatifs dans la première vague permet de tester et améliorer le modèle de déploiement. 
• Ne pas négliger la conduite du changement : dans les deux cas, le déploiement d’une nouvelle solution doit absolument inclure de la sensibilisation et de la formation afin que les sondes OT trouvent leurs utilisateurs. 

Le déploiement de sondes OT peut être un processus long et fastidieux, mais ne vous découragez pas en chemin, car il reste encore une dernière étape à franchir !

5.Fine-tuning 

Une sonde OT est un outil d’amélioration continue, la détection doit gagner en valeur avec le temps. Vous devez donc consacrer du temps à : 

• Configurer le tableau de bord de la console : Prendre le temps d’améliorer le modèle de détection (liste blanche de certains comportements, priorisation des actifs sensibles…), l’inventaire automatique des actifs et la cartographie (enrichir l’inventaire, importer des données, taguer les VLAN…), et ainsi de suite. Ce fine-tuning doit être effectué par une personne familière avec les sites industriels.  
• Intégrer d’autres technologies : Vous pouvez lier les consoles à d’autres outils de votre entreprise, tels que le SIEM, les pares-feux ou la CMDB, afin d’exploiter au maximum les données collectées par les sondes. 
• Testez d’ajouter des fonctionnalités : une fois que vous avez acquis une certaine maturité avec la solution, vous pouvez aller encore plus loin avec les fonctionnalités disponibles, comme l’exécution de requêtes actives pour enrichir l’inventaire. 

Le fine-tuning permet de limiter le nombre de faux-positifs, afin de se concentrer sur les données qui apporteront de la valeur à votre entreprise et à sa sécurité. 

Image 3 : Les 5 étapes clés d’un déploiement de service de sondes OT 

Conclusion 

Ces deux exemples nous ont beaucoup appris sur les sondes de détection industrielle et sur les nombreux défis liés à leur déploiement et utilisation.  

Si demain, je fais face à un client industriel qui se demande que faire de ce projet sonde sur sa feuille de route, je lui partagerai ces 3 conseils :  

Image 4 : Les 3 clés d’un déploiement réussi 

Questionner la valeur ajoutée de ses sondes 

En l’absence de cas d’utilisation clairement identifiés et d’objectifs déterminés, vous pouvez vous retrouver avec des sondes fournissant des informations inutilisées ou sans réelle valeur ajoutée. Les sondes OT sont coûteuses, à la fois financièrement et en termes de temps. Vous devez être sûr qu’elles en valent la peine, et vous donnez les moyens de les exploiter pleinement. 

Pour ce faire, prenez le temps d’évaluer la qualité et la valeur des informations remontées par les sondes OT avec vos différentes équipes (cybersécurité, exploitation, business …). 

Avancer pas à pas 

Ne craignez pas de commencer petit et de croître progressivement, qu’il s’agisse du nombre de sites déployés, du nombre de points d’écoute ou de cas d’utilisation des sondes OT. 

L’exploitation à long terme des sondes OT est complexe et se construit au fil des déploiements. Prenez le temps de soigner l’adoption de la solution : si vous voulez que les équipes utilisent la solution, formez les et montrez en leur la valeur !  

Compter sur l’amélioration continue 

Les sondes OT peuvent fournir nombre de fonctionnalités allant de la détection d’incidents à la cartographie, en passant par la gestion des vulnérabilités et bien d’autres encore qui doivent être publiées par les éditeurs. 

Concentrez-vous d’abord sur les fonctionnalités qui réduisent vos risques OT, en améliorant progressivement les services au fur et à mesure qu’ils gagnent en maturité ! 

Cet article Sondes de détection pour l’OT : Les clés pour réussir son déploiement  est apparu en premier sur RiskInsight.