Comment configurer votre collecteur EDR/SIEM avec OpenAEV

Lorsque nous maintenons des systèmes informatiques critiques, nous sommes inévitablement chargés de les maintenir en état de marche et de les sécuriser contre les attaques et les intrusions. Avec OpenAEV, nous pouvons simuler une pléthore de scénarios d'attaque susceptibles de compromettre ces systèmes.

Cependant, l'histoire ne s'arrête pas à la simple exécution d'un malware simulé : la partie la plus importante est de savoir comment les systèmes ont réagi à l'attaque afin d'avoir une compréhension actualisée des risques potentiels et de l'exposition. Généralement, les plateformes de sécurité telles que les EDR et les SIEM détectent et/ou préviennent ces attaques, puis créent des rapports exploitables avec les détails de ce qui s'est passé et des mesures prises.

OpenAEV est conçu pour utiliser des modules appelés Collecteurs afin de s'interfacer avec ces solutions et de collecter les rapports pertinents pour une attaque simulée orchestrée, puis de les consolider dans sa base de données : il devient ainsi simple de mener un scénario de bout en bout, de l'attaque au rapport, qui établit le niveau de protection des systèmes évalués.

OpenAEV présente la réponse à l'attaque d'une plateforme de sécurité à travers deux périmètres :

• Détection : le comportement suspect a été remarqué et tracé
• Prévention : un comportement malveillant a été empêché de s'exécuter

Dans cet article, nous fournirons des conseils sur la façon de configurer les composants nécessaires pour permettre à OpenAEV d'établir la connexion entre une attaque simulée et les rapports des plateformes de sécurité externes, afin d'avoir la vue la plus complète du résultat d'un scénario d'attaque.

TL;DR

• Comprendre les risques et l'exposition des systèmes informatiques dans des conditions contrôlées
• Tirer parti des EDR et des SIEM pour compléter un rapport sur le résultat d'un scénario d'attaque
• Apprendre à configurer les collecteurs OpenAEV pour surveiller les alertes et rapports pertinents afin de consolider les données sur le résultat de l'attaque.
• Découvrir l'écosystème officiel des collecteurs OpenAEV maintenus par Filigran, des composants prêts à l'emploi qui peuvent déjà s'interfacer avec les principales plateformes de sécurité du marché.

Glossaire

Ces termes et concepts sont importants pour tirer pleinement parti de cet article. Veuillez vous y référer pour comprendre la définition de ces mots au fil de votre lecture.

• Collecteur : un processus autonome s'exécutant sur un serveur, qui s'interface à la fois avec les plateformes de sécurité et OpenAEV
• Détection : résultat d'une exécution d'Inject où l'exécution a déclenché une plateforme de sécurité et a été consignée dans les logs
• Expectation : un espace réservé pour présenter le résultat d'une exécution d'Inject
• Inject : une commande d'attaque atomique qui peut être détectée ou prévenue par une plateforme de sécurité
• Prévention : résultat d'une exécution d'Inject où l'exécution a déclenché une plateforme de sécurité et a été interrompue ou autrement empêchée de terminer une tâche
• Scénario : une collection d'Injects, définissant un ordre d'exécution
• Plateforme de sécurité : un terme générique pour regrouper les solutions (EDR, SIEM…) qui peuvent porter la trace du résultat de l'exécution d'un Inject donné : détection et/ou prévention.

Étude de cas : évaluation de la protection contre l'exfiltration de credentials locaux

Notre scénario simple consistera à déterminer si la plateforme de sécurité déployée détectera et préviendra avec succès l'exfiltration de la base de données des utilisateurs locaux sur les distributions Linux courantes : /etc/passwd. Pour l'instant, nous considérerons un Scénario avec un seul Inject :

Scénario avec un seul inject "Exfiltration de credentials"

Après avoir lancé le Scénario, l'Inject est planifié puis exécuté : OpenAEV attend ensuite que les résultats des Expectations arrivent automatiquement via les Collecteurs (l'objet de cet article) ou appliqués manuellement (un opérateur disposant de privilèges suffisants peut remplacer le résultat d'une Expectation).

Nous pouvons voir cet état d'attente dans l'interface utilisateur, où les Expectations sont prêtes à recevoir des résultats dans le panneau latéral droit :

Inject "Exfiltration de credentials" en attente d'exécution

Nous aimerions voir ces Expectations remplies avec des résultats indiquant si l'exécution de l'Inject a été détectée et/ou prévenue. De cette façon, nous savons si les cibles évaluées sont protégées contre ce modèle d'attaque particulier.

Maintenant que le décor est planté, explorons les Collecteurs qui remplissent les blancs.

Aperçu d'un déploiement de Collecteur

Architecture générale

En se référant à l'architecture générale d'OpenAEV, le périmètre de cette étude a été mis en évidence :

Architecture OpenAEV : région des collecteurs mise en évidence

Vous verrez que les Collecteurs occupent une case autonome dans le diagramme ; en effet, les Collecteurs sont destinés à être des processus indépendants, qui se connectent à la fois aux plateformes de sécurité et à OpenAEV via leurs API respectives ; OpenAEV utilise l'API REST.

En tant qu'agents autonomes, les Collecteurs doivent s'enregistrer auprès d'OpenAEV pour être autorisés à télécharger les résultats récupérés dans la base de données OpenAEV. La liste des Collecteurs actuellement enregistrés se trouve à l'adresse suivante sur toute instance OpenAEV : /admin/assets/security_platforms.

Notez que les Collecteurs s'enregistrent dans la liste "Security Platforms" d'OpenAEV. Ils sont en effet la représentation de la plateforme réelle à laquelle ils se connectent afin de renvoyer les résultats à OpenAEV. Par conséquent, le Collecteur "Crowdstrike" apparaîtra comme la plateforme de sécurité "Crowdstrike" dans OpenAEV. Les résultats renvoyés par ce Collecteur seront estampillés "Crowdstrike" afin que nous sachions d'un coup d'œil la plateforme spécifique qui a contribué à un résultat donné.

Cycle de vie d'action d'un Collecteur

Un Collecteur est essentiellement un processus qui boucle sur un simple modèle de données fetch-process-store.

Étant donné qu'OpenAEV peut planifier l'exécution d'Injects à tout moment, le Collecteur surveille les résultats pertinents apparaissant dans les ensembles de données des Plateformes de sécurité à tout moment.

Chaque fois qu'un Collecteur est capable de faire correspondre une Détection ou une Prévention de la plateforme de sécurité avec les Expectations d'un Inject, un nouveau résultat est stocké correspondant au résultat.

Après un certain temps, notre Inject peut présenter les informations suivantes, en comparaison avec l'état de l'écran de la configuration précédente :

Inject "Exfiltration de credentials" exécuté avec succès, avec des expectations de détection et de prévention réussies

Les deux expectations ont signalé que le Collecteur Crowdstrike Falcon a trouvé dans sa plateforme de sécurité associée (la plateforme Crowdstrike Falcon réelle) des résultats qui correspondaient à notre Inject, et ces résultats indiquaient que l'exécution a été à la fois détectée et prévenue. C'est excellent ! Nous avons pu révéler, via l'écosystème OpenAEV, que notre endpoint était dûment protégé contre le vol de credentials locaux par l'EDR Crowdstrike Falcon.

TUTORIEL : Les Collecteurs en pratique

Nous avons démontré l'utilité des Collecteurs pour mettre le résultat en avant. L'écosystème OpenAEV fournit des Collecteurs maintenus par Filigran pour se connecter à un nombre croissant de plateformes de sécurité de premier plan dans l'industrie, avec toujours plus à venir. Examinons quelques scénarios de déploiement concrets.

Collecteurs prêts à l'emploi par Filigran

Parmi les Collecteurs officiellement pris en charge et maintenus par Filigran, nous pouvons trouver des implémentations Python pour l'EDR Crowdstrike Falcon et le SIEM Microsoft Sentinel. Pour une liste complète et à jour, consultez la documentation de l'écosystème OpenAEV.

La façon la plus simple de déployer l'un de ces Collecteurs est d'exécuter son image Docker officielle respective. Lorsque OpenAEV est déjà déployé avec Docker, il peut suffire d'ajouter le conteneur Collecteur à la stack Docker et de définir les quelques clés de configuration nécessaires pour que le Collecteur s'enregistre auprès d'OpenAEV et se connecte à la plateforme de sécurité.

Les images de Collecteur sont publiées périodiquement aux côtés de l'image du serveur OpenAEV et peuvent être trouvées sur Docker Hub : https://hub.docker.com/u/openaev.

La documentation respective des Collecteurs, notamment la configuration, peut être trouvée ici, par exemple :

• Collecteur Crowdstrike Falcon EDR : https://github.com/OpenAEV-Platform/collectors/tree/main/crowdstrike
• Collecteur Microsoft Sentinel SIEM : https://github.com/OpenAEV-Platform/collectors/tree/main/microsoft-sentinel

Exemple : déploiement d'un Collecteur Crowdstrike Falcon EDR avec Docker

Pour rappel, les Collecteurs sont généralement des processus autonomes, et c'est le cas pour tous les Collecteurs maintenus par Filigran. Cela signifie qu'un Collecteur donné peut s'exécuter n'importe où, indépendamment de l'endroit où l'instance OpenAEV elle-même s'exécute, à condition qu'il puisse atteindre ses endpoints d'API REST.

Dans cette optique, nous pourrions créer une stack Docker autonome pour exécuter uniquement notre conteneur Collecteur (consultez https://github.com/OpenAEV-Platform/collectors/tree/main/crowdstrike#configuration pour les clés de configuration de référence) :

Copied!

1services:
2	crowdstrike_edr_collector:
3		image: openaev/collector-crowdstrike:1.19.0
4		environment:
5		  - OPENAEV_URL=${OPENAEV_URL}
6		  - OPENAEV_TOKEN=${OPENAEV_TOKEN}
7		  - COLLECTOR_ID=${COLLECTOR_ID}
8		  - CROWDSTRIKE_API_BASE_URL=${CROWDSTRIKE_API_BASE_URL}
9		  - CROWDSTRIKE_CLIENT_ID=${CROWDSTRIKE_CLIENT_ID}
10		  - CROWDSTRIKE_CLIENT_SECRET=${CROWDSTRIKE_CLIENT_SECRET}
Copy

docker-compose.yml

Notez que ce Collecteur n'a pas besoin de stockage persistant, donc pas besoin de configurer un volume docker.

Ensuite, rassemblez les informations nécessaires pour démarrer le nouveau conteneur configuré avec l'environnement cible.

• OPENAEV_URL : une URL HTTP vers l'instance OpenAEV qui est visible depuis le conteneur
• OPENAEV_TOKEN : un token API privilégié (admin) d'un compte administrateur ; trouvez-en un en naviguant vers la page de profil d'un compte administrateur sur OpenAEV et faites défiler jusqu'à la section des clés API

Bouton pour accéder à la page de profil du compte

Un exemple de clé API (note : cette clé spécifique est uniquement à des fins d'exemple)

• COLLECTOR_ID : une chaîne globalement unique générée aléatoirement. UUIDv4 fonctionne parfaitement pour cet usage.
• CROWDSTRIKE_* : ces clés sont liées à une paire de credentials OAuth2 active dans un abonnement à CrowdStrike Falcon. Il est recommandé de créer des credentials dédiés à l'usage exclusif du collecteur. Les credentials OAuth2 sont créés dans l'interface web CrowdStrike Falcon, sous Support and Resources → API clients and keys.

Notez que le Collecteur CrowdStrike nécessite les privilèges Alerts: Read and Write conformément à la documentation.

Panneau de création de credentials : les privilèges spécifiquement sélectionnés sont "Alerts: Read and Write", et aucun autre.

Exemple de credentials créés dans CrowdStrike (note : ces credentials sont uniquement à des fins d'exemple)

Le fichier .env correct ressemblerait à quelque chose comme :

Copied!

1# L'URL racine publique de l'instance OpenAEV
2OPENAEV_URL=https://openaev.corporate.example
3# Un token API de niveau admin ; il peut être trouvé sous l'accès API à /admin/profile
4OPENAEV_TOKEN=aa37558b-a934-4c5c-ab17-cb3940c4403b
5# Une chaîne globalement unique : OpenAEV gère bien les UUIDv4 pour cela
6COLLECTOR_ID=6fab3a73-1a3e-4791-831c-946274a15407
7# L'URL de l'API Crowdstrike. Selon votre abonnement,
8# elle peut contenir un identifiant de shard, par exemple "us-2"
9CROWDSTRIKE_API_BASE_URL=https://api.us-2.crowdstrike.com
10# ce qui suit est la paire ID/secret fournie avec le contrat Crowdstrike
11CROWDSTRIKE_CLIENT_ID=2dac83cfba964c129c5365ca228e07f4
12CROWDSTRIKE_CLIENT_SECRET=tpx9M4U5kqDROhVdWo06wG7An182BZTvf3JibeNF
Copy

Ensuite, le lancement de la stack devrait animer le Collecteur, qui commencerait à surveiller les résultats :

Copied!

1$ docker compose up
2{"timestamp": "2025-06-30T19:00:29.900566Z", "level": "WARNING", "name": "CrowdStrike Endpoint Security", "message": "DEPRECATED: this collector should be migrated to use <class 'pyobas.daemons.collector_daemon.CollectorDaemon'>."}
3{"timestamp": "2025-06-30T19:00:30.947613Z", "level": "INFO", "name": "CrowdStrike Endpoint Security", "message": "Starting PingAlive thread"}
4{"timestamp": "2025-06-30T19:00:31.738764Z", "level": "INFO", "name": "CrowdStrike Endpoint Security", "message": "No alerts ID found for this specific parameters :{'filter': \"timestamp:>'2025-06-30T18:15:30.947780+00:00'+type:'ldt'\"}"}
5{"timestamp": "2025-06-30T19:00:31.738978Z", "level": "INFO", "name": "CrowdStrike Endpoint Security", "message": "Gathering expectations for executed injects"}
6{"timestamp": "2025-06-30T19:00:31.752737Z", "level": "INFO", "name": "CrowdStrike Endpoint Security", "message": "Found 0 expectations waiting to be matched"}
Copy

Implémentation d'un Collecteur personnalisé

Si un Collecteur pour la plateforme de sécurité souhaitée n'est pas détaillé dans la liste des Collecteurs Filigran, il est toujours possible d'en implémenter un nouveau.

Nous recommandons d'utiliser pyobas, le client Python officiel pour l'API OpenAEV, pour implémenter un nouveau Collecteur.

Les étapes de haut niveau pour implémenter un Collecteur sont :

1. Identifier les clés de configuration spécifiques à la plateforme de sécurité nécessaires
2. Créer le code squelette pour le nouveau Collecteur
3. Implémenter la logique principale pour faire correspondre les alertes de la plateforme de sécurité avec les Expectations dans OpenAEV

La documentation OpenAEV comporte une section sur la façon d'implémenter un nouveau Collecteur, avec des diagrammes et des exemples de code : Développement de Collecteur.

Conclusion

Dans OpenAEV, les Collecteurs sont des composants polyvalents qui comblent le fossé entre les résultats des plateformes de sécurité et leur représentation dans l'interface utilisateur d'OpenAEV. Comme une instance OpenAEV peut déployer n'importe quel nombre de Collecteurs (pour chaque plateforme de sécurité souhaitée), une seule instance OpenAEV peut donc surveiller une collection variée de systèmes informatiques et leur état de protection respectif sans autre contrainte que l'existence d'une implémentation de Collecteur pour toute plateforme de sécurité souhaitée.

Prochaines étapes

Les Collecteurs sont un excellent moyen d'étendre les fonctionnalités d'OpenAEV. Nous avons couvert les statuts de détection et de prévention pour les Injects, mais il n'y a aucun obstacle pour couvrir d'autres périmètres, par exemple la réponse humaine.

Nous voulons vous entendre

Avez-vous une question sur les Collecteurs, ou tout autre aspect d'OpenAEV ? Visitez le portail communautaire sur Slack, ou visitez les dépôts OpenAEV de votre choix pour poser des questions.

Pour aller plus loin

• Le portail de documentation OpenAEV
• Code source des Collecteurs OpenAEV maintenus par Filigran
• Le répertoire de l'écosystème d'intégrations OpenAEV
• Images docker officielles OpenAEV