Le SOAR (Security Orchestration, Automation and Response) connecte les outils de sécurité d'un SOC et automatise la réponse aux incidents à travers des playbooks, réduisant le MTTD et le MTTR ; contrairement à un SIEM, qui détecte et corrèle les alertes, le SOAR agit sur elles en orchestrant la réponse.
Le SOAR (Security Orchestration, Automation and Response) est une catégorie de plateformes qui connectent les différents outils de sécurité d'une organisation, automatisent les tâches de réponse répétitives et coordonnent le travail des équipes grâce à des procédures codifiées appelées playbooks. Le terme a été inventé par le cabinet Gartner en 2017 pour décrire la convergence de trois technologies qui existaient auparavant séparément : l'orchestration de la sécurité, l'automatisation et la gestion de la réponse aux incidents. Le problème qu'il résout est concret et mesurable : le centre des opérations de sécurité (SOC) reçoit plus d'alertes qu'il ne peut en investiguer manuellement, et chaque alerte traitée à la main consomme de précieuses minutes qu'un attaquant peut exploiter.
Le problème : la lassitude face aux alertes et le goulot d'étranglement humain
Un SOC moderne intègre des dizaines de sources : pare-feux, EDR sur les postes, proxys, IDS/IPS, journaux cloud et un SIEM qui corrèle le tout. Le résultat est de milliers d'alertes par jour, dont beaucoup de faux positifs. La lassitude face aux alertes est réelle et dangereuse : lorsqu'un analyste examine la trois-centième alerte d'une garde, sa capacité à distinguer une menace réelle diminue fortement. Les deux indicateurs que le SOAR vise à réduire sont le MTTD (Mean Time To Detect) et le MTTR (Mean Time To Respond). Chaque minute compte : un rançongiciel peut chiffrer un réseau en quelques minutes, et le coût d'un incident augmente avec le temps de confinement.
Le SOAR ne remplace pas les analystes ; il les libère des tâches à faible valeur ajoutée. Les tâches mécaniques et déterministes — enrichir une IP avec de la threat intelligence, vérifier le hash d'un fichier sur VirusTotal, isoler un poste, bloquer un domaine sur le proxy, ouvrir un ticket — sont automatisées. Le jugement humain est réservé aux décisions qui l'exigent : confirmer une compromission, autoriser une action de confinement agressive ou déclarer un incident majeur. Cette combinaison d'étapes automatisées et de points de décision humains est appelée human-in-the-loop.
Anatomie d'un playbook : le flux de réponse codifié
Le playbook est le cœur du SOAR. C'est un flux de travail qui décrit, étape par étape et sous une forme exécutable, comment répondre à un type spécifique d'incident. Un playbook bien conçu pour un cas de phishing signalé par un utilisateur pourrait suivre cette séquence : extraire l'URL et les pièces jointes de l'e-mail, les détoner dans un environnement isolé (sandbox), vérifier la réputation du domaine et de l'IP auprès des flux de threat intelligence, rechercher dans le système de messagerie de l'entreprise d'autres destinataires du même message, mettre en quarantaine les copies trouvées, bloquer le domaine sur le proxy et, enfin, avertir l'utilisateur. L'analyste n'intervient que si le verdict est ambigu.
| Technologie | Fonction principale | Question à laquelle elle répond |
|---|---|---|
| SIEM | Collecter et corréler les journaux, générer des alertes | Que se passe-t-il sur mon réseau ? |
| SOAR | Orchestrer les outils et automatiser la réponse | Comment répondre rapidement et de manière cohérente ? |
| EDR/XDR | Détection et réponse sur les postes et télémétrie étendue | Que fait cette machine ou cette identité ? |
| TIP | Gérer la threat intelligence (IoC, TTP) | Ce que j'observe est-il connu comme malveillant ? |
La différence avec un SIEM est importante et souvent source de confusion. Le SIEM détecte : il agrège les journaux, les corrèle et déclenche l'alerte. Le SOAR agit sur cette alerte en orchestrant les outils. C'est pourquoi l'architecture standard fait travailler ensemble le SIEM et le SOAR : le SIEM comme capteur et moteur de corrélation, le SOAR comme bras exécutant et coordinateur des cas. Les plateformes XDR intègrent une certaine automatisation de la réponse, mais le SOAR conserve sa valeur lorsqu'une organisation exploite un écosystème hétérogène de fournisseurs qui doit être orchestré via des connecteurs et des API.
Cadres de référence : du cycle de vie des incidents au dictionnaire des techniques
Le SOAR n'opère pas dans un vide méthodologique. Les playbooks sont conçus à partir de cadres reconnus. Le guide NIST SP 800-61 définit le cycle de vie de la gestion des incidents en quatre phases : préparation ; détection et analyse ; confinement, éradication et récupération ; et activité post-incident (retour d'expérience). La norme ISO/IEC 27035 propose une vision équivalente orientée vers le système de management de la sécurité de l'information, et la famille ISO/IEC 27001 exige des procédures de réponse dans le cadre de ses contrôles.
Pour classer les actions des attaquants et cartographier les défenses, la référence de facto est MITRE ATT&CK, une base de connaissances des tactiques et techniques adverses observées dans le monde réel. Étiqueter chaque playbook avec les techniques ATT&CK qu'il couvre permet de mesurer la couverture défensive et d'identifier les lacunes. Sur le plan réglementaire européen, la directive NIS2, toujours en attente de transposition en Espagne, prévoit pour les entités essentielles et importantes des obligations de gestion et de notification des incidents dans des délais stricts — une alerte précoce sous 24 heures et une notification de l'incident sous 72 heures — ce qui fait de la notification automatisée un cas d'usage direct du SOAR.
Mise en œuvre : par où commencer sans trébucher
Une adoption réaliste du SOAR suit une progression fondée sur la maturité. D'abord, mesurer : quels types d'alertes consomment le plus de temps analyste et sont les plus répétitifs ? Ce sont les candidats à la première automatisation, car ils offrent le meilleur retour pour le risque le plus faible. Ensuite, automatiser l'enrichissement (rassembler le contexte d'une alerte) avant le confinement (agir sur les systèmes), car l'enrichissement présente un risque faible et accélère le tri de l'analyste. Enfin, introduire des actions de confinement avec approbation humaine, et ce n'est qu'une fois que le playbook a démontré sa fiabilité qu'il faut envisager l'automatisation complète des cas les plus clairs.
Un cas d'usage concret : le tri des alertes EDR
Pour rendre la théorie concrète, prenons un scénario courant : une alerte EDR signalant l'exécution d'un processus suspect sur un poste. Sans SOAR, l'analyste doit ouvrir la console EDR, identifier la machine et l'utilisateur, rechercher le hash du binaire dans les flux de réputation, vérifier si le processus est apparu sur d'autres machines, examiner les journaux du SIEM pour reconstituer la chaîne d'événements et, seulement alors, décider. Chacune de ces étapes implique de changer d'outil, de copier des identifiants et d'attendre des réponses ; au total, facilement quinze à vingt minutes par alerte. Multiplié par les dizaines d'alertes similaires d'une garde, le SOC est submergé.
Avec un playbook, ce même tri s'exécute en quelques secondes : la plateforme reçoit l'alerte via API, extrait le hash et le nom de la machine, interroge automatiquement la réputation du binaire et la threat intelligence, vérifie la prévalence du processus sur l'ensemble du parc, récupère les événements corrélés du SIEM et assemble un dossier enrichi avec un verdict préliminaire et un niveau de confiance. L'analyste ouvre un dossier unique avec tout le contexte déjà rassemblé et décide de ce qui compte. Si le verdict est clairement malveillant et la confiance élevée, le playbook peut proposer — ou exécuter avec approbation — l'isolement du poste et la création d'un ticket d'incident. Ce schéma, reproduit pour les types d'alertes les plus fréquents, est là où le SOAR démontre son retour sur investissement.
L'essentiel est que chaque action soit enregistrée : ce qui a été fait, quand, sur quelles données et qui l'a approuvé. Cette piste d'audit facilite non seulement les investigations ultérieures, mais constitue aussi la preuve documentaire qu'exigent les obligations NIS2 et les audits de sécurité. Un SOAR bien gouverné est, en plus d'un accélérateur opérationnel, un système de journalisation qui soutient la conformité réglementaire.
Erreurs courantes lors du déploiement du SOAR
- Automatiser le chaos. Si le processus de réponse n'est pas d'abord défini manuellement, le coder dans un playbook ne fait qu'automatiser le désordre. La procédure avant l'automatisation.
- Actions destructrices sans contrôles. Un playbook qui isole automatiquement les postes peut devenir un déni de service auto-infligé si un faux positif déclenche un isolement massif. Les actions à fort impact doivent nécessiter une approbation humaine.
- Connecteurs fragiles. Le SOAR dépend d'API tierces ; un changement dans une API casse le playbook silencieusement. La santé des intégrations doit être surveillée.
- Métriques de vanité. Se vanter du « nombre d'alertes automatisées » sans mesurer le MTTR réel ou le taux de faux positifs contenus ne démontre aucune valeur.
- Sauter le retour d'expérience. La phase post-incident de NIST alimente l'amélioration des playbooks ; la contourner fige la capacité de réponse.
Questions fréquentes
Le SOAR remplace-t-il les analystes du SOC ? Non. Il élimine le travail mécanique et laisse aux analystes les décisions qui exigent du jugement, du contexte et de l'investigation. L'objectif est qu'une petite équipe puisse gérer un volume d'alertes qui serait autrement ingérable.
Quelle est la différence entre SIEM et SOAR ? Le SIEM détecte en corrélant les journaux et en générant des alertes ; le SOAR orchestre les outils et automatise la réponse à ces alertes. Ils sont généralement déployés ensemble : le SIEM déclenche, le SOAR exécute.
Qu'est-ce qu'un playbook et qui le rédige ? C'est un flux de réponse exécutable pour un type spécifique d'incident. Il est conçu par les analystes et les responsables du SOC à partir de la procédure manuelle existante et en s'appuyant sur des cadres comme NIST SP 800-61 et MITRE ATT&CK.
Le SOAR aide-t-il à la conformité NIS2 ou RGPD ? Oui, indirectement : il automatise la documentation des incidents et la notification aux autorités dans les délais requis, réduisant le risque de manquer les échéances légales de communication des violations.
Conclusion : le SOAR est d'abord une discipline de réponse, avant d'être une technologie
Le piège lorsqu'on évalue le SOAR est d'acheter une plateforme en espérant qu'elle automatisera un SOC immature. La réalité est l'inverse : le SOAR amplifie ce qui existe déjà. Si les procédures de réponse sont écrites, répétées et mesurées, la plateforme les exécute à la vitesse de la machine et libère l'analyste pour ce qu'aucune automatisation ne peut remplacer : comprendre l'intention de l'adversaire et prendre des décisions dans l'incertitude. Si ces procédures n'existent pas encore, le SOAR ne fait qu'accélérer les erreurs. L'ordre correct consiste donc à définir la procédure, à l'étiqueter par rapport à MITRE ATT&CK, à automatiser d'abord l'enrichissement à faible risque et à réserver les actions de confinement agressives à un human-in-the-loop. Mesuré à l'aune du MTTD et du MTTR réels — et non de métriques de vanité —, un programme SOAR bien gouverné transforme un SOC saturé d'alertes en une équipe qui répond en quelques minutes et apprend de chaque incident. Chez Summum Sistemas, nous concevons cette architecture : intégration avec le SIEM existant, playbooks alignés sur NIST SP 800-61 et un modèle de gouvernance qui place les personnes au centre des décisions critiques.