SOAR (Security Orchestration, Automation and Response) est une catégorie de plateformes qui relient les différents outils de sécurité d'une organisation, automatisent les tâches répétitives de réponse et coordonnent le travail de l'équipe grâce à des procédures codifiées appelées playbooks. Le terme a été forgé par le cabinet Gartner en 2017 pour décrire la convergence de trois technologies qui vivaient alors 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 d'opérations de sécurité (SOC) reçoit plus d'alertes qu'il ne peut en traiter manuellement, et chaque alerte investiguée à la main consomme de précieuses minutes dont l'attaquant profite.
Le problème : la fatigue des alertes et le goulot d'étranglement humain
Un SOC moderne intègre des dizaines de sources : pare-feux, EDR sur les postes de travail, proxies, IDS/IPS, journaux du cloud et un SIEM qui corrèle tout. Le résultat est des milliers d'alertes quotidiennes, dont beaucoup sont de faux positifs. La fatigue des alertes est réelle et dangereuse : lorsque l'analyste examine la trois centième alerte de son tour de garde, sa capacité à discriminer la menace authentique diminue. Les deux indicateurs que SOAR cherche à réduire sont le MTTD (Mean Time To Detect, délai moyen de détection) et le MTTR (Mean Time To Respond, délai moyen de réponse). Chaque minute compte : un rançongiciel peut chiffrer un réseau en quelques minutes, et le coût d'un incident augmente avec son temps de confinement.
SOAR ne remplace pas l'analyste ; il le libère des tâches à faible valeur ajoutée. Les tâches mécaniques et déterministes — enrichir une adresse IP avec du renseignement sur les menaces, vérifier le hachage d'un fichier sur VirusTotal, isoler un poste de travail, bloquer un domaine dans 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 automatiques avec des points de décision humaine est connue sous le nom d'human-in-the-loop.
Anatomie d'un playbook : le flux de réponse codifié
Le playbook est le cœur de SOAR. C'est un flux de travail qui décrit, étape par étape et de manière exécutable, comment répondre à un type précis 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étonner dans un environnement isolé (sandbox), interroger la réputation des domaines et des IP dans des sources de renseignement, rechercher dans la messagerie d'entreprise d'autres destinataires du même message, mettre en quarantaine les copies trouvées, bloquer le domaine dans le proxy et, finalement, notifier 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 cet équipement ou cette identité ? |
| TIP | Gérer le renseignement sur les menaces (IoC, TTP) | Ce que j'observe est-il connu comme malveillant ? |
La différence avec un SIEM est importante et souvent mal comprise. Le SIEM détecte : il agrège les journaux, les corrèle et déclenche l'alerte. SOAR agit sur cette alerte en orchestrant les outils. C'est pourquoi l'architecture habituelle associe SIEM et SOAR : le SIEM comme capteur et moteur de corrélation, SOAR comme bras exécuteur et coordinateur de l'affaire. Les plateformes XDR intègrent une partie de l'automatisation de la réponse, mais SOAR conserve sa valeur lorsque l'organisation dispose d'un écosystème hétérogène de fabricants qu'il faut orchestrer via des connecteurs et des API.
Cadres de référence : de l'incident au dictionnaire de techniques
SOAR n'opère pas dans un vide méthodologique. Les playbooks sont conçus sur des 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établissement ; et activité post-incident (leçons apprises). La norme ISO/IEC 27035 apporte 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 de l'attaquant et cartographier les défenses, la référence de facto est MITRE ATT&CK, une base de connaissances sur les tactiques et techniques adversariales 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, transposée dans les ordres juridiques nationaux, impose aux entités essentielles et importantes des obligations de gestion des incidents et de notification à l'autorité dans des délais stricts — une alerte précoce en 24 heures et une notification dans les 72 heures —, ce qui fait de l'automatisation de la notification un cas d'usage direct pour SOAR.
Mise en œuvre : par où commencer sans trébucher
Une adoption réaliste de SOAR suit une progression par maturité. Il convient d'abord de mesurer : quels types d'alertes consomment le plus de temps de l'analyste et sont les plus répétitifs ? Ce sont les candidats à automatiser en premier, car ils offrent le meilleur retour avec le moindre risque. Ensuite, on automatise l'enrichissement (recueillir du contexte sur une alerte) avant le confinement (agir sur les systèmes), car enrichir est à faible risque et accélère le triage de l'analyste. Puis on introduit des actions de confinement avec approbation humaine, et ce n'est que lorsque le playbook a démontré sa fiabilité qu'on envisage d'automatiser complètement les cas les plus clairs.
Un cas d'usage concret : triage des alertes EDR
Pour ancrer la théorie dans la pratique, il est utile de suivre un cas courant : une alerte EDR signalant l'exécution d'un processus suspect sur un poste de travail. Sans SOAR, l'analyste doit ouvrir la console EDR, identifier le poste et l'utilisateur, rechercher le hachage du binaire dans des sources de réputation, vérifier si ce processus est apparu sur d'autres postes, consulter 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'un tour de garde, le SOC s'asphyxie.
Avec un playbook, ce même triage s'exécute en quelques secondes : la plateforme reçoit l'alerte via API, extrait le hachage et le poste concerné, interroge automatiquement la réputation du binaire et le renseignement sur les menaces, vérifie la prévalence du processus dans le parc, recueille les événements corrélés du SIEM et compose un dossier enrichi avec un verdict préliminaire et un niveau de confiance. L'analyste ouvre un seul dossier avec tout le contexte déjà réuni et décide sur l'essentiel. Si le verdict est clairement malveillant et que le niveau de confiance est élevé, le playbook peut proposer — ou exécuter avec approbation — l'isolation du poste et l'ouverture du ticket d'incident. Ce schéma, répliqué pour les types d'alertes les plus fréquents, est là où SOAR démontre son retour sur investissement.
La clé est que chaque action soit enregistrée : ce qui a été fait, quand, avec quelles données et qui l'a approuvé. Cette traçabilité facilite non seulement l'investigation ultérieure, mais constitue la preuve documentaire qu'exigent les obligations de NIS2 et les audits de sécurité. Un SOAR bien gouverné est, en plus d'un accélérateur opérationnel, un système d'enregistrement qui soutient la conformité réglementaire.
Erreurs fréquentes lors du déploiement de SOAR
- Automatiser le chaos. Si le processus de réponse n'est pas défini manuellement, le codifier dans un playbook ne fait qu'automatiser le désordre. D'abord la procédure, ensuite l'automatisation.
- Actions destructrices sans contrôle. Un playbook qui isole des postes automatiquement peut devenir un déni de service auto-infligé si un faux positif déclenche une isolation massive. Les actions à fort impact doivent demander une approbation humaine.
- Connecteurs fragiles. SOAR dépend des API tierces ; un changement dans une API peut casser le playbook silencieusement. Il faut surveiller la santé des intégrations.
- Métriques de vanité. Se vanter du « nombre d'alertes automatisées » sans mesurer le MTTR réel ni le taux de faux positifs contenus ne démontre aucune valeur.
- Oublier les leçons apprises. La phase post-incident du NIST alimente l'amélioration des playbooks ; la sauter fige la capacité de réponse.
Questions fréquentes
SOAR remplace-t-il les analystes du SOC ? Non. Il élimine les tâches mécaniques et laisse aux analystes les décisions qui exigent du jugement, du contexte et de l'investigation. L'objectif est qu'une petite équipe gère 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 génère des alertes ; SOAR orchestre les outils et automatise la réponse à ces alertes. Ils sont généralement déployés ensemble : le SIEM déclenche, 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 d'incident. Il est conçu par les analystes et les responsables du SOC à partir de la procédure manuelle existante et de cadres tels que NIST SP 800-61 et MITRE ATT&CK.
SOAR aide-t-il à se conformer à NIS2 ou au RGPD ? Oui, indirectement : il automatise la documentation de l'incident et la notification aux autorités dans les délais exigés, réduisant ainsi le risque de ne pas respecter les délais légaux de communication des violations.
Conclusion : SOAR est une discipline de réponse avant d'être une technologie
Le piège lors de l'évaluation de SOAR est d'acheter une plateforme en espérant qu'elle automatise un SOC immature. La réalité est inverse : 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 résout : comprendre l'intention de l'adversaire et décider dans l'incertitude. Si ce n'est pas le cas, SOAR ne fait qu'accélérer les erreurs. C'est pourquoi l'ordre correct est de définir la procédure, de l'étiqueter en regard de MITRE ATT&CK, d'automatiser d'abord l'enrichissement à faible risque et de réserver les actions de confinement agressives à un human-in-the-loop. Mesuré contre des valeurs réelles de MTTD et MTTR — et non des 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 le NIST SP 800-61 et un modèle de gouvernance qui maintient la personne au centre des décisions critiques.