
Blue Planet Studio - stock.adobe
Elastic automatise la migration vers son SIEM à coup d’IA générative
Elastic exploite l’IA générative et la recherche sémantique pour migrer des règles de détection de SIEM des concurrents vers le sien, en commençant par Splunk. Habituellement, il faut passer par un douloureux processus de réécriture. Un moyen de gagner en attrait sur un marché saturé.
Avec les versions 8.18 et 9.0 d’Elastic Security liée à la licence Enterprise (ou le tier Security Analytics Complete d’Elastic Cloud Serverless), l’éditeur d’origine hollandaise introduit en préversion technique un mécanisme de migration automatique depuis Splunk vers son SIEM.
Ce système est capable de comprendre les règles écrites avec le langage spécifique au domaine SPL et de les convertir en Elastic Query Language (ES|QL). Automatique est un bien grand mot, mais le système doit éviter de récréer manuellement des règles existantes. En premier lieu, il convient de télécharger les règles au format JSON depuis Splunk, pour l’instant. Si l’outil reconnaît la règle, il peut la traduire en ES|QL.
Pour ce faire, Elastic utilise son algorithme d’indexation ELSER, une technologie qui combine recherche traditionnelle et vectorisation. Ainsi, l’éditeur ne s’appuie pas seulement sur des correspondances exactes, mais son outil peut « comprendre l’intention » derrière la règle.
Il est associé à un LLM du choix du client à travers Azure OpenAI, Amazon Bedrock, OpenAI, Google Vertex AI et, en local, à travers LM Studio. L’éditeur tient une liste des LLM des plus performants dans son cas et recommande principalement les modèles d’Anthropic.
L’IA et l’architecture RAG à la rescousse pour migrer les règles de détection
Quand ELSER est responsable de retrouver la règle correspondante, le grand modèle de langage est d’abord chargé de libeller la règle SPL avec des mots-clés qui sont utilisés par ELSER pour faciliter son travail. Ensuite, quand une règle vectorisée par Elastic est retrouvée, un LLM est chargé de déterminer si la correspondance est plus ou moins exacte. Dans le meilleur des cas, la règle ES|QL est directement ajoutée. Sinon, la règle est traduite depuis SPL.
L’éditeur dit avoir codifié la vectorisation et le mappage de plus de 1300 règles de détection couvrant une très grande partie de la matrice MITRE ATT&CK. L’outil tentera par ailleurs d’assurer la correspondance des champs du schéma Splunk Common Information (CIM) avec celui d’Elastic (Elastic Common Schema ou ECS).
Les règles de détection peuvent être partiellement transcrites, c’est notamment le cas pour celles incluant des macros et des lookups SPL ou quand certains éléments du CIM ne sont pas traduisibles en ECS. Dans ce cas-là, il est possible d’éditer manuellement la règle.
En résumé, « cela commence par l’identification des intégrations de données préconstruites à l’aide d’un système RAG. La fonction traduit ensuite la requête SQL en ES|QL, en s’appuyant sur l’IA, nourri par les connaissances personnalisées. Elle valide ensuite sa syntaxe de manière déterministe — en boucle, si nécessaire, pour réviser et retester sa logique », précise l’éditeur.
Cet outil de migration « automatique » est présenté comme un complément à Automatic Import, une fonctionnalité introduite l’année dernière pour créer ces intégrations de données personnalisées.
« De nombreuses équipes de sécurité restent bloquées sur leurs SIEM inefficaces en raison du temps et de l’argent nécessaires pour passer à une solution moderne », affirme Santosh Krishnan, directeur général de la sécurité et de l’observabilité chez Elastic, dans un communiqué de presse. « La migration des règles de détection et des tableaux de bord sont parmi les aspects les plus difficiles de la migration », ajoute-t-il. « En cartographiant et en traduisant les artefacts SIEM existants, Automatic Migration réduit les coûts, la complexité et les risques liés à la migration SIEM. »
Elastic avait déjà développé un mécanisme de RAG et de recherche de correspondance exacte pour les intégrations avec des systèmes tiers. Il avait également présenté Attack Discovery, un système qui utilise les mêmes fondations pour analyser les alertes en provenance des règles de détection afin de prioriser leurs traitements. Enfin, il mentionne Elastic AI Assistant, un chatbot intégré dans ses différentes solutions pour fournir des recommandations aux utilisateurs.
Un argument de plus pour tenter de monter en grade sur un marché saturé
S’il est de bon ton pour l’éditeur de prouver qu’il peut exploiter l’IA générative et le mécanisme RAG pour simplifier certaines étapes de configuration de son SIEM, c’est aussi une évolution logique.
Elastic entend prendre des parts de marché à ses concurrents, en commençant par Splunk. Il a déjà prévu d’étendre ses outils de migration automatique pour les adapter aux solutions d’autres fournisseurs, sans mentionner lesquels. Le développement d’ES|QL était déjà pensé pour simplifier la transition de base de données et de SIEM qui utilisent comme langage principal le SQL.
Mais il n’est pas le seul ni le premier à vouloir attirer les clients de Splunk. Pour favoriser l’adoption de Sentinel, Microsoft a également un outil pour convertir des règles SPL vers d’autres écrites en KQL (Kusto Query Language). Sous le capot, le géant du cloud semble plutôt utiliser des méthodes de comparaisons classiques. Et il a lui aussi son copilote dédié à la sécurité.
Certaines entreprises, dont Pernod-Ricard, préfèrent se tourner vers des outils dont les règles de détection par défaut correspondent en grande partie à ce qu’elles avaient déjà mis en place en interne.
Pour autant, Microsoft n’a pas la même envergure sur ce marché que son concurrent plus connu pour sa suite d’observabilité et sa base de données NoSQL. Dans son Magic Quadrant du début de l’année 2024, Gartner plaçait Splunk, Microsoft, IBM, Securonix, Exabeam en tête du marché du SIEM quand Elastic entre dans la case des « visionnaires » avec Google, Devo, Gurucul, et OpenText.