Dans mon dernier article, nous avons parlé du dilemme des défenseurs en citant les défis auxquels les équipes SOC sont confrontées dans notre récente publication intitulée State of Threat Detection 2023 (État de la détection des menaces 2023). Pour nous, les résultats étaient quelque peu attendus compte tenu des thèmes communs que nous avons entendus de la part des clients, des pairs et des professionnels de la sécurité au cours des dernières années - confirmant principalement ce que nous savions être vrai, à savoir que la plupart des approches actuelles de la détection des menaces et de la réponse sont cassées et voici pourquoi :
- Les équipes SOC reçoivent en moyenne 4 484 alertes par jour, dont les deux tiers (67 %) sont ignorés et 83 % sont des faux positifs.
- Près de trois quarts (71 %) des analystes admettent que l'organisation dans laquelle ils travaillent peut avoir été compromise et qu'ils ne le savent pas encore.
- La plupart (97 %) des analystes craignent de manquer un événement de sécurité important parce qu'il a été noyé dans un flot d'alertes de sécurité.
- Pourtant, 90 % des analystes SOC affirment que leurs outils de détection et de réponse sont efficaces.
Je ne sais pas ce qu'il en est pour vous, mais pourquoi la définition de l'efficacité se résume-t-elle à la capacité de générer une alerte ? Il semble que ce soit l'instrument de mesure utilisé par 90 % des analystes SOC, même s'ils pensent qu'ils sont déjà compromis et qu'ils sont réellement inquiets de manquer une véritable attaque. Des questions qui laissent perplexe - et pour trouver des réponses, Kevin Kennedy, SVP of Product chez Vectra AI et Matt Bromiley, Lead Solutions Engineer chez LimaCharlie et SANS Instructor ont participé à un récent webinaire avec SANS où ils ont posé le gant : "Il est temps que les vendeurs de sécurité soient tenus responsables de l'efficacité de leur signal".
Nous nous sommes plongés dans la recherche et avons posé trois questions simples à Kevin, qui représentait la voix du vendeur, et à Matt, qui représentait la voix du praticien :
- Plus de surface d'attaque, plus d'alertes, plus de faux positifs - quel est le problème à résoudre ?
- Plus d'angles morts, plus de compromis, plus de rotation - où devrions-nous commencer à nous attaquer au problème ?
- Plus de visibilité, plus de détections, plus de signaux - qu'est-ce qui rend un analyste SOC le plus efficace dans son travail ?
Vous trouverez ci-dessous quelques points forts de la conversation. Vous pouvez visionner l'intégralité de la conversation avec Kevin et Matt ici.
Q1 : Plus de surface d'attaque, plus d'alertes, plus de faux positifs - quel est le problème à résoudre ?
Matt: "Je pense qu'un certain nombre de choses se sont produites du point de vue des outils et de la technologie, ce qui a ouvert la voie. Je pense que si nous posions cette question il y a 4 ou 5 ans, les résultats auraient été très différents. La surface d'attaque, je devrais dire la compréhension de la surface d'attaque, est quelque chose qui s'est développé au cours des dernières années. Je pense que nous avons amélioré notre connaissance de notre environnement. L'un des problèmes est que (l'élargissement de la surface d'attaque) ne doit pas se traduire par l'ajout de nouveaux éléments à la file d'attente des alertes, ce qui nous permettrait de nous en sortir. Je pense que ce qui s'est passé ici, c'est que la surface d'attaque et les alertes sont devenues synonymes pour certaines organisations et pour certains analystes SOC.
Il s'agit de savoir comment nous les classons (alertes). Je ne veux pas que mes applications vulnérables soient signalées dans la même file d'attente que celle qui signale l'escalade des privilèges ou l'exécution de Mimikats, par exemple. Je considérerais cela presque comme une file d'attente de posture de sécurité par rapport à une file d'attente d'activité réelle d'un adversaire, ou quelque chose de ce genre. Et cette classification pourrait réduire un peu la tension sur les SOC, simplement parce que vous n'avez plus à penser à une application web vulnérable comme une chose urgente à réparer tout de suite. Et vous savez, lorsque nous entendons quelque chose comme 4 500 alertes par jour - ces chiffres sont tout simplement stupéfiants (et) cela semble faible par rapport à certains des SOC que je vois qui sont à peine, à peine en train de se maintenir hors de l'eau. La question de savoir à qui appartiennent les alertes est un autre aspect du problème. Qui est réellement responsable de la résolution de ce problème ? La sécurité est-elle responsable de la correction ou du suivi de l'alerte ? Et bien souvent, c'est ce dernier point, mais nous le confondons avec le premier".
Kevin: "Je pense que le problème réside dans l'approche. Si vous regardez comment cela a évolué, vous revenez 10 ans en arrière, il s'agissait de jeter des données, d'écrire des règles et il allait donner le signal. Certaines organisations ont réussi à faire fonctionner ce système, mais la plupart n'y sont pas parvenues. C'est ainsi que l'on a assisté à une évolution de la surface d'attaque et à la création d'un outil dédié à chacune d'entre elles à des fins de détection et de réponse. Il y a l'EDR. Il y a le NDR, il y a l'identité. Il y a cloud pour la détection et la réponse. Tout est donc une solution ponctuelle et presque tous les outils optimisent la couverture et souvent la couverture de bas niveau. On ne pense pas vraiment au bruit et c'est là que se trouvent les incitations du point de vue des fournisseurs. Il s'agit d'une couverture de bas niveau en raison de la manière dont les produits sont testés et évalués. C'est le moteur et la réalité. Il est également beaucoup moins coûteux de développer une couverture bruyante de bas niveau que de s'attaquer à un seul produit. Ainsi, vous inondez (les analystes) d'alertes, mais vous avez une couverture. Il y aura un faux positif ou une activité malveillante réelle si vous pouvez la trouver. Si vous signalez chaque exécution de code à distance, vous obtiendrez une activité malveillante. Vous obtiendrez également que tous les administrateurs fassent leur travail et vous le ferez à peu de frais.
Cela ne résout pas le problème. C'est une contribution au problème. Et cela se répercute dans des domaines tels que les tests. Ainsi, si vous regardez MITRE, nous faisons correspondre toutes nos détections à ces méthodes. Nous pensons qu'il s'agit d'une bibliothèque très utile dans le langage. Si vous regardez les tests qu'ils font, principalement axés sur les EDR, il n'y a aucune considération de faux positifs. Il s'agit uniquement d'une méthode malveillante. Elle est déclenchée dans l'environnement. Ils disent : "Est-ce que cela a détecté ou non ?
Il n'y a pas de contrôle pour savoir si un produit normal déclenche des dizaines de milliers d'alertes. Et si c'est la façon dont vous testez et évaluez, c'est la façon dont les incitations sont mises en place, alors vous obtiendrez des produits qui soutiennent cela. Et puis vous dites, ok, ingénierie de la sécurité, c'est votre problème de trouver comment donner du sens. Nous épuisons les gens avec cette approche. Tout d'abord, je pense que si nous envoyons 4 500 alertes en moyenne aux analystes, il n'y a pas beaucoup de temps pour utiliser leurs compétences créatives lorsque votre objectif est de fermer cette alerte très rapidement et de passer à la suivante parce que je suis mesuré sur - est-ce que je suis passé dans la file d'attente et combien de temps cela a-t-il pris ? Ce n'est pas du tout le bon endroit. Cela ne permet pas à la créativité de s'exprimer. La première chose à faire est de créer de l'espace et du temps pour que les analystes puissent utiliser leur créativité en leur donnant ce qu'il y a de pertinent à regarder, le contexte et les données afin de prendre la bonne décision rapidement et efficacement. Si la menace est réelle, il faut arrêter l'attaque. C'est ainsi que nous faisons ressortir le meilleur de l'analyste".
Q2 : Plus d'angles morts, plus de compromis, plus de rotation - où devrions-nous commencer à nous attaquer au problème ?
Kevin: Je pense que le chiffre d'affaires est le résultat et non la source du problème. Je pense que la façon de commencer à résoudre ce problème est d'utiliser un site signal unifié plus précis. Il s'agit de savoir comment consolider l'endroit d'où provient le signal d'attaque. On parle toujours beaucoup d'une seule vitre pour tout contrôler. C'est une grande ambition, mais il est très peu probable que vous y parveniez en une seule étape avec un grand nombre de produits ponctuels. Il faut donc réfléchir à la manière dont on consolide les produits au fil du temps et tenir les fournisseurs responsables de la qualité du signal qu'ils fournissent. Si vous voulez savoir qui ajoute de la valeur, mettez en place une équipe rouge basée sur votre modèle de menace et votre adversaire et voyez si votre outil montre que cela s'est produit et que vous étiez au courant pendant que cela se produisait. Si nous sommes en mesure d'obtenir un signal intégré et précis, et que vous nous en tenez pour responsables, cela nous aidera grandement à résoudre certains de ces problèmes fondamentaux".
Matt: "Et parce qu'il s'agit de donner au SOC le pouvoir de prendre du recul et de dire, hé, vous savez les problèmes que je vois proviennent d'un ou deux ensembles d'outils dans l'environnement. J'espère qu'il n'y aura pas de question d'entretien de départ pour une organisation qui dira, vous savez, quel outil a été le pire à gérer ? Asseyez-vous et discutez avec votre équipe pour obtenir la valeur dont nous avons besoin à partir de la pile d'outils dont nous disposons. Et abordez cela comme un point de contact, obtenez l'avis de l'équipe SOC. Si vous êtes noyé sous les alertes tous les jours et que vous envisagez de partir, je pense que certaines de ces (douleurs) peuvent également être traitées du point de vue de la gestion. Vous ne voulez perdre personne dans l'équipe parce que votre environnement a des niches uniques que seule votre équipe connaît. Quelles sont nos faiblesses en tant qu'organisation ? Asseyez-vous et discutez - c'est un excellent moyen de commencer à répondre à ces préoccupations.
Q3 : Plus de visibilité, plus de détections, plus de signaux - qu'est-ce qui rend un analyste SOC le plus efficace dans son travail ?
Matt: L'idée d'épuisement professionnel va de pair avec l'idée que ma voix n'a pas d'importance. Noyer les analystes SOC, c'est comme ça. Et c'est drôle, je lisais ce fil, sur un forum de discussion, je crois hier ou avant-hier, où quelqu'un disait : " Ecoutez, je suis juste épuisé. J'en ai fini. Et c'est tout. Et c'est drôle parce que la personne a poursuivi en disant : "Je pense à changer de travail". Et la première réponse a été. Eh bien, si vous êtes épuisé, où allez-vous aller ? Lorsque nous examinons l'efficacité, où puis-je trouver le plus de valeur et d'efficacité ? Je voudrais me faire l'écho des sentiments de Kevin, à savoir que s'il y a un domaine dans lequel vos outils ne sont pas efficaces, je veux dire que 44% des répondants ont dit, oui, nous pensons que notre vendeur pourrait être mieux tenu, pour vous, 44%, devinez ce que vous ferez demain ? Vous tenez votre fournisseur pour responsable des signaux qu'il vous envoie et vous vous en servez pour aller de l'avant.
Si je voulais classer l'efficacité des analystes SOC, je ne regarderais pas vraiment le nombre de tickets fermés. Je ne devrais pas le faire. Ce que je veux voir, c'est qu'hier, cette tâche nous prenait deux heures et qu'aujourd'hui, elle nous a pris une heure et 50 minutes. Vous venez de gagner du temps. Vous avez gagné en productivité. Comment avez-vous fait cela ?
Si votre objectif est de fermer le plus grand nombre de tickets possible, c'est là que votre parti pris entre en jeu. C'est là qu'intervient votre manque d'attention aux détails et que vous n'utilisez pas tous les aspects humains pour lesquels vous êtes doué - vous ne faites que fermer des tickets simplement parce que c'est l'incitation sur laquelle vous êtes basé. J'ai l'impression que les chiffres sont presque à l'opposé de ce à quoi nous nous attendions. Je me serais attendu à plus d'insatisfaction que ce que nous voyons dans (le rapport).
Kevin: Je pense que l'efficacité des analystes SOC revient à leur donner l'espace et le temps d'être créatifs - vos voix doivent être entendues sur l'efficacité des outils après coup. Mais il y a aussi le moment où vous choisissez (un outil). Nous travaillons avec de nombreuses équipes SOC et l'ingénierie de la sécurité est en première ligne pour ce qui est des critères de choix de l'outil. Regardez comment il fonctionne avec d'autres outils, afin de pouvoir automatiser davantage. Examinez la qualité. Mettez en place une équipe rouge. Comprenez votre modèle de menace.
A retenir
Au cours de cette conversation d'une heure, nous avons conclu que le problème à résoudre était celui des alertes, et pas seulement du bruit des alertes - n'importe qui peut prétendre réduire le bruit. Le problème central est l'approche des alertes. L'utilisation des alertes pour mesurer. L'appropriation des alertes et la définition de ce qui justifie une alerte. En ce qui concerne les priorités à fixer, nous avons parlé de signal unifié. La capacité à consolider et à mesurer l'efficacité des signaux. Assurez-vous que vous (les analystes SOC) avez la possibilité d'informer la direction et l'ingénierie de la sécurité de l'efficacité de ce signal, car s'il est inefficace, vous devez le dire à quelqu'un. Nous avons parlé de la nécessité pour les responsables SOC de taper sur l'épaule de l'analyste SOC pour lui demander son avis. Que peut-on faire pour améliorer le travail ?
Vous voulez en savoir plus sur Kevin et Matt ? Écoutez leur conversation précédente, "Sortir de la spirale du "plus" en matière de sécurité - Pourquoi le seul "plus" dont la sécurité a besoin, c'est plus de Attack Signal Intelligence", ici.