Dans un paysage de menaces en constante évolution, les opérations de sécurité atteignent un point d'inflexion. À mesure que la vitesse et la complexité des menaces augmentent, les équipes s'agrandissent et les environnements gérés se multiplient. Les approches manuelles de la gestion des règles constituent souvent un goulot d'étranglement. C'est là que les détections de code (DaC) entrent en jeu, non seulement en tant qu'outil, mais aussi en tant que méthodologie.

La méthodologie DaC applique des pratiques de développement logiciel à la création, à la gestion et au déploiement de règles de détection de la sécurité. En traitant les règles de détection comme du code, il permet le contrôle des versions, les tests automatisés et les processus de déploiement, améliorant ainsi la collaboration, la cohérence et l'agilité dans la réponse aux menaces. DaC rationalise le cycle de vie des règles de détection, garantissant des détections de haute qualité grâce à des examens par les pairs et des tests automatisés. Cette méthodologie permet également de se conformer aux exigences en matière de gestion du changement et favorise une posture de sécurité mature.

C'est pourquoi nous sommes ravis de partager les dernières mises à jour des règles de détection d'Elastic, notre référentiel ouvert pour écrire, tester et gérer les règles de détection de sécurité dans Elastic, qui vous permet également de créer votre propre cadre de détection en tant que code (DaC). Poursuivez votre lecture pour découvrir des exemples de mise en œuvre utilisant des fonctionnalités étendues, et l'annonce de l'atelier gratuit d'Elastic sur les détections en tant que code.

Elastic Security DaC : de l'alpha à la disponibilité générale

Grâce à la fonctionnalité désormais fournie dans le référentiel de règles de détection, les utilisateurs peuvent gérer toutes leurs règles de détection en tant que code, revoir les réglages des règles, tester et valider automatiquement les règles et automatiser le déploiement des règles dans leurs environnements.

Avant 2024 : Utilisation interne de DaC par Elastic

L'équipe d'ingénieurs d'Elastic chargée de la recherche et de la détection des menaces a créé et utilisé le référentiel de règles de détection pour développer, tester, gérer et publier des règles préconstruites, en suivant les principes DaC - révision des règles en équipe, automatisation de leurs tests et de leur publication. Le référentiel dispose également d'un CLI interactif pour créer des règles, de sorte que les ingénieurs peuvent commencer à travailler sur les règles dès le départ.

L'intérêt de la communauté de la sécurité pour les principes as-code s'étant accru, et les API Elastic Security disponibles permettant déjà aux utilisateurs de mettre en œuvre leurs solutions personnalisées de détection en tant que code, Elastic a décidé d'étendre la fonctionnalité de référentiel de règles de détection pour permettre à nos utilisateurs de bénéficier de notre outillage et de les aider à créer leurs processus DaC.

Voici les principales étapes du développement du DaC d'Elastic, axé sur l'utilisateur, depuis l'alpha jusqu'à la disponibilité générale.

Mai 2024 : Version alpha des nouvelles fonctionnalités de ""roll your own".

Notre référentiel de règles de détection est adapté à l'usage des clients, ce qui permet de gérer des règles personnalisées, d'adapter la suite de tests aux besoins des utilisateurs et de gérer des actions et des exceptions parallèlement aux règles.

Principaux ajouts :

• Prise en charge d'un répertoire de règles personnalisées
• Sélectionnez le test à exécuter en fonction de vos besoins
• Soutien aux exceptions et aux actions

Nous avons également publié un guide complet sur les détections en tant que code avec des exemples de mise en œuvre avec Elastic Security en utilisant le référentiel detection-rules.

Août 2024 : "Fonctionnalités "Roll your own" désormais en version bêta

La fonctionnalité est étendue pour permettre l'importation et l'exportation de règles personnalisées entre Elastic Security et le référentiel, plus d'options de configuration et la fonctionnalité de versionnement étendue aux règles personnalisées.

De nouvelles fonctionnalités ont été ajoutées :

• Importation/exportation en masse de règles personnalisées (basées sur les API d'Elastic Security)
• Tests unitaires, validation et schémas entièrement configurables
• Verrouillage de la version des règles personnalisées

Mars - août 2025 : sont généralement disponibles et pris en charge

Utilisation de DaC avec Elastic Security 8.18 et plus :

• Prise en charge de la gestion des règles préétablies. Vous pouvez exporter toutes les règles préconstruites d'Elastic Security et les stocker avec vos règles personnalisées.
• Ajout de la prise en charge du filtrage des règles pour l'exportation.

Parallèlement aux efforts de DaC, nous avons également publié de nouvelles ressources Terraform(V0.12.0 et V0.13.0) en octobre-décembre 2025, permettant aux utilisateurs de Terraform de gérer les règles de détection et les exceptions.

Cette base étant posée, explorons les puissantes fonctionnalités disponibles pour rationaliser votre processus d'ingénierie de détection.

Règles de détection Points forts de la fonctionnalité DaC

Quelques ajouts intéressants ont été apportés depuis la dernière publication de DaC, que nous allons développer ci-dessous.

Filtres supplémentaires

La fonctionnalité de filtre disponible lors de l'exportation de règles depuis Kibana a été étendue pour vous permettre de définir précisément les règles à synchroniser dans DaC. Voici les nouveaux drapeaux :

Prenons l'exemple d'un cas où vous souhaitez organiser les règles par source de données et exporter les règles AWS vers un dossier spécifique. Dans ce cas, utilisons le filtrage sur les balises pour les sources de données et exportons toutes les règles avec la balise Data Source AWS:

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

Consultez la documentation Kibana sur le filtrage des chaînes de requête pour connaître l'appel API sous-jacent utilisé ici et l'appel API "list all detection rules" (liste de toutes les règles de détection ) pour obtenir des exemples de champs disponibles pour construire le filtre de requête.

Structure de dossier personnalisée

Dans le répertoire des règles de détection, nous utilisons une structure de dossier basée sur la plate-forme, l'intégration et les informations MITRE ATT&CK. Cela nous aide à nous organiser et à élaborer des règles. Ce n'est pas le seul mode d'organisation. Vous pouvez organiser vos règles par client, par date ou par source, par exemple. Cela varie considérablement en fonction de votre cas d'utilisation.

Que vous utilisiez ce processus d'exportation ou une organisation manuelle, une fois que vous avez placé vos règles dans un emplacement ou une structure de dossiers qui vous convient, vous pouvez désormais conserver cette structure locale même lorsque vous réexportez des règles. Il est important de noter que les nouvelles règles doivent être placées manuellement à l'endroit souhaité. Le mécanisme de chargement local des règles détecte l'endroit où les règles sont placées afin de savoir où les placer. Si la règle ne s'y trouve pas, il utilisera alors le répertoire de sortie spécifié pour y placer la ou les nouvelles règles. Pour utiliser le chargement des règles locales afin de mettre à jour les règles existantes, utilisez l'indicateur --load-rule-loading / -lr pour les commandes kibana export-rules et import-rules-to-repo. Ces drapeaux vous permettent d'utiliser les dossiers locaux spécifiés dans votre site config.yaml.

Prenons un exemple avec les règles organisées en dossiers de la manière suivante :

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

Nous spécifierons ce qui suit dans le fichier config.yaml:

rule_dirs:
- rules
- another_rules_dir

Avec la nouvelle option -lr, les mises à jour de règles de Kibana utiliseront désormais ces chemins supplémentaires au lieu d'exporter directement vers le répertoire spécifié.

L'exécution de python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,exportera les règles de l'espace test_local, my_test_rule.toml sera écrit dans dac_test/rules/ car il était déjà sur le disque à cet endroit et high_number_of_process_and_or_service_terminations.toml sera écrit dans dac_test/another_rules_dir/.

Cela peut être particulièrement utile si vous avez les mêmes règles dans différentes configurations de sous-dossiers pour différents clients. Par exemple, disons que vos règles sont réparties par plateforme et par intégration, comme dans la structure de dossiers de règles préconstruite d'Elastic. Pour vos clients, les SOC ou les équipes de chasseurs de menaces, l'organisation des règles sous ces dossiers de plateforme/intégration peut être le mécanisme le plus utile pour gérer les règles. Cependant, votre équipe de sécurité de l'information ou votre équipe d'ingénierie de détection primaire peut souhaiter gérer les règles par initiative ou par auteur de règle afin que toutes les règles dont une personne ou une équipe particulière est responsable soient organisées en un seul endroit. Maintenant, avec les drapeaux de chargement de règles locales, vous pouvez simplement avoir deux fichiers de configuration et les règles dupliquées dans chaque structure. Lorsque vous exportez les mises à jour des règles, vous utilisez la variable d'environnement pour sélectionner le fichier de configuration approprié et exporter les mises à jour des règles. Ces mises à jour seront ensuite appliquées aux règles en place, en maintenant la structure du répertoire.

Diverses mises à jour sur le chargement local

En plus de ce qui précède, nous avons ajouté deux nouvelles fonctionnalités moins importantes conçues pour aider les utilisateurs qui ajoutent des informations locales dans les fichiers TOML et les schémas des règles de détection. Ces derniers sont les suivants :

1. Prise en charge de la date locale à partir des fichiers locaux où la date locale sera maintenue à partir du fichier d'origine.
2. Mise à jour de la fonction de génération automatique afin d'hériter des types connus à partir des schémas existants.

Le composant date locale peut être utile lorsque l'on souhaite un contrôle plus manuel du champ date dans le fichier. Si vous n'utilisez pas cette option, la date sera basée sur la date à laquelle le contenu de la règle Kibana a été exporté. En utilisant l'option --local-creation-date, la date ne sera pas mise à jour lorsque le contenu du fichier sera réexporté.

La génération automatique de schémas a été mise à jour pour hériter des types d'autres indices/intégrations s'ils sont présents. Cela permet d'obtenir un schéma potentiellement plus précis et de réduire le besoin de mises à jour manuelles a posteriori. Par exemple, vous avez une règle qui utilise l'index "new-integration*" avec les champs suivants :

• host.os.type.new_field
• dll.Ext.relative_file_creation_time
• process.name.okta.thread

Au lieu que chacun de ces champs soit ajouté au schéma avec un type par défaut, leurs types sont hérités des schémas existants. Dans ce cas, les types dll.Ext.relative_file_creation_time et process.name.okta.thread sont hérités.

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

Pour savoir comment l'utiliser avec vos types de données personnalisés, consultez la section Utilisation des schémas personnalisés dans la partie Exemples de mise en œuvre de ce blog.

Développer les exemples d'utilisation

Vous trouverez ci-dessous d'autres exemples d'implémentations de DaC, qui ne sont pas axés sur l'ajout de nouvelles fonctionnalités, mais qui approfondissent les sujets que nous voyons discutés dans la communauté.

Il est intéressant de noter que les fonctionnalités de Detections as Code sont fournies sous forme de composants qui peuvent être utilisés pour construire une implémentation personnalisée pour le processus et l'architecture que vous avez choisis. Lorsque vous mettez en œuvre la DAC dans votre environnement de production, traitez-la comme un processus d'ingénierie et suivez les meilleures pratiques.

Mise en œuvre de DaC avec Gitlab

Lorsque nous examinons les mises en œuvre de DaC, il s'agit généralement d'utiliser une forme de produit CI/CD pour effectuer automatiquement la gestion des règles sur la base d'un déclencheur donné. Ces déclencheurs varient considérablement en fonction de la configuration souhaitée, en particulier de la source de règles faisant autorité et de l'état souhaité de votre système de contrôle des versions (VCS). Pour une exploration beaucoup plus approfondie de certaines de ces considérations, consultez notre matériel de référence DaC. Vous trouverez ci-dessous un exemple simple utilisant Gitlab comme fournisseur de VCS et utilisant son CI/CD intégré via Gitlab Actions.

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

Ceci est très similaire à d'autres CI/CD intégrés dans d'autres VCS basés sur Git comme Gitlab et Gitea. La principale différence réside dans la syntaxe qui détermine l'événement déclencheur. Les commandes DaC telles que kibana import-rules seraient les mêmes quel que soit le VCS. Dans cet exemple, nous synchronisons les règles de notre répertoire detection-rules avec notre espace de production Kibana. Ceci est basé sur un certain nombre de décisions antérieures qui ont été prises, par exemple en exigeant que les tests unitaires soient réussis avant de fusionner les mises à jour des règles et que les règles sur le main soient prêtes pour le prod. Pour une présentation de ces considérations dans le cadre de cette approche particulière, basée sur Github, veuillez consulter notre vidéo de démonstration.

Conseils et exemples de tests unitaires personnalisés

Lorsque vous envisagez d'ajouter la DaC à votre boîte à outils de détection, la mise en place de l'infrastructure CI/CD et de l'infrastructure de base doit être considérée comme la première étape d'un processus continu visant à améliorer la qualité et l'utilité de vos règles. L'un des principaux objectifs de l'outil "as code" est d'ajouter la possibilité de personnaliser davantage l'outil en fonction de vos besoins et de votre environnement.

Les tests unitaires pour les règles en sont un exemple. Au-delà des tests de fonctionnalité de base, d'autres tests unitaires clés existants mettent en œuvre des considérations spécifiques à Elastic concernant la performance et l'optimisation des règles, ainsi que l'organisation des métadonnées et du balisage. Cela permet aux ingénieurs chargés de la détection et aux chercheurs spécialisés dans les menaces de rester cohérents dans l'élaboration des règles. Sur la base de cet exemple, vous pouvez envisager d'ajouter des tests unitaires personnalisés en fonction de vos besoins spécifiques.

Pour illustrer cela, prenons l'exemple d'un centre d'opérations de sécurité (SOC) dans lequel un certain nombre d'analystes sont responsables de différents domaines et tâches. Lorsqu'une alerte est déclenchée dans le SIEM, il n'est pas toujours évident de savoir qui doit s'occuper de la remédiation ou quelle(s) équipe(s) doit(vent) être informée(s) de l'incident. Marquer les règles avec une étiquette d'équipe : ex. Team: Windows Servers De la même manière qu'Elastic utilise des balises pour les sources de données, il peut fournir au SOC un point de contact directement dans l'alerte pour qu'il puisse aider à la remédiation.

Dans notre environnement DaC, nous pouvons rapidement créer un nouveau module de test pour appliquer cette règle à toutes les règles personnalisées (ou préconstruites). Pour ce test, nous allons imposer la présence d'une balise Team: <some name> sur toutes les règles de production qui ne sont pas créées par Elastic. Dans le repo de detection-rules, nos tests sont gérés par la suite de tests Python appelée pytest et, en tant que tels, les tests unitaires sont organisés en modules (fichiers) Python et les classes et fonctions subséquentes dans ces fichiers sous le dossier tests/. Pour ajouter des tests, il suffit d'ajouter des classes ou des fonctions aux fichiers existants ou d'en créer un nouveau. En général, nous recommandons de créer de nouveaux fichiers de test afin que vous puissiez recevoir les mises à jour des tests existants de la part d'Elastic sans avoir à fusionner les différences.

Nous commencerons par créer un nouveau fichier python appelé test_custom_rules.py dans le répertoire tests/ avec le contenu suivant :

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

Désormais, chaque règle non élastique devra avoir une balise dans le modèle spécifié pour une équipe responsable de la remédiation. Par exemple Team: Team A.

Utilisation de schémas personnalisés

La capacité d'Elastic à apporter vos propres types de données s'étend également à nos capacités DaC. Par exemple, examinons quelques schémas personnalisés pour les protocoles de réseau. Les diverses données que vous avez dans votre pile peuvent bien sûr être interrogées par vos règles, et nous voudrons également tirer parti de la validation et des tests applicables à toutes les règles personnalisées sur ces types de données. C'est là que les schémas personnalisés s'avèrent utiles.

Lors de la validation des requêtes, la requête est analysée dans les champs respectifs et les types de ces champs sont comparés à ce qui est fourni dans un schéma donné (par ex. ECS, l'intégration AWS pour les données AWS, etc.) Pour les types de données personnalisés, le processus de validation est le même, avec la possibilité d'utiliser des schémas personnalisés définis localement. Ces fichiers de schéma peuvent être construits à la main sous la forme d'un ou plusieurs fichiers json ; toutefois, si vous disposez déjà d'un échantillon de données dans votre pile, vous pouvez en tirer parti et l'utiliser comme validation pour générer vos schémas automatiquement.

En supposant que vous ayez déjà configuré un dossier de règles personnalisées (si ce n'est pas le cas, voir les instructions), vous pouvez activer la génération automatique de schémas en ajoutant auto_gen_schema_file: <path_to_your_json_file> à votre fichier de configuration. Cette opération génère un fichier de schéma à l'emplacement spécifié, qui sera utilisé pour ajouter des entrées pour chaque combinaison de champ et d'index. Le fichier sera mis à jour lors de toute commande où le contenu des règles est validé par rapport à un schéma, y compris import-rules-to-repo, kibana export-rules, view-rule, et d'autres. Cela l'ajoutera automatiquement à votre fichier stack-schema-map.yaml si vous utilisez un répertoire de règles et une configuration personnalisés.

Ce pouvoir s'accompagne d'une responsabilité accrue pour les réviseurs de règles, car tout champ utilisé dans la requête est immédiatement considéré comme valide et ajouté au schéma. Une façon de réduire les risques est d'utiliser un espace de développement qui a accès aux données. Dans le PR, on peut alors établir un lien avec une exécution réussie de la requête avec une validation au niveau de la pile sur ses types de données. Une fois que cela est approuvé, vous pouvez supprimer l'ajout de auto_gen_schema_file à la configuration et vous avez maintenant un schéma valide basé sur vos données personnalisées. Cela constitue une base sur laquelle les autres auteurs de règles peuvent s'appuyer en cas de besoin et maintient la validation de la vérification du type.

Apprenez-en plus sur DaC et essayez-le vous-même

Vous pouvez faire l'expérience directe de la fonctionnalité Detections as Code (DaC) d'Elastic Security grâce à notre formation interactive Instruqt. Cette formation offre un moyen simple d'explorer les principales fonctionnalités de DaC dans un environnement de test préconfiguré, éliminant ainsi la nécessité d'une configuration manuelle. Essayez-le !

Si vous mettez en œuvre DaC, partagez votre expérience, posez vos questions et aidez les autres sur le canal DaC de la communauté Slack.

Essai Elastic Security

Pour découvrir tous les avantages qu'Elastic offre aux ingénieurs de détection, commencez votre essai gratuit d'Elastic Security. Visitez le site elastic.co/security pour en savoir plus.

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.