Les défis de la surveillance des journaux Azure : Des idées pour votre SOC

Des journaux d'activité complets et opportuns sont des outils puissants qui permettent la surveillance de la sécurité et la réponse aux incidents sur le site cloud. Cependant, en étudiant les journaux Azure, nos chercheurs ont remarqué de nombreuses lacunes qui compliquent la compréhension des actions des utilisateurs et peuvent même permettre à un attaquant de passer inaperçu. Dans ce billet, nous discuterons de ces problèmes et de leur impact sur le travail de l'équipe Blue. 

Pourquoi étudier les journaux d'Azure Monitor    

Avant d'aborder les détails propres à chaque fournisseur, il convient de noter que les journaux n'ont pas la même signification dans les environnements cloud et dans les environnements sur site.

Les administrateurs disposent d'une certaine marge de manœuvre dans les installations sur site : Il est possible d'exploiter le trafic réseau pour surveiller l'activité ou de collecter des journaux à la périphérie du réseau et sur des machines individuelles. Les solutions de journalisation et de surveillance (matériel et logiciel) sont remplaçables, et si un produit d'un fournisseur particulier ne fonctionne pas bien, un autre peut être installé.

Sur le site cloud, vous n'avez pas ces options - le fournisseur contrôle entièrement les journaux disponibles. S'ils sont de grande qualité, tant mieux ! Mais s'il y a des problèmes, vous êtes à la merci de la volonté du fournisseur de les résoudre. Vous pouvez soit les signaler au fournisseur et espérer qu'il les corrige, soit essayer de les contourner, dans la mesure du possible.

Le suivi des activités dans l'environnement cloud répond à plusieurs attentes :

• Pas de modifications inopinées de la structure ou du contenu du journal
• Enregistrement des événements en temps utile
• Des registres complets et exacts (sans valeurs manquantes ou brisées).
• Documentation complète sur les événements enregistrés
• Un moyen simple de corréler les événements et les sessions d'utilisateurs entre différents journaux
• Un ensemble d'indicateurs de menace à utiliser dans l'analyse des incidents

Lors de l'analyse de l'activité, les données suivantes doivent être systématiquement disponibles dans toutes les sources d'enregistrement et pour tous les types d'événements :

• Noms et détails des opérations
• Identité de l'utilisateur et informations de session
• PI
• Géolocalisation
• Informations sur l'appareil
• Indicateurs de menace et de réputation

Essentiellement, vous voulez être en mesure de savoir qui a fait quoi et quand (et ce qu'ils ont fait d'autre). Malheureusement, les journaux Azure ne répondent pas toujours à ces attentes.

Comment surveiller les événements dans Azure

Azure dispose d'un ensemble mature de produits d'analyse et de surveillance des événements :  

Microsoft Sentinel est un produit SIEM natif qui ingère des journaux provenant de diverses sources. Il dispose d'un ensemble de détections intégrées et permet de définir des détections personnalisées. 

Azure Log Analytics est une plateforme d'analyse des journaux qui permet de mener des enquêtes ad hoc sur des événements suspects.    

Ils prennent tous deux en charge Kusto, un puissant langage d'interrogation et d'analyse des journaux. En outre, vous pouvez utiliser des solutions tierces pour surveiller et interpréter les journaux.

L'infrastructure de journalisation d'Azure est vaste et comporte des dizaines, voire des centaines, de sources de journalisation. Il serait impossible de les évoquer toutes, aussi nous concentrerons-nous sur les journaux générés par Azure AD (désormais Entra ID), la solution IAM d'Azure, et Microsoft 365, une suite bureautique SaaS ( cloud ).

Couverture des journaux d' identification d'Entra : 

• ‍Sign-ins - plusieurs journaux couvrant l'activité de signature des utilisateurs interactifs et non interactifs, des mandants de service et des identités gérées.
• Audits - un registre des opérations significatives du répertoire
• Mise à disposition - données relatives à la mise à disposition d'utilisateurs par des services tiers

Ces journaux sont accessibles via l'API graphique et existent actuellement en version de base (1.0) et en version bêta, qui ont des schémas différents. 

Les journaux d'activité de Microsoft 365 sont consommés par l'intermédiaire de l'API de gestion des activités, qui fournit plusieurs journaux pour différents types d'événements :

• Audit.AzureActiveDirectory - événements provenant du service Entra ID (similaire à ce qui est disponible via Graph API), tels que les affectations et les changements de répertoire.
• Audit.Exchange - Événements liés à la bourse
• Audit.SharePoint - Activité SharePoint
• Audit.General - la plupart des autres actions qui n'entrent dans aucun des autres journaux.
• DLP.All - Événements de prévention de la perte de données

Problèmes connus du journal Azure Monitor

Maintenant que nous avons exploré l'importance de la surveillance des journaux Azure, nous allons nous pencher sur certains problèmes que nous avons rencontrés dans ces journaux. Le fait de les connaître peut vous aider à élaborer de meilleures requêtes d'analyse et à perdre moins de temps à vous demander pourquoi les choses se comportent comme elles le font.    

Les défis spécifiques qui devraient être dans le collimateur de tous les analystes et architectes de la sécurité sont les suivants :

• Schéma des fluides
• Flux de logs
• Retards dans les événements
• Événements manquants
• Taxe sur l'exploitation forestière
• Événements qui ne sont jamais enregistrés
• Documentation déficiente
• Changements inopinés
• Incohérences d'identification
• Incohérences IP
• Incohérences de géolocalisation
• Incohérences dans les informations sur les appareils
• Des valeurs brisées

Examinons chacun d'entre eux plus en détail.

Schéma des fluides

Le schéma de certains journaux (par exemple, Management Activity API) est "fluide". Cela signifie qu'un paramètre unique dans une nouvelle opération sera ajouté au journal en tant que nouvelle colonne.

Cela rend sa gestion difficile, même pour Log Analytics. (Nous avons observé qu'il affichait des erreurs à propos d'une "limite de 500 colonnes maximum atteinte"). Si vous cherchez à consommer des événements dans un SIEM externe, vous devrez peut-être être sélectif quant aux colonnes à consommer, et il est impossible de prévoir les nouvelles colonnes ajoutées par Azure.

Une meilleure méthode aurait consisté à utiliser un schéma statique dans tous les journaux, en ajoutant des champs de structure (par exemple en JSON) pour gérer la variabilité.

Flux de logs

Il y a parfois des interruptions de connexion dans Azure. En fait, nous en avons vu plusieurs au cours des dernières années. Bien que l'une d'entre elles ait duré plusieurs semaines et ait été découverte accidentellement, Microsoft est généralement en mesure d'avertir les clients dans de telles situations.

Le problème est que, pendant une panne, vous pouvez être totalement aveugle à toute activité dans l'environnement. Si vous manquez l'annonce de la panne, rien ne vous indiquera qu'il y a un problème. Il est essentiel de rester au fait de l'état des services Azure et éventuellement d'investir dans une solution de surveillance permettant de suivre le flux des journaux.

Les interruptions peuvent également être délibérées. La configuration de la journalisation est contrôlée en bande, et la compromission du compte d'un administrateur peut conduire l'attaquant à désactiver la journalisation à grande échelle (par exemple via Set-AdminAuditLogConfig) ou de manière plus fine et furtive (par exemple via Set-Mailbox -AuditEnabled).

Il est essentiel de surveiller le flux des journaux et les changements de configuration pour atténuer ces problèmes. Seuls quelques utilisateurs autorisés doivent pouvoir modifier les paramètres de journalisation. Il serait préférable qu'Azure ajoute davantage de contrôles à la configuration de la journalisation en raison des conséquences négatives importantes découlant de la désactivation accidentelle ou délibérée de la journalisation.

Retards dans les événements

Microsoft publie les délais prévus pour la disponibilité de ses événements de journalisation. Le temps d'ingestion de l'API graphique est annoncé comme étant inférieur à 3 minutes. D'après notre expérience, l'apparition des événements dans ces sources peut prendre jusqu'à 30 minutes.

La disponibilité typique annoncée pour les événements de la Management ActivityAPI est comprise entre 60 et 90 minutes. En réalité, les délais que nous avons observés sont plus importants. Voici quelques chiffres maximaux que nous avons capturés récemment - certains temps dépassent largement les 24 heures (la colonne max_delay contient le temps maximum observé entre la création de l'événement et sa disponibilité dans le journal) :

Ces délais ne sont pas tenables. Certains attaquants agissent très rapidement. Si l'on tient compte du temps nécessaire au traitement par les outils de détection, à l'ingestion par le SIEM externe et à la réaction du personnel du SOC, il devient évident que, dans de nombreux cas, l'équipe bleue sera en retard - presque à dessein. 

Plus les attaquants automatisent leurs outils, plus la situation s'aggravera. Azure doit donner la priorité à la disponibilité rapide des journaux. Sinon, les défenseurs ne peuvent que réagir aux incidents, et non les arrêter. Les retards des événements sont encore plus difficiles à gérer lorsque les enregistrements de journaux sont transmis à un SIEM externe. Les appels à l'API de journalisation prennent des plages de temps comme paramètres, de sorte que vous devrez soit accepter la perte d'enregistrements, soit interroger des plages de temps qui se chevauchent et supprimer les enregistrements en double afin de ne pas manquer les événements tardifs.

Événements manquants

Certains types d'événements peuvent se trouver dans plusieurs journaux. Par exemple, les enregistrements de connexion sont disponibles à la fois dans l'API graphique et dans l'API des activités de gestion. Comparez les enregistrements d'un même événement dans les deux sources et vous constaterez des différences occasionnelles. 

Prenons les exemples suivants, tirés d'une enquête sur un incident récent. Bien qu'ils correspondent tous aux mêmes actions d'un attaquant, les enregistrements ne correspondent pas exactement :

Graph API (bêta - dans Azure Portal):

Graph API (v1.0) : 

AuditAzureActiveDirectory dans Management Activity API :

Ce type d'incohérence est difficile à reproduire et à expliquer, mais il faut en être conscient lors de l'analyse des journaux. Des enregistrements peuvent se perdre et l'analyse de plusieurs journaux peut s'avérer nécessaire pour obtenir une image plus complète de ce qui s'est passé.

Taxe sur l'exploitation forestière

De nombreux types et détails d'événements de journalisation ne sont disponibles qu'avec les niveaux de paiement les plus élevés (par exemple E5 et P2). Il s'agit par exemple des événements MailItemsAccessed, des détails sur les risques dans le journal des connexions, etc. Cela pose un dilemme à de nombreux clients : il faut choisir entre des coûts moins élevés et une meilleure visibilité des activités dans l'environnement. 

Ce n'est pas un bon choix à faire et, à notre avis, les fonctions de sécurité de base (telles que les journaux) devraient être disponibles pour tous les clients de cloud . Comme l'a récemment déclaré le sénateur américain Ron Wyden,"faire payer aux gens les fonctions de pointe nécessaires pour ne pas être piraté, c'est comme vendre une voiture et faire payer un supplément pour les ceintures de sécurité et les airbags". 

Ce manque de visibilité a causé des difficultés dans de nombreux incidents clients Vectra AI sur lesquels nous avons dû enquêter. Une récente violation publique par l'APT Storm-0558, à laquelle Microsoft a dû faire face, a révélé ce problème au grand jour. À la suite de cet incident, Microsoft a convenu avec la CISA d'étendre l'accès à la journalisation à tous les clients cet automne. 

Espérons que les choses s'amélioreront bientôt. En attendant, vous devez vous assurer que la journalisation à laquelle vous avez accès grâce à votre licence est adaptée aux besoins de votre organisation en matière de RI. Si ce n'est pas le cas, il est temps de procéder à une mise à jour. Lorsque des données essentielles ne sont pas disponibles, certaines d'entre elles (par exemple, la réputation IP et les informations de géolocalisation) peuvent être obtenues auprès de sources tierces.

Quelques événements qui ne sont jamais enregistrés

Azure est un "paradis de la reconnaissance", avec des événements de type "get" qui correspondent à la lecture de la configuration et des données qui, à de rares exceptions près, ne sont pas enregistrées. Depuis octobre 2023, un nouveau journal qui enregistre les appels à l'API Graph a été introduit et couvre certaines des opérations de reconnaissance. Cependant, l'énumération via d'autres API reste invisible pour les défenseurs.

Cela signifie que lorsqu'un attaquant accède à l'environnement cloud , il peut énumérer la plupart des informations - utilisateurs, services, configuration - sans être vu par les défenseurs. Il s'agit là d'un angle mort important : lors de nos tests, la plupart des outils d'énumération M365/AAD à source ouverte n'ont laissé aucune trace dans les journaux. 

La raison pour laquelle il a été décidé de ne pas enregistrer ces événements n'est pas claire, mais il se peut que ce soit pour économiser de l'espace. Malheureusement, il n'existe aucune option permettant d'activer cette journalisation, même si le client souhaite voir ce type d'événements. Cela signifie que vous êtes dans l'ignorance jusqu'à ce que les attaquants commencent à modifier votre environnement.

Documentation déficiente

Alors que les API Azure sont raisonnablement bien documentées, la documentation sur les événements de journalisation fait défaut. Pour de nombreux événements, la seule chose documentée est le nom de l'opération, mais les champs individuels et leur signification sont souvent un mystère. Vous devez parcourir les blogs et les forums de discussion pour essayer d'interpréter ce qui se passe.

Outre le fait que l'objectif d'un champ n'est pas clair, les valeurs des données individuelles sont parfois mal documentées. Nous avons vu des types d'authentification spécifiques, des codes d'état, des sous-types d'opération et d'autres données sans description. Même un effort de recherche approfondi n'a pas permis de clarifier certaines de ces valeurs.

Parce que nous ne comprenons pas certains champs et certaines valeurs, nous ne pouvons pas les contrôler et les interpréter au cours de l'enquête et de la réponse à l'incident.

Changements inopinés

Au fur et à mesure que la fonctionnalité de cloud évolue (comme c'est souvent le cas), de nouveaux types d'événements apparaissent à l'improviste dans les journaux. Par exemple, un nouveau code d'erreur a été ajouté pour les échecs de connexion sans mot de passe que nous avons récemment documentés. L'équipe de recherche en sécurité de Vectra AI a dû passer du temps à enquêter sur ce code avant de comprendre ce qui l'avait déclenché et, jusqu'à ce moment-là, nos requêtes de surveillance n'en tenaient pas compte.  

Plus inquiétant encore, les événements existants peuvent également disparaître ou changer de format. Voici quelques exemples récents :

• MailboxLogin que nous suivions et qui disparaissait silencieusement des journaux Exchange.
• Les erreurs de connexion pour des noms d'utilisateur inexistants que nous suivions pour détecter les premières étapes d'une activité de reconnaissance et qui n'étaient plus écrites dans les journaux de connexion.

Lorsque vous avez des requêtes de surveillance et d'analyse qui recherchent des événements spécifiques, ces changements les feront cesser de fonctionner sans avertissement. Il s'agit là du pire type de défaillance - lorsque vous ne savez même pas qu'il y a un problème. Il se peut que vous deviez investir dans une logique de contrôle de l'intégrité des journaux et surveiller de près l'évolution de leur contenu et de leur documentation. Malheureusement, la plupart des défenseurs sont trop occupés pour y consacrer du temps.

Incohérences d'identification

Les identifiants des utilisateurs ne sont pas toujours "stables". Selon le contexte et le type d'opération, le même utilisateur peut apparaître dans les journaux sous différents "noms principaux d'utilisateur" (UPN). Par exemple, votre utilisateur peut être enregistré sous le nom de :

• john.smith@company.com
• John.Smith@company.com (attention à la différence de majuscules)
• AN045789@company.com

M365 Exchange jette un pavé dans la mare en ajoutant des noms anciens tels que les suivants (et d'autres) :

"NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e "au nom de "NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/JohnSmith".

Dans les cas de variabilité des noms, il devient difficile de relier différents événements au même utilisateur. Si la corrélation des événements par l'UPN peut être la première impulsion, la corrélation par l'ID interne unique peut être une stratégie plus robuste (mais qui n'est pas encore infaillible).  

Les difficultés persistent :  

• Des noms différents dans des journaux différents peuvent avoir des noms de champs qui se chevauchent et qui ont des significations différentes. Par exemple, user_id désignera un GUID d'utilisateur dans un journal et un UPN dans un autre.
• Les identifiants d'utilisateur peuvent avoir des valeurs représentant le prénom et le nom de famille de l'utilisateur, les noms d'application, les GUID d'application et d'autres noms inhabituels et identifiants uniques.
• Les identifiants des utilisateurs peuvent être vides ou contenir des noms inutiles tels que "Non disponible", "Inconnu", "Pas d'UPN" :

En tant que défenseur, vous devez être prêt à voir ces informations (peu utiles) dans les champs d'identité de l'utilisateur et à construire une fonctionnalité de requête en conséquence.

Incohérences IP

Une adresse IP valide est une exigence de base pour chaque enregistrement. Bien que des adresses IPv4 et IPv6 valides soient disponibles dans les entrées de journal la plupart du temps, nous voyons parfois des adresses IP difficiles à comprendre et à utiliser dans l'analyse :

• IP avec numéros de port (v4 et v6)
• IP vides
• IP locales et privées : 127.0.0.1, 192.168.*, 10.*
• Toutes les adresses IP nulles : 0.0.0.0
• Masques IP au lieu d'IP : 255.255.255.255
• IP correspondant à l'infrastructure Azure, et non à l'utilisateur effectuant l'opération

Les adresses IP ne peuvent pas être mises en corrélation avec les enregistrements de connexion pour certaines opérations, ce qui complique l'analyse des incidents. Des indicateurs de risque et de réputation de la propriété intellectuelle peuvent parfois être disponibles, mais ils sont soumis à la "taxe d'enregistrement".

En tant que défenseur, vous devez vous attendre à ces cas particuliers lorsque vous écrivez des requêtes de chasse et des alertes et les intégrer dans votre logique.

Incohérences de géolocalisation

Actuellement, Microsoft ne fournit que la géolocalisation pour les enregistrements de connexion. Cela aurait été utile pour d'autres sources de journaux, car il n'est pas toujours possible de relier l'activité à des enregistrements de connexion spécifiques.

Cette fonction n'est pas parfaite. Il y a parfois des problèmes :

• La même adresse IP renvoie à plusieurs emplacements (très probablement liés à des appareils mobiles).
• Les enregistrements sont géolocalisés de manière incorrecte en masse.
• Les informations géographiques sont manquantes :

La géolocalisation est également facilement trompée par TOR, les VPN, les proxys et les IP des fournisseurs de cloud - et doit être prise avec un grain de sel.

Incohérences dans les informations sur les appareils

Les détails relatifs au dispositif sont complexes à déterminer pour Microsoft (sauf s'il s'agit d'un dispositif enrôlé). Les informations relatives à la plate-forme et au navigateur sont généralement analysées à partir de l'agent utilisateur (UA).

Malheureusement, il y a là aussi des incohérences : 

• Certains journaux analysent l'UA et la fournissent de manière fragmentaire, tandis que d'autres donnent la chaîne complète de l'UA (que vous devez interpréter).
• Les informations sur les appareils ne sont pas disponibles dans tous les journaux
• Les valeurs analysées ne sont pas toujours cohérentes (par exemple, "Windows" vs. "Windows 10")

Les attaquants peuvent facilement falsifier l'agent utilisateur, mais il reste précieux pour les enquêtes, car tous ne sont pas assez disciplinés pour le modifier discrètement. 

Des valeurs brisées

Certains champs du journal ont des structures complexes (par exemple JSON), et les requêtes de chasse et de surveillance doivent les analyser pour se référer à des sous-champs spécifiques.

Parfois, ces valeurs sont coupées en raison de limites de taille, ce qui entraîne des ruptures de structure. Par exemple, considérons la valeur suivante enregistrée pour l'opération Set-ConditionalAccessPolicy. Une partie de cette valeur est coupée et remplacée par trois points ("..."), ce qui perturbe l'analyseur JSON : 

Les requêtes de contrôle qui rencontrent de tels enregistrements échouent, ce qui crée des zones d'ombre.

Dans ce cas, la meilleure stratégie n'est peut-être pas de s'appuyer sur l'analyse correcte des valeurs, et les recherches par sous-chaînes peuvent être plus efficaces.

Que faut-il faire pour améliorer la qualité des grumes ?

Nous ne sommes pas les seuls à critiquer la qualité des logs Azure (des problèmes similaires ont déjà été soulevés par CrowdStrike et EricWoodruff), et nous ne pouvons que spéculer sur la raison pour laquelle ils sont si nombreux.

Les journaux sont généralement relégués au second plan, en termes de priorité, par rapport à d'autres fonctions dans le développement de logiciels. Les fonctions de service en arrière-plan peuvent être sacrifiées lorsque l'équipe de développement est pressée de lancer la fonctionnalité principale du produit.

Dans les énormes écosystèmes de produits tels qu'Azure, de nombreux produits indépendants (et parfois anciens) sont réunis. Il peut être difficile de faire en sorte qu'ils fournissent tous un bon signal dans une architecture de journalisation commune et cette fonctionnalité n'est pas exactement "en contact avec le client", de sorte que les plaintes à ce sujet risquent d'être dépourvues de priorité.

Quelle qu'en soit la raison, l'absence d'alternatives dans un environnement cloud rend les problèmes de journalisation beaucoup plus graves qu'ils ne l'auraient été dans une configuration traditionnelle sur site. Hormis le fait d'être conscient des lacunes des journaux et d'essayer de les contourner, les défenseurs n'ont pas d'autres options. Microsoft est propriétaire de cette fonctionnalité et c'est à lui de l'améliorer.

Nous pensons qu'un certain nombre de changements non intrusifs peuvent (et doivent) être apportés par l'équipe Azure :

• Tous les événements, champs et valeurs d'énumération doivent être entièrement documentés pour que l'analyse des journaux ne soit plus un jeu d'enfant.
• La structure et le contenu des journaux doivent être traités comme une API - toute modification susceptible d'interrompre la fonctionnalité d'interrogation des journaux doit être introduite de manière contrôlée, et les clients doivent avoir le temps de s'adapter aux changements.
• Tous les ajouts et (surtout) toutes les suppressions d'opérations enregistrées doivent être clairement annoncés.
• Les documents doivent être transmis beaucoup plus rapidement qu'aujourd'hui - en quelques secondes plutôt qu'en quelques minutes ou heures - et les événements ne doivent pas être retardés ou arriver dans le désordre.
• Toutes les valeurs enregistrées doivent être utiles, correctes et non ambiguës.
• Les journaux doivent contenir de nombreuses informations utiles pour la réponse aux incidents (par exemple, la réputation des adresses IP).

Idéalement, la refonte de l'architecture de journalisation pour la rendre plus rationnelle (similaire à ce qui est disponible dans AWS et Okta) serait bénéfique.

Les enseignements à tirer pour les joueurs de l'équipe rouge

Jusqu'à présent, nous n'avons parlé que des difficultés que ces problèmes posent à votre équipe. Mais il est important de se rappeler que toute perte du défenseur est un gain pour l'attaquant. Les chapeaux noirs, les APT et les red-teamers compétents peuvent tirer parti des particularités de la journalisation Azure pour dissimuler leurs actions et compliquer les efforts de l'équipe bleue.

Voici quelques-unes des techniques que les attaquants pourraient utiliser :

• Recours à des opérations inhabituelles, moins documentées ou moins comprises
• Exécution d'actions qui injectent des valeurs erronées ou non documentées dans les journaux afin de compliquer l'analyse.
• Connexion à partir d'emplacements pour lesquels les informations d'IP ou de géolocalisation sont enregistrées de manière incorrecte.
• Programmation des opérations pour tirer parti des retards d'ingestion ou pour compliquer la découverte d'événements connexes.

Bien entendu, des recherches supplémentaires seraient nécessaires pour transformer toute lacune en matière de journalisation en une technique d'évasion robuste.

Votre travail de défenseur est difficile. Essayer de détecter les attaques et d'y remédier rapidement est une entreprise de taille, et cela devient encore plus laborieux lorsque vous devez enregistrer les problèmes et les contourner.

La promesse d'une meilleure sécurité sur le site cloud n'est pas une chimère, et l'un des moyens d'y parvenir est de fournir une journalisation de haute qualité. Bien que les fournisseurs aient le pouvoir de faire en sorte que cela se produise, ils peuvent manquer de motivation pour en faire un objectif prioritaire. C'est là que nous intervenons. Plus la communauté des chercheurs en sécurité exposera de choses, et plus nous exercerons de pression, plus nous pourrons nous rapprocher de l'amélioration de la qualité des journaux.

Vous voulez participer à la conversation ? Engagez-vous directement avec l'équipe de recherche sur la sécurité de Vectra AI , sur cet article de blog et sur d'autres sujets, sur Reddit.