Créer et gérer des règles de détection

info

Aperçu

Lakewatch est en aperçu privé. Pour demander l'accès, contactez l'équipe de votre compte Databricks.

Les règles de détection sont des filtres qui s'exécutent sur vos tables pour identifier les anomalies et les menaces de sécurité potentielles. Les règles consomment généralement les données des tables analysées écrites par vos sources de données, mais peuvent être exécutées sur n'importe quelle table sur laquelle vous pouvez effectuer une query. Les règles identifient les signaux basés sur les critères que vous avez spécifiés.

Cette page explique comment créer, afficher, mettre à jour et gérer les règles de détection dans l’interface utilisateur.

Créer et gérer les règles de détection dans l'IU

Cette page couvre la configuration et le déploiement des règles de détection dans l’interface utilisateur. Vous configurerez les paramètres d’exécution des règles, la planification, les ressources de compute et les paramètres de génération de signal.

Avant de commencer

Prérequis : Vous devez déjà avoir conçu votre logique de détection. Cette page configure la manière dont cette logique s'exécute en production.

Workflow : une fois ce formulaire rempli, Lakewatch programme et exécute votre règle de détection en fonction de vos paramètres. Les correspondances génèrent des signaux, que Lakewatch regroupe en alertes qui apparaissent dans le panneau latéral Alertes pour examen par l'analyste. Vous pouvez également effectuer des query sur les signaux directement dans la table système signals dans Unity Catalog.

Comment créer des règles de détection ?

Allez dans Règles de détection et cliquez sur Créer une règle de détection . Le formulaire comprend la configuration du SQL et de la query, avec des paramètres organisés en tab :

• Exécution : calendrier, état actif, suppression des alertes et principal d’exécution.
• Signaux : résumé de sortie, champs contextuels et déduplication.
• MITRE ATT&CK (facultatif) : mappez la détection sur le framework MITRE ATT&CK.
• Détails : métadonnées de classification (gravité, catégorie, fidélité, objectif).

Ces contrôles d'en-tête s'appliquent partout :

• Créer avec Genie : Ouvre un panneau latéral fixe dans lequel Genie (un assistant AI) vous aide à écrire et à affiner la logique de détection. Slogan de Genie : « Créez, examinez et affinez les règles de détection avec un partenaire IA. »
• Modifier en YAML : basculez entre le formulaire et la modification de la règle au format YAML ; les deux restent synchronisés. Voir Modifier une règle au format YAML.
• Actif (bascule) : si la règle est activée et s'exécute selon son calendrier.
• Modifier la suppression des alertes (bouton) : lorsque la suppression est activée, une règle active s'exécute toujours et produit des signaux, mais ces signaux n'ouvrent pas d' alertes. Définissez une date et une heure de fin pour la suppression (obligatoire). Les heures utilisent votre fuseau horaire local et sont stockées en UTC.

Configuration des règles

Nommez la règle, définissez sa logique de détection et sélectionnez son warehouse compute :

• Nom de la règle (obligatoire) : saisissez un nom pour la règle. Il ne peut pas être changé après la création.
• SQL de détection (obligatoire) : Écrivez votre logique de détection en SQL en ligne. Voir Écrire des règles de détection pour savoir comment fonctionne le SQL de détection.
• SQL Warehouse (obligatoire) : une règle de détection exécute votre SQL de détection sur un SQL Warehouse que vous sélectionnez, dans son propre Job isolé. Les règles n'utilisent pas de regroupement de clusters ou de paramètres de compute personnalisés. Si vous n'avez pas de warehouse dimensionné pour les charges de travail de détection, consultez le guide de détection warehouse.
• Description (facultatif) : brève description de la fonction de votre règle, par exemple : « Détecte le credential stuffing » ou « Identifie les pièces jointes e-mail volumineuses ».
• Principal d'exécution (optionnel) : l'utilisateur ou le service principal en tant que lequel la règle s'exécute. default, le créateur de la règle.

tab Exécution

Configurez l'exécution de la règle, si elle est active et comment les alertes sont supprimées :

• Actif (bascule) : indique si la règle est activée et s’exécute selon son planning. Par default : activé.

• Schedule (bouton « Edit schedule » [Modifier le calendrier]) : définissez la fréquence d'exécution de la règle, en utilisant l'un des deux types de calendrier :

  • Au moins toutes les : La règle s’exécute au moins à cette fréquence (minimum 5 minutes), mais peut s’exécuter plus souvent dans certaines circonstances. Définissez une valeur et une unité : minutes, heures ou jours.
  • Exactement à : La règle s’exécute selon un calendrier cron. Créez-le avec le contrôle Chaque N et une unité (minute, heure, jour, semaine ou mois) plus le contrôle à , ou sélectionnez Afficher la syntaxe Cron pour saisir une expression cron Quartz directement.
  • Dans les deux cas, la règle est un job de batch qui s'exécute sur le SQL warehouse sélectionné à l'étape Règle et entrée , dans son propre job isolé. Le regroupement des clusters et les paramètres de compute ne s'appliquent pas.

• Suppression d’alerte (bouton « Modifier la suppression d’alerte ») : lorsqu’elle est activée, la règle s’exécute toujours et produit des signaux, mais ces signaux n’ouvrent pas d’ alertes. Définissez une date et une heure jusqu’à laquelle la suppression doit être activée (obligatoire). Les heures utilisent votre fuseau horaire local et sont stockées en UTC.

Tab Signaux

Définissez la structure des signaux produits par la règle et contrôlez la déduplication :

Résumé

Le résumé du signal apparaît dans la liste des résultats de détection et fournit aux analystes un titre rapide et descriptif de ce qui a été détecté. Ce champ vous permet de créer des messages d'alerte dynamiques en incorporant les données de l'événement d'origine à l'aide d'expressions SQL entourées de doubles accolades {sql-expression}. Les signaux qui partagent un résumé, un ID de règle et une version sont regroupés en une seule alerte; si leurs lignes de sortie entières correspondent également dans la fenêtre de déduplication, le doublon est supprimé à la place. Pour éviter de créer un nombre excessif d'alertes, gardez le résumé général et évitez les expansions de champ qui produisent une valeur unique à chaque correspondance, comme un timestamp ou un ID d'événement.

Exemple :

Brute force attempt detected for `{user.name}`

Contexte

Le champ context joint des métadonnées structurées à l'événement de signal sous forme de paires clé-valeur. Chaque clé est une étiquette et chaque valeur peut inclure des expressions SQL entourées d'accolades {sql-expression} pour insérer des détails sur l'événement. Par exemple, une clé source_ip avec une valeur {src_endpoint.ip}.

Sinon, activez Inclure toutes les données pour enregistrer automatiquement toutes les colonnes de la ligne d’entrée ayant déclenché le signal.

Déduplication

Contrôlez si Lakewatch ignore les doublons de signaux produits par cette règle. Voir Déduplication de signal pour savoir comment les doublons sont identifiés et comment fonctionne la fenêtre temporelle.

• Déduplication : activez pour supprimer les signaux dont les lignes de sortie entières sont identiques dans la fenêtre temporelle ; désactivez pour enregistrer chaque signal.
• Fenêtre temporelle de déduplication : Automatic (recommended) dérive la fenêtre de la planification de la règle. Une fenêtre personnalisée ne peut pas dépasser 7 jours.

Tab MITRE ATT&CK

Mappez la détection avec le framework MITRE ATT&CK pour une catégorisation standardisée des menaces :

MITRE ATT&CK® est une base de connaissances mondialement accessible de tactiques et de techniques adverses basées sur des observations concrètes. La base de connaissances ATT&CK sert de fondement au développement de modèles et de méthodologies de menace spécifiques dans le secteur privé, au sein des gouvernements et dans la communauté des produits et services de cybersécurité.

Si la détection correspond au cadre MITRE ATT&CK, remplissez les champs suivants pour aider les analystes à comprendre le contexte de la menace et à permettre une meilleure recherche de menaces :

Cliquez sur Ajouter pour créer un mappage, puis remplissez ces menus déroulants. Ajoutez autant de mappages que nécessaire :

• Taxonomie : la matrice MITRE ATT&CK, comme Enterprise.
• Tactique : L'objectif tactique de l'adversaire.
• Technique : la méthode utilisée pour atteindre la tactique.
• Sous-technique : variante spécifique de la technique.

Onglet Détails tab

Définissez les métadonnées de classification de la règle :

Champs obligatoires :

• Gravité : Une évaluation de la gravité de la menace, utilisée pour assigner des scores de risque aux signaux. Valeurs : Informational, Low, Medium, High, Critical.

• Catégorie : Classification décrivant la méthodologie de détection. Tous les Workspace Lakewatch incluent ces catégories default :

  • Signature statique - Pour les règles correspondant à des modèles exacts (ex. : signatures de logiciels malveillants connues)
  • Signature approximative - Pour la correspondance de motifs avec tolérance de variation (p. ex., objets de hameçonnage similaires)
  • Comportement : pour la détection basée sur les actions (p. ex., séquences d'élévation de privilèges)
  • Statistique - Pour la détection basée sur un threshold (par exemple, volume de connexion inhabituel)
  • Apprentissage (IA/ML) - Pour la détection basée sur le ML (ex. modèles de détection d'anomalies)

  Les catégories personnalisées peuvent être ajoutées dans la configuration du workspace. Les catégories permettent d’organiser les règles, de filtrer les détections par méthodologie et de comprendre la couverture de la détection.

Obligatoire sous condition :

• Fidélité : Niveau de maturité de la règle. Les règles nouvellement créées et non testées doivent être marquées comme Development ou Investigative. Les règles plus anciennes et bien testées doivent être marquées comme High. Cela aide les analystes à déterminer la probabilité qu’un signal soit un faux positif. Valeurs : Development, Investigative, Medium, High. (Requis uniquement pour la création de règles ; peut être vide pour les brouillons.)

Champs facultatifs :

• Objectif : Une description plus longue pour une documentation détaillée de la règle ; vous pouvez inclure vos raisons pour la création de la règle, la méthodologie de test et/ou des notes de mise en œuvre.
• Annotations (Paires clé/valeur) : méthode de catégorisation supplémentaire utilisant un système d'étiquetage flexible pour une organisation personnalisée.

Créer ou annuler la règle

Une fois que vous avez rempli tous les champs requis, cliquez sur Créer la règle pour l'enregistrer et la déployer. Cliquez sur Annuler pour abandonner les modifications.

Modifier une règle au format YAML

Le formulaire de règle comprend un bouton Modifier au format YAML qui ouvre un éditeur YAML. Le formulaire et l'éditeur YAML restent synchronisés : les modifications que vous apportez dans le YAML remplissent le formulaire, et le YAML reflète toujours les valeurs actuelles du formulaire. Utilisez l'éditeur YAML pour examiner une règle complète en un coup d'œil, ou pour copier une règle et ajuster quelques champs.

Le YAML d'une règle utilise des noms de champs snake_case plats, et chaque champ est associé à un contrôle dans l'assistant. L'exemple suivant définit une règle planifiée qui lit les événements d'authentification analysés et génère un signal pour chaque connexion correspondante :

YAML

catalog_name: security
schema_name: detections
rule_name: suspicious_login_activity

description: Detects login attempts from unusual locations.
severity: High
category: Behavioral
fidelity: FIDELITY_INVESTIGATIVE

schedule:
  enabled: true
  at_least_every: 1h

batch:
  sql:
    query: |
      SELECT
        time,
        actor.user.name AS user_name,
        src_endpoint.ip AS source_ip
      FROM security.parsed.authentication_events
      WHERE IN_TIMERANGE(time)
        AND activity_name = 'Logon'

output:
  event_time_column: time
  summary: 'Suspicious login from {source_ip} by {user_name}'
  context:
    user_name: '{user_name}'
    source_ip: '{source_ip}'
  default_context: false

Champs de règle

Chaque champ est mappé à un contrôle d'assistant décrit ci-dessus. Pour savoir ce qu'un champ fait, consultez son étape d'assistant.

Champ YAML	Contrôle de l’assistant	Obligatoire	Notes
catalog_name	Catalogue	Oui	Ne peut pas être modifié après la création de la règle.
schema_name	Schéma	Oui	Ne peut pas être modifié après la création de la règle.
rule_name	Nom	Oui	Ne peut pas être modifié après la création de la règle.
description	Description	Non
run_as_principal	Identité « Exécuter en tant que »	Non	Un e-mail utilisateur ou un ID d'application de service principal. default, le créateur de la règle.
batch.sql.query	SQL de détection	Oui	La query de détection. Utilisez IN_TIMERANGE() pour lui donner la portée de la fenêtre de chaque exécution. Voir Écrire des règles de détection.
batch.warehouse_id	Calculer	Non	L'ID du SQL Warehouse sur lequel la règle s'exécute.
severity	Gravité	Oui	L'un de Informational, Low, Medium, High ou Critical.
category	Catégorie	Non	Une étiquette de catégorie, telle que Behavioral.
fidelity	Fidelity	Oui	L’un de FIDELITY_DEVELOPMENT, FIDELITY_INVESTIGATIVE, FIDELITY_MEDIUM ou FIDELITY_HIGH (affichés dans l’assistant sous les noms Développement, Investigatif, Moyen et Élevé).
objective	Objectif	Non
mitre	MITRE ATT&CK	Non	Une liste de mappages, chacun avec taxonomy, tactic, technique_id, technique, sub_technique_id et sub_technique.
output.summary	Résumé	Non	Prend en charge {sql-expression} substitutions.
output.context	Contexte	Non	Une carte clé/valeur. Les valeurs prennent en charge les substitutions {sql-expression}.
output.default_context	Inclure toutes les données	Non	Lorsque true, enregistre chaque colonne de la ligne Trigger.
output.event_time_column	—	Non	La colonne de sortie qui contient le timestamp de l'événement.
deduplication	Déduplication	Non	L’une des valeurs DEDUPLICATION_DEFAULT, DEDUPLICATION_ENABLED ou DEDUPLICATION_DISABLED.
deduplication_time_window	Fenêtre temporelle de déduplication	Non	Une durée telle que 1h, 24h ou 7d, ou automatic.
schedule.enabled	Actif	Non	Indique si la règle s'exécute selon son calendrier. La valeur default est true.
schedule.at_least_every	Au moins chaque	L'un de	Un intervalle tel que 5m, 15m ou 1h (minimum 5 minutes), pour une planification Au moins chaque .
schedule.cron_expression	Exactement à	L'un de	Une expression cron Quartz, pour un calendrier Exactement à .
suppress_until_time	Supprimer jusqu’à	Non	Un timestamp jusqu’auquel les signaux de la règle ne déclenchent pas d’alertes.
annotations	Annotations	Non	Une carte clé/valeur.

Champ YAML	Contrôle de l’assistant	Obligatoire	Notes
catalog_name	Catalogue	Oui	Ne peut pas être modifié après la création de la règle.
schema_name	Schéma	Oui	Ne peut pas être modifié après la création de la règle.
rule_name	Nom	Oui	Ne peut pas être modifié après la création de la règle.
description	Description	Non
run_as_principal	Identité « Exécuter en tant que »	Non	Un e-mail utilisateur ou un ID d'application de service principal. default, le créateur de la règle.
batch.sql.query	SQL de détection	Oui	La query de détection. Utilisez IN_TIMERANGE() pour lui donner la portée de la fenêtre de chaque exécution. Voir Écrire des règles de détection.
batch.warehouse_id	Calculer	Non	L'ID du SQL Warehouse sur lequel la règle s'exécute.
severity	Gravité	Oui	L'un de Informational, Low, Medium, High ou Critical.
category	Catégorie	Non	Une étiquette de catégorie, telle que Behavioral.
fidelity	Fidelity	Oui	L’un de FIDELITY_DEVELOPMENT, FIDELITY_INVESTIGATIVE, FIDELITY_MEDIUM ou FIDELITY_HIGH (affichés dans l’assistant sous les noms Développement, Investigatif, Moyen et Élevé).
objective	Objectif	Non
mitre	MITRE ATT&CK	Non	Une liste de mappages, chacun avec taxonomy, tactic, technique_id, technique, sub_technique_id et sub_technique.
output.summary	Résumé	Non	Prend en charge {sql-expression} substitutions.
output.context	Contexte	Non	Une carte clé/valeur. Les valeurs prennent en charge les substitutions {sql-expression}.
output.default_context	Inclure toutes les données	Non	Lorsque true, enregistre chaque colonne de la ligne Trigger.
output.event_time_column	—	Non	La colonne de sortie qui contient le timestamp de l'événement.
deduplication	Déduplication	Non	L’une des valeurs DEDUPLICATION_DEFAULT, DEDUPLICATION_ENABLED ou DEDUPLICATION_DISABLED.
deduplication_time_window	Fenêtre temporelle de déduplication	Non	Une durée telle que 1h, 24h ou 7d, ou automatic.
schedule.enabled	Actif	Non	Indique si la règle s'exécute selon son calendrier. La valeur default est true.
schedule.at_least_every	Au moins chaque	L'un de	Un intervalle tel que 5m, 15m ou 1h (minimum 5 minutes), pour une planification Au moins chaque .
schedule.cron_expression	Exactement à	L'un de	Une expression cron Quartz, pour un calendrier Exactement à .
suppress_until_time	Supprimer jusqu’à	Non	Un timestamp jusqu’auquel les signaux de la règle ne déclenchent pas d’alertes.
annotations	Annotations	Non	Une carte clé/valeur.