La vision de Cyber Academy
SOAR est la couche qui prend les alertes du SIEM et exécute des playbooks : enrichissement, triage, confinement, ticketing. Objectif : réduire le MTTR et libérer les analystes des tâches de copier-coller. Méfiez-vous des promesses excessives des éditeurs : un SOAR ne vaut que ce que valent les playbooks que vous écrivez et maintenez. La plupart des projets SOAR en échec ont manqué d'auteurs de playbooks.
Ce que le SOAR ajoute par-dessus le SIEM
Security Orchestration, Automation and Response est la couche d'action qui se place derrière la détection. Un SIEM excelle dans la collecte des journaux, leur corrélation et la levée d'alertes, mais il s'arrête à l'alerte.
Le SOAR prend le relais et effectue le travail qu'un analyste réaliserait autrement à la main : il enrichit l'alerte avec des recherches de réputation et du contexte sur les actifs, décide de son degré d'urgence, ouvre ou met à jour un ticket et, lorsque la politique l'autorise, prend des mesures de confinement comme isoler un hôte, désactiver un compte ou bloquer un indicateur au niveau du pare-feu.
L'unité de travail dans un SOAR est le playbook, une séquence d'étapes codifiée qui transforme une procédure répétable de traitement d'incident en quelque chose que la plateforme peut exécuter seule.
L'orchestration et l'automatisation sont deux idées distinctes que l'acronyme regroupe. L'orchestration, c'est le câblage : connecter le SIEM, l'EDR, le système de ticketing, le fournisseur d'identité, les flux de renseignement sur les menaces et le pare-feu pour qu'ils puissent s'échanger données et commandes via une seule console. L'automatisation, c'est ce qui s'exécute à travers ce câblage sans intervention humaine.
La plupart des équipes matures conservent un point de validation humain sur les étapes destructrices : la plateforme enrichit et trie automatiquement, mais attend qu'un analyste confirme avant de mettre en quarantaine un serveur de production. Ce mélange, le travail fastidieux automatisé avec le jugement humain sur les actions lourdes de conséquences, est ce que les praticiens déploient réellement.
SIEM, SOAR et le SOC
Ces trois termes vont de pair et sont faciles à confondre. Ce ne sont pas des produits concurrents. Ils décrivent des rôles différents au sein d'une même opération de détection et de réponse.
| Terme | Ce que c'est | Son rôle |
|---|---|---|
| SIEM | Une plateforme | Collecte et corrèle les journaux et la télémétrie, puis lève des alertes lorsque quelque chose semble anormal. |
| SOAR | Une plateforme | Reprend ces alertes et exécute des playbooks : enrichissement, triage, confinement, ticketing. |
| SOC | Une équipe et une fonction | Les analystes et le processus qui exploitent les deux, enquêtent sur ce que les outils font remonter et décident de la marche à suivre. |
Lisez cela comme un pipeline. Le SIEM trouve le signal, le SOAR effectue le travail de réponse répétable autour de ce signal, et le SOC, ce sont les personnes qui possèdent toute la boucle et gèrent tout ce que les playbooks ne peuvent pas traiter. La valeur la plus évidente du SOAR porte sur le volume : signalements de phishing, alertes de malwares courants, connexions suspectes. Tout ce qui arrive en masse et suit un schéma de traitement prévisible est candidat à un playbook, et c'est de là que vient la réduction du temps moyen de réponse, et pourquoi les analystes cessent de passer leur poste sur de l'enrichissement en copier-coller.
Pourquoi les projets SOAR réussissent ou échouent
La shortDefinition est sans détour sur le piège, et cela correspond à ce qu'on observe sur le terrain : un SOAR ne vaut que ce que valent les playbooks que vous écrivez et maintenez, et la plupart des projets SOAR ayant échoué se sont retrouvés à court d'auteurs de playbooks. La plateforme est livrée avec des connecteurs et un moteur de workflow, mais elle est livrée sans aucune connaissance de votre environnement. Chaque playbook doit être conçu, construit, testé contre de vraies alertes, puis maintenu à mesure que vos outils, votre réseau et vos attaquants évoluent. Un playbook qui appelle une API dépréciée le trimestre dernier est pire que pas de playbook du tout, car il échoue silencieusement en plein milieu d'un incident.
Sous l'angle de la gouvernance, le SOAR est la façon dont plusieurs objectifs de contrôle cessent d'être de simples aspirations. Dans le cadre d'un système de management de la sécurité de l'information ISO/IEC 27001, il soutient le volet technique de la gestion des incidents, de la journalisation et de la surveillance, et il produit un enregistrement cohérent et horodaté de la manière dont chaque incident a été traité, ce qui est précisément la preuve que recherche un auditeur.
Il sous-tend également la capacité de réponse que le NIST Cybersecurity Framework présuppose et que des réglementations comme NIS2 et DORA attendent des organisations, en particulier autour du traitement et du signalement en temps voulu des incidents significatifs. Considérez le SOAR comme un multiplicateur de force pour un processus qui fonctionne, et non comme un substitut au fait d'en avoir un.
Frequently asked questions
01Quelle est la différence entre SIEM et SOAR ?
Un SIEM collecte et corrèle les journaux et lève des alertes. Un SOAR reprend ces alertes et agit dessus en exécutant des playbooks qui enrichissent, trient, créent des tickets et confinent. Le SIEM trouve le signal, le SOAR effectue le travail de réponse répétable qui l'entoure. Ils sont couramment déployés ensemble plutôt que comme des alternatives.
02Le SOAR remplace-t-il les analystes SOC ?
Non. Le SOAR supprime le travail répétitif de copier-coller pour que les analystes puissent consacrer du temps à l'investigation et au jugement. Il a besoin de personnes pour écrire et maintenir les playbooks, pour gérer tout ce que les playbooks ne peuvent pas traiter et pour approuver les actions de confinement lourdes de conséquences. C'est un multiplicateur de force, pas un remplaçant.
03Qu'est-ce qu'un playbook SOAR ?
Un playbook est une procédure de traitement d'incident codifiée et répétable que la plateforme peut exécuter. Un playbook type enrichit une alerte avec du contexte et du renseignement sur les menaces, évalue son urgence, ouvre un ticket et, lorsque la politique l'autorise, prend une mesure de confinement comme isoler un hôte ou désactiver un compte.
04Pourquoi les projets SOAR échouent-ils ?
La plupart s'enlisent parce qu'il ne reste personne pour écrire et maintenir les playbooks. La plateforme est livrée sans aucune connaissance de votre environnement, de sorte que chaque playbook doit être construit, testé et tenu à jour à mesure que les outils et les menaces évoluent. Sans effort de rédaction soutenu, la valeur ne se matérialise jamais.
05Le SOAR est-il obligatoire pour la conformité ?
Aucune norme ne nomme spécifiquement le SOAR. Ses capacités correspondent aux mesures de gestion des incidents, de journalisation et de surveillance d'ISO/IEC 27001 ainsi qu'aux attentes en matière de réponse du NIST CSF et de réglementations comme NIS2 et DORA. C'est un moyen d'opérationnaliser ces obligations de manière cohérente, et non une case à cocher en soi.