Présentation des 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 avec 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 fournit une vue complète des menaces de sécurité en corrélant les données de différentes sources et étapes d'attaque.

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

• Règles composites : utilisent des détections ou des alertes (ou les deux) comme entrées. Vous pouvez également les enrichir avec des événements, des métriques et un large éventail de données contextuelles issues du graphique d'entités, telles que des données de prévalence, des renseignements 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 champs de métadonnées, à des variables match et à des variables outcome à partir 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 les 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, associer une détection de téléchargement de logiciel malveillant à une alerte de balisage C2 ultérieure provenant du même hôte).

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

• Réduisez la lassitude face 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éez 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émasquez les attaques en plusieurs phases : les cyberattaques sont souvent complexes et interconnectées. La détection composite révèle le récit d'attaque plus large en associant 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, comme 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 prioriser 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 des événements du modèle de données universel (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.

• Simplifier 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.

• Utilisation dans les tableaux de bord : intégrez facilement 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 liste quelques cas d'utilisation courants des détections composites.

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

Ce cas d'utilisation implique d'associer une alerte de haut niveau d'un système aux journaux d'événements d'un autre système.

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

• Exemple :

  1. Une alerte se déclenche 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 sur les points de terminaison (EDR) (les événements) de la même charge de travail dans un intervalle d'une minute, à la recherche d'opérations de ligne de commande contenant le même domaine malveillant.

  La dernière alerte fournit un contexte complet : elle indique qu'un domaine malveillant a été contacté et précise la commande ssh 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 axé sur l'association de l'événement de connexion d'un utilisateur à des activités suspectes ultérieures. Une règle multi-événement standard peut suivre une séquence courte, mais une détection composite est plus adaptée pour créer un profil de risque complet de l'ensemble de la session d'un utilisateur.

• Objectif : mettre en corrélation un événement unique, comme une connexion à haut risque, avec un large éventail d'activités ultérieures de "signal faible" sur une période plus longue, par exemple une journée complète.

• Exemple : Créez plusieurs règles qui produisent 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 alerte lors d'une connexion suspecte initiale et la mettre en corrélation avec l'une des détections suivantes du même utilisateur :

  • Un utilisateur efface l'historique de sa ligne de commande.

  • La création d'un compte administrateur local.

  • Importation d'un grand volume de données vers un site Cloud Storage personnel.

Combiner avec les métriques UEBA

Ce cas d'utilisation exploite les métriques UEBA existantes comme point de départ d'une détection composite afin de détecter des comportements plus complexes et à long terme.

• Objectif : corréler un pic d'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 sortants provenant du même utilisateur.

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

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

Cela implique de mettre en corrélation plusieurs actions utilisateur distinctes qui, lorsqu'elles sont combinées, peuvent indiquer une tentative d'exfiltration de données.

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

• Actions corrélées :

  • Vous vous connectez sur plusieurs appareils (par exemple, un ordinateur personnel et un ordinateur professionnel).

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

  • Télécharger, imprimer et envoyer des données par e-mail simultanément.

  • Compter le nombre de documents classifiés auxquels un utilisateur accède au cours d'une période donnée.

  • Ayant présenté une lettre de démission.

Détecter les logiciels malveillants multi-étagés

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

• Objectif : Associer le vecteur d'infection initial aux actions malveillantes ultérieures, même si elles se produisent plusieurs heures ou jours plus tard.

• Exemple :

  1. Un utilisateur accède à 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. Bien plus tard, le fichier dropper télécharge et exécute un autre fichier 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 nombre d'alertes

Ce cas d'utilisation implique la gestion des détections qui sont trop "bruyantes" ou qui produisent 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 optimisée bruyante sur "Détecter uniquement" pour qu'elle ne génère plus d'alertes.

  2. Créez une détection composite qui utilise le résultat de cette règle sélectionnée comme première condition.

  3. Ajoutez une deuxième condition pour fournir une qualification supplémentaire, par exemple "alerter 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 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 d'autres règles comme entrées. L'évaluation peut être basée sur les informations de la section "meta" de la règle d'origine, les variables de résultat et les variables de correspondance.

Sur la base de cette évaluation, vous pouvez utiliser des règles composites pour créer des détections qui serviront de 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 pour 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 et qu'elles 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, qui génèrent un grand nombre de faux positifs ou qui sont trop complexes et difficiles à gérer.

2. Déterminer les scénarios spécifiques dans lesquels les règles composites peuvent être utiles. Cela inclut la détection d'attaques en plusieurs étapes, la corrélation de plusieurs alertes à faible niveau de confiance en une seule alerte à niveau de confiance élevé, ou l'enrichissement des détections avec un contexte supplémentaire provenant d'autres sources de données.

3. Créez un plan de mise en œuvre en fonction de votre évaluation. Déterminez les règles bruyantes que vous devez affiner, les règles complexes que vous devez simplifier et les nouvelles détections multi-étapes que vous devez prioriser.

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

Sélectionnez la méthode appropriée.

Avant de créer une détection composite, si vous pouvez obtenir le résultat souhaité avec d'autres alternatives. Déterminez si vous pouvez identifier un schéma complexe avec une détection UEBA existante. Une détection trop complexe peut augmenter les frais 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 ou plusieurs règles préexistantes différentes. Cela permet de relier des étapes d'une attaque qui sont conceptuellement distinctes.

  Exemple : Corréler une détection d'une règle "Malware Downloaded" (Logiciel malveillant téléchargé) avec une détection ultérieure d'une règle "C2 Beaconing Detected" (Balise C2 détectée).

• Utilisez une détection UEBA existante lorsque vous souhaitez identifier quand un utilisateur ou un appareil s'écarte de 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 ne 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, découvrez l'impact des différents types de règles sur votre quota de règles.

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

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

Vous pouvez utiliser une détection optimisée en la définissant sur "Détection uniquement". Cela permet à la règle sélectionnée d'effectuer la détection générale initiale 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 permet d'obtenir plus de valeur tout en gérant votre quota de manière stratégique.

Comprendre la différence entre risque et contexte

Lorsque vous concevez une logique de détection, distinguez les règles qui évaluent les risques de celles qui fournissent du contexte.

Le risque est l'évaluation de la dangerosité d'un ensemble d'activités. Une règle conçue pour le risque regroupe souvent plusieurs événements ou détections contextuels pour émettre un jugement. Par exemple, si une seule tentative de connexion échouée fournit du contexte, un nombre élevé de tentatives 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 les détails 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 crucial indiquant que cette connexion provient d'un pays nouveau et inhabituel.

Exemple : une détection initiale peut vous alerter d'un risque potentiel, tel qu'un appel DNS vers un domaine malveillant. Une règle composite met ensuite en corrélation 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.

Utilisez les fenêtres de correspondance longues de manière stratégique

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

Utiliser les détections pour la visualisation

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

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

Exemple : Suivre le traitement des informations permettant d'identifier personnellement l'utilisateur

Une règle suit chaque fois qu'un utilisateur traite des informations sensibles permettant d'identifier personnellement l'utilisateur. Au lieu d'envoyer une alerte à chaque fois, elle est configurée pour 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 permet d'obtenir une vue d'audit rapide des comportements à risque sans générer d'alertes constantes.

Exemple : Surveiller des risques spécifiques de perte de données

Un widget regroupe les scores de risque d'un sous-ensemble très spécifique de règles de protection contre la perte de données. Cela permet à une équipe spécifique (par exemple, les administrateurs de la protection contre la perte de données) de ne surveiller que 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 pour créer 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éfinir le scénario de menace : définissez la menace spécifique que vous souhaitez détecter.

2. Créer ou identifier 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éfinir les conditions de jointure : déterminez l'information commune qui associe les détections de vos règles d'entrée, comme les libellés de règle, les variables ou les champs de détection.

4. Créer la règle composite : écrivez la règle qui ingère les détections des 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 libellé de métadonnées partagé.

   • Définissez la section match pour spécifier la clé de jointure et la période de correspondance.

   • Définissez la section condition pour définir la condition à remplir pour que l'alerte finale se déclenche.

5. Tester et déployer 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. Il 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. Lancez manuellement une rétrorecherche à 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 des résultats de détection antérieurs lors des tests, envisagez d'ajouter un meta: label unique à chaque règle de la chaîne composite.

Exemple : la règle suivante fournit un modèle de corrélation de règles de base :

rule Basic_Rule_Correlation_Template {
    
    meta:
    description = "Triggers when a user triggers two different rules within X days"

    events: 
    // 1. Identify the first sub-rule detection
    $d1.metadata.event_type = "DETECTION" $d1.metadata.rule_name = "INSERT_RULE_NAME_A_HERE" $user = [REDACTED_GENERIC_ID]

    // 2. Identify the second sub-rule detection
    $d2.metadata.event_type = "DETECTION"
    $d2.metadata.rule_name = "INSERT_RULE_NAME_B_HERE"
    $user = [REDACTED_GENERIC_ID]
    match: 
    // 3. Connect the rules by the same user over the specified window
    $user over 14d
    condition: 
    // 4. Fire when both conditions have occurred
    $d1 and $d2
}

Exemple : La règle suivante vérifie la détection optimisée avec une règle de détection d'événements et un graphique d'événements. Elle utilise des fonctions YARA-L avancées et des définitions de variables :

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 composite

Vous pouvez afficher les résultats des détections 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 avec un nombre à côté (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 pour la latence

Pour une latence minimale dans les pipelines de détection, utilisez des règles à événement unique chaque fois que 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 les détections

Nous vous recommandons d'utiliser des variables de résultat, des métatags et des variables de correspondance pour joindre les 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-étiquettes sont particulièrement flexibles, car elles vous permettent de classer les règles de sorte qu'une règle composite puisse cibler n'importe quelle détection associée à cette étiquette.

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

Conseil : Le nombre de variables de résultat étant 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 la non-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 version de la règle. Les règles composites utilisent automatiquement la nouvelle version. Nous vous recommandons de tester l'intégralité 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 période de correspondance maximale de 14 jours.

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

• Exclusions : n'appliquez pas d'exclusion de règle directement à une règle composite. Vous devez appliquer l'exclusion aux règles sous-jacentes fondamentales qui alimentent la règle composite. En effet, les exclusions de règles sont évaluées par rapport aux champs UDM (comme principal.user.userid), mais les règles composites se déclenchent en fonction d'autres détections plutôt que des champs UDM. Si vous appliquez une exclusion de règle directement à une règle composite, l'exclusion ne correspondra pas et l'événement ne sera pas exclu.

• 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 cas en fonction de l'état (par exemple, $edetection.feedback_summary.status != "CLOSED") n'est pas acceptée.

• 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 période 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 à un maximum de 20 variables de résultat. De plus, chaque variable de résultat répétée est limitée à 25 valeurs.

• Exemples d'événements : seuls 10 exemples 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.

Étapes suivantes

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 de membres de la communauté et de professionnels Google SecOps.