Les SOC (Centres Opérationels de Sécurité) sont souvent surchargés par les alertes à traiter. Le volume de ces alertes de sécurité et le nombre des « faux positifs » augmentent régulièrement avec la complexification des menaces. Les analystes passent beaucoup de temps à produire des rapports et à définir des mesures d’activité. Les SOC doivent gérer des dizaines d’outils hétéroclites provenant des fournisseurs différents. La réponse aux incidents est encore très manuelle et « réactive ». Or plus les temps de réaction sont longs, plus les impacts sont grands. Comment réduire les délais entre la détection et la réponse aux incidents?

Parmi les solutions, l’utilisation de l’apprentissage automatique dans la détection des menaces, l’orchestration et l’automatisation de la réponse aux incidents. C’est ce qu’ont présenté Thierry Berthier, Chercheur et Directeur du groupe « Sécurité Intelligence Artificielle » du Hub France IA, et Thomas Anglade, Lead Data Scientist, lors de la Conférence Forensik 2020.

Ensemble, ils ont fait un état des lieux des SOC pour mettre en perspective la nécessité d’orchestrer et d’automatiser les playbooks de réponse aux incidents afin de répondre efficacement aux attaques et réduire les risques de perte de données.

Puis, ils ont expliqué comment l’intelligence humaine et l’intelligence artificielle collaborent pour:

  • optimiser la détection des menaces potentielles;
  • diminuer les faux positifs;
  • et améliorer l’investigation des incidents de façon continue.

Durant leur conférence, nos deux experts ont mis l’accent sur les indicateurs clés de performance et comment les mesurer.

Nous les avons donc interrogés pour en savoir plus sur les gains et métriques dans l’automatisation de la réponse aux incidents dans le cadre de notre podcast INTRASEC, la chaîne cybersécurité d’In Fidem.

Dans votre conférence, vous mettez l’accent sur les Indicateurs clés de performance et comment les mesurer dans la gestion et les réponses aux incidents. Pouvez-vous nous en dire plus?

T. Berthier: La performance, elle se chiffre surtout dans le gain de temps finalement. Quand on a une réponse informatique aujourd’hui, la réponse à incident elle se fait techniquement par des moyens humains et par les équipes qui sont en place.

Parfois, il y a des processus qui sont automatisés, mais ce sont typiquement des techniques hybrides : de l’humain, plus de la technologie. Maintenant, l’objectif devient d’automatiser le plus possible la réponse aux incidents en mettant l’humain un peu plus haut pour gagner en temps.

C’était ça l’idée directrice de la conférence. Quelles sont des solutions pour gagner du temps, pour réduire les délais de réponse à incidents, etc. ?

T. Anglade: Or le problème, c’est qu’aujourd’hui l’équipe, qui est en charge du monitoring et de la surveillance du réseau, manque de ressources et a beaucoup trop d’informations à traiter, avec des ressources et un temps limité. Parallèlement, il y a beaucoup d’idées reçues sur l’intelligence artificielle.

Pour beaucoup, elle s’alimenterait de manière autonome et elle serait capable de prendre des décisions. Autrement dit, ce serait une espèce d’algorithme qui serait capable de dire que dès qu’il y a une attaque, ce dernier serait en mesure de le dire avec une précision de 100%.

Alors qu’en réalité, il faut se demander « comment est-ce que je peux utiliser ces algorithmes-là pour optimiser le traitement de toutes les informations avec les ressources que j’ai ? ».
Il faut voir l’IA comme un outil qui permet de travailler plus vite sur un chantier.

Donc il faut trouver un moyen d’être plus efficace…

T. Berthier: Exactement, et notamment par rapport aux attaques ciblées. L’idée est de faire réduire les délais de détection et de réponse parce qu’aujourd’hui, le délai moyen, est de plus de 100 jours.

Or entre le moment où l’attaque a lieu et où elle est détectée, il peut se passer plus de 100 jours. Donc le mal est fait depuis longtemps, et donc, il faut absolument faire baisser ces délais-là. L’automatisation va permettre de contribuer à réduire ces délais de détection, puis de réponse.

On est vraiment dans une course contre la montre. Et comme le disait Thomas, l’intelligence artificielle va permettre de réduire ces temps de réponse, pas sur tout, mais sur tout ce qui est automatisable.

Pouvez-vous me brosser un portrait du mécanisme de réponse actuel versus le mécanisme de réponse proposé?

T. Anglade : Le mécanisme actuel est davantage centré sur l’humain et vise à mettre en place une organisation – avec un SIEM – un système de surveillance qui stocke les événements – et les traite – et une organisation autour de ce SIEM – avec des humains qui apportent leur expertise et sont capables de dire quand les événements enregistrés paraissent suspects.

On entre alors dans un système de « ticketing » où j’ai des niveaux – niveau 1, niveau 2, niveau 3.

  • Niveau 1 : je crée un ticket pour chaque événement qui me paraît suspect.
  • Niveau 2 : je fais une analyse approfondie, et si l’événement est potentiellement une attaque, je passe au niveau 3.
  • Niveau 3 : c’est là où je vais qualifier en attaque et enclencher une réponse.

Et donc on est sur quelque chose d’assez hiérarchisé et dans tout ce processus, pour l’instant, il n’y a pas tant d’aide numérique.

C’est-à-dire qu’on est sur un traitement systématique – j’ai des règles dans mon SIEM qui vont dire ce qui semble suspect. Une fois que tous les éléments suspects ont été identifiés, je me retrouve avec une liste d’événements à traiter, selon mes niveaux 1, 2 ou 3. Mais je n’ai pas de priorisation qui me dit quel événement est plus suspect qu’un autre.

Et l’apport de ces technologies est de permettre de hiérarchiser tous ces événements pour qu’à chaque étape, je puisse savoir quelles sont les choses qui sont les plus suspectes et comment mieux investir mon temps pour répondre à ces attaques potentielles.

Cette activité d’évaluation se base sur des règles statiques un peu comme dans un système expert ou bien sont-elles quand même un peu dynamiques?

T. Anglade : Initialement, c’était vraiment des règles statiques. Ça reste encore souvent des règles statiques, mais ça dépend du contexte, du client, de l’entreprise. En fait, plus on fait le travail de comprendre quelles sont les habitudes et les comportements des réseaux, plus on peut mettre en place des règles dynamiques, c’est-à-dire des règles qui sont propres à chaque entreprise.

Par exemple, si je sais que mes mises à jour sont faites tous les jeudis entre 23h et minuit et que j’intègre cela dans mon système de règle, je vais pouvoir commencer à dire que pour cette entreprise-là, si je vois des événements non conformes, c’est suspect. Ou inversement, si je vois une grosse activité à ce moment-là, ce n’est pas vraiment suspect, c’est juste une mise à jour de l’OS.

Et donc progressivement, avec l’aide de la data science, on va progresser dans la compréhension du réseau pour mettre en place des règles qui soient de plus en plus dynamiques et contextualisées, voire même aller vers des algorithmes qui sont capables d’observer le réseau et de déduire les bonnes règles. C’est ce qui nous permet de passer d’un système expert simple à un système expert augmenté où la compétence de l’humain reste centrale et c’est l’IA qui vient amener cette partie de contextualisation.

Vous avez mentionné dans votre conférence le nombre important de faux positifs. Comment est-ce que l’IA viendrait régler une partie de cette problématique-là?

T. Anglade: C’est une très bonne question. En fait, c’est presque le cœur du sujet aujourd’hui, parce qu’elle touche directement le processus d’investigation. Il faut partir du principe que c’est absolument impossible – pour l’IA ou l’humain – d’avoir un algorithme qui ne détecterait que les attaques.

Ça correspondrait à avoir un oracle qui saurait quelles attaques arriveraient dans le futur et qui nous avertirait; c’est absolument impossible.

Donc en fait, c’est inhérent au processus d’avoir des faux positifs, alors la question devient de savoir comment on peut avoir des alertes qui sont bien qualifiées. Ce que je veux, c’est des alertes qui soient pertinentes avec le moins de faux positifs possible.

Et donc avec l’apport de l’IA, qu’on va pouvoir contextualiser. Quand j’ai une alerte qui remonte grâce aux algorithmes, je vais aller chercher des données et dans les habitudes du système. C’est là que la notion de priorisation va entrer ligne de compte.

Autrement dit, même si aujourd’hui il existe différents niveaux, l’IA viendrait ajouter une notion de « scoring » pour me permettre de mieux évaluer les alertes à chaque niveau.

T. Anglade: Exactement.

T. Berthier: Avec une approche risque par-dessus qui va prioriser en fonction de la probabilité que la séquence d’événements corresponde à une vraie séquence d’attaque. C’est ça que l’IA permet de faire, c’est vraiment une approche statistique avec du risque qui est pris en compte. Donc c’est en cela qu’il y a une valeur ajoutée par rapport à la détection purement statique. Ça ne veut pas dire que les moteurs de règles statiques devraient être mis à la poubelle. Au contraire, ils sont encore très efficaces et il y a beaucoup d’attaques qui sont détectées par ces moteurs de règles classiques où il n’y a pas de machine learning derrière. Ces modèles de machine learning signalent des événements qui sortent de la normalité statistique.

Après un événement, on crée une nouvelle règle, les clients vont devoir faire une mise à jour pour les détecter dans le futur, etc. Ce problème de mise à jour, est-ce quelque chose qu’on cherche à résoudre avec cette nouvelle approche?

T. Anglade : En effet, avec l’IA, on passe un gap, où avec un système statique, à moins d’avoir une très bonne capacité d’anticipation, par exemple, un expert qui serait capable de dire « attention, voilà les nouvelles vulnérabilités à laquelle on devrait faire ça » et du coup, en amont de ces vulnérabilités, je mets en place des règles, [on va être réactif].

Et ça, c’est pratiquement impossible parce qu’il faudrait que tous les jours, j’ai quelqu’un qui soit au fait des vulnérabilités et capable de déduire des règles en amont. Comme c’est impossible, avec des règles statiques, je vais toujours être un peu en retard.

Avec l’IA, je passe une étape parce que je vais être plus en mesure de voir les tendances et les changements. Et donc si l’IA remonte ces changements à l’opérateur, en disant « Attention ! Ce genre de choses à changer ! », lui il peut tout de suite voir quels sont les changements dans le réseau et s’il y a des nouvelles règles à mettre en place ou s’il a besoin d’ajuster un seuil de détection, par exemple.

Par contre, l’étape d’après, c’est d’avoir quelque chose d’auto-apprenant et ça, on n’y est pas encore. Parce qu’on ne pourra jamais s’extraire de la capacité humaine à dire « je suis proche du milieu des hackers et du darknet, alors je peux anticiper quelles seront leurs prochaines attaques ». Ça, on ne pourra pas le remplacer, mais on va pouvoir permettre aux opérateurs de voir plus rapidement les changements dans le réseau.

Donc l’IA nous permet d’avoir des outils plus intelligents pour nous permettre d’identifier plus rapidement des nouvelles tendances et de les suivre plus facilement. On continue de travailler comme on le faisait avant, mais on peut faire davantage confiance à notre outil parce qu’on n’a pas besoin de vérifier autant si les règles sont à jour, etc.

T. Berthier : Exactement. Et sur la partie machine learning, on peut bâtir des modèles avec une phase d’apprentissage sur des données « métier », chose qui est très compliquée à faire avec des règles fixes ou statiques, la complexité est bien plus élevée. Il faudrait être capable de mettre à jour en permanence les règles et les vulnérabilités qui sortent tous les jours. Ce n’est pas juste une impossibilité physique, c’est aussi une impossibilité mathématique.
Aujourd’hui, on peut dire que la sécurité absolue n’existe pas, alors on ne peut pas avoir une mise en place de règles systématique derrière.
L’IA permet de contourner cette impossibilité en permettant d’aller vers le mieux sans être parfaitement exhaustif sur la détection, mais au moins d’ajouter une approche statistique à la détection et il y a plein de cas qui montrent que ça marche.

L’IA joue donc un rôle important dans la détection. La réponse aux incidents est encore très manuelle et réactive. Et là, on cherche à s’orienter davantage vers l’orchestration et l’automatisation des playbooks de réponse. L’IA va-t-elle aussi jouer un rôle dans l’automatisation de cette réponse.

T. Berthier : Exactement. Il faut savoir qu’il y a plusieurs étapes dans la réponse aux incidents. Il y en a presque 6.

  1. Il y a d’abord l’étape préparatoire, c’est-à-dire avant les attaques. Dans l’équipe de sécurité, on va se mettre d’accord sur un plan en cas d’attaque. Par exemple : qui on va aller chercher si notre système est à terre ou si une partie du système ne marche plus.
  2. Ensuite, il y a l’identification. Qu’est-ce qui nous a attaqué? Quelle panne je constate? Quel service n’est plus accessible?
  3. Puis la partie confinement: est-ce que tout mon réseau est « down »? Tout ou seulement une partie? Si je suis une grosse entreprise, est-ce qu’il y a des parties sur réseau qui ont été compromises? Et au contraire, quelles sont celles qui sont encore saines?
    Une fois qu’on a pu faire cette cartographie – et des fois c’est très compliqué de la faire – surtout maintenant avec les nouveaux outils d’attaque, on va essayer de confiner. On va mettre des barrières entre la partie saine et infectée afin de maintenir une activité minimale, même si elle est dégradée.
  4. Ensuite, il y a l’éradication. Il va falloir nettoyer en profondeur les endroits compromis. Ce qui veut parfois dire tout réinstaller, aller chercher des back-up, des copies, etc. Et il faut savoir qu’aujourd’hui, même les copies sont ciblées par les nouveaux rançongiciels. Ces ransomware vont même commencer par cibler les back-up, avant même de cibler les systèmes pour être sûr que si on tente de remettre en place le système, on va le faire avec des fichiers compromis. Donc les attaquants sont quand même très malins. Ce qui rend la partie éradication très compliquée et très coûteuse.
  5. Suit ensuite la phase de récupération des données perdues. Est-ce qu’on peut les récupérer? Est-ce qu’on a tout récupéré ou est-ce que certaines informations ont été perdues malgré les sauvegardes? Donc il faut faire un inventaire.
  6. Enfin, une fois que la crise est passée et qu’on a remis le système en marche, il y a toute la partie retour d’expérience et de savoir-faire. Ça, c’est le dernier élément qui va venir alimenter la boucle dans l’autre sens. Autrement dit, on va l’utiliser dans la préparation et la planification pour ensuite améliorer la réponse à incident. C’est un vrai cycle.

De plus, il peut y avoir plein d’acteurs impliqués comme les RH parce que si l’attaque est venue d’une attaque interne, d’un collaborateur indélicat, les RH vont être prévenus.

La partie juridique aussi joue un rôle. Si mon système est attaqué, la réglementation en Europe RGPD m’oblige à prévenir mes fournisseurs, mes prestataires, mes partenaires, les start-ups et grands groupes avec lesquels je travaille. Je dois les mettre au courant de l’attaque et de l’éventuelle fuite de données et des effets collatéraux. Donc l’aspect réglementaire rentre dans la réponse à incident. Bref, il y a l’aspect technique, mais aussi tout le collatéral.

Si je résume, il y a un playbook qu’il faut appliquer, des actions qu’il faut mener et à la fin il y a un bilan pour évaluer la qualité de la réponse. Ce bilan informe-t-il seulement la réponse ou aussi la détection?

T. Berthier: Ça sert partout. Ça rentre dans les données métier de l’entreprise. Ça peut aussi être utilisé dans d’autres entreprises. Donc il y a vraiment une boucle vertueuse de l’information. Est-ce qu’on a bien répondu? Est-ce qu’on a répondu assez rapidement ? Est-ce que notre réponse a été efficace? Eh bien tout ça, tous ces éléments-là vont venir, vont rester dans des bases de données et vont permettre de créer de nouvelles réponses et de nouveaux playbooks plus efficients.

Et lorsqu’on parle de réduire la boucle entre « la recherche de » et « l’application de meilleures solutions », parle-t-on de ces playbooks-là ou d’autre chose?

T. Berthier: On parle effectivement du cycle. J’ai parlé des 6 composantes et on va essayer d’automatiser une partie de ces composantes-là. Il y en a qui sont plus faciles que d’autres. Et d’autres – comme la mise en quarantaine – qui sont assez compliquées parce que ça veut dire pouvoir discriminer entre la partie du réseau qui est encore saine et la partie qui a été compromise. Pour un humain, c’est compliqué, pour une machine aussi, notamment par rapport aux nouvelles menaces où on a des malwares qui eux-mêmes peuvent embarquer des enveloppes de machine learning. Le malware peut être très furtif et ne pas s’activer à un moment donné, et puis décider en fonction du contexte de se déployer ou non. Ça, c’était une démo faite à BlackHat 2019 par IBM Security Center.

Alors ça devient difficile parce que ça suppose de les détecter, même s’ils n’ont rien fait sur le système. Il y a vraiment un passage en revue du système et à un moment donné, il faut décider ce qui va continuer de fonctionner, si tout le trafic on va le concentrer là-dessus pour maintenir l’activité de l’entreprise ou pas.

Bref, c’est très compliqué. Ça peut s’automatiser dans certaines composantes, mais pas partout.

Comment les entreprises peuvent faire évoluer leur pratique pour intégrer ces nouvelles approches?

T. Anglade: En fait, c’est vraiment de mettre en place une culture de la donnée. Pour aller vers une automatisation et du machine learning qui va nous permettre de gagner du temps et de gagner en qualité de détection, on a vraiment besoin de devenir data-driven.

Ça veut dire qu’il faut vraiment, au même titre que l’humain, mettre la donnée, au cœur du processus parce que c’est elle qui va permettre les décisions. Pour être capables de calculer les probabilités de bonne qualité, il faut qu’elles soient basées sur un gros volume de données.

Pour pouvoir dire de manière pertinente « Attention! Là j’estime que le risque il est de 98 / 100 », il faut avoir vu énormément de cas, des milliers, pour faire confiance à la probabilité.

Par contre, si j’en ai que 10 dans ma base de données, et que je sais que 8 / 10 qui étaient ok et deux qui étaient mauvais, ça me donne une probabilité de 80 %, mais c’est 8 / 10, ce n’est pas un niveau de certitude énorme.

Alors plus je vais collecter de la donnée et plus je vais la mettre au cœur de mon apprentissage et de la prise de décision, et plus je vais bénéficier de toutes ces technologies-là.

Ce qui va vraiment décider de la performance globale de ma capacité à détecter et à répondre, ça va être le volume de données que j’ai. Ça, c’est pour aujourd’hui.

Et pour demain, l’interaction données/algorithme/utilisateurs parce que finalement, une fois que j’aurais mis en place une première fois ce socle de machine learning, qui comprend bien le contexte et qui remonte bien les choses pertinentes et de manières contextualisées, la deuxième question ce sera « Comment est-ce qu’on fait en sorte que ces algorithmes apprennent en continue? ».

Parce que, en fait, ces algorithmes ont appris sur un contexte, à un moment donné. Alors leurs décisions sont pertinentes à un moment donné. Mais si finalement, je laisse du temps passé, après un an, il ne sera plus pertinent parce qu’il y aura beaucoup de choses qui auront changé.

Alors ça me demande de la donnée en continu, et donc de la ressource qui soit disponible pour faire ce travail éducatif avec mon algorithme.

Pour les entreprises qui veulent faire cette transition, quel conseil donneriez-vous? Par où commencer?

T. Anglade: En toute franchise, je dirais que ce sont plus des questions de gouvernance et de conduite du changement. Il y a d’abord une question d’humain et d’adhésion parce que ça va dépendre de la capacité des entreprises à faire adhérer les employés à ces nouvelles méthodes de travail. Et pour ce faire, à mon avis, il y a plusieurs biais assez simples à dépasser. Le premier biais va être sur la partie cyber, de penser qu’on va se faire remplacer par un algorithme. De se dire « je ne veux pas d’un algorithme qui va faire mon travail, parce que s’il fait mon travail, j’en aurai plus ». Alors qu’en réalité, ce n’est pas du tout cela, on va juste progresser dans l’efficacité globale de l’équipe.
Je pense aussi que c’est important pour les entreprises d’accompagner les salariés dans la maîtrise de ces technologies-là qui sont beaucoup plus centrées sur la donnée et l’algorithme. Il faut dépasser cette idée que l’intelligence artificielle fait tout, toute seule « Je clique sur un bouton et elle me sort les alertes ». C’est un processus dans lequel je dois m’engager et me préparer; nettoyer les données, les ingérer, interagir entre équipes, faire collaborer les équipes techniques, les data scientists et les personnes qui ont la compétence en cybersécurité. Alors si on veut que cette partie très théorique et mathématique fonctionne de manière concrète, il faut que tout le monde comprenne comment ça s’utilise, à quoi ça sert et qui doit communiquer ensemble. Donc le conseil que je donnerais, c’est d’accompagner les gens dans l’adoption de ces technologies-là, qui sont celles qui vont marcher dans les prochaines années.

T. Berthier: On peut rajouter aussi pour les entreprises qui se poseraient des questions, c’est de développer une culture du risque. En effet, souvent c’est ce qui manque. Il faut toujours avoir en tête le tableau classique impacts / risques où il y a certains risques qui sont très peu probables, mais qui ont un impact important sur l’entreprise.

Ce sont des processus qui sont connus dans les industries lourdes, il faut les adapter en cybersécurité.

Dans le cadre de cette culture du risque, la deuxième question, est-ce que j’ai un plan de continuité des activités? Quels sont les plans existants? Est-ce que j’ai réfléchi en amont à ce qui peut être une attaque, quel impact ça peut avoir sur mon système et qu’est-ce que je fais?

Et quand on a cette double culture du risque et de la continuité, là déjà on est sur la bonne voie et on peut aller regarder davantage du côté technique et de comment on peut gagner du temps, notamment dans la réponse.

Parce que tout à l’heure on en a parlé, mais aujourd’hui, c’est avec un outil SIEM qui embarque de l’UBA (analyse du comportement des utilisateurs) et de la réponse automatisée, le facteur de gain est de 40. On est donc 40 fois plus rapides grâce à des playbooks dynamiques qui intègrent le personnel, les processus, les technologies versus la réponse humaine classique.

C’est un gain de temps assez significatif. Par exemple, où avec un SIEM, ça prenait 20 jours pour clore un incident, avec une réponse automatisée, on parle de 5 jours.

Vous souhaitez en savoir plus sur nos offres de services gérés pour accroître votre efficacité dans la gestion et réponses aux incidents? Contactez nos experts!

L’intégralité de l’entrevue est disponible en français sur Ausha, Spotify, Apple Podcasts, Google Podcasts, Podcast Addict.