Chez Elastic, nous exploitons un ensemble important et diversifié de règles de détection des comportements sur plusieurs ensembles de données, environnements et niveaux de gravité. La plupart de ces règles sont atomiques, chacune étant conçue pour détecter un comportement, un signal ou un modèle d'attaque spécifique. En outre, nous ingérons et promouvons des alertes externes provenant d'intégrations de sécurité telles que les pare-feu, EDR, WAF et autres contrôles de sécurité.
Il en résulte une grande visibilité, mais aussi un important volume d'alertes. D'après nos données télémétriques, même si l'on ne tient compte quedes règles qui ne sont pas des blocs de construction, 65 règles de détection uniques génèrent près de 8 000 alertes par jour et par cluster de production. L'analyse isolée de chaque alerte n'est ni extensible ni rentable.
C'est là que les règles d'ordre supérieur entrent en jeu.
Les règles d'ordre supérieur ne détectent pas un comportement unique. En revanche, ils mettent en corrélation les alertes connexes dans le temps, entre les sources de données ou dans un contexte partagé (hôte, utilisateur, IP ou processus, par exemple). En regroupant les signaux en modèles significatifs, nous pouvons donner la priorité à ce qui est vraiment important et réduire la nécessité d'une analyse approfondie et coûteuse de chaque alerte, qu'elle soit effectuée manuellement, automatisée ou augmentée par l'IA.
Dans ce blog, nous présenterons notre approche de la création de règles d'ordre supérieur dans Elastic, nous partagerons des exemples pratiques et nous mettrons en évidence les principales leçons apprises en cours de route.
Que sont les règles d'ordre supérieur ?
Les règles d'ordre supérieur (HOR) sont des détections qui utilisent les alertes comme données d'entrée, soit en corrélant les alertes avec d'autres alertes (alerte sur alerte), soit en combinant les alertes avec des données supplémentaires telles que des événements bruts, des mesures ou des données télémétriques contextuelles.
Contrairement aux règles atomiques qui détectent un comportement unique, les règles d'ordre supérieur identifient des modèles parmi les signaux. Leur objectif n'est pas de remplacer les détections de base, mais d'élever les combinaisons de résultats qui sont plus susceptibles de représenter une activité d'attaque réelle. Dans la pratique, ils font apparaître des résultats plus fiables et améliorent l'ordre de priorité du triage. Les règles d'ordre supérieur sont conçues pour fonctionner en parallèle avec les règles de construction. Les règles de construction génèrent des alertes qui n'apparaissent pas dans la vue des alertes par défaut, ce qui permet de réduire le bruit tout en continuant à alimenter les détections corrélées. La plupart des règles de base mentionnées dans cet article peuvent également être configurées comme des règles de base, de sorte que seules les corrélations d'ordre supérieur soient soumises à l'examen de l'analyste.
L'idée de base est que des détections indépendantes convergeant vers la même entité augmentent la confiance, chaque signal supplémentaire multipliant la probabilité que l'activité soit réelle et non anodine :
1. Corrélation basée sur les entités
Les règles mettent en corrélation l'activité par entités partagées telles que l'hôte, l'utilisateur, l'IP source, l'IP de destination ou le processus, ce qui permet aux analystes de voir rapidement si plusieurs résultats convergent vers le même actif ou la même identité.
2. Visibilité des sources de données croisées
Certaines règles fonctionnent dans le cadre d'une intégration unique (par exemple, les détections de points d'extrémité d'Elastic Defend ou d'un EDR tiers). D'autres combinent intentionnellement les signaux de plusieurs domaines : le point final avec le réseau (PANW, FortiGate, Suricata), le point final avec le courrier électronique ou le point final avec les mesures du système afin de capturer l'activité en plusieurs étapes ou sur plusieurs surfaces.
3. Temps et prévalence Sensibilisation
La logique temporelle joue un rôle clé.
Les règles nouvellement observées mettent en évidence la première occurrence d'une alerte donnée dans un délai défini (par exemple, cinq jours), ce qui permet de s'assurer que même une alerte rare fait surface pour être examinée.
La logique basée sur la prévalence (telle que l'utilisation de INLINE STATS) filtre les alertes qui ne se produisent que sur un petit nombre d'hôtes au niveau mondial, ce qui permet de réduire le bruit et de mettre l'accent sur les comportements anormaux.
L'ensemble des règles d'ordre supérieur couvre les corrélations entre points d'extrémité uniquement, les détections interdomaines (point d'extrémité + réseau, point d'extrémité + courrier électronique), les modèles de mouvement latéral (par exemple, alert_1 host.ip = alert_2 source.ip), les groupements alignés sur ATT&CK (activité tactique unique ou multiple), les alertes nouvellement observées et les corrélations entre alertes et événements (telles que les alertes combinées à des mesures anormales de l'unité centrale de traitement). Les sections suivantes présentent des exemples représentatifs de ces catégories.
Corrélation et règles d'ordre supérieur nouvellement observées
Dans la pratique, les activités à haut risque ne se présentent pas toujours de la même manière.
Parfois, le compromis se révèle à travers de multiples signaux convergents. D'autres fois, il s'agit d'une alerte unique qui n'a jamais été observée auparavant.
Pour faire face à ces deux réalités, nous organisons nos règles d'ordre supérieur en trois modèles complémentaires :
- Règles de corrélation plusieurs alertes ou événements liés à une entité partagée (hôte, utilisateur, IP ou processus).
- Règles nouvellement observées une alerte unique qui est rare ou observée pour la première fois dans une fenêtre temporelle définie.
- Des modèles hybrides combinant la corrélation et la logique de la première vue, qui peuvent renforcer les soupçons et mettre en évidence des activités particulièrement intéressantes.
Les règles de corrélation augmentent la confiance grâce à la densité et à la diversité des signaux : lorsque plusieurs détections indépendantes pointent vers la même entité, la probabilité d'une activité malveillante réelle augmente.
Les règles nouvellement observées concernent le cas inverse, à savoir un faible volume mais une grande nouveauté. Ils classent les alertes par ordre de priorité en fonction de leur rareté au fil du temps, ce qui permet de ne pas négliger les premières détections ou les détections très inhabituelles simplement parce qu'elles ne se produisent qu'une seule fois.
Ensemble, ces approches constituent la base d'une stratégie de triage efficace et évolutive.
Prenons des exemples et explorons les différences, les points forts et les compromis de chaque modèle.
Corrélation des alertes de points finaux
Une part importante des découvertes d'attaques dans le monde réel provient de la télémétrie des points d'extrémité. Il fournit un contexte riche en activités de processus, lignes de commande, comportement des fichiers et actions de l'utilisateur, ce qui en fait l'une des sources de détection les plus puissantes.
Dans le même temps, les environnements des points d'extrémité sont dynamiques. Les logiciels légitimes, les outils d'administration et les applications tierces (et récemment les utilitaires GenAI pour terminaux 🥲) peuvent générer un volume élevé d'alertes et de faux positifs, ce qui nécessite un réglage continu.
La corrélation d'ordre supérieur permet de résoudre ce problème en mettant l'accent non plus sur les alertes individuelles, mais sur plusieurs signaux distincts sur le même hôte ou processus, ce qui accroît la confiance tout en réduisant les efforts d'investigation inutiles.
La requête ES|QL suivante se déclenche lorsqu'il y a 3 règles de comportement Elastic Defend uniques OU des alertes provenant de différentes fonctionnalités (par exemple, un shellcode_thread avec comportement, un fichier malveillant avec comportement) OU plus de 2 alertes de logiciels malveillants dans une fenêtre de temps de 24 heures provenant du même hôte :
from logs-endpoint.alerts-* metadata _id
| eval day = DATE_TRUNC(24 hours, @timestamp)
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
| stats Esql.alerts_count = COUNT(*),
Esql.event_code_distinct_count = count_distinct(event.code),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, day
| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)Pour renforcer les soupçons, nous pouvons également corréler les alertes Elastic Defend qui appartiennent à la même arborescence de processus :
from logs-endpoint.alerts-*
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") and process.Ext.ancestry is not null
// aggregate alerts by process.Ext.ancestry and agent.id
| stats Esql.alerts_count = COUNT(*),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.event_code_distinct_count = COUNT_DISTINCT(event.code),
Esql.process_id_distinct_count = COUNT_DISTINCT(process.entity_id),
Esql.message_values = VALUES(message),
... by process.Ext.ancestry, agent.id
// filter for at least 3 unique process IDs and 2 or more alert types or rule names.
| where Esql.process_id_distinct_count >= 3 and (Esql.rule_name_distinct_count >= 2 or Esql.event_code_distinct_count >= 2)
// keep unique values
| stats Esql.alert_names = values(Esql.message_values),
Esql.alerts_process_cmdline_values = VALUES(Esql.process_command_line_values),
... by agent.id
| keep Esql.*, agent.idExemple de correspondance :
Pour compléter notre couverture, nous devrons également rechercher des atomes rares. L'ES|QL suivant est conçu pour s'exécuter sur un programme de 10 minutes avec une fenêtre de rétroaction de 5 ou 7 jours. Le lookback regroupe toutes les alertes par nom de règle sur l'ensemble de la fenêtre afin de calculer l'heure de première apparition. Le filtre final (Esql.recent <= 10) garantit que seules les règles dont l'heure de première observation se situe dans la fenêtre d'exécution actuelle de 10 minutes sont affichées, ce qui permet de détecter le moment où une règle se déclenche pour la première fois au cours de la période d'observation. Cela permet de mettre en évidence des faux positifs rares et des comportements furtifs qui pourraient autrement être perdus dans le volume :
from logs-endpoint.alerts-*
| WHERE event.code == "behavior" and rule.name is not null
| STATS Esql.alerts_count = count(*),
Esql.first_time_seen = MIN(@timestamp),
Esql.last_time_seen = MAX(@timestamp),
Esql.agents_distinct_count = COUNT_DISTINCT(agent.id),
Esql.process_executable = VALUES(process.executable),
Esql.process_parent_executable = VALUES(process.parent.executable),
Esql.process_command_line = VALUES(process.command_line),
Esql.process_hash_sha256 = VALUES(process.hash.sha256),
Esql.host_id_values = VALUES(host.id),
Esql.user_name = VALUES(user.name) by rule.name
// first time seen in the last 5 days - defined in the rule schedule Additional look-back time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
// first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)
// Move single values to their corresponding ECS fields for alerts exclusion
| eval host.id = mv_min(Esql.host_id_values)
| keep host.id, rule.name, Esql.*La même logique peut être appliquée à une alerte externe provenant d'un autre système de gestion des alertes (EDR) :
Corrélation entre le point final et les alertes réseau
Une méthode de détection efficace consiste à mettre en corrélation les alertes des points d'accès et les alertes du réseau. Cela permet de répondre à la question clé :
Quel processus a déclenché cette alerte réseau ?
Les alertes réseau seules manquent souvent de contexte de processus, comme l'utilisateur ou l'exécutable à l'origine de l'activité. En combinant les alertes réseau avec la télémétrie des points d'extrémité (données EDR), vous pouvez enrichir les alertes avec :
- Nom du processus et hachage
- Ligne de commande et processus parent
- Informations sur l'utilisateur et l'appareil
La requête suivante met en corrélation toute alerte Elastic Defend avec des événements suspects provenant de dispositifs de sécurité réseau tels que Palo Alto Networks (PANW) et Fortinet FortiGate. La clé de jonction est l'adresse IP : pour les alertes réseau, il s'agit de source.ip, pour les alertes sur les terminaux, il s'agit de host.ip. La requête les normalise en un seul champ à l'aide de COALESCE, ce qui permet d'établir une corrélation entre les sources de données qui utilisent des noms de champs différents pour la même entité. Cela peut indiquer que cet hôte est compromis et déclenche des alertes multi-sources.
FROM logs-* metadata _id
| WHERE
(event.module == "endpoint" and event.dataset == "endpoint.alerts") or
(event.dataset == "panw.panos" and event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", ...)) or
(event.dataset == "fortinet_fortigate.log" and (...)) or
(event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", ...))
| eval
fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
| where Esql.source_ip is not null
| stats Esql.alerts_count = COUNT(*),
Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
Esql.message_values_distinct_count = COUNT_DISTINCT(message),
... by Esql.source_ip
| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
| where concat_module_values like "*endpoint*"Exemple de correspondances entre les alertes Elastic Defend et Fortigate où la source.ip de l'alerte FortiGate est égale à l'hôte.ip de l'alerte Elastic Defend endpoint :
La requête EQL suivante met en corrélation les alertes de Suricata avec les événements réseau d'Elastic Defend afin de fournir un contexte sur le processus et l'hôte source :
sequence by source.port, source.ip, destination.ip with maxspan=5s
// Suricata severithy 3 corresponds to information alerts, which are excluded to reduce noise
[network where event.dataset == "suricata.eve" and event.kind == "alert" and event.severity != 3 and source.ip != null and destination.ip != null]
[network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")]Exemple de correspondances confirmant l'alerte Suricata et la reliant au processus du serveur web cible nginx à partir des événements Elastic Defend confirmant la tentative d'exploitation web :
Sécurité des points finaux avec Observability
La corrélation entre la télémétrie de l'observabilité et les alertes de sécurité est une stratégie de détection puissante.
L'incident de la porte dérobée XZ Utils a démontré que les anomalies relatives à la sécurité peuvent d'abord apparaître comme des régressions de performance plutôt que comme des alertes de sécurité traditionnelles. Dans ce cas, un comportement inhabituel du démon SSH a conduit à une investigation plus approfondie et à la découverte d'un code malveillant.
Cela met en évidence un principe important : les anomalies opérationnelles peuvent être des indicateurs précoces de compromission.
Avec l'agent Elastic, les mesures du système, telles que l'utilisation du processeur et de la mémoire, peuvent être collectées en même temps que la télémétrie de sécurité. En corrélant les pointes de ressources anormales avec les alertes SIEM par processus ou par hôte, nous pouvons augmenter la confiance dans la détection et détecter plus tôt les activités à haut risque.
Par exemple, une règle de corrélation ES|QL peut identifier un processus présentant une utilisation soutenue du processeur de 70% qui est également la source d'une alerte de signature de mémoire pour un cryptomineur d'Elastic Defend. Individuellement, chaque signal peut être de gravité faible ou moyenne. Mis en corrélation, ils représentent une activité malveillante très probable.
Nous avons développé plus de 30 détections d'ordre supérieur couvrant différents types de relations. Bien que nous ne puissions pas toutes les couvrir ici, les liens ci-dessous fournissent suffisamment de contexte pour adapter ces règles à votre environnement :
Alertes sur les points de terminaison :
Alertes multiples Elastic Defend par agent
Plusieurs alertes Elastic Defend à partir d'une seule arborescence de processus
Plusieurs règles de comportement Elastic Defend rares par hôte
Alerte de comportement Elastic Defend nouvellement observée
Plusieurs alertes EDR externes par hôte
Point final et réseau :
Alerte du réseau Palo Alto récemment observée
Alerte de Suricata de haute sévérité nouvellement observée
Trafic SOCKS FortiGate provenant d'un processus inhabituel
PANW et Elastic Defend - Corrélation de commande et de contrôle
Corrélation entre Elastic Defend et les alertes de sécurité réseau
Corrélation entre Suricata et Elastic Defend Network
Générique par MITRE ATT&CK :
Alertes dans différentes tactiques ATT&CK par hôte
Alertes multiples dans le même ATT&Tactique CK par hôte
Corrélation générique entre plusieurs intégrations :
Alertes provenant de plusieurs intégrations par adresse source
Alertes provenant d'intégrations multiples par adresse de destination
Alertes provenant de plusieurs intégrations par nom d'utilisateur
Alerte de détection de haute sévérité nouvellement observée
Corrélation des mouvements latéraux :
Mouvement latéral suspecté à partir d'un hôte compromis
Alertes de mouvements latéraux provenant d'une adresse source nouvellement observée
Alertes de mouvements latéraux provenant d'un utilisateur nouvellement observé
Observabilité et corrélation de la sécurité :
Alerte de détection sur un processus présentant un pic de CPU
Alertes multiples sur un hôte présentant un pic d'utilisation du processeur
Processus nouvellement observé présentant une utilisation élevée du processeur
Corrélation de l'apprentissage automatique :
Alertes multiples de Machine Learning par champ d'influence
Autres idées de corrélation :
Vulnérabilités multiples par actif via Wiz
Corrélation entre Elastic Defend et les alertes par courriel
Demande suspecte de ticket d'authentification Kerberos
Accès à plusieurs secrets du cloud par adresse source
Ces exemples illustrent comment la corrélation des alertes entre les terminaux, le réseau et l'observabilité peut enrichir le contexte, accélérer les enquêtes et améliorer la confiance dans la détection. Nous développons activement la couverture dans ce domaine afin de prendre en charge d'autres scénarios de corrélation.
Vous pouvez les activer en filtrant la valeur de la balise Rule Type : Règle d'ordre supérieur dans la page de gestion des règles :
Sur une période de 15 jours, le nombre d'alertes est resté dans les limites du volume acceptable (~30 alertes/jour). Un réglage ciblé des valeurs aberrantes initiales devrait les réduire à environ 20 alertes par jour et améliorer sensiblement la qualité globale du signal.
Considérations et compromis
Les règles d'ordre supérieur introduisent un risque de latence dans l'ordonnancement. Étant donné qu'ils interrogent les indices d'alerte, il existe un délai inhérent entre le moment où les alertes de base sont déclenchées et celui où les corrélations font surface. Les intervalles d'ordonnancement des règles et les fenêtres de bouclage doivent être réglés de manière à équilibrer la rapidité d'exécution et le coût des performances. En outre, la qualité du HOR dépend directement de la qualité des détections de base. Une règle atomique bruyante entraînera une cascade de faux positifs dans chaque corrélation qui y fait référence. Nous vous recommandons de régler les règles de base de manière agressive avant d'activer les règles d'ordre supérieur dépendantes. Enfin, les requêtes ESQL portant sur des schémas d'indexation larges (par exemple logs-*) peut s'avérer coûteux à grande échelle. Dans les environnements à fort volume, l'attribution de modèles d'index à des ensembles de données spécifiques ou l'utilisation de vues de données peuvent réduire de manière significative le coût des requêtes.
Conclusion
Les règles d'ordre élevé sont essentielles pour hiérarchiser le tri des alertes et gérer les volumes d'alertes pour l'automatisation et l'analyse pilotée par l'IA**.**. Combinées à l'évaluation des risques des entités, les règles d'ordre supérieur peuvent alimenter directement les profils de risque des hôtes et des utilisateurs, créant ainsi une couche de hiérarchisation quantitative qui réduit encore la charge de triage manuel. Dans nos tests de production, la majorité de ces détections ont produit un volume d'alerte moyen à faible, ce qui les rend pratiques pour une utilisation dans le monde réel. Bien qu'un petit nombre de règles bruyantes ou de faux positifs puissent initialement apparaître, leur exclusion au niveau de la règle atomique permet d'obtenir rapidement un ensemble solide de corrélations de grande valeur.
Pour maximiser leur efficacité, deux pratiques opérationnelles sont essentielles. Tout d'abord, veillez à ce que les alertes en entrée utilisent des niveaux de gravité qui reflètent avec précision à la fois le bruit et l'impact réel, le nettoyage et la normalisation de la gravité étant essentiels pour obtenir une corrélation significative. Deuxièmement, commencez petit et développez délibérément : n'essayez pas de corréler tous les signaux d'alerte possibles. Exclure les tactiques intrinsèquement bruyantes (telles que la découverte), donner la priorité aux signaux de faible gravité et supprimer les règles qui influencent de manière disproportionnée les résultats de la corrélation.
Appliquées correctement, les règles High-Order rationalisent les enquêtes, améliorent la précision de la détection et augmentent considérablement l'efficacité et la fiabilité des opérations de sécurité modernes.