Mettre en forme les données des journaux en tant qu'UDM

Tous les événements UDM (Unified Data Model) comportent un ensemble de champs et de messages communs que les partenaires peuvent renseigner, quel que soit le type d'événement. Ces champs sont 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'origine, etc.
  • Métadonnées réseau: métadonnées réseau de haut niveau pour les événements réseau, ainsi que les détails du protocole dans les sous-messages :
    • Métadonnées des e-mails: informations dans les champs "À", "Formulaire", "Cc", "Cci" et d'autres
    • Métadonnées HTTP: méthode, URL_site référent, user-agent, 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 propres au fournisseur qui ne peuvent pas être représentées correctement dans les sections officielles du modèle UDM peuvent être ajoutées à l'aide d'un champ de charge utile JSON de forme libre.

Les sections suivantes décrivent comment encoder et mettre en forme les événements pour le modèle de données unifié (UDM, Unified Data Model).

Encodage UDM

Les événements UDM doivent être envoyés à Chronicle via l'un des formats suivants:

Dans le cadre du présent document, les champs sont représentés par un point. Par exemple, la syntaxe JSON suivante:

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

Documenté 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 formater un événement UDM afin de le préparer à envoyer à Google, procédez comme suit:

  1. Spécifier le type d'événement : le type d'événement sélectionné détermine les champs que vous devez également inclure dans l'événement.
  2. Spécifier l'horodatage de l'événement – metadata-position="body" } : spécifiez l'horodatage de l'événement.
  3. Noms (entités) : chaque événement doit inclure au moins un nom décrivant l'appareil ou l'utilisateur participant à l'événement.
  4. Indiquer le résultat de sécurité : (facultatif) spécifiez les résultats de sécurité en incluant des détails sur les risques de sécurité et les menaces détectés par un système de sécurité, ainsi que les mesures prises pour limiter ces risques et menaces.
  5. Remplissez les autres champs obligatoires et facultatifs à 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 pour Metadata.event_type. Cela inclut des valeurs telles que PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (pour obtenir la liste complète, consultez la section "Metadata.event_type"). Chaque type d'événement nécessite que vous remplissiez un ensemble d'autres champs et valeurs avec les informations associées à l'événement d'origine. Pour en savoir plus sur les champs à inclure pour chaque type d'événement, consultez la section 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 en utilisant la notation textuelle Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Spécifier l'horodatage de l'événement

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

  • Pour le format JSON, utilisez la RFC 3339.
  • Horodatage Proto3

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

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

Spécifier des noms (entités)

Vous devez définir un ou plusieurs noms pour chaque événement UDM. Un nom représente un participant ou une entité dans un événement UDM. Un nom peut être 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 correspondre à des pièces jointes ou des URL. Enfin, un nom peut également être utilisé pour décrire un appareil 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 ou plusieurs des noms suivants doivent être spécifiés pour un événement UDM:

principal: représente l'entité agissant ou l'appareil à l'origine de l'activité décrite dans l'événement. Le compte 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 CrowdStrike) ou sur les détails utilisateur (par exemple, le nom d'utilisateur). Il peut également inclure des informations sur le processus. Il ne doit PAS inclure les champs suivants: adresse e-mail, fichiers, clés de registre ou valeurs.

Si tous les événements se déroulent sur la même machine, cette machine doit être décrite dans la section principal. La machine n'a pas besoin d'être décrite dans target ni src.

.

L'exemple suivant illustre le remplissage des champs principal:

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

L'exemple ci-dessus décrit toutes les informations connues sur l'appareil et sur l'utilisateur qui a été l'acteur principal décrit dans l'événement. Cet exemple inclut l'adresse IP et le numéro de port de l'appareil, ainsi que son nom d'hôte. Il inclut également un identifiant d'élément provenant de Sophos, qui est un identifiant 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 principal et B est la cible. Pour l'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 est décrit comme la cible.

principal ou cible dans udm Versus principal cible dans UDM

L'exemple suivant illustre le remplissage des champs d'une cible:

target {
   ip: "198.51.100.31"
   port: 80
}

Encore une fois, si d'autres informations sont disponibles (nom d'hôte, adresses IP supplémentaires, adresses MAC, identifiants d'éléments propriétaires, etc.), elles doivent également être incluses dans l'élément target.

principal et target (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 traité par le participant et le contexte de l'appareil ou du processus pour l'objet source (la machine où se trouve l'objet source). Par exemple, si l'utilisateur U copie le fichier A sur la machine X dans le fichier B sur la machine Y, les fichiers A et la machine X seront spécifiés dans la partie src de l'événement UDM.
  • intermédiaire:correspond aux détails relatifs à un ou plusieurs appareils intermédiaires ayant traité l'activité décrite dans l'événement. y compris des informations sur l'appareil concernant un serveur proxy, un serveur de relais SMTP, etc.
  • observateur:représente un observateur (par exemple, un outil de détection de paquets ou un outil d'analyse des failles basé sur le réseau), qui n'est pas un intermédiaire direct, mais qui observe et signale l'événement en question.
  • about:pour stocker les détails de tous les objets référencés par l'événement qui ne sont pas décrits dans participant, src, target, intermédiaire ou observateur. Elle permet par exemple d'effectuer le suivi des éléments suivants :
    • Envoyer des pièces jointes par e-mail
    • Domaines/URL/adresses IP intégrés dans un corps d'e-mail
    • DLL chargées pendant un événement PROCESS_LAUNCH

Les sections liées aux événements UDM contiennent 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 Chronicle impose des exigences obligatoires pour 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 varie en fonction du type d'événement.

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

Vous pouvez éventuellement spécifier des résultats de sécurité en renseignant les champs SecurityResult, y compris les détails des risques de sécurité et des menaces détectés par le système de sécurité, ainsi que les actions effectuées pour limiter ces risques et menaces. Voici des exemples de certains des é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é (BLOCK) l'e-mail.
  • Un pare-feu proxy de sécurité des e-mails a détecté deux pièces jointes infectées (SOFTWARE_MALICIOUS) et mises en quarantaine et désinfectées (QUARANTINE, ALLOW_WITH_MODIFICATION). Ces pièces jointes ont ensuite été transférées par e-mail.
  • Un système SSO a facilité la connexion (AUTH_VIOLATION) qui a été bloquée (BLOCK).
  • Un bac à sable contenant des logiciels malveillants a détecté un logiciel espion (SOFTWARE_MALICIOUS) dans une pièce jointe cinq minutes après l'envoi du fichier (AUTORISATION) à l'utilisateur dans sa boîte de réception.