Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Flux de fusion des renseignements sur les menaces appliqués

Compatible avec :

Google SecOps SIEM

Le flux Fusion Applied Threat Intelligence (ATI) est un ensemble d'indicateurs de compromission (IoC), y compris des hachages, des adresses IP, des domaines et des URL, associés à des acteurs malveillants connus, des souches de logiciels malveillants, des campagnes actives et des rapports de renseignement terminés. Le flux inclut également des IoC provenant de flux Open Source que Mandiant Intelligence a soigneusement vérifiés et validés, ce qui maximise la valeur et offre une grande précision.

Le processus de curation de Mandiant comprend les phases suivantes :

Réponse aux incidents de première ligne : lors de l'enquête sur les violations, les analystes Mandiant acquièrent une connaissance directe des outils et des techniques des pirates informatiques.
Recherche sur les menaces : des équipes dédiées suivent les acteurs malveillants, analysent les logiciels malveillants et découvrent les infrastructures d'attaque émergentes.
Contextualisation : les IoC sont mappés à des menaces et des campagnes spécifiques, ce qui permet de comprendre et de hiérarchiser les incidents.

Le flux Breach Analytics s'appuie sur le flux ATI Fusion en incluant des indicateurs provenant d'enquêtes sur les violations Mandiant nouvelles et actives. Il fournit des insights en temps réel sur les dernières tendances en matière d'attaques. Pour améliorer la correspondance des indicateurs, les règles YARA-L peuvent utiliser des informations contextuelles du flux ATI Fusion, telles que les groupes de menaces associés, la présence d'un indicateur dans des environnements compromis ou le score de malveillance automatisé de Mandiant.

Écrire des règles YARA-L avec le flux ATI Fusion

La rédaction de règles YARA-L qui utilisent le flux ATI Fusion dans Google Security Operations suit un processus similaire à la rédaction de règles YARA-L qui utilisent d'autres sources d'entités de contexte. Pour en savoir plus, consultez Créer des analyses contextuelles.

Événements et sections de match

Pour rédiger une règle, procédez comme suit : 1. Filtrer le graphique d'entités du contexte sélectionné. Dans ce cas, Fusion Feed. 1. Filtrer un type d'indicateur spécifique. Exemple :FILE Consultez l'exemple ci-dessous :

events:
   $context_graph.graph.metadata.product_name = "MANDIANT_FUSION_IOC"
   $context_graph.graph.metadata.vendor_name = "MANDIANT_FUSION_IOC"
   $context_graph.graph.metadata.source_type = "GLOBAL_CONTEXT"
   $context_graph.graph.metadata.entity_type = "FILE"

Vous pouvez ajouter d'autres conditions de l'événement ou de l'entité de contexte dans la section events. Vous pouvez joindre un champ de l'entité de contexte et un champ d'événement UDM.

Dans l'exemple suivant, la variable d'espace réservé ioc est utilisée pour effectuer une jointure transitive entre l'entité de contexte et l'événement. La variable ioc est ensuite utilisée dans la section match pour s'assurer qu'il existe une correspondance dans un délai spécifique.

   $ioc = $context_graph.graph.entity.file.md5
   $ioc = $e1.principal.process.file.md5

match:
   $ioc over 1h

Pour en savoir plus sur les champs d'entité de contexte pouvant être utilisés dans les règles YARA-L, consultez la section Champs d'entité de contexte du flux Fusion.

Section "outcome"

Pour reprendre l'exemple précédent, la règle de correspondance d'indicateur de base est configurée par rapport aux hachages de fichiers dans les entités de contexte du champ graph.entity.file.md5 et du champ UDM principal.process.file.md5.

Étant donné que cette règle peut correspondre à un grand nombre d'événements, nous vous recommandons de l'affiner pour qu'elle corresponde aux entités de contexte disposant d'informations spécifiques. Par exemple, vous pouvez rechercher une correspondance avec le score de confiance que Mandiant a attribué à l'indicateur, qu'il ait été détecté dans un environnement piraté ou dans la famille de logiciels malveillants associée à l'indicateur. Vous pouvez effectuer toutes ces opérations dans la section outcome de la règle.

 outcome:
   // Extract the Mandiant Automated Intel confidence score of maliciousness
   $confidence_score = max(if($context_graph.graph.metadata.threat.verdict_info.source_provider = "Mandiant Automated Intel", $context_graph.graph.metadata.threat.verdict_info.confidence_score, 0))
   // Extract the status of the indicator as seen in a breached environment
   $breached = max(if($context_graph.graph.metadata.threat.verdict_info.pwn = true, 1, 0))

   // Intermediary outcome variable to combine conditions of intelligence extracted in the previous outcome variables.
   // Return 1 if conditions are met, otherwise return 0.
   $matched_conditions = if($confidence_score >= 80 AND $breached = 1, 1, 0)

Dans la section outcome de la règle YARA-L, le score de confiance est extrait à l'aide d'une if statement encapsulée dans une fonction max. Cette technique est requise pour les règles à événements multiples. La même technique est utilisée pour extraire la variable pwn de verdict_info, qui indique si un indicateur a été détecté dans un environnement compromis identifié par Mandiant.

Ces deux variables de résultat sont ensuite combinées dans une autre variable matched_conditions, ce qui permet d'utiliser une logique enchaînée dans la section condition.

Section "Condition"

La section condition garantit que e1, context_graph et matched_conditions existent et/ou correspondent à la condition spécifiée.

 condition:
   // Ensure $e1, $context_graph and $matched_conditions conditions are met.
   $e1 AND $context_graph AND $matched_conditions = 1

Règle YARA-L complète

À ce stade, la règle est prête à être utilisée et doit se présenter comme suit :

rule fusion_feed_example_principal_process_file_md5 {
 meta:
   rule_name = "File Hash - Applied Threat Intelligence"
   description = "Matches file hashes against the Applied Threat Intelligence Fusion Feed."

 events:
   // Filter graph
   $context_graph.graph.metadata.product_name = "MANDIANT_FUSION_IOC"
   $context_graph.graph.metadata.vendor_name = "MANDIANT_FUSION_IOC"
   $context_graph.graph.metadata.entity_type = "FILE"
   $context_graph.graph.metadata.source_type = "GLOBAL_CONTEXT"

   // Do join
   $ioc = $context_graph.graph.entity.file.md5
   $ioc = $e1.principal.process.file.md5

 match:
   $ioc over 1h

 outcome:
   // Extract the Mandiant Automated Intel confidence score of maliciousness
   $confidence_score = max(if($context_graph.graph.metadata.threat.verdict_info.source_provider = "Mandiant Automated Intel", $context_graph.graph.metadata.threat.verdict_info.confidence_score, 0))
   // Extract the status of the indicator as seen in a breached environment
   $breached = max(if($context_graph.graph.metadata.threat.verdict_info.pwn = true, 1, 0))

   // Intermediary outcome variable to combine conditions of intelligence extracted in the previous outcome variables.
   // Return 1 if conditions are met, otherwise return 0.
   $matched_conditions = if($confidence_score >= 80 AND $breached = 1, 1, 0)

 condition:
   // Ensure $e1, $context_graph and $matched_conditions conditions are met.
   $e1 AND $context_graph AND $matched_conditions = 1
}

Champs d'entité de contexte du flux ATI Fusion

Vous pouvez utiliser de nombreux champs du flux ATI Fusion dans les règles. Ces champs sont tous définis dans la liste des champs du modèle de données unifié. Les champs suivants sont pertinents pour hiérarchiser les indicateurs :

Champ d'entité	Valeurs possibles
`metadata.threat.associations.type`	`MALWARE`, `THREAT_ACTOR`
`metadata.threat.associations.name`	Nom de l'association de menace
`metadata.threat.verdict_info.pwn`	`TRUE`, `FALSE`
`metadata.threat.verdict_info.pwn_first_tagged_time.seconds`	Code temporel (en secondes)

Certains champs comportent des paires clé-valeur qui doivent être utilisées en combinaison pour accéder aux valeurs correctes. Exemple :

Champ d'entité 1	Valeurs	Champ d'entité 2	Valeurs
`metadata.threat.verdict_info.source_provider`	Mandiant Global Intel	`metadata.threat.verdict_info.global_hits_count`	Integer
`metadata.threat.verdict_info.source_provider`	Mandiant Global Intel	`metadata.threat.verdict_info.global_customer_count`	Integer
`metadata.threat.verdict_info.source_provider`	Mandiant Analyst Intel	`metadata.threat.verdict_info.confidence_score`	Integer
`metadata.threat.verdict_info.source_provider`	Mandiant Automated Intel	`metadata.threat.verdict_info.confidence_score`	Integer

Dans la section outcome d'une règle YARA-L, vous pouvez accéder à une valeur désignée par une clé spécifique à l'aide de la commande suivante :

$hit_count = max(if($context_graph.graph.metadata.threat.verdict_info.source_provider = "Mandiant Global Intel", $context_graph.graph.metadata.threat.verdict_info.global_hits_count, 0))

L'examen des correspondances d'entités dans Google Security Operations vous permet d'obtenir une vue complète des données, révélant des champs supplémentaires qui peuvent être utiles pour évaluer la priorité et le contexte d'une alerte d'indicateur.

L'exemple suivant montre une entité de contexte Fusion Feed comme point de référence initial :

{
  "metadata": {
    "product_entity_id": "md5--147d19e6-cdae-57bb-b9a1-a8676265fa4c",
    "collected_timestamp": {
      "seconds": "1695165683",
      "nanos": 48000000
    },
    "vendor_name": "MANDIANT_FUSION_IOC",
    "product_name": "MANDIANT_FUSION_IOC",
    "product_version": "1710194393",
    "entity_type": "FILE",
    "creation_timestamp": {
      "seconds": "1710201600"
    },
    "interval": {
      "start_time": {
        "seconds": "1"
      },
      "end_time": {
        "seconds": "253402300799"
      }
    },
    "threat": [
      {
        "category_details": [
          "A phishing email message or the relevant headers from a phishing email."
        ],
        "severity_details": "HIGH",
        "confidence_details": "75",
        "risk_score": 75,
        "first_discovered_time": {
          "seconds": "1683294326"
        },
        "associations": [
          {
            "id": "threat-actor--3e5e6bdf-5b4e-5166-84fa-83045e637f23",
            "type": "THREAT_ACTOR",
            "name": "UNC2633"
          },
          {
            "id": "threat-actor--3e5e6bdf-5b4e-5166-84fa-83045e637f23",
            "country_code": [
              "unknown"
            ],
            "type": "THREAT_ACTOR",
            "name": "UNC2633",
            "description": "UNC2633 is a distribution threat cluster that delivers emails containing malicious attachments or links that lead to malware payloads, primarily QAKBOT, but also SNOWCONE.GZIPLOADER (which leads to ICEDID) and MATANBUCHUS. Historically, UNC2633 has distributed ZIP files containing malicious Excel files that download malware payloads. In early 2023, UNC2633 started distributing OneNote files (.one) that usually led to QAKBOT. It has also leveraged HTML smuggling to distribute ZIP files containing IMG files that contain LNK files and malware payloads.",
            "alias": [
              {
                "name": "TA570 (Proofpoint)"
              }
            ],
            "first_reference_time": {
              "seconds": "1459085092"
            },
            "last_reference_time": {
              "seconds": "1687392000"
            },
            "industries_affected": [
              "Aerospace & Defense",
              "Agriculture",
              "Automotive",
              "Chemicals & Materials",
              "Civil Society & Non-Profits",
              "Construction & Engineering",
              "Education",
              "Energy & Utilities",
              "Financial Services",
              "Governments",
              "Healthcare",
              "Hospitality",
              "Insurance",
              "Legal & Professional Services",
              "Manufacturing",
              "Media & Entertainment",
              "Oil & Gas",
              "Pharmaceuticals",
              "Retail",
              "Technology",
              "Telecommunications",
              "Transportation"
            ]
          }
        ],
        "campaigns": [
          "CAMP.23.007"
        ],
        "last_updated_time": {
          "seconds": "1695165683",
          "nanos": 48000000
        },
        "verdict_info": [
          {
            "source_provider": "Mandiant Automated Intel",
            "confidence_score": 75
          },
          {
            "verdict_type": "ANALYST_VERDICT",
            "confidence_score": 75
          },
          {
            "source_count": 91,
            "response_count": 1,
            "verdict_type": "PROVIDER_ML_VERDICT",
            "malicious_count": 1,
            "ioc_stats": [
              {
                "ioc_stats_type": "MANDIANT_SOURCES",
                "second_level_source": "Knowledge Graph",
                "quality": "HIGH_CONFIDENCE",
                "malicious_count": 1,
                "response_count": 1,
                "source_count": 8
              },
              {
                "ioc_stats_type": "MANDIANT_SOURCES",
                "second_level_source": "Malware Analysis",
                "source_count": 4
              },
              {
                "ioc_stats_type": "MANDIANT_SOURCES",
                "second_level_source": "Spam Monitoring",
                "source_count": 1
              },
              {
                "ioc_stats_type": "THIRD_PARTY_SOURCES",
                "second_level_source": "Crowdsourced Threat Analysis",
                "source_count": 71
              },
              {
                "ioc_stats_type": "THIRD_PARTY_SOURCES",
                "first_level_source": "MISP",
                "second_level_source": "Trusted Software List",
                "source_count": 3
              },
              {
                "ioc_stats_type": "THIRD_PARTY_SOURCES",
                "first_level_source": "Threat Intelligence Feeds",
                "second_level_source": "Digitalside It Hashes",
                "source_count": 1
              },
              {
                "ioc_stats_type": "THIRD_PARTY_SOURCES",
                "first_level_source": "Threat Intelligence Feeds",
                "second_level_source": "Tds Harvester",
                "source_count": 1
              },
              {
                "ioc_stats_type": "THIRD_PARTY_SOURCES",
                "first_level_source": "Threat Intelligence Feeds",
                "second_level_source": "Urlhaus",
                "source_count": 1
              }
            ]
          },
          {
            "source_provider": "Mandiant Analyst Intel",
            "confidence_score": 75,
            "pwn": true,
            "pwn_first_tagged_time": {
              "seconds": "1683911695"
            }
          }
        ],
        "last_discovered_time": {
          "seconds": "1683909854"
        }
      }
    ],
    "source_type": "GLOBAL_CONTEXT",
    "source_labels": [
      {
        "key": "is_scanner",
        "value": "false"
      },
      {
        "key": "osint",
        "value": "false"
      },
      {
        "key": "misp_akamai",
        "value": "false"
      },
...
      {
        "key": "has_pwn",
        "value": "2023-05-12T17:14:55.000+0000"
      }
    ],
    "event_metadata": {
      "id": "\\000\\000\\000\\000\\034Z\\n\\2545\\237\\367\\353\\271\\357\\302\\215t\\330\\275\\237\\000\\000\\000\\000\\007\\000\\000\\000\\206\\000\\000\\000",
      "base_labels": {
        "log_types": [
          "MANDIANT_FUSION_IOC"
        ],
        "allow_scoped_access": true
      }
    }
  },
  "entity": {
    "file": {
      "sha256": "000bc5900dc7a32851e380f418cc178ff0910242ee0561ae37ff424e6d3ec64a",
      "md5": "f0095b0a7480c826095d9ffc9d5d2d8f",
      "sha1": "8101315b9fbbf6a72bddbfe64837d246f4c8b419"
    },
    "labels": [
      {
        "key": "is_scanner",
        "value": "false"
      },
      {
        "key": "osint",
        "value": "false"
      },
      {
        "key": "misp_akamai",
        "value": "false"
      },
...
    ]
  }
}

Conditions complexes

Pour utiliser plusieurs champs dans une entité de contexte, vous pouvez combiner plusieurs variables de résultat afin de créer une logique conditionnelle plus complexe. Les variables de résultat intermédiaire peuvent être utilisées pour combiner plusieurs champs. Ces variables sont ensuite combinées pour former une nouvelle variable de résultat qui peut être utilisée dans la section condition.

Exemple :

// Value will be 1 if threat.associations.type = "MALWARE"
// Wrapper max function required for multi-event rules
$is_attributed_malware = max(if($entity_context.graph.metadata.threat.associations.type = "MALWARE", 1, 0))

// Value will be 1 if threat.associations.type = "THREAT_ACTOR"
$is_attributed_actor = max(if($entity_context.graph.metadata.threat.associations.type = "THREAT_ACTOR", 1,0))

// Value will be the sum of the $is_attributed_malware $is_attributed_malware and $is_attributed_actor
$is_attributed = if($is_attributed_malware = 1, 1, 0)
                    +
                    if($is_attributed_actor = 1, 1, 0)

// If the value of $is_attributed is greater than 1, this indicates the indicator has been attributed at least once with the type "MALWARE" or "THREAT_ACTOR"

Dans cet exemple, deux variables de résultat intermédiaire, is_attributed_malware et is_attributed_actor, sont combinées dans une variable de résultat is_attributed.

Les valeurs de résultat intermédiaire renvoient des valeurs numériques, ce qui permet d'effectuer des comparaisons numériques dans la nouvelle variable de résultat.

La valeur de is_attributed sera supérieure ou égale à 1 si l'indicateur est associé à au moins une menace de type MALWARE ou THREAT_ACTOR.

Jointures flexibles dans une règle YARA-L

Pour réduire le nombre de règles requises, vous pouvez utiliser des jointures flexibles entre les IoC pour connecter plusieurs champs UDM à une entité de contexte.

L'exemple suivant montre l'utilisation de jointures flexibles pour plusieurs champs UDM dans la section event :

  events:
    // Filter graph
    $mandiant.graph.metadata.product_name = "MANDIANT_FUSION_IOC"
    $mandiant.graph.metadata.vendor_name = "MANDIANT_FUSION_IOC"
    $mandiant.graph.metadata.entity_type = "FILE"
    $mandiant.graph.metadata.source_type = "GLOBAL_CONTEXT"

    $mandiant.graph.entity.file.md5 = strings.coalesce($e.target.process.file.md5, $e.target.process.file.md5) OR
    $mandiant.graph.entity.file.md5 = strings.coalesce($e.principal.process.file.md5, $e.principal.process.file.md5)

Migrer les anciens flux Mandiant vers GTI

Google SecOps consolide les sources de données de renseignement sur les menaces. Pour fournir un ensemble plus large d'indicateurs de compromission et simplifier l'intégration, nous migrons des anciens flux Mandiant vers le flux unifié Google Threat Intelligence (GTI).

Ce guide s'adresse aux ingénieurs et analystes en détection qui souhaitent maintenir une couverture ininterrompue des menaces lors de la migration vers le flux GTI unifié. Il explique comment mettre à jour les règles YARA-L existantes pour qu'elles correspondent aux nouveaux IoC GTI, tout en préservant l'ancienne fonctionnalité d'alerte. En mettant à jour la syntaxe de vos règles selon le calendrier et les workflows de migration fournis, vous assurez une transition fluide avant que les anciens flux ne soient gelés.

Mettre à jour vos règles YARA-L

Nous vous recommandons de mettre à jour vos règles YARA-L avec le nouveau nom du produit GTI afin de maintenir une couverture ininterrompue.

Ancien nom du flux Mandiant	Nouveau nom du produit GTI	Niveau de licence
`MANDIANT_FUSION_IOC`	GTI_IOC	Enterprise ou Enterprise+
`OPEN_SOURCE_INTEL_IOC`	GTI_IOC	Enterprise ou Enterprise+
`MANDIANT_ACTIVE_BREACH_IOC`	GTI_IOC	Enterprise+

Documentation de référence sur la migration YARA-L

Utilisez ces extraits pour mettre à jour manuellement vos règles si vous préférez ne pas utiliser la fonction Appliquer de Gemini.

Migration de base

Utilisez cette syntaxe YARA-L pour rechercher des correspondances avec les données historiques et les nouvelles données GTI.

Ancienne syntaxe YARA-L :

$mandiant.graph.metadata.product_name = "MANDIANT_FUSION_IOC"

Syntaxe YARA-L recommandée :

(
    $mandiant.graph.metadata.product_name = "GTI_IOC"
    $mandiant.graph.metadata.threat_intel.stable = true
)

Comprendre le workflow de migration

Le workflow suivant reflète la nouvelle expérience de gestion des règles conçue pour vous guider tout au long de la migration.

Identifiez les règles concernées. Ouvrez la page Gestion des règles/Lister. Une bannière générale bien visible s'affiche si votre locataire comporte des règles concernées.
- Indicateur : les règles faisant référence à d'anciens flux affichent une icône d'avertissement ou une info-bulle Update Required.
- Action : cliquez sur Demander à Gemini de vous aider à mettre à jour ou sélectionnez une règle spécifique pour afficher les détails.
Analysez les détails de la règle. Lorsque vous ouvrez une règle concernée, l'éditeur de règles met en surbrillance l'ancienne syntaxe (par exemple, $mandiant.graph.metadata.product_name = "MANDIANT_FUSION_IOC").

Un bouton de migration dédié s'affiche dans l'en-tête de l'éditeur, qui déclenche le panneau latéral Gemini.
Lisez la mise à jour assistée par Gemini. Le panneau latéral Gemini charge automatiquement une fiche de contexte préremplie :
- Gemini explique la correspondance entre votre ancien flux et le nouveau flux GTI en fonction de vos droits d'accès.
- Gemini fournit un bloc de code Correction suggérée. Examinez la logique YARA-L mise à jour, qui ajoute GTI_IOC tout en conservant la référence héritée pour la couverture historique.
Cliquez sur Appliquer à l'éditeur pour remplacer l'ancienne logique par la nouvelle syntaxe suggérée.
Vérifiez votre nouvelle syntaxe. Une fois la règle enregistrée avec la syntaxe GTI_IOC mise à jour, les détails suivants s'affichent :
- L'icône d'avertissement Mise à jour requise disparaît de l'éditeur et de la page principale Liste des règles.
- L'état de votre migration est mis à jour en temps réel à mesure que vous supprimez les règles signalées.

Comprendre le filtrage de l'ingestion des flux GTI_IOC

Pour garantir une haute fidélité et minimiser le bruit, Google SecOps filtre les IoC dans le flux GTI_IOC. Google SecOps n'inclut un IoC du flux que s'il répond à au moins l'un des critères suivants :

Il a un score de confiance GTI de 80 ou plus.

Remarque : Vous pouvez récupérer le score de confiance (c'est-à-dire gti_confidence_score) à l'aide de l'API GTI.
Il a un verdict GTI "malveillant".
Il est associé à une menace connue (par exemple, il est lié à une campagne de menace spécifique).

Les IoC non examinés qui répondent à ces critères sont toujours ingérés dans Google SecOps et peuvent être utilisés dans vos règles YARA-L, mais ils sont marqués de l'icône metadata.threat.stable = false. Une fois que ces IoC ont été entièrement examinés ou validés, le tag stable est remplacé par true.

Pour en savoir plus, consultez Score d'indicateur Google Threat Intelligence.

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