Intégrer vos propres flux de renseignements sur les menaces

Compatible avec :

Ce guide s'adresse aux ingénieurs en sécurité et en détection qui souhaitent intégrer des indicateurs de compromission (IoC) personnalisés et des flux de renseignements sur les menaces tiers à Google Security Operations. Il explique comment ingérer des flux de menaces, normaliser les indicateurs dans le graphique ECG (Entity Context Graph) du modèle de données unifié (UDM) et corréler les entités d'indicateur avec la télémétrie des événements en flux continu. En suivant cette méthode, vous automatisez la détection des menaces dans votre environnement et éliminez les recherches manuelles d'indicateurs. Une intégration réussie réduit les temps de tri des alertes et renforce la posture de sécurité de votre organisation grâce à la détection des menaces en temps réel et rétroactive.

L'intégration de flux de renseignements sur les menaces personnalisés permet à votre équipe chargée des opérations de sécurité de combiner des flux d'indicateurs externes (tels que la plate-forme de partage d'informations sur les logiciels malveillants (MISP), STIX/TAXII ou les flux commerciaux) avec votre télémétrie de sécurité interne. Une fois normalisées dans l'ECG, les entités de menace sont compatibles avec la mise en correspondance automatique des indicateurs et les règles de corrélation YARA-L 2.0 multi-événements personnalisées.

Terminologie clé

  • Graphique de contexte des entités (ECG, Entity Context Graph) : couche de stockage contextuel dans Google SecOps qui conserve les enregistrements d'entités avec état (tels que les ressources, les utilisateurs et les indicateurs de menace) pour la corrélation avec les journaux d'événements de sécurité.
  • Modèle de données unifié (UDM) : schéma standardisé que Google SecOps utilise pour normaliser les journaux d'événements bruts et les données d'entités contextuelles.
  • Intervalle du cycle de vie de l'indicateur (metadata.interval) : fenêtre de validité limitée dans le temps (start_time et end_time) qui définit le moment où un indicateur de menace est actif dans l'ECG.
  • Correspondance automatique des IoC : résultat généré par le système lorsqu'un événement de sécurité entrant correspond à une entité d'indicateur active dans l'ECG. Il s'affiche sur la page Correspondances des IoC.
  • Recherche rétroactive YARA-L : recherche historique à la demande qui exécute une règle de détection YARA-L 2.0 sur les données de télémétrie de sécurité des 30 derniers jours maximum.

Cas d'utilisation courants

Les cas d'utilisation suivants montrent comment l'utilisation de votre propre renseignement sur les menaces répond aux objectifs courants des opérations de sécurité.

Correspondance automatisée des indicateurs en temps réel

  • Objectif : évaluer automatiquement les événements de sécurité en streaming par rapport aux indicateurs tiers ingérés sans avoir à gérer de règles de corrélation personnalisées.
  • Valeur : élimine la maintenance manuelle des règles pour les flux de menaces à volume élevé et affiche les correspondances immédiates sur la page Correspondances IoC.

Règles de corrélation YARA-L personnalisées et rétrochasse

  • Objectif : joindre des entités de renseignements sur les menaces dans l'ECG avec la télémétrie multi-événements et analyser jusqu'à 30 jours de données historiques à l'aide de la recherche rétroactive.
  • Valeur : détecte les attaques en plusieurs étapes et révèle les compromissions historiques qui se sont produites avant l'ajout d'un indicateur à vos flux de menaces.

Avant de commencer

Avant de commencer, vérifiez que les conditions préalables suivantes sont remplies :

  • Autorisations : vous devez disposer des autorisations Identity and Access Management pour gérer les flux de données et créer des règles de détection dans Google SecOps (par exemple, Chronicle API Admin ou Chronicle API Editor). Pour en savoir plus sur les rôles requis, consultez Configurer l'accès aux fonctionnalités.
  • Vérification de l'environnement : vérifiez que vous disposez d'une instance Google SecOps active et d'identifiants API ou d'URL de point de terminaison valides pour votre fournisseur externe de renseignements sur les menaces (par exemple, MISP, STIX/TAXII ou les buckets Cloud Storage).
  • Fonctionnalités de recherche et de règles : la recherche UDM vous permet d'inspecter les enregistrements d'entités brutes stockés dans l'ECG, quelle que soit leur fenêtre active. En revanche, les règles de détection YARA-L et la mise en correspondance automatique n'évaluent que les indicateurs dont le metadata.interval englobe le code temporel de l'événement.
  • Préfixes des tableaux de bord et des champs de recherche : lorsque vous interrogez des entités de renseignement sur les menaces dans la recherche UDM, les tableaux de bord ou les règles YARA-L, utilisez le préfixe graph.entity. pour les valeurs d'indicateur (comme graph.entity.ip) et le préfixe graph.metadata.threat. pour les champs d'attribution des menaces.

Ingérer des indicateurs de renseignements sur les menaces

Sélectionnez et configurez un mécanisme d'ingestion pour importer des flux d'indicateurs externes dans Google SecOps.

Sélectionner un mécanisme d'ingestion de flux

Vous pouvez ingérer des flux de renseignements sur les menaces à l'aide de l'un des mécanismes compatibles suivants :

  • Analyseurs par défaut prédéfinis : Google SecOps inclut des analyseurs par défaut pour de nombreuses plates-formes de renseignements sur les menaces. Pour obtenir la liste des analyseurs compatibles classés sous IOC, consultez Types de journaux et analyseurs par défaut compatibles. Les fournisseurs compatibles incluent MISP, ThreatConnect, Intel471 et Cyjax.
  • API Feed Management : configurez des flux dans la console Google SecOps ou à l'aide de l'API Feed Management pour extraire régulièrement des indicateurs à partir de points de terminaison HTTPS, Cloud Storage ou Amazon S3 externes.
  • API Ingestion : envoyez des charges utiles d'entités préstructurées directement à Google SecOps à l'aide de l'API Ingestion.
  • Agent Bindplane : collectez et transférez les journaux d'indicateurs à partir d'environnements sur site ou cloud à l'aide de l'agent Bindplane.
  • Fonctions Cloud Run : déployez des scripts d'ingestion sans serveur à l'aide des fonctions Cloud Run pour extraire les indicateurs à partir d'API externes (telles que STIX/TAXII ou MISP) et les diffuser dans Google SecOps. Pour en savoir plus, consultez Utiliser des scripts d'ingestion déployés en tant que fonctions Cloud Run.
  • Intégrations de réponse Google SecOps : ingérez des indicateurs via les connecteurs du Hub de contenu pour synchroniser les listes de menaces dans le cadre de playbooks automatisés. Pour en savoir plus, consultez Utiliser le Hub de contenu.

Intégrer des flux de renseignements sur les menaces

Pour ingérer les journaux d'indicateurs de votre fournisseur de renseignements sur les menaces dans Google SecOps :

  1. Suivez la procédure d'intégration pour le format ou le fournisseur de flux de menaces spécifique :

  2. Attribuez le type de journal IoC correspondant (STIX, MISP_IOC, CSV_CUSTOM_IOC ou THREATCONNECT_IOC, par exemple) aux données du flux entrant afin que l'analyseur par défaut extraie les attributs d'indicateur dans les champs d'entité UDM.

  3. Ouvrez le tableau de bord Ingestion de données et vérifiez que les entrées de journaux entrantes s'affichent sans erreurs de journaux non analysés.

Remplir et valider le graphique du contexte des entités

Lorsque des indicateurs de menace sont intégrés à Google SecOps, le pipeline d'analyse les normalise en enregistrements d'entité UDM et remplit l'ECG. Pour en savoir plus sur le fonctionnement de l'enrichissement des entités, consultez Comment Google SecOps enrichit les données d'événements et d'entités.

Mappage des données structurées et non structurées

Selon la façon dont vous envoyez les données de renseignements sur les menaces à Google SecOps, suivez le workflow de mappage des champs approprié :

  • Ingestion de données structurées : lorsque vous envoyez des enregistrements d'entités UDM préstructurés directement à l'aide de l'API Ingestion, mettez en forme chaque charge utile selon le schéma Entity de l'UDM avant l'ingestion.
  • Ingestion de données non structurées et semi-structurées : lorsque vous envoyez des journaux bruts (tels que CSV, JSON, STIX ou CEF) à l'aide de flux, de l'agent Bindplane ou de redirecteurs, attribuez un analyseur par défaut prédéfini ou créez des mappages de champs personnalisés à l'aide des extensions d'analyseur pour extraire les valeurs des indicateurs et les mapper aux champs d'entité UDM requis.

Qu'est-ce qui fait d'une entité un IoC ?

Pour qu'un enregistrement d'entité dans l'ECG soit reconnu comme un IoC exploitable par des règles de détection et de correspondance automatiques, l'analyseur ou la charge utile de l'API doivent remplir les cinq groupes de champs UDM suivants :

  • Type d'entité (metadata.entity_type) : type d'entité indicateur compatible, tel que DOMAIN_NAME, IP_ADDRESS, FILE ou URL.
  • Type de source (metadata.source_type) : classification de la source de données, qui doit être définie sur ENTITY_CONTEXT pour les flux de renseignements sur les menaces ingérés par le client.
  • Identifiant de l'artefact (entity.*) : valeur de l'indicateur lui-même, par exemple graph.entity.ip, graph.entity.hostname, graph.entity.domain.name, graph.entity.file.sha256 (ou md5 et sha1) ou graph.entity.url.
  • Métadonnées sur les menaces (metadata.threat) : attributs contextuels décrivant la menace, y compris threat_feed_name, threat_name, category, severity et confidence.

  • Intervalle de cycle de vie (metadata.interval) :

    • metadata.interval.start_time : code temporel indiquant le moment où l'indicateur devient actif.
    • metadata.interval.end_time : code temporel d'expiration de l'indicateur.

Pour les définitions de schéma, consultez la liste des champs UDM pour Entity et EntityMetadata.

Les indicateurs deviennent généralement consultables dans la recherche UDM deux à cinq minutes après leur ingestion et leur analyse. Vérifiez que vos indicateurs remplissent l'ECG en exécutant une recherche UDM :

  1. Dans le menu de navigation Google SecOps, sélectionnez Investigation > Rechercher.

  2. Dans le champ de recherche, saisissez une requête ciblant le graphique d'entités pour une valeur d'indicateur ingérée :

    • Adresse IP :

      graph.entity.ip = "<var>IP_ADDRESS</var>"

    • Domaine :

      graph.entity.hostname = "<var>DOMAIN_NAME</var>"

    • Hachage du fichier (SHA-256) :

      graph.entity.file.sha256 = "<var>SHA256_HASH</var>"

    • Produit source :

      graph.metadata.source_product = "<var>SOURCE_PRODUCT_NAME</var>"

  3. Cliquez sur Rechercher ou appuyez sur Entrée.

  4. Cliquez sur la fiche d'entité renvoyée et vérifiez que les champs threat et interval contiennent les métadonnées et les codes temporels actifs attendus.

Corréler la télémétrie et détecter les menaces

Une fois vos indicateurs de menace renseignés dans le graphique ECG, mettez-les en corrélation avec les événements de sécurité entrants et historiques.

Activer la correspondance automatique des IoC

Google SecOps inclut un moteur de mise en correspondance automatique qui fonctionne indépendamment des règles de détection personnalisées. Lorsque la télémétrie d'événement correspond à un indicateur actif dans l'ECG :

  • Correspondances générées par le système : la plate-forme crée automatiquement un enregistrement de correspondance d'IoC sans nécessiter de maintenance des règles personnalisées.
  • Délai estimé après l'ingestion (estimation approximative) :
    • Événements de flux : une fois qu'un indicateur est ajouté à l'ECG (généralement entre 5 et 15 minutes après l'ingestion), Google SecOps évalue les événements de flux entrants et affiche les correspondances sur la page Correspondances d'IoC dans un délai de 5 à 15 minutes.
    • Événements historiques : le moteur de mise en correspondance automatique évalue également les indicateurs nouvellement ingérés de manière rétroactive par rapport à la télémétrie historique par cycles de traitement par lot. Les correspondances initiales apparaissent généralement sous une à quatre heures (et la corrélation historique complète est effectuée sous 24 heures).
  • Application des intervalles : le moteur de correspondance évalue les événements de manière stricte par rapport aux indicateurs actifs lorsque le code temporel de l'événement se situe dans metadata.interval.

Créer des règles de corrélation YARA-L 2.0

Écrivez des règles de détection YARA-L 2.0 pour joindre la télémétrie des événements (telles que les connexions réseau, les requêtes DNS ou les lancements de processus) aux entités d'indicateur dans l'ECG. Les règles personnalisées vous permettent de combiner les correspondances d'indicateurs avec des seuils comportementaux, le contexte des composants et les listes d'exclusion :

  1. Dans le menu de navigation Google SecOps, sélectionnez Détection > Règles et détections, puis cliquez sur Nouveau.
  2. Dans la section events: de votre règle, définissez une variable d'espace réservé pour joindre un champ d'événement UDM (tel que $net.target.ip = $ip) au champ d'entité ECG correspondant (tel que $ioc.graph.entity.ip = $ip).

  3. Filtrez la variable d'entité par attributs de menace (tels que $ioc.graph.metadata.threat.category) et spécifiez une période de corrélation dans la section match: (par exemple, $ip over 5m).

  4. Cliquez sur Enregistrer la nouvelle règle.

Exécuter une rétrochasse pour détecter les compromissions historiques

Les flux de renseignements sur les menaces contiennent souvent des indicateurs utilisés par les pirates informatiques quelques jours ou semaines avant que votre organisation n'ingère le flux. Alors que les règles en direct évaluent la nouvelle télémétrie entrante, une rétrochasse YARA-L applique la logique de votre règle de manière rétroactive à un historique d'événements de sécurité pouvant remonter jusqu'à 30 jours :

  1. Dans le menu de navigation Google SecOps, sélectionnez Détection > Règles et détections.
  2. Recherchez votre règle de renseignement sur les menaces personnalisée dans la liste des règles.
  3. Cliquez sur  pour afficher d'autres options de règles, puis sélectionnez Recherche Retrohunt YARA-L.
  4. Dans la boîte de dialogue YARA-L Retrohunt, sélectionnez les heures de début et de fin de votre recherche historique. Assurez-vous que la plage de dates sélectionnée est supérieure ou égale à la période de correspondance spécifiée dans votre règle.
  5. Cliquez sur Exécuter.

  6. Ouvrez l'onglet Détections de la règle pour surveiller la progression et inspecter les correspondances historiques.

Pour en savoir plus, consultez Exécuter une règle sur des données historiques.

Examiner les correspondances et les alertes

Passez en revue les résultats générés par les règles de correspondance automatique et de corrélation personnalisée dans les vues dédiées de Google SecOps.

Examiner les correspondances automatiques sur la page "Correspondances IoC"

Pour examiner les correspondances automatiques d'indicateurs :

  1. Dans le menu de navigation Google SecOps, sélectionnez Détection > Correspondances d'IoC.
  2. Utilisez les commandes de filtrage pour limiter les résultats par type d'indicateur (domaines, adresses IP, hachages de fichiers ou URL).
  3. Cliquez sur une ligne d'indicateur pour ouvrir le panneau des détails de la correspondance, qui affiche les informations suivantes :
    • Les composants internes et les noms d'utilisateur associés.
    • Horodatages de la première et de la dernière occurrences de l'événement.
    • Source du flux de renseignements sur les menaces et attribution du niveau de confiance.
  4. Cliquez sur Afficher dans la recherche UDM pour inspecter tous les événements de télémétrie bruts associés à l'indicateur.

Pour en savoir plus, consultez Afficher les IoC à l'aide d'Applied Threat Intelligence.

Trier les correspondances de règles sur les pages "Alertes" et "Détections"

Les détections générées par des règles YARA-L personnalisées s'affichent sur les pages Alertes et Détections :

  1. Dans le menu de navigation Google SecOps, sélectionnez Détection > Alertes et IoC pour afficher les alertes de règles prioritaires.
  2. Cliquez sur le nom d'une alerte pour ouvrir la page Détails de l'alerte et inspecter le tableau Détections, qui liste les lignes d'événements corrélés et les attributs d'entité ECG.
  3. Pour les règles silencieuses (où les alertes sont désactivées) ou les analyses rétrospectives terminées, ouvrez Détection > Règles et détections, cliquez sur le nom de la règle, puis examinez l'onglet Détections.

Corréler des indicateurs personnalisés avec le centre des menaces émergentes

Vous pouvez également utiliser le Centre des menaces émergentes pour examiner le lien entre vos correspondances d'IoC personnalisées et les campagnes d'adversaires et les familles de logiciels malveillants plus larges :

  1. Dans le menu de navigation Google SecOps, sélectionnez Détection > Menaces émergentes.
  2. Examinez les campagnes de menaces et les avis actifs, puis passez à la recherche UDM pour vérifier si les indicateurs de vos flux de menaces personnalisés chevauchent l'activité de campagne observée.

Pour en savoir plus, consultez la Présentation du centre des menaces émergentes.

Accéder aux composants et références avancés

Utilisez les extraits YARA-L 2.0 et les ressources de référence suivants lorsque vous créez des règles personnalisées de renseignements sur les menaces.

Connexion réseau sortante correspondant à une adresse IP malveillante

Cette règle met en corrélation les événements NETWORK_CONNECTION sortants avec les indicateurs d'adresse IP actifs dans l'ECG :

rule custom_ioc_network_connection {
  meta:
    author = "Security Operations"
    description = "Detects connections to IPs matching custom threat intel"
    severity = "HIGH"
    priority = "HIGH"

  events:
    $net.metadata.event_type = "NETWORK_CONNECTION"
    $net.target.ip = $ip

    $ioc.graph.entity.ip = $ip
    $ioc.graph.metadata.threat.category = "SUSPICIOUS_NETWORK"

  match:
    $ip over 5m

  outcome:
    $risk_score = max(85)
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $principal_hostname = array_distinct($net.principal.asset.hostname)

  condition:
    $net and $ioc
}

Requête DNS correspondant à un domaine malveillant

Cette règle identifie les recherches NETWORK_DNS pour les domaines signalés comme malveillants dans vos flux de renseignements sur les menaces ingérés :

rule custom_ioc_malicious_domain_query {
  meta:
    author = "Security Operations"
    description = "Detects DNS queries for domains matching threat intel"
    severity = "MEDIUM"
    priority = "MEDIUM"

  events:
    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name = $domain

    $ioc.graph.entity.hostname = $domain

  match:
    $domain over 10m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $client_ip = array_distinct($dns.principal.ip)

  condition:
    $dns and $ioc
}

Exécution de processus correspondant à un hachage de fichier SHA-256 malveillant

Cette règle se déclenche lorsqu'un événement PROCESS_LAUNCH correspond à un hachage de fichier SHA-256 malveillant connu stocké dans l'ECG :

rule custom_ioc_malicious_file_execution {
  meta:
    author = "Security Operations"
    description = "Detects process launches matching malicious file hashes"
    severity = "CRITICAL"
    priority = "HIGH"

  events:
    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.target.process.file.sha256 = $sha256

    $ioc.graph.entity.file.sha256 = $sha256

  match:
    $sha256 over 5m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $file_path = array_distinct($process.target.process.file.full_path)
    $hostname = array_distinct($process.principal.asset.hostname)
    $user = array_distinct($process.principal.user.userid)

  condition:
    $process and $ioc
}

Blogs de la communauté et ressources supplémentaires

Pour obtenir d'autres exemples de création de règles YARA-L et de corrélation de flux personnalisés de renseignements sur les menaces, consultez les ressources de la communauté Google Cloud suivantes :

Dépannage

Utilisez cette section pour gérer les attentes en termes de performances et résoudre les problèmes courants lors de l'intégration de flux de renseignement sur les menaces et de la création de règles de corrélation.

Latence, quota de service et limites

  • Ingestion et indexation pour la recherche UDM : les indicateurs nouvellement ingérés apparaissent généralement dans la recherche UDM sous deux à cinq minutes. Attendez au moins cinq minutes après l'ingestion du flux avant de résoudre les problèmes liés aux enregistrements d'entités manquants.
  • Latence de la mise en correspondance automatique des IoC : une fois qu'un indicateur est ajouté à l'ECG, les correspondances avec les événements de flux entrants s'affichent sur la page Correspondances IoC dans un délai de 5 à 15 minutes. L'établissement de correspondances par lot rétroactif avec les événements historiques prend généralement entre une et quatre heures (et jusqu'à 24 heures pour la corrélation historique complète).
  • Fenêtre de corrélation du graphique de contexte des entités : les règles de corrélation YARA-L et de correspondance automatique des IoC évaluent les indicateurs strictement dans leur fenêtre metadata.interval active. Les indicateurs dont les valeurs end_time ont expiré ne génèrent pas de correspondances.
  • Période de recherche Retrohunt : les recherches Retrohunt YARA-L analysent jusqu'à 30 jours de télémétrie historique par exécution. Le temps de traitement dépend de la complexité de la règle et de la disponibilité des ressources système.

Correction des erreurs

Utilisez ce tableau pour diagnostiquer et résoudre les problèmes lors de l'intégration du renseignement sur les menaces et de la création de règles de détection.

Problème Description du problème Corriger
Journaux d'IoC non analysés L'état du flux indique que les données entrantes sont bien reçues, mais les journaux ne parviennent pas à être analysés en entités UDM. Vérifiez que le type de journal de flux correspond à votre analyseur (par exemple, STIX, MISP_IOC ou CSV_CUSTOM_IOC). Consultez le tableau de bord Ingestion de données pour détecter les erreurs de schéma brut.
Résultats de recherche UDM manquants Les journaux d'indicateurs sont analysés sans erreur, mais la recherche UDM ne renvoie aucun enregistrement d'entité. Vérifiez que votre requête cible les champs graph.entity.* (tels que graph.entity.ip) plutôt que les champs d'événement udm.principal.*.
La règle ne se déclenche pas sur un indicateur connu L'événement et l'indicateur existent dans la recherche UDM, mais la règle YARA-L ne produit aucune détection. Vérifiez que metadata.interval.start_time et metadata.interval.end_time sur l'indicateur entourent le code temporel de l'événement.
Alerte d'inondation lors de la recherche Retrohunt L'exécution d'une rétrochasse crée des centaines d'alertes et de cas SOAR en double. Désactivez l'option d'alerte de la règle avant de lancer une recherche RetroHunt. Consultez les détections sur la page Détections avant de réactiver les alertes en direct.
Volume élevé de faux positifs Les indicateurs bruyants déclenchent des détections sur les scanners internes ou les hôtes administratifs bénins. Ajoutez une exclusion de liste de référence à votre règle (par exemple, not $net.principal.ip in %benign_scanner_ips) et exigez un contexte d'événement comportemental.

Validation et test

Avant d'activer une règle de renseignements sur les menaces personnalisée en mode d'alerte en direct, vérifiez sa logique à l'aide de la fonctionnalité Tester la règle intégrée :

  1. Ouvrez Détection > Règles et détections, puis cliquez sur votre règle pour ouvrir l'éditeur de règles.
  2. Cliquez sur Tester la règle dans le panneau inférieur pour évaluer la règle par rapport aux données d'événements historiques récents et aux entités ECG actives sans générer d'alertes ni de cas SOAR.
  3. Inspectez les détections de test renvoyées pour vérifier que les variables outcome (telles que $threat_name et $source_feed) sont renseignées comme prévu.

Étapes suivantes

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