La mise en œuvre des plateformes SIEM et SOAR : guide du praticien

Je vous propose un second article sur le déploiement et l’usage d’un SIEM couplé à un SOAR suite aux publications de la CISA en collaborations avec d’autres agences de cybersécurité. J’ai orienté cet article pour qu’il résume les points saillants à destination des professionnels (CERT, CSIRT, SOC, RSSI).

Cette seconde synthèse en français, permet aux utilisateurs de ce type de plateforme d’appréhender la mise en œuvre des plateformes SIEM et SOAR

Je vous recommande fortement la lecture en anglais de l’ASD car elle contient des informations techniques pour vous permettre de concevoir/organiser ce type de plateforme.

Ce que j’ai retenu c’est que les plateformes SIEM et SOAR jouent un rôle clé dans la cybersécurité moderne en améliorant la visibilité du réseau, la détection des menaces et la capacité de réponse aux incidents.

Les plateformes SIEM et SOAR jouent un rôle clé dans la cybersécurité moderne en améliorant la visibilité du réseau, la détection des menaces et la capacité de réponse aux incidents. Publié le 27 mai 2025, un guide pratique rédigé par plusieurs agences de cybersécurité* décrit ces technologies, leurs bénéfices, un cas d’usage face aux menaces dites Living off the Land (LOTL), les défis liés à leur implémentation et les principes de bonnes pratiques pour les déployer efficacement.

Définition des plateformes SIEM et SOAR

Le SIEM (Security Information and Event Management). Une plateforme SIEM est un logiciel (ou appliance) qui collecte, centralise et analyse les journaux (logs) de sécurité provenant de multiples sources au sein d’un réseau ou système informatique. Elle automatise la collecte et la centralisation des logs importants dispersés dans l’environnement, facilitant ainsi leur examen par les analystes.

Un SIEM bien configuré applique des règles de corrélation et une ligne de base d’activité normale du réseau pour détecter des comportements inhabituels susceptibles d’indiquer un incident de sécurité. La plupart des SIEM intègrent des flux de renseignement sur les menaces afin d’enrichir l’analyse et d’identifier plus rapidement les attaques connues.

De plus, les SIEM offrent des tableaux de bord, rapports et alertes, et permettent des requêtes d’analyse (via un langage propre à chaque produit) exécutées périodiquement ou à la demande, par exemple pour investiguer une activité anormale ou réaliser une analyse forensic après un incident.

Le SOAR (Security Orchestration, Automation and Response). Une plateforme SOAR est un outil logiciel destiné à automatiser la réponse aux activités anormales détectées sur le réseau.

Elle exécute des playbooks prédéfinis – combinant procédures de réponse à incident et plans de continuité d’activité – qui dictent les actions à mener face à un type d’alerte donné.

L’objectif est d’accélérer et d’orchestrer la réponse aux incidents sans remplacer les opérateurs humains, qui restent indispensables pour les décisions critiques.

Selon les produits, un SOAR peut s’appuyer sur un SIEM externe pour la collecte et l’analyse des journaux, ou disposer de son propre module de SIEM intégré. Les SOAR s’interfacent également avec divers autres outils de sécurité (pare-feux, solutions EDR, scanners de vulnérabilités, etc.) afin d’exécuter automatiquement des mesures de défense sur ces systèmes lorsqu’un incident est confirmé.

Les bénéfices attendus des SIEM/SOAR

Grâce à l’automatisation, les SIEM et SOAR renforcent considérablement les capacités d’un centre opérationnel de sécurité en termes de visibilité du réseau, de détection des menaces et de réponse aux incidents. Lorsqu’ils sont correctement implémentés et maintenus, ces outils contribuent à améliorer la sécurité du système d’information et l’intégrité des données en permettant d’identifier plus vite les activités suspectes et d’y répondre de manière appropriée. Les bénéfices majeurs incluent :

Visibilité accrue sur le réseau : en centralisant automatiquement les journaux et en les corrélant, un SIEM offre une vue d’ensemble de l’activité du réseau autrefois dispersée. Les équipes de sécurité peuvent ainsi interpréter plus facilement ce qui se passe dans l’infrastructure, au moyen de tableaux de bord et rapports unifiés. Par ailleurs, l’accès aux données d’événements s’en trouve simplifié lors des investigations, sans devoir collecter manuellement des logs sur chaque machine. Ceci réduit le risque de manquer des indices critiques disséminés sur différents systèmes.
Amélioration de la détection : un SIEM continuellement affiné génère des alertes rapides en cas d’activité anormale, ce qui renforce la détection précoce des cybermenaces. La collecte automatisée et l’intégrité des journaux centralisés empêchent également des attaquants de dissimuler leurs traces en modifiant ou supprimant des logs. En outre, l’utilisation de formats de log standardisés et de règles de corrélation éprouvées (communes à la communauté ou fournies par les éditeurs) accélère le déploiement de nouvelles détections et augmente la capacité à repérer des comportements suspects sur le réseau. Un SIEM bien maintenu aide aussi à filtrer les faux positifs, en distinguant les anomalies réellement malveillantes de l’activité légitime, afin de ne pas submerger les analystes d’alertes inutiles.
Réponse aux incidents accélérée : en générant des alertes en temps opportun, un SIEM/SOAR permet à l’organisation d’agir plus rapidement pour contenir un incident avant qu’il ne s’aggrave. Les journaux centralisés et les alertes corrélées fournissent aux intervenants une vision consolidée de ce qui s’est produit, facilitant les analyses post incident et la détermination des mesures à prendre. Un SOAR apporte en complément la rapidité de l’automatisation : il peut exécuter instantanément des actions de réponse prédéfinies (isolement d’un hôte, blocage d’une adresse IP, etc.), ce qui accélère la mitigation tout en laissant aux experts humains le soin de traiter les volets complexes de l’incident. L’automatisation permet ainsi de contrer les attaquants utilisant des techniques scriptées en égalant leur vitesse d’exécution, tout en évitant de ralentir la réaction globale du fait de tâches manuelles répétitives.

Un cas d’usage : menaces « Living off the Land » (LOTL)

Les attaquants informatiques exploitent souvent des outils et fonctionnalités légitimes du système cible pour accomplir leurs objectifs malveillants. Cette technique, connue sous le nom de Living off the Land (LOTL), est particulièrement difficile à détecter et à contrer, car les actions malveillantes se fondent dans l’activité normale de l’environnement.

Une implémentation robuste de SIEM/SOAR aide néanmoins à déceler et neutraliser ce type de menace furtive en s’appuyant sur plusieurs capacités :

La consolidation des journaux multi-sources : la collecte centralisée des logs issus des équipements réseau, des endpoints et autres systèmes renforce l’intégrité des journaux et empêche les acteurs malveillants d’effacer ou modifier ces traces pour masquer leurs activités. Un référentiel unifié fournit en outre une vue holistique de toutes les actions se déroulant dans l’environnement, évitant les angles morts dans la surveillance.
Les règles de détection des actions suspectes : la mise en place de règles d’analyse sur les logs collectés permet d’identifier des indicateurs typiques des techniques LOTL, tels que l’exécution de scripts ou d’outils intégrés de manière inhabituelle, ou encore des tentatives d’accès système anormales par rapport aux habitudes de l’organisation. Ce type de corrélation aide à distinguer les activités légitimes de l’utilisation malveillante d’outils légitimes.
La baseline comportementale : l’établissement d’une base de référence du comportement normal des utilisateurs et des applications dans un SIEM sert de point de comparaison pour repérer des écarts inexpliqués. Toute déviation significative par rapport à cette ligne de base peut révéler une activité LOTL indésirable. Par ailleurs, l’utilisation éventuelle de fonctions d’apprentissage automatique d’un SOAR contribue à détecter des schémas anormaux dans les comportements système ou utilisateur, y compris ceux associés à des escalades de privilèges discrètes ou à l’usage détourné d’outils d’administration courants.
Les renseignements sur les menaces intégrés : un SIEM (ou SOAR) devrait ingérer des flux de Threat Intelligence externes afin de rester à jour sur les TTP (tactiques, techniques et procédures) LOTL connues. En combinant ces renseignements avec les journaux et indicateurs comportementaux internes, la plateforme peut déterminer plus rapidement si une action observée est légitime ou malveillante, et adapter ses détections en conséquence.
La réponse automatisée orchestrée : les capacités d’automatisation d’un SOAR, via des playbooks, permettent de contenir proactivement une activité suspecte liée à du LOTL dès son identification. Par exemple, le système peut automatiquement isoler une machine compromise, segmenter ou bloquer le trafic réseau associé, ou révoquer des comptes d’utilisateurs utilisés à des fins malveillantes. Ces mesures immédiates limitent les dégâts potentiels tout en alertant parallèlement les équipes de sécurité pour investigation approfondie.
L’intégration avec d’autres outils de sécurité : un SIEM/SOAR combiné à des solutions comme l’EDR (Endpoint Detection & Response) renforce la réaction en temps réel contre le LOTL. Par exemple, une règle corrélant un événement suspect dans le SIEM peut déclencher via le SOAR une action de l’EDR pour bloquer un script PowerShell ou un outil d’administration légitime utilisé abusivement par un intrus. Cela améliore la capacité globale de l’organisation à détecter, interrompre et remédier à ce type d’attaque furtive, qui sans cela pourrait compromettre le système cible sans être détectée.

Quelques défis d’implémentation des plateformes SIEM/SOAR

La mise en place d’un SIEM et/ou d’un SOAR s’accompagne de défis importants qu’il faut anticiper.

Ces plateformes ne sont pas des solutions « plug-and-play » que l’on peut installer puis oublier : elles n’apportent une valeur ajoutée (visibilité, détection, réponse) qu’à condition d’être correctement configurées et continuellement maintenues par du personnel qualifié.

Le guide souligne notamment les points de vigilance suivants :

La normalisation des données de journaux : un SIEM agrège des logs provenant de sources hétérogènes (pare-feu, IDS/IPS, postes de travail, applications, etc.), chacune ayant son format propre. Il est donc crucial de parser correctement les données, de standardiser la terminologie des champs (par ex. adresses IP source) et d’assurer la synchronisation temporelle des événements collectés (prise en compte des fuseaux horaires). Sans normalisation, l’analyse corrélée sera partielle ou erronée.
La couverture de collecte : la portée de l’ingestion des logs doit couvrir l’ensemble de l’infrastructure, en fonction des priorités de risque de l’organisation. Des sources non intégrées laissent des zones d’ombre dans la surveillance. Par exemple, si les journaux de seulement 10 contrôleurs de domaine sur 12 sont collectés, le SIEM aura des blind spots sur les 2 serveurs manquants. À l’inverse, pour des raisons de coût ou de charge, une organisation peut délibérément choisir de n’ingérer qu’un échantillon représentatif de certaines sources (par exemple un sous-ensemble de postes clients) après évaluation des risques acceptables. L’important est de connaître et de documenter ces limites de couverture.
La centralisation versus analyse : un écueil courant est d’utiliser le SIEM principalement comme un dépôt central de logs à des fins de conformité, en y envoyant un très gros volume de données peu exploitable. Cette approche n’est pas recommandée. En effet, un SIEM saturé de logs non pertinents consommera des ressources importantes et générera un flot d’alertes peu utiles qui diluent les vrais signaux d’attaque. Il est plus efficace de n’envoyer vers le SIEM que les données ayant une valeur de sécurité, les autres logs pouvant être conservés dans des outils de stockage ou data lakes séparés dédiés à l’archivage ou à la conformité. Cette sélectivité permet de réduire le bruit et de focaliser l’analyse sur les événements significatifs.
La qualité de l’analyse et faux alertes : atteindre une analyse de logs efficace nécessite une configuration minutieuse et évolutive du SIEM. L’objectif est d’obtenir principalement des vrais positifs (alertes pertinentes en cas d’incident réel) et des vrais négatifs (pas d’alertes en l’absence d’incident). Pour cela, il faut continuellement ajuster les règles et filtres : c’est un effort de longue haleine, car l’environnement technique et les techniques d’attaque évoluent sans cesse. Si les données ingérées sont incomplètes ou les règles trop laxistes, le SIEM manquera des incidents (faux négatifs). Inversement, des règles trop sensibles ou une ingestion trop large produiront des faux positifs massifs (alertes sans incident réel). Un trop grand nombre de fausses alertes conduit à une fatigue des analystes (alert fatigue), qui risquent de manquer les vraies menaces noyées dans la masse. Trouver le bon équilibre est donc indispensable. À noter qu’un SIEM mal calibré peut aussi réduire l’efficacité d’un SOAR connecté, par exemple en lui transmettant trop d’alertes erronées à traiter.
Les limites de l’automatisation : pour un SOAR, le principal défi est de paramétrer judicieusement les réponses automatiques. Chaque environnement étant unique, il faut mobiliser des experts de divers domaines (analystes sécurité, ingénieurs plateforme, développeurs, juristes conformité) afin de déterminer quelles parties de la réponse peuvent être automatisées en toute sécurité et dans quelles conditions. Si la configuration n’est pas optimale ou mise à jour, le SOAR pourrait interpréter à tort un comportement légitime comme malveillant et appliquer des mesures inappropriées (isolement de système, blocage, etc.), perturbant le fonctionnement normal de l’entreprise. Par ailleurs, l’organisation doit adhérer à l’outil : si les équipes manquent de confiance ou de compétences pour tirer parti de l’automatisation, le SOAR risque d’être sous-utilisé, voire laissé de côté après son acquisition. En résumé, l’orchestration automatisée nécessite une maturation progressive et une supervision humaine avisée.
Les ressources humaines et les coûts associés : l’implémentation d’une plateforme SIEM/SOAR exige un investissement important et durable en ressources. Les coûts initiaux et récurrents incluent les licences logicielles et l’infrastructure de stockage des données, le recrutement et la rétention de personnels hautement qualifiés (compétences rares en SIEM/SOAR), ainsi que la formation continue des équipes en place pour configurer et faire évoluer la solution. Maintenir la plateforme efficace implique un effort soutenu de mise à jour des connaissances et d’adaptation aux changements technologiques et aux nouvelles menaces. L’organisation doit s’attendre à affecter plusieurs employés à plein temps pour l’administration et l’amélioration du SIEM/SOAR, ce qui peut représenter une charge de travail significative sur la durée. Le recours à un prestataire externe pour la configuration et la maintenance est possible, mais il génère lui aussi des coûts permanents et peut entraîner une perte de visibilité fine sur les activités du réseau. Dans les environnements critiques ou sensibles, il est généralement recommandé de développer une capacité interne afin de garder la maîtrise de la détection et de la réponse, et d’éviter les difficultés de communication ou les lacunes qu’une externalisation pourrait engendrer.

Quelques principes de bonnes pratiques (sélection, déploiement, maintien)

Pour guider les praticiens que nous sommes, le document recense onze principes de bonnes pratiques applicables tout au long du cycle de vie d’un SIEM/SOAR : depuis le choix de la solution jusqu’à son exploitation continue. En voici les grandes lignes, structurées par phase d’implémentation :

La phase de sélection : Il est conseillé de définir clairement le périmètre et les objectifs du projet dès le départ (par exemple via un proof of concept). Cela permet d’aligner le SIEM/SOAR sur les besoins métiers et risques à couvrir, et d’éviter de s’engager trop tôt sur une solution inadaptée.

Lors de l’évaluation des produits, le guide invite à considérer des critères techniques clés : une architecture capable de gérer de gros volumes de données (type data lake), la capacité à corréler des informations issues de multiples sources, ainsi que la compatibilité avec les outils existants via des intégrations tierces (API, etc.).

Je vous recommande fortement d’être attentif aux coûts cachés (stockage additionnel, modules optionnels, frais de support…) afin de comparer le coût total de possession des différentes offres.

Le game changer pour réussir ce type de projet est d’investir dans la formation : disposer de la meilleure technologie sans les compétences pour l’exploiter serait vain, d’où la nécessité de prévoir un budget et du temps pour former les équipes internes sur la nouvelle plateforme.

La phase de déploiement : Durant l’implémentation, plusieurs bonnes pratiques visent à tirer efficacement parti du SIEM/SOAR. D’abord, établir une base de référence de l’activité « normale » sur le réseau est essentiel. Cette baseline initial servira de point de comparaison pour repérer les anomalies une fois la solution en place. Ensuite, il convient de développer des standards de journalisation en définissant précisément quels types de logs seront collectés et comment.

Une collecte homogène et bien documentée facilitera l’intégration des données et la création de règles de corrélation efficaces. Par ailleurs, il est préconisé d’intégrer le SIEM dans l’architecture globale de l’entreprise dès sa mise en œuvre. Cela implique de s’assurer que la plateforme s’interface correctement avec l’infrastructure existante (réseaux, cloud, annuaires, applications métier…) et s’insère dans les processus opérationnels du SOC.

Une intégration planifiée réduit les risques de silos et permet au SIEM/SOAR de devenir un élément central de l’écosystème de sécurité.

La phase de maintien : Une fois le SIEM/SOAR en production, le travail ne s’arrête pas – il s’agit de faire vivre la solution au quotidien pour conserver son efficacité. Un premier principe est d’évaluer régulièrement la qualité de la détection fournie par la plateforme.

Concrètement, cela peut passer par des revues périodiques des alertes (pour affiner les règles ou ajouter de nouvelles détections en fonction des menaces émergentes) et par des tests simulés d’incident visant à vérifier que le SIEM/SOAR alerte correctement et suffisamment tôt.

Un second axe d’optimisation est de réduire l’ingestion de données inutiles grâce à un pré-traitement des logs en amont. En filtrant ou en échantillonnant les événements peu pertinents avant qu’ils n’entrent dans le SIEM, on maîtrise les volumes de données et on diminue les coûts, tout en améliorant les performances d’analyse pour les données réellement critiques.

Pour conclure cette phase, il est indispensable de tester la performance et la résilience de la plateforme de façon continue. Des exercices de charge, des scénarios de réponse automatisée et des audits réguliers de configuration permettront de s’assurer que le SIEM/SOAR tient ses promesses dans la durée (stabilité, rapidité de traitement, capacité à gérer un afflux d’incidents) et de détecter proactivement les besoins de mise à niveau.

Si vous appliquer ces principes de gouvernance, votre organisation augmente ses chances de tirer pleinement parti de son SIEM/SOAR tout en maîtrisant les risques et contraintes liés à son exploitation.

J’espère que cette synthèse vous donnera l’envie d’explorer plus en profondeur l’usage des plateformes SIEM et SOAR au sein de vos équipes de réponse à incidents. Ce que je retiens : il faut expérimenter, ajuster, apprendre de ses échecs… et progresser pas à pas jusqu’à atteindre le niveau de maturité nécessaire pour un SIEM/SOAR réellement efficace.

Enjoy !

Références

** Ce guide intitulé Implementing SIEM and SOAR platforms: Practitioner guidance a été publié conjointement par l’Australian Cyber Security Centre (ACSC), le National Cyber Security Centre néo-zélandais (NCSC NZ) et d’autres partenaires internationaux, à destination des praticiens de la sécurité. Il fait partie d’une série de trois documents couvrant également une vue d’ensemble pour les décideurs et des recommandations techniques sur les journaux à prioriser pour l’ingestion.

Open Source & Outils