L’augmentation des cyberattaques observée au cours des dernières années peut être attribuée en partie à l’évolution et à la diffusion des outils d’automatisation, qui sont exploités pour effectuer des attaques plus larges à moindre ressources. Aujourd’hui, de nombreuses étapes d’une attaque peuvent être automatisées – notamment l’exploration et les mouvements latéraux avec Mimikatz – permettant parfois même aux attaquants novices de tenter des actions malveillantes et de parvenir à leurs fins.

Afin de lutter contre cette menace croissante sur un pied d’égalité, les équipes de réponse aux incidents – centres d’opérations de sécurité (SOC) et équipes de réponse aux incidents de sécurité informatique (CSIRT) – peuvent bénéficier d’un large éventail d’outils de sécurité automatisés. Les plates-formes SOAR (Security Orchestration, Automation and Response) attirent alors progressivement l’attention. Ces outils combinent des capacités de réponse aux incidents, d’orchestration et d’automatisation, ainsi que des capacités de gestion de la plate-forme de renseignement sur les menaces.

Malgré d’importants avantages accordés aux SOC et CSIRT, l’introduction d’un outil automatisé au sein des processus de réponse aux incidents existants reste complexe. Les plateformes SOAR présentent ainsi de nouveaux défis pour les équipes, notamment définir quelles tâches et décisions nécessitent une automatisation ou au contraire une expertise humaine.

Cet article vise à présenter une vue d’ensemble des plateformes SOAR en exposant les bonnes pratiques et recommandations sur la manière de répondre aux défis rencontrés par des équipes de réponse aux incidents utilisant ces solutions. Dans un premier temps, il décompose les utilisations potentielles des plates-formes SOAR en support sur l’ensemble des phases de réponse aux incidents. Dans un second temps, il approfondit certaines des considérations et des décisions que les équipes doivent prendre, offrant également des recommandations concrètes. Enfin, il compare brièvement le rôle des humains aux plates-formes améliorées par l’IA.

 

Prise en charge du processus de réponse aux incidents

 

Rassemblant l’ensemble des outils de sécurité, une plate-forme SOAR fonctionne à la manière d’un chef d’orchestre de l’écosystème de sécurité au sein d’une organisation, rationalisant le processus de réponse aux incidents. En effet, celle-ci peut soutenir et faciliter l’intégralité des phases clés de la réponse à l’incident, y compris le triage et la préqualification, l’enquête et l’analyse, ainsi que la dernière intervention et la correction.

Figure 1 : Vue d’ensemble du modèle d’intégration SOAR

Lors de la phase de triage et de préqualification, une plate-forme SOAR peut collecter des alertes provenant d’outils spécialisés de détection d’incidents, tels que les outils de gestion des informations et des événements de sécurité (SIEM). Bien qu’il s’agisse d’une activité bien établie et gérée par des outils robustes, deux problèmes majeurs demeurent ; la détection des faux positifs et la hiérarchisation des menaces sur la base d’informations contextuelles.

C’est au croisement de ces deux problématiques que les plates-formes SOAR peuvent être utiles, en enrichissant automatiquement les incidents, en filtrant les faux positifs, puis en mettant en évidence les incidents de sécurité critiques.

Les plateformes SOAR peuvent être alimentées par de nombreuses données issues de sources à la fois internes et externes. En effet, les indicateurs de compromission (IoC) pertinents peuvent être automatiquement intégrés à partir de sources fiables, telles que les fournisseurs de renseignements sur les cybermenaces (CTI) offrant des données hautement personnalisées issues de violations récentes survenues à des organisations similaires. D’autre part, les connaissances internes peuvent également être ingérées, en s’appuyant sur des résultats prédéfinis de classification des actifs ou d’analyses d’impact sur les entreprises (BIA) lisibles par machine. Cela permet ainsi aux analystes de gagner du temps en identifiant directement les incidents critiques et de disposer de toutes les informations nécessaires pour se concentrer sur la réponse aux incidents.

Lors de la phase d’investigation et de qualification des incidents, un CSIRT peut bénéficier du support SOAR en automatisant la gestion des cas d’utilisation de base. Alors que la première phase concernait des actions plus automatisées déclenchées par des alertes systèmes, par exemple l’enrichissement CTI basé sur des alertes SIEM, dans la phase d’enquête, la valeur ajoutée d’une plate-forme SOAR consiste principalement à soutenir l’analyse de l’équipe. Par exemple, lorsqu’un e-mail de phishing est signalé, la plateforme SOAR peut faciliter la collecte des informations nécessaires pour effectuer l’enquête et la qualification de l’incident, le rendant ainsi plus efficace. Cependant, l’évaluation de l’expert peut difficilement être automatisée pour des tâches plus complexes, telles que l’analyse approfondie et la qualification d’incidents complexes.

La phase de réponse et de correction reste la plus compliquée à automatiser, en raison à la fois de la nature des actions requises et du risque d’impact négatif sur l’entreprise si une correction est mal exécutée. L’automatisation d’une action de réponse doit permettre de capitaliser sur les gains d’efficacité, tout en tenant compte de l’évaluation coûts-bénéfices. 

Les plateformes SOAR peuvent donc considérablement faciliter le travail des analystes en cybersécurité, qui n’ont plus à traiter chaque incident manuellement d’outil en outil à chaque étape du processus de réponse aux incidents, et s’appuient plutôt sur des tâches automatisées mêlant différents outils de sécurité.

Après avoir vu différentes utilisations possibles des plateformes SOAR, il est intéressant de s’interroger de quelle manière choisir ce qu’il faut automatiser.

 

Décider quand automatiser en fonction du principe d’impact à faible regret

 

Pour chaque tâche de réponse à incident (IR), il existe trois approches différentes pour les plates-formes SOAR :

• Automatisation complète,
• Semi-automatisation,
• Pas d’automatisation.

Dans les cas d’automatisation complète, plusieurs étapes sont prédéfinies et automatisées en séquence sur la base de déclencheurs prédéfinis ou d’une activation manuelle. Des cas d’utilisation simples, comme les e-mails de phishing mentionnés précédemment, peuvent s’appuyer sur une automatisation complète et offrir des avantages substantiels pour minimiser les tâches longues et répétitives.

Dans les cas de semi-automatisation, certaines étapes – par exemple l’analyse initiale, la collecte de preuves ou l’enrichissement de l’information – sont automatisées afin de permettre à l’analyste de choisir le meilleur plan d’action. Cela pourrait être l’utilisation la plus courante de la plate-forme SOAR à l’heure actuelle.

Enfin, certaines situations ne permettent tout simplement pas l’automatisation et continueront d’être requises et exécutées par des opérateurs humains.

Alors que les équipes IR explorent les fonctionnalités et le potentiel des plates-formes SOAR, il est courant de se demander comment choisir quels cas d’utilisation peuvent et doivent être automatisés. Outre une évaluation de faisabilité, un facteur fondamental à adopter est le principe de l’impact à faible regret. Étant donné que la sécurité est toujours une fonction support des objectifs métiers, une analyse minutieuse des risques est nécessaire lorsque la possibilité d’affecter les services métiers existe. Une évaluation des avantages par rapport au regret encouru amène les organisations à changer leur perspective sur le problème en leur faisant choisir quand certaines actions peuvent être automatisées au lieu de savoir si elles peuvent être automatisées.

Afin de fournir une image plus sophistiquée et réaliste, deux observations s’imposent. Tout d’abord, ce choix est généralement non binaire (par exemple, regret élevé vs regret faible), car il devrait y avoir des niveaux croissants de risques et une confiance raisonnable en fonction de l’appétit pour le risque d’une organisation. Le regret est mieux quantifié sur une échelle. Deuxièmement, une telle analyse coûts-avantages est nécessairement contextuelle, ce qui signifie qu’elle doit tenir compte des conditions situationnelles dans lesquelles elle est effectuée. Pendant une crise en cours, les actions automatisées peuvent devenir plus ou moins attrayantes, compte tenu de l’évolution du calcul des risques.

Concrètement, les actions ayant très peu de chance de perturber les opérations métiers doivent être considérées comme des actions à faible regret, permettant une plus grande automatisation. Les actions susceptibles de provoquer des perturbations généralisées ou percutantes lorsqu’elles sont mal exécutées peuvent être évaluées comme des actions de regret moyen, nécessitant une confirmation humaine pour terminer le flux de travail. Enfin, les actions qui perturberaient les activités métiers d’une manière inacceptable (par exemple, la perturbation d’actifs hautement critiques) sont considérées comme des actions à grand regret, décourageant l’automatisation. Néanmoins, dans des circonstances particulières, ce barème peut être révisé et adapté.

 

Adopter une approche progressive

 

 

Une fois les concepts de base des solutions SOAR définis, les équipes IR sont confrontées à un autre défi majeur lié à la conduite du changement. Le passage de playbooks manuels à des workflows automatisés implique un processus fastidieux qui nécessite une hiérarchisation minutieuse. Un degré croissant d’automatisation peut être atteint grâce à une approche progressive et progressive.

Les tâches simples, chronophages et présentant un faible risque de regret peuvent être automatisées en priorité, réduisant la charge de travail à faible valeur ajoutée des analystes IR et augmentant leur efficacité. Cela peut être mis en place rapidement, compte tenu de la faisabilité technique de telles actions (ex : API existantes). En outre, la standardisation des tâches peut accélérer les étapes d’automatisation ultérieures en les rendant réutilisables dans différents playbooks ou branches. En effet, il est préférable de commencer à automatiser les branches des playbooks les plus simples, comme par exemple effacer les faux positifs, avant d’étendre l’automatisation à l’ensemble du playbook où toutes les possibilités d’alerte doivent être envisagées.

 

L’IA au service des activités humaines

 

Certaines solutions SOAR s’appuient sur l’intelligence artificielle (IA), grâce à laquelle un modèle d’apprentissage automatique (ML) peut être formé sur des données spécifiques qui lui sont fournies. Par exemple, un ensemble de données d’e-mails de phishing classées selon différentes valeurs (par exemple, légitime, malveillant, spam) peut alimenter le modèle ML.

Les solutions SOAR améliorées par l’IA peuvent aider à résoudre rapidement des incidents simples ou à identifier facilement des actions automatisables. Cependant, le raisonnement humain permettra de mieux contextualiser les choix en fonction de considérations commerciales et opérationnelles. A l’heure actuelle, aucune solution automatisée ne peut encore fonctionner sans l’intervention et la supervision des analystes. Au lieu de cela, l’IA est principalement destinée à effectuer efficacement une tâche spécialisée unique en traitant de grandes quantités de données. Cela améliore considérablement l’efficacité de l’équipe, travaillant aux côtés des humains, plutôt que de les remplacer.

 

Conclusion

 

Tout bien considéré, les plateformes SOAR sont des outils puissants. Bien qu’ils puissent soutenir les équipes IR à toutes les étapes de leur travail quotidien, y compris la collecte d’informations, l’analyse et la réponse active, il convient de souligner que les SOAR ne sont pas des outils magiques capables de résoudre tous les problèmes auxquels les équipes sont confrontées aujourd’hui. Au contraire, les achats qui ne sont pas suivis de projets de mise en œuvre bien définis entraîneront probablement des résultats inefficaces et de faibles retours sur investissement. Sur le plan technique, les SOAR ne peuvent pas effectuer des tâches que les systèmes backend ne permettent pas ; du côté organisationnel, ils s’appuieront toujours sur des processus et des procédures bien établis, standardisés et testés. Au fur et à mesure que les organisations évaluent leur adoption et, par conséquent, franchissent les étapes pour les intégrer et capitaliser sur leur potentiel, des principes directeurs tels qu’un principe d’impact à faible regret et une approche progressive déterminent le résultat final et les avantages que les équipes visent à obtenir.

 

Merci à Fabien Leclerc pour sa participation à la recherche et à la rédaction