Qu’est-ce que SOAR et pourquoi est-il essentiel dans la cybersécurité moderne

En cybersécurité, il existe presque autant d’acronymes que de vulnérabilités. Et aujourd’hui, nous allons nous pencher sur l’un des plus importants si l’on souhaite que notre département de cybersécurité fonctionne de manière optimale : SOAR (pour Security Orchestration, Automation and Response, ou en français Orchestration de la sécurité, Automatisation et Réponse).
La mise en œuvre de cette approche conditionnera notre capacité à réagir aux incidents de façon rapide et, surtout, efficace.
Dans cet article, nous allons donc analyser ce qu’est le SOAR, à quoi il sert, comment il fonctionne, et comment il peut démultiplier notre efficacité face aux menaces – ou, au minimum, rendre nos journées un peu plus supportables.

Qu’est-ce que le SOAR ?

Les films donnent l’image d’une cybersécurité incarnée par des hackers ultra-compétents qui s’affrontent dans un terminal, en tapant des incantations incompréhensibles sur un écran noir. Ou qui pianotent frénétiquement des absurdités jusqu’à ce que le plus rapide annonce : « Je suis dedans. »
La réalité est tout autre : des claviers pleins de miettes de chips, des script kiddies recopiant des commandes sans comprendre, des tonnes de spam et de phishing chaque minute, et des utilisateurs qui cliquent exactement là où on leur a dit de ne surtout pas cliquer.
Dans ce contexte, le SOAR est une technologie qui poursuit deux objectifs principaux :

• Orchestrer, c’est-à-dire coordonner de manière synchronisée les réponses appropriées aux menaces majeures.
• Automatiser autant que possible, les réponses efficaces aux menaces fréquentes et répétitives.

Aujourd’hui, déployer un SOAR est essentiel pour les organisations présentant un minimum de complexité, de taille ou d’importance stratégique. Pourquoi ? Parce que la cybersécurité moderne ressemble davantage à “mourir à petit feu par mille coupures” qu’à un duel contre des attaquants hyper sophistiqués lançant des attaques zero-day de pointe.
Scans de ports constants, milliers d’emails de phishing, réutilisation de credentials compromis disponibles sur le dark web… Nous sommes comme Gulliver, submergés par une armée de lilliputiens numériques.
Dans ce contexte, il faut automatiser la réponse, sinon vos experts passeront leur temps à gérer manuellement des menaces basiques. Un gaspillage pur et simple de ressources.
Le SOAR permet d’exécuter automatiquement ces tâches lourdes, répétitives mais indispensables, Il ne remplace pas le SOC : il soulage sa charge, en libérant les analystes humains pour qu’ils se consacrent à des tâches complexes à forte valeur ajoutée (comme saturer la bande passante avec tous les épisodes de Star Trek), pendant que les réponses automatisées s’occupent des blocages d’IP ou de la gestion du phishing.

Sans SOAR, nous sommes plus vulnérables. Car pendant que nos experts attribuent des tickets ou mettent à jour des listes de blocage, un hacker s’introduit par un appareil IoT, se déplace latéralement jusqu’à une imprimante, puis cherche à compromettre d’autres équipements et à élever ses privilèges – tout cela pendant que nos “gardiens du temple” gèrent encore à la main une énième attaque DDoS.

Composants clés d’une solution SOAR

Les piliers qui soutiennent une solution SOAR sont précisément ceux indiqués par son acronyme :

• Orchestration.
• Automatisation.
• Réponse.

L’orchestration signifie la coordination des outils et systèmes de sécurité, tels qu’un SIEM, des EDRs, des pare-feux, etc. Selon la solution choisie, cette orchestration peut s’effectuer via des API, des connecteurs ou d’autres moyens.
Cette orchestration permet ensuite l’automatisation de contre-mesures, qui constitue le second pilier fondamental d’un SOAR.
Un exemple très simple serait l’analyse des pièces jointes dans les emails. Dans l’outil SOAR, on peut créer un flux de réponse (appelé playbook, que nous approfondirons plus tard) pour ce type de cas. Ce playbook pourrait analyser les pièces jointes, vérifier s’il s’agit de malwares et, dans ce cas, bloquer l’expéditeur et placer le message en quarantaine. Peut-être même envoyer une alerte à cet expéditeur s’il appartient au domaine de l’entreprise, en suspendant préventivement son compte.
Les playbooks de réponse automatisée peuvent être extrêmement flexibles, et grâce à eux, vous n’aurez pas besoin de gaspiller cinq années d’ingénierie à analyser des fichiers attachés ou à bloquer manuellement des comptes.
Enfin, vient le troisième pilier : la réponse. Dans bien des cas, elle est déjà intégrée aux flux automatisés mentionnés ci-dessus, mais elle peut varier selon le type de menace.
Par exemple, pour des incidents simples comme celui-ci, on peut automatiser ce blocage de compte préventif. Dans d’autres cas, le playbook peut exiger une validation humaine, en générant par exemple un message destiné au SOC afin qu’il prenne une décision ou intervienne manuellement.

Comment fonctionne un SOAR ?

Au cœur du fonctionnement d’un SOAR se trouvent les playbooks dont nous avons parlé précédemment.
Un playbook (ou « livre de jeux », un terme emprunté au football américain, où il désigne des stratégies prédéfinies que les joueurs connaissent et que les leaders activent sur le terrain) est un flux de travail automatiséqui indique au SOAR ce qu’il doit faire dans chaque situation.
Selon l’outil SOAR choisi, la création de ce flux peut se faire en code (Python, par exemple) ou via des interfaces low-code ou no-code.
Par exemple, Splunk SOAR permet de définir des playbooks de manière visuelle, en créant un diagramme de flux indiquant les actions à entreprendre dans chaque scénario, sans avoir à écrire de conditions « if » en ligne de commande.
Un exemple de flux de travail typique serait le suivant :

• Le SIEM envoie une alerte concernant un email potentiellement malveillant, une information transmise par l’EDR installé sur un endpoint, comme l’ordinateur portable du CEO.
• Le SOAR reçoit l’alerte et déclenche le playbook correspondant.
• Les premières actions de réponse automatique sont exécutées, comme l’isolement de l’email suspect..
• Ensuite, le playbook peut comporter des décisions conditionnelles, ce qui offre de la flexibilité. Par exemple : si l’email provient de l’extérieur et que l’expéditeur ne nous avait jamais contacté auparavant, le message est supprimé, l’expéditeur bloqué, et personne n’est dérangé — ce type d’événement survient des dizaines de fois par jour. Le SOAR consigne tout cela dans un journal pour référence.
• Si, en revanche, l’email provient de notre domaine interne, le playbook peut estimer que le danger est plus élevé — une mauvaise configuration DMARC, par exemple — et dans ce cas, déclencher une action hybride. Il place le message en quarantaine, crée une alerte avec toutes les informations utiles et l’envoie au SOC pour enquête.

Il est important de ne pas confondre un playbook avec un runbook. Ce dernier est un processus linéaire, comme une recette de cuisine, qui décrit étape par étape comment effectuer une tâche (par exemple, redémarrer un service tombé en panne).
Les playbooks, quant à eux, sont souvent plus complexes et non linéaires, prenant des décisions basées sur des conditions spécifiques plutôt que de suivre toujours la même séquence d’étapes comme le ferait un runbook.

Avantages de l’implémentation d’un SOAR dans votre organisation

Les avantages d’un SOAR sont clairs. À notre petit armée de cybersécurité, nous ajoutons des drones automatisés qui se déploient sur le champ de bataille dès que la surveillance de sécurité détecte quelque chose. Cela nous permet d’éliminer ces « petites coupures » constantes qui saignent nos ressources.

Cela se traduit par :

• Une réduction des temps moyens de détection et de réponse (respectivement MMTD et MMTR pour leurs sigles en anglais).
• Une augmentation de la capacité de réponse sans accroître les effectifs humains du SOC.
• Un meilleur respect des normes de conformité, en définissant des playbooks qui sauvegardent automatiquement les informations nécessaires pour les audits judiciaires ou prouvent que nous surveillons activement notre infrastructure IT.
• Une réduction des erreurs humaines, dans les réponses, notamment dans les tâches répétitives, sujettes aux fautes dues à la fatigue ou au manque d’attention.
• Une réponse standardisée et plus efficace, fondée sur des playbooks mettant en œuvre les meilleures pratiques.

Cas d’utilisation courants d’un SOAR

Nous avons déjà vu des exemples de menaces pour lesquelles un SOAR est idéal afin d’éviter de rendre (encore plus) fous nos ingénieurs, mais d’autres cas d’utilisation fréquents sont :

• La mitigation de phishing ou de malware, déjà illustrée dans les exemples précédents.
• Une meilleure gestion des alertes et des faux positifs à condition que les règles des playbooks soient bien définies, comme par exemple ignorer les tentatives de connexion depuis des IP internes.
• Une enquête plus rapide sur les incidents, par exemple en consolidant dans une seule réponse le journal de l’Active Directory, ceux du firewall et de l’EDR, au lieu que le SOC doive fouiller dans chacun séparément.
• La mitigation automatique des attaques DDoS.
• L’automatisation de la conformité réglementaire (rapports d’audit, enregistrement de chaque action lors d’un incident…).
• L’automatisation du patching des vulnérabilités sur des systèmes non critiques.
• Le blocage des comptes d’agents malveillants internes (par exemple lorsqu’on détecte des téléchargements massifs de données).
• Etc., etc.

Différences entre SOAR et SIEM : rivalité ou complémentarité ?

En cybersécurité, comme dans la vie, il n’existe ni noir ni blanc, ni frontières toujours bien délimitées. De plus, il y a une tendance naturelle pour les outils à vouloir élargir leurs fonctionnalités.
Ainsi, par exemple, un logiciel IDS comme Snort est fortement incité à ne pas seulement scanner le réseau, mais aussi à ajouter des capacités de prévention, devenant ainsi un IPS.
Un SIEM et un SOAR occupent généralement une « position contiguë » au sein de l’architecture de cybersécurité. C’est pourquoi ils ont tendance à flouter la frontière qui les sépare, chacun adoptant parfois des fonctionnalités de l’autre pour rendre sa solution plus attrayante.
Cependant, SIEM et SOAR restent deux spécialistes d’élite, chacun dans son domaine :

• Le SIEM est l’expert en analyse d’informations, en corrélation des données pour les transformer en savoirs exploitables, et même en prédiction de menaces potentielles invisibles à première vue grâce au Machine Learning.
• Le SOAR est l’expert en réponse basée sur ces informations, capable d’agir avec plus de souplesse et de puissance.

Ainsi, un SIEM peut inclure quelques fonctions de réponse automatisée, et un SOAR quelques capacités d’analyse, mais la clé d’une sécurité optimale réside dans la collaboration étroite entre les deux spécialistes.
Cependant, il est vrai que la qualité de la réponse dépendra de la qualité des informations fournies.
Sinon, le SOAR commencera à bloquer massivement des IPs inutiles si les données reçues sont médiocres, ou à supprimer des emails qui auraient dû être livrés. D’où l’importance cruciale d’un SIEM solide, capable d’agréger et d’analyser correctement les données avant d’alerter le SOAR.
En résumé :

Intégration de SOAR avec d’autres outils de sécurité

Un SOAR ne peut pas fonctionner seul. Il dépend, comme nous l’avons vu, de sa connexion à un SIEM (le cas échéant) ou à d’autres programmes (comme un IDS) pour savoir sur quoi agir. Mais il dépend également de sa capacité à se connecter à d’autres dispositifs pour pouvoir exécuter ses playbooks. C’est là toute l’orchestration évoquée dans son nom, dirigeant les autres éléments avec sa baguette pour répondre aux menaces.
C’est ici qu’entre en jeu l’importance des API et des connecteurs : ils doivent être faciles à configurer et la solution doit savoir travailler en équipe.
Prenons un exemple d’architecture SOAR moderne et voyons comment ses connexions fonctionneraient dans un cas simple de malware.

• Un employé mécontent arrive au bureau avec une clé USB pleine de mauvaises intentions.
• Il exécute le malware contenu dessus, mais l’EDR surveille cette action et, étant connecté à un SIEM, lui communique l’incident. Le SIEM détermine qu’il s’agit d’une menace et alerte le SOAR.
• Le SOAR déclenche alors le playbook défini pour ce type de situation, en se connectant à l’EDR pour bloquer l’exécution du fichier.
• En parallèle, le SOAR contacte VirusTotal via une API pour lui envoyer le fichier suspect.
• Si VirusTotal confirme qu’il s’agit bien d’un malware, le SOAR agit de nouveau : il se reconnecte à l’EDR pour isoler le poste de travail concerné, et génère un ticket dans le système de gestion pour informer le SOC de l’incident et de l’identité de la personne impliquée.

Comme on peut le voir, le SOAR dépend de ces connexions avec d’autres technologies — à la fois en réception et en action — pour orchestrer et automatiser la réponse.

Considérations pour mettre en place une solution SOAR

Après avoir lu cela, tout responsable de cybersécurité voudra sûrement disposer de cette armée de petits « robots programmables », qui aident dans les tâches fastidieuses sans jamais demander à manger ni se plaindre, contrairement à leurs ingénieurs.
Cependant, le SOAR n’est pas la solution miracle pour toutes les organisations. Avant de se lancer, certaines considérations doivent être prises en compte.
La première : une analyse des besoins.
En fonction de nos ressources et de l’infrastructure à protéger, il se peut qu’un SOAR ne soit pas nécessaire et que d’autres solutions offrant une réponse partiellement automatisée soient suffisantes. Il faut garder à l’esprit qu’un SOAR ajoute de la complexité à plusieurs niveaux, et il convient de se poser des questions clés, comme :

• Consacrons-nous beaucoup de temps à des tâches répétitives ? Si ce n’est pas le cas, un SOAR sera d’une utilité limitée.
• Avons-nous des solutions SIEM, IDS, etc., capables de bien se coordonner ? Parce qu’un SOAR n’agit pas seul.
• Avons-nous des processus préexistants, mais peu automatisés, susceptibles d’être délégués au SOAR ?

Si l’analyse montre qu’un SOAR est nécessaire, alors vient le moment de choisir parmi les options disponibles. Comme toujours dans la vraie vie, la première contrainte sera budgétaire, la seconde, la complexité technique.
Il existe des solutions open source comme Shuffle, qui offrent des capacités de réponse automatique, mais leur configuration est relativement complexe.
Et bien que j’adore l’open source par-dessus tout, si nous sommes une organisation stratégique ou exposée à des risques, une solution commerciale est probablement plus adaptée. Splunk, récemment acquise par Cisco, est l’une des options les plus réputées, mais pas la seule :Fortisoar de Fortinet ou Microsoft Sentinel sont également parmi les choix les plus courants.
Ensuite viennent le déploiement et l’intégration, qui dépendront de l’outil sélectionné.
Après le déploiement, il faudra effectuer des tests limités, essayer quelques playbooks, vérifier leur bon fonctionnement, puis les déployer « en production » et continuer les tests progressivement.
De plus, un SOAR transforme les processus de sécurité du SOC.
Il faudra donc non seulement former le personnel sur la nouvelle solution, mais aussi accompagner le changement de rôles, car beaucoup de tâches monotones (heureusement) seront automatisées, permettant aux équipes humaines de se concentrer sur d’autres responsabilités à plus forte valeur ajoutée.

SOAR dans l’écosystème de Pandora FMS

Pandora SIEM est le meilleur allié au sein d’une architecture de sécurité intégrant un SOAR. Placé juste « en amont » de ses capacités d’action, il fournit des fonctionnalités avancées de renseignement et d’alerte, multipliant ainsi l’efficacité et allégeant la charge de travail.
Le fait que Pandora SIEM agisse comme un centre d’intelligence réduit l’exécution de playbooks inutiles ou contre-productifs — parce qu’encore une fois, des machines ont été bloquées suite à de fausses alertes, et tout le monde crie pendant que nous essayons de réduire le temps d’arrêt en rêvant secrètement de devenir jardiniers.
L’intégration avec l’écosystème Pandora ne se limite pas au SIEM, mais s’étend également à l’ITSM en général, rendant la gestion quotidienne beaucoup plus fluide.
Par exemple, Pandora SIEM détecte une activité malveillante et envoie une alerte au SOAR. Ce dernier déclenche alors le playbook approprié, mais imaginons qu’il s’agisse d’un incident sérieux : les actions automatiques permettront d’atténuer le problème sans le résoudre complètement.
Dans ce cas, le SOAR peut créer un ticket dans Pandora ITSM pour l’équipe SOC, en y incluant toutes les informations nécessaires, réduisant ainsi considérablement les délais de réponse et de résolution.
Ou bien, il peut s’agir d’une fausse alerte, comme lorsqu’un scan de ports est effectué par notre propre Équipe Bleue pour vérifier d’éventuelles failles. Le SOAR détecte cela et, conformément à son playbook, ferme automatiquement le ticket dans Pandora ITSM en documentant l’incident et ses raisons.
De cette manière, le SOC est libéré pour se concentrer sur des tâches à haute priorité — comme jouer en ligne pendant les heures de bureau sans que personne ne s’en rende compte.
Comme nous pouvons le constater, un SOAR permet d’atténuer l’un des problèmes les plus répandus dans la cybersécurité actuelle. Toutefois, il nécessite une analyse préalable de sa pertinence, ainsi qu’un budget et un temps de configuration et de mise en œuvre.
Mais s’il est bien déployé, il augmentera considérablement notre capacité de réponse, en déployant de véritables « drones robotisés » sur le champ de bataille, nous libérant des tâches répétitives.