Mettre en forme les données de journal sous forme d'UDM

Compatible avec :

Champs d'événement UDM courants

Tous les événements UDM (UDM) comportent un ensemble de champs et de messages communs que les partenaires peuvent renseigner, quel que soit le type d'événement. Ces champs incluent les suivants :

  • Entités : appareils, utilisateurs et processus impliqués dans un événement.
  • Métadonnées de l'événement : date et heure de l'événement, type d'événement, origine, etc.
  • Métadonnées réseau : métadonnées réseau de haut niveau pour les événements orientés réseau, ainsi que les détails du protocole dans les sous-messages :
    • Métadonnées des e-mails : informations figurant dans les champs "À", "De", "Cc", "Cci" et autres champs des e-mails.
    • Métadonnées HTTP : méthode, referral_url, useragent, etc.
  • Résultats de sécurité : toute classification ou action effectuée par un produit de sécurité.
  • Métadonnées supplémentaires : toutes les données d'événement importantes spécifiques à un fournisseur qui ne peuvent pas être représentées de manière adéquate dans les sections formelles du modèle UDM peuvent être ajoutées à l'aide d'un champ de charge utile JSON de format libre.

Les sections suivantes expliquent comment encoder et mettre en forme les événements pour l'UDM.

Encodage UDM

Les événements UDM doivent être envoyés à Google Security Operations dans l'un des formats suivants :

Dans ce document, les champs sont représentés à l'aide d'une notation par points. Par exemple, la syntaxe JSON suivante :

{"menu":
  {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"}
      ]
    }
  }
}

Elle est documentée comme suit :

menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"

Mettre en forme un événement UDM

Pour mettre en forme un événement UDM afin de le préparer à l'envoi à Google, vous devez procéder comme suit :

  1. Spécifiez le type d'événement : le type d'événement que vous sélectionnez détermine les champs que vous devez également inclure avec l'événement.
  2. Spécifiez l'horodatage de l'événement : spécifiez l'horodatage de l'événement.
  3. Spécifiez des noms (entités) : chaque événement doit inclure au moins un nom décrivant un appareil ou un utilisateur participant à l'événement.
  4. Spécifiez le résultat de sécurité : (facultatif) spécifiez les résultats de sécurité en incluant des détails sur les risques et menaces de sécurité détectés par un système de sécurité, ainsi que les actions entreprises pour atténuer ces risques et menaces.
  5. Remplissez les autres informations obligatoires et facultatives sur l'événement à l'aide des champs d'événement UDM.

Spécifier le type d'événement

La valeur la plus importante définie pour tout événement envoyé au format UDM est le type d'événement, spécifié à l'aide de l'une des valeurs possibles disponibles pour Metadata.event_type. Il s'agit, par exemple, de valeurs telles que PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (pour obtenir la liste complète, consultez Metadata.event_type). Pour chaque type d'événement, vous devez également renseigner un ensemble d'autres champs et valeurs avec les informations liées à l'événement d'origine. Pour savoir quels champs inclure pour chaque type d'événement, consultez Champs obligatoires et facultatifs pour chaque type d'événement UDM. L'exemple suivant montre comment spécifier PROCESS_OPEN comme type d'événement à l'aide de la notation textuelle Proto3 :

metadata {
    event_type: PROCESS_OPEN
}

Spécifier le code temporel de l'événement

Vous devez spécifier le code temporel GMT pour tout événement envoyé au format UDM à l'aide de Metadata.event_timestamp. Le tampon doit être encodé à l'aide de l'une des normes suivantes :

  • Pour JSON, utilisez RFC 3339.
  • Code temporel Proto3

L'exemple suivant montre comment spécifier l'horodatage au format RFC 3339. Dans cet exemple, aaaa-mm-jjThh:mm:ss+hh:mm correspond à l'année, au mois, au jour, à l'heure, à la minute, à la seconde et au décalage par rapport à l'heure UTC. Le décalage par rapport à l'heure UTC est de -8 heures, ce qui correspond à l'heure PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Spécifier des noms (entités)

Pour chaque événement UDM, vous devez définir un ou plusieurs noms. Un nom représente un participant ou une entité dans un événement UDM. Un nom peut être, par exemple, l'appareil ou l'utilisateur qui effectue l'activité décrite dans un événement, ou l'appareil ou l'utilisateur qui est la cible de cette activité décrite dans l'événement. Les noms peuvent également être des pièces jointes ou des URL. Enfin, un nom peut également être utilisé pour décrire un dispositif de sécurité qui a observé l'activité décrite dans l'événement (par exemple, un proxy de messagerie ou un routeur réseau).

Un événement UDM doit comporter un ou plusieurs des noms suivants :

principal : représente l'entité agissante ou l'appareil à l'origine de l'activité décrite dans l'événement. Le principal doit inclure au moins un détail sur la machine (nom d'hôte, adresses MAC, adresses IP, port, identifiants spécifiques au produit comme un GUID de machine CrowdStrike) ou sur l'utilisateur (par exemple, nom d'utilisateur), et peut éventuellement inclure des détails sur le processus. Il ne doit PAS inclure les champs suivants : adresse e-mail, fichiers, clés ou valeurs de registre.

Si tous les événements ont lieu sur la même machine, il suffit de décrire cette machine dans principal. Il n'est pas nécessaire de décrire également la machine dans target ou src.

L'exemple suivant montre comment les champs principal peuvent être renseignés :

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

Cet exemple fournit des informations sur l'appareil et l'utilisateur qui était le principal acteur de l'événement. Il inclut l'adresse IP, le numéro de port et le nom d'hôte de l'appareil, ainsi qu'un identifiant d'asset spécifique au fournisseur (Sophos), qui est un ID unique généré par le produit de sécurité tiers.

target : représente un appareil cible référencé par l'événement ou un objet sur l'appareil cible. Par exemple, dans une connexion de pare-feu de l'appareil A à l'appareil B, A est décrit comme le principal et B comme la cible. Dans le cas d'une injection de processus par le processus C dans le processus cible D, le processus C est décrit comme le principal et le processus D comme la cible.

principal et cible dans udm

Principal et cible dans UDM

L'exemple suivant montre comment les champs d'une cible sont renseignés :

target {
   ip: "198.51.100.31"
   port: 80
}

Encore une fois, si des informations supplémentaires sont disponibles (nom d'hôte, adresse(s) IP supplémentaire(s), adresse(s) MAC, identifiants de ressources propriétaires, etc.), elles doivent également être incluses dans target.

Les principaux et les cibles (ainsi que d'autres noms) peuvent faire référence à des acteurs sur la même machine. Par exemple, le processus A (principal) exécuté sur la machine X agit sur le processus B (cible) également sur la machine X.

  • src : représente un objet source sur lequel le participant agit, ainsi que le contexte de l'appareil ou du processus pour l'objet source (la machine sur laquelle réside l'objet source). Par exemple, si l'utilisateur U copie le fichier A sur la machine X vers le fichier B sur la machine Y, le fichier A et la machine X seront spécifiés dans la partie src de l'événement UDM.
  • intermediary : représente les détails d'un ou de plusieurs appareils intermédiaires traitant l'activité décrite dans l'événement. Cela inclut les informations sur un serveur proxy, un serveur de relais SMTP, etc.
  • observer : représente un appareil observateur (par exemple, un renifleur de paquets ou un scanner de vulnérabilités basé sur le réseau), qui n'est pas un intermédiaire direct, mais qui observe l'événement en question et en rend compte.
  • about : utilisé pour stocker des informations sur tous les objets référencés par l'événement qui ne sont pas décrits dans participant, src, target, intermediary ou observer. Par exemple, il peut être utilisé pour suivre les éléments suivants :
    • Pièces jointes aux e-mails
    • Domaines/URL/adresses IP intégrés dans le corps d'un e-mail
    • DLL chargées lors d'un événement PROCESS_LAUNCH

Les sections d'entités des événements UDM incluent des informations sur les différents participants (appareils, utilisateurs, objets tels que les URL, les fichiers, etc.) décrits dans l'événement. L'UDM Google Security Operations comporte des exigences obligatoires concernant le remplissage des champs "Nom". Ces exigences sont décrites dans Champs obligatoires et facultatifs pour chaque type d'événement UDM. L'ensemble des champs d'entité à remplir diffère selon le type d'événement.

Spécifier le résultat de sécurité

Vous pouvez éventuellement spécifier les résultats de sécurité en remplissant les champs SecurityResult, y compris les détails sur les risques et menaces de sécurité détectés par le système de sécurité, ainsi que les actions entreprises pour atténuer ces risques et menaces. Voici quelques exemples de types d'événements de sécurité qui nécessitent de renseigner les champs SecurityResult :

  • Un proxy de sécurité des e-mails a détecté une tentative d'hameçonnage (MAIL_PHISHING) et a bloqué l'e-mail (BLOCK).
  • Un pare-feu proxy de sécurité des e-mails a détecté deux pièces jointes infectées (SOFTWARE_MALICIOUS), les a mises en quarantaine et désinfectées (QUARANTINE, ALLOW_WITH_MODIFICATION), puis a transféré l'e-mail désinfecté.
  • Un système SSO a facilité une connexion (AUTH_VIOLATION) qui a été bloquée (BLOCK).
  • Un bac à sable de sécurité contre les logiciels malveillants a détecté un logiciel espion (SOFTWARE_MALICIOUS) dans une pièce jointe cinq minutes après que le fichier a été distribué (ALLOW) à l'utilisateur dans sa boîte de réception.

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