Skip to main content

The Forrester Wave™ : Plateformes XDR, T2 2026

Accéder au rapport
À propos de nousPartenairesSupport technique|Connexion
Elastic logo
Démarrez un essai gratuitNous contacter

Réduire les faux positifs grâce aux investigations SIEM automatisées d'Elastic et Tines

By
Aaron Jewitt

L'un des plus grands problèmes de gestion SIEM auxquels les équipes SOC sont confrontées est qu'elles sont souvent submergées par les faux positifs, ce qui entraîne une fatigue des analystes et des lacunes en matière de visibilité. En outre, l'un des défis les plus difficiles en matière de sécurité consiste à détecter la compromission des jetons d'accès SaaS sans aggraver le problème des faux positifs. 

Chez Elastic, l'équipe InfoSec s'attaque à ces deux problèmes en automatisant les enquêtes sur les alertes SIEM avec des outils comme Tines. Cet article de blog explique comment nous avons rationalisé nos workflows, réduit les faux positifs et donné à nos analystes les moyens de se concentrer sur les menaces réelles.

Automatisation de l'investigation initiale des alertes SIEM

Dans un article de blog précédent, nous avons expliqué comment l'équipe InfoSec d'Elastic a créé des packages de règles permettant de détecter l'analytique du comportement des utilisateurs et des entités (UEBA). À mesure que nous avons étendu ces packages d'alertes pour inclure davantage de sources de données, nous avons constaté que nous surchargions les analystes du SOC avec un niveau élevé de faux positifs causés par des activités anormales mais bénignes — par exemple, une activité de jeton API qui ne se produisait qu'une fois par mois ou provenant d'un scanner connu. Cela nous a confrontés à un problème : nous devions décider s'il fallait créer une règle de détection potentiellement bruyante en raison des faux positifs, ou accepter un manque de visibilité faute de cette détection. Une détection bruyante générant de nombreux faux positifs crée son propre type de manque de visibilité en raison de la fatigue des analystes. Mais ce problème a suscité une nouvelle réflexion : et si nous pouvions automatiser l'investigation initiale d'une alerte, en clôturant les faux positifs connus et en escaladant ceux que nous ne pouvons pas clôturer ?

Nous avons constaté que pour bon nombre de nos règles de détection UEBA et de fournisseurs SaaS, nous pouvions fermer la règle si l'activité provenait d'un appareil approuvé, tel que l'une de nos stations de travail gérées. Dans de nombreux cas, l'action initiale du playbook d'investigation consiste à utiliser une information issue de l'alerte d'origine, telle que la source.ip, puis à interroger d'autres modèles d'indexation dans Elasticsearch pour cette source.ip. Si la requête renvoie des résultats, l'alerte peut être fermée en tant que faux positif. Par exemple, si vous voyez une alerte UEBA concernant une activité de clé secrète AWS, nous exécuterions alors le groupe de requêtes suivant pour trier l'alerte et déterminer si l'activité provient d'un appareil approuvé :

  • Existe-t-il des logs de proxy montrant que l’Elastic Agent se connecte avec succès à notre serveur Fleet depuis une station de travail ou un serveur avec cette source.ip?

  • Cette source.ip appartient-elle à la plage d'adresses IP publiques de l'une des zones réseau AWS, GCP ou Azure que nous gérons et contrôlons ?

  • L'source.ip appartient-elle à une application tierce autorisée telle qu'Okta, Terraform, Tines, Qualys ou Snyk ?

  • Y a-t-il eu des connexions FIDO2 par authentification unique réussies depuis cette source.ip au cours des 2 dernières heures ?

Si l'une de ces requêtes Elasticsearch de suivi renvoie des résultats, nous pouvons supposer que cette activité de clé d'API AWS est probablement autorisée et nous pouvons fermer l'alerte. Si toutes ces requêtes renvoient zéro résultat, nous considérons que l'activité est suspecte et nous l'escaladons vers un membre de l'équipe SOC pour une enquête plus approfondie. Toutes les requêtes Elasticsearch ci-dessus peuvent être effectuées à l'aide de l'API _search, et nous pouvons utiliser l'API Signals pour fermer et marquer les alertes, ce qui nous permet d'automatiser l'ensemble du processus.

En envoyant nos détections SIEM d’Elastic vers un système d’ orchestration, automatisation et réponse en matière de sécurité (SOAR) via la fonctionnalité Alert Actions, nous pouvons utiliser notre SOAR pour exécuter automatiquement ces requêtes d’examen pour chaque alerte applicable. Sur la base des résultats des requêtes, nous pouvons fermer automatiquement l’alerte ou l’escalader vers un analyste. 

Cette capacité de tri automatisé nous permet de créer des classes entières de détections qui seraient normalement beaucoup trop bruyantes pour être étudiées sans une augmentation spectaculaire du nombre de membres du SOC. Notre workflow automatisé trie et clôture actuellement plus de 3 000 alertes par jour sans aucune intervention humaine. Il faudrait plus de 15 minutes à un analyste expérimenté par alerte pour effectuer le même tri. Si nous voulions obtenir les mêmes détections sans cette automatisation, nous aurions besoin de 94 employés à temps plein supplémentaires. Ce graphique montre nos chiffres pour les 30 derniers jours d'alertes dans notre SIEM :

30 jours d'alertes
30 jours d'alertes

Ce workflow de tri automatisé pourrait être créé à l'aide de scripts personnalisés, mais cet article vous montrera comment construire cette automatisation avec Tines. Nous avons décidé d'explorer cette voie car c'est ce qu'utilise l'équipe InfoSec d'Elastic et, pour dire les choses simplement, c'est plus facile que de scripter. Nous avons constaté que Tines facilite la création et la modification d'automatisations sans avoir besoin d'une équipe de développement dédiée.

Envoi des alertes vers n'importe quel SOAR

Comme mentionné ci-dessus, la première étape consiste à extraire le contenu de l'alerte d'Elastic Security pour l'envoyer vers la solution SOAR de votre choix. Pour ce faire, nous utilisons la fonctionnalité Alert Actions dans Elastic Security, qui effectuera une action personnalisée à chaque fois qu'une alerte est déclenchée. 

Lors de la configuration d'une règle de détection, il existe une option pour ajouter une action de règle. À partir de là, vous pouvez sélectionner le type de connecteur souhaité.

Vue de sélection du connecteur d'action de règle
Vue de sélection du connecteur d'action de règle

Le moyen le plus simple d'envoyer vos alertes à Tines consiste à configurer et à utiliser le connecteur Tines intégré dans Elastic, qui envoie vos alertes à une story Tines pour traitement.   

 L'autre option consiste à utiliser le connecteur Webhook, qui est très flexible car il vous permet d'envoyer une partie de l'alerte ou l'intégralité de son contenu au format ndjson vers un Webhook en écoute. Chez Elastic, nous utilisons Tines en interne depuis avant même l'existence du connecteur Tines ; c'est pourquoi la plupart de nos automatisations utilisent encore le connecteur Webhook. Vous pouvez envoyer les alertes une par une au Webhook ou toutes ensemble dans un seul fichier ndjson. Si vous utilisez des scripts personnalisés, vous pouvez utiliser ce connecteur pour recevoir et traiter les alertes ; il fonctionne également avec l'action Webhook de Tines. Pour envoyer l'intégralité du contenu de l'alerte vers un Webhook, vous devrez configurer un connecteur Webhook pour utiliser une action POST avec le type de contenu défini sur application/x-ndjson; charset=utf-8.

Paramètres de configuration du connecteur Webhook
Paramètres de configuration du connecteur Webhook

Lorsque vous ajoutez des actions à vos règles, sélectionnez le connecteur Webhook configuré et utilisez la syntaxe mustache suivante dans votre configuration pour envoyer l'alerte complète sous forme de ndjson au Webhook.

Configuration de l'action d'alerte vers un webhook
Configuration de l'action d'alerte vers un webhook

Utilisation de balises pour acheminer l'automatisation

Lors de la création de ces automatisations, nous avons commencé par construire un chemin d'automatisation personnalisé pour chaque alerte individuellement, mais nous avons très vite constaté que cela ne permettait pas de scaler. Notre solution a été d'utiliser des balises personnalisées dans nos règles de détection pour acheminer la règle vers le chemin de tri approprié. Nous envoyons l'alerte complète à Tines, qui inclut les balises sous forme de tableau dans le champ signal.rule.tags. Nous avons décidé d'utiliser une convention de nommage Triage:{option} pour décrire les vérifications automatisées qui seront effectuées sur une règle. Les règles de détection peuvent avoir plusieurs balises différentes.

Liste des balises de tri
Liste des balises de tri

Voici une description des balises de tri automatisé que nous utilisons :

  • Triage : Tous achemineront l'alerte via les chemins de triage automatisés Asset, PMFA et workstation. Si l'une des requêtes renvoie « true », l'alerte est fermée. Si aucune requête ne renvoie « true », l'alerte est escaladée.

  • Triage : Asset vérifiera divers modèles d'indexation pour déterminer si l'adresse IP source provient d'une ressource qu'Elastic possède ou gère d'une manière ou d'une autre. Cela inclut notre base de données Asset que nous stockons dans Elastic, les zones réseau internes, nos adresses IP publiques Elastic Cloud, les systèmes CI/CD et l'espace IP public des systèmes tiers autorisés tels qu'Okta ou Tines.

  • Triage : PMFA examinera nos logs d'audit Okta pour une authentification réussie utilisant une MFA résistante au phishing, telle qu'une passkey via Okta Verify ou Windows Hello. Nous utilisons l'intégration Okta pour collecter nos logs d'audit Okta.

  • Triage : poste de travail vérifiera nos logs de proxy Nginx pour les connexions réussies d'Elastic Defend vers notre serveur Fleet depuis l'adresse IP. Elastic est une entreprise distribuée et les employés peuvent travailler de n'importe où dans le monde, mais leurs agents Elastic Defend se connectent régulièrement ; nous pouvons donc généralement constater que le poste de travail géré d'un employé d'Elastic était connecté depuis la même adresse IP que celle ayant généré l'alerte.

  • Triage : Nouvel employé vérifiera notre base de données des actifs, qui contient un rapport quotidien de tous les employés exporté depuis notre système RH, pour voir si l'utilisateur est un nouvel employé. Ceci est important pour certaines catégories de règles de détection telles que Slack UEBA qui se déclenchent généralement lorsqu'un nouvel employé configure ses comptes, mais alertent rarement pour les employés existants.

  • Triage : 1 h indiquera à Tines de suspendre le triage des alertes pendant 1 heure avant d'effectuer le reste des actions de triage. Cela peut être utile pour des événements tels qu'un utilisateur configurant une toute nouvelle station de travail, où l'alerte peut être fermée si la station de travail est correctement inscrite et enregistrée auprès de nos systèmes de gestion des points de terminaison qui installent Elastic Defend.

  • Triage : 24 h indiquera à Tines de suspendre le triage des alertes pendant 24 heures complètes avant le traitement. Cela peut être nécessaire pour certains chemins de triage où les données ne sont mises à jour que quotidiennement, comme certaines parties de notre base de données d'actifs qui collectent un inventaire quotidien de tous les ordinateurs, utilisateurs et comptes cloud.

  • Triage : personnalisé est destiné à tout chemin de triage personnalisé pouvant être requis pour une alerte. Un bon exemple est un scénario dans lequel nous avons fourni à un tiers, tel qu'Okta, une clé d'API hautement privilégiée utilisée pour créer ou désactiver des comptes dans Azure, et nous souhaitons être alertés si ce jeton d'API est utilisé depuis une adresse IP qui n'appartient pas à Okta. Cette alerte et ce triage automatisé nous permettent de « faire confiance, mais vérifier » au cas où le stockage de notre clé d'API par Okta serait compromis et utilisé en dehors des espaces IP d'Okta.

Blocs de construction pour l'automatisation

Maintenant que nous envoyons l'alerte complète sous forme de JSON à notre SOAR, nous pouvons l'envoyer via notre parcours de tri, puis vers d'autres sources telles que Slack ou PagerDuty. Dans Tines, il existe sept types différents d'actions qui peuvent être utilisées pour créer vos témoignages :

  • L'action Webhook émettra les événements qu'elle reçoit via des webhooks (callbacks HTTP). Il s'agit de la méthode principale pour envoyer des événements à une story dans Tines.

  • L'action Envoyer un e-mail envoie des e-mails aux destinataires spécifiés dans les options de l'action.

  • L'action Receive Email, anciennement connue sous le nom d'action IMAP, émet des événements lorsqu'elle détecte de nouveaux e-mails sur un serveur IMAP ou lorsque des e-mails sont envoyés à une adresse e-mail générée de manière unique.

  • L'action de transformation d'événement dispose de plusieurs modes qui modifient le contenu des événements reçus. Ces actions sont extrêmement flexibles et puissantes.

  • L'action HTTP Request envoie des requêtes HTTP en utilisant diverses méthodes vers une URL spécifiée.

  • Le déclencheur action compare le contenu d'un champ provenant d'un événement entrant avec des règles prédéfinies, et lorsque les règles correspondent, une émission d'événement est déclenchée. Cela peut être considéré comme une action logique « Si Alors ».

  • L'action Send to Story envoie des événements à une autre story Tines (la sous-story). Une fois que la sous-story a terminé son action, l'action Send to Story émet un événement. Les actions Send to Story sont similaires aux fonctions ou aux bibliothèques dans le code, lorsque vous souhaitez réutiliser des actions à plusieurs endroits.

Grâce à ces actions, nous pouvons créer des automatisations qui nous permettent d'économiser des milliers d'heures de travail par mois.

Exemple de workflow de tri automatisé simplifié :

Scénario de triage Tines
Scénario de triage Tines

Dans ce scénario d'automatisation, nous traitons les nouvelles alertes à mesure qu'elles arrivent dans le Webhook, nous utilisons une action de transformation d'événement pour analyser le ndjson en un objet que nous pouvons plus facilement référencer, puis nous utilisons des actions de déclenchement pour déterminer les chemins de triage que l'alerte doit suivre.

La plupart des actions de requête HTTP sont des interrogations de l'API _search d'Elasticsearch. Dans ces requêtes de suivi, nous utilisons des champs issus de l'alerte initiale, tels que source.ip ou user.email, pour trier les alertes. 

Tines est fourni avec des centaines de modèles d’action prédéfinis, dont plusieurs pour interagir avec Elasticsearch. Vous pouvez utiliser le modèle « Interroger un index Elasticsearch pour tous les enregistrements », puis modifier la charge utile pour ajouter votre requête en utilisant l’adresse IP source de l’alerte. Comme la plupart des requêtes recherchent n’importe quels événements provenant d’une source.ip spécifique, je recommande d’ajouter l’option « size » : 1 à vos requêtes pour améliorer la vitesse et les performances. Cela renverra un résultat si Elasticsearch trouve une correspondance avec la source.ip au cours des 4 dernières heures.

{
  "size": 1,
  "query": {
    "bool": {
      "must": [],
      "filter": [
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "source.ip": "<<extract_source_ip.source_ip>>"
                }
              }
            ]
          }
        },
        {
          "range": {
            "@timestamp": {
              "format": "strict_date_optional_time",
              "gte": "now-4h",
              "lte": "now"
            }
          }
        }
      ],
      "should": [],
      "must_not": []
    }
  }
}

Après chaque action de requête, nous avons une action de déclenchement pour vérifier si des résultats ont été trouvés. Si le nombre de résultats est supérieur à zéro, nous utilisons l'API Signals pour fermer l'alerte. S'il n'y a aucun résultat, nous poursuivons le traitement et passons à l'action suivante. Si toutes les actions renvoient zéro résultat, nous envoyons alors l'alerte sur Slack pour avertir les analystes afin qu'ils mènent une investigation. 

Voici des exemples de paramètres pour une action de déclenchement qui vérifie s'il existe des résultats pour une requête :

Paramètres des actions de déclenchement
Paramètres des actions de déclenchement

En utilisant la logique consistant à exécuter une requête Elasticsearch, puis à fermer l'alerte s'il y a des résultats, nous pouvons enchaîner plusieurs de ces actions pour construire des scénarios complets qui ferment les alertes provenant d'adresses IP connues et fiables.

Exemple de triage de station de travail gérée

Dans l'exemple de branche de scénario ci-dessous, nous fermons toute alerte provenant d'une station de travail ou d'un serveur que nous gérons. Elastic est une entreprise mondialement distribuée et la majorité de nos employés travaillent depuis leur domicile ; nous n'avons donc aucun moyen de prédire l'adresse IP à partir de laquelle ils se connecteront à Internet et, dans de nombreux cas, leur adresse IP publique peut changer plusieurs fois par jour. Notre solution pour identifier de manière fiable les adresses IP publiques de ces postes de travail lorsqu'ils se déplacent dans le monde entier consiste à déployer Elastic Agent sur les proxies nginx situés devant notre infrastructure InfoSec. 

Grâce à ces données, nous pouvons désormais identifier les connexions réussies via le proxy envoyant du trafic Elastic Agent, Auditbeat ou Endgame vers nos clusters. Tous nos systèmes de serveurs cloud ont Auditbeat ou Elastic Agent installés ; ces requêtes détecteront donc également les adresses IP publiques de nos systèmes de serveurs qui utilisent régulièrement des clés secrètes pour exécuter des pipelines CI/CD et DevOps.

Vous trouverez ci-dessous le chemin dans le scénario Tines que nous utilisons pour vérifier la présence d'un poste de travail ou d'un serveur géré à partir d'une adresse IP source. Les lignes en pointillés partant des actions de déclenchement représentent le chemin suivi par le scénario si une action de déclenchement ne renvoie pas « true ».

Branche de témoignage sur les postes de travail
Branche de témoignage sur les postes de travail

L'alerte de fermeture Envoyer au scénario

Vous avez peut-être remarqué qu'à chaque fois que nous voulons fermer l'alerte, nous utilisons une action Send to Story dans Tines. Cette action enverra les champs que nous avons choisis vers un nouveau témoignage dans Tines via un Webhook, où nous fermerons et marquerons ensuite l'alerte. En utilisant une action Send to Story, nous facilitons d'assurer la maintenance de notre témoignage principal et nous pouvons ajouter des fonctionnalités supplémentaires, comme la déduplication par ID de signal afin de ne pas essayer de fermer la même alerte deux fois depuis deux branches de tri différentes, et l'utilisation d'une action de limitation (throttle) pour ne pas surcharger l'API si un grand nombre d'alertes arrivent simultanément. 

Nous utilisons également l'API Signals pour mettre à jour les tags de règle, ce qui peut être utile pour les métriques et le suivi du statut des alertes. Toutes les alertes que nous fermons avec notre workflow de triage automatisé sont également taguées comme Triage automatisé afin que nous puissions suivre le nombre d'alertes triées par mois et voir facilement dans l'interface utilisateur SIEM si une alerte a été fermée par l'automatisation ou par un analyste.

Fermer l'alerte Envoyer vers Story
Fermer l'alerte Envoyer vers Story

Escalade des alertes ouvertes vers Slack

Comme nous envoyons les alertes via les différents chemins de triage automatisés en parallèle, nous envoyons également l'historique sur un chemin où nous suspendons le traitement pendant 5 minutes. Cette pause de 5 minutes permet aux autres branches de terminer et de fermer les alertes qui s'avèrent provenir d'une adresse IP source de confiance. Après la pause de 5 minutes, nous envoyons une requête à l'API de recherche de signaux pour vérifier si l'alerte est toujours ouverte. Si l'alerte est toujours ouverte, nous envoyons un message sur notre canal Slack dédié aux alertes pour informer les analystes du SOC qu'une alerte n'a pas été triée automatiquement.

Escalade des alertes ouvertes vers Slack
Escalade des alertes ouvertes vers Slack

Si vous souhaitez ajouter plus de fonctionnalités à ce scénario, Tines facilite la création d'une autre branche pour ajouter des capacités supplémentaires. Par exemple, si vous avez un accord de niveau de service (SLA) exigeant que vous accusiez réception des alertes de gravité critique ou élevée dans un certain délai, vous pourriez ajouter une logique pour attendre une heure, puis vérifier si l'alerte a été acquittée dans Elastic SIEM. Si l'alerte est toujours ouverte et n'a été assignée à personne, vous pouvez procéder à une escalade en envoyant une alerte à PagerDuty ou un second message Slack à une autre équipe.

Escalade vers PagerDuty
Escalade vers PagerDuty

Tines inclut également des modèles pour travailler avec les incidents dans Elastic Security — avec quelques actions supplémentaires dans cette branche, vous pourriez ouvrir un nouvel incident, l'assigner à l'analyste de garde et ajouter les détails de l'alerte à l'incident.

Défis rencontrés

Rien n'est parfait en matière de sécurité, et pour chaque contrôle de sécurité, il existe des moyens pour les acteurs malveillants de les contourner. Mais ce n’est pas parce qu’une chose n’est pas parfaite qu’elle ne vaut pas la peine d’être faite. L'une des faiblesses évidentes est que ces alertes ont une efficacité limitée contre les menaces internes. Si un acteur malveillant pivote via une station de travail, un serveur ou une connexion VPN d'entreprise compromis, il peut alors provenir d'une adresse IP connue et fiable, et pour les règles avec des workflows de tri automatisés, les alertes seraient fermées automatiquement. 

J'ai deux arguments à ce sujet : le premier est que sans cette automatisation, la plupart de ces détections sont impossibles à déployer sans des centaines d'employés supplémentaires. Malgré leurs faiblesses, ces détections automatisées offrent une meilleure visibilité que l'absence de détection. Les alertes triées peuvent être utilisées pour la chasse aux menaces et incluses dans des détections qui alertent sur plusieurs règles de détection distinctes pour un hôte ou un utilisateur afin qu'elles puissent toujours apporter de la valeur.

Deuxièmement, si nous pouvons forcer les acteurs malveillants à changer de tactique — par exemple en les obligeant à compromettre et à pivoter via l'une de nos stations de travail ou l'un de nos serveurs —, cela augmente considérablement les chances de détection. Nos stations de travail et nos serveurs sont hautement instrumentés avec Elastic Defend et contiennent plus d'un millier de règles de détection en place. Nous avons constaté que la plupart du temps, lorsqu'un acteur malveillant compromet des identifiants SaaS ou un jeton secret d'API, il se connecte généralement au service directement depuis sa propre infrastructure et non via un hôte compromis.

L'autre défi majeur lors de la création de ces détections est le Shadow IT ainsi que toutes les interconnexions et relations de confiance avec des tiers dans un système informatique moderne. Le Shadow IT est un terme utilisé pour décrire le moment où une équipe au sein de l'entreprise met en place ses propres systèmes informatiques sans passer par les canaux appropriés pour ajouter ces systèmes à l'inventaire des ressources et installer Elastic Agent ou Auditbeat. 

Lorsque vous créez ces workflows de triage et que vous définissez ce qu’est une « adresse IP connue et fiable », vous constaterez inévitablement que des jetons d’API sont utilisés de manière autorisée à partir d’adresses IP qui n’appartiennent pas à votre entreprise. Ces jetons sont généralement utilisés pour diverses automatisations tierces telles que GitHub Actions ou par des applications d’analyse comme Qualys ou Snyk. Traquer ces éléments et créer les exceptions peut prendre du temps, mais cela peut également s’avérer très précieux pour identifier et supprimer le Shadow IT.

Dans certains cas, les fournisseurs tiers tels qu'Okta, GitHub ou Elastic Cloud publient leurs espaces IP publics afin que vous puissiez mettre en place des contrôles supplémentaires pour filtrer l'activité provenant de ces adresses IP. Si vous utilisez un locataire cloud Tines, vous pouvez récupérer l'adresse IP publique actuelle de votre locataire à l'adresse https://<tenant-domain>/info.

Exemples de détections

Ces automatisations ont initialement été conçues comme une solution pour une règle de détection unique, mais nous avons constaté qu'elles sont extrêmement précieuses pour de nombreux scénarios différents. Pour nombre de vos règles de détection, vous pouvez vous poser la question suivante : « Si cette alerte est déclenchée par une adresse IP dont nous avons confirmé qu'elle nous appartient, notre SOC fermerait-il l'alerte ? » Nous avons constaté que cela s'applique à la plupart des règles de détection basées sur le comportement pour les services tiers, ce qui en fait de bons candidats pour un tri automatisé.    

 

Voici une liste de certaines des détections pour lesquelles nous automatisons le tri initial, afin de vous donner des idées de détections que vous pouvez créer avec ce workflow. Certaines de ces détections sont des détections personnalisées conçues pour fonctionner avec ce workflow de tri automatisé, mais beaucoup d'entre elles sont des détections existantes auxquelles nous avons ajouté des balises de tri afin d'éliminer certains faux positifs.

 

Atteindre de nouveaux niveaux de protection

Dans cet article de blog, je vous ai montré comment l'équipe d'Elastic en charge de la sécurité des informations utilise Tines pour automatiser le triage initial d'un grand nombre de nos alertes. Cette automatisation nous permet d'avoir une bien meilleure visibilité tout en renforçant l'efficacité, et nous permet de consacrer notre temps à l'investigation des menaces réelles. Grâce à Tines, nous avons pu enquêter de manière exhaustive et clôturer plus de 50 000 alertes au cours des 30 derniers jours. Chacune de ces alertes a été minutieusement examinée et clôturée quelques secondes après son déclenchement. Il serait impossible d'avoir le même niveau de protection sur notre réseau sans cela. 

Si vous souhaitez essayer par vous-même, vous pouvez le faire gratuitement avec un essai de 14 jours d'Elastic Cloud et l'édition communautaire toujours gratuite de Tines pour constater à quel point ces workflows peuvent être puissants pour vous.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Optez pour un déploiement ultra-complet sur la plateforme cloud de votre choix. En tant que créateurs d'Elasticsearch, nous mettons nos fonctionnalités et notre support technique au service de vos clusters Elastic dans le cloud.

Démarrer un essai gratuit