Du fait des nombreux outils de sécurité présents dans un SOC, le travail de recherche de renseignements et de traitement suite à un incident de sécurité est très répétitif et chronophage pour les analystes. Certains outils d’automatisation comme le SOAR (Security Orchestration, Automation, and Response) permettent d’anticiper et faciliter le travail de l’analyste. Nous avons cherché à comprendre comment ces outils s’intègrent dans le quotidien des équipes de réponse à incident (IR) et en quoi ils permettent d’optimiser la capacité à répondre et à résoudre les incidents. Pour cela, nous avons interrogé Aurélien Bouzon, Security Engineer & Cybersecurity Analyst chez IMS Networks.

En quoi une plateforme SOAR permet-elle au SOC de gagner en efficacité pour répondre à des incidents complexes ?

AB - Historiquement dans un SOC on opère un SIEM et d’autres outils à proximité viennent l’alimenter en logs comme les EDR, les pare-feux, les proxys, les systèmes d’exploitation etc.
A partir des logs issus des différentes sources, le SIEM a la capacité d'intégrer ces données, de les structurer, de les stocker selon une certaine organisation. Des étapes de parsing, de normalisation, et de corrélation sont réalisées par le SIEM sur les logs reçus pour détecter des comportements définis liés à des activités malveillantes.
Cette approche se prête à de l'information qui est bien structurée.
Cependant, certaines sources de données ne se prêtent plus aussi bien au fait d’être consommées par un SIEM.

Aujourd’hui il existe des outils de détection, comme des EDR.
Ils offrent des interfaces d’analyse plus évoluées, graphiques et adaptées qui permettent de lier les éléments entre eux, de telle sorte que l’investigation soit efficace.. Ce qui veut dire que la donnée exploitée par l’analyste ne va pas toujours provenir du SIEM lui-même.

Le SOAR (Security Orchestration, Automation, and Response) est une plateforme intégrée qui va faciliter la gestion des incidents de sécurité, qui était avant manuelle, principalement à 2 niveaux.

En premier lieu il va permettre d’automatiser et centraliser la recherche et l’analyse d’information relatives à un incident de sécurité. En passant par les API des éditeurs il peut interagir avec plusieurs outils de sécurité différents, pour récupérer des informations, les consolider et lancer des recherches complémentaires.
Par exemple, à partir d’un élément déclenchant comme une alerte sur des tentatives d’authentification douteuses, l’analyste SOC va pouvoir obtenir automatiquement des renseignements complémentaires issus du SIEM, ou de l’EDR dans le SOAR. Il peut ainsi savoir automatiquement depuis combien de temps ce comportement est détecté, avoir une liste de toutes les tentatives douteuses, avoir des informations sur la réputation des IP qui en sont à l’origine en consultant des bases d’IOC ou encore savoir si il y a eu des remontées de l’EDR récemment pour cet utilisateur.

Ces outils d'automatisation permettent de centraliser la recherche au niveau de plusieurs outils de sécurité et croiser les analyses pour éviter à l’analyste ce travail répétitif.
L’intérêt du SOAR c’est de préparer et faciliter le travail de l'analyste en lançant des recherches de manière proactive. Ainsi l’analyste n’a ni à écrire toujours les mêmes requêtes, ni à rechercher manuellement l'information sur 3 ou 4 outils différents, ni à attendre les résultats avant de débuter l’analyse de l’incident.
Le SOAR va lui restituer les résultats de recherche, effectuer des vérifications basiques pour déterminer s’il s’agit bien d’un incident, et peut même proposer une réponse et des actions de mitigation.
En gagnant du temps sur la phase de renseignement, l’analyste va pouvoir se concentrer sur les recherches très précises et à forte plus-value qui ne peuvent pas être automatisées.
Pour des analyses très spécifiques, il arrive que le SOAR ne soit pas en mesure de reproduire toutes les capacités d'analyse des outils tiers. Les analyses doivent alors toujours être réalisées au niveau de chaque outil de sécurité.

Au-delà des capacités de recherche et d’analyse, le SOAR permet de déclencher rapidement des actions de réponse à incident.

Lorsqu’un malware est détecté sur un poste, généralement l'EDR le nettoie automatiquement. Imaginons que le nettoyage échoue, il est possible de faire remonter cette information, et demander, par API, à l’EDR d’isoler automatiquement ce poste-là du réseau. En complément on peut passer des instructions pour commander au pare-feu de bloquer automatiquement l’adresse IP ou MAC pour garantir l’isolation du poste et ainsi éviter que l'infection ne se propage. La capacité de réaction très rapide qu’apporte le SOAR permet de limiter très fortement la capacité de propagation en cas de compromission.

 

Quels sont les cas d’usages d’un SOAR et comment intégrez-vous les playbooks dans votre quotidien ?

AB - Une plateforme SOAR fournit à l’équipe des playbooks préconfigurés de réponse aux incidents (IR). Les playbooks déroulent des actions qui visent à rassembler des renseignements nécessaires pour comprendre le contexte de l’incident ainsi que des conseils pour réagir et résoudre les incidents. L'intégration de ces playbooks dans le quotidien des équipes de sécurité a pour objectif de réduire les temps de réponse critiques.

Le phishing

Par exemple, si vous détectez une tentative de phishing vous exécuterez en premier lieu un playbook qui va vérifier les activités d’authentification de cet utilisateur pour vérifier si ses identifiants ont été compromis. Vous pouvez également lancer un playbook pour vérifier avec les logs proxy si cet utilisateur a tenté d’accéder à des URL réputées malveillantes, par une recherche directe dans les logs ou en vérifiant si un autre incident en lien n’a pas été créé. Dans ce cas de figure nous n’allons pas inclure dans le playbook de vérification ciblée sur l’activité de l’utilisateur sur les espaces de stockage partagés. Au début de l’investigation ce n’est pas la recherche la plus pertinente à mener.

Les playbooks vont assister les analystes en fonction du type d'incident de sécurité à analyser. Par rapport à cette attaque bien particulière, on va éviter de noyer l'analyse avec des tonnes d’informations. En premier lieu on va proposer les informations qui vont vraiment être utiles pour se positionner sur ce type d’incident.

Les playbooks sont définis pour répondre à des cas d’usage, à certaines caractéristiques de menaces.

L’important c’est d’associer au playbook une condition de déclenchement. Quelle est la succession de critères pour exécuter une action ? Le lancement d’un playbook peut être automatique mais peut aussi se faire manuellement.

Cette succession de conditions, présentes dans un playbook, est assez complexe à définir. Ce travail implique du développement. Lorsqu’on développe un logiciel il ne faut pas laisser de zone d'ombre dans l'algorithmique, car c'est là où peuvent se cacher les bugs.

Quand on définit des workflows, c'est exactement le même risque. Il est essentiel de se questionner sur tous les cas de figure qui peuvent se présenter. Et pour chaque cas identifié, prévoir l'issue à donner. Si ma condition d’entrée est de travailler sur telle donnée, il faut prévoir l’hypothèse où la donnée ne sera pas présente, et décider de l’action qui va en découler.

 

Concernant la partie automatisation de la réponse, il y a beaucoup de possibilités avec le SOAR.

Pour des cas de phishing, on peut envisager d'aller supprimer le mail en question dans la boite de l'utilisateur, ou du moins de le mettre en quarantaine. Ces fonctionnalités sont plus ou moins bien intégrées aux outils de sécurité mail. Ensuite on peut chercher le mail considéré comme du phishing et le nettoyer dans les boîtes d'autres utilisateurs. Enfin, on peut forcer la modification du mot de passe de l’utilisateur si l’on estime qu’il a pu être compromis.

Le risque c'est qu’un mail soit identifié comme du phishing alors qu'il n'en est pas. On aura alors détruit un message potentiellement important dans plusieurs mailing lists, c'est toujours la difficulté avec l’automatisation.

Plutôt que de paramétrer le playbook en mode autopilote, je considère que c'est toujours bien qu'un analyste contrôle s'il n’y a pas d'anomalie, le temps d’être certain que les actions de réponse automatiques fonctionnent bien.

Les malware

Si un problème de malware est remonté par l’EDR, on lance un full scan sur la machine et une isolation automatique du poste. On va regarder l'activité de l'utilisateur et définir des critères pour vérifier si l'activité n'a pas varié. On vérifie si on ne détecte pas de flux vers des sites douteux, si on ne voit pas des blocages sur des numéros de port étranges, par exemple.

On pourrait automatiser ces recherches et la réaction automatique mais si vous voulez comprendre pourquoi il y a eu ce malware, c’est là que l’humain apporte de la valeur.

Les DSI que l’on accompagne apprécient qu’on leur rapporte des tendances. Savoir si on a rencontré ce type de malware sur d’autres machines pour en déduire si le parc informatique du client est la cible d’un groupe. Si une menace d'ampleur est en train de vouloir rentrer ou si ce sont des petites menaces diffuses et opportunistes.

L'objectif est de leur apporter de la visibilité sur ce qui se passe en périmétrie, de faire des rapprochements et de corréler les informations sur plusieurs incidents et plusieurs clients.

La règlementation

Un SOAR peut également être une aide précieuse pour les aspects règlementaires. Peu d'outils SOAR le proposent à ma connaissance. En cas d’incident de sécurité l’outil va guider l’analyste sur les questions réglementaires.

Dans le cas d’un ransomware par exemple, on observe l'activité de chiffrement sur le poste infecté et la donnée devient inaccessible. Après avoir privé les gens de leurs données, les attaquants les auront probablement déjà exfiltrées et ils peuvent potentiellement demander une rançon avant de les publier. C’est là que les exigences réglementaires doivent être prises en compte. En tant qu’OIV (Organisme d’Intérêt Vital) il est exigé de notifier l’incident de sécurité auprès de l'ANSSI dans un certain délai.

L’outil SOAR va proposer automatiquement des informations sur la législation en vigueur en fonction du type d’incident, du pays dans lequel l’incident intervient et aussi en fonction du secteur d’activité. Le rapport émis va guider les analystes sur les actions à réaliser auprès des organismes et permettre à l’entreprise attaquée de prendre les décisions nécessaires.

La mise en place d’un SOAR peut s’avérer complexe à mettre en œuvre et à maintenir. Quelles sont les compétences et expertises spécialisées qui sont nécessaires ?

AB - Définir le workflow s’avère assez complexe, et nécessite de s’appuyer sur l’expertise du métier d’analyste. Il est important de savoir quels renseignements sont utiles, quels sont les critères de décision, quels sont les critères de déclenchement d’une action de remédiation et les éléments à apporter aux clients.

Même si les outils SOAR essaient de rendre les choses simples, intuitives et graphiques, il y a toujours des parties de codes à écrire pour retravailler l'information, la trier, paramétrer des conditions et définir les étapes de traitement suivantes. Il faut avoir cette compétence d’analyste et aussi savoir scripter pour paramétrer l’outil SOAR.

Pour recueillir des informations pertinentes, le plus compliqué c'est de s'assurer que les données d'entrée qui vont être utiles à ma requête ou à l’action lancée, sont disponibles et exploitables.

La phase de définition du processus est très importante pour être efficace et prendre le moins de risque possible dans la phase de remédiation automatique. Celle-ci doit faire l’objet d’une réflexion impliquant les experts sécurité et le client.

Nous devons connaitre le périmètre sur lequel on intervient. Les mécanismes doivent être testés et validés par le client au cours d’un POC.

 

Conclusion

En tant que MSSP (Managed Security Service Provider) et prestataire SIEM/SOC il est évident que nous sommes concernés par ce besoin d’automatisation et d’industrialisation de l’analyse et du traitement des incidents.

Contrairement à ce que l’on peut entendre parfois, le SOAR ne fait pas de la détection d’incident. Il s’appuie sur des outils de détection qui sont en proximité, comme le SIEM ou l’EDR pour investiguer et ensuite éventuellement réagir.

Un SOAR contient l'information utile et nécessaire pour analyser et traiter l'incident efficacement. Il est là pour agréger les données, guider l'analyste dans son travail sur l'incident.

Si vous avez besoin de faire un rapport d'analyse de l'incident, le SOAR contient la donnée nécessaire pour le faire.

En revanche le SOAR ne va pas contenir toute la donnée relative à l'incident. Ces niveaux de détails sont contenus dans les logs. Contrairement au SIEM qui renferme des téraoctets de données, on est sur des volumes nettement plus faibles avec le SOAR.

Le SOAR représente un outil parmi une palette d’outils du SOC. Il permet aux analystes de gagner du temps pour se concentrer sur les incidents plus critiques et apporter plus de visibilité aux clients sur l’état des menaces qui les concernent.