Rédiger des règles de détection

La logique d’une règle de détection est le SQL qui définit ce qu’elle recherche. Cette page explique comment fonctionnent les règles, comment choisir une approche pour les schémas de détection courants, et comment définir le périmètre d’une règle sur la bonne fenêtre de données. Pour les étapes de l’interface utilisateur afin de créer une règle, voir Créer et gérer des règles de détection.

Comment fonctionnent les règles de détection

Chaque règle de détection dans Lakewatch fonctionne selon un planning. Lorsqu’une règle s’exécute, elle exécute votre SQL de détection sur une fenêtre temporelle et génère un signal pour chaque correspondance. Vous écrivez la requête complète, y compris la clause FROM, afin qu’une règle puisse joindre des tables, scanner une table entière ou calculer des agrégats. Une règle de détection planifiée s’exécute sur un entrepôt SQL que vous fournissez. Voir Mettre en place un entrepôt de détection.

Vous définissez la planification et les ressources de calcul d’une règle lors de sa création. Voir Créer et gérer les règles de détection.

Choix d’une approche

Ce tableau associe les schémas de détection courants à la façon de rédiger chacun :

Limiter les règles à une plage temporelle

Dans la mesure du possible, limitez la portée d’une règle à une plage de temps pertinente plutôt que de scanner une table entière. Utilisez la fonction IN_TIMERANGE pour définir cette fenêtre temporelle et laissez l’exécution fournir ses limites :

SELECT *
FROM process_activity
WHERE IN_TIMERANGE(<event_time>)
  AND activity_id = 1
  AND endswith(lower(process.name), '\\hashcat.exe')

Remplacez <event_time> par la colonne ou l’expression TIMESTAMP à filtrer.

IN_TIMERANGE(<event_time>) renvoie true lorsqu’un événement se situe dans la plage de temps effective de l’exécution en cours. La plage est à moitié ouverte : un événement dont l’horodatage est égal au début de la fenêtre est inclus, mais un événement égal à la fin est exclu. Cela évite de partager un endpoint entre fenêtres non superposées. Un non zéro extend_lookback fait intentionnellement se chevaucher des fenêtres consécutives. La déduplication des signaux contrôle les signaux répétés provenant des lignes qui correspondent. Vous n’écrivez pas vous-même les heures de début et de fin dans le SQL. À la place, Lakewatch fournit la plage en fonction de la façon dont la requête s’exécute :

• Pour une exécution planifiée, la fenêtre de base commence à l’heure d’exécution planifiée précédente et se termine à l’heure d’exécution planifiée actuelle. Cette fenêtre horaire n’est pas affectée par les retards de planning. Pour tenir compte du délai d’ingestion, consultez « Étendre la fenêtre avec extend_lookback ».
• Sur la page de requête (que vous pouvez utiliser pour élaborer une règle), vous sélectionnez la plage à l’aide du selecteur date/heure. Parce que le code SQL saisi sur la page de requête ne contient pas lui-même la plage de temps, il peut être déployé comme règle de détection sans changement.

Agrandissez la fenêtre à l’aide de extend_lookback

IN_TIMERANGE(<event_time>) filtre en fonction de l’heure de l’événement, mais les journaux n’arrivent souvent dans la table que quelques minutes après l’événement. Une ligne peut arriver après la fin de l’exécution dont la fenêtre couvrait l’horodatage de son événement. Les exécutions suivantes analysent alors des événements plus récents, ce qui crée un écart dans la couverture. extend_lookback, un paramètre facultatif propre à chaque règle, décale le début de la fenêtre temporelle vers le passé afin que chaque exécution réanalyse une partie des événements plus anciens et détecte les lignes arrivées depuis la dernière exécution. Seule la limite de début est décalée. La limite de fin reste fixée à l’heure de déclenchement planifiée actuelle. Régle-la à une durée telle que 30s, 10m, ou 2h. La fenêtre analysée par une règle planifiée correspond à son intervalle de planification, auquel s’ajoute extend_lookback :

Les exécutions qui se chevauchent peuvent sélectionner la même ligne plusieurs fois. Gardez la déduplication du signal activée et choisissez une fenêtre de déduplication qui couvre la période pendant laquelle une ligne peut être sélectionnée à nouveau. Une période de rétrospection plus longue ne prolonge pas automatiquement la fenêtre de déduplication. Évitez d’ajouter au résultat SQL des valeurs variables telles que CURRENT_TIMESTAMP() uniquement à des fins de suivi, car les lignes de résultat modifiées ne sont pas des doublons. Voir Déduplication du signal.

Si vous ne le définissez pas extend_lookback, Lakewatch applique un temps par défaut de 15 minutes. La plupart des sources d’entreprise transmettent les données en quelques minutes, mais rares sont celles qui garantissent un délai maximal. La valeur par défaut permet donc de prendre en compte les retards d’arrivée habituels sans nécessiter d’ajustement.

Pour définir extend_lookback dans l’interface, entrez une durée dans Extend lookback, à côté du SQL de détection. Utilisez des valeurs ordonnées jour, heure, minute et seconde, telles que 15m ou 1h30m. Laissez-le vide pour utiliser la valeur par défaut de 15 minutes, ou saisissez 0s pour désactiver l’extension. Le paramètre n’a aucun effet à moins que votre SQL n’utilise IN_TIMERANGE.

Choisissez la bonne colonne horaire

Une colonne de temps d’événement associée à extend_lookback est la bonne approche pour presque toutes les règles. Estimez le délai d’ingestion de votre source et définissez extend_lookback de manière à le couvrir, ou conservez la valeur par défaut de 15 minutes pour les sources qui transmettent rapidement les données.

Si la latence d’ingestion d’une source est si variable qu’aucune valeur unique de extend_lookback ne permet de la couvrir de manière fiable, vous pouvez plutôt définir la portée de la règle en fonction de l’heure d’ingestion. Sur les tables produites par une source de données Lakewatch, la lw_meta.ingestion_time colonne indique quand Lakewatch a écrit chaque ligne après ingestion, de sorte qu’une fenêtre au-dessus n’est pas affectée par les retards de livraison :

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

N’utilisez cette approche que lorsque l’horodatage des événements associé à extend_lookback ne permet pas d’obtenir le résultat souhaité. Chaque exécution couvre alors une tranche fixe du temps d’ingestion plutôt que celle de l’événement, de sorte que l’horodatage propre d’un événement peut sortir de la fenêtre nominale de l’exécution, ce qui peut fausser les agrégations par intervalles de temps. Essayez de résoudre le problème avec l’heure de l’événement d’abord.

Éviter de s’ancrer à NOW() ou CURRENT_TIMESTAMP()

Une pratique courante consiste à définir manuellement la fenêtre temporelle par rapport à l’heure système actuelle :

-- Avoid this
WHERE time BETWEEN CURRENT_TIMESTAMP() - INTERVAL 24 HOUR AND CURRENT_TIMESTAMP()

Cela fonctionne pour une exécution de routine, mais peut poser des problèmes :

• Données manquées ou comptées en double : Une fenêtre comme « la dernière heure » est ancrée au moment où l’exécution se déclenche, pas à la tranche qu’elle devait couvrir. Si une exécution de 3:00 est retardée à 3:12, elle scanne 2:12–3:12, laisse un écart de 2:00–2:12, et peut chevaucher la prochaine exécution. IN_TIMERANGE détermine la fenêtre à partir de la tranche temporelle planifiée, de sorte qu’une exécution retardée ne laisse aucun intervalle non couvert. Le chevauchement entre les exécutions planifiées provient de extend_lookback. Consultez Étendre la fenêtre avec extend_lookback.
• Modifications de la planification : si vous faites passer la fréquence d’une règle de 15 à 30 minutes, une valeur INTERVAL 15 MINUTES codée en dur devient incorrecte jusqu’à ce que vous pensiez à la modifier. Avec IN_TIMERANGE, la fenêtre temporelle s’adapte automatiquement à la planification.
• Redéfinition de la fenêtre : le rattrapage d’une période manquée, la réexécution après une correction des données ou l’aperçu d’une nouvelle règle sur des données plus anciennes exécutent tous la même règle sur une fenêtre différente. Une requête reposant sur une valeur fixe de NOW() ne peut pas s’adapter de cette manière sans modifications manuelles.
• Reproductibilité : Avec les mêmes bornes, IN_TIMERANGE il scanne les mêmes lignes à chaque exécution, donc les résultats sont répétables. Une requête liée à NOW() change à chaque exécution.

Réservez NOW() et CURRENT_TIMESTAMP() pour les cas où vous devez référencer l’heure réelle de l’horloge murale, comme en calculant l’âge d’un événement par rapport au moment présent.

Référencer la fenêtre de l’exécution à l’aide de TIMERANGE_NOW()

Lorsque vous avez besoin d’une valeur « maintenant » qui respecte la fenêtre d’exécution plutôt que l’horloge système, utilisez TIMERANGE_NOW(). Cette fonction renvoie l’heure de déclenchement planifiée de l’exécution et utilise l’heure actuelle réelle lorsqu’aucune fenêtre n’est définie (par exemple, sur la page de requête). Utilisez-le pour construire à la main une fenêtre que IN_TIMERANGE ne permet pas d’exprimer, comme décaler la fenêtre ou scanner deux périodes non adjacentes en une seule exécution :

Ces prédicats utilisent des décalages fixes de TIMERANGE_NOW(). Changer le planning ne modifie pas leurs littéraux d’intervalle. extend_lookback n’élargit pas ces fenêtres spécifiées manuellement, car il ne modifie que la limite de démarrage gérée utilisée par IN_TIMERANGE.

Ce tableau résume quand utiliser chaque fonction :