Détections composites

Compatible avec :

Google secops SIEM

Ce document présente les détections composites et explique comment elles peuvent améliorer les workflows de détection des menaces en corrélant les résultats de plusieurs règles.

Les détections composites sont générées par des règles qui utilisent les détections d'autres règles comme entrée, combinées à des événements, des métriques ou des signaux de risque d'entité. Ces règles sont ensuite combinées à des événements, des métriques ou des signaux de risque d'entité pour détecter les menaces complexes en plusieurs étapes que les règles individuelles peuvent manquer.

Les détections composites permettent d'analyser les événements via des interactions et des déclencheurs de règles définis. Cela améliore la précision, réduit les faux positifs et offre une vue complète des menaces de sécurité en corrélant les données provenant de différentes sources et étapes d'attaque.

Les concepts suivants définissent les blocs de construction des règles composites et expliquent leur fonctionnement dans les workflows de détection :

• Règles composites : utilisent des détections ou des alertes (ou les deux) comme entrée. Vous pouvez également les enrichir avec des événements, des métriques et un large éventail de données contextuelles provenant du graphique d'entités, telles que des données de prévalence, du renseignement sur les menaces ou un score de risque d'entité. Ces règles doivent toujours comporter une section de correspondance et peuvent faire référence à des méta-champs, des variables match et des variables outcome provenant de règles d'entrée.

• Détection : résultat généré lorsque les conditions d'une règle sont remplies.

• Règles de détection uniquement : règles composites qui n'utilisent que des détections ou des alertes comme entrées.

Quand utiliser des détections composites ?

Les détections composites peuvent être utiles pour atteindre les objectifs suivants :

• Corréler les résultats de deux règles ou plus (par exemple, lier une détection de téléchargement de logiciels malveillants à une alerte de balise C2 ultérieure provenant du même hôte).

• Enrichir les alertes avec des données d'événement associées.

• Réduire la fatigue liée aux alertes en ne déclenchant une alerte finale que lorsqu'une détection bruyante et peu fiable se produit plusieurs fois ou en combinaison avec d'autres activités suspectes.

• Créer une alerte pour une attaque complexe en plusieurs étapes, où chaque étape est déjà identifiée par sa propre règle.

Avantages des détections composites

Les détections composites présentent les avantages suivants :

• Démasquer les attaques en plusieurs étapes : les cyberattaques sont souvent multiformes et interconnectées. La détection composite révèle le récit plus large de l'attaque en liant des événements de sécurité apparemment isolés. Par exemple, les détections composites peuvent identifier la séquence complète d'une attaque, telle qu'une violation initiale suivie d'une élévation des privilèges et d'une exfiltration de données.

• Réduire la fatigue liée aux alertes : les règles composites consolident et filtrent les alertes bruyantes, ce qui permet une réponse plus ciblée. Cette approche permet de hiérarchiser les incidents à fort impact et de réduire la fatigue globale liée aux alertes.

• Améliorer la précision de la détection : combinez les insights provenant des événements du modèle de données unifié (UDM), des détections de règles, du contexte d'entité, des résultats de l'analyse du comportement des utilisateurs et des entités (UEBA) et des tables de données pour créer une logique de détection plus précise.

• Rationaliser la logique complexe : décomposez les scénarios de détection complexes en règles gérables, interconnectées et réutilisables pour simplifier le développement et la maintenance.

• Utiliser dans les tableaux de bord : intégrez de manière transparente les détections composites en tant que sources de données pour les tableaux de bord Google SecOps. Vous pouvez les utiliser pour créer des visualisations qui résument les schémas d'attaque en plusieurs étapes, ce qui facilite la compréhension des risques complexes.

Cas d'utilisation courants

Cette section répertorie quelques cas d'utilisation courants des détections composites.

Enrichir les détections avec le contexte des événements bruts

Ce cas d'utilisation consiste à lier une alerte de haut niveau d'un système à des journaux d'événements d'un autre système.

• Objectif : identifier l'action locale spécifique qui a provoqué une alerte de haut niveau.

• Exemple :

  1. Une alerte est déclenchée dans Google Cloud Event Threat Detection, car une charge de travail a effectué un appel DNS vers un domaine malveillant. Il s'agit de la détection.

  2. Une règle composite est déclenchée par cette détection.

  3. La règle recherche ensuite les journaux bruts de détection et de réponse des points de terminaison (EDR) (les événements) de la même charge de travail dans une fenêtre d'une minute, à la recherche d'opérations de ligne de commande contenant le même domaine malveillant.

  L'alerte finale fournit un contexte riche : elle indique qu'un domaine malveillant a été contacté et la commande ssh spécifique utilisée. Ces informations rendent le résultat beaucoup plus exploitable que la détection d'origine.

Suivre l'activité des utilisateurs après la connexion

Un cas d'utilisation principal consiste à lier l'événement de connexion d'un utilisateur à des activités suspectes ultérieures. Bien qu'une règle standard multi-événements puisse suivre une courte séquence, une détection composite est plus adaptée à la création d'un profil de risque complet pour l'ensemble de la session d'un utilisateur.

• Objectif : corréler un seul événement, tel qu'une connexion à haut risque, avec un large éventail d'activités ultérieures à "signal faible" sur une période plus longue, par exemple une journée complète.

• Exemple : créez plusieurs règles qui génèrent des détections de niveau inférieur. Ensuite, utilisez une règle composite avec une longue fenêtre de correspondance (par exemple, 24 heures) pour déclencher une connexion suspecte initiale et la corréler avec l'une des détections suivantes du même utilisateur :

  • Un utilisateur efface son historique de ligne de commande.

  • Création d'un compte administrateur local.

  • Importation de données volumineuses vers un site Cloud Storage personnel.

Combiner avec des métriques UEBA

Ce cas d'utilisation exploite les métriques UEBA existantes comme point de départ d'une détection composite pour trouver un comportement plus complexe et à long terme.

• Objectif : corréler un pic dans une métrique UEBA avec une autre activité anormale.

• Exemple :

  1. Une règle UEBA détecte un nombre excessif d'échecs de connexion pour un utilisateur.

  2. Une autre règle UEBA détecte un grand nombre d'octets de sortie provenant du même utilisateur.

  3. Une détection composite lie ces deux résultats UEBA distincts sur une période de plusieurs jours pour identifier une éventuelle compromission de compte suivie d'un vol de données.

Détecter les tentatives d'exfiltration de données

Cela implique de corréler plusieurs actions distinctes de l'utilisateur qui, combinées, peuvent indiquer une tentative d'exfiltration de données.

• Objectif : créer un profil de gestion des données à risque par un seul utilisateur sur plusieurs appareils et actions.

• Actions corrélées :

  • Connexion depuis plusieurs appareils (par exemple, ordinateur personnel et ordinateur professionnel).

  • Accès à plus de sources de données que d'habitude.

  • Téléchargement, impression et envoi de données par e-mail simultanément.

  • Comptabilisation du nombre de documents classifiés qu'un utilisateur touche dans un délai donné.

  • Envoi d'une lettre de démission.

Détecter les logiciels malveillants en plusieurs étapes

Ce cas d'utilisation consiste à identifier les logiciels malveillants qui fonctionnent lentement sur une longue période, ce qui est difficile à détecter avec des règles uniques qui ont des fenêtres de correspondance courtes.

• Objectif : lier le vecteur d'infection initial aux actions malveillantes ultérieures, même si elles sont espacées de plusieurs heures ou jours.

• Exemple :

  1. Un utilisateur consulte un site Web malveillant (événement réseau initial).

  2. Un "fichier dropper" est téléchargé et exécuté (premier événement de processus).

  3. Beaucoup plus tard, le fichier dropper télécharge et exécute un autre exécutable (deuxième événement de processus).

  Cela nécessite une longue fenêtre match pour connecter les processus parent et enfant, ce que les détections composites peuvent fournir.

Réduire le bruit des alertes

Ce cas d'utilisation consiste à gérer les détections trop "bruyantes" ou qui génèrent trop de faux positifs par elles-mêmes.

• Objectif : affiner une règle bruyante sans la désactiver ni créer d'exclusions complexes.

• Exemple :

  1. Définissez une détection organisée bruyante sur "Détecter uniquement" afin qu'elle ne génère plus d'alertes.

  2. Créez une détection composite qui utilise la sortie de cette règle organisée comme première condition.

  3. Ajoutez une deuxième condition pour fournir une qualification supplémentaire, par exemple "alerte uniquement si cette détection se produit cinq fois pour le même utilisateur en une heure" ou si elle est combinée à une détection provenant d'une autre règle.

Fonctionnement des détections composites

Lorsque les règles remplissent des conditions prédéfinies, elles génèrent des détections. Ces détections peuvent éventuellement inclure des variables de résultat, qui capturent des données ou des états d'événement spécifiques.

Les règles composites utilisent ces détections provenant d'autres règles dans leurs entrées. L'évaluation peut être basée sur les informations de la section méta de la règle d'origine, les variables de résultat et les variables de correspondance.

En fonction de cette évaluation, vous pouvez utiliser des règles composites pour créer de nouvelles détections à utiliser comme représentation intermédiaire pour l'investigation et l'alerte avec une règle ultérieure. Cela permet de corréler plusieurs facteurs provenant de différentes détections afin d'identifier les menaces complexes.

Pour en savoir plus sur la syntaxe et les exemples, consultez Règles de détection composites et Exemples.

Définir votre stratégie

Avant de commencer à créer des règles composites, planifiez votre stratégie pour vous assurer que vos nouvelles règles sont efficaces, efficientes et résolvent les bons problèmes.

1. Évaluez votre stratégie de détection actuelle. Examinez vos règles existantes pour identifier celles qui sont trop bruyantes, génèrent un nombre élevé de faux positifs ou sont trop complexes et difficiles à gérer.

2. Déterminez les scénarios spécifiques dans lesquels les règles composites peuvent apporter de la valeur. Cela inclut la détection d'attaques en plusieurs étapes, la corrélation de plusieurs alertes peu fiables en une seule alerte très fiable ou l'enrichissement des détections avec un contexte supplémentaire provenant d'autres sources de données.

3. En fonction de votre évaluation, créez un plan d'implémentation. Décidez des règles bruyantes que vous devez affiner, des règles complexes que vous devez simplifier et des nouvelles détections en plusieurs étapes que vous devez hiérarchiser.

Ce plan défini fournit une feuille de route pour la création de règles composites ciblées et efficaces. Tenez compte des stratégies générales suivantes pour tirer le meilleur parti des détections composites tout en gérant les contraintes techniques.

Sélectionner la méthode appropriée

Avant de créer une détection composite, vérifiez si vous pouvez obtenir le résultat requis avec d'autres alternatives. Analysez si vous pouvez identifier un schéma complexe avec une détection UEBA existante. Une détection trop complexe peut augmenter les frais généraux de maintenance et consommer le quota de règles.

• Utilisez une détection composite lorsque votre objectif est de corréler les résultats finaux de deux règles différentes ou plus, préexistantes. Cela connecte des étapes d'une attaque conceptuellement distinctes.

  Exemple : corréler une détection d'une règle de téléchargement de logiciels malveillants avec une détection ultérieure d'une règle de détection de balise C2.

• Utilisez une détection UEBA existante lorsque vous souhaitez savoir quand un utilisateur ou un appareil enfreint son schéma d'activité normal.

  Exemple : détecter automatiquement qu'un utilisateur a téléchargé 100 Go de données aujourd'hui alors qu'il n'en télécharge normalement que 1 Go.

Gérer les quotas de règles et les scores de risque

Pour gérer les ressources de votre organisation, comprenez l'impact des différents types de règles sur votre quota de règles.

• Les règles organisées ne sont pas comptabilisées dans votre quota de règles personnalisées.

• Les règles composites et les règles personnalisées multi-événements sont comptabilisées dans votre quota.

Vous pouvez utiliser une détection organisée en la définissant sur "Détecter uniquement". Cela permet à la règle organisée d'effectuer la détection initiale large sans générer d'alertes. Vous pouvez ensuite utiliser une règle composite pour appliquer une logique spécifique à ces résultats, ce qui vous apporte plus de valeur tout en gérant stratégiquement votre quota.

Comprendre la différence entre risque et contexte

Lorsque vous concevez une logique de détection, faites la distinction entre les règles qui évaluent le risque et celles qui fournissent un contexte.

Le risque est l'évaluation du niveau de dangerosité d'un ensemble d'activités. Une règle conçue pour le risque agrège souvent plusieurs événements ou détections contextuels pour prendre une décision. Par exemple, alors qu'un seul échec de connexion fournit un contexte, un nombre élevé d'échecs indique un risque d'attaque par force brute.

Le contexte fait référence aux détails factuels entourant un événement. Une règle conçue pour le contexte enrichit un événement avec des détails provenant d'un autre. Par exemple, alors qu'une règle peut détecter une connexion utilisateur réussie, une règle contextuelle fournit le contexte essentiel selon lequel cette connexion provient d'un pays nouveau et inhabituel.

Exemple : une détection initiale peut vous alerter sur un risque potentiel, tel qu'un appel DNS vers un domaine malveillant. Une règle composite corrèle ensuite cette alerte avec les journaux d'événements dans Google SecOps pour trouver le processus de ligne de commande spécifique qui a initié l'appel. Cela enrichit l'alerte de risque de haut niveau avec un contexte critique et exploitable.

Utiliser des fenêtres de correspondance longues de manière stratégique

Les règles composites configurées avec des fenêtres de correspondance longues (par exemple, 14 jours) sont exécutées moins fréquemment. Leur latence élevée peut les rendre inadaptées aux alertes urgentes. Envisagez d'utiliser ces fenêtres de longue durée pour détecter les activités malveillantes lentes et persistantes sur des périodes prolongées.

Utiliser des détections pour la visualisation

Une stratégie de gestion des règles bruyantes consiste à transformer leur sortie en visualisation sur un tableau de bord. Cette approche ne consomme pas de quota de règles et peut transformer des données à faible fidélité et à volume élevé en insights précieux.

En définissant une règle sur "Détecter uniquement", puis en traçant ses détections dans un widget de tableau de bord, vous pouvez suivre les tendances, identifier les valeurs aberrantes et obtenir une vue d'audit de haut niveau de l'activité sans être submergé par des alertes individuelles.

Exemple : Suivre la gestion des données PII

Une règle suit chaque fois qu'un utilisateur gère des données PII sensibles. Au lieu d'alerter à chaque fois, elle est définie sur "Détecter uniquement". Un widget de tableau de bord indique ensuite quels utilisateurs approchent d'une limite de sortie quotidienne (par exemple, 10,000 octets). Cela fournit une vue d'audit rapide des comportements à risque sans générer d'alertes constantes.

Exemple : Surveiller les risques DLP spécifiques :

Un widget agrège les scores de risque d'un sous-ensemble très spécifique de règles DLP. Cela permet à une équipe spécifique (par exemple, les administrateurs de la protection contre la perte de données (DLP)) de surveiller uniquement les risques pertinents, en filtrant le bruit provenant d'autres domaines de sécurité.

Créer des détections composites

Le workflow suivant décrit le parcours type de création d'une règle composite. Pour en savoir plus sur la syntaxe et les exemples, consultez Règles de détection composites et Exemples.

1. Définissez le scénario de menace : définissez la menace spécifique que vous souhaitez détecter.

2. Créez ou identifiez les règles d'entrée : pour chaque étape du scénario de menace, créez ou identifiez une règle d'entrée qui détecte l'activité spécifique.

3. Définissez les conditions de jointure : déterminez l'élément d'information commun qui lie les détections de vos règles d'entrée, telles que les libellés de règles, les variables ou les champs de détection.

4. Créez la règle composite : écrivez la règle qui ingère les détections de règles d’entrée.

   • Définissez la section events, en référençant les règles d'entrée par leur nom, leur ID ou un méta-libellé partagé.

   • Définissez la section match pour spécifier la clé de jointure et la fenêtre temporelle de la correspondance.

   • Définissez la section condition pour définir la condition à remplir pour que l'alerte finale soit déclenchée.

5. Testez et déployez la chaîne de règles : nous vous recommandons d'exécuter manuellement une recherche rétroactive pour chaque règle de la séquence.

   Lorsque vous utilisez la fonctionnalité Tester la règle sur une règle composite, elle ne s'exécute que sur les détections préexistantes qui correspondent aux critères d'entrée de la règle. Elle n'exécute pas automatiquement les règles sous-jacentes pour générer de nouvelles entrées pour le test, ce qui signifie que vous ne pouvez pas valider une chaîne de règles entière en une seule action.

   Pour exécuter une recherche rétroactive pour la séquence de règles, procédez comme suit :

   1. Démarrez manuellement une recherche rétroactive à partir de la première règle de la séquence.

   2. Attendez la fin de l'opération.

   3. Passez à la règle suivante.

   Conseil : Pour éviter de faire correspondre accidentellement les résultats de détection précédents lors des tests, envisagez d’ajouter un meta: label unique à chaque règle de la chaîne composite.

Exemple :

rule CheckCuratedDetection_with_EDR_and_EG {

  meta:
    author = "[e-mail]"

  events:

    $d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
    $d.detection.collection_elements.references.event.network.dns.questions.name = $domain
    $d.detection.collection_elements.references.event.principal.asset.hostname = $hostname

    $e.metadata.log_type = "LIMACHARLIE_EDR"
    $e.metadata.product_event_type = "NETWORK_CONNECTIONS"
    $domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
    $hostname = re.capture($e.principal.hostname, "([^.]*)")

    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 5
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0

  match:
    $hostname over 1h

  outcome:
    $risk_score = 80
    $CL_target = array($domain)

  condition:
    $e and $d and $prevalence

}

Afficher les résultats de détection composites

Vous pouvez afficher les résultats de détection composites sur la page Détections. Une alerte est une détection composite lorsque la colonne Entrées affiche Détection comme source et que la colonne Type de détection affiche un libellé Alerte suivi d'un chiffre (par exemple, Alert (3)).

Remarque : Si vous disposez à la fois de SIEM et de SOAR, vous pouvez également afficher les résultats dans l'onglet Demandes.

Optimiser les détections composites

Nous vous recommandons de suivre les pratiques suivantes pour créer des règles composites.

Optimiser la latence

Pour une latence minimale dans les pipelines de détection, utilisez des règles à événement unique chaque fois que cela est possible, par exemple pour le déclencheur initial. Les règles composites peuvent utiliser leurs détections pour effectuer des corrélations plus complexes avec d'autres événements, entités ou détections, ce qui permet de réduire la latence globale.

Utiliser des méthodes efficaces pour joindre des détections

Nous vous recommandons d'utiliser des variables de résultat, des méta-libellés et des variables de correspondance pour joindre des détections. Ces méthodes fournissent des résultats plus déterministes et fiables que l'utilisation d'échantillons d'événements. Les méta-libellés sont particulièrement flexibles, car ils vous permettent de catégoriser les règles afin qu'une règle composite puisse cibler n'importe quelle détection avec ce libellé.

Par exemple, si plusieurs règles partagent le même méta-libellé tactic: exfiltration, vous pouvez avoir une règle composite qui cible n'importe quelle détection où le libellé de tactique a la valeur exfiltration.

Conseil : Étant donné que le nombre de variables de résultat est limité à 20, nous vous recommandons d'établir une taxonomie commune de variables de résultat (telles que hostname, ip_address, user, et file_bytes) à réutiliser de manière cohérente dans un large éventail de règles. Pour en savoir plus, consultez la section Limites.

Lorsque vous utilisez nocase avec des variables de jointure dans des détections composites, vous pouvez recevoir l'erreur d'analyse sémantique suivante :

semantic analysis: match variable <variable_name> is not assigned to an event field.

Dans les détections composites, la première attribution de variable (par exemple, $username = $fact1...) définit les propriétés de la variable, y compris l'absence de sensibilité à la casse lors de l'utilisation de nocase. L'application de nocase aux attributions de variables ultérieures de la même variable de jointure (par exemple, $username = $fact2...) est interprétée par le compilateur comme une redéfinition conflictuelle ou une contrainte redondante, ce qui entraîne l'erreur sémantique.

Améliorer les détections avec la bibliothèque de fonctions

Vous pouvez utiliser la bibliothèque de fonctions YARA-L à des points stratégiques d'une règle composite pour augmenter le signal et ajouter une logique plus complexe.

Gérer les mises à jour des règles

Lorsque vous mettez à jour une règle utilisée dans une ou plusieurs règles composites, le système crée automatiquement une nouvelle version de la règle. Les règles composites utilisent automatiquement la nouvelle version. Nous vous recommandons de tester l'ensemble de la séquence de règles mise à jour pour vérifier le comportement prévu.

Limites

**Remarque** : Toutes les règles de détection ont une fenêtre de correspondance maximale de 14 jours.

Lorsque vous concevez et implémentez des détections composites, tenez compte des limites suivantes :

• Disponibilité des données de demande SOAR : les détections composites n'ont pas accès à toutes les données de demande SOAR. La logique de règle qui tente de filtrer ou d'exclure des demandes en fonction de leur état (par exemple, $edetection.feedback_summary.status != "CLOSED") n'est pas compatible.

• Règles composites : Google SecOps accepte une profondeur maximale de 10 pour les règles composites. La profondeur correspond au nombre de règles entre une règle de base et la règle composite finale.

• Règles de détection uniquement : ont une fenêtre de correspondance maximale de 14 jours et sont soumises à une limite de détection quotidienne de 10 000 détections par règle.

• Variables de résultat : chaque règle est limitée à 20 variables de résultat maximum. De plus, chaque variable de résultat répétée est limitée à 25 valeurs.

• Échantillons d'événements : seuls 10 échantillons d'événements sont stockés par variable d'événement dans une règle, par exemple 10 pour $e1 et 10 pour $e2.

Pour en savoir plus sur les limites de détection, consultez Limites de détection.

Étape suivante

Pour savoir comment créer des règles de détection composites, consultez Règles de détection composites et Exemples.

Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.