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.
