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 de contexte d'entité (ECG) 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 le 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) : 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é utilisé par Google SecOps pour normaliser les journaux d'événements bruts et les données d'entités contextuelles.
  • Intervalle de 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 télémétriques 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 permet d'atteindre les 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 et de rétrochasse YARA-L personnalisées

  • Objectif : Joignez des entités de renseignements sur les menaces dans l'ECG avec la télémétrie multi-événements et analysez jusqu'à 30 jours de données historiques à l'aide de la chasse 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 périodiquement des indicateurs à partir de points de terminaison HTTPS, Cloud Storage ou Amazon S3 externes.
  • API d'ingestion : envoyez des charges utiles d'entités préstructurées directement à Google SecOps à l'aide de l'API d'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 renseignements sur les menaces que vous avez choisis :

  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 journal entrantes s'affichent sans erreurs de journal non analysées.

Remplir et valider le graphique de 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 UDM Entity 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, telle que 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 les listes 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 > Search (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 l'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'un é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 remplit l'ECG (généralement 5 à 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 1 à 4 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 de comportement, le contexte des composants et des 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 renseignement sur les menaces contiennent souvent des indicateurs que les pirates informatiques ont utilisés des jours ou des semaines avant que votre organisation n'ingère le flux. Alors que les règles en direct évaluent les nouvelles données de télémétrie entrantes, 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 renseignements 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 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 couverture 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 par rapport aux données de l'historique.

Examiner les correspondances et les alertes

Passez en revue les résultats générés par les règles de mise en 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 des 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 :
    • Ressources et noms d'utilisateur internes 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 Présentation du centre de veille sur les menaces émergentes.

Accéder à des composants et des 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 de renseignements sur les menaces personnalisées.

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 d'informations 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 dans un délai de 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 une corrélation historique complète).
  • Fenêtre de corrélation du graphique du 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 IoC non analysés L'état du flux indique que des données sont entrantes, mais les journaux ne parviennent pas à être analysés en entités UDM. Vérifiez que le type de journal du 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 rétroactive. 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 confirmer 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 auprès des membres de la communauté et des professionnels Google SecOps.