Écrire des règles de détection
Aperçu
Lakewatch est en Aperçu privé. Pour demander l'accès, contactez l'équipe de votre compte Databricks.
La logique d’une règle de détection correspond au SQL qui définit ce qu’elle recherche. Cette page explique comment les règles s’exécutent, comment choisir une approche pour les modèles de détection courants et comment délimiter une règle à la fenêtre de données appropriée. Pour connaître les étapes à suivre dans l’interface utilisateur pour créer une règle, consultez la section 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 s'exécute selon un programme. 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 query complète, y compris la clause FROM, afin qu'une règle puisse joindre des tables, scanner une table entière ou compute des agrégats. Une règle s'exécute sur un SQL warehouse que vous fournissez, ou sur un compute serverless ; voir Configurer un warehouse de détection.
Vous définissez la planification et le compute d'une règle lorsque vous la créez. Consultez Créer et gérer des règles de détection.
Choisir une approche
Cette table associe les motifs de détection courants à la manière dont vous rédigez chacun d’eux :
Modèle de détection | Exemple | Comment le rédiger |
|---|---|---|
Correspondance avec une signature ou un IoC | Un hachage de processus dans une liste de mauvais éléments connus ; une connexion à une IP signalée | Comparez les événements à une liste de valeurs connues comme étant malveillantes |
Signal atomique | Un nouveau compte administrateur ; un journal d’audit effacé ; une règle de transfert de boîte aux lettres ajoutée | Faire correspondre un seul événement digne d'être noté |
threshold de fenêtre courte | Plus de 5 échecs de connexion pour un utilisateur en 1 minute ; une IP échouant pour 20 comptes en 10 minutes | Agrégation et threshold sur un calendrier court |
Ligne de base comportementale ou anomalie | Un utilisateur accédant à un nombre de serveurs bien supérieur à sa norme sur 30 jours | Comparaison par rapport à une table de base |
Rare ou vu pour la première fois | Un hachage de processus jamais vu auparavant ; un premier ajout à un groupe privilégié | Comparer par rapport à une table de liste vue |
Corrélation entre sources | Connexion, puis accès au partage de fichiers, puis exfiltration, joints entre les sources | Joindre des sources sur un planning horaire ou plus court |
Limiter les règles à une période
Dans la mesure du possible, définissez une règle pour une plage de temps pertinente plutôt que d’analyser une table entière. Utilisez la fonction IN_TIMERANGE() pour exprimer cette fenêtre, et laissez l’exécution fournir les limites :
SELECT *
FROM process_activity
WHERE IN_TIMERANGE(time)
AND activity_id = 1
AND endswith(lower(process.name), '\\hashcat.exe')
IN_TIMERANGE(time) renvoie vrai quand un événement se situe dans la plage de temps effective de l’exécution actuelle. La plage est semi-ouverte : un événement dont le timestamp est égal au start de la fenêtre est inclus, mais celui qui est égal à la fin est exclu. Les exécutions adjacentes ne comptent donc jamais la limite en double. Vous n’écrivez pas vous-même les heures de start et de fin dans le SQL. Au lieu de cela, Lakewatch fournit la plage en fonction de la façon dont la query s’exécute :
- Dans une règle de détection, la fenêtre est dérivée du programme de la règle et se termine à l’heure de Trigger de l’exécution. Une règle qui s’exécute toutes les 15 minutes couvre une tranche de 15 minutes. Vous pouvez élargir cette tranche avec
extend_lookbackpour inclure les Logs arrivés tardivement. - Sur la page de la query (que vous pouvez utiliser pour développer une règle), vous sélectionnez la fenêtre à l'aide du sélecteur de date/heure. Comme le SQL écrit sur la page de la query ne contient pas lui-même la plage horaire, il peut être déployé en tant que règle de détection sans modification.
Étendre la fenêtre avec extend_lookback
IN_TIMERANGE() filtre sur le moment de l'événement, mais les logs atteignent souvent la table des minutes après que l'événement s'est produit. Une ligne peut arriver après que l'exécution dont la fenêtre couvrait le moment de l'événement soit déjà terminée, et les exécutions ultérieures analysent des moments d'événement plus récents, créant un déficit de couverture. extend_lookback, un paramètre facultatif par règle, déplace le start de la fenêtre dans le passé afin que chaque exécution réanalyse une tranche de temps d'événement plus ancienne et récupère les lignes arrivées depuis la dernière exécution. Il déplace uniquement la limite la plus ancienne ; la limite la plus récente reste au moment du Trigger de l'exécution. Réglez-la sur une durée telle que 30s, 10m ou 2h. La fenêtre analysée par une règle programmée correspond à sa cadence de programmation plus extend_lookback:
| Planning | Période analysée (se terminant à l’heure de Trigger) |
|---|---|---|
Non défini (15 mn default) | Toutes les 5 minutes | Les 20 dernières minutes |
| Toutes les 5 minutes | Les 5 dernières minutes |
| Toutes les 30 minutes | Les 42 minutes précédentes |
| Toutes les 10 minutes | Les 5 heures et 10 minutes précédentes |
Si vous ne définissez pas extend_lookback, Lakewatch applique une valeur default de 15 minutes. La plupart des sources d’entreprise fournissent les données en quelques minutes, mais rares sont celles qui garantissent une limite supérieure ; default absorbe donc les arrivées tardives habituelles sans aucun ajustement.
extend_lookback n'a pas de champ de formulaire dédié. Définissez-le en modifiant la règle en tant que YAML (voir Créer et gérer des règles de détection) et en ajoutant un bloc timerange de niveau supérieur :
timerange:
extend_lookback: 30m
Choisir la bonne colonne de temps
L'heure de l'événement (time) associée à extend_lookback est la bonne approche pour presque toutes les règles. Estimez le délai d'importation de votre source et définissez extend_lookback pour le couvrir, ou comptez sur le default de 15 minutes pour les sources qui fournissent des données rapidement.
Si la latence d’ingestion d’une source est si variable qu’aucun extend_lookback unique ne la couvre de manière fiable, vous pouvez plutôt délimiter la règle sur le temps d’ingestion. Sur les tables produites par une source de données Lakewatch, la colonne lw_meta.ingestion_time enregistre le moment où Lakewatch a écrit chaque ligne après ingestion ; ainsi, une fenêtre sur celle-ci n'est pas affectée par les retards de livraison :
WHERE IN_TIMERANGE(lw_meta.ingestion_time)
N'utilisez cette solution que lorsque le temps de l'événement plus extend_lookback ne fait pas le Job. Chaque exécution couvre ensuite une tranche fixe de temps d' ingestion plutôt que de temps d' événement . Le Timestamp d'un événement peut donc se trouver en dehors de la fenêtre nominale de l'exécution, ce qui peut fausser les agrégations par compartiment temporel. Essayez d'abord de le résoudre avec le temps de l'événement.
Évitez l’ancrage à NOW() ou CURRENT_TIMESTAMP()
Un modèle courant écrit manuellement la fenêtre par rapport à l'heure actuelle :
-- Avoid this
WHERE time BETWEEN CURRENT_TIMESTAMP() - INTERVAL 24 HOUR AND CURRENT_TIMESTAMP()
Cela fonctionne pour une exécution de routine, mais peut créer des problèmes :
- Cela peut ignorer ou double-compter des données. Une fenêtre comme « la dernière heure » est ancrée au moment où l’exécution se déclenche, et non à la tranche qu’elle est censée couvrir. Si une exécution à 3 h 00 est retardée à 3 h 12, elle analyse la période de 2 h 12 à 3 h 12, laisse un vide de 2 h 00 à 2 h 12 et peut chevaucher l’exécution suivante.
IN_TIMERANGE()dérive la fenêtre de la tranche programmée, éliminant ainsi le risque de lacune et de chevauchement. - Cela ne s’adapte pas aux modifications de planification. Si vous modifiez une règle de 15 minutes à 30 minutes, un
INTERVAL 15 MINUTEScodé en dur est erroné jusqu’à ce que vous pensiez à le modifier. AvecIN_TIMERANGE(), la fenêtre suit le calendrier. - Cela ne peut pas être re-fenêtré. Le remplissage rétroactif d'une période manquante, la réexécution après une correction de données ou la prévisualisation 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 query verrouillée sur
NOW()ne peut pas le faire sans modifications manuelles. - Il est plus difficile à reproduire. Avec les mêmes limites,
IN_TIMERANGE()scanne les mêmes lignes à chaque exécution ; les résultats sont donc reproductibles. Une query 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, comme le calcul de l'ancienneté d'un événement par rapport au moment présent.
Référencer la fenêtre de l’exécution avec TIMERANGE_NOW()
Lorsque vous avez besoin d’une valeur « maintenant » qui respecte la fenêtre de l’exécution plutôt que l’horloge murale, utilisez TIMERANGE_NOW(). Elle renvoie l’heure de Trigger de l’exécution et revient à l’heure actuelle réelle lorsqu’aucune fenêtre n’est définie (par exemple, sur la page de la query). Utilisez-la pour créer manuellement une fenêtre que IN_TIMERANGE() ne peut pas exprimer, par exemple en décalant la fenêtre ou en analysant deux périodes non adjacentes en une seule exécution :
Planning | Prédicat | Résultat |
|---|---|---|
Toutes les 10 minutes |
| Décale la fenêtre de 10 minutes de 7 minutes dans le passé |
Tous les jours |
| Correspond aux événements d’aujourd’hui et à ceux du même jour la semaine dernière |
Ce tableau récapitule quand utiliser chaque fonction :
Objectif | Utilisation |
|---|---|
Limiter une règle à sa fenêtre temporelle |
|
Référence « maintenant » qui respecte la fenêtre d’exécution |
|