Suivre La portabilité des règles de détection est la pratique consistant à écrire et gérer la logique de détection de menaces de manière à ce qu’elle puisse se déplacer à travers les plateformes SIEM, EDR et XDR sans réécriture complète.
Que se passe-t-il avec mes règles de détection lorsque je migre vers une nouvelle plateforme SIEM ?
Les règles écrites dans le langage de requête natif d’une plateforme ne voyagent pas. SPL reste dans Splunk. KQL reste dans Microsoft Sentinel. YARA-L reste dans Google SecOps. Lorsque vous migrez, ces règles doivent être réécrites ou traduites pour la plateforme de destination.
La fidélité de la traduction dépend de la construction, pas de la paire de langues. Deux axes de dégradation décident de ce qui survit.
Axe 1 : mappage des champs. Les taxonomies de champs sources (CIM, ASIM, ECS, OCSF, Sysmon-native, fournisseur-native) ne se mappent pas complètement. Un champ non mappé ou renommé réduit silencieusement ou casse la règle.
Axe 2 : sémantique des constructions. La sémantique d’agrégation et de fenêtre temporelle, la logique de séquence ou de transaction, le dialecte regex et les fonctions de type eval/lookup/join n’ont souvent que des analogies partielles sur la plateforme cible. Cet axe porte la part de réécriture.
Sigma les règles sont conçues pour être traduites. Elles sont rédigées une fois et traduites par backend via pySigma, sigma-cli, ou Uncoder.
La traduction n’est pas une préservation. Chaque règle traduite nécessite encore une validation propre au backend contre les champs analysés de la destination avant qu’elle ne soit fiable. Une traduction syntaxiquement correcte peut référencer des champs que la nouvelle plateforme ne remplit jamais.
Le routage du pipeline de télémétrie est un mécanisme distinct. Acheminer un flux de journaux vers une nouvelle destination ne transfère pas la logique de détection qui a fonctionné dessus. SPL reste SPL, indépendamment de l’endroit où atterrissent les journaux.
Quelle est la différence entre les règles de détection spécifiques au fournisseur et celles indépendantes ?
Une règle spécifique à un fournisseur est un atout de la plateforme. Une règle indépendante du fournisseur est un atout de l’équipe.
| Dimension | SPL (Splunk) | KQL (Microsoft Sentinel) | YARA-L (Google SecOps) | Sigma |
|---|---|---|---|---|
| S’exécute nativement sur | Splunk | Microsoft Sentinel | Google SecOps | Aucun directement. Se traduit en tous les trois plus IBM QRadar, Elastic, CrowdStrike, et d’autres. |
| Le déplacer nécessite | Réécriture dans le langage cible | Réécriture dans le langage cible | Réécriture dans le langage cible | Traduction via pySigma/sigma-cli ou Uncoder, puis validation du mappage des champs |
| À qui cela appartient-il | Le déploiement Splunk | L’espace de travail Sentinel | Le locataire SecOps | Votre équipe, dans le contrôle de version |
| Coût multi-plateformes | Écrire N copies | Écrire N copies | Écrire N copies | Traduire une fois par backend, valider une fois par backend |
La différence de coût apparaît à la migration et à l’opération multi-plateformes. La logique de détection indépendante du fournisseur reste portable sur l’ensemble de votre pile.
Comment migrer le contenu de la détection de Splunk vers Microsoft Sentinel ?
Six étapes. C’est l’une des paires de langues les plus difficiles car SPL et KQL diffèrent sur le modèle de données, le nommage des champs et la sémantique des fonctions.
- Inventoriez les règles SPL. Exportez chaque recherche enregistrée, alerte, et recherche de corrélation. Notez les dépendances de modèle de données de chaque règle (type source, index, noms de champs).
- Classifiez par type de construction. Triez les règles en trois catégories : logique de sélection simple (se déplace proprement), dépendante du mappage de champs (se déplace avec travail de mappage), et logique de corrélation/état (exige une réécriture manuelle).
- Traduisez via Sigma. Convertissez les règles SPL en Sigma, puis traduire Sigma en KQL en utilisant pySigma avec le backend Microsoft Sentinel, sigma-cli ou Uncoder. Cela gère la syntaxe. Cela ne gère pas le mappage des champs.
- Mappez les champs selon le schéma Sentinel. Alignez les noms de champs CIM aux équivalents ASIM. Microsoft documente leur schéma à learn.microsoft.com. Chaque champ dans la règle traduite doit correspondre à une colonne dans la table de destination.
- Testez sur les tables Sentinel. Exécutez chaque règle traduite sur des données réellement ingérées. Gardez un événement de test par règle pour pouvoir vérifier la correspondance après tout changement de schéma.
- Passez à l’étape suivante avec une fenêtre d’exécution parallèle. Faites fonctionner les deux plateformes sur les mêmes sources de journaux. Comparez la sortie d’alerte. Retirez la version SPL uniquement après que la version KQL s’exécute sur les mêmes événements.
Avant de passer à l’étape suivante, mappez les règles déployées sur les deux plateformes à MITRE ATT&CK techniques et comparez les deux cartes, pour qu’une technique que la migration laisse tomber se montre avant la transition, pas après ; SOC Prime MITRE ATT&CK Audit cartographie les détections déployées et les sources de données à ATT&CK en tant que service.
Migration d’une bibliothèque de règles ? Explorez le Prime Architect de SOC Prime pour la traduction de règles multi-plateformes, la recherche sur les menaces et les flux de travail d’ingénierie de détection.
Quelles sont les meilleures pratiques pour traduire des langages de requêtes comme SPL en KQL ?
Traduisez la logique, pas la syntaxe. Un transfert caractère par caractère produit des règles fragiles qui référencent des champs que la destination peut ne pas remplir.
- Mappez les champs selon le schéma de destination. Ne supposez pas que les noms de champs se transfèrent. CIM de Splunk et ASIM de Sentinel sont des contrats différents. L’effort de migration se situe dans le mappage entre eux.
- Gardez un événement de test par règle. Un événement connu-mauvais associé à un événement connu-bénin. Si la règle traduite ne correspond pas au mauvais et ne rejette pas le bénin, quelque chose a échoué dans la traduction.
- Examinez tout ce que le traducteur signale. Les traducteurs automatisés gèrent bien la logique de sélection simple. Les règles de corrélation, les fonctions propriétaires et les agrégations complexes nécessitent un examen humain.
- Nommez vos outils. Prime Architect traduit Sigma en 65 langages de détection, migre entre les langages de requête natifs tels que SPL et KQL, applique des préréglages de mappage de champs pour l’environnement que vous connectez, et déploie à partir d’un référentiel de règles gouverné dans une plateforme cible prise en charge. L’open source Uncoder IO couvre l’étape de traduction et peut fonctionner en autogestion (source sur GitHub). Aucun des trois n’élimine la validation du mappage de champs.
Exemple : une règle de création de processus simple traduisant EventCode=4688 et New_Process_Name (Splunk CIM) en EventID == 4688 et NewProcessName (table SecurityEvent de Sentinel). Même fait, nom de champ différent par contrat de plateforme.
Le joker ancré final SPL devient un opérateur endswith KQL. Ce couple fonctionne parce qu’il s’agit d’une correspondance de champ à événement unique. Les règles de corrélation ne se traduisent pas aussi proprement.
Combien de temps prend la migration d’une bibliothèque de règles, et qu’est-ce qui la détermine ?
Trois déterminants de l’effort.
Nombre de règles. Plus de règles, plus de cycles de validation. Chaque règle traduite a besoin d’un test contre les données ingérées de la destination.
Champs personnalisés et dépendances de modèle de données. Les règles qui font référence à des champs spécifiques au fournisseur, des extractions personnalisées ou des tables de recherche nécessitent un travail de mappage par champs. Plus il y a de personnalisations dans la source, plus il y a de travail manuel dans la migration.
Effort de validation. Chaque règle traduite doit être validée par rapport aux champs analysés de la plateforme de destination. Une traduction syntaxiquement correcte peut échouer silencieusement si le schéma cible ne renseigne pas le champ référencé.
Le livrable honnête d’une évaluation de migration est une classification par règle : se déplace proprement, se déplace avec travail de mappage, ou nécessite une réécriture manuelle. Une estimation unique du temps pour toute la bibliothèque représente mal la répartition des efforts.
Comment éviter l’enfermement la prochaine fois ?
Trois pratiques.
- Rédigez en Sigma. Rédigez la logique de détection indépendante du fournisseur dès le début. Les règles Sigma se traduisent pour toutes les grandes plateformes SIEM, EDR et XDR. Le contenu de détection déjà sourcé en Sigma, tel que les règles Sigma dans SOC Prime’s Core, garde la bibliothèque portable dès la première règle.
- Gardez la logique sous contrôle de version. Stockez vos règles de détection dans Git aux côtés des mappages de champs et des événements de test pour chaque backend cible. Les règles voyagent avec l’équipe, pas la plateforme.
- Traduisez lors du déploiement. Utilisez pySigma, sigma-cli, ou Uncoder pour générer des requêtes natives à la plateforme au moment du déploiement. La source reste portable. La sortie compilée est jetable.
Cette séparation signifie qu’une migration de plateforme change la cible de la traduction, pas la logique de détection.
Acheminer la télémétrie à travers un pipeline est-il équivalent au portage de vos détections ?
Non. Un pipeline de télémétrie (Cribl et des outils similaires) déplace les données. Il ne déplace pas la logique de détection.
Acheminer un flux de journaux de Splunk vers Microsoft Sentinel à travers un pipeline livre les événements à une nouvelle destination. Les règles SPL qui ont fonctionné sur ces événements dans Splunk ne suivent pas. SPL reste SPL. La logique de détection doit encore être traduite ou réécrite pour la plateforme de destination.
Le routage par pipeline résout le problème de la livraison des données. La portabilité de la détection résout le problème de la traduction de la logique. Ils sont indépendants. Une équipe qui achemine la télémétrie vers un nouveau SIEM sans porter ses détections a des données dans un nouvel endroit mais pas de règles pour correspondre aux données.
L’exception est un pipeline qui exécute lui-même les détections : Prime Detect de SOC Prime applique des règles en Sigma à la couche pipeline avant le SIEM, et son édition open-source est sur GitHub.
Où cela ne tient pas
Tout ne se traduit pas, même avec Sigma. Quatre classes de constructions nécessitent des réécritures manuelles sur la plateforme de destination.
- Logique de corrélation et d’état. Comptage et agrégation de valeurs, séquence temporelle, corrélation multi-événements. Sigma a ajouté des types de règles de corrélation dans sa spécification v2, mais le support backend varie par backend pySigma. L’exécution par planification par rapport au streaming change aussi ce qu’une règle peut exprimer.
- Fonctions propriétaires. Transaction Splunk, expressions eval, enrichissement basé sur les recherches, macros. Les analogues KQL sont partiels.
- Certains modèles d’agrégation. Les constructions de seuil sur une fenêtre et patterns stats … par … span= se traduisent inégalement entre plateformes.
- Références de champs dépendant du schéma. La même règle de création de processus Sigma tombe sur un champ différent selon le pipeline. Sur Sysmon, c’est Image. Sur Splunk Windows Security, c’est New_Process_Name. La traduction est correcte seulement vis-à-vis du schéma réellement déployé.
Ces constructions sont celles pour lesquelles la classification par règle est la plus importante. Attendez-vous à ce qu’elles nécessitent une validation manuelle et, dans de nombreux cas, une réécriture complète.
Liste de contrôle de préparation à la migration
[ ] Inventaire complet des règles exporté (recherches enregistrées, alertes, recherches de corrélation)
[ ] Chaque règle classée : se déplace proprement / se déplace avec mappage / réécriture requise
[ ] Tableau de mappage des champs construit : schéma source au schéma de destination
[ ] Versions Sigma des règles portables créées et stockées dans le contrôle de version
[ ] Outils de traduction sélectionnés (pySigma/sigma-cli, Uncoder, ou les deux)
[ ] Paires d'événements de test créées par règle (un connu-mauvais, un connu-bénin)
[ ] Règles traduites validées contre des tables de destination avec des données réellement ingérées
[ ] Règles de corrélation et d'état identifiées pour réécriture manuelle
[ ] Fonctions propriétaires cataloguées (transaction, eval, recherches, macros)
[ ] Fenêtre d'exécution parallèle définie : les deux plateformes ingérant les mêmes sources
[ ] Critères de comparaison de sortie d'alerte documentés
[ ] Plan de retour en arrière défini : conditions pour revenir à la plateforme source
FAQ
Que se passe-t-il avec mes règles de détection lorsque je migre vers une nouvelle plateforme SIEM ?
Les règles natives des plateformes ne voyagent pas. SPL, KQL, et YARA-L doivent être réécrites ou traduites pour la plateforme de destination. Une règle rédigée en Sigma est traduite une fois par backend, et chaque règle traduite nécessite encore une validation contre les champs analysés de la destination. La corrélation, la logique d’état, les fonctions propriétaires, et certains patterns d’agrégation ne se traduisent pas proprement.
Comment migrer le contenu de la détection de Splunk vers Microsoft Sentinel ?
Inventoriez les règles SPL, classez-les chacune par type de construction, traduisez via Sigma avec pySigma ou Uncoder, mappez les champs du schéma Splunk au schéma Sentinel, testez chaque règle avec des données Sentinel réellement ingérées, puis passez à l’étape suivante avec une fenêtre d’exécution parallèle avant de retirer la version SPL. Microsoft documente le schéma Sentinel sur learn.microsoft.com.
Quelle est la différence entre les règles de détection spécifiques au fournisseur et celles indépendantes ?
Une règle spécifique à un fournisseur est un atout de la plateforme sur laquelle elle s’exécute. Une règle indépendante du fournisseur rédigée en Sigma est un atout de l’équipe, gardée sous contrôle de version et traduite par backend. La différence de coût apparaît à la migration et à l’opération multi-plateformes.
Acheminer la télémétrie à travers un pipeline rend-il mes détections portables ?
Non. Un pipeline de télémétrie déplace les données vers une nouvelle destination. Il ne déplace pas la logique de détection qui a fonctionné dessus. SPL reste SPL où que les journaux atterrissent, donc les règles ont encore besoin de traduction ou d’une réécriture.
Quelles sont les meilleures pratiques pour traduire un langage de requête comme SPL en KQL ?
Traduisez la logique, pas la syntaxe. Mappez chaque champ selon le schéma de destination, gardez un événement de test connu-mauvais et un connu-bénin par règle, et revoyez tout ce que le traducteur signale, car les règles de corrélation et les fonctions propriétaires ont besoin d’une révision humaine. pySigma, sigma-cli, et Uncoder gèrent la traduction Sigma, et aucun ne supprime la validation du mappage de champs.
Évaluez votre couverture SIEM existante et créez un plan pour votre transition en utilisant Prime Hunt. Prime Hunt passe en revue toutes vos règles SIEM, identifie les lacunes et établit un parcours pour une couverture totale – travail critique avant une migration SIEM.
