Rechercher

Étude de cas : benchmark technique des solutions EDR dans un environnement OT

L’un de nos clients nous a demandé de comparer des solutions EDR au sein d’un environnement industriel. Voici les résultats.

Quels étaient les principaux objectifs de l’étude ?

L’un de nos clients a décidé de comparer des solutions EDR (endpoint detection and response) pour son système d’information OT (operational technology). L’entreprise a fait appel à nos services pour analyser différentes solutions EDR, d’abord d’un point de vue théorique, puis d’un point de vue technique. L’analyse théorique a permis de présélectionner 3 EDR sur 9 qui répondent au mieux à leurs besoins. Puis lors de la seconde phase, l’objectif était d’étudier quelles solutions répondaient à leurs exigences techniques.

Quelle méthodologie utilise-t-on pour ce type d’analyse technique ?

Pour comparer les solutions EDR d’un point de vue technique, des attaques basées sur un référentiel ont été construites. Ensuite les scénarios d’attaque ont été joué dans notre environnement de test. Chaque phase est décrite ci-dessous.

  • Références publiques

Pour simuler des attaques qui ressemblent à des attaques réelles et semblables à celles du terrain, nous utilisons la matrice MITRE ATT&CK for ICS(1). Elle est par exemple utilisée pour cartographier les attaques réalisées lors des tests d’intrusion. La matrice ATT&CK est construite en fonction des cyberattaques (logiciels malveillants ou attaques manuelles) qui ont eu lieu sur un environnement OT au cours des dernières années. Cette base de connaissances publique décrit les actions qu’un adversaire peut effectuer lorsqu’il opère dans un réseau industriel. La matrice cartographie un scénario d’attaque qui commence après que le premier accès à un réseau OT ait été établi. D’autres matrices MITRE (ATT&CK enterprise ou PRE-ATT&CK) décrivent comment obtenir cet accès (pénétrer dans le système d’information ou si nécessaire compromettre le réseau IT).

La matrice est divisée en 11 catégories appelées “tactiques”. Pour chaque tactique, plusieurs types d’attaques, appelées “techniques”, sont référencées. Pour chaque technique, il y a une description, le groupe d’attaque qui l’a utilisée, plusieurs types de mesures d’atténuation possibles, etc. Cette matrice cartographie les différents vecteurs d’entrée des attaques sur l’environnement ICS, mais aussi les impacts d’une intrusion.

Par exemple, un scénario d’attaque qui supprime les alarmes d’un logiciel SCADA, et empêche donc les opérateurs d’être informés des conditions critiques, peut avoir un impact sur la “manipulation of view ” ou même, selon les conditions, une “loss of safety”.

  • Conception de scénarios d’attaque

Après avoir choisi le MITRE ATT&CK for ICS comme référence, nous étudions les techniques qui peuvent être détectées par un EDR. Comme mentionné précédemment, le framework fournit différents types de recommandation pour chaque technique, pour sélectionner la technique, nous recherchons la recommandation qui correspond aux fonctionnalités de l’EDR. Les tactiques “exécution” et “évasion” sont celles que nous ciblons principalement pour cette évaluation. Les techniques suivantes (en bleu) ont été incluses :

Techniques couvertes par l’étude – Orange Cyberdefense

Après avoir répertorié les techniques qui s’appliquent à ce benchmark, nous définissons des tests, avec différents niveaux de complexité . En effet, différents niveaux de tests (allant d’une charge utile d’attaque connue à une charge complètement personnalisée) sont créés pour chaque technique mise en évidence ci-dessus.

Pour les charges utiles, nous nous appuyons sur des charges publiques, dont certaines sont utilisées lors d’un exercice de test d’intrusion. Nous développons également de nouveaux payloads en C#/C++ afin de ne pas avoir de signature publique.

Ensuite, à partir des tests unitaires définis, nous mettons en corrélation plusieurs d’entre eux pour construire un scénario d’attaque complet avec des conséquences OT.

Par exemple, nous avons conçu, développé et testé le cas d’utilisation suivant, cartographié en fonction des phases de la kill chain ICS :

Exemple de scénario d’attaque – Orange Cyberdefense

La couverture de correspondance sur la matrice ICS ATT&CK est la suivante :

Construction de l’environnement de test

Après avoir élaboré divers scénarios d’attaque, nous construisons l’environnement de test.

Des PC Windows avec des versions classique (W7,10,2012,2016,2008R2) ont été mis en place ainsi que certains ordinateurs plus anciens comme Windows XP. En effet, dans les environnements OT, le cycle de vie des machines est plus long que dans un environnement IT. Parfois, la migration n’est pas une option pour assurer la compatibilité avec les anciens logiciels qui sont critiques pour la chaîne de production. L’un des objectifs du client est également de voir les résultats d’une attaque sur ce type de système.

De plus, pour simuler un réseau OT plus réaliste, plusieurs logiciels SCADA ont été installés sur les systèmes. Par exemple, des automates sont surveillés par la supervision Topkapi depuis le serveur Windows 2008R2.

Pour être plus efficaces, toutes les solutions EDR doivent être reliées au cloud de l’éditeur. Cet accès est nécessaire pour accéder à toutes les fonctionnalités telles que la threat intelligence. Cependant, sur un périmètre ICS, les éléments ne devraient pas avoir une connexion directe à Internet. Par conséquent, les EDRs testés ont été installés en mode hybride. Ce mode permet à l’agent EDR de se connecter à un serveur local qui doit être installé dans une DMZ (zone démilitarisée) industrielle et seul le serveur se connecte à Internet. Une connexion de confiance doit être établie entre l’agent et la console et entre la console et le cloud. Les interconnexions peuvent être représentées comme ci-dessous sur le modèle de Purdue :

Interconnexion avec le mode hybride – Orange Cyberdefense Exécution du scénario d’attaque sur l’environnement de test

Après avoir construit les cas d’utilisation et configuré l’environnement, nous avons effectué les tests sur les différents systèmes d’exploitation. Pour cette phase, chaque éditeur d‘EDR nous a aidé à interpréter les résultats et a détaillé comment la détection peut être améliorée en configurant la solution différemment. Chaque résultat a été décrit et synthétisé dans un rapport pour nos clients.

Comparatif des solutions EDR au sein d’un environnement OT : quels résultats ?

La configuration de l’EDR est le point le plus important, elle doit être définie avec soin dans un environnement OT pour éviter tout impact sur la disponibilité. Par exemple, nous avons utilisé pour tous les EDR une politique de détection configurée pour maximiser le taux de détection afin de voir les limites de la solution. Avec cette politique, un des logiciels SCADA a été détecté et bloqué. Ce n’est, bien sûr, pas une politique qui devrait être choisie dans un environnement de production. Avec ce type de politique, plusieurs faux positifs ont également été relevés, c’est pourquoi la partie configuration est cruciale. Dans un environnement OT, la réaction après la détection d’une menace (comme l’arrêt du processus affecté) doit être définie avec plus de prudence pour la même raison que précédemment : l’impact sur la disponibilité.

De plus, un autre point important sur un réseau OT est la bande passante. En effet, la bande passante de certains réseaux peut être très limitée dans le cas d’un site distant. Lors du benchmark, nous avons comparé la bande passante des agents EDR sur notre environnement de test à celle estimée par l’éditeur. Pour certains EDR, il y avait des différences majeures entre eux, ce qui peut s’expliquer par la politique choisie qui maximise la détection, mais induit des faux positifs et une consommation de bande passante.

En ce qui concerne les résultats obtenus, nous avons remarqué que sur nos 8 scénarios corrélant différentes attaques, au moins une étape a été détectée par les solutions. Dans le cas d’une attaque réelle, cela pourrait suffire à alerter les équipes et à lancer une action conformément au plan de réponse aux incidents. Par exemple, si nous analysons le composant killdisk qui fait partie de la famille des malwares « BlackEnergy » (2). Ce composant a un impact sur la disponibilité de la cible. Il effectue, entre autres, la suppression des journaux système ou l’arrêt d’un processus. Ce type d’action, testé dans le scénario ci-dessus, peut être détecté par une solution EDR bien configurée.

Cependant, si nous prenons un autre exemple de malware comme PLC- blaster (3). Ce malware scanne le réseau pour trouver des dispositifs PLC S7 et les infecter. Ces types d’actions sont difficiles à détecter avec une solution de protection des endpoint et nécessitent d’autres solutions de défense telles que des sondes réseau. Ces solutions doivent être corrélées à un plan de réponse aux incidents approprié et peuvent être intégrées à un service de détection.

C’est pourquoi, chez Orange Cyberdefense, nous avons construit une Use Case Factory dédiée à l’environnement OT, non seulement pour la protection des endpoint, mais aussi pour d’autres solutions de défense. Elle peut être utilisée pour analyser et améliorer la détection des attaques pour les différents scénarios d’attaque qui peuvent se produire dans un environnement OT.

LIEN :

(1) collaborate.mitre.org/attackics/index.php/Main_Page

(2) https://collaborate.mitre.org/attackics/index.php/Software/S0016

(3) collaborate.mitre.org/attackics/index.php/Software/S0009

Retrouvez nos experts à une webinar le 7 juillet et posez leur vos questions en direct 

S'inscrire ici